Oakleys protokoll

Oakley- protokollet är ett nyckelavtalsprotokoll som tillåter två autentiserade parter att säkert komma överens om nyckelmaterial . Protokollet föreslogs av Hilary K. Orman 1998 och utgjorde grunden för det mer utbredda Internet Key Exchange- protokollet .

Protokollegenskaper

Allmänna bestämmelser

Syftet med bearbetning av nyckelutbyte är att på ett säkert sätt upprätta ett delat tillstånd av nyckelinformation om de två parterna. Denna tillståndsinformation är nyckelnamnet, det hemliga nyckelmaterialet, identiteten för de två parterna och tre algoritmer att använda under autentisering: kryptering (för att hålla de två parternas identitet konfidentiell), hashing ( en pseudo-slumpmässig funktion för att skydda meddelandeintegritet och för att autentisera meddelandefält), och autentisering (algoritmen som den ömsesidiga autentiseringen av två parter bygger på).

Huvudlägesutbytet har fem ytterligare funktioner: statslöst cookie-utbyte, perfekt vidarebefordran av nyckelmaterial, sekretess för identiteter, absolut vidarebefordran för identitet, användning av signaturer (för icke-avvisande). Båda parter kan använda vilken kombination som helst av dessa funktioner.

Det allmänna bearbetningsschemat är att Exchange Initiator börjar med att specificera så mycket information som möjligt i sitt första meddelande. Respondenten svarar med att ge så mycket information som den vill. Båda parter utbyter meddelanden, varje gång ger mer information, tills deras krav uppfylls.

Valet av hur mycket information som ska inkluderas i varje meddelande beror på vilka parametrar som önskas. Till exempel, om tillståndslösa cookies är valfria, och identitetssekretess och perfekt vidarebefordran av nyckelmaterial är valfria, och om icke-avvisade signaturer tillåts, kan utbytet slutföras i tre meddelanden. Ytterligare funktioner kan öka antalet cykler som krävs för att bestämma nyckelmaterialet.

ISAKMP tillhandahåller fält för att specificera säkerhetsassocieringsalternativ för användning med AH- och ESP- protokollen . Dessa säkerhetsföreningsnyttolasttyper är specificerade i ISAKMP-specifikationen; nyttolasttyper kan säkras med hjälp av nyckelmaterial och Oakley-algoritmer.

Key Exchange Protocol

Idé

Nyckelutbytet kan genomföras i tre eller flera meddelanden, men det exakta antalet meddelanden bestäms av parternas val av alternativ.

Huvudkomponenterna i protokollet:

  1. Cookiedelning (tillståndslöst läge möjligt);
  2. Diffie-Hellman partiell nyckelutbyte ;
  3. Autentisering (med alternativ för att uppnå icke-avvisande, sekretess för identiteter med eller utan fullständig sekretess).

I början av utbytet kan initiatorn sända till svaranden både minimidatauppsättningen för en nyckelutbytesbegäran utan ytterligare information, eller tillhandahålla mer information upp till all nödvändig information för autentisering och snabbt slutförande av nyckelbestämning. Som svar får initiativtagaren, beroende på den information som ursprungligen överfördes, åtminstone en cookie.

Autentiseringsmetoden kan vara antingen digitala signaturer eller asymmetrisk kryptering , en symmetrisk nyckel utanför bandet. Varje metod introducerar små skillnader i budskapen mellan parterna.

Initiativtagaren ansvarar för att återsända meddelanden till svarsmottagaren vid fel, så svarspersonen måste lagra informationen som tagits emot under utbytet tills denna information bekräftas.

Notation
  • "->" - meddelande skickat från initiatorn (I) till svararen (R)
  • "<-" - meddelande skickat från svararen (R) till initiatorn (I)

Alla fält i meddelandet namnges och separeras med ett kommatecken.

  • EHAO - Lista över tillgängliga krypterings-, hash- och autentiseringsalgoritmer. Varje element är ett värdepar av ett klassnamn och ett algoritmnamn.
  • EHAS - tre utvalda element från EHAO. En del av kryptering, hash och autentisering.
  • GRP är ett 32-bitars namn för gruppen och tillhörande parametrar - storlek på heltal, aritmetisk operation och generatorelement.
  • Vertikal strecktecken "|" används för att beteckna sammanlänkningen av bitsträngar. Fälten sammanfogas med hjälp av sin kodade form när de visas i nyttolasten.
  • Ni och Nr är nonser valda av initiatorn respektive svarspersonen.
  • ID(I) och ID(R) är identifierare som används för autentisering.
  • E{x}Ki — kryptering av x med initiatorns publika nyckel.
  • S{x}Ki — signering över xc med initiatorns privata nyckel.
  • prf(a, b) är en hash- eller envägsblandningsfunktion för ingången "b" med pseudoslumptangenten "a".
  • prf(0, b) - tillämpa hashing på data "b".
  • NIDP - En flagga som PFS-funktionen för identitetsdöljning inte används.
  • IDP - En flagga som visar att autentiseringsdata krypteras med den valda krypteringsalgoritmen med nyckeln prf(0, g^xy).
