You are on page 1of 39

Sécurité des Réseaux, Master CSI 2

J.Bétréma, LaBRI, Université Bordeaux 1

IKE : Internet Key
Exchange
• RFC 2409 (novembre 1998)
• ISAKMP (Internet Security Association
and Key Management Protocol, RFC 2408)
• DoI (IPSec Domain of Interpretation
for ISAKMP, RFC 2407)

Architecture
There are two ways to design a system:
• One is to make it so simple there are obviously no deficiencies.
• The other is to make it so complex there are no obvious deficiencies.
C.A.R. Hoare

Miraculously, people were able to implement IKE, and even interoperate…
Kaufman, Perlman, Speciner
Network Security

RFC 2409, section 4. Introduction

IKE : phases
• Phase 1 is where the two ISAKMP peers establish a secure, authenticated
channel with which to communicate. This is called the ISAKMP Security
Association (SA).
• Phase 2 is where Security Associations are negotiated on behalf of services
such as IPsec or any other service which needs key material and/or
parameter negotiation.
• With the use of ISAKMP phases, an implementation can accomplish very
fast keying when necessary. A single phase 1 negotiation may be used for
more than one phase 2 negotiation. Additionally a single phase 2 negotiation
can request multiple Security Associations. With these optimizations, an
implementation can see less than one round trip per SA as well as less than
one DH exponentiation per SA.

