Oakley-protokollen

Oakley -protokollen er en nøgleaftaleprotokol, der giver to godkendte parter mulighed for sikkert at blive enige om nøglemateriale . Protokollen blev foreslået af Hilary K. Orman i 1998 og dannede grundlaget for den mere udbredte Internet Key Exchange protokol .

Protokolegenskaber

Generelle bestemmelser

Formålet med nøgleudvekslingsbehandling er sikkert at etablere en delt tilstand af nøgleoplysninger om de to parter. Denne tilstandsinformation er nøglenavnet, det hemmelige nøglemateriale, identiteten af ​​de to parter og tre algoritmer, der skal bruges under godkendelse: kryptering (for at holde de to parters identitet fortrolig), hashing ( en pseudo-tilfældig funktion til at beskytte meddelelsesintegritet og til autentificering af meddelelsesfelter) og autentificering (algoritmen, som den gensidige autentificering af to parter er baseret på).

Hovedtilstandsudvekslingen har fem yderligere funktioner: statsløs cookieudveksling, perfekt videresendelseshemmelighed for nøglemateriale, hemmelighed for identiteter, absolut fremadrettet hemmeligholdelse for identitet, brug af signaturer (til ikke-afvisning). Begge parter kan bruge enhver kombination af disse funktioner.

Den generelle behandlingsplan er, at Exchange Initiator starter med at angive så mange oplysninger som muligt i sin første besked. Respondenten svarer ved at give så mange oplysninger, som den ønsker. Begge parter udveksler beskeder, hver gang de giver mere information, indtil deres krav er opfyldt.

Valget af, hvor meget information der skal inkluderes i hver besked afhænger af hvilke parametre der ønskes. For eksempel, hvis statsløse cookies er valgfrie, og identitetshemmelighed og perfekt videresendelseshemmelighed for nøglemateriale er valgfrit, og hvis ikke-afviste signaturer er tilladt, så kan udvekslingen gennemføres i tre meddelelser. Yderligere funktioner kan øge antallet af cyklusser, der kræves for at bestemme nøglematerialet.

ISAKMP leverer felter til at specificere sikkerhedstilknytningsmuligheder til brug med AH- og ESP -protokollerne . Disse typer af sikkerhedsforeningsnyttelast er specificeret i ISAKMP-specifikationen; nyttelasttyper kan sikres ved hjælp af nøglemateriale og Oakley-algoritmer.

Key Exchange Protocol

Idé

Nøgleudvekslingen kan gennemføres i tre eller flere meddelelser, men det nøjagtige antal meddelelser bestemmes af parternes valg af muligheder.

Hovedkomponenterne i protokollen:

  1. Cookie-deling (statsløs tilstand mulig);
  2. Diffie-Hellman delvis nøgleudveksling ;
  3. Autentificering (med muligheder for at opnå ikke-afvisning, privatliv for identiteter med eller uden fuld fremadrettet hemmeligholdelse).

I begyndelsen af ​​udvekslingen kan initiatoren sende til responderen både minimumsdatasættet for en nøgleudvekslingsanmodning uden yderligere information, eller give mere information op til alle de nødvendige oplysninger til autentificering og hurtig afslutning af nøglebestemmelse. Som svar vil initiativtageren modtage, afhængigt af den oprindeligt transmitterede information, mindst en cookie.

Godkendelsesmetoden kan enten være digitale signaturer eller asymmetrisk kryptering , en symmetrisk nøgle uden for båndet. Hver metode introducerer små forskelle i budskaberne mellem parterne.

Initiativtageren er ansvarlig for at videresende beskeder til responderen i tilfælde af fejl, så responderen skal gemme informationen modtaget under udvekslingen, indtil denne information er kvitteret.

Notation
  • "->" - besked sendt fra initiativtageren (I) til responderen (R)
  • "<-" - besked sendt fra responderen (R) til initiativtageren (I)

Alle felter i meddelelsen er navngivet og adskilt af et komma.

  • EHAO - Liste over tilgængelige kryptering, hashing og godkendelsesalgoritmer. Hvert element er et værdipar af et klassenavn og et algoritmenavn.
  • EHAS - tre udvalgte elementer fra EHAO. Et element af kryptering, hashing og autentificering.
  • GRP er et 32-bit navn for gruppen og tilhørende parametre - størrelse af heltal, aritmetisk operation og generatorelement.
  • Lodret stregtegn "|" bruges til at betegne sammenkædningen af ​​bitstrenge. Felterne er sammenkædet ved hjælp af deres kodede form, når de vises i nyttelasten.
  • Ni og Nr er noncer valgt af henholdsvis initiativtager og responder.
  • ID(I) og ID(R) er identifikatorer, der bruges til godkendelse.
  • E{x}Ki — kryptering af x ved hjælp af initiativtagerens offentlige nøgle.
  • S{x}Ki — signering over xc ved hjælp af initiativtagerens private nøgle.
  • prf(a, b) er en hashing- eller envejsblandingsfunktion for input "b" ved brug af den pseudo-tilfældige nøgle "a".
  • prf(0, b) - anvende hashing på data "b".
  • NIDP - Et flag om, at PFS-faciliteten til identitetsskjul ikke bruges.
  • IDP - Et flag om, at godkendelsesdataene er krypteret ved hjælp af den valgte krypteringsalgoritme ved hjælp af prf(0, g^xy) nøglen.
Aggressiv tilstand

Aggressiv nøgleudvekslingstilstand giver dig mulighed for at indstille nøgleoplysninger i tre beskeder. I denne tilstand er parternes identifikatorer ikke hemmelige, men det modtagne nøglemateriale opfylder betingelserne for fuld fremadrettet hemmeligholdelse.

Brugen af ​​digitale signaturer til autentificering giver bevis for tilknytning til parter, og disse data kan også optages og præsenteres for tredjeparter.

Når det er sagt, kræves det nøglemateriale, som gruppeudstillere antyder, ikke for at gennemføre udvekslingen. Hvis det ønskes at udskyde beregningen, er det muligt at gemme disse "x" og "g^y" værdier, med dette nøglemateriale markeret som "uberegnet".

Initiativtager tiltalte
-> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ID(I), ID(R), Ni, 0,

S{ID(I)|ID(R)|Ni|0|GRP|g^x|0|EHAO}Ki

->
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, ID(R), ID(I), Nr, Ni,

S{ID(R)|ID(I)|Nr|Ni|GRP|g^y|g^x|EHAS}Kr

<-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, ID(I), ID(R), Ni, Nr,

S{ID(I)|ID(R)|Ni|Nr|GRP|g^x|g^y|EHAS}Ki

->

Resultatet af udvekslingen er en nøgle med identifikationen KEYID og værdien sKEYID:

KEYID = CKY-I|CKY-R;

sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).

Udvekslingsskema i aggressiv tilstand:

  1. Initiativtageren opretter en unik cookie, knytter den til den forventede responder-IP-adresse og valgte tilstandsoplysninger: GRP (Group ID), pseudo-tilfældigt tal x, g^x, EHAO, Ni (nonce), ID(I), ID( R). Den første godkendelsesmulighed på EHAO-listen er en algoritme, der understøtter digitale signaturer og bruges til at signere identifikatorer, noncer og gruppeidentifikatorer. Initiativtageren bemærker derefter, at nøglen er i den indledende "uautentificerede" tilstand og indstiller en timer til at gentransmittere meddelelsen og/eller fuldføre anmodningen.
  2. Hvis CKY-I ikke allerede bruges af kildeadressen i IP-headeren, opretter svaret en unik CKY-R-cookie. Yderligere handlinger afhænger af respondentens præferencer. Responderen kan ignorere al modtaget information og gå til standardtilstand, eller som svar give en gruppe med GRP-identifikationen, det første valg af godkendelse (bekræftelse af initiativtagerens valg, da svaret ellers ikke vil være i stand til at bekræfte signaturen af initiativtageren), NIDP, identifikatorer.
  3. Initiativtageren bekræfter CKY-I som en gyldig tilknytning til netværksadressen for den indgående meddelelse, tilføjer CKY-R værdien til tilstanden af ​​(CKY-I, netværksadresse) parret og knytter al tilstandsinformation til parret (CKY) -I, CKY-R), verificerer signatursvareren, holder g^y og EHAS i tilstand. Kan beregne (g^y)^x (= g^xy) (dette kan forsinkes, indtil svarbeskeden sendes). Markerer KEYID (CKY-I|CKY-R) som godkendt, komponerer derefter en svarmeddelelse, underskriver den og sender den til den, der svarer.
  4. Svarpersonen, efter at have modtaget beskeden, verificerer signaturen, markerer nøglen som autentificeret, beregner g^(xy) og forbinder den med KEYID.