Aggressivt läge

Aggressivt nyckelutbytesläge låter dig ställa in nyckelinformation i tre meddelanden. I det här läget är parternas identifierare inte hemliga, men det mottagna nyckelmaterialet uppfyller villkoren för full framåtsekretess.

Användningen av digitala signaturer för autentisering ger bevis på associering till parter, och dessa data kan också registreras och presenteras för tredje part.

Med detta sagt krävs inte nyckelmaterialet från grupputställare för att genomföra utbytet. Om man önskar skjuta upp beräkningen är det möjligt att lagra dessa "x"- och "g^y"-värden, med detta nyckelmaterial markerat som "oberäknat".

Initiativtagare svarande
-> 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 av utbytet är en nyckel med identifieraren KEYID och värdet sKEYID:

KEYID = CKY-I|CKY-R;

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

Utbytesschema i aggressivt läge:

  1. Initiativtagaren skapar en unik cookie, associerar den med den förväntade svararens IP-adress och vald tillståndsinformation: GRP (Group ID), pseudo-slumpmässigt nummer x, g^x, EHAO, Ni (nonce), ID(I), ID( R). Det första autentiseringsalternativet på EHAO-listan är en algoritm som stöder digitala signaturer och som används för att signera identifierare, nonces och gruppidentifierare. Initiatorn noterar sedan att nyckeln är i det initiala "oautentiserade" tillståndet och ställer in en timer för att återsända meddelandet och/eller slutföra begäran.
  2. Om CKY-I inte redan används av källadressen i IP-huvudet, skapar svararen en unik CKY-R-cookie. Ytterligare åtgärder beror på respondentens preferenser. Svararen kan ignorera all mottagen information och gå till standardläge, eller som svar ge en grupp med GRP-identifieraren, det första valet av autentisering (bekräftelse av valet av initiatorn, eftersom annars svararen inte kommer att kunna bekräfta signaturen av initiatorn), NIDP, identifierare.
  3. Initiatorn bekräftar CKY-I som en giltig association för nätverksadressen för det inkommande meddelandet, lägger till CKY-R-värdet till tillståndet för (CKY-I, nätverksadress) paret och associerar all tillståndsinformation med paret (CKY) -I, CKY-R), verifierar signatursvararen, håller g^y och EHAS i tillstånd. Kan beräkna (g^y)^x (= g^xy) (detta kan fördröjas tills svarsmeddelandet skickas). Markerar KEYID (CKY-I|CKY-R) som autentiserat, skriver sedan ett svarsmeddelande, signerar det och skickar det till svarspersonen.
  4. Svararen, när han tar emot meddelandet, verifierar signaturen, markerar nyckeln som autentiserad, beräknar g^(xy) och associerar den med KEYID.

I alla byten säkerställer varje sida att den inte erbjuder eller accepterar 1 eller g^(p-1) som exponent. Samtidigt, trots frånvaron av PFS för att skydda identifierare, finns PFS för det mottagna nyckelmaterialet, eftersom partiella Diffie-Hellman-nycklar utbyts.

Om svaranden endast accepterar en del av initiatorns information, kommer initiatorn att anta att protokollet pågår. Initiativtagaren måste utgå från att de fält som inte accepterades av den som svarade inte skrevs av den som svarade. Om svarsmottagaren inte accepterar det aggressiva utbytet och väljer en annan algoritm för autentiseringsfunktionen, går protokollet till standardläge och parterna slutar använda signaturalgoritmen från det första meddelandet.

När svarsmottagaren inte accepterar fälten som föreslagits av initiativtagaren, inkluderar den nollvärden för dessa fält i sitt svar, med alla efterföljande fält måste vara null. Om identifierare och noncer har nollvärden, kommer det inte att finnas någon signatur över dessa nollvärden.

Med dolda identifierare

Offentlig nyckelkryptering döljer identitet under autentisering. Gruppexponenter utbyts och autentiseras, men det underförstådda nyckelmaterialet (g^xy) krävs inte under utbytet.

Detta utbyte har en viktig skillnad från det tidigare signaturschemat - i det första meddelandet indikeras svarspersonens identifierare i klartext: ID(R'). Identiteten som döljs av kryptografi med publik nyckel är dock annorlunda: ID(R). Detta beror på att initiatorn måste tala om för svararen vilket offentligt/privat nyckelpar som ska användas för dekryptering, men samtidigt döljs identiteten av kryptering med den publika nyckeln.

Initiativtagaren kan välja att avstå från respondentens identitet, men det är inte önskvärt. Istället, om det finns ett välkänt svarsvärd-ID, kan den publika nyckeln för det ID:t användas för att kryptera svararens faktiska värd-ID.

Initiativtagare svarande
-> 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)

KEYID = CKY-I|CKY-R

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

Exchange-schema i aggressivt läge med dolda identifierare:

  1. Initiativtagaren skapar en unik cookie, associerar denna cookie med den förväntade svararens IP-adress och vald tillståndsinformation: GRP, g^x, EHAO, identifierare. Det första autentiseringsalternativet på EHAO-listan är en algoritm som stöder kryptering av offentlig nyckel. Initiatorn har en välkänd identifierare för den svarande maskinen och dess motsvarande publika nyckel; denna nyckel krypterar icke-Ni och två anslutningsidentifierare. Initiatorn noterar sedan att nyckeln är i det initiala "oautentiserade" tillståndet och ställer in en timer för att återsända meddelandet och/eller slutföra begäran.
  2. Om CKY-I inte redan används av källadressen i IP-huvudet, skapar svararen en unik CKY-R-cookie. Ytterligare åtgärder beror på respondentens preferenser. Svararen kan ignorera all mottagen information och gå till standardläge, eller som svar ge en grupp med GRP-identifieraren, det första valet av autentisering (bekräftelse av valet av initiatorn, eftersom annars svararen inte kommer att kunna dekryptera initiatorn data), NIDP, identifierarna för svaranden och initiatorn. Svararen måste dekryptera identifieraren och nonce-informationen med hjälp av den privata nyckeln för R'ID. Den privata R ID-nyckeln kommer sedan att användas för att dekryptera nonce-fältet. Svararen krypterar sedan tillståndsinformationen med den publika nyckeln ID(I), genererar ett prf-värde och skickar ett meddelande till initiatorn.
  3. Initiatorn bekräftar CKY-I som en giltig association för nätverksadressen för det inkommande meddelandet, lägger till CKY-R-värdet till parets tillstånd (CKY-I, nätverksadress) och associerar all tillståndsinformation med paret (CKY) -Jag, CKY-R). Dekrypterar id och icke-information Nr, kontrollerar prf-beräkning, sparar g^y och EHAS i tillstånd. Kan beräkna (g^y)^x (= g^xy) (detta kan fördröjas tills svarsmeddelandet skickas). Markerar KEYID (CKY-I|CKY-R) som autentiserat, komponerar sedan ett svarsmeddelande, krypterar det med den publika nyckeln och skickar det till svararen.
  4. Svararen tar emot detta meddelande, den markerar nyckeln som i autentiserat tillstånd. Om den inte redan har gjort det måste den beräkna g^xy och associera den med KEYID.

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

Samtidigt, trots frånvaron av PFS för att skydda identifierare, finns PFS för det mottagna nyckelmaterialet, eftersom partiella Diffie-Hellman-nycklar g^x och g^y utbyts.

Med dolda identifierare utan Diffie-Hellman

Betydande beräkningskostnader kan undvikas om full framsedd hemlighet inte är ett krav för att erhålla en sessionsnyckel. Båda parter kan utbyta nonces och delar av den hemliga nyckeln för autentisering och erhållande av nyckelmaterial. Den långsiktiga sekretessen för data som skyddas med härlett nyckelmaterial beror på varje parts privata nycklar.

I utbytet nedan sätts GRP till 0 och gruppexponentfältet används istället för att lagra nonce-värdet. Den första föreslagna algoritmen skulle vara ett krypteringssystem för publik nyckel; genom att svara med en cookie och ett exponentiellt fält som inte är noll, accepterar svararen implicit den första meningen och avsaknaden av fullständig sekretess för identifierare och härlett nyckelmaterial.

Initiativtagare svarande
-> 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)

KEYID = CKY-I|CKY-R

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

Standardläge

Standardläget kännetecknas av mindre information som överförs i varje meddelande.

Här är ett exempel där parterna använder ett cookieutbyte för att skjuta upp skapandet av tillstånd, använda fullständig sekretess för att skydda identiteten och använda kryptering av offentlig nyckel för autentisering. Digitala signaturer och fördelade nycklar kan dock också användas som en autentiseringsmetod.

Svararen betraktar initiatorns förmåga att upprepa CKY-R som ett svagt bevis för att meddelandet härrörde från en "live"-svarare på nätverket och att svararen är associerad med initiatorns nätverksadress. Initiativtagaren gör liknande antaganden när CKY-I upprepas till initiatorn.

Alla meddelanden måste ha antingen giltiga cookies eller minst en noll-cookie. Om båda cookies är null indikerar detta en cookie-begäran; om bara initiatorns cookie är null, är det ett svar på en cookie-förfrågan.

Alla ospecificerade fält har nullvärden:

Initiativtagare svarande
-> 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)

Utbytesschema i standardläge:

  1. Utbyte av cookies. Initiativtagaren KAN skicka sin egen cookie på den första begäran, men svararen KAN välja att inte lagra denna cookie genom att utelämna CKY-I i sitt svar, detta beteende är möjligt och anses vara acceptabelt.
  2. Efter att cookie-utbytet har slutförts, beräknar parterna det publika nyckelmaterialet sKEYID. (Prf-funktionen som används för att beräkna nyckeln är en pseudo-slumpmässig funktion i klassen "hash" från EHAS.

Liksom med cookies, betraktar varje sida fjärrsidans förmåga att replikera värdet Ni eller Nr som ett bevis på att Ka, sida A:s publika nyckel, talar på den fjärranslutna sidans vägnar och fastställer dess identitet.

Observera att även om IDP-flaggan säkerställer att identiteterna skyddas av den delade nyckeln g^xy, är själva autentiseringen oberoende av g^xy. Det är viktigt att autentiseringsstegen kontrollerar g^x- och g^y-värdena, och därför är det viktigt att autentiseringen inte innebär ett cirkulärt beroende av dem. En tredje part kan ingripa på ett man-i-mitten-sätt för att övertyga initiativtagaren och den som svarar att använda olika värden av g^xy; även om en sådan attack kan avslöja identitet för en interceptor, skulle autentisering misslyckas.

Nonserna Ni och Nr används för att tillhandahålla en ytterligare säkerhetsåtgärd vid härledning av sessionsnycklar. Detta gör nyckelhemligheten beroende av två olika problem: det diskreta logaritmproblemet i grupp G och problemet med att bryta nonce-krypteringsschemat. Om RSA-kryptering används, är detta andra problem ungefär lika med faktorisering av de offentliga RSA-nycklarna för både initiatorn och svaranden.

Snabbläge

När ett autentiserat KEYID och tillhörande sKEYID-nyckelmaterial redan finns, är det lätt att få ytterligare KEYID och nycklar med liknande attribut (GRP, EHAS, etc.) med enbart hashfunktioner.

Alternativt kan den autentiserade nyckeln vara en manuellt distribuerad nyckel som delas mellan initiatorn och den som svarar på något sätt utanför Oakley. Om en distributionsmetod genererade ett KEYID med motsvarande unika värden för de två halvorna (CKY-I och CKY-R), är den metoden tillämplig.

Följande använder Oakley Quick Mode som nyckelutbytesidentifierare. Nonces skickas i autentiseringsnyttolasten, och prf-värdet skickas i autentiseringsnyttolasten; Autentiseringsmyndigheten är "Ingen" och typen är "Pre-Shared".

Protokoll:

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

NKEYID = Ni | Nej.

sNKEYID = prf(sKEYID, Ni | Nr)

Inloggningsuppgifterna och EHA-värdena som är associerade med ett NKEYID är desamma som för ett KEYID. Varje part måste verifiera hash-värdena innan du använder den nya nyckeln för något syfte.

Kompatibilitet med ISAKMP

Alla fält i OAKLEY-meddelandet motsvarar ISAKMP-meddelandens nyttolast eller nyttolastkomponenter.

CKY-I - ISAKMP header

CKY-R - ISAKMP rubrik

MSGTYPE - Meddelandetyp i ISAKMP-huvudet

GRP - SA last, Erbjudande avsnitt

g^x - nyckelutbytesnyttolasten kodad som ett heltal med variabel precision

g^y - nyckelutbytesnyttolasten kodad som ett heltal med variabel precision

EHAO - SA nyttolast, meningen avsnitt

EHAS-SA

IDP är lite i det reserverade fältet för AUTH-huvudet

ID(I) - AUTH-belastning, identifieringsfält

ID(R) - AUTH-belastning, identifieringsfält

Ni - AUTH nyttolast, nonce-fält

Nr - AUTH nyttolast, nonce-fält

S{...}Kx - AUTH-belastning, datafält

prf{K,...} - AUTH nyttolast, datafält

Externa länkar

  • RFC 2412 OAKLEY Key Deermination Protocol