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.

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 vain yhdellä tavalla, joka on saanut nimen Quick mode. Nimi juontuu siitä, että saman IKE SA:n turvissa voidaan neuvotella useita IPSec SA:ita, 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 ja Responder (modulaarista DH:ta käyttäen, mutta jättäen 'mod p' merkitsemättä ).

Main-moodi

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

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

I --> R : gx (mod p)

R --> I : gy (mod p)

I --> R : {"I", todiste että olen I}gxy

R --> I : {"R", todiste että olen R}gxy

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 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 : 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. 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.

-- 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
Print version |  PDF  | History: r8 | r6 < r5 < r4 < r3 | 
Topic revision: r5 - 19 Nov 2010 - 12:23:10 - TimoJarvenpaa?
 

TUTWiki

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