| blob | 7b2f87c854ca10e264add53cee74d4382a79f7d5 |
7 Network Working Group D. Piper
8 Request for Comments: 2407 Network Alchemy
9 Category: Standards Track November 1998
12 The Internet IP Security Domain of Interpretation for ISAKMP
14 Status of this Memo
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.
22 Copyright Notice
24 Copyright (C) The Internet Society (1998). All Rights Reserved.
26 IESG Note
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.
39 1. Abstract
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.
50 For a list of changes since the previous version of the IPSEC DOI,
51 please see Section 7.
58 Piper Standards Track [Page 1]
59 \f
60 RFC 2407 IP Security Domain of Interpretation November 1998
63 2. Introduction
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.
73 Overall, ISAKMP places the following requirements on a DOI
74 definition:
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
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.
89 For a description of the overall IPSEC architecture, see [ARCH],
90 [AH], and [ESP].
92 3. Terms and Definitions
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].
98 4.1 IPSEC Naming Scheme
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.
109 All multi-octet binary values are stored in network byte order.
114 Piper Standards Track [Page 2]
115 \f
116 RFC 2407 IP Security Domain of Interpretation November 1998
119 4.2 IPSEC Situation Definition
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.
127 Situation Value
128 --------- -----
129 SIT_IDENTITY_ONLY 0x01
130 SIT_SECRECY 0x02
131 SIT_INTEGRITY 0x04
133 4.2.1 SIT_IDENTITY_ONLY
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.
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.
151 4.2.2 SIT_SECRECY
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.
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.
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.
170 Piper Standards Track [Page 3]
171 \f
172 RFC 2407 IP Security Domain of Interpretation November 1998
175 4.2.3 SIT_INTEGRITY
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.
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.
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.
195 4.3 IPSEC Security Policy Requirements
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.
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.
205 4.3.1 Key Management Issues
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.
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.
226 Piper Standards Track [Page 4]
227 \f
228 RFC 2407 IP Security Domain of Interpretation November 1998
231 4.3.2 Static Keying Issues
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.
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.
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.
249 4.3.3 Host Policy Issues
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.
257 A minimal approach is probably a static list of IP addresses, network
258 masks, and a security required flag or flags.
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.
269 4.3.4 Certificate Management
271 Host systems implementing a certificate-based authentication scheme
272 will need a mechanism for obtaining and managing a database of
273 certificates.
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
282 Piper Standards Track [Page 5]
283 \f
284 RFC 2407 IP Security Domain of Interpretation November 1998
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.
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.
295 4.4 IPSEC Assigned Numbers
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.
303 4.4.1 IPSEC Security Protocol Identifier
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.
312 The following table lists the values for the Security Protocol
313 Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
314 DOI.
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
324 4.4.1.1 PROTO_ISAKMP
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.
331 NB: ISAKMP reserves the value one (1) across all DOI definitions.
338 Piper Standards Track [Page 6]
339 \f
340 RFC 2407 IP Security Domain of Interpretation November 1998
343 4.4.1.2 PROTO_IPSEC_AH
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.
350 4.4.1.3 PROTO_IPSEC_ESP
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.
358 4.4.1.4 PROTO_IPCOMP
360 The PROTO_IPCOMP type specifies IP payload compression as defined in
361 [IPCOMP].
363 4.4.2 IPSEC ISAKMP Transform Identifiers
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.
372 Transform Value
373 --------- -----
374 RESERVED 0
375 KEY_IKE 1
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.
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].
394 Piper Standards Track [Page 7]
395 \f
396 RFC 2407 IP Security Domain of Interpretation November 1998
399 4.4.2.1 KEY_IKE
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.
405 4.4.3 IPSEC AH Transform Identifiers
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.
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.
421 Transform ID Value
422 ------------ -----
423 RESERVED 0-1
424 AH_MD5 2
425 AH_SHA 3
426 AH_DES 4
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.
433 4.4.3.1 AH_MD5
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.
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].
443 The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH
444 transform (Key/Pad/Data/Key) described in RFC-1826.
450 Piper Standards Track [Page 8]
451 \f
452 RFC 2407 IP Security Domain of Interpretation November 1998
455 Use of AH_MD5 with any other Authentication Algorithm attribute value
456 is currently undefined.
458 4.4.3.2 AH_SHA
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.
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].
468 Use of AH_SHA with any other Authentication Algorithm attribute value
469 is currently undefined.
471 4.4.3.3 AH_DES
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.
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.
481 Use of AH_DES with any other Authentication Algorithm attribute value
482 is currently undefined.
484 4.4.4 IPSEC ESP Transform Identifiers
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.
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).
506 Piper Standards Track [Page 9]
507 \f
508 RFC 2407 IP Security Domain of Interpretation November 1998
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
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.
531 4.4.4.1 ESP_DES_IV64
533 The ESP_DES_IV64 type specifies the DES-CBC transform defined in
534 RFC-1827 and RFC-1829 using a 64-bit IV.
536 4.4.4.2 ESP_DES
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.
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].
548 4.4.4.3 ESP_3DES
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.
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].
562 Piper Standards Track [Page 10]
563 \f
564 RFC 2407 IP Security Domain of Interpretation November 1998
567 4.4.4.4 ESP_RC5
569 The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].
571 4.4.4.5 ESP_IDEA
573 The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].
575 4.4.4.6 ESP_CAST
577 The ESP_CAST type specifies the CAST transform defined in [ESPCBC].
579 4.4.4.7 ESP_BLOWFISH
581 The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
582 [ESPCBC].
584 4.4.4.8 ESP_3IDEA
586 The ESP_3IDEA type is reserved for triple-IDEA.
588 4.4.4.9 ESP_DES_IV32
590 The ESP_DES_IV32 type specifies the DES-CBC transform defined in
591 RFC-1827 and RFC-1829 using a 32-bit IV.
593 4.4.4.10 ESP_RC4
595 The ESP_RC4 type is reserved for RC4.
597 4.4.4.11 ESP_NULL
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.
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.
609 4.4.5 IPSEC IPCOMP Transform Identifiers
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
618 Piper Standards Track [Page 11]
619 \f
620 RFC 2407 IP Security Domain of Interpretation November 1998
623 IPSEC DOI.
625 Transform ID Value
626 ------------ -----
627 RESERVED 0
628 IPCOMP_OUI 1
629 IPCOMP_DEFLATE 2
630 IPCOMP_LZS 3
632 4.4.5.1 IPCOMP_OUI
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.
638 4.4.5.2 IPCOMP_DEFLATE
640 The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
641 algorithm as specified in [DEFLATE].
643 4.4.5.3 IPCOMP_LZS
645 The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
646 algorithm as specified in [LZS].
648 4.5 IPSEC Security Association Attributes
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.
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.
674 Piper Standards Track [Page 12]
675 \f
676 RFC 2407 IP Security Domain of Interpretation November 1998
679 Attribute Types
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
693 Class Values
695 SA Life Type
696 SA Duration
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:
703 RESERVED 0
704 seconds 1
705 kilobytes 2
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.
713 If unspecified, the default value shall be assumed to be
714 28800 seconds (8 hours).
716 An SA Life Duration attribute MUST always follow an SA Life
717 Type which describes the units of duration.
719 See Section 4.5.4 for additional information relating to
720 lifetime notification.
722 Group Description
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].
730 Piper Standards Track [Page 13]
731 \f
732 RFC 2407 IP Security Domain of Interpretation November 1998
735 Encapsulation Mode
736 RESERVED 0
737 Tunnel 1
738 Transport 2
740 Values 3-61439 are reserved to IANA. Values 61440-65535 are
741 for private use.
743 If unspecified, the default value shall be assumed to be
744 unspecified (host-dependent).
746 Authentication Algorithm
747 RESERVED 0
748 HMAC-MD5 1
749 HMAC-SHA 2
750 DES-MAC 3
751 KPDK 4
753 Values 5-61439 are reserved to IANA. Values 61440-65535 are
754 for private use.
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.
760 When negotiating ESP without authentication, the Auth
761 Algorithm attribute MUST NOT be included in the proposal.
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.
767 Key Length
768 RESERVED 0
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.
775 Key Rounds
776 RESERVED 0
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.
786 Piper Standards Track [Page 14]
787 \f
788 RFC 2407 IP Security Domain of Interpretation November 1998
791 Compression Dictionary Size
792 RESERVED 0
794 Specifies the log2 maximum size of the dictionary.
796 There is no default value for dictionary size.
798 Compression Private Algorithm
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.
805 4.5.1 Required Attribute Support
807 To ensure basic interoperability, all implementations MUST be
808 prepared to negotiate all of the following attributes.
810 SA Life Type
811 SA Duration
812 Auth Algorithm
814 4.5.2 Attribute Parsing Requirement (Lifetime)
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.
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.)
828 Attribute #1:
829 0x80010001 (AF = 1, type = SA Life Type, value = seconds)
831 Attribute #2:
832 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
833 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours)
835 Attribute #3:
836 0x80010002 (AF = 1, type = SA Life Type, value = KB)
842 Piper Standards Track [Page 15]
843 \f
844 RFC 2407 IP Security Domain of Interpretation November 1998
847 Attribute #4:
848 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
849 0x000186A0 (value = 0x186A0 = 100000KB = 100MB)
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.
855 4.5.3 Attribute Negotiation
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.
862 If an implementation receives an attribute value in the reserved
863 range, an implementation MAY chose to continue based on local policy.
865 4.5.4 Lifetime Notification
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.
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.
885 4.6 IPSEC Payload Content
887 The following sections describe those ISAKMP payloads whose data
888 representations are dependent on the applicable DOI.
890 4.6.1 Security Association Payload
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.
898 Piper Standards Track [Page 16]
899 \f
900 RFC 2407 IP Security Domain of Interpretation November 1998
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
930 Figure 1: Security Association Payload Format
932 The Security Association Payload is defined as follows:
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).
938 o RESERVED (1 octet) - Unused, must be zero (0).
940 o Payload Length (2 octets) - Length, in octets, of the current
941 payload, including the generic header.
943 o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
944 which has been assigned the value one (1).
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.
954 Piper Standards Track [Page 17]
955 \f
956 RFC 2407 IP Security Domain of Interpretation November 1998
959 o Labeled Domain Identifier (4 octets) - IANA Assigned Number used
960 to interpret the Secrecy and Integrity information.
962 o Secrecy Length (2 octets) - Specifies the length, in octets, of
963 the secrecy level identifier, excluding pad bits.
965 o RESERVED (2 octets) - Unused, must be zero (0).
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.
971 o Secrecy Category Length (2 octets) - Specifies the length, in
972 bits, of the secrecy category (compartment) bitmap, excluding
973 pad bits.
975 o RESERVED (2 octets) - Unused, must be zero (0).
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.
982 o Integrity Length (2 octets) - Specifies the length, in octets,
983 of the integrity level identifier, excluding pad bits.
985 o RESERVED (2 octets) - Unused, must be zero (0).
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.
991 o Integrity Category Length (2 octets) - Specifies the length, in
992 bits, of the integrity category (compartment) bitmap, excluding
993 pad bits.
995 o RESERVED (2 octets) - Unused, must be zero (0).
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.
1002 4.6.1.1 IPSEC Labeled Domain Identifiers
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.
1010 Piper Standards Track [Page 18]
1011 \f
1012 RFC 2407 IP Security Domain of Interpretation November 1998
1015 Domain Value
1016 ------- -----
1017 RESERVED 0
1019 4.6.2 Identification Payload Content
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.
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.
1036 The following diagram illustrates the content of the Identification
1037 Payload.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1048 Figure 2: Identification Payload Format
1050 The Identification Payload fields are defined as follows:
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).
1056 o RESERVED (1 octet) - Unused, must be zero (0).
1058 o Payload Length (2 octets) - Length, in octets, of the
1059 identification data, including the generic header.
1061 o Identification Type (1 octet) - Value describing the identity
1062 information found in the Identification Data field.
1066 Piper Standards Track [Page 19]
1067 \f
1068 RFC 2407 IP Security Domain of Interpretation November 1998
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.
1075 o Port (2 octets) - Value specifying an associated port. A value
1076 of zero means that the Port field should be ignored.
1078 o Identification Data (variable length) - Value, as indicated by
1079 the Identification Type.
1081 4.6.2.1 Identification Type Values
1083 The following table lists the assigned values for the Identification
1084 Type field found in the Identification Payload.
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
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.
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.
1109 4.6.2.2 ID_IPV4_ADDR
1111 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
1113 4.6.2.3 ID_FQDN
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.
1122 Piper Standards Track [Page 20]
1123 \f
1124 RFC 2407 IP Security Domain of Interpretation November 1998
1127 4.6.2.4 ID_USER_FQDN
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.
1133 4.6.2.5 ID_IPV4_ADDR_SUBNET
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.
1141 4.6.2.6 ID_IPV6_ADDR
1143 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
1144 address.
1146 4.6.2.7 ID_IPV6_ADDR_SUBNET
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.
1154 4.6.2.8 ID_IPV4_ADDR_RANGE
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.
1162 4.6.2.9 ID_IPV6_ADDR_RANGE
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.
1170 4.6.2.10 ID_DER_ASN1_DN
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.
1178 Piper Standards Track [Page 21]
1179 \f
1180 RFC 2407 IP Security Domain of Interpretation November 1998
1183 4.6.2.11 ID_DER_ASN1_GN
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.
1189 4.6.2.12 ID_KEY_ID
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.
1196 4.6.3 IPSEC Notify Message Types
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.
1203 Notify Messages - Error Types Value
1204 ----------------------------- -----
1205 RESERVED 8192
1207 Notify Messages - Status Types Value
1208 ------------------------------ -----
1209 RESPONDER-LIFETIME 24576
1210 REPLAY-STATUS 24577
1211 INITIAL-CONTACT 24578
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.
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.
1234 Piper Standards Track [Page 22]
1235 \f
1236 RFC 2407 IP Security Domain of Interpretation November 1998
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.
1245 4.6.3.1 RESPONDER-LIFETIME
1247 The RESPONDER-LIFETIME status message may be used to communicate the
1248 IPSEC SA lifetime chosen by the responder.
1250 When present, the Notification Payload MUST have the following
1251 format:
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)
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.
1269 4.6.3.2 REPLAY-STATUS
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.
1275 When present, the Notification Payload MUST have the following
1276 format:
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:
1290 Piper Standards Track [Page 23]
1291 \f
1292 RFC 2407 IP Security Domain of Interpretation November 1998
1295 0 = replay detection disabled
1296 1 = replay detection enabled
1298 4.6.3.3 INITIAL-CONTACT
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).
1310 When present, the Notification Payload MUST have the following
1311 format:
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>
1321 4.7 IPSEC Key Exchange Requirements
1323 The IPSEC DOI introduces no additional Key Exchange types.
1325 5. Security Considerations
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.
1334 6. IANA Considerations
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.
1346 Piper Standards Track [Page 24]
1347 \f
1348 RFC 2407 IP Security Domain of Interpretation November 1998
1351 6.1 IPSEC Situation Definition
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.
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.
1364 The upper two bits are reserved for private use amongst cooperating
1365 systems.
1367 6.2 IPSEC Security Protocol Identifiers
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.
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.
1380 The values 249-255 are reserved for private use amongst cooperating
1381 systems.
1383 6.3 IPSEC ISAKMP Transform Identifiers
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.
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.
1396 The values 249-255 are reserved for private use amongst cooperating
1397 systems.
1402 Piper Standards Track [Page 25]
1403 \f
1404 RFC 2407 IP Security Domain of Interpretation November 1998
1407 6.4 IPSEC AH Transform Identifiers
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]).
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.
1420 The values 249-255 are reserved for private use amongst cooperating
1421 systems.
1423 6.5 IPSEC ESP Transform Identifiers
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]).
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.
1436 The values 249-255 are reserved for private use amongst cooperating
1437 systems.
1439 6.6 IPSEC IPCOMP Transform Identifiers
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.
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.
1458 Piper Standards Track [Page 26]
1459 \f
1460 RFC 2407 IP Security Domain of Interpretation November 1998
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.
1468 6.7 IPSEC Security Association Attributes
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.
1478 The values 32001-32767 are reserved for private use amongst
1479 cooperating systems.
1481 6.8 IPSEC Labeled Domain Identifiers
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.
1490 The values 0x80000000-0xffffffff are reserved for private use amongst
1491 cooperating systems.
1493 6.9 IPSEC Identification Type
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.
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.
1506 The values 249-255 are reserved for private use amongst cooperating
1507 systems.
1514 Piper Standards Track [Page 27]
1515 \f
1516 RFC 2407 IP Security Domain of Interpretation November 1998
1519 6.10 IPSEC Notify Message Types
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.
1528 The values 16001-16383 and the values 32001-32767 are reserved for
1529 private use amongst cooperating systems.
1531 7. Change Log
1533 7.1 Changes from V9
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
1542 7.2 Changes from V8
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
1549 7.3 Changes from V7
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
1564 7.4 Changes from V6
1566 The following changes were made relative to the IPSEC DOI V6:
1570 Piper Standards Track [Page 28]
1571 \f
1572 RFC 2407 IP Security Domain of Interpretation November 1998
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
1585 7.5 Changes from V5
1587 The following changes were made relative to the IPSEC DOI V5:
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
1598 7.6 Changes from V4
1600 The following changes were made relative to the IPSEC DOI V4:
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
1616 7.7 Changes from V3 to V4
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:
1621 o added ESP transform identifiers for NULL and ARCFOUR
1626 Piper Standards Track [Page 29]
1627 \f
1628 RFC 2407 IP Security Domain of Interpretation November 1998
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)
1645 Acknowledgments
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.
1652 References
1654 [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
1655 2402, November 1998.
1657 [ARCH] Kent, S., and R. Atkinson, "Security Architecture for the
1658 Internet Protocol", RFC 2401, November 1998.
1660 [DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
1661 2394, August 1998.
1663 [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security
1664 Payload (ESP)", RFC 2406, November 1998.
1666 [ESPCBC] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher
1667 Algorithms", RFC 2451, November 1998.
1669 [ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and
1670 Its Use With IPsec", RFC 2410, November 1998.
1672 [DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
1673 Algorithm With Explicit IV", RFC 2405, November 1998.
1675 [HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP
1676 and AH", RFC 2403, November 1998.
1682 Piper Standards Track [Page 30]
1683 \f
1684 RFC 2407 IP Security Domain of Interpretation November 1998
1687 [HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
1688 ESP and AH", RFC 2404, November 1998.
1690 [IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange
1691 (IKE)", RFC 2409, November 1998.
1693 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
1694 Payload Compression Protocol (IPComp)", RFC 2393, August
1695 1998.
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.
1701 [LZS] Friend, R., and R. Monsour, "IP Payload Compression Using
1702 LZS", RFC 2395, August 1998.
1704 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC
1705 2412, November 1998.
1707 [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
1708 Interconnection - The Directory: Models", CCITT/ITU
1709 Recommendation X.501, 1993.
1711 [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
1712 Interconnection - The Directory: Authentication
1713 Framework", CCITT/ITU Recommendation X.509, 1993.
1715 Author's Address
1717 Derrell Piper
1718 Network Alchemy
1719 1521.5 Pacific Ave
1720 Santa Cruz, California, 95060
1721 United States of America
1723 Phone: +1 408 460-3822
1724 EMail: ddp@network-alchemy.com
1738 Piper Standards Track [Page 31]
1739 \f
1740 RFC 2407 IP Security Domain of Interpretation November 1998
1743 Full Copyright Statement
1745 Copyright (C) The Internet Society (1998). All Rights Reserved.
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.
1761 The limited permissions granted above are perpetual and will not be
1762 revoked by the Internet Society or its successors or assigns.
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.
1794 Piper Standards Track [Page 32]
1795 \f