- moved RFCs from ikev2 into doc dir
[strongswan.git] / doc / ikev2 / [RFC2407] - The Internet IP Security Domain of Interpretation for ISAKMP.txt
1
2
3
4
5
6
7 Network Working Group                                           D. Piper
8 Request for Comments: 2407                               Network Alchemy
9 Category: Standards Track                                  November 1998
10
11
12       The Internet IP Security Domain of Interpretation for ISAKMP
13
14 Status of this Memo
15
16    This document specifies an Internet standards track protocol for the
17    Internet community, and requests discussion and suggestions for
18    improvements.  Please refer to the current edition of the "Internet
19    Official Protocol Standards" (STD 1) for the standardization state
20    and status of this protocol.  Distribution of this memo is unlimited.
21
22 Copyright Notice
23
24    Copyright (C) The Internet Society (1998).  All Rights Reserved.
25
26 IESG Note
27
28    Section 4.4.4.2 states, "All implememtations within the IPSEC DOI
29    MUST support ESP_DES...".  Recent work in the area of cryptanalysis
30    suggests that DES may not be sufficiently strong for many
31    applications.  Therefore, it is very likely that the IETF will
32    deprecate the use of ESP_DES as a mandatory cipher suite in the near
33    future.  It will remain as an optional use protocol.  Although the
34    IPsec working group and the IETF in general have not settled on an
35    alternative algorithm (taking into account concerns of security and
36    performance), implementers may want to heed the recommendations of
37    section 4.4.4.3 on the use of ESP_3DES.
38
39 1. Abstract
40
41    The Internet Security Association and Key Management Protocol
42    (ISAKMP) defines a framework for security association management and
43    cryptographic key establishment for the Internet.  This framework
44    consists of defined exchanges, payloads, and processing guidelines
45    that occur within a given Domain of Interpretation (DOI).  This
46    document defines the Internet IP Security DOI (IPSEC DOI), which
47    instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate
48    security associations.
49
50    For a list of changes since the previous version of the IPSEC DOI,
51    please see Section 7.
52
53
54
55
56
57
58 Piper                       Standards Track                     [Page 1]
59 \f
60 RFC 2407          IP Security Domain of Interpretation     November 1998
61
62
63 2. Introduction
64
65    Within ISAKMP, a Domain of Interpretation is used to group related
66    protocols using ISAKMP to negotiate security associations.  Security
67    protocols sharing a DOI choose security protocol and cryptographic
68    transforms from a common namespace and share key exchange protocol
69    identifiers.  They also share a common interpretation of DOI-specific
70    payload data content, including the Security Association and
71    Identification payloads.
72
73    Overall, ISAKMP places the following requirements on a DOI
74    definition:
75
76      o  define the naming scheme for DOI-specific protocol identifiers
77      o  define the interpretation for the Situation field
78      o  define the set of applicable security policies
79      o  define the syntax for DOI-specific SA Attributes (Phase II)
80      o  define the syntax for DOI-specific payload contents
81      o  define additional Key Exchange types, if needed
82      o  define additional Notification Message types, if needed
83
84    The remainder of this document details the instantiation of these
85    requirements for using the IP Security (IPSEC) protocols to provide
86    authentication, integrity, and/or confidentiality for IP packets sent
87    between cooperating host systems and/or firewalls.
88
89    For a description of the overall IPSEC architecture, see [ARCH],
90    [AH], and [ESP].
91
92 3. Terms and Definitions
93
94    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
95    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
96    document, are to be interpreted as described in [RFC 2119].
97
98 4.1 IPSEC Naming Scheme
99
100    Within ISAKMP, all DOI's must be registered with the IANA in the
101    "Assigned Numbers" RFC [STD-2].  The IANA Assigned Number for the
102    Internet IP Security DOI (IPSEC DOI) is one (1).  Within the IPSEC
103    DOI, all well-known identifiers MUST be registered with the IANA
104    under the IPSEC DOI.  Unless otherwise noted, all tables within this
105    document refer to IANA Assigned Numbers for the IPSEC DOI.  See
106    Section 6 for further information relating to the IANA registry for
107    the IPSEC DOI.
108
109    All multi-octet binary values are stored in network byte order.
110
111
112
113
114 Piper                       Standards Track                     [Page 2]
115 \f
116 RFC 2407          IP Security Domain of Interpretation     November 1998
117
118
119 4.2 IPSEC Situation Definition
120
121    Within ISAKMP, the Situation provides information that can be used by
122    the responder to make a policy determination about how to process the
123    incoming Security Association request.  For the IPSEC DOI, the
124    Situation field is a four (4) octet bitmask with the following
125    values.
126
127        Situation                   Value
128        ---------                   -----
129        SIT_IDENTITY_ONLY           0x01
130        SIT_SECRECY                 0x02
131        SIT_INTEGRITY               0x04
132
133 4.2.1 SIT_IDENTITY_ONLY
134
135    The SIT_IDENTITY_ONLY type specifies that the security association
136    will be identified by source identity information present in an
137    associated Identification Payload.  See Section 4.6.2 for a complete
138    description of the various Identification types.  All IPSEC DOI
139    implementations MUST support SIT_IDENTITY_ONLY by including an
140    Identification Payload in at least one of the Phase I Oakley
141    exchanges ([IKE], Section 5) and MUST abort any association setup
142    that does not include an Identification Payload.
143
144    If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the
145    situation consists only of the 4 octet situation bitmap and does not
146    include the Labeled Domain Identifier field (Figure 1, Section 4.6.1)
147    or any subsequent label information.  Conversely, if the initiator
148    supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain
149    Identifier MUST be included in the situation payload.
150
151 4.2.2 SIT_SECRECY
152
153    The SIT_SECRECY type specifies that the security association is being
154    negotiated in an environment that requires labeled secrecy.  If
155    SIT_SECRECY is present in the Situation bitmap, the Situation field
156    will be followed by variable-length data that includes a sensitivity
157    level and compartment bitmask.  See Section 4.6.1 for a complete
158    description of the Security Association Payload format.
159
160    If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be
161    set in the Situation bitmap and no secrecy level or category bitmaps
162    shall be included.
163
164    If a responder does not support SIT_SECRECY, a SITUATION-NOT-
165    SUPPORTED Notification Payload SHOULD be returned and the security
166    association setup MUST be aborted.
167
168
169
170 Piper                       Standards Track                     [Page 3]
171 \f
172 RFC 2407          IP Security Domain of Interpretation     November 1998
173
174
175 4.2.3 SIT_INTEGRITY
176
177    The SIT_INTEGRITY type specifies that the security association is
178    being negotiated in an environment that requires labeled integrity.
179    If SIT_INTEGRITY is present in the Situation bitmap, the Situation
180    field will be followed by variable-length data that includes an
181    integrity level and compartment bitmask.  If SIT_SECRECY is also in
182    use for the association, the integrity information immediately
183    follows the variable-length secrecy level and categories.  See
184    section 4.6.1 for a complete description of the Security Association
185    Payload format.
186
187    If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST
188    NOT be set in the Situation bitmap and no integrity level or category
189    bitmaps shall be included.
190
191    If a responder does not support SIT_INTEGRITY, a SITUATION-NOT-
192    SUPPORTED Notification Payload SHOULD be returned and the security
193    association setup MUST be aborted.
194
195 4.3 IPSEC Security Policy Requirements
196
197    The IPSEC DOI does not impose specific security policy requirements
198    on any implementation.  Host system policy issues are outside of the
199    scope of this document.
200
201    However, the following sections touch on some of the issues that must
202    be considered when designing an IPSEC DOI host implementation.  This
203    section should be considered only informational in nature.
204
205 4.3.1 Key Management Issues
206
207    It is expected that many systems choosing to implement ISAKMP will
208    strive to provide a protected domain of execution for a combined IKE
209    key management daemon.  On protected-mode multiuser operating
210    systems, this key management daemon will likely exist as a separate
211    privileged process.
212
213    In such an environment, a formalized API to introduce keying material
214    into the TCP/IP kernel may be desirable.  The IP Security
215    architecture does not place any requirements for structure or flow
216    between a host TCP/IP kernel and its key management provider.
217
218
219
220
221
222
223
224
225
226 Piper                       Standards Track                     [Page 4]
227 \f
228 RFC 2407          IP Security Domain of Interpretation     November 1998
229
230
231 4.3.2 Static Keying Issues
232
233    Host systems that implement static keys, either for use directly by
234    IPSEC, or for authentication purposes (see [IKE] Section 5.4), should
235    take steps to protect the static keying material when it is not
236    residing in a protected memory domain or actively in use by the
237    TCP/IP kernel.
238
239    For example, on a laptop, one might choose to store the static keys
240    in a configuration store that is, itself, encrypted under a private
241    password.
242
243    Depending on the operating system and utility software installed, it
244    may not be possible to protect the static keys once they've been
245    loaded into the TCP/IP kernel, however they should not be trivially
246    recoverable on initial system startup without having to satisfy some
247    additional form of authentication.
248
249 4.3.3 Host Policy Issues
250
251    It is not realistic to assume that the transition to IPSEC will occur
252    overnight.  Host systems must be prepared to implement flexible
253    policy lists that describe which systems they desire to speak
254    securely with and which systems they require speak securely to them.
255    Some notion of proxy firewall addresses may also be required.
256
257    A minimal approach is probably a static list of IP addresses, network
258    masks, and a security required flag or flags.
259
260    A more flexible implementation might consist of a list of wildcard
261    DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional
262    firewall address.  The wildcard DNS name would be used to match
263    incoming or outgoing IP addresses, the in/out bitmask would be used
264    to determine whether or not security was to be applied and in which
265    direction, and the optional firewall address would be used to
266    indicate whether or not tunnel mode would be needed to talk to the
267    target system though an intermediate firewall.
268
269 4.3.4 Certificate Management
270
271    Host systems implementing a certificate-based authentication scheme
272    will need a mechanism for obtaining and managing a database of
273    certificates.
274
275    Secure DNS is to be one certificate distribution mechanism, however
276    the pervasive availability of secure DNS zones, in the short term, is
277    doubtful for many reasons.  What's far more likely is that hosts will
278
279
280
281
282 Piper                       Standards Track                     [Page 5]
283 \f
284 RFC 2407          IP Security Domain of Interpretation     November 1998
285
286
287    need an ability to import certificates that they acquire through
288    secure, out-of-band mechanisms, as well as an ability to export their
289    own certificates for use by other systems.
290
291    However, manual certificate management should not be done so as to
292    preclude the ability to introduce dynamic certificate discovery
293    mechanisms and/or protocols as they become available.
294
295 4.4 IPSEC Assigned Numbers
296
297    The following sections list the Assigned Numbers for the IPSEC DOI:
298    Situation Identifiers, Protocol Identifiers, Transform Identifiers,
299    AH, ESP, and IPCOMP Transform Identifiers, Security Association
300    Attribute Type Values, Labeled Domain Identifiers, ID Payload Type
301    Values, and Notify Message Type Values.
302
303 4.4.1 IPSEC Security Protocol Identifier
304
305    The ISAKMP proposal syntax was specifically designed to allow for the
306    simultaneous negotiation of multiple Phase II security protocol
307    suites within a single negotiation.  As a result, the protocol suites
308    listed below form the set of protocols that can be negotiated at the
309    same time.  It is a host policy decision as to what protocol suites
310    might be negotiated together.
311
312    The following table lists the values for the Security Protocol
313    Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
314    DOI.
315
316        Protocol ID                         Value
317        -----------                         -----
318        RESERVED                            0
319        PROTO_ISAKMP                        1
320        PROTO_IPSEC_AH                      2
321        PROTO_IPSEC_ESP                     3
322        PROTO_IPCOMP                        4
323
324 4.4.1.1 PROTO_ISAKMP
325
326    The PROTO_ISAKMP type specifies message protection required during
327    Phase I of the ISAKMP protocol.  The specific protection mechanism
328    used for the IPSEC DOI is described in [IKE].  All implementations
329    within the IPSEC DOI MUST support PROTO_ISAKMP.
330
331    NB: ISAKMP reserves the value one (1) across all DOI definitions.
332
333
334
335
336
337
338 Piper                       Standards Track                     [Page 6]
339 \f
340 RFC 2407          IP Security Domain of Interpretation     November 1998
341
342
343 4.4.1.2 PROTO_IPSEC_AH
344
345    The PROTO_IPSEC_AH type specifies IP packet authentication.  The
346    default AH transform provides data origin authentication, integrity
347    protection, and replay detection.  For export control considerations,
348    confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform.
349
350 4.4.1.3 PROTO_IPSEC_ESP
351
352    The PROTO_IPSEC_ESP type specifies IP packet confidentiality.
353    Authentication, if required, must be provided as part of the ESP
354    transform.  The default ESP transform includes data origin
355    authentication, integrity protection, replay detection, and
356    confidentiality.
357
358 4.4.1.4 PROTO_IPCOMP
359
360    The PROTO_IPCOMP type specifies IP payload compression as defined in
361    [IPCOMP].
362
363 4.4.2 IPSEC ISAKMP Transform Identifiers
364
365    As part of an ISAKMP Phase I negotiation, the initiator's choice of
366    Key Exchange offerings is made using some host system policy
367    description.  The actual selection of Key Exchange mechanism is made
368    using the standard ISAKMP Proposal Payload.  The following table
369    lists the defined ISAKMP Phase I Transform Identifiers for the
370    Proposal Payload for the IPSEC DOI.
371
372        Transform                           Value
373        ---------                           -----
374        RESERVED                            0
375        KEY_IKE                             1
376
377    Within the ISAKMP and IPSEC DOI framework it is possible to define
378    key establishment protocols other than IKE (Oakley).  Previous
379    versions of this document defined types both for manual keying and
380    for schemes based on use of a generic Key Distribution Center (KDC).
381    These identifiers have been removed from the current document.
382
383    The IPSEC DOI can still be extended later to include values for
384    additional non-Oakley key establishment protocols for ISAKMP and
385    IPSEC, such as Kerberos [RFC-1510] or the Group Key Management
386    Protocol (GKMP) [RFC-2093].
387
388
389
390
391
392
393
394 Piper                       Standards Track                     [Page 7]
395 \f
396 RFC 2407          IP Security Domain of Interpretation     November 1998
397
398
399 4.4.2.1 KEY_IKE
400
401    The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
402    key exchange (IKE) as defined in the [IKE] document.  All
403    implementations within the IPSEC DOI MUST support KEY_IKE.
404
405 4.4.3 IPSEC AH Transform Identifiers
406
407    The Authentication Header Protocol (AH) defines one mandatory and
408    several optional transforms used to provide authentication,
409    integrity, and replay detection.  The following table lists the
410    defined AH Transform Identifiers for the ISAKMP Proposal Payload for
411    the IPSEC DOI.
412
413    Note: the Authentication Algorithm attribute MUST be specified to
414    identify the appropriate AH protection suite.  For example, AH_MD5
415    can best be thought of as a generic AH transform using MD5.  To
416    request the HMAC construction with AH, one specifies the AH_MD5
417    transform ID along with the Authentication Algorithm attribute set to
418    HMAC-MD5.  This is shown using the "Auth(HMAC-MD5)" notation in the
419    following sections.
420
421        Transform ID                        Value
422        ------------                        -----
423        RESERVED                            0-1
424        AH_MD5                              2
425        AH_SHA                              3
426        AH_DES                              4
427
428    Note: all mandatory-to-implement algorithms are listed as "MUST"
429    implement (e.g. AH_MD5) in the following sections.  All other
430    algorithms are optional and MAY be implemented in any particular
431    implementation.
432
433 4.4.3.1 AH_MD5
434
435    The AH_MD5 type specifies a generic AH transform using MD5.  The
436    actual protection suite is determined in concert with an associated
437    SA attribute list.  A generic MD5 transform is currently undefined.
438
439    All implementations within the IPSEC DOI MUST support AH_MD5 along
440    with the Auth(HMAC-MD5) attribute.  This suite is defined as the
441    HMAC-MD5-96 transform described in [HMACMD5].
442
443    The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH
444    transform (Key/Pad/Data/Key) described in RFC-1826.
445
446
447
448
449
450 Piper                       Standards Track                     [Page 8]
451 \f
452 RFC 2407          IP Security Domain of Interpretation     November 1998
453
454
455    Use of AH_MD5 with any other Authentication Algorithm attribute value
456    is currently undefined.
457
458 4.4.3.2 AH_SHA
459
460    The AH_SHA type specifies a generic AH transform using SHA-1.  The
461    actual protection suite is determined in concert with an associated
462    SA attribute list.  A generic SHA transform is currently undefined.
463
464    All implementations within the IPSEC DOI MUST support AH_SHA along
465    with the Auth(HMAC-SHA) attribute.  This suite is defined as the
466    HMAC-SHA-1-96 transform described in [HMACSHA].
467
468    Use of AH_SHA with any other Authentication Algorithm attribute value
469    is currently undefined.
470
471 4.4.3.3 AH_DES
472
473    The AH_DES type specifies a generic AH transform using DES.  The
474    actual protection suite is determined in concert with an associated
475    SA attribute list.  A generic DES transform is currently undefined.
476
477    The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute
478    to be a DES-MAC transform.  Implementations are not required to
479    support this mode.
480
481    Use of AH_DES with any other Authentication Algorithm attribute value
482    is currently undefined.
483
484 4.4.4 IPSEC ESP Transform Identifiers
485
486    The Encapsulating Security Payload (ESP) defines one mandatory and
487    many optional transforms used to provide data confidentiality.  The
488    following table lists the defined ESP Transform Identifiers for the
489    ISAKMP Proposal Payload for the IPSEC DOI.
490
491    Note: when authentication, integrity protection, and replay detection
492    are required, the Authentication Algorithm attribute MUST be
493    specified to identify the appropriate ESP protection suite.  For
494    example, to request HMAC-MD5 authentication with 3DES, one specifies
495    the ESP_3DES transform ID with the Authentication Algorithm attribute
496    set to HMAC-MD5.  For additional processing requirements, see Section
497    4.5 (Authentication Algorithm).
498
499
500
501
502
503
504
505
506 Piper                       Standards Track                     [Page 9]
507 \f
508 RFC 2407          IP Security Domain of Interpretation     November 1998
509
510
511        Transform ID                        Value
512        ------------                        -----
513        RESERVED                            0
514        ESP_DES_IV64                        1
515        ESP_DES                             2
516        ESP_3DES                            3
517        ESP_RC5                             4
518        ESP_IDEA                            5
519        ESP_CAST                            6
520        ESP_BLOWFISH                        7
521        ESP_3IDEA                           8
522        ESP_DES_IV32                        9
523        ESP_RC4                             10
524        ESP_NULL                            11
525
526    Note: all mandatory-to-implement algorithms are listed as "MUST"
527    implement (e.g. ESP_DES) in the following sections.  All other
528    algorithms are optional and MAY be implemented in any particular
529    implementation.
530
531 4.4.4.1 ESP_DES_IV64
532
533    The ESP_DES_IV64 type specifies the DES-CBC transform defined in
534    RFC-1827 and RFC-1829 using a 64-bit IV.
535
536 4.4.4.2 ESP_DES
537
538    The ESP_DES type specifies a generic DES transform using DES-CBC.
539    The actual protection suite is determined in concert with an
540    associated SA attribute list.  A generic transform is currently
541    undefined.
542
543    All implementations within the IPSEC DOI MUST support ESP_DES along
544    with the Auth(HMAC-MD5) attribute.  This suite is defined as the
545    [DES] transform, with authentication and integrity provided by HMAC
546    MD5 [HMACMD5].
547
548 4.4.4.3 ESP_3DES
549
550    The ESP_3DES type specifies a generic triple-DES transform.  The
551    actual protection suite is determined in concert with an associated
552    SA attribute list.  The generic transform is currently undefined.
553
554    All implementations within the IPSEC DOI are strongly encouraged to
555    support ESP_3DES along with the Auth(HMAC-MD5) attribute.  This suite
556    is defined as the [ESPCBC] transform, with authentication and
557    integrity provided by HMAC MD5 [HMACMD5].
558
559
560
561
562 Piper                       Standards Track                    [Page 10]
563 \f
564 RFC 2407          IP Security Domain of Interpretation     November 1998
565
566
567 4.4.4.4 ESP_RC5
568
569    The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].
570
571 4.4.4.5 ESP_IDEA
572
573    The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].
574
575 4.4.4.6 ESP_CAST
576
577    The ESP_CAST type specifies the CAST transform defined in [ESPCBC].
578
579 4.4.4.7 ESP_BLOWFISH
580
581    The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
582    [ESPCBC].
583
584 4.4.4.8 ESP_3IDEA
585
586    The ESP_3IDEA type is reserved for triple-IDEA.
587
588 4.4.4.9 ESP_DES_IV32
589
590    The ESP_DES_IV32 type specifies the DES-CBC transform defined in
591    RFC-1827 and RFC-1829 using a 32-bit IV.
592
593 4.4.4.10 ESP_RC4
594
595    The ESP_RC4 type is reserved for RC4.
596
597 4.4.4.11 ESP_NULL
598
599    The ESP_NULL type specifies no confidentiality is to be provided by
600    ESP.  ESP_NULL is used when ESP is being used to tunnel packets which
601    require only authentication, integrity protection, and replay
602    detection.
603
604    All implementations within the IPSEC DOI MUST support ESP_NULL.  The
605    ESP NULL transform is defined in [ESPNULL].  See the Authentication
606    Algorithm attribute description in Section 4.5 for additional
607    requirements relating to the use of ESP_NULL.
608
609 4.4.5 IPSEC IPCOMP Transform Identifiers
610
611    The IP Compression (IPCOMP) transforms define optional compression
612    algorithms that can be negotiated to provide for IP payload
613    compression ([IPCOMP]).  The following table lists the defined IPCOMP
614    Transform Identifiers for the ISAKMP Proposal Payload within the
615
616
617
618 Piper                       Standards Track                    [Page 11]
619 \f
620 RFC 2407          IP Security Domain of Interpretation     November 1998
621
622
623    IPSEC DOI.
624
625        Transform ID                        Value
626        ------------                        -----
627        RESERVED                            0
628        IPCOMP_OUI                          1
629        IPCOMP_DEFLATE                      2
630        IPCOMP_LZS                          3
631
632 4.4.5.1 IPCOMP_OUI
633
634    The IPCOMP_OUI type specifies a proprietary compression transform.
635    The IPCOMP_OUI type must be accompanied by an attribute which further
636    identifies the specific vendor algorithm.
637
638 4.4.5.2 IPCOMP_DEFLATE
639
640    The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
641    algorithm as specified in [DEFLATE].
642
643 4.4.5.3 IPCOMP_LZS
644
645    The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
646    algorithm as specified in [LZS].
647
648 4.5 IPSEC Security Association Attributes
649
650    The following SA attribute definitions are used in Phase II of an IKE
651    negotiation.  Attribute types can be either Basic (B) or Variable-
652    Length (V).  Encoding of these attributes is defined in the base
653    ISAKMP specification.
654
655    Attributes described as basic MUST NOT be encoded as variable.
656    Variable length attributes MAY be encoded as basic attributes if
657    their value can fit into two octets.  See [IKE] for further
658    information on attribute encoding in the IPSEC DOI.  All restrictions
659    listed in [IKE] also apply to the IPSEC DOI.
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674 Piper                       Standards Track                    [Page 12]
675 \f
676 RFC 2407          IP Security Domain of Interpretation     November 1998
677
678
679        Attribute Types
680
681              class               value           type
682        -------------------------------------------------
683        SA Life Type                1               B
684        SA Life Duration            2               V
685        Group Description           3               B
686        Encapsulation Mode          4               B
687        Authentication Algorithm    5               B
688        Key Length                  6               B
689        Key Rounds                  7               B
690        Compress Dictionary Size    8               B
691        Compress Private Algorithm  9               V
692
693        Class Values
694
695          SA Life Type
696          SA Duration
697
698            Specifies the time-to-live for the overall security
699            association.  When the SA expires, all keys negotiated under
700            the association (AH or ESP) must be renegotiated.  The life
701            type values are:
702
703            RESERVED                0
704            seconds                 1
705            kilobytes               2
706
707            Values 3-61439 are reserved to IANA.  Values 61440-65535 are
708            for private use.  For a given Life Type, the value of the
709            Life Duration attribute defines the actual length of the
710            component lifetime -- either a number of seconds, or a number
711            of Kbytes that can be protected.
712
713            If unspecified, the default value shall be assumed to be
714            28800 seconds (8 hours).
715
716            An SA Life Duration attribute MUST always follow an SA Life
717            Type which describes the units of duration.
718
719            See Section 4.5.4 for additional information relating to
720            lifetime notification.
721
722          Group Description
723
724            Specifies the Oakley Group to be used in a PFS QM
725            negotiation.  For a list of supported values, see Appendix A
726            of [IKE].
727
728
729
730 Piper                       Standards Track                    [Page 13]
731 \f
732 RFC 2407          IP Security Domain of Interpretation     November 1998
733
734
735          Encapsulation Mode
736            RESERVED                0
737            Tunnel                  1
738            Transport               2
739
740            Values 3-61439 are reserved to IANA.  Values 61440-65535 are
741            for private use.
742
743            If unspecified, the default value shall be assumed to be
744            unspecified (host-dependent).
745
746          Authentication Algorithm
747            RESERVED                0
748            HMAC-MD5                1
749            HMAC-SHA                2
750            DES-MAC                 3
751            KPDK                    4
752
753            Values 5-61439 are reserved to IANA.  Values 61440-65535 are
754            for private use.
755
756            There is no default value for Auth Algorithm, as it must be
757            specified to correctly identify the applicable AH or ESP
758            transform, except in the following case.
759
760            When negotiating ESP without authentication, the Auth
761            Algorithm attribute MUST NOT be included in the proposal.
762
763            When negotiating ESP without confidentiality, the Auth
764            Algorithm attribute MUST be included in the proposal and the
765            ESP transform ID must be ESP_NULL.
766
767          Key Length
768            RESERVED                0
769
770            There is no default value for Key Length, as it must be
771            specified for transforms using ciphers with variable key
772            lengths.  For fixed length ciphers, the Key Length attribute
773            MUST NOT be sent.
774
775          Key Rounds
776            RESERVED                0
777
778            There is no default value for Key Rounds, as it must be
779            specified for transforms using ciphers with varying numbers
780            of rounds.
781
782
783
784
785
786 Piper                       Standards Track                    [Page 14]
787 \f
788 RFC 2407          IP Security Domain of Interpretation     November 1998
789
790
791          Compression Dictionary Size
792            RESERVED                0
793
794            Specifies the log2 maximum size of the dictionary.
795
796            There is no default value for dictionary size.
797
798          Compression Private Algorithm
799
800            Specifies a private vendor compression algorithm.  The first
801            three (3) octets must be an IEEE assigned company_id (OUI).
802            The next octet may be a vendor specific compression subtype,
803            followed by zero or more octets of vendor data.
804
805 4.5.1 Required Attribute Support
806
807    To ensure basic interoperability, all implementations MUST be
808    prepared to negotiate all of the following attributes.
809
810            SA Life Type
811            SA Duration
812            Auth Algorithm
813
814 4.5.2 Attribute Parsing Requirement (Lifetime)
815
816    To allow for flexible semantics, the IPSEC DOI requires that a
817    conforming ISAKMP implementation MUST correctly parse an attribute
818    list that contains multiple instances of the same attribute class, so
819    long as the different attribute entries do not conflict with one
820    another.  Currently, the only attributes which requires this
821    treatment are Life Type and Duration.
822
823    To see why this is important, the following example shows the binary
824    encoding of a four entry attribute list that specifies an SA Lifetime
825    of either 100MB or 24 hours.  (See Section 3.3 of [ISAKMP] for a
826    complete description of the attribute encoding format.)
827
828      Attribute #1:
829        0x80010001  (AF = 1, type = SA Life Type, value = seconds)
830
831      Attribute #2:
832        0x00020004  (AF = 0, type = SA Duration, length = 4 bytes)
833        0x00015180  (value = 0x15180 = 86400 seconds = 24 hours)
834
835      Attribute #3:
836        0x80010002  (AF = 1, type = SA Life Type, value = KB)
837
838
839
840
841
842 Piper                       Standards Track                    [Page 15]
843 \f
844 RFC 2407          IP Security Domain of Interpretation     November 1998
845
846
847      Attribute #4:
848        0x00020004  (AF = 0, type = SA Duration, length = 4 bytes)
849        0x000186A0  (value = 0x186A0 = 100000KB = 100MB)
850
851    If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED
852    Notification Payload SHOULD be returned and the security association
853    setup MUST be aborted.
854
855 4.5.3 Attribute Negotiation
856
857    If an implementation receives a defined IPSEC DOI attribute (or
858    attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT
859    SHOULD be sent and the security association setup MUST be aborted,
860    unless the attribute value is in the reserved range.
861
862    If an implementation receives an attribute value in the reserved
863    range, an implementation MAY chose to continue based on local policy.
864
865 4.5.4 Lifetime Notification
866
867    When an initiator offers an SA lifetime greater than what the
868    responder desires based on their local policy, the responder has
869    three choices: 1) fail the negotiation entirely; 2) complete the
870    negotiation but use a shorter lifetime than what was offered; 3)
871    complete the negotiation and send an advisory notification to the
872    initiator indicating the responder's true lifetime.  The choice of
873    what the responder actually does is implementation specific and/or
874    based on local policy.
875
876    To ensure interoperability in the latter case, the IPSEC DOI requires
877    the following only when the responder wishes to notify the initiator:
878    if the initiator offers an SA lifetime longer than the responder is
879    willing to accept, the responder SHOULD include an ISAKMP
880    Notification Payload in the exchange that includes the responder's
881    IPSEC SA payload.  Section 4.6.3.1 defines the payload layout for the
882    RESPONDER-LIFETIME Notification Message type which MUST be used for
883    this purpose.
884
885 4.6 IPSEC Payload Content
886
887    The following sections describe those ISAKMP payloads whose data
888    representations are dependent on the applicable DOI.
889
890 4.6.1 Security Association Payload
891
892    The following diagram illustrates the content of the Security
893    Association Payload for the IPSEC DOI.  See Section 4.2 for a
894    description of the Situation bitmap.
895
896
897
898 Piper                       Standards Track                    [Page 16]
899 \f
900 RFC 2407          IP Security Domain of Interpretation     November 1998
901
902
903     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
904    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
905    !  Next Payload !   RESERVED    !        Payload Length         !
906    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
907    !                Domain of Interpretation (IPSEC)               |
908    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
909    !                       Situation (bitmap)                      !
910    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
911    !                    Labeled Domain Identifier                  !
912    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
913    !  Secrecy Length (in octets)   !           RESERVED            !
914    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
915    ~                        Secrecy Level                          ~
916    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
917    ! Secrecy Cat. Length (in bits) !           RESERVED            !
918    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
919    ~                    Secrecy Category Bitmap                    ~
920    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
921    ! Integrity Length (in octets)  !           RESERVED            !
922    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
923    ~                       Integrity Level                         ~
924    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
925    ! Integ. Cat. Length (in bits)  !           RESERVED            !
926    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
927    ~                  Integrity Category Bitmap                    ~
928    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
929
930                Figure 1: Security Association Payload Format
931
932    The Security Association Payload is defined as follows:
933
934      o  Next Payload (1 octet) - Identifier for the payload type of
935         the next payload in the message.  If the current payload is the
936         last in the message, this field will be zero (0).
937
938      o  RESERVED (1 octet) - Unused, must be zero (0).
939
940      o  Payload Length (2 octets) - Length, in octets, of the current
941         payload, including the generic header.
942
943      o  Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
944         which has been assigned the value one (1).
945
946      o  Situation (4 octets) - Bitmask used to interpret the remainder
947         of the Security Association Payload.  See Section 4.2 for a
948         complete list of values.
949
950
951
952
953
954 Piper                       Standards Track                    [Page 17]
955 \f
956 RFC 2407          IP Security Domain of Interpretation     November 1998
957
958
959      o  Labeled Domain Identifier (4 octets) - IANA Assigned Number used
960         to interpret the Secrecy and Integrity information.
961
962      o  Secrecy Length (2 octets) - Specifies the length, in octets, of
963         the secrecy level identifier, excluding pad bits.
964
965      o  RESERVED (2 octets) - Unused, must be zero (0).
966
967      o  Secrecy Level (variable length) - Specifies the mandatory
968         secrecy level required.  The secrecy level MUST be padded with
969         zero (0) to align on the next 32-bit boundary.
970
971      o  Secrecy Category Length (2 octets) - Specifies the length, in
972         bits, of the secrecy category (compartment) bitmap, excluding
973         pad bits.
974
975      o  RESERVED (2 octets) - Unused, must be zero (0).
976
977      o  Secrecy Category Bitmap (variable length) - A bitmap used to
978         designate secrecy categories (compartments) that are required.
979         The bitmap MUST be padded with zero (0) to align on the next
980         32-bit boundary.
981
982      o  Integrity Length (2 octets) - Specifies the length, in octets,
983         of the integrity level identifier, excluding pad bits.
984
985      o  RESERVED (2 octets) - Unused, must be zero (0).
986
987      o  Integrity Level (variable length) - Specifies the mandatory
988         integrity level required.  The integrity level MUST be padded
989         with zero (0) to align on the next 32-bit boundary.
990
991      o  Integrity Category Length (2 octets) - Specifies the length, in
992         bits, of the integrity category (compartment) bitmap, excluding
993         pad bits.
994
995      o  RESERVED (2 octets) - Unused, must be zero (0).
996
997      o  Integrity Category Bitmap (variable length) - A bitmap used to
998         designate integrity categories (compartments) that are required.
999         The bitmap MUST be padded with zero (0) to align on the next
1000         32-bit boundary.
1001
1002 4.6.1.1 IPSEC Labeled Domain Identifiers
1003
1004    The following table lists the assigned values for the Labeled Domain
1005    Identifier field contained in the Situation field of the Security
1006    Association Payload.
1007
1008
1009
1010 Piper                       Standards Track                    [Page 18]
1011 \f
1012 RFC 2407          IP Security Domain of Interpretation     November 1998
1013
1014
1015        Domain                              Value
1016        -------                             -----
1017        RESERVED                            0
1018
1019 4.6.2 Identification Payload Content
1020
1021    The Identification Payload is used to identify the initiator of the
1022    Security Association.  The identity of the initiator SHOULD be used
1023    by the responder to determine the correct host system security policy
1024    requirement for the association.  For example, a host might choose to
1025    require authentication and integrity without confidentiality (AH)
1026    from a certain set of IP addresses and full authentication with
1027    confidentiality (ESP) from another range of IP addresses.  The
1028    Identification Payload provides information that can be used by the
1029    responder to make this decision.
1030
1031    During Phase I negotiations, the ID port and protocol fields MUST be
1032    set to zero or to UDP port 500.  If an implementation receives any
1033    other values, this MUST be treated as an error and the security
1034    association setup MUST be aborted.  This event SHOULD be auditable.
1035
1036    The following diagram illustrates the content of the Identification
1037    Payload.
1038
1039     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
1040    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1041    !  Next Payload !   RESERVED    !        Payload Length         !
1042    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1043    !   ID Type     !  Protocol ID  !             Port              !
1044    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1045    ~                     Identification Data                       ~
1046    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1047
1048                   Figure 2: Identification Payload Format
1049
1050    The Identification Payload fields are defined as follows:
1051
1052      o  Next Payload (1 octet) - Identifier for the payload type of
1053         the next payload in the message.  If the current payload is the
1054         last in the message, this field will be zero (0).
1055
1056      o  RESERVED (1 octet) - Unused, must be zero (0).
1057
1058      o  Payload Length (2 octets) - Length, in octets, of the
1059         identification data, including the generic header.
1060
1061      o  Identification Type (1 octet) - Value describing the identity
1062         information found in the Identification Data field.
1063
1064
1065
1066 Piper                       Standards Track                    [Page 19]
1067 \f
1068 RFC 2407          IP Security Domain of Interpretation     November 1998
1069
1070
1071      o  Protocol ID (1 octet) - Value specifying an associated IP
1072         protocol ID (e.g. UDP/TCP).  A value of zero means that the
1073         Protocol ID field should be ignored.
1074
1075      o  Port (2 octets) - Value specifying an associated port.  A value
1076         of zero means that the Port field should be ignored.
1077
1078      o  Identification Data (variable length) - Value, as indicated by
1079         the Identification Type.
1080
1081 4.6.2.1 Identification Type Values
1082
1083    The following table lists the assigned values for the Identification
1084    Type field found in the Identification Payload.
1085
1086        ID Type                   Value
1087        -------                   -----
1088        RESERVED                            0
1089        ID_IPV4_ADDR                        1
1090        ID_FQDN                             2
1091        ID_USER_FQDN                        3
1092        ID_IPV4_ADDR_SUBNET                 4
1093        ID_IPV6_ADDR                        5
1094        ID_IPV6_ADDR_SUBNET                 6
1095        ID_IPV4_ADDR_RANGE                  7
1096        ID_IPV6_ADDR_RANGE                  8
1097        ID_DER_ASN1_DN                      9
1098        ID_DER_ASN1_GN                      10
1099        ID_KEY_ID                           11
1100
1101    For types where the ID entity is variable length, the size of the ID
1102    entity is computed from size in the ID payload header.
1103
1104    When an IKE exchange is authenticated using certificates (of any
1105    format), any ID's used for input to local policy decisions SHOULD be
1106    contained in the certificate used in the authentication of the
1107    exchange.
1108
1109 4.6.2.2 ID_IPV4_ADDR
1110
1111    The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
1112
1113 4.6.2.3 ID_FQDN
1114
1115    The ID_FQDN type specifies a fully-qualified domain name string.  An
1116    example of a ID_FQDN is, "foo.bar.com".  The string should not
1117    contain any terminators.
1118
1119
1120
1121
1122 Piper                       Standards Track                    [Page 20]
1123 \f
1124 RFC 2407          IP Security Domain of Interpretation     November 1998
1125
1126
1127 4.6.2.4 ID_USER_FQDN
1128
1129    The ID_USER_FQDN type specifies a fully-qualified username string, An
1130    example of a ID_USER_FQDN is, "piper@foo.bar.com".  The string should
1131    not contain any terminators.
1132
1133 4.6.2.5 ID_IPV4_ADDR_SUBNET
1134
1135    The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
1136    represented by two four (4) octet values.  The first value is an IPv4
1137    address.  The second is an IPv4 network mask.  Note that ones (1s) in
1138    the network mask indicate that the corresponding bit in the address
1139    is fixed, while zeros (0s) indicate a "wildcard" bit.
1140
1141 4.6.2.6 ID_IPV6_ADDR
1142
1143    The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
1144    address.
1145
1146 4.6.2.7 ID_IPV6_ADDR_SUBNET
1147
1148    The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
1149    represented by two sixteen (16) octet values.  The first value is an
1150    IPv6 address.  The second is an IPv6 network mask.  Note that ones
1151    (1s) in the network mask indicate that the corresponding bit in the
1152    address is fixed, while zeros (0s) indicate a "wildcard" bit.
1153
1154 4.6.2.8 ID_IPV4_ADDR_RANGE
1155
1156    The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,
1157    represented by two four (4) octet values.  The first value is the
1158    beginning IPv4 address (inclusive) and the second value is the ending
1159    IPv4 address (inclusive).  All addresses falling between the two
1160    specified addresses are considered to be within the list.
1161
1162 4.6.2.9 ID_IPV6_ADDR_RANGE
1163
1164    The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,
1165    represented by two sixteen (16) octet values.  The first value is the
1166    beginning IPv6 address (inclusive) and the second value is the ending
1167    IPv6 address (inclusive).  All addresses falling between the two
1168    specified addresses are considered to be within the list.
1169
1170 4.6.2.10 ID_DER_ASN1_DN
1171
1172    The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1
1173    X.500 Distinguished Name [X.501] of the principal whose certificates
1174    are being exchanged to establish the SA.
1175
1176
1177
1178 Piper                       Standards Track                    [Page 21]
1179 \f
1180 RFC 2407          IP Security Domain of Interpretation     November 1998
1181
1182
1183 4.6.2.11 ID_DER_ASN1_GN
1184
1185    The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1
1186    X.500 GeneralName [X.509] of the principal whose certificates are
1187    being exchanged to establish the SA.
1188
1189 4.6.2.12 ID_KEY_ID
1190
1191    The ID_KEY_ID type specifies an opaque byte stream which may be used
1192    to pass vendor-specific information necessary to identify which pre-
1193    shared key should be used to authenticate Aggressive mode
1194    negotiations.
1195
1196 4.6.3 IPSEC Notify Message Types
1197
1198    ISAKMP defines two blocks of Notify Message codes, one for errors and
1199    one for status messages.  ISAKMP also allocates a portion of each
1200    block for private use within a DOI.  The IPSEC DOI defines the
1201    following private message types for its own use.
1202
1203        Notify Messages - Error Types       Value
1204        -----------------------------       -----
1205        RESERVED                            8192
1206
1207        Notify Messages - Status Types      Value
1208        ------------------------------      -----
1209        RESPONDER-LIFETIME                  24576
1210        REPLAY-STATUS                       24577
1211        INITIAL-CONTACT                     24578
1212
1213    Notification Status Messages MUST be sent under the protection of an
1214    ISAKMP SA: either as a payload in the last Main Mode exchange; in a
1215    separate Informational Exchange after Main Mode or Aggressive Mode
1216    processing is complete; or as a payload in any Quick Mode exchange.
1217    These messages MUST NOT be sent in Aggressive Mode exchange, since
1218    Aggressive Mode does not provide the necessary protection to bind the
1219    Notify Status Message to the exchange.
1220
1221    Nota Bene: a Notify payload is fully protected only in Quick Mode,
1222    where the entire payload is included in the HASH(n) digest.  In Main
1223    Mode, while the notify payload is encrypted, it is not currently
1224    included in the HASH(n) digests.  As a result, an active substitution
1225    attack on the Main Mode ciphertext could cause the notify status
1226    message type to be corrupted.  (This is true, in general, for the
1227    last message of any Main Mode exchange.)  While the risk is small, a
1228    corrupt notify message might cause the receiver to abort the entire
1229    negotiation thinking that the sender encountered a fatal error.
1230
1231
1232
1233
1234 Piper                       Standards Track                    [Page 22]
1235 \f
1236 RFC 2407          IP Security Domain of Interpretation     November 1998
1237
1238
1239    Implementation Note: the ISAKMP protocol does not guarantee delivery
1240    of Notification Status messages when sent in an ISAKMP Informational
1241    Exchange.  To ensure receipt of any particular message, the sender
1242    SHOULD include a Notification Payload in a defined Main Mode or Quick
1243    Mode exchange which is protected by a retransmission timer.
1244
1245 4.6.3.1 RESPONDER-LIFETIME
1246
1247    The RESPONDER-LIFETIME status message may be used to communicate the
1248    IPSEC SA lifetime chosen by the responder.
1249
1250    When present, the Notification Payload MUST have the following
1251    format:
1252
1253      o  Payload Length - set to length of payload + size of data (var)
1254      o  DOI - set to IPSEC DOI (1)
1255      o  Protocol ID - set to selected Protocol ID from chosen SA
1256      o  SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
1257         cookies) or four (4) (one IPSEC SPI)
1258      o  Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
1259      o  SPI - set to the two ISAKMP cookies or to the sender's inbound
1260         IPSEC SPI
1261      o  Notification Data - contains an ISAKMP attribute list with the
1262         responder's actual SA lifetime(s)
1263
1264    Implementation Note: saying that the Notification Data field contains
1265    an attribute list is equivalent to saying that the Notification Data
1266    field has zero length and the Notification Payload has an associated
1267    attribute list.
1268
1269 4.6.3.2 REPLAY-STATUS
1270
1271    The REPLAY-STATUS status message may be used for positive
1272    confirmation of the responder's election on whether or not he is to
1273    perform anti-replay detection.
1274
1275    When present, the Notification Payload MUST have the following
1276    format:
1277
1278      o  Payload Length - set to length of payload + size of data (4)
1279      o  DOI - set to IPSEC DOI (1)
1280      o  Protocol ID - set to selected Protocol ID from chosen SA
1281      o  SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
1282         cookies) or four (4) (one IPSEC SPI)
1283      o  Notify Message Type - set to REPLAY-STATUS
1284      o  SPI - set to the two ISAKMP cookies or to the sender's inbound
1285         IPSEC SPI
1286      o  Notification Data - a 4 octet value:
1287
1288
1289
1290 Piper                       Standards Track                    [Page 23]
1291 \f
1292 RFC 2407          IP Security Domain of Interpretation     November 1998
1293
1294
1295           0 = replay detection disabled
1296           1 = replay detection enabled
1297
1298 4.6.3.3 INITIAL-CONTACT
1299
1300    The INITIAL-CONTACT status message may be used when one side wishes
1301    to inform the other that this is the first SA being established with
1302    the remote system.  The receiver of this Notification Message might
1303    then elect to delete any existing SA's it has for the sending system
1304    under the assumption that the sending system has rebooted and no
1305    longer has access to the original SA's and their associated keying
1306    material.  When used, the content of the Notification Data field
1307    SHOULD be null (i.e. the Payload Length should be set to the fixed
1308    length of Notification Payload).
1309
1310    When present, the Notification Payload MUST have the following
1311    format:
1312
1313      o  Payload Length - set to length of payload + size of data (0)
1314      o  DOI - set to IPSEC DOI (1)
1315      o  Protocol ID - set to selected Protocol ID from chosen SA
1316      o  SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies)
1317      o  Notify Message Type - set to INITIAL-CONTACT
1318      o  SPI - set to the two ISAKMP cookies
1319      o  Notification Data - <not included>
1320
1321 4.7 IPSEC Key Exchange Requirements
1322
1323    The IPSEC DOI introduces no additional Key Exchange types.
1324
1325 5. Security Considerations
1326
1327    This entire memo pertains to the Internet Key Exchange protocol
1328    ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to
1329    provide for the derivation of cryptographic keying material in a
1330    secure and authenticated manner.  Specific discussion of the various
1331    security protocols and transforms identified in this document can be
1332    found in the associated base documents and in the cipher references.
1333
1334 6. IANA Considerations
1335
1336    This document contains many "magic" numbers to be maintained by the
1337    IANA.  This section explains the criteria to be used by the IANA to
1338    assign additional numbers in each of these lists.  All values not
1339    explicitly defined in previous sections are reserved to IANA.
1340
1341
1342
1343
1344
1345
1346 Piper                       Standards Track                    [Page 24]
1347 \f
1348 RFC 2407          IP Security Domain of Interpretation     November 1998
1349
1350
1351 6.1 IPSEC Situation Definition
1352
1353    The Situation Definition is a 32-bit bitmask which represents the
1354    environment under which the IPSEC SA proposal and negotiation is
1355    carried out.  Requests for assignments of new situations must be
1356    accompanied by an RFC which describes the interpretation for the
1357    associated bit.
1358
1359    If the RFC is not on the standards-track (i.e., it is an
1360    informational or experimental RFC), it must be explicitly reviewed
1361    and approved by the IESG before the RFC is published and the
1362    transform identifier is assigned.
1363
1364    The upper two bits are reserved for private use amongst cooperating
1365    systems.
1366
1367 6.2 IPSEC Security Protocol Identifiers
1368
1369    The Security Protocol Identifier is an 8-bit value which identifies a
1370    security protocol suite being negotiated.  Requests for assignments
1371    of new security protocol identifiers must be accompanied by an RFC
1372    which describes the requested security protocol.  [AH] and [ESP] are
1373    examples of security protocol documents.
1374
1375    If the RFC is not on the standards-track (i.e., it is an
1376    informational or experimental RFC), it must be explicitly reviewed
1377    and approved by the IESG before the RFC is published and the
1378    transform identifier is assigned.
1379
1380    The values 249-255 are reserved for private use amongst cooperating
1381    systems.
1382
1383 6.3 IPSEC ISAKMP Transform Identifiers
1384
1385    The IPSEC ISAKMP Transform Identifier is an 8-bit value which
1386    identifies a key exchange protocol to be used for the negotiation.
1387    Requests for assignments of new ISAKMP transform identifiers must be
1388    accompanied by an RFC which describes the requested key exchange
1389    protocol.  [IKE] is an example of one such document.
1390
1391    If the RFC is not on the standards-track (i.e., it is an
1392    informational or experimental RFC), it must be explicitly reviewed
1393    and approved by the IESG before the RFC is published and the
1394    transform identifier is assigned.
1395
1396    The values 249-255 are reserved for private use amongst cooperating
1397    systems.
1398
1399
1400
1401
1402 Piper                       Standards Track                    [Page 25]
1403 \f
1404 RFC 2407          IP Security Domain of Interpretation     November 1998
1405
1406
1407 6.4 IPSEC AH Transform Identifiers
1408
1409    The IPSEC AH Transform Identifier is an 8-bit value which identifies
1410    a particular algorithm to be used to provide integrity protection for
1411    AH.  Requests for assignments of new AH transform identifiers must be
1412    accompanied by an RFC which describes how to use the algorithm within
1413    the AH framework ([AH]).
1414
1415    If the RFC is not on the standards-track (i.e., it is an
1416    informational or experimental RFC), it must be explicitly reviewed
1417    and approved by the IESG before the RFC is published and the
1418    transform identifier is assigned.
1419
1420    The values 249-255 are reserved for private use amongst cooperating
1421    systems.
1422
1423 6.5 IPSEC ESP Transform Identifiers
1424
1425    The IPSEC ESP Transform Identifier is an 8-bit value which identifies
1426    a particular algorithm to be used to provide secrecy protection for
1427    ESP.  Requests for assignments of new ESP transform identifiers must
1428    be accompanied by an RFC which describes how to use the algorithm
1429    within the ESP framework ([ESP]).
1430
1431    If the RFC is not on the standards-track (i.e., it is an
1432    informational or experimental RFC), it must be explicitly reviewed
1433    and approved by the IESG before the RFC is published and the
1434    transform identifier is assigned.
1435
1436    The values 249-255 are reserved for private use amongst cooperating
1437    systems.
1438
1439 6.6 IPSEC IPCOMP Transform Identifiers
1440
1441    The IPSEC IPCOMP Transform Identifier is an 8-bit value which
1442    identifier a particular algorithm to be used to provide IP-level
1443    compression before ESP.  Requests for assignments of new IPCOMP
1444    transform identifiers must be accompanied by an RFC which describes
1445    how to use the algorithm within the IPCOMP framework ([IPCOMP]).  In
1446    addition, the requested algorithm must be published and in the public
1447    domain.
1448
1449    If the RFC is not on the standards-track (i.e., it is an
1450    informational or experimental RFC), it must be explicitly reviewed
1451    and approved by the IESG before the RFC is published and the
1452    transform identifier is assigned.
1453
1454
1455
1456
1457
1458 Piper                       Standards Track                    [Page 26]
1459 \f
1460 RFC 2407          IP Security Domain of Interpretation     November 1998
1461
1462
1463    The values 1-47 are reserved for algorithms for which an RFC has been
1464    approved for publication.  The values 48-63 are reserved for private
1465    use amongst cooperating systems.  The values 64-255 are reserved for
1466    future expansion.
1467
1468 6.7 IPSEC Security Association Attributes
1469
1470    The IPSEC Security Association Attribute consists of a 16-bit type
1471    and its associated value.  IPSEC SA attributes are used to pass
1472    miscellaneous values between ISAKMP peers.  Requests for assignments
1473    of new IPSEC SA attributes must be accompanied by an Internet Draft
1474    which describes the attribute encoding (Basic/Variable-Length) and
1475    its legal values.  Section 4.5 of this document provides an example
1476    of such a description.
1477
1478    The values 32001-32767 are reserved for private use amongst
1479    cooperating systems.
1480
1481 6.8 IPSEC Labeled Domain Identifiers
1482
1483    The IPSEC Labeled Domain Identifier is a 32-bit value which
1484    identifies a namespace in which the Secrecy and Integrity levels and
1485    categories values are said to exist.  Requests for assignments of new
1486    IPSEC Labeled Domain Identifiers should be granted on demand.  No
1487    accompanying documentation is required, though Internet Drafts are
1488    encouraged when appropriate.
1489
1490    The values 0x80000000-0xffffffff are reserved for private use amongst
1491    cooperating systems.
1492
1493 6.9 IPSEC Identification Type
1494
1495    The IPSEC Identification Type is an 8-bit value which is used as a
1496    discriminant for interpretation of the variable-length Identification
1497    Payload.  Requests for assignments of new IPSEC Identification Types
1498    must be accompanied by an RFC which describes how to use the
1499    identification type within IPSEC.
1500
1501    If the RFC is not on the standards-track (i.e., it is an
1502    informational or experimental RFC), it must be explicitly reviewed
1503    and approved by the IESG before the RFC is published and the
1504    transform identifier is assigned.
1505
1506    The values 249-255 are reserved for private use amongst cooperating
1507    systems.
1508
1509
1510
1511
1512
1513
1514 Piper                       Standards Track                    [Page 27]
1515 \f
1516 RFC 2407          IP Security Domain of Interpretation     November 1998
1517
1518
1519 6.10 IPSEC Notify Message Types
1520
1521    The IPSEC Notify Message Type is a 16-bit value taken from the range
1522    of values reserved by ISAKMP for each DOI.  There is one range for
1523    error messages (8192-16383) and a different range for status messages
1524    (24576-32767).  Requests for assignments of new Notify Message Types
1525    must be accompanied by an Internet Draft which describes how to use
1526    the identification type within IPSEC.
1527
1528    The values 16001-16383 and the values 32001-32767 are reserved for
1529    private use amongst cooperating systems.
1530
1531 7. Change Log
1532
1533 7.1 Changes from V9
1534
1535      o  add explicit reference to [IPCOMP], [DEFLATE], and [LZS]
1536      o  allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed
1537         at an IPSEC SPI in addition to the ISAKMP "SPI"
1538      o  added padding exclusion to Secrecy and Integrity Length text
1539      o  added forward reference to Section 4.5 in Section 4.4.4
1540      o  update document references
1541
1542 7.2 Changes from V8
1543
1544      o  update IPCOMP identifier range to better reflect IPCOMP draft
1545      o  update IANA considerations per Jeff/Ted's suggested text
1546      o  eliminate references to DES-MAC ID ([DESMAC])
1547      o  correct bug in Notify section; ISAKMP Notify values are 16-bits
1548
1549 7.3 Changes from V7
1550
1551      o  corrected name of IPCOMP (IP Payload Compression)
1552      o  corrected references to [ESPCBC]
1553      o  added missing Secrecy Level and Integrity Level to Figure 1
1554      o  removed ID references to PF_KEY and ARCFOUR
1555      o  updated Basic/Variable text to align with [IKE]
1556      o  updated document references and add intro pointer to [ARCH]
1557      o  updated Notification requirements; remove aggressive reference
1558      o  added clarification about protection for Notify payloads
1559      o  restored RESERVED to ESP transform ID namespace; moved ESP_NULL
1560      o  added requirement for ESP_NULL support and [ESPNULL] reference
1561      o  added clarification on Auth Alg use with AH/ESP
1562      o  added restriction against using conflicting AH/Auth combinations
1563
1564 7.4 Changes from V6
1565
1566    The following changes were made relative to the IPSEC DOI V6:
1567
1568
1569
1570 Piper                       Standards Track                    [Page 28]
1571 \f
1572 RFC 2407          IP Security Domain of Interpretation     November 1998
1573
1574
1575      o  added IANA Considerations section
1576      o  moved most IANA numbers to IANA Considerations section
1577      o  added prohibition on sending (V) encoding for (B) attributes
1578      o  added prohibition on sending Key Length attribute for fixed
1579         length ciphers (e.g. DES)
1580      o  replaced references to ISAKMP/Oakley with IKE
1581      o  renamed ESP_ARCFOUR to ESP_RC4
1582      o  updated Security Considerations section
1583      o  updated document references
1584
1585 7.5 Changes from V5
1586
1587    The following changes were made relative to the IPSEC DOI V5:
1588
1589      o  changed SPI size in Lifetime Notification text
1590      o  changed REPLAY-ENABLED to REPLAY-STATUS
1591      o  moved RESPONDER-LIFETIME payload definition from Section 4.5.4
1592         to Section 4.6.3.1
1593      o  added explicit payload layout for 4.6.3.3
1594      o  added Implementation Note to Section 4.6.3 introduction
1595      o  changed AH_SHA text to require SHA-1 in addition to MD5
1596      o  updated document references
1597
1598 7.6 Changes from V4
1599
1600    The following changes were made relative to the IPSEC DOI V4:
1601
1602      o  moved compatibility AH KPDK authentication method from AH
1603         transform ID to Authentication Algorithm identifier
1604      o  added REPLAY-ENABLED notification message type per Architecture
1605      o  added INITIAL-CONTACT notification message type per list
1606      o  added text to ensure protection for Notify Status messages
1607      o  added Lifetime qualification to attribute parsing section
1608      o  added clarification that Lifetime notification is optional
1609      o  removed private Group Description list (now points at [IKE])
1610      o  replaced Terminology with pointer to RFC-2119
1611      o  updated HMAC MD5 and SHA-1 ID references
1612      o  updated Section 1 (Abstract)
1613      o  updated Section 4.4 (IPSEC Assigned Numbers)
1614      o  added restriction for ID port/protocol values for Phase I
1615
1616 7.7 Changes from V3 to V4
1617
1618    The following changes were made relative to the IPSEC DOI V3, that
1619    was posted to the IPSEC mailing list prior to the Munich IETF:
1620
1621      o  added ESP transform identifiers for NULL and ARCFOUR
1622
1623
1624
1625
1626 Piper                       Standards Track                    [Page 29]
1627 \f
1628 RFC 2407          IP Security Domain of Interpretation     November 1998
1629
1630
1631      o  renamed HMAC Algorithm to Auth Algorithm to accommodate
1632         DES-MAC and optional authentication/integrity for ESP
1633      o  added AH and ESP DES-MAC algorithm identifiers
1634      o  removed KEY_MANUAL and KEY_KDC identifier definitions
1635      o  added lifetime duration MUST follow lifetype attribute to
1636         SA Life Type and SA Life Duration attribute definition
1637      o  added lifetime notification and IPSEC DOI message type table
1638      o  added optional authentication and confidentiality
1639         restrictions to MAC Algorithm attribute definition
1640      o  corrected attribute parsing example (used obsolete attribute)
1641      o  corrected several Internet Draft document references
1642      o  added ID_KEY_ID per ipsec list discussion (18-Mar-97)
1643      o  removed Group Description default for PFS QM ([IKE] MUST)
1644
1645 Acknowledgments
1646
1647    This document is derived, in part, from previous works by Douglas
1648    Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
1649    and Dave Carrel.  Matt Thomas, Roy Pereira, Greg Carter, and Ran
1650    Atkinson also contributed suggestions and, in many cases, text.
1651
1652 References
1653
1654    [AH]      Kent, S., and R. Atkinson, "IP Authentication Header", RFC
1655              2402, November 1998.
1656
1657    [ARCH]    Kent, S., and R. Atkinson, "Security Architecture for the
1658              Internet Protocol", RFC 2401, November 1998.
1659
1660    [DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
1661              2394, August 1998.
1662
1663    [ESP]     Kent, S., and R. Atkinson, "IP Encapsulating Security
1664              Payload (ESP)", RFC 2406, November 1998.
1665
1666    [ESPCBC]  Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher
1667              Algorithms", RFC 2451, November 1998.
1668
1669    [ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and
1670              Its Use With IPsec", RFC 2410, November 1998.
1671
1672    [DES]     Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
1673              Algorithm With Explicit IV", RFC 2405, November 1998.
1674
1675    [HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP
1676              and AH", RFC 2403, November 1998.
1677
1678
1679
1680
1681
1682 Piper                       Standards Track                    [Page 30]
1683 \f
1684 RFC 2407          IP Security Domain of Interpretation     November 1998
1685
1686
1687    [HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
1688              ESP and AH", RFC 2404, November 1998.
1689
1690    [IKE]     Harkins, D., and D. Carrel, D., "The Internet Key Exchange
1691              (IKE)", RFC 2409, November 1998.
1692
1693    [IPCOMP]  Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
1694              Payload Compression Protocol (IPComp)", RFC 2393, August
1695              1998.
1696
1697    [ISAKMP]  Maughan, D., Schertler, M., Schneider, M., and J. Turner,
1698              "Internet Security Association and Key Management Protocol
1699              (ISAKMP)", RFC 2408, November 1998.
1700
1701    [LZS]     Friend, R., and R. Monsour, "IP Payload Compression Using
1702              LZS", RFC 2395, August 1998.
1703
1704    [OAKLEY]  Orman, H., "The OAKLEY Key Determination Protocol", RFC
1705              2412, November 1998.
1706
1707    [X.501]   ISO/IEC 9594-2, "Information Technology - Open Systems
1708              Interconnection - The Directory:  Models", CCITT/ITU
1709              Recommendation X.501, 1993.
1710
1711    [X.509]   ISO/IEC 9594-8, "Information Technology - Open Systems
1712              Interconnection - The Directory:  Authentication
1713              Framework", CCITT/ITU Recommendation X.509, 1993.
1714
1715 Author's Address
1716
1717    Derrell Piper
1718    Network Alchemy
1719    1521.5 Pacific Ave
1720    Santa Cruz, California, 95060
1721    United States of America
1722
1723    Phone: +1 408 460-3822
1724    EMail: ddp@network-alchemy.com
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738 Piper                       Standards Track                    [Page 31]
1739 \f
1740 RFC 2407          IP Security Domain of Interpretation     November 1998
1741
1742
1743 Full Copyright Statement
1744
1745    Copyright (C) The Internet Society (1998).  All Rights Reserved.
1746
1747    This document and translations of it may be copied and furnished to
1748    others, and derivative works that comment on or otherwise explain it
1749    or assist in its implementation may be prepared, copied, published
1750    and distributed, in whole or in part, without restriction of any
1751    kind, provided that the above copyright notice and this paragraph are
1752    included on all such copies and derivative works.  However, this
1753    document itself may not be modified in any way, such as by removing
1754    the copyright notice or references to the Internet Society or other
1755    Internet organizations, except as needed for the purpose of
1756    developing Internet standards in which case the procedures for
1757    copyrights defined in the Internet Standards process must be
1758    followed, or as required to translate it into languages other than
1759    English.
1760
1761    The limited permissions granted above are perpetual and will not be
1762    revoked by the Internet Society or its successors or assigns.
1763
1764    This document and the information contained herein is provided on an
1765    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1766    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1767    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1768    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1769    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794 Piper                       Standards Track                    [Page 32]
1795 \f