I alle udvekslinger sikrer hver side, at den ikke tilbyder eller accepterer 1 eller g^(p-1) som eksponent. På samme tid, på trods af fraværet af PFS til beskyttelse af identifikatorer, er PFS for det modtagne nøglemateriale til stede, da delvise Diffie-Hellman nøgler udveksles.

Hvis respondenten kun accepterer en del af initiativtagerens information, så vil initiativtageren antage, at protokollen er i gang. Initiativtageren må gå ud fra, at de felter, der ikke blev accepteret af respondenten, ikke er skrevet af respondenten. Hvis svaret ikke accepterer den aggressive udveksling og vælger en anden algoritme til autentificeringsfunktionen, går protokollen til standardtilstand, og parterne holder op med at bruge signaturalgoritmen fra den første besked.

Når respondenten ikke accepterer felterne foreslået af initiativtageren, inkluderer den null-værdier for disse felter i sit svar, hvor alle efterfølgende felter skal være null. Hvis identifikatorer og noncer har nulværdier, vil der ikke være nogen signatur over disse nulværdier.

Med skjulte identifikatorer

Offentlig nøglekryptering skjuler identitet under godkendelse. Gruppeeksponenter udveksles og autentificeres, men det underforståede nøglemateriale (g^xy) er ikke påkrævet under udvekslingen.

Denne udveksling har en vigtig forskel fra det tidligere signaturskema - i den første meddelelse er identifikatoren for svaret angivet i almindelig tekst: ID(R'). Imidlertid er identiteten skjult af offentlig nøglekryptografi anderledes: ID(R). Dette skyldes, at initiativtageren skal fortælle responderen, hvilket offentligt/privat nøglepar, der skal bruges til dekryptering, men samtidig skjules identiteten ved kryptering med den offentlige nøgle.

Initiativtageren kan vælge at give afkald på respondentens identitet, men det er uønsket. I stedet, hvis der er et velkendt responder-værts-id, kan den offentlige nøgle til dette ID bruges til at kryptere responderens faktiske værts-id.

Initiativtager tiltalte
-> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP,

ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr'

->
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP,

E{ID(R), ID(I), Nr}Ki,

prf(Kir, ID(R)|ID(I)|GRP|g^y|g^x|EHAS)

<-
-> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP,

prf(Kir, ID(I)|ID(R)|GRP|g^x|g^y|EHAS)

->

Kir = prf(0, Ni | Nr)

NØGLEID = CKY-I|CKY-R

sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)

Udvekslingsskema i aggressiv tilstand med skjulte identifikatorer:

  1. Initiativtageren opretter en unik cookie, forbinder denne cookie med den forventede responder IP-adresse og udvalgte tilstandsoplysninger: GRP, g^x, EHAO, identifikatorer. Den første godkendelsesmulighed på EHAO-listen er en algoritme, der understøtter offentlig nøglekryptering. Initiativtageren har en velkendt identifikator for den reagerende maskine og dens tilsvarende offentlige nøgle; denne nøgle krypterer ikke-Ni og to forbindelsesidentifikatorer. Initiativtageren bemærker derefter, at nøglen er i den indledende "uautentificerede" tilstand og indstiller en timer til at gentransmittere meddelelsen og/eller fuldføre anmodningen.
  2. Hvis CKY-I ikke allerede bruges af kildeadressen i IP-headeren, opretter svaret en unik CKY-R-cookie. Yderligere handlinger afhænger af respondentens præferencer. Responderen kan ignorere al modtaget information og gå til standardtilstand, eller som svar give en gruppe med GRP-identifikationen, det første valg af autentificering (bekræftelse af initiatorens valg, da svaret ellers ikke vil være i stand til at dekryptere initiatoren data), NIDP, identifikatorerne for responderen og initiativtageren. Reageren skal dekryptere identifikatoren og nonce-informationen ved hjælp af den private nøgle til R'ID'et. Den private R ID-nøgle vil derefter blive brugt til at dekryptere nonce-feltet. Reageren krypterer derefter tilstandsinformationen med den offentlige nøgle ID(I), genererer en prf-værdi og sender en besked til initiativtageren.
  3. Initiativtageren bekræfter CKY-I som en gyldig tilknytning til netværksadressen for den indgående meddelelse, tilføjer CKY-R-værdien til parrets tilstand (CKY-I, netværksadresse) og knytter alle tilstandsoplysninger til parret (CKY) -I, CKY-R). Dekrypterer id og nonce information Nr, kontrollerer prf beregning, gemmer g^y og EHAS i tilstand. Kan beregne (g^y)^x (= g^xy) (dette kan forsinkes, indtil svarbeskeden sendes). Markerer KEYID (CKY-I|CKY-R) som autentificeret, komponerer derefter en svarmeddelelse, krypterer den med den offentlige nøgle og sender den til svaret.
  4. Svarpersonen modtager denne besked, den markerer nøglen som værende i den godkendte tilstand. Hvis den ikke allerede har gjort det, skal den beregne g^xy og knytte den til KEYID.

sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)

På samme tid, på trods af fraværet af PFS til beskyttelse af identifikatorer, er PFS for det modtagne nøglemateriale til stede, da delvise Diffie-Hellman nøgler g^x og g^y udveksles.

Med skjulte identifikatorer uden Diffie-Hellman

Betydelige beregningsmæssige overhead kan undgås, hvis fuld fremadrettet hemmeligholdelse ikke er et krav for at opnå en sessionsnøgle. Begge parter kan udveksle noncer og dele af den hemmelige nøgle til godkendelse og opnåelse af nøglemateriale. Den langsigtede fortrolighed af data, der er beskyttet med afledt nøglemateriale, afhænger af hver parts private nøgler.

I udvekslingen nedenfor er GRP sat til 0, og gruppeeksponentfeltet bruges i stedet til at gemme nonce-værdien. Den første foreslåede algoritme ville være et offentligt nøglekrypteringssystem; ved at svare med en cookie og et ikke-nul eksponentielt felt, accepterer Responderen implicit den første sætning og manglen på fuld fremadrettet hemmeligholdelse for identifikatorer og afledt nøglemateriale.

Initiativtager tiltalte
-> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP,

ID(R'), E{ID(I), ID(R), sKi}Kr', Ni

->
<- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP,

E{ID(R), ID(I), sKr}Ki, Nr,

prf(Kir, ID(R)|ID(I)|Nr|Ni|EHAS)

<-
-> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP,

prf(Kir, ID(I)|ID(R)|Ni|Nr|EHAS)

->

Kir = prf(0, sKi | sKr)

NØGLEID = CKY-I|CKY-R

sKEYID = prf(Kir, CKY-I | CKY-R)

Standardtilstand

Standardtilstand er kendetegnet ved, at der sendes færre informationer i hver besked.

Her er et eksempel, hvor parter bruger en cookie-udveksling til at udskyde oprettelse af staten, bruge fuld fremsendelseshemmelighed for at beskytte identitet og bruge offentlig nøglekryptering til godkendelse. Digitale signaturer og foruddelte nøgler kan dog også bruges som en godkendelsesmetode.

Reageren betragter initiativtagerens evne til at gentage CKY-R som et svagt bevis på, at meddelelsen stammer fra en "live" responder på netværket, og at responderen er forbundet med initiativtagerens netværksadresse. Initiativtageren gør lignende antagelser, når CKY-I gentages til initiatoren.

Alle meddelelser skal have enten gyldige cookies eller mindst én nul-cookie. Hvis begge cookies er nul, indikerer dette en cookie-anmodning; hvis kun initiativtagerens cookie er nul, er det et svar på en cookie-anmodning.

Alle uspecificerede felter har null-værdier:

Initiativtager tiltalte
-> 0, 0, OK_KEYX ->
<- 0, CKY-R, OK_KEYX <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO ->
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP,

ID(I), ID(R), E{Ni}Kr

->
<- CKY-R, CKY-I, OK_KEYX, GRP, 0, 0, IDP,

E{Nr, Ni}Ki, ID(R), ID(I),

prf(Kir, ID(R)|ID(I)|GRP|g^y|g^x|EHAS)

<-
-> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, IDP,

prf(Kir, ID(I)|ID(R)|GRP|g^x|g^y|EHAS)

->

Kir = prf(0, Ni | Nr)

sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)

Udvekslingsskema i standardtilstand:

  1. Udveksling af cookies. Initiativtageren MÅSKE sende sin egen cookie på den første anmodning, men respondenten MÅSKE vælge ikke at gemme denne cookie ved at udelade CKY-I i sit svar, denne adfærd er mulig og anses for acceptabel.
  2. Efter at cookie-udvekslingen er afsluttet, beregner parterne det offentlige nøglemateriale til sKEYID. (Prf-funktionen, der bruges til at beregne nøglen, er en pseudo-tilfældig funktion i "hash"-klassen fra EHAS.

Som med cookies, betragter hver side fjernsidens evne til at replikere værdien Ni eller Nr som bevis på, at Ka, side A's offentlige nøgle, taler på vegne af fjernsiden og etablerer dens identitet.

Bemærk, at mens IDP-flaget sikrer, at identiteterne er beskyttet af den delte nøgle g^xy, er selve godkendelsen uafhængig af g^xy. Det er vigtigt, at godkendelsestrinnene kontrollerer g^x- og g^y-værdierne, og derfor er det vigtigt, at godkendelsen ikke involverer en cirkulær afhængighed af dem. En tredjepart kan gribe ind på en man-in-the-midten måde for at overbevise initiativtageren og responderen til at bruge forskellige værdier af g^xy; selvom et sådant angreb kan afsløre identiteten til en interceptor, ville godkendelse mislykkes.

Noncerne Ni og Nr bruges til at give en yderligere sikkerhedsforanstaltning ved udledning af sessionsnøgler. Dette gør nøglehemmeligheden afhængig af to forskellige problemer: det diskrete logaritmeproblem i gruppe G og problemet med at bryde nonce-krypteringsskemaet. Hvis der bruges RSA-kryptering, svarer dette andet problem nogenlunde til at faktorisere de offentlige RSA-nøgler for både initiativtageren og responderen.

Hurtig tilstand

Når først et godkendt KEYID og tilhørende sKEYID-nøglemateriale allerede eksisterer, er det nemt at få yderligere KEYID'er og nøgler med lignende attributter (GRP, EHAS osv.) ved at bruge hash-funktioner alene.

Alternativt kan den autentificerede nøgle være en manuelt distribueret nøgle, der deles mellem initiatoren og den, der reagerer, via nogle midler, der er udenfor Oakley. Hvis en distributionsmetode genererede et KEYID ved hjælp af de tilsvarende unikke værdier for de to halvdele (CKY-I og CKY-R), så er denne metode anvendelig.

Det følgende bruger Oakley Quick Mode som nøgleudvekslings-id. Nonces sendes i godkendelsesnyttelasten, og prf-værdien sendes i godkendelsesnyttelasten; Godkendelsesautoriteten er "Ingen", og typen er "Foruddelt".

Protokol:

Initiativtager tiltalte
-> KEYID, INEWKRQ, Ni, prf(sKEYID, Ni) ->
<- KEYID, INEWKRS, Nr, prf(sKEYID, 1|Nr|Ni) <-
-> KEYID, INEWKRP, 0, prf(sKEYID, 0|Ni|Nr) ->

NKEYID = Ni | Ingen.

sNKEYID = prf(sKEYID, Ni | Nr)

De legitimationsoplysninger og EHA-værdier, der er forbundet med et NKEYID, er de samme som for et KEYID. Hver part skal verificere hash-værdierne, før du bruger den nye nøgle til ethvert formål.

Kompatibilitet med ISAKMP

Alle felter i OAKLEY-meddelelsen svarer til ISAKMP-meddelelsens nyttelast eller nyttelastkomponenter.

CKY-I - ISAKMP header

CKY-R - ISAKMP header

MSGTYPE - Meddelelsestype i ISAKMP header

GRP - SA belastning, Tilbudssektion

g^x - nøgleudvekslingens nyttelast kodet som et heltal med variabel præcision

g^y - nøgleudvekslingens nyttelast kodet som et heltal med variabel præcision

EHAO - SA nyttelast, sætningsafsnit

EHAS-SA

IDP er lidt i det reserverede felt i AUTH-headeren

ID(I) - AUTH-belastning, identifikationsfelt

ID(R) - AUTH-belastning, identifikationsfelt

Ni - AUTH nyttelast, nonce-felt

Nr - AUTH nyttelast, nonce-felt

S{...}Kx - AUTH-belastning, datafelt

prf{K,...} - AUTH nyttelast, datafelt

Eksterne links

  • RFC 2412 OAKLEY Key Determination Protocol