Headers (HDR) include “cookies” CKY-I and CKY-R respectively. Initiator’s SA has one or more “proposals”, inpreference order, for algorithms to be used for ISAKMP, the key management channel we’re building. Theresponder chooses exactly one of these proposals. These SAs may refer to one of a few standard Diffie-Hellman groups (both integer and ECC), or may define new DH groups.

HDR includes CKY-I. SA_i has exactly one “take-it-or-leave-it” proposal. The nonce Ni is encrypted in theresponder’s public key; KE (that’s g^x) and IDII are encrypted under Ke_i = prf( Ni, CKY-I ). So, the respondercan decrypt Ni and so derive Ke_i only if it has the private complement to Pubkey_r.

<--

HDR, SA_r, <Nr>Pubkey_i, <KE>Ke_r,

<IDir>Ke_r, HASH_R

HDR includes CKY-R. SA_r must equal SA_i. Similarly to the initiator’s message, the nonce Nr is encrypted inthe initiator’s public key, while KE (that’s g^y) and IDir are encrypted under KE_r = prf( Nr, CKY-R ), requiringthe initiator to have the private complement of Pubkey_i. HASH_R is as on the previous page.

HDR, HASH_I

-->

The hashes sent in each direction aren’t signed; but the ability to generate them proves receipt and successfuldecryption of the nonce received from the other party.

Key material for the underlying ISAKMP key-management SA we’re building first is derived from the shared-secretquantity g^xy and the nonces securely exchanged during Phase 1 as follows:

SKEYID = prf( Ni | Nr, g^xy )

SKEYID_d = prf( SKEYID, g^xy | CKY-I | CKY-R | “0” )

SKEYID_a = prf( SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | “1” )

SKEYID_e = prf( SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | “2” )

where _a refers to Authenticator (MAC) material for the ISAKMP channel, and _e is for Encrypting material for theISAKMP channel. _d is dual-purpose; firstly, it’s used as input for the _a and _e pseudo-random streams; secondly,it’s the main source of key material for the Phase 2 SAs which are the ones used by IPSec itself. SKEYID is useddirectly as the prf key for HASH_I and HASH_R, used to authenticate the parties.

Particular “transforms” (symmetric encryption algorithms, MACs, and so on) specify exactly how SKEYID_a,SKEYID_e, and SKEYID_d is to be used. For example, the specification for single-key DES uses at minimum thefirst 8 bytes of the PRF, forcing the parity bits to appropriate values, throwing away any bytes which would give riseto the known weak or semi-weak keys. (There are only 16 out of 2^56 such keys, so this isn’t likely to occur inpractice!) The Triple-DES definition uses at least 24 bytes of the prf output, and the prf definition “stretches” itsinitial result by repeated application to produce as many bytes as are needed.

Phase 2: “Quick Mode”

Now that we have an ISAKMP SA to define a secure key-management channel, doingalgorithm and key agreementfor client SAs such as AH and ESPis cheap and easy (relatively speaking). As example, this is how you get 4 SAs(one for each direction of an AH + ESP pair)-

see RFC2409 p.19:

HDR*{HASH(1), SA0, SA1, Ni}

-->

As before, HDR*{} means that all further material is encrypted (under SKEYID_e, remember?). SA0, SA1, etc. are“proposals” for client SAs for the AH and ESP transforms–

each one is a preference-ordered list of possible algorithmcombinations. Ni is a new initiator nonce. HASH(1) = prf( SKEYID_a, M-ID | SA0 | SA1 | Ni ); see how SKEYID_a isthe MAC key. M-ID is the unique message-ID from HDR.

<--

HDR*{HASH(2), SA0, SA1, Nr}

Back come single algorithm choices for each SA, and a new responder nonce Nr. HASH(2) is similar to HASH(1):HASH(2) = prf( SKEYID_a, M-ID | Ni | SA0 | SA1 | Nr ); it has Ni added as a liveness proof.

HDR*{HASH(3}

-->

This is a simple acknowledgement that the responder’s message has been received;

HASH(3) = prf(SKEYID_a, “0” | M-ID | Ni | Nr )

Now key material for each IPSec SA is defined as follows:

KEYMAT = prf( SKEYID_d, protocol | SPI | Ni | Nr )

Since protocol and SPI are unique to AH/ESP and direction respectively, this gives 4 separate chunks of KEYMAT. Ifnecessary, they are “stretched” as before by applying prf iteratively. Note the single Phase 1 DH exchange and public-key operations have been used to derive key material for all four IPSec SAs, spreading the cost of those expensiveoperations. There’s an option to include a fresh DH exchange in each Quick Mode if you prefer Forward Secrecy tocomputational efficiency...

Final notes on IPSec

•IKE is carried over UDP; hence unreliable (may needto be restarted) and blocked by some firewalls

•Managing IPSec policy and deployments isn’t easy,and getting it wrong can be embarassing in losingconnectivity, e.g. by making exchanges of routingupdates unreadable