Difference: IPSec:IKE(v1),Vaiheet(2-A) (r6 vs. r5)

IKE (eli IKE v1) koostuu kahdesta vaiheesta (phase). Vaihe 1 muodostaa IKE SA:n (Security Association). Sen turvin tehdään vaihe 2, joka vasta muodostaa IPSec SA:n eli sen, jota AH tai ESP käyttävät. Toisin kuin IPSec SA, IKE SA on kaksisuuntainen, eli samoja parametreja käytetään sekä lähteviin että tuleviin IKE-paketteihin. SA:t ovat yksisuuntaisia, joten osapuolten välillä pitää olla molempiin suuntiin yksisuuntainen SA. SA on "määritelmä" kahden verkkolaitteen välisen liikenteen suojauksen parametreille. Se on perusta kaikelle suojatulle liikenteelle IPSec:ssä.

Vaihe 1 on mahdollista tehdä kahdella eri tavalla: Main mode ja Aggressive mode. Näiden taustalla on ISAKMP-vaihdot, joiden nimet selittävät eron: Identity Protection Exchange (IKE:ssä siis Main mode) ja Aggressive Exchange. Ensimmäinen vaihtotapa käyttää kuusi viestiä ja aggressiivinen selviää (kutakuinkin) samasta tehtävästä kolmella, mutta ei salaa osapuolten identiteettiä. (Mainittu ISAKMP, Internet Security Association and Key Management Protocol, määrittelee melko yleiset puitteet protokollille, joilla SA voidaan luoda ja avaintenvaihto toteuttaa -- myös muutoin kuin IPSecin yhteydessä, RFC 2408.)

Vaihe 2 tapahtuu aina Main mode ja Aggressive vain yhdellä tavalla, joka on saanut nimen Quick mode. Nimi juontuu siitä, että saman IKE SA:n turvissa Näiden taustalla on ISAKMP-vaihdot, joiden nimet selittävät eron: Identity Protection Exchange (IKE:ssä siis Main mode) ja Aggressive Exchange. Ensimmäinen vaihtotapa käyttää kuusi viestiä ja aggressiivinen selviää (kutakuinkin) samasta tehtävästä kolmella, mutta ei salaa osapuolten identiteettiä. (Mainittu ISAKMP, Internet Security Association and Key Management Protocol, määrittelee melko yleiset puitteet protokollille, joilla SA voidaan neuvotella useita IPSec SA:ita, eli päästään liikkeelle luoda ja avaintenvaihto toteuttaa -- myös muutoin nopeammin kuin jos vaiheen 1 askeleet IPSecin yhteydessä, RFC 2408.) pitäisi toistaa.

I
<-----IKE-SA---->
R

IKE (eli IKE v1) koostuu kahdesta vaiheesta (phase). Vaihe 1 muodostaa IKE SA:n (Security Association)(yllä oleva kuva). Sen turvin tehdään vaihe 2, joka vasta muodostaa IPSec SA:n eli sen, jota AH tai ESP käyttävät. Toisin kuin IPSec SA, IKE SA on kaksisuuntainen, eli samoja parametreja käytetään sekä lähteviin että tuleviin IKE-paketteihin. SA on "määritelmä" kahden verkkolaitteen välisen liikenteen suojauksen parametreille. Se on perusta kaikelle suojatulle liikenteelle IPSec:ssä.

Vaihe 1 on mahdollista tehdä kahdella eri tavalla:

Main mode ja Aggressive mode. Näiden taustalla on ISAKMP-vaihdot, joiden nimet selittävät eron: Identity Protection Exchange (IKE:ssä siis Main mode) ja Aggressive Exchange. Ensimmäinen vaihtotapa käyttää kuusi viestiä ja aggressiivinen selviää (kutakuinkin) samasta tehtävästä kolmella, mutta ei salaa osapuolten identiteettiä. (Mainittu ISAKMP, Internet Security Association and Key Management Protocol, määrittelee melko yleiset puitteet protokollille, joilla SA voidaan luoda ja avaintenvaihto toteuttaa -- myös muutoin kuin IPSecin yhteydessä, RFC 2408.)

