- moved RFCs from ikev2 into doc dir
[strongswan.git] / doc / ikev2 / [RFC2409] - The Internet Key Exchange (IKE).txt
1
2
3
4
5
6
7 Network Working Group                                         D. Harkins
8 Request for Comments: 2409                                     D. Carrel
9 Category: Standards Track                                  cisco Systems
10                                                            November 1998
11
12
13                     The Internet Key Exchange (IKE)
14
15 Status of this Memo
16
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.
22
23 Copyright Notice
24
25    Copyright (C) The Internet Society (1998).  All Rights Reserved.
26
27 Table Of Contents
28
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
55
56
57
58 Harkins & Carrel            Standards Track                     [Page 1]
59 \f
60 RFC 2409                          IKE                      November 1998
61
62
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
72
73 1. Abstract
74
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.
79
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).
83
84    SKEME ([SKEME]) describes a versatile key exchange technique which
85    provides anonymity, repudiability, and quick key refreshment.
86
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.
91
92 2. Discussion
93
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.
97
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.
102
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.
107
108
109
110
111
112
113
114 Harkins & Carrel            Standards Track                     [Page 2]
115 \f
116 RFC 2409                          IKE                      November 1998
117
118
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.
123
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.
128
129 3. Terms and Definitions
130
131 3.1 Requirements Terminology
132
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].
136
137 3.2 Notation
138
139    The following notation is used throughout this memo.
140
141      HDR is an ISAKMP header whose exchange type is the mode.  When
142      writen as HDR* it indicates payload encryption.
143
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.
147
148      <P>_b indicates the body of payload <P>-- the ISAKMP generic
149      vpayload is not included.
150
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.
154
155      CKY-I and CKY-R are the Initiator's cookie and the Responder's
156      cookie, respectively, from the ISAKMP header.
157
158      g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the
159      initiator and responder respectively.
160
161      g^xy is the Diffie-Hellman shared secret.
162
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.
166
167
168
169
170 Harkins & Carrel            Standards Track                     [Page 3]
171 \f
172 RFC 2409                          IKE                      November 1998
173
174
175      Nx is the nonce payload; x can be: i or r for the ISAKMP initiator
176      and responder respectively.
177
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].
183
184      SIG is the signature payload. The data to sign is exchange-
185      specific.
186
187      CERT is the certificate payload.
188
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.
192
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]).
197
198      SKEYID is a string derived from secret material known only to the
199      active players in the exchange.
200
201      SKEYID_e is the keying material used by the ISAKMP SA to protect
202      the confidentiality of its messages.
203
204      SKEYID_a is the keying material used by the ISAKMP SA to
205      authenticate its messages.
206
207      SKEYID_d is the keying material used to derive keys for non-ISAKMP
208      security associations.
209
210      <x>y indicates that "x" is encrypted with the key "y".
211
212      --> signifies "initiator to responder" communication (requests).
213
214      <-- signifies "responder to initiator" communication (replies).
215
216       |  signifies concatenation of information-- e.g. X | Y is the
217      concatentation of X with Y.
218
219      [x] indicates that x is optional.
220
221
222
223
224
225
226 Harkins & Carrel            Standards Track                     [Page 4]
227 \f
228 RFC 2409                          IKE                      November 1998
229
230
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.
236
237 3.3 Perfect Forward Secrecy
238
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.
246
247    Perfect Forward Secrecy for both keys and identities is provided in
248    this protocol. (Sections 5.5 and 8).
249
250 3.4 Security Association
251
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.
256
257 4. Introduction
258
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.
263
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.
267
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.
273
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.
278
279
280
281
282 Harkins & Carrel            Standards Track                     [Page 5]
283 \f
284 RFC 2409                          IKE                      November 1998
285
286
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.
291
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.
302
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.
315
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.
329
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.)
335
336
337
338 Harkins & Carrel            Standards Track                     [Page 6]
339 \f
340 RFC 2409                          IKE                      November 1998
341
342
343       - encryption algorithm
344
345       - hash algorithm
346
347       - authentication method
348
349       - information about a group over which to do Diffie-Hellman.
350
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.
360
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).
368
369    IKE implementations MUST support the following attribute values:
370
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.
374
375       - MD5 [MD5] and SHA [SHA}.
376
377       - Authentication via pre-shared keys.
378
379       - MODP over default group number one (see below).
380
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.
387
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.
391
392
393
394 Harkins & Carrel            Standards Track                     [Page 7]
395 \f
396 RFC 2409                          IKE                      November 1998
397
398
399 5. Exchanges
400
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.
410
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.
416
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.
420
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.
425
426    The length of nonce payload MUST be between 8 and 256 bytes
427    inclusive.
428
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.
437
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
446
447
448
449
450 Harkins & Carrel            Standards Track                     [Page 8]
451 \f
452 RFC 2409                          IKE                      November 1998
453
454
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.
458
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.
462
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.
472
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.
475
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.
486
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.
490
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.
497
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.
502
503
504
505
506 Harkins & Carrel            Standards Track                     [Page 9]
507 \f
508 RFC 2409                          IKE                      November 1998
509
510
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)
516
517    The result of either Main Mode or Aggressive Mode is three groups of
518    authenticated keying material:
519
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)
523
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).
528
529    To authenticate either exchange the initiator of the protocol
530    generates HASH_I and the responder generates HASH_R where:
531
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 )
534
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.
541
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.
548
549 5.1 IKE Phase 1 Authenticated With Signatures
550
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:
555
556
557
558
559
560
561
562 Harkins & Carrel            Standards Track                    [Page 10]
563 \f
564 RFC 2409                          IKE                      November 1998
565
566
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
575
576    Aggressive mode with signatures in conjunction with ISAKMP is
577    described as follows:
578
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        -->
585
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.
589
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.
600
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.
608
609    One or more certificate payloads MAY be optionally passed.
610
611
612
613
614
615
616
617
618 Harkins & Carrel            Standards Track                    [Page 11]
619 \f
620 RFC 2409                          IKE                      November 1998
621
622
623 5.2 Phase 1 Authenticated With Public Key Encryption
624
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.
629
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.
637
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.
644
645    When using encryption for authentication, Main Mode is defined as
646    follows.
647
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
659
660    Aggressive Mode authenticated with encryption is described as
661    follows:
662
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               -->
671
672
673
674 Harkins & Carrel            Standards Track                    [Page 12]
675 \f
676 RFC 2409                          IKE                      November 1998
677
678
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.
682
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.
689
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].
697
698    Note that, unlike other authentication methods, authentication with
699    public key encryption allows for identity protection with Aggressive
700    Mode.
701
702 5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption
703
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.
711
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.
721
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
727
728
729
730 Harkins & Carrel            Standards Track                    [Page 13]
731 \f
732 RFC 2409                          IKE                      November 1998
733
734
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.
741
742    When using the revised encryption mode for authentication, Main Mode
743    is defined as follows.
744
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
759
760    Aggressive Mode authenticated with the revised encryption method is
761    described as follows:
762
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               -->
773
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.
780
781    The symmetric cipher keys are derived from the decrypted nonces as
782    follows.  First the values Ne_i and Ne_r are computed:
783
784
785
786 Harkins & Carrel            Standards Track                    [Page 14]
787 \f
788 RFC 2409                          IKE                      November 1998
789
790
791       Ne_i = prf(Ni_b, CKY-I)
792       Ne_r = prf(Nr_b, CKY-R)
793
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
807
808       K = K1 | K2 | K3 and
809       K1 = prf(Ne_i, 0)
810       K2 = prf(Ne_i, K1)
811       K3 = prf(Ne_i, K2)
812
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.
817
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.
823
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.
834
835
836
837
838
839
840
841
842 Harkins & Carrel            Standards Track                    [Page 15]
843 \f
844 RFC 2409                          IKE                      November 1998
845
846
847 5.4 Phase 1 Authenticated With a Pre-Shared Key
848
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.
852
853    When doing a pre-shared key authentication, Main Mode is defined as
854    follows:
855
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
864
865    Aggressive mode with a pre-shared key is described as follows:
866
867             Initiator                        Responder
868            -----------                      -----------
869             HDR, SA, KE, Ni, IDii -->
870                                   <--    HDR, SA, KE, Nr, IDir, HASH_R
871             HDR, HASH_I           -->
872
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.
880
881 5.5 Phase 2 - Quick Mode
882
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.
892
893
894
895
896
897
898 Harkins & Carrel            Standards Track                    [Page 16]
899 \f
900 RFC 2409                          IKE                      November 1998
901
902
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.
909
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.
917
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.
923
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.
934
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.
939
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.
946
947    Quick Mode is defined as follows:
948
949
950
951
952
953
954 Harkins & Carrel            Standards Track                    [Page 17]
955 \f
956 RFC 2409                          IKE                      November 1998
957
958
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)             -->
966
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:
979
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)
984
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.
991
992    If PFS is not needed, and KE payloads are not exchanged, the new
993    keying material is defined as
994
995        KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).
996
997    If PFS is desired and KE payloads were exchanged, the new keying
998    material is defined as
999
1000        KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
1001
1002    where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman
1003    exchange of this Quick Mode.
1004
1005    In either case, "protocol" and "SPI" are from the ISAKMP Proposal
1006    Payload that contained the negotiated Transform.
1007
1008
1009
1010 Harkins & Carrel            Standards Track                    [Page 18]
1011 \f
1012 RFC 2409                          IKE                      November 1998
1013
1014
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.
1020
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,
1025
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.
1034
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.
1039
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.
1045
1046    Using Quick Mode, multiple SA's and keys can be negotiated with one
1047    exchange as follows:
1048
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)             -->
1056
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.
1060
1061
1062
1063
1064
1065
1066 Harkins & Carrel            Standards Track                    [Page 19]
1067 \f
1068 RFC 2409                          IKE                      November 1998
1069
1070
1071 5.6 New Group Mode
1072
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).
1076
1077         Initiator                        Responder
1078        -----------                      -----------
1079         HDR*, HASH(1), SA        -->
1080                                  <--     HDR*, HASH(2), SA
1081
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:
1088
1089       HASH(1) = prf(SKEYID_a, M-ID | SA)
1090       HASH(2) = prf(SKEYID_a, M-ID | SA)
1091
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).
1097
1098    ISAKMP implementations MAY require private groups to expire with the
1099    SA under which they were established.
1100
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.
1109
1110 5.7 ISAKMP Informational Exchanges
1111
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:
1116
1117
1118
1119
1120
1121
1122 Harkins & Carrel            Standards Track                    [Page 20]
1123 \f
1124 RFC 2409                          IKE                      November 1998
1125
1126
1127         Initiator                        Responder
1128        -----------                      -----------
1129         HDR*, HASH(1), N/D      -->
1130
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:
1136
1137       HASH(1) = prf(SKEYID_a, M-ID | N/D)
1138
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.
1145
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.
1149
1150 6 Oakley Groups
1151
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.
1159
1160    These groups were all generated by Richard Schroeppel at the
1161    University of Arizona. Properties of these groups are described in
1162    [Orm96].
1163
1164 6.1 First Oakley Default Group
1165
1166    Oakley implementations MUST support a MODP group with the following
1167    prime and generator. This group is assigned id 1 (one).
1168
1169       The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
1170       Its hexadecimal value is
1171
1172
1173
1174
1175
1176
1177
1178 Harkins & Carrel            Standards Track                    [Page 21]
1179 \f
1180 RFC 2409                          IKE                      November 1998
1181
1182
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
1187
1188       The generator is: 2.
1189
1190 6.2 Second Oakley Group
1191
1192    IKE implementations SHOULD support a MODP group with the following
1193    prime and generator. This group is assigned id 2 (two).
1194
1195    The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
1196    Its hexadecimal value is
1197
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
1204
1205    The generator is 2 (decimal)
1206
1207 6.3 Third Oakley Group
1208
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.
1216
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
1223
1224    Group Order: 0X0800000000000000000057db5698537193aef944
1225
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
1231
1232
1233
1234 Harkins & Carrel            Standards Track                    [Page 22]
1235 \f
1236 RFC 2409                          IKE                      November 1998
1237
1238
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).
1244
1245 6.4 Fourth Oakley Group
1246
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.
1254
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
1261
1262    Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc
1263
1264    The data in the KE payload when using this group will be identical to
1265    that as when using Oakley Group 3 (three).
1266
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].
1270
1271 7. Payload Explosion for a Complete IKE Exchange
1272
1273    This section illustrates how the IKE protocol is used to:
1274
1275       - establish a secure and authenticated channel between ISAKMP
1276       processes (phase 1); and
1277
1278       - generate key material for, and negotiate, an IPsec SA (phase 2).
1279
1280 7.1 Phase 1 using Main Mode
1281
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.
1285
1286
1287
1288
1289
1290 Harkins & Carrel            Standards Track                    [Page 23]
1291 \f
1292 RFC 2409                          IKE                      November 1998
1293
1294
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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1322
1323    The responder replies in kind but selects, and returns, one transform
1324    proposal (the ISAKMP SA attributes).
1325
1326    The second exchange consists of the following payloads:
1327
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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1341
1342
1343
1344
1345
1346 Harkins & Carrel            Standards Track                    [Page 24]
1347 \f
1348 RFC 2409                          IKE                      November 1998
1349
1350
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.
1354
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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1368
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).
1374
1375 7.2 Phase 2 using Quick Mode
1376
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.
1381
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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1399
1400
1401
1402 Harkins & Carrel            Standards Track                    [Page 25]
1403 \f
1404 RFC 2409                          IKE                      November 1998
1405
1406
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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1435
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.
1442
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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1452
1453    where the contents of the hash are described in 5.5 above.
1454
1455
1456
1457
1458 Harkins & Carrel            Standards Track                    [Page 26]
1459 \f
1460 RFC 2409                          IKE                      November 1998
1461
1462
1463 8. Perfect Forward Secrecy Example
1464
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.
1469
1470    To provide Perfect Forward Secrecy of both keys and all identities,
1471    two parties would perform the following:
1472
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.
1480
1481    Since the key for use in the non-ISAKMP SA was derived from the
1482    single ephemeral Diffie-Hellman exchange PFS is preserved.
1483
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.
1491
1492 9. Implementation Hints
1493
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.
1501
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.
1509
1510
1511
1512
1513
1514 Harkins & Carrel            Standards Track                    [Page 27]
1515 \f
1516 RFC 2409                          IKE                      November 1998
1517
1518
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.
1526
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.
1531
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.
1541
1542 10. Security Considerations
1543
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.
1548
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.
1555
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.
1560
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
1567
1568
1569
1570 Harkins & Carrel            Standards Track                    [Page 28]
1571 \f
1572 RFC 2409                          IKE                      November 1998
1573
1574
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.
1582
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.
1594
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.
1601
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.
1607
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.
1612
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.
1621
1622
1623
1624
1625
1626 Harkins & Carrel            Standards Track                    [Page 29]
1627 \f
1628 RFC 2409                          IKE                      November 1998
1629
1630
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.
1639
1640 11. IANA Considerations
1641
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.
1645
1646 11.1 Attribute Classes
1647
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.
1651
1652 11.2 Encryption Algorithm Class
1653
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.
1659
1660 11.3 Hash Algorithm
1661
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.
1671
1672 11.4 Group Description and Group Type
1673
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
1679
1680
1681
1682 Harkins & Carrel            Standards Track                    [Page 30]
1683 \f
1684 RFC 2409                          IKE                      November 1998
1685
1686
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.
1690
1691 11.5 Life Type
1692
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.
1697
1698 12. Acknowledgements
1699
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.
1705
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.
1709
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.
1713
1714 13. References
1715
1716    [CAST]   Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
1717             May 1997.
1718
1719    [BLOW]   Schneier, B., "The Blowfish Encryption Algorithm", Dr.
1720             Dobb's Journal, v. 19, n. 4, April 1994.
1721
1722    [Bra97]  Bradner, S., "Key Words for use in RFCs to indicate
1723             Requirement Levels", BCP 14, RFC 2119, March 1997.
1724
1725    [DES]    ANSI X3.106, "American National Standard for Information
1726             Systems-Data Link Encryption", American National Standards
1727             Institute, 1983.
1728
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.
1732
1733
1734
1735
1736
1737
1738 Harkins & Carrel            Standards Track                    [Page 31]
1739 \f
1740 RFC 2409                          IKE                      November 1998
1741
1742
1743    [DSS]    NIST, "Digital Signature Standard", FIPS 186, National
1744             Institute of Standards and Technology, U.S. Department of
1745             Commerce, May, 1994.
1746
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
1750
1751    [KBC96]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
1752             Hashing for Message Authentication", RFC 2104, February
1753             1997.
1754
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.
1758
1759    [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
1760             April 1992.
1761
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.
1765
1766    [Orm96]  Orman, H., "The Oakley Key Determination Protocol", RFC
1767             2412, November 1998.
1768
1769    [PKCS1]  RSA Laboratories, "PKCS #1: RSA Encryption Standard",
1770             November 1993.
1771
1772    [Pip98]  Piper, D., "The Internet IP Security Domain Of
1773             Interpretation for ISAKMP", RFC 2407, November 1998.
1774
1775    [RC5]    Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's
1776             Journal, v. 20, n. 1, January 1995.
1777
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.
1781
1782    [Sch96]  Schneier, B., "Applied Cryptography, Protocols, Algorithms,
1783             and Source Code in C", 2nd edition.
1784
1785    [SHA]    NIST, "Secure Hash Standard", FIPS 180-1, National Institue
1786             of Standards and Technology, U.S. Department of Commerce,
1787             May 1994.
1788
1789    [TIGER]  Anderson, R., and Biham, E., "Fast Software Encryption",
1790             Springer LNCS v. 1039, 1996.
1791
1792
1793
1794 Harkins & Carrel            Standards Track                    [Page 32]
1795 \f
1796 RFC 2409                          IKE                      November 1998
1797
1798
1799 Appendix A
1800
1801    This is a list of DES Weak and Semi-Weak keys.  The keys come from
1802    [Sch96].  All keys are listed in hexidecimal.
1803
1804        DES Weak Keys
1805        0101 0101 0101 0101
1806        1F1F 1F1F E0E0 E0E0
1807        E0E0 E0E0 1F1F 1F1F
1808        FEFE FEFE FEFE FEFE
1809
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
1817
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
1824
1825    Attribute Assigned Numbers
1826
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).
1835
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).
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850 Harkins & Carrel            Standards Track                    [Page 33]
1851 \f
1852 RFC 2409                          IKE                      November 1998
1853
1854
1855    Attribute Classes
1856
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
1875
1876    values 17-16383 are reserved to IANA. Values 16384-32767 are for
1877    private use among mutually consenting parties.
1878
1879    Class Values
1880
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
1888
1889      values 7-65000 are reserved to IANA. Values 65001-65535 are for
1890      private use among mutually consenting parties.
1891
1892    - Hash Algorithm                             Defined In
1893       MD5                                 1     RFC 1321
1894       SHA                                 2     FIPS 180-1
1895       Tiger                               3     See Reference [TIGER]
1896
1897      values 4-65000 are reserved to IANA. Values 65001-65535 are for
1898      private use among mutually consenting parties.
1899
1900
1901
1902
1903
1904
1905
1906 Harkins & Carrel            Standards Track                    [Page 34]
1907 \f
1908 RFC 2409                          IKE                      November 1998
1909
1910
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
1917
1918      values 6-65000 are reserved to IANA. Values 65001-65535 are for
1919      private use among mutually consenting parties.
1920
1921    - Group Description
1922       default 768-bit MODP group (section 6.1)      1
1923
1924       alternate 1024-bit MODP group (section 6.2)   2
1925
1926       EC2N group on GP[2^155] (section 6.3)         3
1927
1928       EC2N group on GP[2^185] (section 6.4)         4
1929
1930      values 5-32767 are reserved to IANA. Values 32768-65535 are for
1931      private use among mutually consenting parties.
1932
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
1937
1938      values 4-65000 are reserved to IANA. Values 65001-65535 are for
1939      private use among mutually consenting parties.
1940
1941    - Life Type
1942       seconds                             1
1943       kilobytes                           2
1944
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.
1950
1951    - PRF
1952      There are currently no pseudo-random functions defined.
1953
1954      values 1-65000 are reserved to IANA. Values 65001-65535 are for
1955      private use among mutually consenting parties.
1956
1957
1958
1959
1960
1961
1962 Harkins & Carrel            Standards Track                    [Page 35]
1963 \f
1964 RFC 2409                          IKE                      November 1998
1965
1966
1967    - Key Length
1968
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.
1973
1974    - Field Size
1975
1976      The field size, in bits, of a Diffie-Hellman group.
1977
1978    - Group Order
1979
1980      The group order of an elliptical curve group. Note the length of
1981      this attribute depends on the field size.
1982
1983    Additional Exchanges Defined-- XCHG values
1984      Quick Mode                         32
1985      New Group Mode                     33
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018 Harkins & Carrel            Standards Track                    [Page 36]
2019 \f
2020 RFC 2409                          IKE                      November 1998
2021
2022
2023 Appendix B
2024
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.
2034
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:
2045
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
2051
2052    so therefore to derive SKEYID_d:
2053
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
2059
2060    Subsequent PRF derivations are done similarly.
2061
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.
2068
2069
2070
2071
2072
2073
2074 Harkins & Carrel            Standards Track                    [Page 37]
2075 \f
2076 RFC 2409                          IKE                      November 1998
2077
2078
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:
2083
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)
2089
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.
2095
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.
2106
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.
2114
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).
2122
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
2127
2128
2129
2130 Harkins & Carrel            Standards Track                    [Page 38]
2131 \f
2132 RFC 2409                          IKE                      November 1998
2133
2134
2135    Informational Exchanges) generates IVs independantly to prevent IVs
2136    from getting out of sync when two different exchanges are started
2137    simultaneously.
2138
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.
2142
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.
2146
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.
2150
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.
2155
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.
2162
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.
2168
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.
2173
2174    Support for algorithms other than DES-CBC is purely optional. Some
2175    optional algorithms may be subject to intellectual property claims.
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186 Harkins & Carrel            Standards Track                    [Page 39]
2187 \f
2188 RFC 2409                          IKE                      November 1998
2189
2190
2191 Authors' Addresses
2192
2193    Dan Harkins
2194    cisco Systems
2195    170 W. Tasman Dr.
2196    San Jose, California, 95134-1706
2197    United States of America
2198
2199    Phone: +1 408 526 4000
2200    EMail: dharkins@cisco.com
2201
2202
2203    Dave Carrel
2204    76 Lippard Ave.
2205    San Francisco, CA 94131-2947
2206    United States of America
2207
2208    Phone: +1 415 337 8469
2209    EMail: carrel@ipsec.org
2210
2211 Authors' Note
2212
2213    The authors encourage independent implementation, and
2214    interoperability testing, of this hybrid protocol.
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242 Harkins & Carrel            Standards Track                    [Page 40]
2243 \f
2244 RFC 2409                          IKE                      November 1998
2245
2246
2247 Full Copyright Statement
2248
2249    Copyright (C) The Internet Society (1998).  All Rights Reserved.
2250
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.
2264
2265    The limited permissions granted above are perpetual and will not be
2266    revoked by the Internet Society or its successors or assigns.
2267
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.
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298 Harkins & Carrel            Standards Track                    [Page 41]
2299 \f