3 messages). • La phase 2 se déroule en « mode rapide » (quick mode). 6 messages) ou en « mode agressif » (aggressive mode. .IKE : modes • La phase 1 peut se dérouler en « mode principal » (main mode.

nonces) necessary for the exchange. . Exchanges Phase 1. section 5. The XCHG for Main Mode is ISAKMP Identity Protect. The authentication method negotiated as part of the initial ISAKMP exchange influences the composition of the payloads but not their purpose.RFC 2409. • the next two exchange Diffie-Hellman public values and ancillary data (e. main mode Main Mode is an instantiation of the ISAKMP Identity Protect Exchange: • The first two messages negotiate policy. • and the last two messages authenticate the Diffie-Hellman Exchange.g.

SA RFC 2409.Négociation Initiator ----------HDR.2 de la RFC 2408.4 : n’est-ce pas clair ? • HDR (header) désigne l’en-tête d’un message ISAKMP • SA désigne une « charge utile » (payload) de type Security Association. • Ces messages contiennent chacun une liste de protocoles cryptographiques. pour en savoir plus.1 à 5. . proposés par Alice (initiator) ou acceptés par Bob (responder). dans un jargon obscur : voir section 4. sections 5. • Codage complexe. SA Responder ------------> <-- HDR. il faut consulter la RFC 2408 (ISAKMP).

All of these attributes are mandatory and MUST be negotiated.RFC 2409. . Introduction Négociation (2) The following attributes are used by IKE and are negotiated as part of the ISAKMP Security Association. section 4. • encryption algorithm • hash algorithm • authentication method • information about a group over which to do Diffie-Hellman.

Introduction Négociation (3) IKE implementations MUST support the following attribute values: • DES in CBC mode with a weak. The key is derived according to Appendix B. . • MD5 and SHA. section 4. and semi-weak. • MODP over default group number one. • Authentication via pre-shared keys. key check (weak and semi-weak keys are listed in Appendix A).RFC 2409.

section 4. . IKE implementations MAY support any additional encryption algorithms defined in Appendix A and MAY support ECP and EC2N groups. Introduction Négociation (4) In addition. • Tiger for hash. • the Digital Signature Standard. RSA signatures and authentication with RSA public key encryption.RFC 2409. • and MODP group number 2. IKE implementations SHOULD support: • 3DES for encryption.

Inc. • The fixed header contains the information required by the protocol to maintain state. Maughan National Security Agency M. followed by a variable number of payloads. • The presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type Field located in the ISAKMP Header . M. process payloads and possibly prevent denial of service or replay attacks. Turner RABA Technologies. Inc. Schertler Securify. November 1998 • An ISAKMP message has a fixed header format. Schneider National Security Agency J.Message ISAKMP Network Working Group Request for Comments: 2408 Category: Standards Track Internet Security Association and Key Management Protocol (ISAKMP) D.

En-tête (header) ISAKMP 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Initiator ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Responder ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ISAKMP Header Format .

temps de calcul) avant réception du message suivant de la part du client (supposé). the UDP Source and Destination Ports and a locally generated secret random value.Cookies • Anti-Clogging Token (to clog = obstruer. codé selon les règles ISAKMP. car il faut mémoriser les termes de la négociation. • Pour que le serveur ne consomme aucune ressource prématurément. il doit pouvoir vérifier le « responder cookie » en mode « stateless »: Karn's suggested method for creating the cookie is to perform a fast hash (e. • Impossible ici.g. inclus dans les deux premiers messages… . encrasser) : pour gêner les attaques DoS (déni de service). le serveur ne doit pas consommer de ressource (mémoire. • La requête initiale peut être falsifiée (IP spoofing). MD5) over the IP Source and Destination Address.

Nr RFC 2409.42 [ANSI]. KE. and the RSA-based key exchange used by PGP. section 5. Diffie-Hellman. KE. clef secrète partagée. pour en savoir plus. • RFC 2408 : The Key Exchange Payload supports a variety of key exchange techniques. • KE désigne une « charge utile » (payload) de type Key Exchange. messages 3 et 4. Example key exchanges are Oakley. the enhanced Diffie-Hellman key exchange described in X9.Diffie-Hellman Initiator ---------HDR. Ni Responder ------------> <-- HDR. il faut consulter la RFC 2408 (ISAKMP).4. . • N désigne une « charge utile » (payload) de type Nonce.

section 6.are defined below. . These groups were all generated by Richard Schroeppel at the University of Arizona.RFC 2409. the group in which to do the Diffie-Hellman exchange is negotiated. These groups originated with the Oakley protocol and are therefore called "Oakley Groups".values 1 through 4 -. Four groups -. Oakley groups Diffie-Hellman (2) With IKE.

1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is FFFFFFFF 29024E08 EF9519B3 E485B576 FFFFFFFF 8A67CC74 CD3A431B 625E7EC6 The generator is: 2. This group is assigned id 1 (one).Oakley groups First Oakley Default Group Oakley implementations MUST support a MODP group with the following prime and generator.2 ^704 . The prime is: 2^768 . C90FDAA2 020BBEA6 302B0A6D F44C42E9 2168C234 3B139B22 F25F1437 A63A3620 C4C6628B 514A0879 4FE1356D FFFFFFFF 80DC1CD1 8E3404DD 6D51C245 FFFFFFFF .

This group is assigned id 2 (two).Oakley groups (2) Second Oakley Default Group IKE implementations SHOULD support a MODP group with the following prime and generator. Its hexadecimal value is FFFFFFFF 29024E08 EF9519B3 E485B576 EE386BFB FFFFFFFF FFFFFFFF 8A67CC74 CD3A431B 625E7EC6 5A899FA5 FFFFFFFF C90FDAA2 020BBEA6 302B0A6D F44C42E9 AE9F2411 The generator is 2 (decimal) 2168C234 3B139B22 F25F1437 A637ED6B 7C4B1FE6 C4C6628B 514A0879 4FE1356D 0BFF5CB6 49286651 80DC1CD1 8E3404DD 6D51C245 F406B7ED ECE65381 .2^960 .1 + 2^64 * { [2^894 pi] + 129093 }. The prime is 2^1024 .

Oakley groups (3) Third Oakley Group IKE implementations SHOULD support a EC2N group with the following characteristics. The curve is based on the Galois Field GF[2^155]. The irreducible polynomial for the field is: u^155 + u^62 + 1. Field Size: 155 Group Prime/Irreducible Polynomial: 0x0800000000000000000000004000000000000001 Group Generator One: 0x7b Group Curve A: 0x0 Group Curve B: 0x07338f Group Order: 0X0800000000000000000057db5698537193aef944 . The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. This group is assigned id 3 (three). The field size is 155.

The curve is based on the Galois Field GF[2^185].Oakley groups (4) Third Oakley Group The data in the KE payload when using this group is the value x from the solution (x. P is the curve point with x coordinate equal to generator 1 and the y coordinate determined from the defining equation.y). Fourth Oakley Group This group is assigned id 4 (four). where * is the repetition of the group addition and double operations. The irreducible polynomial for the field is: u^185 + u^69 + 1 etc. The field size is 185. the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P. Group Group Group Group Generator One: 0x18 Curve A: 0x0 Curve B: 0x1ee9 Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc .

However. not by ISAKMP. or as a separate payload.Nonces Nonce Payload (RFC 2408) The Nonce Payload contains random data used to guarantee liveness (sic) during an exchange and protect against replay attacks. this is defined by the key exchange. . The nonces may be transmitted as part of the key exchange data.

HASH_I --> <-- Responder ----------HDR*. IDir. x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation. or "ui" or "ur" for the user initiator and responder respectively during phase two. section 3.2. section 5. The contents of the hash are specific to the authentication method. . IDii. clef secrète partagée.4. Notation Initiator ---------HDR*. pour protéger l’identité des partenaires. • IDx is the identification payload for "x". • Ces messages sont chiffrés (notation HDR*) avec SKEYID_e (voir plus loin). messages 5 et 6. HASH_R RFC 2409. • HASH (and any derivative such as HASH_I) is the hash payload.Authentification par clé partagée RFC 2409.

IDii. KE.RFC 2409. SA HDR. section 5. Exchanges ‘b’ = (payload) body ! Authentification par clé partagée (2) • HASH_I = prf (SKEYID. SA HDR. Nr HDR*. Ni HDR*. g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) • SKEYID = prf (pre-shared-key. g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) • HASH_R = prf (SKEYID. Ni_b | Nr_b) Initiator ---------HDR. HASH_R . HASH_I Responder ------------> <---> <---> <-- HDR. IDir. KE.

SKEYID_a | g^xy | CKY-I | CKY-R | 2) . • SKEYID_a is the keying material used by the ISAKMP SA to authenticate its messages. • SKEYID_d = prf (SKEYID. SKEYID_d | g^xy | CKY-I | CKY-R | 1) • SKEYID_e = prf (SKEYID.RFC 2409. • SKEYID_e is the keying material used by the ISAKMP SA to protect the confidentiality of its messages. • SKEYID_d is the keying material used to derive keys for nonISAKMP security associations. Exchanges Authentification par clé partagée (3) • SKEYID is a string derived from secret material known only to the active players in the exchange. g^xy | CKY-I | CKY-R | 0) • SKEYID_a = prf (SKEYID. section 3. Notation RFC 2409.2. section 5.

• La clé est complétée (padding) par des 0. égaux chacun à 0x36 • const2 est une suite de 64 octets. the HMAC version of the negotiated hash algorithm is used as a pseudo-random function. elle est d’abord condensée (digest) • const1 est une suite de 64 octets. • Si la clé dépasse 512 bits. égaux chacun à 0x5c .HMAC If a "prf" is not negotiated. pour atteindre 512 bits.

clef secrète partagée.4. KE. "Aggressive Mode" can be used to reduce round trips. aggressive mode RFC 2409. SA. IDii --> <-HDR. SA. section 5. HASH_R Section 4. . IDir. Nr. Initiator ----------HDR. HASH_I --> Responder ----------HDR.Phase 1. Ni. KE. Introduction : when identity protection is not needed.

Exchanges Méthodes d’authentification Four different authentication methods are allowed with either Main Mode or Aggressive Mode : • digital signature. • pre-shared key. • two forms of authentication with public key encryption.RFC 2409. section 5. . The value SKEYID is computed seperately for each authentication method.

IDii. IDir. section 5. KE. SA HDR. [ CERT. [ CERT. SA --> <-HDR.1 Authentification par signature Initiator ----------HDR. g^xy) . ] SIG_I --> <-- Responder ----------HDR. Nr HDR*. ] SIG_R Seuls les messages 5 et 6 changent. et : SKEYID = prf (Ni_b | Nr_b. Ni --> <-HDR*. KE.RFC 2409.

g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) • HASH_R = prf (SKEYID. g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) . • In general the signature will be over HASH_I and HASH_R as above using the negotiated prf.g. • However. section 5.RFC 2409.1 Authentification par signature (2) • The signed data. SIG_I or SIG_R. • HASH_I = prf (SKEYID. DSS is only defined with SHA's 160 bit output). this can be overridden for construction of the signature if the signature algorithm is tied to a particular hash algorithm (e. is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. or the HMAC version of the negotiated hash function (if no prf is negotiated). Rappel • One or more certificate payloads MAY be optionally passed.

IDii HDR. ] SIG_R . [ CERT. IDir.Authentification par signature (3) Mode agressif : Initiator ----------HDR. Nr. KE. SA. Ni. SA. ] SIG_I Responder ------------> <---> HDR. [ CERT. KE.

[<Cert-I_b>Ke_i] HDR*. HASH_I Responder ------------> <-- HDR. <KE_b>Ke_r. <Nr_b>PubKey_i. ] <Ni_b>Pubkey_r. et : SKEYID = prf (hash (Ni_b | Nr_b).RFC 2409. SA HDR. <IDir_b>Ke_r. HDR*. <KE_b>Ke_i.3 méthode révisée Authentification par chiffrement asymétrique Initiator ----------HDR. <IDii_b>Ke_i. [ HASH(1). HASH_R Seuls les messages 3 et 4 sont nouveaux. SA --> <---> <-- HDR. section 5. CKY-I | CKY-R) .

. section 5.2 Authentification par chiffrement asymétrique (2) • Using encryption for authentication provides for a plausably deniable exchange. There is no proof (as with a digital signature) that the conversation ever took place since each party can completely reconstruct both sides of the exchange. • In addition. • This exchange was motivated by [SKEME]. security is added to secret generation since an attacker would have to successfully break not only the Diffie-Hellman exchange but also both RSA encryptions.RFC 2409.

• This solution adds minimal complexity and state yet saves two costly public key operations on each side.RFC 2409. • A HASH payload may be sent to identify a certificate if the responder has multiple certificates which contain useable public keys (e. section 5. This provides additional protection against cryptanalysis of the Diffie-Hellman exchange. however the peer's identity (and the certificate if it is sent) is encrypted using the negotiated symmetric encryption algorithm (from the SA payload) with a key derived from the nonce. In addition. the Key Exchange payload is also encrypted using the same derived key. .3 Authentification par chiffrement asymétrique (3) • In this mode. the nonce is still encrypted using the public key of the peer. either due to certificate restrictions or algorithmic restrictions).g. if the certificate is not for signatures only.

3 The symmetric cipher keys are derived from the decrypted nonces as follows. . section 5. CKY-I) Ne_r = prf (Nr_b.Authentification par chiffrement asymétrique (4) RFC 2409. CKY-R) • The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively in the manner described in Appendix B used to derive symmetric keys for use with the negotiated encryption algorithm. • First the values Ne_i and Ne_r are computed: Ne_i = prf (Ni_b.

<IDii_b>Ke_i [. <KE_b>Ke_r. SA. [ HASH(1). HASH_I <---> Responder ----------- HDR. <KE_b>Ke_i.] <Ni_b>Pubkey_r. <Nr_b>PubKey_i.Authentification par chiffrement asymétrique (5) Mode agressif : Initiator ----------HDR. SA. <Cert-I_b>Ke_i ] --> HDR. HASH_R . <IDir_b>Ke_r.

• The information exchanged along with Quick Mode MUST be protected by the ISAKMP SA -.i. . a HASH payload MUST immediately follow the ISAKMP header and a SA payload MUST immediately follow the HASH. • In Quick Mode.e. This HASH authenticates the message and also provides liveliness proofs. all payloads except the ISAKMP header are encrypted.Phase 2 (Quick Mode) • Quick Mode is not a complete exchange itself (in that it is bound to a phase 1 exchange). but is used as part of the SA negotiation process (phase 2) to derive keying material and negotiate shared policy for non-ISAKMP SAs.

• Base Quick Mode (without the KE payload) refreshes the keying material derived from the exponentiation in phase 1. . Using the optional KE payload. an additional exponentiation is performed and PFS is provided for the keying material. • An optional Key Exchange payload can be exchanged to allow for an additional Diffie-Hellman exchange and exponentiation per Quick Mode. • The nonces are used to generate fresh key material and prevent replay attacks from generating bogus security associations. This does not provide PFS.Quick Mode (2) • Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection.

IDci. Nr [. KE ] [. HASH(3) --> Responder ----------HDR*. IDci.Quick Mode (3) Initiator ----------HDR*. IDcr ] --> <-HDR*. HASH(1). IDcr] . Ni [. KE ] [. SA. HASH(2). SA.

M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ) HASH(2) = prf (SKEYID_a. • HASH(3) -. In other words.minus the payload header. 0 | M-ID | Ni_b | Nr_b) .the initiator's followed by the responder's -.is the prf over the value zero represented as a single octet. followed by a concatenation of the message id and the two nonces -.Quick Mode (4) • HASH(1) is the prf over the message id (M-ID) from the ISAKMP header. concatenated with the entire message that follows the hash including all payload headers. The addition of the nonce to HASH(2) is for a liveliness proof.for liveliness -. M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ) HASH(3) = prf (SKEYID_a.Ni. • HASH(2) is identical to HASH(1) except the initiator's nonce -. minus the payload header -.is added after M-ID but before the complete message. the hashes for the above exchange are: HASH(1) = prf (SKEYID_a. but excluding any padding added for encryption.

g(qm)^xy | protocol | SPI | Ni_b | Nr_b) • where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman exchange of this Quick Mode.Quick Mode (5) • If PFS is not needed. . protocol | SPI | Ni_b | Nr_b). the new keying material is defined as KEYMAT = prf(SKEYID_d. "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform. the new keying material is defined as KEYMAT = prf (SKEYID_d. and KE payloads are not exchanged. • In either case. • If PFS is desired and KE payloads were exchanged.

. KEYMAT is expanded by feeding the results of the prf back into itself and concatenating results until the required keying material has been reached.. K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf (SKEYID_d.Extension des clés For situations where the amount of keying material desired is greater than that supplied by the prf. K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) etc. [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf (SKEYID_d. where K1 = prf (SKEYID_d.. In other words. KEYMAT = K1 | K2 | K3 | .