I <--------SA SA---------> <--------SA SA---------> R

Vaihe 2 tapahtuu aina vain yhdellä tavalla, joka on saanut nimen Quick mode. Nimi juontuu siitä, että saman IKE SA:n turvissa voidaan neuvotella useita IPSec SA:ita (yllä oleva kuva), eli päästään liikkeelle nopeammin kuin jos vaiheen 1 askeleet pitäisi toistaa.

Sekä vaiheessa 1 että (valinnaisesti) vaiheessa 2 tehdään Diffie-Hellman-vaihto. Siihen on tarjolla viisi ennalta sovittua ryhmää, ja niitä voi määritellä lisää. Ryhmällä tarkoitetaan rakennetta, jonka puitteissa DH-vaihto tehdään. Tuttu rakenne on eksponenttilasku modulo p. Siinä ryhmänä on lukujoukko 1,...,p-1, jolla on jokin julkinen primitiivialkio g, jota osapuolet korottavat salassa pitämiinsä potensseihin. Näitä ryhmiä eli (p,g)-pareja on valmiina kolme. Niissä p:n pituus on 768, 1024 ja 1680 bittiä. Kaksi muuta ryhmää ovat vain noin 2^155- ja 2^185-alkioiset, mutta niissä ryhmäoperaatio onkin elliptisten käyrien mukainen.

Vaihe 1

Vaihe 1 koostuu kolmesta askelesta

  • parametrien neuvottelu
  • avaimen vaihto
  • tunnistus ja autentikointi

Main-moodi käyttää kuhunkin kaksi viestiä, mutta aggressiivinen moodi limittää askeleet. Seuraavassa on abstrakti luonnehdinta kummastakin, osapuolina Initiator (yhteyden aloittaja I) ja Responder (R) (modulaarista DH:ta käyttäen, mutta jättäen 'mod p' merkitsemättä ).

Main-moodi

1. I --> R : krypto, jota voin käyttää

2. R --> I : krypto, jonka valitsen (erityisesti p ja g)

3. I --> R : g x (mod p)

4. R --> I : g y (mod p)

5. I --> R : {"I", todiste että olen I}g xy

6. R --> I : {"R", todiste että olen R}g xy

Aggressive-moodi

I --> R : gx, "I", kryptoehdotus

R --> I : gy, kryptovalinta, todiste että olen R

I --> R : todiste että olen I

Jokaisen viestin alussa on otsikkokenttä. Ensimmäisessä viestissä I sijoittaa siihen keksimänsä Cookie-arvon Ci, ja toistaa sen kaikissa myöhemmissä viesteissään, samoinkuin "piparin" Cr, jonka R puolestaan keksii ja sijoittaa ensimmäiseen omaan viestiinsä. Kummankin osapuolen viesteissä on siis toisesta alkaen otsikossa Ci ja Cr, joilla osapuolet indeksoivat IKE-vaihtonsa. Näitä käytetään myös avainten muodostamisessa kuten kohta nähdään.

Kumpikin moodi voidaan suorittaa Ensimmäisessä viestissä I sijoittaa siihen keksimänsä Cookie-arvon Ci, ja toistaa sen kaikissa myöhemmissä viesteissään, samoinkuin Cr, jonka R puolestaan keksii ja sijoittaa ensimmäiseen omaan viestiinsä. Nämä Cookie-arvot ovat eri asia kuin evästeet. neljällä eri tavalla, sen mukaan millaista autentikointia käytetään.

Kummankin osapuolen viesteissä on siis toisesta alkaen otsikossa Ci ja Cr, joilla osapuolet indeksoivat IKE-vaihtonsa. Näitä käytetään myös avainten muodostamisessa kuten kohta nähdään. Kumpikin moodi voidaan suorittaa neljällä eri tavalla, sen mukaan millaista autentikointia käytetään.

Vaihe 2

