IKEv1 versus IKEv2 met vooraf gedeelde sleutel: wat authenticatie anders maakt

Twee gateways met dezelfde vooraf gedeelde sleutel ronden een handshake af, en een packet capture laat geen geheim over de lijn gaan. Dat is het deel dat mensen onthouden. Het interessante deel is wat elke versie werkelijk berekent om te bewijzen dat het geheim bekend is, want IKEv1 en IKEv2 bouwen dat bewijs uit verschillende invoer en tonen daarbij verschillende informatie. Lees de twee traces naast elkaar en het verschil houdt op cosmetisch te zijn.

Wat het bewijs moet bereiken

Diffie-Hellman geeft beide peers een gedeelde waarde waarvan iedereen die meekijkt ook de publieke helften kan berekenen. Op zichzelf bewijst dat niets over identiteit: een aanvaller die een sleuteluitwisseling afrondt, heeft dezelfde gedeelde waarde als jouw gateway. De authenticatiestap bestaat om die uitwisseling te binden aan een geheim dat alleen de bedoelde peers bezitten, en aan de identiteiten en parameters waarover zij het eens werden.

Die binding is de reden dat de hash meer dan de sleutel dekt. Als hij alleen het geheim dekte, kon een aanvaller hem in een andere uitwisseling met andere identiteiten of voorstellen herspelen.

IKEv1 Main Mode: SKEYID afleiden en dan bewijzen

Main Mode doorloopt zes berichten. Het eerste paar onderhandelt de security association, het tweede wisselt publieke Diffie-Hellman-waarden en nonces uit, en het derde draagt identiteiten plus authenticatiehashes onder de zojuist opgezette versleuteling. RFC 2409 definieert de constructie: bij authenticatie met vooraf gedeelde sleutel wordt SKEYID afgeleid uit het geheim en beide nonces, en het latere sleutelmateriaal uit SKEYID, de Diffie-Hellman-waarde, de cookies en constanten.

De hash in bericht vijf en zes wordt berekend over de Diffie-Hellman-waarde, de twee cookies, het voorstel en de identiteit van de afzender, met SKEYID als sleutel. De ontvanger herberekent hem met zijn eigen geconfigureerde geheim. Een verschil beeindigt de uitwisseling, en op geen enkel moment is het geheim zelf een payload.

Aggressive Mode perst hetzelfde werk in drie berichten, wat betekent dat identiteiten en de authenticatiehash reizen voordat er een versleuteld kanaal bestaat. Dat is een echte blootstelling bij een raadbaar geheim, en het staat los van de vraag of het geheim is verzonden. IKEv1 is afgekeurd door RFC 9395, dus een oude trace is een diagnostische oefening en geen implementatiedoel.

IKEv2: een andere afleiding en een andere AUTH-payload

IKEv2 hergebruikt het sleutelschema van IKEv1 niet. De eerste IKE-sleutels komen uit een seed die uit de nonces en de Diffie-Hellman-waarde is opgebouwd, en de child security associations komen daaruit voort. De vooraf gedeelde sleutel voedt de seed helemaal niet.

Authenticatie verschijnt dan als een AUTH-payload. Voor authenticatie met gedeelde sleutel schrijft RFC 7296 een opgevulde vorm van het geheim voor, verkregen door het geheim te hashen met de vaste string Key Pad for IKEv2, en daarna de ondertekende uitwisselingsgegevens en de identiteit te hashen met die opgevulde sleutel. De verifier kan dezelfde waarde opnieuw opbouwen; een waarnemer niet, zonder het geheim.

Let op wat er veranderd is. In IKEv1 zit het geheim in het sleutelschema gebakken voordat de authenticatiehash bestaat; in IKEv2 is het sleutelschema onafhankelijk van het geheim en is het bewijs een aparte payload die aan de ondertekende octetten hangt. Dezelfde conceptuele garantie, andere machinerie, en daarom mappen parameternamen en captures niet een op een.

Wat een waarnemer werkelijk leert

Diffie-Hellman-waarden, voorstellen, nonces en cookies zijn in beide versies zichtbaar. Identiteiten zijn zichtbaar in IKEv1 Aggressive Mode en beschermd in de andere gevallen. Het geheim is nooit zichtbaar.

Die laatste zin heeft een grens die het vermelden waard is. Een zwak, door een mens gekozen geheim is aan te vallen door te raden: de aanvaller berekent wat de authenticatiewaarde voor een kandidaat-geheim zou zijn en vergelijkt. IKEv1 Aggressive Mode maakt dat het goedkoopst omdat het bewijs in de open lucht staat, en de standaarden waarschuwen in het algemeen voor geheimen met lage entropie. Het geheim nooit versturen is niet hetzelfde als een slecht geheim veilig maken.

Wat je met de vergelijking doet

Gebruik een uniek geheim per peerpaar, genereer het uit een willekeurige bron en roteer het via hetzelfde provisioningpad dat het heeft verspreid. Als het geheim in een configuratiesjabloon staat dat naar elke vestiging gaat, is een compromis op een locatie een compromis overal.

Geef de voorkeur aan certificaatgebaseerde authenticatie waar de operationele kosten aanvaardbaar zijn, want die haalt het raadprobleem van het gedeelde geheim weg en geeft elke peer een eigen identiteit. Waar een vooraf gedeelde sleutel blijft, houd hem lang, beperk zijn bereik en zie de IKE-versie als een beveiligingsbeslissing, niet als een interoperabiliteitsdetail.