Säkerhetsalternativ

Det här avsnittet beskriver utvecklingen av och funktionen hos API:t för RPCSEC_GSS.

Säkerhetsfunktioner före RPCSEC_GSS

Ett av de första säkerhetsalternativ som stöddes av RPC var AUTH_SYS (kallas även AUTH_UNIX). AUTH_SYS gav en UNIX-liknande referensfunktion, med identifikationsnummer för grupper och användare, för att identifiera avsändare och mottagare av meddelanden. Det är enkelt att implementera AUTH_SYS, men det är samtidigt enkelt att förbigå funktionen eftersom den inte har äkta verifiering - det finns inget sätt för servern att verifiera att klienten verkligen är den som den utger sig för att vara. Därför är det ganska enkelt att förfalska nätverksanrop under AUTH_SYS.

Ett senare säkerhetsalternativ, AUTH_DES, introducerades strax efter AUTH_SYS. AUTH_DES är baserat på verifiering med offentliga nycklar - funktioner använder nyckelutväxling enligt Diffie-Hellman för att skapa en gemensam nyckel mellan klientens privata nyckel och serverns offentliga nyckel. Den gemensamma nyckeln används sedan för kryptering av en DES-sessionsnyckel, vilken sedan dekrypteras av servern så att en session kan upprättas.

Trots att AUTH_DES är klart bättre än AUTH_SYS finns det ett par begränsningar som har gjort att funktionen aldrig fått någon större utbredning. Det största problemet enligt många användare är att nycklarna är underdimensionerade enligt dagens krypteringsstandarder.

Därför lanserades så småningom ytterligare ett säkerhetsalternativ för RPC. AUTH_KERB, baserat på Kerberos V4, ger bättre säkerhet än både AUTH_DES och AUTH_SYS. AUTH_KERB är dock inte helt säkert.

Mer information om de här säkerhetsalternativen finns i ONC+ Developer's Guide.

Integritet och skydd av personuppgifter: API:t för GSS

Ett nytt nätverksskikt, API:t för GSS (Generic Security Standard), har lagts till för att förbättra säkerheten. Ramverket för API:t för GSS innehåller förutom verifiering två ytterligare säkerhetstjänster:

• Integritet. För integritetstjänsten (integrity) använder GSS-API:t den underliggande mekanismen för att verifiera meddelanden som skickas mellan program. Kryptografiska kontrollsummor säkerställer:

  • Att mottagaren får veta vem som har skickat informationen.

  • Att den som skickar får veta vem som tar emot informationen (om ömsesidig verifiering är begärd).

  • Tillförlitligheten hos den överförda informationen.

• Skydd av personuppgifter. Tjänsten för skydd av personuppgifter (privacy) omfattar även integritetstjänsten. Dessutom krypteras överförd data så att ingen kan tjuvlyssna på den.

  På grund av USA:s exportregler är det inte säkert att tjänsten för skydd av personuppgifter finns tillgänglig för alla användare av SEAM.

För närvarande visas inte GSS-API:t. Vissa GSS-API-funktioner är dock "synliga" via RPCSEC_GSS-funktioner - de kan ändras "indirekt". Programmeraren behöver inte direkt ta hänsyn till funktionernas värden.

API:t för RPCSEC_GSS

Med säkerhetsalternativet RPCSEC_GSS kan ONC-RPC-program använda funktionerna i GSS-API:t. RPCSEC_GSS är placerat "ovanpå" GSS-API-lagret enligt följande:

Figur 8-1 Säkerhetslagren GSS-API och RPCSEC_GSS

Med programmeringsgränssnittet för RPCSEC_GSS kan ONC-RPC-program ange:

mekanism

Ett säkerhetsparadigm. De olika säkerhetsmekanismerna har olika typer och en eller flera nivåer av av dataskydd. Det här gäller säkerhetsmekanismer som stöds av GSS-API:t (Kerberos V5, offentlig RSA-nyckel osv).

säkerhetstjänst

Antingen skydd av personuppgifter eller integritet (eller ingen av dem). Integritetstjänsten är standard. Tjänsten är oberoende av mekanism.

QOP

QOP (Quality of Protection, skyddsegenskap). QOP anger vilken krypteringsalgoritm som ska användas för implementering av tjänsterna för integritet och skydd av personuppgifter. Alla säkerhetsmekanismer kan vara associerade med en eller flera QOP:er.

Program kan hämta listor med giltiga QOP:er och mekanismer genom funktioner i RPCSEC_GSS. (Läs "Diverse funktioner".) Utvecklarna bör undvika att använda mekanismer och QOP:er för hårdkodning i sina program så att programmen inte behöver ändras för att använda andra mekanismer och QOP:er.

Från början betydde "säkerhetsalternativ" och "verifieringsalternativ" samma sak. Sedan introduktionen av RPCSEC_GSS har "alternativ" dock fått en något annorlunda innebörd. Nu kan ett alternativ omfatta en tjänst (integritet eller skydd av personuppgifter) förutom verifiering. Än så länge är det dock bara alternativet RPCSEC_GSS som gör det detta.

ONC-RPC-program använder RPCSEC_GSS för att upprätta säkra anslutningar med motparter, utväxla data och förstöra anslutningarna, på samma sätt som med andra alternativ. När en anslutning är upprättad kan programmet ändra QOP och tjänst för var och en av dataenheterna som skickas.

Mer information om RPCSEC_GSS, bl a om datatyper för RPCSEC_GSS, finns i direkthjälpsavsnittet (man page) rpcsec_gss(3N).