Toisessa vaiheessa neuvotellaan kolmella viestillä IPSecin AH- tai ESP-protokollan tarvitsemat SA:t. Protokollan viestin salaus ja autentikointi hoidetaan IKE SA:sta peräisin olevilla avaimilla SKEYID_e ja SKEYID_a (, joista edellinen on juuri se, joka taulukossa on nimeltään k). Ne eroavat toisistaan vain hash-funktion laskussa käytetyn vakion verran. Salauksessa ketjutuksen aloittamiseen tarvittava alustusvektori otetaan vaiheen 2 viimeisestä kryptolohkosta, joten sekin täytyy pitää tallessa. Koska voi olla useita vaiheen 2 neuvotteluja saman IKE SA:n suojaamana, ne pitää erotella toisistaan ja sitä varten viestin otsikoissa on tunniste. Tätä tunnistetta käytetään myös alustusvektorin laskennassa, jotta sekin olisi erilainen eri neuvotteluissa. Jokaisen viestin alussa on tunnisteen lisäksi samat piparit Ci ja Cr kuin vaiheessa 1. Nämä kolme kulkevat salaamattomina. Viestin salatut osat ovat seuraavanlaiset.

I --> R --> I --> R

IPSecin AH- tai ESP-protokollan tarvitsemat SA:t. Protokollan viestin salaus ja autentikointi hoidetaan IKE SA:sta peräisin olevilla avaimilla SKEYID_e ja SKEYID_a (joista edellinen _e on juuri se, joka taulukossa on nimeltään k). Ne eroavat toisistaan vain hash-funktion laskussa käytetyn vakion verran. Salauksessa ketjutuksen aloittamiseen tarvittava alustusvektori otetaan vaiheen 2 viimeisestä kryptolohkosta, joten sekin täytyy pitää tallessa. Koska voi olla useita vaiheen 2 neuvotteluja saman IKE SA:n suojaamana, ne pitää erotella toisistaan ja sitä varten viestin otsikoissa on tunniste. Tätä tunnistetta käytetään myös alustusvektorin laskennassa, jotta sekin olisi erilainen eri neuvotteluissa. Jokaisen viestin alussa on tunnisteen lisäksi samat Cookiet Ci ja Cr kuin vaiheessa 1. Nämä kolme kulkevat salaamattomina. Viestin salatut osat ovat seuraavanlaiset.

I --> R : CP, Hi, SPIi, Ni, [gx], [liikennerajoituksia]

R --> I : CPA, Hr, SPIr, Nr, [gy], [liikennerajoituksia]

I --> R : H'i

Selityksiä:

  • CP on kryptoehdotus ja CPA on vastaus siihen.
  • Hi, Hr ja H'i ovat samantapaiset todisteet kuin vaiheessa 1: Ne lasketaan hash-funktiolla useista muista viestin parametreista. Erityisenä parametrina on avain SKEYID_a, joka osoittaa autenttisuuden. Laskussa ovat mukana myös valinnaiset tiedot.
  • SPIa = osapuolen a valitsema SPI, jota käytetään SA:ssa b:ltä a:lle.
  • Na = nonce-arvoja, jotka seuraavassa viestissä osoittavat tuoreutta.
  • gz= DH-"puolikas". DH-vaihtoa voidaan käyttää, jotta uusien SA:iden avaimet eivät riippuisi IKE SA:sta. Tuloksena on Perfect Forward Secrecy, PFS (eli "täydellinen jatkosalaisuus").
  • Liikennerajoituksia voidaan asettaa sille, minkälaiseen liikenteeseen syntyviä SA:ita saa käyttää. Nämä vastaavat sitä, mitä IPSEcin politiikkatietokannassa (SPD:ssä) kerrotaan. Siellä oleva "traffic selector" voi asettaa vaatimuksia IP-osoitteille, protokollalle (erityisesti UDP vai TCP) sekä porttinumeroille. Liikennerajoituskentällä voidaan nyt välittää toiselle osapuolelle oman politiikan sisältö. Tässä puheena olevat rajoitukset ovat siis vain lisä sille, että SPD:ssä kerrotaan, millaiselle liikenteelle pitää soveltaa IPSeciä.

