1 Internet Key Exchange Rocky K. C. Chang 20 March 2007

Rocky, K. C. Chang2 Outline  An overview of IKEv1  IKE phase 1 Main mode and aggressive mode 4 different authentication methods  IKE phase 2 Setting up IPSec SAs The quick mode  The current state of IKE

Rocky, K. C. Chang3 IKE  Internet Key Exchange (IKE) protocol is the default method for IPSec. IKE is an application-layer protocol using the well-known UDP port 500. IKE is a general key exchange protocol.  IKE can be thought of as a combination of the packet formats of ISAKMP and the exchanges of OAKLEY. Also influenced by SKEME and Photuris.

Rocky, K. C. Chang4 IKE and ISAKMP  Internet Security Association and Key Management Protocol (ISAKMP), which defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks)  ISAKMP does not define how a particular key exchange is done, and the attributes necessary for establishing security associations.

Rocky, K. C. Chang5 ISAKMP relationships

Rocky, K. C. Chang6 DOI and OAKLEY  An IPSec DOI is also needed to define an IPSec-specific interpretation of certain parts of ISAKMP headers and payloads.  OAKLEY is a key management framework that describes a family of canonical key negotiation sequences, and the security properties of each.  IKE (RFC 2409)+ ISAKMP (RFC 2408) + DOI (RFC 2407)

Rocky, K. C. Chang7 A 2-phase IKE  IKE consists of two phases. IKE phase 1 creates an ISAKMP SA that is a secure channel (encryption and integrity check) for phase 2 negotiation.  Unlike IPSec SAs, an ISAKMP SA is bi-directional.  IKE phase 1 offers two modes---main and aggressive, and 4 authentication methods. IKE phase 2 is used to establish IPSec SAs, for example.

Rocky, K. C. Chang8 Why 2 phases?  Q: Why not use a single phase to establish IPSec SAs?  A1: Set up a single ISAKMP SA from which multiple IPSec SAs and nonIPSec SAs can be established.  A2: Set up IPSec SAs for different flows.  A3: It is more efficient for rekeying (or key rollover)

9 IKE Phase 1: The Main Mode

Rocky, K. C. Chang10 The main mode  The main mode uses three pairs of messages (three RTTs) to establish an ISAKMP SA. 1st pair: ISAKMP SA negotiation (including an exchange of cookies)  Encryption algorithms, hash algorithms, authentication methods, and D-H group (protection suite) 2nd pair: a D-H exchange and an exchange of nonces  Derive the necessary keys for this ISAKMP SA and for the authentication of the peer in the 3rd pair of the messages. 3rd pair: Peer authentication  Four authentication methods available.

Rocky, K. C. Chang11 A 6-message exchange

Rocky, K. C. Chang12 ISAKMP header and payloads  ISAKMP header:

Rocky, K. C. Chang13 ISAKMP header and payloads Cookies generated by I and R. Next Payload indicates the type of the payload after the header. Different (13 at this point) payloads are chained together using the Next Payload field.  All payloads begin with a generic header:

Rocky, K. C. Chang14 (1) ISAKMP SA negotiation  Negotiate (through the ISAKMP SA payloads) Encryption algorithm: used for data encryption, e.g., in the peer authentication in the main mode. Hash algorithm (PRF): used for deriving secret keys in the D- H key exchange and for authentication, e.g., HMAC-MD5. Authentication method: select one out of four methods for peer authentication, e.g.,  Symmetric-key encryption, digital signatures, and 2 public-key encryptions. D-H group: select a group out of five, e.g., OAKLEY group 1:  Use exponentiation over a prime modulus with  p = * { [2 638  } and g = 2  I proposes parameters for the SA, and R replies by saying which ones are accepted.

Rocky, K. C. Chang15 (1) ISAKMP SA negotiation  Exchange of cookies How to generate the cookies (not specified in ISAKMP)? After the cookie exchange, the concatenation of the two cookies identifies the SA. SA I is the entire SA payload with all protection suites offered by I to R and SA R is the entire SA that indicates the protection suite accepted by R.

Rocky, K. C. Chang16

Rocky, K. C. Chang17 Stateless cookies in IKE  A cookie exchange guards against simple flooding attacks sent with bogus IP sources addresses or UDP ports.  I generates a cookie (of length between 64 and 128 bits) C I, and sends it to R.  R then generates a cookie C R, and sends it with C I to I.  To launch a flooding attack, the attacker has to complete a cookie exchange with the victim for each spoofed source IP address (read the cookie sent by the victim for each cookie exchange.)

Rocky, K. C. Chang18 Requirements for cookie generation  The cookie must depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and then using it to swamp the victim with requests from randomly chosen IP addresses or ports.  It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity will use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie.

Rocky, K. C. Chang19 Requirements for cookie generation  The cookie generation and verification methods must be fast to thwart attacks intended to sabotage CPU resources.  A recommended technique is to use a hashing function, such as MD5. An incoming cookie can be verified by regenerating it locally from values contained in the incoming datagram and the local secret random value. For example, cookie = h(secret, source and destination IP addresses, source and destination UDP port numbers)

Rocky, K. C. Chang20 Initiator and responder cookies  The Initiator secret value should be different for each cookie exchange and the secret value is cached. An alternative, of course, is to cache the cookie itself instead of the secret value. It is recommended that the cookie be computed over the secret, source and destination IP addresses, and source and destination UDP port numbers.  The responder secret value may be the same for many different initiators. This secret value should be changed periodically. It is recommended that the cookie be computed over the secret, the Initiator cookie, source and destination IP addresses, and UDP port numbers.

Rocky, K. C. Chang21 (2) The D-H exchange  A secret key, k, will be generated between the peers using the D-H key exchange.  Additionally, four secret keys will be generated between the peers: SKEYID: a string derived from secret material known only to the peers. It is derived differently for each authentication algorithm (why?). SKEYID d : the keying material used to derive keys for non-ISAKMP security associations. SKEYID a : the keying material used by the ISAKMP SA to authenticate its messages. SKEYID e : the keying material used by the ISAKMP SA to protect the confidentiality of its messages.

Rocky, K. C. Chang22 (2) D-H exchange  SKEYID x, x = d, a, e, are derived from SKEYID and k: SKEYID d = PRF(SKEYID, k | C I | C R | 0) SKEYID a = PRF(SKEYID, SKEYID d | k | C I | C R | 1) SKEYID e = PRF(SKEYID, SKEYID a | k | C I | C R | 2), where PRF is the keyed pseudo-random function (often a keyed hash function) agreed between the peers in the ISAKMP SA negotiation stage.  The principle of key separation Different cryptographic functions should use different and cryptographically independent keys, e.g., not to use k for both encryption and authentication. Instead, use k as a seed from which other keys are derived.

Rocky, K. C. Chang23 (2) D-H exchange and (3) peer authentication  Derivation of SKEYID, message contents in the D-H exchange, and peer authentication depend on the authentication method chosen.  Four authentication methods available: pre-shared keys digital signatures public key encryption with four encryption public key encryption with two encryption

Rocky, K. C. Chang24 Why 4 authentication methods?  The pre-shared key method is simple to configure and fast.  Why 2 public-key encryption methods? The original public-key encryption method is not efficient.  Why public-key encryption and signature? The public-key encryption method may be unusable, because I is required to know R’s public key. Using the signature method, one has to reveal its identity to the other first.

Rocky, K. C. Chang25 Pre-shared key authentication  PSKEY: pre-shared key  A nonce is a large pseudo-random number, bits in length, adds randomness to the key negotiation process.  SKEYID = PRF(PSKEY, N I | N R )  ID is a unique identification of I and R, e.g. IP address, domain name, address, etc.  Authentication: HASH I = PRF(SKEYID, X | Y | C I | C R | SA I | ID I ) HASH R = PRF(SKEYID, Y | X | C R | C I | SA I | ID R )  Messages (5) and (6) are encrypted with SKEYID e (the ISAKMP headers are not encrypted).

Rocky, K. C. Chang26 Pre-shared key authentication

Rocky, K. C. Chang27 Disadv. of pre-shared key authen.  When R receives message (5), he cannot view ID I due to the encrypted ISAKMP payloads. Therefore, R could not retrieve the shared key corresponding to ID I. As a result, ID I in this case must be based on the IP header information (the source IP address). If I is allocated with a different IP address due to DHCP, NAT, Mobile IP, etc, R would not be able to retrieve the correct shared key.

Rocky, K. C. Chang28 Public-key signature authentication  In the messages (3) and (4), each peer can optionally request a digital certificate from another side.  SKEYID = PRF(N I | N R, k)  HASH I and HASH R are the same as before.  Each side signs its HASH value: SIG I = PRVKEY I (HASH I ) SIG R = PRVKEY R (HASH R )  The other side could verify the digital signature based on the other side’s public key obtained from the certificate.  Messages (5) and (6) are encrypted with SKEYID e (the ISAKMP headers are not encrypted).

Rocky, K. C. Chang29 Public-key signature authentication

30 Phase 1: The Aggressive Mode

Rocky, K. C. Chang31 The aggressive mode  Aggressive mode is an option defined for each authentication method.  Differences: Reduce from 3 RTT to 1.5 RTT I cannot offer different D-H groups in different protection suites. ID I and ID R are not encrypted; therefore there is no identity protection. Unlike the pre-shared keys for the main mode, aggressive mode allows PSKEY to be computed based on an IP address in the ID payload rather than the packet’s source IP address.

Rocky, K. C. Chang32 Pre-shared key authentication

Rocky, K. C. Chang33 Public-key signature authentication

34 IKE Phase 2

Rocky, K. C. Chang35 IKE phase 2  This second phase can be used to negotiate for a nonISAKMP SA (quick mode), derive new keying material (new group mode), and send an unacknowledged notification message.  All phase 2 packets are protected by the ISAKMP SA established in phase 1. All payloads except for the ISAKMP header are encrypted. A HASH payload must immediately follow the ISAKMP header. An SA payload must immediately follow the HASH.

Rocky, K. C. Chang36 Setting up an IPSec SA  A single SA negotiation results in two IPSec SAs: one inbound and one outbound.  I sends a set of proposals in SA I to R, and R accepts one proposal in SA R. The values for protocol and SPI are specified in the ISAKMP proposal payloads (SA I and SA R ). protocol: PROTO_IPSEC_AH, PROTO_IPSEC_ESP (from DOI) Each side chooses an SPI, and the IPSec SA’s SPI is specified by the source’s SPI.  The keying material of the IPSec SA is partly determined from the destination’s SPI.

Rocky, K. C. Chang37 The first message in quick mode

Rocky, K. C. Chang38 Perfect forward secrecy  If PFS is required, the peers could derive a new private key using D-H exchange in the quick mode. When PFS is in effect, if a key used as part of a session is compromised, other keys used to protect later parts of the session are not compromised. A system would not have PFS if there was a single secret which all symmetric keys were derived.  Multiple quick mode negotiations may take place simultaneously between two participants, which are distinguished by the message identifier, M ID.

Rocky, K. C. Chang39 The quick mode

Rocky, K. C. Chang40 Computing the hash values  HASH(1): Without PFS: HASH(1) = PRF(SKEYID a, M ID | SA I | N I ) With PFS: HASH(1) = PRF(SKEYID a, M ID | SA I | N I | X | ID I | ID R )  HASH(2) Without PFS: HASH(2) = PRF(SKEYID a, M ID | SA R | N I | N R ) With PFS: HASH(2) = PRF(SKEYID a, M ID | SA R | N I | N R | Y | ID I | ID R )  HASH(3) HASH(3) = PRF(SKEYID a, 0 | M ID | N I | N R ) What is the purpose of this message?

Rocky, K. C. Chang41 Computing keys for IPSec SAs  If PFS is not used, KEYMAT = PRF(SKEYID d, protocol | SPI | N I | N R ) (key refreshing)  If PFS is used, KEYMAT = PRF(SKEYID d, k | protocol | SPI | N I | N R )

Rocky, K. C. Chang42 The current state of IKE  Besides the complexity and unreadability of the RFC documents, a number of flaws have been identified.  A draft on IKEv2 To define the entire IKE protocol in a single document, replacing RFCs 2407, 2408, and 2409 …. To simplify IKE by replacing the eight different initial exchanges with a single four message exchange …. To decrease IKE's latency in the common case by making the initial exchange be 2 round trips (4 messages) …. To fix cryptographic weaknesses such as the problem with symmetries in hashes used for authentication ….  Obsoleted by RFC 4306 (December 2005)!

Rocky, K. C. Chang43 Summary  Examined how the authenticated DH protocol is implemented in a practical key exchange protocol. Hiding the identities of the end points Denial of service protection  IKEv1’s complexity, flaws, and the lack of security objectives  A better IKE protocol (version 2)

Rocky, K. C. Chang44 Acknowledgements  These lecture notes are based on M. S. Borella, “Methods and Protocols for Secure Key Negotiation Using IKE,” IEEE Network, pp , July/Aug., N. Doraswamy and D. Harkins, IPSec, Prentice Hall, D. Maughan, M. Schertler, M. Schneider, and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)," RFC2408, Nov D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)." RFC2409, Nov D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP," RFC2407, Nov