| blob | 9d3e6f80e8f58130de8dcb26453f935fc1ed1cfb |
7 Network Working Group D. Harkins
8 Request for Comments: 2409 D. Carrel
9 Category: Standards Track cisco Systems
10 November 1998
13 The Internet Key Exchange (IKE)
15 Status of this Memo
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
23 Copyright Notice
25 Copyright (C) The Internet Society (1998). All Rights Reserved.
27 Table Of Contents
29 1 Abstract........................................................ 2
30 2 Discussion...................................................... 2
31 3 Terms and Definitions........................................... 3
32 3.1 Requirements Terminology...................................... 3
33 3.2 Notation...................................................... 3
34 3.3 Perfect Forward Secrecty...................................... 5
35 3.4 Security Association.......................................... 5
36 4 Introduction.................................................... 5
37 5 Exchanges....................................................... 8
38 5.1 Authentication with Digital Signatures........................ 10
39 5.2 Authentication with Public Key Encryption..................... 12
40 5.3 A Revised method of Authentication with Public Key Encryption. 13
41 5.4 Authentication with a Pre-Shared Key.......................... 16
42 5.5 Quick Mode.................................................... 16
43 5.6 New Group Mode................................................ 20
44 5.7 ISAKMP Informational Exchanges................................ 20
45 6 Oakley Groups................................................... 21
46 6.1 First Oakley Group............................................ 21
47 6.2 Second Oakley Group........................................... 22
48 6.3 Third Oakley Group............................................ 22
49 6.4 Fourth Oakley Group........................................... 23
50 7 Payload Explosion of Complete Exchange.......................... 23
51 7.1 Phase 1 with Main Mode........................................ 23
52 7.2 Phase 2 with Quick Mode....................................... 25
53 8 Perfect Forward Secrecy Example................................. 27
54 9 Implementation Hints............................................ 27
58 Harkins & Carrel Standards Track [Page 1]
59 \f
60 RFC 2409 IKE November 1998
63 10 Security Considerations........................................ 28
64 11 IANA Considerations............................................ 30
65 12 Acknowledgments................................................ 31
66 13 References..................................................... 31
67 Appendix A........................................................ 33
68 Appendix B........................................................ 37
69 Authors' Addresses................................................ 40
70 Authors' Note..................................................... 40
71 Full Copyright Statement.......................................... 41
73 1. Abstract
75 ISAKMP ([MSST98]) provides a framework for authentication and key
76 exchange but does not define them. ISAKMP is designed to be key
77 exchange independant; that is, it is designed to support many
78 different key exchanges.
80 Oakley ([Orm96]) describes a series of key exchanges-- called
81 "modes"-- and details the services provided by each (e.g. perfect
82 forward secrecy for keys, identity protection, and authentication).
84 SKEME ([SKEME]) describes a versatile key exchange technique which
85 provides anonymity, repudiability, and quick key refreshment.
87 This document describes a protocol using part of Oakley and part of
88 SKEME in conjunction with ISAKMP to obtain authenticated keying
89 material for use with ISAKMP, and for other security associations
90 such as AH and ESP for the IETF IPsec DOI.
92 2. Discussion
94 This memo describes a hybrid protocol. The purpose is to negotiate,
95 and provide authenticated keying material for, security associations
96 in a protected manner.
98 Processes which implement this memo can be used for negotiating
99 virtual private networks (VPNs) and also for providing a remote user
100 from a remote site (whose IP address need not be known beforehand)
101 access to a secure host or network.
103 Client negotiation is supported. Client mode is where the
104 negotiating parties are not the endpoints for which security
105 association negotiation is taking place. When used in client mode,
106 the identities of the end parties remain hidden.
114 Harkins & Carrel Standards Track [Page 2]
115 \f
116 RFC 2409 IKE November 1998
119 This does not implement the entire Oakley protocol, but only a subset
120 necessary to satisfy its goals. It does not claim conformance or
121 compliance with the entire Oakley protocol nor is it dependant in any
122 way on the Oakley protocol.
124 Likewise, this does not implement the entire SKEME protocol, but only
125 the method of public key encryption for authentication and its
126 concept of fast re-keying using an exchange of nonces. This protocol
127 is not dependant in any way on the SKEME protocol.
129 3. Terms and Definitions
131 3.1 Requirements Terminology
133 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
134 "MAY" that appear in this document are to be interpreted as described
135 in [Bra97].
137 3.2 Notation
139 The following notation is used throughout this memo.
141 HDR is an ISAKMP header whose exchange type is the mode. When
142 writen as HDR* it indicates payload encryption.
144 SA is an SA negotiation payload with one or more proposals. An
145 initiator MAY provide multiple proposals for negotiation; a
146 responder MUST reply with only one.
148 <P>_b indicates the body of payload <P>-- the ISAKMP generic
149 vpayload is not included.
151 SAi_b is the entire body of the SA payload (minus the ISAKMP
152 generic header)-- i.e. the DOI, situation, all proposals and all
153 transforms offered by the Initiator.
155 CKY-I and CKY-R are the Initiator's cookie and the Responder's
156 cookie, respectively, from the ISAKMP header.
158 g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the
159 initiator and responder respectively.
161 g^xy is the Diffie-Hellman shared secret.
163 KE is the key exchange payload which contains the public
164 information exchanged in a Diffie-Hellman exchange. There is no
165 particular encoding (e.g. a TLV) used for the data of a KE payload.
170 Harkins & Carrel Standards Track [Page 3]
171 \f
172 RFC 2409 IKE November 1998
175 Nx is the nonce payload; x can be: i or r for the ISAKMP initiator
176 and responder respectively.
178 IDx is the identification payload for "x". x can be: "ii" or "ir"
179 for the ISAKMP initiator and responder respectively during phase
180 one negotiation; or "ui" or "ur" for the user initiator and
181 responder respectively during phase two. The ID payload format for
182 the Internet DOI is defined in [Pip97].
184 SIG is the signature payload. The data to sign is exchange-
185 specific.
187 CERT is the certificate payload.
189 HASH (and any derivitive such as HASH(2) or HASH_I) is the hash
190 payload. The contents of the hash are specific to the
191 authentication method.
193 prf(key, msg) is the keyed pseudo-random function-- often a keyed
194 hash function-- used to generate a deterministic output that
195 appears pseudo-random. prf's are used both for key derivations and
196 for authentication (i.e. as a keyed MAC). (See [KBC96]).
198 SKEYID is a string derived from secret material known only to the
199 active players in the exchange.
201 SKEYID_e is the keying material used by the ISAKMP SA to protect
202 the confidentiality of its messages.
204 SKEYID_a is the keying material used by the ISAKMP SA to
205 authenticate its messages.
207 SKEYID_d is the keying material used to derive keys for non-ISAKMP
208 security associations.
210 <x>y indicates that "x" is encrypted with the key "y".
212 --> signifies "initiator to responder" communication (requests).
214 <-- signifies "responder to initiator" communication (replies).
216 | signifies concatenation of information-- e.g. X | Y is the
217 concatentation of X with Y.
219 [x] indicates that x is optional.
226 Harkins & Carrel Standards Track [Page 4]
227 \f
228 RFC 2409 IKE November 1998
231 Message encryption (when noted by a '*' after the ISAKMP header) MUST
232 begin immediately after the ISAKMP header. When communication is
233 protected, all payloads following the ISAKMP header MUST be
234 encrypted. Encryption keys are generated from SKEYID_e in a manner
235 that is defined for each algorithm.
237 3.3 Perfect Forward Secrecy
239 When used in the memo Perfect Forward Secrecy (PFS) refers to the
240 notion that compromise of a single key will permit access to only
241 data protected by a single key. For PFS to exist the key used to
242 protect transmission of data MUST NOT be used to derive any
243 additional keys, and if the key used to protect transmission of data
244 was derived from some other keying material, that material MUST NOT
245 be used to derive any more keys.
247 Perfect Forward Secrecy for both keys and identities is provided in
248 this protocol. (Sections 5.5 and 8).
250 3.4 Security Association
252 A security association (SA) is a set of policy and key(s) used to
253 protect information. The ISAKMP SA is the shared policy and key(s)
254 used by the negotiating peers in this protocol to protect their
255 communication.
257 4. Introduction
259 Oakley and SKEME each define a method to establish an authenticated
260 key exchange. This includes payloads construction, the information
261 payloads carry, the order in which they are processed and how they
262 are used.
264 While Oakley defines "modes", ISAKMP defines "phases". The
265 relationship between the two is very straightforward and IKE presents
266 different exchanges as modes which operate in one of two phases.
268 Phase 1 is where the two ISAKMP peers establish a secure,
269 authenticated channel with which to communicate. This is called the
270 ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode"
271 each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode"
272 MUST ONLY be used in phase 1.
274 Phase 2 is where Security Associations are negotiated on behalf of
275 services such as IPsec or any other service which needs key material
276 and/or parameter negotiation. "Quick Mode" accomplishes a phase 2
277 exchange. "Quick Mode" MUST ONLY be used in phase 2.
282 Harkins & Carrel Standards Track [Page 5]
283 \f
284 RFC 2409 IKE November 1998
287 "New Group Mode" is not really a phase 1 or phase 2. It follows
288 phase 1, but serves to establish a new group which can be used in
289 future negotiations. "New Group Mode" MUST ONLY be used after phase
290 1.
292 The ISAKMP SA is bi-directional. That is, once established, either
293 party may initiate Quick Mode, Informational, and New Group Mode
294 Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified
295 by the Initiator's cookie followed by the Responder's cookie-- the
296 role of each party in the phase 1 exchange dictates which cookie is
297 the Initiator's. The cookie order established by the phase 1 exchange
298 continues to identify the ISAKMP SA regardless of the direction the
299 Quick Mode, Informational, or New Group exchange. In other words, the
300 cookies MUST NOT swap places when the direction of the ISAKMP SA
301 changes.
303 With the use of ISAKMP phases, an implementation can accomplish very
304 fast keying when necessary. A single phase 1 negotiation may be used
305 for more than one phase 2 negotiation. Additionally a single phase 2
306 negotiation can request multiple Security Associations. With these
307 optimizations, an implementation can see less than one round trip per
308 SA as well as less than one DH exponentiation per SA. "Main Mode"
309 for phase 1 provides identity protection. When identity protection
310 is not needed, "Aggressive Mode" can be used to reduce round trips
311 even further. Developer hints for doing these optimizations are
312 included below. It should also be noted that using public key
313 encryption to authenticate an Aggressive Mode exchange will still
314 provide identity protection.
316 This protocol does not define its own DOI per se. The ISAKMP SA,
317 established in phase 1, MAY use the DOI and situation from a non-
318 ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an
319 implementation MAY choose to restrict use of the ISAKMP SA for
320 establishment of SAs for services of the same DOI. Alternately, an
321 ISAKMP SA MAY be established with the value zero in both the DOI and
322 situation (see [MSST98] for a description of these fields) and in
323 this case implementations will be free to establish security services
324 for any defined DOI using this ISAKMP SA. If a DOI of zero is used
325 for establishment of a phase 1 SA, the syntax of the identity
326 payloads used in phase 1 is that defined in [MSST98] and not from any
327 DOI-- e.g. [Pip97]-- which may further expand the syntax and
328 semantics of identities.
330 The following attributes are used by IKE and are negotiated as part
331 of the ISAKMP Security Association. (These attributes pertain only
332 to the ISAKMP Security Association and not to any Security
333 Associations that ISAKMP may be negotiating on behalf of other
334 services.)
338 Harkins & Carrel Standards Track [Page 6]
339 \f
340 RFC 2409 IKE November 1998
343 - encryption algorithm
345 - hash algorithm
347 - authentication method
349 - information about a group over which to do Diffie-Hellman.
351 All of these attributes are mandatory and MUST be negotiated. In
352 addition, it is possible to optionally negotiate a psuedo-random
353 function ("prf"). (There are currently no negotiable pseudo-random
354 functions defined in this document. Private use attribute values can
355 be used for prf negotiation between consenting parties). If a "prf"
356 is not negotiation, the HMAC (see [KBC96]) version of the negotiated
357 hash algorithm is used as a pseudo-random function. Other non-
358 mandatory attributes are described in Appendix A. The selected hash
359 algorithm MUST support both native and HMAC modes.
361 The Diffie-Hellman group MUST be either specified using a defined
362 group description (section 6) or by defining all attributes of a
363 group (section 5.6). Group attributes (such as group type or prime--
364 see Appendix A) MUST NOT be offered in conjunction with a previously
365 defined group (either a reserved group description or a private use
366 description that is established after conclusion of a New Group Mode
367 exchange).
369 IKE implementations MUST support the following attribute values:
371 - DES [DES] in CBC mode with a weak, and semi-weak, key check
372 (weak and semi-weak keys are referenced in [Sch96] and listed in
373 Appendix A). The key is derived according to Appendix B.
375 - MD5 [MD5] and SHA [SHA}.
377 - Authentication via pre-shared keys.
379 - MODP over default group number one (see below).
381 In addition, IKE implementations SHOULD support: 3DES for encryption;
382 Tiger ([TIGER]) for hash; the Digital Signature Standard, RSA [RSA]
383 signatures and authentication with RSA public key encryption; and
384 MODP group number 2. IKE implementations MAY support any additional
385 encryption algorithms defined in Appendix A and MAY support ECP and
386 EC2N groups.
388 The IKE modes described here MUST be implemented whenever the IETF
389 IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes
390 described here.
394 Harkins & Carrel Standards Track [Page 7]
395 \f
396 RFC 2409 IKE November 1998
399 5. Exchanges
401 There are two basic methods used to establish an authenticated key
402 exchange: Main Mode and Aggressive Mode. Each generates authenticated
403 keying material from an ephemeral Diffie-Hellman exchange. Main Mode
404 MUST be implemented; Aggressive Mode SHOULD be implemented. In
405 addition, Quick Mode MUST be implemented as a mechanism to generate
406 fresh keying material and negotiate non-ISAKMP security services. In
407 addition, New Group Mode SHOULD be implemented as a mechanism to
408 define private groups for Diffie-Hellman exchanges. Implementations
409 MUST NOT switch exchange types in the middle of an exchange.
411 Exchanges conform to standard ISAKMP payload syntax, attribute
412 encoding, timeouts and retransmits of messages, and informational
413 messages-- e.g a notify response is sent when, for example, a
414 proposal is unacceptable, or a signature verification or decryption
415 was unsuccessful, etc.
417 The SA payload MUST precede all other payloads in a phase 1 exchange.
418 Except where otherwise noted, there are no requirements for ISAKMP
419 payloads in any message to be in any particular order.
421 The Diffie-Hellman public value passed in a KE payload, in either a
422 phase 1 or phase 2 exchange, MUST be the length of the negotiated
423 Diffie-Hellman group enforced, if necessary, by pre-pending the value
424 with zeros.
426 The length of nonce payload MUST be between 8 and 256 bytes
427 inclusive.
429 Main Mode is an instantiation of the ISAKMP Identity Protect
430 Exchange: The first two messages negotiate policy; the next two
431 exchange Diffie-Hellman public values and ancillary data (e.g.
432 nonces) necessary for the exchange; and the last two messages
433 authenticate the Diffie-Hellman Exchange. The authentication method
434 negotiated as part of the initial ISAKMP exchange influences the
435 composition of the payloads but not their purpose. The XCHG for Main
436 Mode is ISAKMP Identity Protect.
438 Similarly, Aggressive Mode is an instantiation of the ISAKMP
439 Aggressive Exchange. The first two messages negotiate policy,
440 exchange Diffie-Hellman public values and ancillary data necessary
441 for the exchange, and identities. In addition the second message
442 authenticates the responder. The third message authenticates the
443 initiator and provides a proof of participation in the exchange. The
444 XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY
445 NOT be sent under protection of the ISAKMP SA allowing each party to
450 Harkins & Carrel Standards Track [Page 8]
451 \f
452 RFC 2409 IKE November 1998
455 postpone exponentiation, if desired, until negotiation of this
456 exchange is complete. The graphic depictions of Aggressive Mode show
457 the final payload in the clear; it need not be.
459 Exchanges in IKE are not open ended and have a fixed number of
460 messages. Receipt of a Certificate Request payload MUST NOT extend
461 the number of messages transmitted or expected.
463 Security Association negotiation is limited with Aggressive Mode. Due
464 to message construction requirements the group in which the Diffie-
465 Hellman exchange is performed cannot be negotiated. In addition,
466 different authentication methods may further constrain attribute
467 negotiation. For example, authentication with public key encryption
468 cannot be negotiated and when using the revised method of public key
469 encryption for authentication the cipher and hash cannot be
470 negotiated. For situations where the rich attribute negotiation
471 capabilities of IKE are required Main Mode may be required.
473 Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG
474 values for Quick Mode and New Group Mode are defined in Appendix A.
476 Main Mode, Aggressive Mode, and Quick Mode do security association
477 negotiation. Security Association offers take the form of Tranform
478 Payload(s) encapsulated in Proposal Payload(s) encapsulated in
479 Security Association (SA) payload(s). If multiple offers are being
480 made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST
481 take the form of multiple Transform Payloads for a single Proposal
482 Payload in a single SA payload. To put it another way, for phase 1
483 exchanges there MUST NOT be multiple Proposal Payloads for a single
484 SA payload and there MUST NOT be multiple SA payloads. This document
485 does not proscribe such behavior on offers in phase 2 exchanges.
487 There is no limit on the number of offers the initiator may send to
488 the responder but conformant implementations MAY choose to limit the
489 number of offers it will inspect for performance reasons.
491 During security association negotiation, initiators present offers
492 for potential security associations to responders. Responders MUST
493 NOT modify attributes of any offer, attribute encoding excepted (see
494 Appendix A). If the initiator of an exchange notices that attribute
495 values have changed or attributes have been added or deleted from an
496 offer made, that response MUST be rejected.
498 Four different authentication methods are allowed with either Main
499 Mode or Aggressive Mode-- digital signature, two forms of
500 authentication with public key encryption, or pre-shared key. The
501 value SKEYID is computed seperately for each authentication method.
506 Harkins & Carrel Standards Track [Page 9]
507 \f
508 RFC 2409 IKE November 1998
511 For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy)
512 For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |
513 CKY-R)
514 For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b |
515 Nr_b)
517 The result of either Main Mode or Aggressive Mode is three groups of
518 authenticated keying material:
520 SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
521 SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
522 SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
524 and agreed upon policy to protect further communications. The values
525 of 0, 1, and 2 above are represented by a single octet. The key used
526 for encryption is derived from SKEYID_e in an algorithm-specific
527 manner (see appendix B).
529 To authenticate either exchange the initiator of the protocol
530 generates HASH_I and the responder generates HASH_R where:
532 HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
533 HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
535 For authentication with digital signatures, HASH_I and HASH_R are
536 signed and verified; for authentication with either public key
537 encryption or pre-shared keys, HASH_I and HASH_R directly
538 authenticate the exchange. The entire ID payload (including ID type,
539 port, and protocol but excluding the generic header) is hashed into
540 both HASH_I and HASH_R.
542 As mentioned above, the negotiated authentication method influences
543 the content and use of messages for Phase 1 Modes, but not their
544 intent. When using public keys for authentication, the Phase 1
545 exchange can be accomplished either by using signatures or by using
546 public key encryption (if the algorithm supports it). Following are
547 Phase 1 exchanges with different authentication options.
549 5.1 IKE Phase 1 Authenticated With Signatures
551 Using signatures, the ancillary information exchanged during the
552 second roundtrip are nonces; the exchange is authenticated by signing
553 a mutually obtainable hash. Main Mode with signature authentication
554 is described as follows:
562 Harkins & Carrel Standards Track [Page 10]
563 \f
564 RFC 2409 IKE November 1998
567 Initiator Responder
568 ----------- -----------
569 HDR, SA -->
570 <-- HDR, SA
571 HDR, KE, Ni -->
572 <-- HDR, KE, Nr
573 HDR*, IDii, [ CERT, ] SIG_I -->
574 <-- HDR*, IDir, [ CERT, ] SIG_R
576 Aggressive mode with signatures in conjunction with ISAKMP is
577 described as follows:
579 Initiator Responder
580 ----------- -----------
581 HDR, SA, KE, Ni, IDii -->
582 <-- HDR, SA, KE, Nr, IDir,
583 [ CERT, ] SIG_R
584 HDR, [ CERT, ] SIG_I -->
586 In both modes, the signed data, SIG_I or SIG_R, is the result of the
587 negotiated digital signature algorithm applied to HASH_I or HASH_R
588 respectively.
590 In general the signature will be over HASH_I and HASH_R as above
591 using the negotiated prf, or the HMAC version of the negotiated hash
592 function (if no prf is negotiated). However, this can be overridden
593 for construction of the signature if the signature algorithm is tied
594 to a particular hash algorithm (e.g. DSS is only defined with SHA's
595 160 bit output). In this case, the signature will be over HASH_I and
596 HASH_R as above, except using the HMAC version of the hash algorithm
597 associated with the signature method. The negotiated prf and hash
598 function would continue to be used for all other prescribed pseudo-
599 random functions.
601 Since the hash algorithm used is already known there is no need to
602 encode its OID into the signature. In addition, there is no binding
603 between the OIDs used for RSA signatures in PKCS #1 and those used in
604 this document. Therefore, RSA signatures MUST be encoded as a private
605 key encryption in PKCS #1 format and not as a signature in PKCS #1
606 format (which includes the OID of the hash algorithm). DSS signatures
607 MUST be encoded as r followed by s.
609 One or more certificate payloads MAY be optionally passed.
618 Harkins & Carrel Standards Track [Page 11]
619 \f
620 RFC 2409 IKE November 1998
623 5.2 Phase 1 Authenticated With Public Key Encryption
625 Using public key encryption to authenticate the exchange, the
626 ancillary information exchanged is encrypted nonces. Each party's
627 ability to reconstruct a hash (proving that the other party decrypted
628 the nonce) authenticates the exchange.
630 In order to perform the public key encryption, the initiator must
631 already have the responder's public key. In the case where the
632 responder has multiple public keys, a hash of the certificate the
633 initiator is using to encrypt the ancillary information is passed as
634 part of the third message. In this way the responder can determine
635 which corresponding private key to use to decrypt the encrypted
636 payloads and identity protection is retained.
638 In addition to the nonce, the identities of the parties (IDii and
639 IDir) are also encrypted with the other party's public key. If the
640 authentication method is public key encryption, the nonce and
641 identity payloads MUST be encrypted with the public key of the other
642 party. Only the body of the payloads are encrypted, the payload
643 headers are left in the clear.
645 When using encryption for authentication, Main Mode is defined as
646 follows.
648 Initiator Responder
649 ----------- -----------
650 HDR, SA -->
651 <-- HDR, SA
652 HDR, KE, [ HASH(1), ]
653 <IDii_b>PubKey_r,
654 <Ni_b>PubKey_r -->
655 HDR, KE, <IDir_b>PubKey_i,
656 <-- <Nr_b>PubKey_i
657 HDR*, HASH_I -->
658 <-- HDR*, HASH_R
660 Aggressive Mode authenticated with encryption is described as
661 follows:
663 Initiator Responder
664 ----------- -----------
665 HDR, SA, [ HASH(1),] KE,
666 <IDii_b>Pubkey_r,
667 <Ni_b>Pubkey_r -->
668 HDR, SA, KE, <IDir_b>PubKey_i,
669 <-- <Nr_b>PubKey_i, HASH_R
670 HDR, HASH_I -->
674 Harkins & Carrel Standards Track [Page 12]
675 \f
676 RFC 2409 IKE November 1998
679 Where HASH(1) is a hash (using the negotiated hash function) of the
680 certificate which the initiator is using to encrypt the nonce and
681 identity.
683 RSA encryption MUST be encoded in PKCS #1 format. While only the body
684 of the ID and nonce payloads is encrypted, the encrypted data must be
685 preceded by a valid ISAKMP generic header. The payload length is the
686 length of the entire encrypted payload plus header. The PKCS #1
687 encoding allows for determination of the actual length of the
688 cleartext payload upon decryption.
690 Using encryption for authentication provides for a plausably deniable
691 exchange. There is no proof (as with a digital signature) that the
692 conversation ever took place since each party can completely
693 reconstruct both sides of the exchange. In addition, security is
694 added to secret generation since an attacker would have to
695 successfully break not only the Diffie-Hellman exchange but also both
696 RSA encryptions. This exchange was motivated by [SKEME].
698 Note that, unlike other authentication methods, authentication with
699 public key encryption allows for identity protection with Aggressive
700 Mode.
702 5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption
704 Authentication with Public Key Encryption has significant advantages
705 over authentication with signatures (see section 5.2 above).
706 Unfortunately, this is at the cost of 4 public key operations-- two
707 public key encryptions and two private key decryptions. This
708 authentication mode retains the advantages of authentication using
709 public key encryption but does so with half the public key
710 operations.
712 In this mode, the nonce is still encrypted using the public key of
713 the peer, however the peer's identity (and the certificate if it is
714 sent) is encrypted using the negotiated symmetric encryption
715 algorithm (from the SA payload) with a key derived from the nonce.
716 This solution adds minimal complexity and state yet saves two costly
717 public key operations on each side. In addition, the Key Exchange
718 payload is also encrypted using the same derived key. This provides
719 additional protection against cryptanalysis of the Diffie-Hellman
720 exchange.
722 As with the public key encryption method of authentication (section
723 5.2), a HASH payload may be sent to identify a certificate if the
724 responder has multiple certificates which contain useable public keys
725 (e.g. if the certificate is not for signatures only, either due to
726 certificate restrictions or algorithmic restrictions). If the HASH
730 Harkins & Carrel Standards Track [Page 13]
731 \f
732 RFC 2409 IKE November 1998
735 payload is sent it MUST be the first payload of the second message
736 exchange and MUST be followed by the encrypted nonce. If the HASH
737 payload is not sent, the first payload of the second message exchange
738 MUST be the encrypted nonce. In addition, the initiator my optionally
739 send a certificate payload to provide the responder with a public key
740 with which to respond.
742 When using the revised encryption mode for authentication, Main Mode
743 is defined as follows.
745 Initiator Responder
746 ----------- -----------
747 HDR, SA -->
748 <-- HDR, SA
749 HDR, [ HASH(1), ]
750 <Ni_b>Pubkey_r,
751 <KE_b>Ke_i,
752 <IDii_b>Ke_i,
753 [<<Cert-I_b>Ke_i] -->
754 HDR, <Nr_b>PubKey_i,
755 <KE_b>Ke_r,
756 <-- <IDir_b>Ke_r,
757 HDR*, HASH_I -->
758 <-- HDR*, HASH_R
760 Aggressive Mode authenticated with the revised encryption method is
761 described as follows:
763 Initiator Responder
764 ----------- -----------
765 HDR, SA, [ HASH(1),]
766 <Ni_b>Pubkey_r,
767 <KE_b>Ke_i, <IDii_b>Ke_i
768 [, <Cert-I_b>Ke_i ] -->
769 HDR, SA, <Nr_b>PubKey_i,
770 <KE_b>Ke_r, <IDir_b>Ke_r,
771 <-- HASH_R
772 HDR, HASH_I -->
774 where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to
775 the symmetric encryption algorithm negotiated in the SA payload
776 exchange. Only the body of the payloads are encrypted (in both public
777 key and symmetric operations), the generic payload headers are left
778 in the clear. The payload length includes that added to perform
779 encryption.
781 The symmetric cipher keys are derived from the decrypted nonces as
782 follows. First the values Ne_i and Ne_r are computed:
786 Harkins & Carrel Standards Track [Page 14]
787 \f
788 RFC 2409 IKE November 1998
791 Ne_i = prf(Ni_b, CKY-I)
792 Ne_r = prf(Nr_b, CKY-R)
794 The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively
795 in the manner described in Appendix B used to derive symmetric keys
796 for use with the negotiated encryption algorithm. If the length of
797 the output of the negotiated prf is greater than or equal to the key
798 length requirements of the cipher, Ke_i and Ke_r are derived from the
799 most significant bits of Ne_i and Ne_r respectively. If the desired
800 length of Ke_i and Ke_r exceed the length of the output of the prf
801 the necessary number of bits is obtained by repeatedly feeding the
802 results of the prf back into itself and concatenating the result
803 until the necessary number has been achieved. For example, if the
804 negotiated encryption algorithm requires 320 bits of key and the
805 output of the prf is only 128 bits, Ke_i is the most significant 320
806 bits of K, where
808 K = K1 | K2 | K3 and
809 K1 = prf(Ne_i, 0)
810 K2 = prf(Ne_i, K1)
811 K3 = prf(Ne_i, K2)
813 For brevity, only derivation of Ke_i is shown; Ke_r is identical. The
814 length of the value 0 in the computation of K1 is a single octet.
815 Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be
816 discarded after use.
818 Save the requirements on the location of the optional HASH payload
819 and the mandatory nonce payload there are no further payload
820 requirements. All payloads-- in whatever order-- following the
821 encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the
822 direction.
824 If CBC mode is used for the symmetric encryption then the
825 initialization vectors (IVs) are set as follows. The IV for
826 encrypting the first payload following the nonce is set to 0 (zero).
827 The IV for subsequent payloads encrypted with the ephemeral symmetric
828 cipher key, Ke_i, is the last ciphertext block of the previous
829 payload. Encrypted payloads are padded up to the nearest block size.
830 All padding bytes, except for the last one, contain 0x00. The last
831 byte of the padding contains the number of the padding bytes used,
832 excluding the last one. Note that this means there will always be
833 padding.
842 Harkins & Carrel Standards Track [Page 15]
843 \f
844 RFC 2409 IKE November 1998
847 5.4 Phase 1 Authenticated With a Pre-Shared Key
849 A key derived by some out-of-band mechanism may also be used to
850 authenticate the exchange. The actual establishment of this key is
851 out of the scope of this document.
853 When doing a pre-shared key authentication, Main Mode is defined as
854 follows:
856 Initiator Responder
857 ---------- -----------
858 HDR, SA -->
859 <-- HDR, SA
860 HDR, KE, Ni -->
861 <-- HDR, KE, Nr
862 HDR*, IDii, HASH_I -->
863 <-- HDR*, IDir, HASH_R
865 Aggressive mode with a pre-shared key is described as follows:
867 Initiator Responder
868 ----------- -----------
869 HDR, SA, KE, Ni, IDii -->
870 <-- HDR, SA, KE, Nr, IDir, HASH_R
871 HDR, HASH_I -->
873 When using pre-shared key authentication with Main Mode the key can
874 only be identified by the IP address of the peers since HASH_I must
875 be computed before the initiator has processed IDir. Aggressive Mode
876 allows for a wider range of identifiers of the pre-shared secret to
877 be used. In addition, Aggressive Mode allows two parties to maintain
878 multiple, different pre-shared keys and identify the correct one for
879 a particular exchange.
881 5.5 Phase 2 - Quick Mode
883 Quick Mode is not a complete exchange itself (in that it is bound to
884 a phase 1 exchange), but is used as part of the SA negotiation
885 process (phase 2) to derive keying material and negotiate shared
886 policy for non-ISAKMP SAs. The information exchanged along with Quick
887 Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except
888 the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST
889 immediately follow the ISAKMP header and a SA payload MUST
890 immediately follow the HASH. This HASH authenticates the message and
891 also provides liveliness proofs.
898 Harkins & Carrel Standards Track [Page 16]
899 \f
900 RFC 2409 IKE November 1998
903 The message ID in the ISAKMP header identifies a Quick Mode in
904 progress for a particular ISAKMP SA which itself is identified by the
905 cookies in the ISAKMP header. Since each instance of a Quick Mode
906 uses a unique initialization vector (see Appendix B) it is possible
907 to have multiple simultaneous Quick Modes, based off a single ISAKMP
908 SA, in progress at any one time.
910 Quick Mode is essentially a SA negotiation and an exchange of nonces
911 that provides replay protection. The nonces are used to generate
912 fresh key material and prevent replay attacks from generating bogus
913 security associations. An optional Key Exchange payload can be
914 exchanged to allow for an additional Diffie-Hellman exchange and
915 exponentiation per Quick Mode. While use of the key exchange payload
916 with Quick Mode is optional it MUST be supported.
918 Base Quick Mode (without the KE payload) refreshes the keying
919 material derived from the exponentiation in phase 1. This does not
920 provide PFS. Using the optional KE payload, an additional
921 exponentiation is performed and PFS is provided for the keying
922 material.
924 The identities of the SAs negotiated in Quick Mode are implicitly
925 assumed to be the IP addresses of the ISAKMP peers, without any
926 implied constraints on the protocol or port numbers allowed, unless
927 client identifiers are specified in Quick Mode. If ISAKMP is acting
928 as a client negotiator on behalf of another party, the identities of
929 the parties MUST be passed as IDci and then IDcr. Local policy will
930 dictate whether the proposals are acceptable for the identities
931 specified. If the client identities are not acceptable to the Quick
932 Mode responder (due to policy or other reasons), a Notify payload
933 with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.
935 The client identities are used to identify and direct traffic to the
936 appropriate tunnel in cases where multiple tunnels exist between two
937 peers and also to allow for unique and shared SAs with different
938 granularities.
940 All offers made during a Quick Mode are logically related and must be
941 consistant. For example, if a KE payload is sent, the attribute
942 describing the Diffie-Hellman group (see section 6.1 and [Pip97])
943 MUST be included in every transform of every proposal of every SA
944 being negotiated. Similarly, if client identities are used, they MUST
945 apply to every SA in the negotiation.
947 Quick Mode is defined as follows:
954 Harkins & Carrel Standards Track [Page 17]
955 \f
956 RFC 2409 IKE November 1998
959 Initiator Responder
960 ----------- -----------
961 HDR*, HASH(1), SA, Ni
962 [, KE ] [, IDci, IDcr ] -->
963 <-- HDR*, HASH(2), SA, Nr
964 [, KE ] [, IDci, IDcr ]
965 HDR*, HASH(3) -->
967 Where:
968 HASH(1) is the prf over the message id (M-ID) from the ISAKMP header
969 concatenated with the entire message that follows the hash including
970 all payload headers, but excluding any padding added for encryption.
971 HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni,
972 minus the payload header-- is added after M-ID but before the
973 complete message. The addition of the nonce to HASH(2) is for a
974 liveliness proof. HASH(3)-- for liveliness-- is the prf over the
975 value zero represented as a single octet, followed by a concatenation
976 of the message id and the two nonces-- the initiator's followed by
977 the responder's-- minus the payload header. In other words, the
978 hashes for the above exchange are:
980 HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
981 HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
982 IDcr )
983 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
985 With the exception of the HASH, SA, and the optional ID payloads,
986 there are no payload ordering restrictions on Quick Mode. HASH(1) and
987 HASH(2) may differ from the illustration above if the order of
988 payloads in the message differs from the illustrative example or if
989 any optional payloads, for example a notify payload, have been
990 chained to the message.
992 If PFS is not needed, and KE payloads are not exchanged, the new
993 keying material is defined as
995 KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).
997 If PFS is desired and KE payloads were exchanged, the new keying
998 material is defined as
1000 KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
1002 where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman
1003 exchange of this Quick Mode.
1005 In either case, "protocol" and "SPI" are from the ISAKMP Proposal
1006 Payload that contained the negotiated Transform.
1010 Harkins & Carrel Standards Track [Page 18]
1011 \f
1012 RFC 2409 IKE November 1998
1015 A single SA negotiation results in two security assocations-- one
1016 inbound and one outbound. Different SPIs for each SA (one chosen by
1017 the initiator, the other by the responder) guarantee a different key
1018 for each direction. The SPI chosen by the destination of the SA is
1019 used to derive KEYMAT for that SA.
1021 For situations where the amount of keying material desired is greater
1022 than that supplied by the prf, KEYMAT is expanded by feeding the
1023 results of the prf back into itself and concatenating results until
1024 the required keying material has been reached. In other words,
1026 KEYMAT = K1 | K2 | K3 | ...
1027 where
1028 K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
1029 K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b |
1030 Nr_b)
1031 K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b |
1032 Nr_b)
1033 etc.
1035 This keying material (whether with PFS or without, and whether
1036 derived directly or through concatenation) MUST be used with the
1037 negotiated SA. It is up to the service to define how keys are derived
1038 from the keying material.
1040 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode,
1041 the exponential (g(qm)^xy) is irretreivably removed from the current
1042 state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation)
1043 continue to protect and authenticate the ISAKMP SA and SKEYID_d
1044 continues to be used to derive keys.
1046 Using Quick Mode, multiple SA's and keys can be negotiated with one
1047 exchange as follows:
1049 Initiator Responder
1050 ----------- -----------
1051 HDR*, HASH(1), SA0, SA1, Ni,
1052 [, KE ] [, IDci, IDcr ] -->
1053 <-- HDR*, HASH(2), SA0, SA1, Nr,
1054 [, KE ] [, IDci, IDcr ]
1055 HDR*, HASH(3) -->
1057 The keying material is derived identically as in the case of a single
1058 SA. In this case (negotiation of two SA payloads) the result would be
1059 four security associations-- two each way for both SAs.
1066 Harkins & Carrel Standards Track [Page 19]
1067 \f
1068 RFC 2409 IKE November 1998
1071 5.6 New Group Mode
1073 New Group Mode MUST NOT be used prior to establishment of an ISAKMP
1074 SA. The description of a new group MUST only follow phase 1
1075 negotiation. (It is not a phase 2 exchange, though).
1077 Initiator Responder
1078 ----------- -----------
1079 HDR*, HASH(1), SA -->
1080 <-- HDR*, HASH(2), SA
1082 where HASH(1) is the prf output, using SKEYID_a as the key, and the
1083 message-ID from the ISAKMP header concatenated with the entire SA
1084 proposal, body and header, as the data; HASH(2) is the prf output,
1085 using SKEYID_a as the key, and the message-ID from the ISAKMP header
1086 concatenated with the reply as the data. In other words the hashes
1087 for the above exchange are:
1089 HASH(1) = prf(SKEYID_a, M-ID | SA)
1090 HASH(2) = prf(SKEYID_a, M-ID | SA)
1092 The proposal will specify the characteristics of the group (see
1093 appendix A, "Attribute Assigned Numbers"). Group descriptions for
1094 private Groups MUST be greater than or equal to 2^15. If the group
1095 is not acceptable, the responder MUST reply with a Notify payload
1096 with the message type set to ATTRIBUTES-NOT-SUPPORTED (13).
1098 ISAKMP implementations MAY require private groups to expire with the
1099 SA under which they were established.
1101 Groups may be directly negotiated in the SA proposal with Main Mode.
1102 To do this the component parts-- for a MODP group, the type, prime
1103 and generator; for a EC2N group the type, the Irreducible Polynomial,
1104 Group Generator One, Group Generator Two, Group Curve A, Group Curve
1105 B and Group Order-- are passed as SA attributes (see Appendix A).
1106 Alternately, the nature of the group can be hidden using New Group
1107 Mode and only the group identifier is passed in the clear during
1108 phase 1 negotiation.
1110 5.7 ISAKMP Informational Exchanges
1112 This protocol protects ISAKMP Informational Exchanges when possible.
1113 Once the ISAKMP security association has been established (and
1114 SKEYID_e and SKEYID_a have been generated) ISAKMP Information
1115 Exchanges, when used with this protocol, are as follows:
1122 Harkins & Carrel Standards Track [Page 20]
1123 \f
1124 RFC 2409 IKE November 1998
1127 Initiator Responder
1128 ----------- -----------
1129 HDR*, HASH(1), N/D -->
1131 where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete
1132 Payload and HASH(1) is the prf output, using SKEYID_a as the key, and
1133 a M-ID unique to this exchange concatenated with the entire
1134 informational payload (either a Notify or Delete) as the data. In
1135 other words, the hash for the above exchange is:
1137 HASH(1) = prf(SKEYID_a, M-ID | N/D)
1139 As noted the message ID in the ISAKMP header-- and used in the prf
1140 computation-- is unique to this exchange and MUST NOT be the same as
1141 the message ID of another phase 2 exchange which generated this
1142 informational exchange. The derivation of the initialization vector,
1143 used with SKEYID_e to encrypt this message, is described in Appendix
1144 B.
1146 If the ISAKMP security association has not yet been established at
1147 the time of the Informational Exchange, the exchange is done in the
1148 clear without an accompanying HASH payload.
1150 6 Oakley Groups
1152 With IKE, the group in which to do the Diffie-Hellman exchange is
1153 negotiated. Four groups-- values 1 through 4-- are defined below.
1154 These groups originated with the Oakley protocol and are therefore
1155 called "Oakley Groups". The attribute class for "Group" is defined in
1156 Appendix A. All values 2^15 and higher are used for private group
1157 identifiers. For a discussion on the strength of the default Oakley
1158 groups please see the Security Considerations section below.
1160 These groups were all generated by Richard Schroeppel at the
1161 University of Arizona. Properties of these groups are described in
1162 [Orm96].
1164 6.1 First Oakley Default Group
1166 Oakley implementations MUST support a MODP group with the following
1167 prime and generator. This group is assigned id 1 (one).
1169 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
1170 Its hexadecimal value is
1178 Harkins & Carrel Standards Track [Page 21]
1179 \f
1180 RFC 2409 IKE November 1998
1183 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
1184 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
1185 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
1186 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
1188 The generator is: 2.
1190 6.2 Second Oakley Group
1192 IKE implementations SHOULD support a MODP group with the following
1193 prime and generator. This group is assigned id 2 (two).
1195 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
1196 Its hexadecimal value is
1198 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
1199 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
1200 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
1201 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
1202 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
1203 FFFFFFFF FFFFFFFF
1205 The generator is 2 (decimal)
1207 6.3 Third Oakley Group
1209 IKE implementations SHOULD support a EC2N group with the following
1210 characteristics. This group is assigned id 3 (three). The curve is
1211 based on the Galois Field GF[2^155]. The field size is 155. The
1212 irreducible polynomial for the field is:
1213 u^155 + u^62 + 1.
1214 The equation for the elliptic curve is:
1215 y^2 + xy = x^3 + ax^2 + b.
1217 Field Size: 155
1218 Group Prime/Irreducible Polynomial:
1219 0x0800000000000000000000004000000000000001
1220 Group Generator One: 0x7b
1221 Group Curve A: 0x0
1222 Group Curve B: 0x07338f
1224 Group Order: 0X0800000000000000000057db5698537193aef944
1226 The data in the KE payload when using this group is the value x from
1227 the solution (x,y), the point on the curve chosen by taking the
1228 randomly chosen secret Ka and computing Ka*P, where * is the
1229 repetition of the group addition and double operations, P is the
1230 curve point with x coordinate equal to generator 1 and the y
1234 Harkins & Carrel Standards Track [Page 22]
1235 \f
1236 RFC 2409 IKE November 1998
1239 coordinate determined from the defining equation. The equation of
1240 curve is implicitly known by the Group Type and the A and B
1241 coefficients. There are two possible values for the y coordinate;
1242 either one can be used successfully (the two parties need not agree
1243 on the selection).
1245 6.4 Fourth Oakley Group
1247 IKE implementations SHOULD support a EC2N group with the following
1248 characteristics. This group is assigned id 4 (four). The curve is
1249 based on the Galois Field GF[2^185]. The field size is 185. The
1250 irreducible polynomial for the field is:
1251 u^185 + u^69 + 1. The
1252 equation for the elliptic curve is:
1253 y^2 + xy = x^3 + ax^2 + b.
1255 Field Size: 185
1256 Group Prime/Irreducible Polynomial:
1257 0x020000000000000000000000000000200000000000000001
1258 Group Generator One: 0x18
1259 Group Curve A: 0x0
1260 Group Curve B: 0x1ee9
1262 Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc
1264 The data in the KE payload when using this group will be identical to
1265 that as when using Oakley Group 3 (three).
1267 Other groups can be defined using New Group Mode. These default
1268 groups were generated by Richard Schroeppel at the University of
1269 Arizona. Properties of these primes are described in [Orm96].
1271 7. Payload Explosion for a Complete IKE Exchange
1273 This section illustrates how the IKE protocol is used to:
1275 - establish a secure and authenticated channel between ISAKMP
1276 processes (phase 1); and
1278 - generate key material for, and negotiate, an IPsec SA (phase 2).
1280 7.1 Phase 1 using Main Mode
1282 The following diagram illustrates the payloads exchanged between the
1283 two parties in the first round trip exchange. The initiator MAY
1284 propose several proposals; the responder MUST reply with one.
1290 Harkins & Carrel Standards Track [Page 23]
1291 \f
1292 RFC 2409 IKE November 1998
1295 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
1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1297 ~ ISAKMP Header with XCHG of Main Mode, ~
1298 ~ and Next Payload of ISA_SA ~
1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1300 ! 0 ! RESERVED ! Payload Length !
1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1302 ! Domain of Interpretation !
1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1304 ! Situation !
1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1306 ! 0 ! RESERVED ! Payload Length !
1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1308 ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms !
1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1310 ! ISA_TRANS ! RESERVED ! Payload Length !
1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1312 ! Transform #1 ! KEY_OAKLEY | RESERVED2 !
1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1314 ~ prefered SA attributes ~
1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1316 ! 0 ! RESERVED ! Payload Length !
1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1318 ! Transform #2 ! KEY_OAKLEY | RESERVED2 !
1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1320 ~ alternate SA attributes ~
1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1323 The responder replies in kind but selects, and returns, one transform
1324 proposal (the ISAKMP SA attributes).
1326 The second exchange consists of the following payloads:
1328 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
1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1330 ~ ISAKMP Header with XCHG of Main Mode, ~
1331 ~ and Next Payload of ISA_KE ~
1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1333 ! ISA_NONCE ! RESERVED ! Payload Length !
1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1335 ~ D-H Public Value (g^xi from initiator g^xr from responder) ~
1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1337 ! 0 ! RESERVED ! Payload Length !
1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1339 ~ Ni (from initiator) or Nr (from responder) ~
1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1346 Harkins & Carrel Standards Track [Page 24]
1347 \f
1348 RFC 2409 IKE November 1998
1351 The shared keys, SKEYID_e and SKEYID_a, are now used to protect and
1352 authenticate all further communication. Note that both SKEYID_e and
1353 SKEYID_a are unauthenticated.
1355 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
1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1357 ~ ISAKMP Header with XCHG of Main Mode, ~
1358 ~ and Next Payload of ISA_ID and the encryption bit set ~
1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1360 ! ISA_SIG ! RESERVED ! Payload Length !
1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1362 ~ Identification Data of the ISAKMP negotiator ~
1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1364 ! 0 ! RESERVED ! Payload Length !
1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1366 ~ signature verified by the public key of the ID above ~
1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1369 The key exchange is authenticated over a signed hash as described in
1370 section 5.1. Once the signature has been verified using the
1371 authentication algorithm negotiated as part of the ISAKMP SA, the
1372 shared keys, SKEYID_e and SKEYID_a can be marked as authenticated.
1373 (For brevity, certificate payloads were not exchanged).
1375 7.2 Phase 2 using Quick Mode
1377 The following payloads are exchanged in the first round of Quick Mode
1378 with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP
1379 negotiators are proxies for other parties which have requested
1380 authentication.
1382 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
1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1384 ~ ISAKMP Header with XCHG of Quick Mode, ~
1385 ~ Next Payload of ISA_HASH and the encryption bit set ~
1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1387 ! ISA_SA ! RESERVED ! Payload Length !
1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1389 ~ keyed hash of message ~
1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1391 ! ISA_NONCE ! RESERVED ! Payload Length !
1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1393 ! Domain Of Interpretation !
1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1395 ! Situation !
1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1397 ! 0 ! RESERVED ! Payload Length !
1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1402 Harkins & Carrel Standards Track [Page 25]
1403 \f
1404 RFC 2409 IKE November 1998
1407 ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms !
1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1409 ~ SPI (4 octets) ~
1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1411 ! ISA_TRANS ! RESERVED ! Payload Length !
1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1413 ! Transform #1 ! AH_SHA | RESERVED2 !
1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1415 ! other SA attributes !
1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1417 ! 0 ! RESERVED ! Payload Length !
1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1419 ! Transform #2 ! AH_MD5 | RESERVED2 !
1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1421 ! other SA attributes !
1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1423 ! ISA_ID ! RESERVED ! Payload Length !
1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1425 ~ nonce ~
1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1427 ! ISA_ID ! RESERVED ! Payload Length !
1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1429 ~ ID of source for which ISAKMP is a client ~
1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1431 ! 0 ! RESERVED ! Payload Length !
1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1433 ~ ID of destination for which ISAKMP is a client ~
1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1436 where the contents of the hash are described in 5.5 above. The
1437 responder replies with a similar message which only contains one
1438 transform-- the selected AH transform. Upon receipt, the initiator
1439 can provide the key engine with the negotiated security association
1440 and the keying material. As a check against replay attacks, the
1441 responder waits until receipt of the next message.
1443 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
1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1445 ~ ISAKMP Header with XCHG of Quick Mode, ~
1446 ~ Next Payload of ISA_HASH and the encryption bit set ~
1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1448 ! 0 ! RESERVED ! Payload Length !
1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1450 ~ hash data ~
1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1453 where the contents of the hash are described in 5.5 above.
1458 Harkins & Carrel Standards Track [Page 26]
1459 \f
1460 RFC 2409 IKE November 1998
1463 8. Perfect Forward Secrecy Example
1465 This protocol can provide PFS of both keys and identities. The
1466 identies of both the ISAKMP negotiating peer and, if applicable, the
1467 identities for whom the peers are negotiating can be protected with
1468 PFS.
1470 To provide Perfect Forward Secrecy of both keys and all identities,
1471 two parties would perform the following:
1473 o A Main Mode Exchange to protect the identities of the ISAKMP
1474 peers.
1475 This establishes an ISAKMP SA.
1476 o A Quick Mode Exchange to negotiate other security protocol
1477 protection.
1478 This establishes a SA on each end for this protocol.
1479 o Delete the ISAKMP SA and its associated state.
1481 Since the key for use in the non-ISAKMP SA was derived from the
1482 single ephemeral Diffie-Hellman exchange PFS is preserved.
1484 To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP
1485 security association, it in not necessary to do a phase 1 exchange if
1486 an ISAKMP SA exists between the two peers. A single Quick Mode in
1487 which the optional KE payload is passed, and an additional Diffie-
1488 Hellman exchange is performed, is all that is required. At this point
1489 the state derived from this Quick Mode must be deleted from the
1490 ISAKMP SA as described in section 5.5.
1492 9. Implementation Hints
1494 Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2
1495 negotiations extremely quick. As long as the Phase 1 state remains
1496 cached, and PFS is not needed, Phase 2 can proceed without any
1497 exponentiation. How many Phase 2 negotiations can be performed for a
1498 single Phase 1 is a local policy issue. The decision will depend on
1499 the strength of the algorithms being used and level of trust in the
1500 peer system.
1502 An implementation may wish to negotiate a range of SAs when
1503 performing Quick Mode. By doing this they can speed up the "re-
1504 keying". Quick Mode defines how KEYMAT is defined for a range of SAs.
1505 When one peer feels it is time to change SAs they simply use the next
1506 one within the stated range. A range of SAs can be established by
1507 negotiating multiple SAs (identical attributes, different SPIs) with
1508 one Quick Mode.
1514 Harkins & Carrel Standards Track [Page 27]
1515 \f
1516 RFC 2409 IKE November 1998
1519 An optimization that is often useful is to establish Security
1520 Associations with peers before they are needed so that when they
1521 become needed they are already in place. This ensures there would be
1522 no delays due to key management before initial data transmission.
1523 This optimization is easily implemented by setting up more than one
1524 Security Association with a peer for each requested Security
1525 Association and caching those not immediately used.
1527 Also, if an ISAKMP implementation is alerted that a SA will soon be
1528 needed (e.g. to replace an existing SA that will expire in the near
1529 future), then it can establish the new SA before that new SA is
1530 needed.
1532 The base ISAKMP specification describes conditions in which one party
1533 of the protocol may inform the other party of some activity-- either
1534 deletion of a security association or in response to some error in
1535 the protocol such as a signature verification failed or a payload
1536 failed to decrypt. It is strongly suggested that these Informational
1537 exchanges not be responded to under any circumstances. Such a
1538 condition may result in a "notify war" in which failure to understand
1539 a message results in a notify to the peer who cannot understand it
1540 and sends his own notify back which is also not understood.
1542 10. Security Considerations
1544 This entire memo discusses a hybrid protocol, combining parts of
1545 Oakley and parts of SKEME with ISAKMP, to negotiate, and derive
1546 keying material for, security associations in a secure and
1547 authenticated manner.
1549 Confidentiality is assured by the use of a negotiated encryption
1550 algorithm. Authentication is assured by the use of a negotiated
1551 method: a digital signature algorithm; a public key algorithm which
1552 supports encryption; or, a pre-shared key. The confidentiality and
1553 authentication of this exchange is only as good as the attributes
1554 negotiated as part of the ISAKMP security association.
1556 Repeated re-keying using Quick Mode can consume the entropy of the
1557 Diffie-Hellman shared secret. Implementors should take note of this
1558 fact and set a limit on Quick Mode Exchanges between exponentiations.
1559 This memo does not prescribe such a limit.
1561 Perfect Forward Secrecy (PFS) of both keying material and identities
1562 is possible with this protocol. By specifying a Diffie-Hellman group,
1563 and passing public values in KE payloads, ISAKMP peers can establish
1564 PFS of keys-- the identities would be protected by SKEYID_e from the
1565 ISAKMP SA and would therefore not be protected by PFS. If PFS of both
1566 keying material and identities is desired, an ISAKMP peer MUST
1570 Harkins & Carrel Standards Track [Page 28]
1571 \f
1572 RFC 2409 IKE November 1998
1575 establish only one non-ISAKMP security association (e.g. IPsec
1576 Security Association) per ISAKMP SA. PFS for keys and identities is
1577 accomplished by deleting the ISAKMP SA (and optionally issuing a
1578 DELETE message) upon establishment of the single non-ISAKMP SA. In
1579 this way a phase one negotiation is uniquely tied to a single phase
1580 two negotiation, and the ISAKMP SA established during phase one
1581 negotiation is never used again.
1583 The strength of a key derived from a Diffie-Hellman exchange using
1584 any of the groups defined here depends on the inherent strength of
1585 the group, the size of the exponent used, and the entropy provided by
1586 the random number generator used. Due to these inputs it is difficult
1587 to determine the strength of a key for any of the defined groups. The
1588 default Diffie-Hellman group (number one) when used with a strong
1589 random number generator and an exponent no less than 160 bits is
1590 sufficient to use for DES. Groups two through four provide greater
1591 security. Implementations should make note of these conservative
1592 estimates when establishing policy and negotiating security
1593 parameters.
1595 Note that these limitations are on the Diffie-Hellman groups
1596 themselves. There is nothing in IKE which prohibits using stronger
1597 groups nor is there anything which will dilute the strength obtained
1598 from stronger groups. In fact, the extensible framework of IKE
1599 encourages the definition of more groups; use of elliptical curve
1600 groups will greatly increase strength using much smaller numbers.
1602 For situations where defined groups provide insufficient strength New
1603 Group Mode can be used to exchange a Diffie-Hellman group which
1604 provides the necessary strength. In is incumbent upon implementations
1605 to check the primality in groups being offered and independently
1606 arrive at strength estimates.
1608 It is assumed that the Diffie-Hellman exponents in this exchange are
1609 erased from memory after use. In particular, these exponents must not
1610 be derived from long-lived secrets like the seed to a pseudo-random
1611 generator.
1613 IKE exchanges maintain running initialization vectors (IV) where the
1614 last ciphertext block of the last message is the IV for the next
1615 message. To prevent retransmissions (or forged messages with valid
1616 cookies) from causing exchanges to get out of sync IKE
1617 implementations SHOULD NOT update their running IV until the
1618 decrypted message has passed a basic sanity check and has been
1619 determined to actually advance the IKE state machine-- i.e. it is not
1620 a retransmission.
1626 Harkins & Carrel Standards Track [Page 29]
1627 \f
1628 RFC 2409 IKE November 1998
1631 While the last roundtrip of Main Mode (and optionally the last
1632 message of Aggressive Mode) is encrypted it is not, strictly
1633 speaking, authenticated. An active substitution attack on the
1634 ciphertext could result in payload corruption. If such an attack
1635 corrupts mandatory payloads it would be detected by an authentication
1636 failure, but if it corrupts any optional payloads (e.g. notify
1637 payloads chained onto the last message of a Main Mode exchange) it
1638 might not be detectable.
1640 11. IANA Considerations
1642 This document contains many "magic numbers" to be maintained by the
1643 IANA. This section explains the criteria to be used by the IANA to
1644 assign additional numbers in each of these lists.
1646 11.1 Attribute Classes
1648 Attributes negotiated in this protocol are identified by their class.
1649 Requests for assignment of new classes must be accompanied by a
1650 standards-track RFC which describes the use of this attribute.
1652 11.2 Encryption Algorithm Class
1654 Values of the Encryption Algorithm Class define an encryption
1655 algorithm to use when called for in this document. Requests for
1656 assignment of new encryption algorithm values must be accompanied by
1657 a reference to a standards-track or Informational RFC or a reference
1658 to published cryptographic literature which describes this algorithm.
1660 11.3 Hash Algorithm
1662 Values of the Hash Algorithm Class define a hash algorithm to use
1663 when called for in this document. Requests for assignment of new hash
1664 algorithm values must be accompanied by a reference to a standards-
1665 track or Informational RFC or a reference to published cryptographic
1666 literature which describes this algorithm. Due to the key derivation
1667 and key expansion uses of HMAC forms of hash algorithms in IKE,
1668 requests for assignment of new hash algorithm values must take into
1669 account the cryptographic properties-- e.g it's resistance to
1670 collision-- of the hash algorithm itself.
1672 11.4 Group Description and Group Type
1674 Values of the Group Description Class identify a group to use in a
1675 Diffie-Hellman exchange. Values of the Group Type Class define the
1676 type of group. Requests for assignment of new groups must be
1677 accompanied by a reference to a standards-track or Informational RFC
1678 which describes this group. Requests for assignment of new group
1682 Harkins & Carrel Standards Track [Page 30]
1683 \f
1684 RFC 2409 IKE November 1998
1687 types must be accompanied by a reference to a standards-track or
1688 Informational RFC or by a reference to published cryptographic or
1689 mathmatical literature which describes the new type.
1691 11.5 Life Type
1693 Values of the Life Type Class define a type of lifetime to which the
1694 ISAKMP Security Association applies. Requests for assignment of new
1695 life types must be accompanied by a detailed description of the units
1696 of this type and its expiry.
1698 12. Acknowledgements
1700 This document is the result of close consultation with Hugo Krawczyk,
1701 Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and
1702 Jeff Turner. It relies on protocols which were written by them.
1703 Without their interest and dedication, this would not have been
1704 written.
1706 Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis,
1707 and Elfed Weaver for technical input, encouragement, and various
1708 sanity checks along the way.
1710 We would also like to thank the many members of the IPSec working
1711 group that contributed to the development of this protocol over the
1712 past year.
1714 13. References
1716 [CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
1717 May 1997.
1719 [BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr.
1720 Dobb's Journal, v. 19, n. 4, April 1994.
1722 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
1723 Requirement Levels", BCP 14, RFC 2119, March 1997.
1725 [DES] ANSI X3.106, "American National Standard for Information
1726 Systems-Data Link Encryption", American National Standards
1727 Institute, 1983.
1729 [DH] Diffie, W., and Hellman M., "New Directions in
1730 Cryptography", IEEE Transactions on Information Theory, V.
1731 IT-22, n. 6, June 1977.
1738 Harkins & Carrel Standards Track [Page 31]
1739 \f
1740 RFC 2409 IKE November 1998
1743 [DSS] NIST, "Digital Signature Standard", FIPS 186, National
1744 Institute of Standards and Technology, U.S. Department of
1745 Commerce, May, 1994.
1747 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH
1748 Series in Information Processing, v. 1, Konstanz: Hartung-
1749 Gorre Verlag, 1992
1751 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
1752 Hashing for Message Authentication", RFC 2104, February
1753 1997.
1755 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
1756 Mechanism for Internet", from IEEE Proceedings of the 1996
1757 Symposium on Network and Distributed Systems Security.
1759 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
1760 April 1992.
1762 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
1763 "Internet Security Association and Key Management Protocol
1764 (ISAKMP)", RFC 2408, November 1998.
1766 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC
1767 2412, November 1998.
1769 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard",
1770 November 1993.
1772 [Pip98] Piper, D., "The Internet IP Security Domain Of
1773 Interpretation for ISAKMP", RFC 2407, November 1998.
1775 [RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's
1776 Journal, v. 20, n. 1, January 1995.
1778 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for
1779 Obtaining Digital Signatures and Public-Key Cryptosystems",
1780 Communications of the ACM, v. 21, n. 2, February 1978.
1782 [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms,
1783 and Source Code in C", 2nd edition.
1785 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institue
1786 of Standards and Technology, U.S. Department of Commerce,
1787 May 1994.
1789 [TIGER] Anderson, R., and Biham, E., "Fast Software Encryption",
1790 Springer LNCS v. 1039, 1996.
1794 Harkins & Carrel Standards Track [Page 32]
1795 \f
1796 RFC 2409 IKE November 1998
1799 Appendix A
1801 This is a list of DES Weak and Semi-Weak keys. The keys come from
1802 [Sch96]. All keys are listed in hexidecimal.
1804 DES Weak Keys
1805 0101 0101 0101 0101
1806 1F1F 1F1F E0E0 E0E0
1807 E0E0 E0E0 1F1F 1F1F
1808 FEFE FEFE FEFE FEFE
1810 DES Semi-Weak Keys
1811 01FE 01FE 01FE 01FE
1812 1FE0 1FE0 0EF1 0EF1
1813 01E0 01E0 01F1 01F1
1814 1FFE 1FFE 0EFE 0EFE
1815 011F 011F 010E 010E
1816 E0FE E0FE F1FE F1FE
1818 FE01 FE01 FE01 FE01
1819 E01F E01F F10E F10E
1820 E001 E001 F101 F101
1821 FE1F FE1F FE0E FE0E
1822 1F01 1F01 0E01 0E01
1823 FEE0 FEE0 FEF1 FEF1
1825 Attribute Assigned Numbers
1827 Attributes negotiated during phase one use the following definitions.
1828 Phase two attributes are defined in the applicable DOI specification
1829 (for example, IPsec attributes are defined in the IPsec DOI), with
1830 the exception of a group description when Quick Mode includes an
1831 ephemeral Diffie-Hellman exchange. Attribute types can be either
1832 Basic (B) or Variable-length (V). Encoding of these attributes is
1833 defined in the base ISAKMP specification as Type/Value (Basic) and
1834 Type/Length/Value (Variable).
1836 Attributes described as basic MUST NOT be encoded as variable.
1837 Variable length attributes MAY be encoded as basic attributes if
1838 their value can fit into two octets. If this is the case, an
1839 attribute offered as variable (or basic) by the initiator of this
1840 protocol MAY be returned to the initiator as a basic (or variable).
1850 Harkins & Carrel Standards Track [Page 33]
1851 \f
1852 RFC 2409 IKE November 1998
1855 Attribute Classes
1857 class value type
1858 -------------------------------------------------------------------
1859 Encryption Algorithm 1 B
1860 Hash Algorithm 2 B
1861 Authentication Method 3 B
1862 Group Description 4 B
1863 Group Type 5 B
1864 Group Prime/Irreducible Polynomial 6 V
1865 Group Generator One 7 V
1866 Group Generator Two 8 V
1867 Group Curve A 9 V
1868 Group Curve B 10 V
1869 Life Type 11 B
1870 Life Duration 12 V
1871 PRF 13 B
1872 Key Length 14 B
1873 Field Size 15 B
1874 Group Order 16 V
1876 values 17-16383 are reserved to IANA. Values 16384-32767 are for
1877 private use among mutually consenting parties.
1879 Class Values
1881 - Encryption Algorithm Defined In
1882 DES-CBC 1 RFC 2405
1883 IDEA-CBC 2
1884 Blowfish-CBC 3
1885 RC5-R16-B64-CBC 4
1886 3DES-CBC 5
1887 CAST-CBC 6
1889 values 7-65000 are reserved to IANA. Values 65001-65535 are for
1890 private use among mutually consenting parties.
1892 - Hash Algorithm Defined In
1893 MD5 1 RFC 1321
1894 SHA 2 FIPS 180-1
1895 Tiger 3 See Reference [TIGER]
1897 values 4-65000 are reserved to IANA. Values 65001-65535 are for
1898 private use among mutually consenting parties.
1906 Harkins & Carrel Standards Track [Page 34]
1907 \f
1908 RFC 2409 IKE November 1998
1911 - Authentication Method
1912 pre-shared key 1
1913 DSS signatures 2
1914 RSA signatures 3
1915 Encryption with RSA 4
1916 Revised encryption with RSA 5
1918 values 6-65000 are reserved to IANA. Values 65001-65535 are for
1919 private use among mutually consenting parties.
1921 - Group Description
1922 default 768-bit MODP group (section 6.1) 1
1924 alternate 1024-bit MODP group (section 6.2) 2
1926 EC2N group on GP[2^155] (section 6.3) 3
1928 EC2N group on GP[2^185] (section 6.4) 4
1930 values 5-32767 are reserved to IANA. Values 32768-65535 are for
1931 private use among mutually consenting parties.
1933 - Group Type
1934 MODP (modular exponentiation group) 1
1935 ECP (elliptic curve group over GF[P]) 2
1936 EC2N (elliptic curve group over GF[2^N]) 3
1938 values 4-65000 are reserved to IANA. Values 65001-65535 are for
1939 private use among mutually consenting parties.
1941 - Life Type
1942 seconds 1
1943 kilobytes 2
1945 values 3-65000 are reserved to IANA. Values 65001-65535 are for
1946 private use among mutually consenting parties. For a given "Life
1947 Type" the value of the "Life Duration" attribute defines the actual
1948 length of the SA life-- either a number of seconds, or a number of
1949 kbytes protected.
1951 - PRF
1952 There are currently no pseudo-random functions defined.
1954 values 1-65000 are reserved to IANA. Values 65001-65535 are for
1955 private use among mutually consenting parties.
1962 Harkins & Carrel Standards Track [Page 35]
1963 \f
1964 RFC 2409 IKE November 1998
1967 - Key Length
1969 When using an Encryption Algorithm that has a variable length key,
1970 this attribute specifies the key length in bits. (MUST use network
1971 byte order). This attribute MUST NOT be used when the specified
1972 Encryption Algorithm uses a fixed length key.
1974 - Field Size
1976 The field size, in bits, of a Diffie-Hellman group.
1978 - Group Order
1980 The group order of an elliptical curve group. Note the length of
1981 this attribute depends on the field size.
1983 Additional Exchanges Defined-- XCHG values
1984 Quick Mode 32
1985 New Group Mode 33
2018 Harkins & Carrel Standards Track [Page 36]
2019 \f
2020 RFC 2409 IKE November 1998
2023 Appendix B
2025 This appendix describes encryption details to be used ONLY when
2026 encrypting ISAKMP messages. When a service (such as an IPSEC
2027 transform) utilizes ISAKMP to generate keying material, all
2028 encryption algorithm specific details (such as key and IV generation,
2029 padding, etc...) MUST be defined by that service. ISAKMP does not
2030 purport to ever produce keys that are suitable for any encryption
2031 algorithm. ISAKMP produces the requested amount of keying material
2032 from which the service MUST generate a suitable key. Details, such
2033 as weak key checks, are the responsibility of the service.
2035 Use of negotiated PRFs may require the PRF output to be expanded due
2036 to the PRF feedback mechanism employed by this document. For example,
2037 if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces
2038 only 8 bytes of output, the output must be expanded three times
2039 before being used as the key for another instance of itself. The
2040 output of a PRF is expanded by feeding back the results of the PRF
2041 into itself to generate successive blocks. These blocks are
2042 concatenated until the requisite number of bytes has been acheived.
2043 For example, for pre-shared key authentication with DOORAK-MAC as the
2044 negotiated PRF:
2046 BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b)
2047 BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b)
2048 BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b)
2049 and
2050 SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
2052 so therefore to derive SKEYID_d:
2054 BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
2055 BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0)
2056 BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0)
2057 and
2058 SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
2060 Subsequent PRF derivations are done similarly.
2062 Encryption keys used to protect the ISAKMP SA are derived from
2063 SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long
2064 enough to supply all the necessary keying material an algorithm
2065 requires, the key is derived from feeding the results of a pseudo-
2066 random function into itself, concatenating the results, and taking
2067 the highest necessary bits.
2074 Harkins & Carrel Standards Track [Page 37]
2075 \f
2076 RFC 2409 IKE November 1998
2079 For example, if (ficticious) algorithm AKULA requires 320-bits of key
2080 (and has no weak key check) and the prf used to generate SKEYID_e
2081 only generates 120 bits of material, the key for AKULA, would be the
2082 first 320-bits of Ka, where:
2084 Ka = K1 | K2 | K3
2085 and
2086 K1 = prf(SKEYID_e, 0)
2087 K2 = prf(SKEYID_e, K1)
2088 K3 = prf(SKEYID_e, K2)
2090 where prf is the negotiated prf or the HMAC version of the negotiated
2091 hash function (if no prf was negotiated) and 0 is represented by a
2092 single octet. Each result of the prf provides 120 bits of material
2093 for a total of 360 bits. AKULA would use the first 320 bits of that
2094 360 bit string.
2096 In phase 1, material for the initialization vector (IV material) for
2097 CBC mode encryption algorithms is derived from a hash of a
2098 concatenation of the initiator's public Diffie-Hellman value and the
2099 responder's public Diffie-Hellman value using the negotiated hash
2100 algorithm. This is used for the first message only. Each message
2101 should be padded up to the nearest block size using bytes containing
2102 0x00. The message length in the header MUST include the length of the
2103 pad since this reflects the size of the ciphertext. Subsequent
2104 messages MUST use the last CBC encryption block from the previous
2105 message as their initialization vector.
2107 In phase 2, material for the initialization vector for CBC mode
2108 encryption of the first message of a Quick Mode exchange is derived
2109 from a hash of a concatenation of the last phase 1 CBC output block
2110 and the phase 2 message id using the negotiated hash algorithm. The
2111 IV for subsequent messages within a Quick Mode exchange is the CBC
2112 output block from the previous message. Padding and IVs for
2113 subsequent messages are done as in phase 1.
2115 After the ISAKMP SA has been authenticated all Informational
2116 Exchanges are encrypted using SKEYID_e. The initiaization vector for
2117 these exchanges is derived in exactly the same fashion as that for a
2118 Quick Mode-- i.e. it is derived from a hash of a concatenation of the
2119 last phase 1 CBC output block and the message id from the ISAKMP
2120 header of the Informational Exchange (not the message id from the
2121 message that may have prompted the Informational Exchange).
2123 Note that the final phase 1 CBC output block, the result of
2124 encryption/decryption of the last phase 1 message, must be retained
2125 in the ISAKMP SA state to allow for generation of unique IVs for each
2126 Quick Mode. Each post- phase 1 exchange (Quick Modes and
2130 Harkins & Carrel Standards Track [Page 38]
2131 \f
2132 RFC 2409 IKE November 1998
2135 Informational Exchanges) generates IVs independantly to prevent IVs
2136 from getting out of sync when two different exchanges are started
2137 simultaneously.
2139 In all cases, there is a single bidirectional cipher/IV context.
2140 Having each Quick Mode and Informational Exchange maintain a unique
2141 context prevents IVs from getting out of sync.
2143 The key for DES-CBC is derived from the first eight (8) non-weak and
2144 non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first
2145 8 bytes of the IV material derived above.
2147 The key for IDEA-CBC is derived from the first sixteen (16) bytes of
2148 SKEYID_e. The IV is the first eight (8) bytes of the IV material
2149 derived above.
2151 The key for Blowfish-CBC is either the negotiated key size, or the
2152 first fifty-six (56) bytes of a key (if no key size is negotiated)
2153 derived in the aforementioned pseudo-random function feedback method.
2154 The IV is the first eight (8) bytes of the IV material derived above.
2156 The key for RC5-R16-B64-CBC is the negotiated key size, or the first
2157 sixteen (16) bytes of a key (if no key size is negotiated) derived
2158 from the aforementioned pseudo-random function feedback method if
2159 necessary. The IV is the first eight (8) bytes of the IV material
2160 derived above. The number of rounds MUST be 16 and the block size
2161 MUST be 64.
2163 The key for 3DES-CBC is the first twenty-four (24) bytes of a key
2164 derived in the aforementioned pseudo-random function feedback method.
2165 3DES-CBC is an encrypt-decrypt-encrypt operation using the first,
2166 middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV
2167 is the first eight (8) bytes of the IV material derived above.
2169 The key for CAST-CBC is either the negotiated key size, or the first
2170 sixteen (16) bytes of a key derived in the aforementioned pseudo-
2171 random function feedback method. The IV is the first eight (8) bytes
2172 of the IV material derived above.
2174 Support for algorithms other than DES-CBC is purely optional. Some
2175 optional algorithms may be subject to intellectual property claims.
2186 Harkins & Carrel Standards Track [Page 39]
2187 \f
2188 RFC 2409 IKE November 1998
2191 Authors' Addresses
2193 Dan Harkins
2194 cisco Systems
2195 170 W. Tasman Dr.
2196 San Jose, California, 95134-1706
2197 United States of America
2199 Phone: +1 408 526 4000
2200 EMail: dharkins@cisco.com
2203 Dave Carrel
2204 76 Lippard Ave.
2205 San Francisco, CA 94131-2947
2206 United States of America
2208 Phone: +1 415 337 8469
2209 EMail: carrel@ipsec.org
2211 Authors' Note
2213 The authors encourage independent implementation, and
2214 interoperability testing, of this hybrid protocol.
2242 Harkins & Carrel Standards Track [Page 40]
2243 \f
2244 RFC 2409 IKE November 1998
2247 Full Copyright Statement
2249 Copyright (C) The Internet Society (1998). All Rights Reserved.
2251 This document and translations of it may be copied and furnished to
2252 others, and derivative works that comment on or otherwise explain it
2253 or assist in its implementation may be prepared, copied, published
2254 and distributed, in whole or in part, without restriction of any
2255 kind, provided that the above copyright notice and this paragraph are
2256 included on all such copies and derivative works. However, this
2257 document itself may not be modified in any way, such as by removing
2258 the copyright notice or references to the Internet Society or other
2259 Internet organizations, except as needed for the purpose of
2260 developing Internet standards in which case the procedures for
2261 copyrights defined in the Internet Standards process must be
2262 followed, or as required to translate it into languages other than
2263 English.
2265 The limited permissions granted above are perpetual and will not be
2266 revoked by the Internet Society or its successors or assigns.
2268 This document and the information contained herein is provided on an
2269 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2270 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2271 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2272 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2273 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2298 Harkins & Carrel Standards Track [Page 41]
2299 \f