IKE v2

IKEn versio 2 on esitetty RFC:ssä 4306 vuonna 2005. Keskeinen ero IKE:n versioon 1 verrattuna on tämä: Kahdella viestinvaihdolla (=4 viestillä) luodaan paitsi IKE_SA myös ensimmäinen turva-assosiaatio ESP:tä ja/tai AH:ta varten. Jälkimmäistä SA:ta kutsutaan nimellä CHILD_SA ja sellaisia voi myöhemmin luoda lisää, mikä vastaa versiossa 1 aina tarvittua vaihetta 2. Lisää eroja versioiden 1 ja 2 välillä on mainittu kohdassa Appendix A. Yksi tärkeä muutos on erilaisten autentikointitapojen toteuttaminen samoilla neljällä ensimmäisellä viestillä siten, että vain yhtä kenttää muutetaan. Näiden lisäksi on toteutettu parempaa suojaa esim. palvelunestohyökkäyksiä vastaan, jotka ovat nykypäivänä erittäin yleisiä. Alla kuvataan miten IKE:n versiossa 2 tapahtuu IKE SA:n ja CHILD_SA:n muodostus.

IKE_SA:n luominen:

1 ja 2 viesteissä lähetetään toisilleen IKE_SA-turvaparametrit, nonce.arvot ja Diffie-Helman-puolikkaat. HDR = otsikkokenttä, SA = turvaparametrit, KE = Diffie-Helman-puolikas, N = nonce-arvo, CERT ja CERTREQ = sertifikaatti ja sertifikaattipyyntö.

1. I --> R : HDR, SAi1, KEi, Ni

2. R --> I : HDR, SAr1, KEr, Nr, [CERTREQ]

Viesteissä 3 ja 4 tehdään AH:ta ja ESP:tä varten ensimmäinen CHILD_SA ja osoitetaan että ollaan myös se joka väitetään olevan. Tässä vaiheessa viestit salataan ja autentikoidutaan. SK = salaus symmetrisellä avaimella, AUTH = autentikointi tiivisteenä, ID = identiteetti, SA ja TS = IPSec:n turvaparametrit.

3. I --> R : HDR, SK{ IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}

4. R --> I : HDR, SK{ IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Uusien CHILD_SA:en luominen:

Luonti tapahtuu kahdella viestillä, pyyntö ja vastaus. CHILD_SA:n luomispyynnön voi lähettää kumpi vaan ja se on kuin IKEv1:sen vaihe 2. Tässä välitetään toiselle pyyntö tehdä SA ja luodaan turvaparametrit, välitetään nonce-arvot ja valintaisesti DH-puolikkaat jos halutaan lisätä turvallisuutta. Jos SA on jo olemassa ja halutaan vaihtaa sen avaimia voi kentällä N (notify) ilmoittaa asiasta.

1. I --> R : HDR, SK{ [N], SA, Ni, [KEi],[TSi, TSr]}

2. R --> I : HDR, SK{ SA, Nr, [KEr], [TSi, TSr]}

JFK

(Just Fast Keying) on toinen vaihtoehdoista IKE:n seuraajaksi. Sen suunnitteluun on ryhdytty hyvin erilaisista lähtökohdista kuin IKEv2:en suunnittelussa. Suunnittelussa tavoitteena on ollut tärkeää toteutuksen yksinkertaisuus ja tehokkuus. Lisää JFK:sta täällä?.

-- JukkaKoskinen

SivuTiedotLaajennettu edit
Vaativuus Jatko
Valmius Valmisteilla
Tyyppi Ydin
Luokitus Uhkat
Mitä Luottamuksellisuus
Miltä Ihmisetön uhka
Missä Organisaatio
Kuka Titu-ammattilainen
Milloin Ennakolta
Miksi Hyvä tapa

View topic | View difference side by side | History: r8 < r7 < r6 < r5 | More topic actions
 
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback