idnits 2.17.1 draft-ietf-ipsec-ipsec-doi-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ROADMAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 75: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 76: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 84: '...nown identifiers MUST be registered wi...' RFC 2119 keyword, line 112: '... implementations MUST support SIT_IDEN...' RFC 2119 keyword, line 114: '... exchanges ([IKE], Section 5) and MUST abort any association setup...' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 1997) is 9926 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 78, but not defined == Missing Reference: 'STD-2' is mentioned on line 82, but not defined == Missing Reference: 'RFC-1510' is mentioned on line 320, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Missing Reference: 'RFC-2093' is mentioned on line 321, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-03 -- Possible downref: Normative reference to a draft: ref. 'ARCFOUR' == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-02 -- Possible downref: Normative reference to a draft: ref. 'BLOW' -- Possible downref: Normative reference to a draft: ref. 'CAST' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-ciph-des-expiv is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '3DES' -- Possible downref: Normative reference to a draft: ref. 'DESMAC' -- Possible downref: Normative reference to a draft: ref. 'IDEA' == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IKE') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-oakley is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'OAKLEY') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-doc-roadmap is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-doc-roadmap (ref. 'ROADMAP') == Outdated reference: A later version (-05) exists of draft-mcdonald-pf-key-v2-03 ** Downref: Normative reference to an Informational draft: draft-mcdonald-pf-key-v2 (ref. 'PFKEY') -- Possible downref: Normative reference to a draft: ref. 'RC5' Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Derrell Piper 3 INTERNET-DRAFT Network Alchemy 4 draft-ietf-ipsec-ipsec-doi-07.txt February 13, 1997 6 The Internet IP Security Domain of Interpretation for ISAKMP 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this memo is unlimited. This draft will expire six 28 months from date of issue. 30 1. Abstract 32 The Internet Security Association and Key Management Protocol 33 (ISAKMP) defines a framework for security association management and 34 cryptographic key establishment for the Internet. This framework 35 consists of defined exchanges, payloads, and processing guidelines 36 that occur within a given Domain of Interpretation (DOI). This 37 document defines the Internet IP Security DOI (IPSEC DOI), which 38 instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate 39 security associations. 41 For a description of how the IPSEC DOI fits into the overall IP 42 Security Documentation framework, please see [ROADMAP]. 44 For a list of changes since the previous version of the IPSEC DOI, 45 please see Section 7. 47 2. Introduction 49 Within ISAKMP, a Domain of Interpretation is used to group related 50 protocols using ISAKMP to negotiate security associations. Security 51 protocols sharing a DOI choose security protocol and cryptographic 52 transforms from a common namespace and share key exchange protocol 53 identifiers. They also share a common interpretation of DOI-specific 54 payload data content, including the Security Association and 55 Identification payloads. 57 Overall, ISAKMP places the following requirements on a DOI 58 definition: 60 o define the naming scheme for DOI-specific protocol identifiers 61 o define the interpretation for the Situation field 62 o define the set of applicable security policies 63 o define the syntax for DOI-specific SA Attributes (Phase II) 64 o define the syntax for DOI-specific payload contents 65 o define additional Key Exchange types, if needed 66 o define additional Notification Message types, if needed 68 The remainder of this document details the instantiation of these 69 requirements for using the IP Security (IPSEC) protocols to provide 70 authentication, integrity, and/or confidentiality for IP packets sent 71 between cooperating host systems and/or firewalls. 73 3. Terms and Definitions 75 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 76 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 77 document, are to be interpreted as described in [RFC 2119]. 79 4.1 IPSEC Naming Scheme 81 Within ISAKMP, all DOI's must be registered with the IANA in the 82 ``Assigned Numbers'' RFC [STD-2]. The IANA Assigned Number for the 83 Internet IP Security DOI (IPSEC DOI) is one (1). Within the IPSEC 84 DOI, all well-known identifiers MUST be registered with the IANA 85 under the IPSEC DOI. Unless otherwise noted, all tables within this 86 document refer to IANA Assigned Numbers for the IPSEC DOI. See 87 Section 6 for further information relating to the IANA registry for 88 the IPSEC DOI. 90 All multi-octet binary values are stored in network byte order. 92 4.2 IPSEC Situation Definition 94 Within ISAKMP, the Situation provides information that can be used by 95 the responder to make a policy determination about how to process the 96 incoming Security Association request. For the IPSEC DOI, the 97 Situation field is a four (4) octet bitmask with the following 98 values. 100 Situation Value 101 --------- ----- 102 SIT_IDENTITY_ONLY 0x01 103 SIT_SECRECY 0x02 104 SIT_INTEGRITY 0x04 106 4.2.1 SIT_IDENTITY_ONLY 108 The SIT_IDENTITY_ONLY type specifies that the security association 109 will be identified by source identity information present in an 110 associated Identification Payload. See Section 4.6.2 for a complete 111 description of the various Identification types. All IPSEC DOI 112 implementations MUST support SIT_IDENTITY_ONLY by including an 113 Identification Payload in at least one of the Phase I Oakley 114 exchanges ([IKE], Section 5) and MUST abort any association setup 115 that does not include an Identification Payload. 117 If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the 118 situation consists only of the 4 octet situation bitmap and does not 119 include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) 120 or any subsequent label information. Conversely, if the initiator 121 supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain 122 Identifier MUST be included in the situation payload. 124 4.2.2 SIT_SECRECY 126 The SIT_SECRECY type specifies that the security association is being 127 negotiated in an environment that requires labeled secrecy. If 128 SIT_SECRECY is present in the Situation bitmap, the Situation field 129 will be followed by variable-length data that includes a sensitivity 130 level and compartment bitmask. See Section 4.6.1 for a complete 131 description of the Security Association Payload format. 133 If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be 134 set in the Situation bitmap and no secrecy level or category bitmaps 135 shall be included. 137 If a responder does not support SIT_SECRECY, a SITUATION-NOT- 138 SUPPORTED Notification Payload SHOULD be returned and the security 139 association setup MUST be aborted. 141 4.2.3 SIT_INTEGRITY 143 The SIT_INTEGRITY type specifies that the security association is 144 being negotiated in an environment that requires labeled integrity. 145 If SIT_INTEGRITY is present in the Situation bitmap, the Situation 146 field will be followed by variable-length data that includes an 147 integrity level and compartment bitmask. If SIT_SECRECY is also in 148 use for the association, the integrity information immediately 149 follows the variable-length secrecy level and categories. See 150 section 4.6.1 for a complete description of the Security Association 151 Payload format. 153 If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST 154 NOT be set in the Situation bitmap and no integrity level or category 155 bitmaps shall be included. 157 If a responder does not support SIT_INTEGRITY, a SITUATION-NOT- 158 SUPPORTED Notification Payload SHOULD be returned and the security 159 association setup MUST be aborted. 161 4.3 IPSEC Security Policy Requirements 163 The IPSEC DOI does not impose specific security policy requirements 164 on any implementation. Host system policy issues are outside of the 165 scope of this document. 167 However, the following sections touch on some of the issues that must 168 be considered when designing an IPSEC DOI host implementation. This 169 section should be considered only informational in nature. 171 4.3.1 Key Management Issues 173 It is expected that many systems choosing to implement ISAKMP will 174 strive to provide a protected domain of execution for a combined IKE 175 key management daemon. On protected-mode multiuser operating 176 systems, this key management daemon will likely exist as a separate 177 privileged process. 179 In such an environment, a formalized API to introduce keying material 180 into the TCP/IP kernel may be desirable. The PF_KEY API [PFKEY] is 181 an example of one such API that provides an abstracted key management 182 interface. The IP Security architecture does not place any 183 requirements for structure or flow between a host TCP/IP kernel and 184 its key management provider. 186 4.3.2 Static Keying Issues 188 Host systems that implement static keys, either for use directly by 189 IPSEC, or for authentication purposes (see [IKE] Section 5.4), should 190 take steps to protect the static keying material when it is not 191 residing in a protected memory domain or actively in use by the 192 TCP/IP kernel. 194 For example, on a laptop, one might choose to store the static keys 195 in a configuration store that is, itself, encrypted under a private 196 password. 198 Depending on the operating system and utility software installed, it 199 may not be possible to protect the static keys once they've been 200 loaded into the TCP/IP kernel, however they should not be trivially 201 recoverable on initial system startup without having to satisfy some 202 additional form of authentication. 204 4.3.3 Host Policy Issues 206 It is not realistic to assume that the transition to IPSEC will occur 207 overnight. Host systems must be prepared to implement flexible 208 policy lists that describe which systems they desire to speak 209 securely with and which systems they require speak securely to them. 210 Some notion of proxy firewall addresses may also be required. 212 A minimal approach is probably a static list of IP addresses, network 213 masks, and a security required flag or flags. 215 A more flexible implementation might consist of a list of wildcard 216 DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional 217 firewall address. The wildcard DNS name would be used to match 218 incoming or outgoing IP addresses, the in/out bitmask would be used 219 to determine whether or not security was to be applied and in which 220 direction, and the optional firewall address would be used to 221 indicate whether or not tunnel mode would be needed to talk to the 222 target system though an intermediate firewall. 224 4.3.4 Certificate Management 226 Host systems implementing a certificate-based authentication scheme 227 will need a mechanism for obtaining and managing a database of 228 certificates. 230 Secure DNS is to be one certificate distribution mechanism, however 231 the pervasive availability of secure DNS zones, in the short term, is 232 doubtful for many reasons. What's far more likely is that hosts will 233 need an ability to import certificates that they acquire through 234 secure, out-of-band mechanisms, as well as an ability to export their 235 own certificates for use by other systems. 237 However, manual certificate management should not be done so as to 238 preclude the ability to introduce dynamic certificate discovery 239 mechanisms and/or protocols as they become available. 241 4.4 IPSEC Assigned Numbers 243 The following sections list the Assigned Numbers for the IPSEC DOI: 244 Situation Identifiers, Protocol Identifiers, Transform Identifiers, 245 AH, ESP, and IPCOMP Transform Identifiers, Security Association 246 Attribute Type Values, Labeled Domain Identifiers, ID Payload Type 247 Values, and Notify Message Type Values. 249 4.4.1 IPSEC Security Protocol Identifier 251 The ISAKMP proposal syntax was specifically designed to allow for the 252 simultaneous negotiation of multiple security protocol suites within 253 a single negotiation. As a result, the protocol suites listed below 254 form the set of protocols that can be negotiated at the same time. 255 It is a host policy decision as to what protocol suites might be 256 negotiated together. 258 The following table lists the values for the Security Protocol 259 Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC 260 DOI. 262 Protocol ID Value 263 ----------- ----- 264 RESERVED 0 265 PROTO_ISAKMP 1 266 PROTO_IPSEC_AH 2 267 PROTO_IPSEC_ESP 3 268 PROTO_IPCOMP 4 270 4.4.1.1 PROTO_ISAKMP 271 The PROTO_ISAKMP type specifies message protection required during 272 Phase I of the ISAKMP protocol. The specific protection mechanism 273 used for the IPSEC DOI is described in [IKE]. All implementations 274 within the IPSEC DOI MUST support PROTO_ISAKMP. 276 NB: ISAKMP reserves the value one (1) across all DOI definitions. 278 4.4.1.2 PROTO_IPSEC_AH 280 The PROTO_IPSEC_AH type specifies IP packet authentication. The 281 default AH transform provides data origin authentication, integrity 282 protection, and replay prevention. For export control 283 considerations, confidentiality MUST NOT be provided by any 284 PROTO_IPSEC_AH transform. 286 4.4.1.3 PROTO_IPSEC_ESP 288 The PROTO_IPSEC_ESP type specifies IP packet confidentiality. 289 Authentication, if required, must be provided as part of the ESP 290 transform. The default ESP transform includes data origin 291 authentication, integrity protection, replay prevention, and 292 confidentiality. 294 4.4.1.4 PROTO_IPCOMP 296 The PROTO_IPCOMP type specifies IP packet compression. 298 4.4.2 IPSEC ISAKMP Transform Identifiers 300 As part of an ISAKMP Phase I negotiation, the initiator's choice of 301 Key Exchange offerings is made using some host system policy 302 description. The actual selection of Key Exchange mechanism is made 303 using the standard ISAKMP Proposal Payload. The following table 304 lists the defined ISAKMP Phase I Transform Identifiers for the 305 Proposal Payload for the IPSEC DOI. 307 Transform Value 308 --------- ----- 309 RESERVED 0 310 KEY_IKE 1 312 Within the ISAKMP and IPSEC DOI framework it is possible to define 313 key establishment protocols other than IKE (Oakley). Previous 314 versions of this document defined types both for manual keying and 315 for schemes based on use of a generic Key Distribution Center (KDC). 316 These identifiers have been removed from the current document. 318 The IPSEC DOI can still be extended later to include values for 319 additional non-Oakley key establishment protocols for ISAKMP and 320 IPSEC, such as Kerberos [RFC-1510] or the Group Key Management 321 Protocol (GKMP) [RFC-2093]. 323 4.4.2.1 KEY_IKE 325 The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman 326 key exchange (IKE) as defined in the [IKE] document. All 327 implementations within the IPSEC DOI MUST support KEY_IKE. 329 4.4.3 IPSEC AH Transform Identifiers 331 The Authentication Header Protocol (AH) defines one mandatory and 332 several optional transforms used to provide authentication, 333 integrity, and replay detection. The following table lists the 334 defined AH Transform Identifiers for the ISAKMP Proposal Payload for 335 the IPSEC DOI. 337 Transform ID Value 338 ------------ ----- 339 RESERVED 0-1 340 AH_MD5 2 341 AH_SHA 3 342 AH_DES 4 344 4.4.3.1 AH_MD5 346 The AH_MD5 type specifies a generic AH transform using MD5. The 347 actual protection suite is determined in concert with an associated 348 SA attribute list. A generic MD5 transform is currently undefined. 350 All implementations within the IPSEC DOI MUST support AH_MD5 along 351 with the Auth(HMAC-MD5) attribute. This suite is defined as the 352 HMAC-MD5-96 transform described in [HMACMD5]. 354 The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH 355 transform (Key/Pad/Data/Key) described in RFC-1826. This mode MAY be 356 negotiated for compatibility with older implementations. 357 Implementations are not required to support this mode. 359 4.4.3.2 AH_SHA 361 The AH_SHA type specifies a generic AH transform using SHA-1. The 362 actual protection suite is determined in concert with an associated 363 SA attribute list. A generic SHA transform is currently undefined. 365 All implementations within the IPSEC DOI MUST support AH_SHA along 366 with the Auth(HMAC-SHA) attribute. This suite is defined as the 367 HMAC-SHA-1-96 transform described in [HMACSHA]. 369 4.4.3.3 AH_DES 371 The AH_DES type specifies a generic AH transform using DES. The 372 actual protection suite is determined in concert with an associated 373 SA attribute list. A generic DES transform is currently undefined. 375 The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute 376 to be the DES-MAC transform described in [DESMAC]. Implementations 377 are not required to support this mode. 379 4.4.4 IPSEC ESP Transform Identifiers 381 The Encapsulating Security Payload (ESP) defines one mandatory and 382 many optional transforms used to provide data confidentiality. The 383 following table lists the defined ESP Transform Identifiers for the 384 ISAKMP Proposal Payload for the IPSEC DOI. 386 Transform ID Value 387 ------------ ----- 388 ESP_NULL 0 389 ESP_DES_IV64 1 390 ESP_DES 2 391 ESP_3DES 3 392 ESP_RC5 4 393 ESP_IDEA 5 394 ESP_CAST 6 395 ESP_BLOWFISH 7 396 ESP_3IDEA 8 397 ESP_DES_IV32 9 398 ESP_RC4 10 400 4.4.4.1 ESP_NULL 402 The ESP_NULL type specifies no confidentiality is to be provided by 403 ESP. ESP_NULL is used when ESP is being used to tunnel packets which 404 require only authentication and integrity protection. See the Auth 405 Algorithm attribute description in Section 4.5 for additional 406 requirements relating to the use of ESP_NULL. 408 4.4.4.2 ESP_DES_IV64 410 The ESP_DES_IV64 type specifies the DES-CBC transform defined in 411 RFC-1827 and RFC-1829 using a 64-bit IV. This mode MAY be negotiated 412 for compatibility with older implementations. Implementations are 413 not required to support this mode. 415 4.4.4.3 ESP_DES 417 The ESP_DES type specifies a generic DES transform using DES-CBC. 418 The actual protection suite is determined in concert with an 419 associated SA attribute list. A generic transform is currently 420 undefined. 422 All implementations within the IPSEC DOI MUST support ESP_DES along 423 with the Auth(HMAC-MD5) attribute. This suite is defined as the 424 [DES] transform, with authentication and integrity provided by HMAC 425 MD5. 427 4.4.4.4 ESP_3DES 429 The ESP_3DES type specifies a generic triple-DES transform. The 430 actual protection suite is determined in concert with an associated 431 SA attribute list. The generic transform is currently undefined. 433 All implementations within the IPSEC DOI are strongly encourage to 434 support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite 435 is defined as the [3DES] transform, with authentication and integrity 436 provided by HMAC MD5. 438 4.4.4.5 ESP_RC5 440 The ESP_RC5 type specifies the RC5 transform defined in [RC5]. 442 4.4.4.6 ESP_IDEA 444 The ESP_IDEA type specifies the IDEA transform defined in [IDEA]. 446 4.4.4.7 ESP_CAST 448 The ESP_CAST type specifies the CAST transform defined in [CAST]. 450 4.4.4.8 ESP_BLOWFISH 452 The ESP_BLOWFISH type specifies the BLOWFISH transform defined in 453 [BLOW]. 455 4.4.4.9 ESP_3IDEA 457 The ESP_3IDEA type is reserved for triple-IDEA. 459 4.4.4.10 ESP_DES_IV32 461 The ESP_DES_IV32 type specifies the DES-CBC transform defined in 462 RFC-1827 and RFC-1829 using a 32-bit IV. This mode MAY be negotiated 463 for compatibility with older implementations. Implementations are 464 not required to support this mode. 466 4.4.4.11 ESP_RC4 468 The ESP_RC4 type specifies the RC4 transform. An RC4 compatible 469 transform is described in [ARCFOUR]. 471 4.4.5 IPSEC IPCOMP Transform Identifiers 473 The IP Compression (IPCOMP) transforms define optional compression 474 algorithms that can be negotiated to provide for IP compression 475 before ESP encryption. The following table lists the defined IPCOMP 476 Transform Identifiers for the ISAKMP Proposal Payload within the 477 IPSEC DOI. 479 Transform ID Value 480 ------------ ----- 481 RESERVED 0 482 IPCOMP_OUI 1 483 IPCOMP_DEFLATE 2 484 IPCOMP_LZS 3 485 IPCOMP_V42BIS 4 487 4.4.5.1 IPCOMP_OUI 489 The IPCOMP_OUI type specifies a proprietary compression transform. 490 The IPCOMP_OUI type must be accompanied by an attribute which further 491 identifies the specific vendor algorithm. 493 4.4.5.2 IPCOMP_DEFLATE 495 The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate 496 algorithm. 498 4.4.5.3 IPCOMP_LZS 500 The IPCOMP_LZS type specifies the use of the Stac Electronics LZS 501 algorithm. 503 4.4.5.4 IPCOMP_V42BIS 505 The IPCOMP_V42BIS type specifies the use of V42bis compression. 507 4.5 IPSEC Security Association Attributes 509 The following SA attribute definitions are used in Phase II of an IKE 510 negotiation. Attribute types can be either Basic (B) or Variable- 511 Length (V). Encoding of these attributes is defined in the base 512 ISAKMP specification. 514 IPSEC DOI attributes that at defined as basic-only (B) MUST NOT be 515 encoded as variable-length (V). See [IKE] for further information on 516 attribute encoding in the IPSEC DOI. All restrictions listed in 517 [IKE] apply to the IPSEC DOI. 519 Attribute Types 521 class value type 522 ------------------------------------------------- 523 SA Life Type 1 B 524 SA Life Duration 2 B/V 525 Group Description 3 B 526 Encapsulation Mode 4 B 527 Authentication Algorithm 5 B 528 Key Length 6 B 529 Key Rounds 7 B 530 Compress Dictionary Size 8 B 531 Compress Private Algorithm 9 B/V 533 Class Values 535 SA Life Type 536 SA Duration 538 Specifies the time-to-live for the overall security 539 association. When the SA expires, all keys negotiated under 540 the association (AH or ESP) must be renegotiated. The life 541 type values are: 543 RESERVED 0 544 seconds 1 545 kilobytes 2 547 Values 3-61439 are reserved to IANA. Values 61440-65535 are 548 for private use. For a given Life Type, the value of the 549 Life Duration attribute defines the actual length of the 550 component lifetime -- either a number of seconds, or a number 551 of Kbytes that can be protected. 553 If unspecified, the default value shall be assumed to be 554 28800 seconds (8 hours). 556 An SA Life Duration attribute MUST always follow an SA Life 557 Type which describes the units of duration. 559 See Section 4.5.4 for additional information relating to 560 lifetime notification. 562 Group Description 564 Specifies the Oakley Group to be used in a PFS QM 565 negotiation. For a list of supported values, see Appendix A 566 of [IKE]. 568 Encapsulation Mode 569 RESERVED 0 570 Tunnel 1 571 Transport 2 573 Values 3-61439 are reserved to IANA. Values 61440-65535 are 574 for private use. 576 If unspecified, the default value shall be assumed to be 577 unspecified (host-dependent). 579 Authentication Algorithm 580 RESERVED 0 581 HMAC-MD5 1 582 HMAC-SHA-1 2 583 DES-MAC 3 584 KPDK 4 586 Values 5-61439 are reserved to IANA. Values 61440-65535 are 587 for private use. 589 There is no default value for Auth Algorithm, as it must be 590 specified to correctly identify the applicable AH or ESP 591 transform, except in the following case. 593 When negotiating ESP without authentication, the Auth 594 Algorithm attribute MUST NOT be included in the proposal. 596 When negotiating ESP without confidentiality, the Auth 597 Algorithm attribute MUST be included in the proposal and 598 the ESP transform ID must be ESP_NULL. 600 Key Length 601 RESERVED 0 603 There is no default value for Key Length, as it must be 604 specified for transforms using ciphers with variable key 605 lengths. For fixed length ciphers, the Key Length attribute 606 MUST NOT be sent. 608 Key Rounds 609 RESERVED 0 611 There is no default value for Key Rounds, as it must be 612 specified for transforms using ciphers with varying 613 numbers of rounds. 615 Compression Dictionary Size 616 RESERVED 0 618 Specifies the log2 maximum size of the dictionary. 620 There is no default value for dictionary size. 622 Compression Private Algorithm 624 Specifies a private vendor compression algorithm. The first 625 three (3) octets must be an IEEE assigned company_id (OUI). 626 The next octet may be a vendor specific compression subtype, 627 followed by zero or more octets of vendor data. 629 4.5.1 Required Attribute Support 631 To ensure basic interoperability, all implementations MUST be 632 prepared to negotiate all of the following attributes. 634 SA Life Type 635 SA Duration 636 Auth Algorithm 638 4.5.2 Attribute Parsing Requirement (Lifetime) 640 To allow for flexible semantics, the IPSEC DOI requires that a 641 conforming ISAKMP implementation MUST correctly parse an attribute 642 list that contains multiple instances of the same attribute class, so 643 long as the different attribute entries do not conflict with one 644 another. Currently, the only attributes which requires this 645 treatment are Life Type and Duration. 647 To see why this is important, the following example shows the binary 648 encoding of a four entry attribute list that specifies an SA Lifetime 649 of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a 650 complete description of the attribute encoding format.) 652 Attribute #1: 653 0x80010001 (AF = 1, type = SA Life Type, value = seconds) 655 Attribute #2: 657 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 658 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) 660 Attribute #3: 661 0x80010002 (AF = 1, type = SA Life Type, value = KB) 663 Attribute #4: 664 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 665 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) 667 If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED 668 Notification Payload SHOULD be returned and the security association 669 setup MUST be aborted. 671 4.5.3 Attribute Negotiation 673 If an implementation receives a defined IPSEC DOI attribute (or 674 attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT 675 SHOULD be sent and the security association setup MUST be aborted, 676 unless the attribute value is in the reserved range. 678 If an implementation receives an attribute value in the reserved 679 range, an implementation MAY chose to continue based on local policy. 681 4.5.4 Lifetime Notification 683 When an initiator offers an SA lifetime greater than what the 684 responder desires based on their local policy, the responder has 685 three choices: 1) fail the negotiation entirely; 2) complete the 686 negotiation but use a shorter lifetime than what was offered; 3) 687 complete the negotiation and send an advisory notification to the 688 initiator indicating the responder's true lifetime. The choice of 689 what the responder actually does is implementation specific and/or 690 based on local policy. 692 To ensure interoperability in the latter case, the IPSEC DOI requires 693 the following only when the responder wishes to notify the initiator: 694 if the initiator offers an SA lifetime longer than the responder is 695 willing to accept, the responder SHOULD include an ISAKMP 696 Notification Payload in the exchange that includes the responder's 697 IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the 698 RESPONDER-LIFETIME Notification Message type which MUST be used for 699 this purpose. 701 4.6 IPSEC Payload Content 703 The following sections describe those ISAKMP payloads whose data 704 representations are dependent on the applicable DOI. 706 4.6.1 Security Association Payload 708 The following diagram illustrates the content of the Security 709 Association Payload for the IPSEC DOI. See Section 4.2 for a 710 description of the Situation bitmap. 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 ! Next Payload ! RESERVED ! Payload Length ! 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 ! Domain of Interpretation (IPSEC) | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 ! Situation (bitmap) ! 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 ! Labeled Domain Identifier ! 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 ! Secrecy Length (in octets) ! RESERVED ! 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 ~ Secrecy Level ~ 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 ! Secrecy Cat. Length (in bits) ! RESERVED ! 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 ~ Secrecy Category Bitmap ~ 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 ! Integrity Length (in octets) ! RESERVED ! 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 ~ Integrity Level ~ 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 ! Integ. Cat. Length (in bits) ! RESERVED ! 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 ~ Integrity Category Bitmap ~ 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 1: Security Association Payload Format 741 The Security Association Payload is defined as follows: 743 o Next Payload (1 octet) - Identifier for the payload type of 744 the next payload in the message. If the current payload is 745 the last in the message, this field will be zero (0). 747 o RESERVED (1 octet) - Unused, must be zero (0). 749 o Payload Length (2 octets) - Length, in octets, of the current 750 payload, including the generic header. 752 o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, 753 which has been assigned the value one (1). 755 o Situation (4 octets) - Bitmask used to interpret the 756 remainder of the Security Association Payload. See Section 757 4.2 for a complete list of values. 759 o Labeled Domain Identifier (4 octets) - IANA Assigned Number 760 used to interpret the Secrecy and Integrity information. 762 o Secrecy Length (2 octets) - Specifies the length, in octets, 763 of the secrecy level identifier. 765 o RESERVED (2 octets) - Unused, must be zero (0). 767 o Secrecy Category Length (2 octets) - Specifies the length, in 768 bits, of the secrecy category (compartment) bitmap, excluding 769 pad bits. 771 o RESERVED (2 octets) - Unused, must be zero (0). 773 o Secrecy Category Bitmap (variable length) - A bitmap used to 774 designate secrecy categories (compartments) that are 775 required. The bitmap MUST be padded with zero (0) to the 776 next 32-bit boundary. 778 o Integrity Length (2 octets) - Specifies the length, in 779 octets, of the integrity level identifier. 781 o RESERVED (2 octets) - Unused, must be zero (0). 783 o Integrity Category Length (2 octets) - Specifies the length, 784 in bits, of the integrity category (compartment) bitmap, 785 excluding pad bits. 787 o RESERVED (2 octets) - Unused, must be zero (0). 789 o Integrity Category Bitmap (variable length) - A bitmap used 790 to designate integrity categories (compartments) that are 791 required. The bitmap MUST be padded with zero (0) to the 792 next 32-bit boundary. 794 4.6.1.1 IPSEC Labeled Domain Identifiers 796 The following table lists the assigned values for the Labeled Domain 797 Identifier field contained in the Situation field of the Security 798 Association Payload. 800 Domain Value 801 ------- ----- 802 RESERVED 0 804 4.6.2 Identification Payload Content 806 The Identification Payload is used to identify the initiator of the 807 Security Association. The identity of the initiator SHOULD be used 808 by the responder to determine the correct host system security policy 809 requirement for the association. For example, a host might choose to 810 require authentication and integrity without confidentiality (AH) 811 from a certain set of IP addresses and full authentication with 812 confidentiality (ESP) from another range of IP addresses. The 813 Identification Payload provides information that can be used by the 814 responder to make this decision. 816 During Phase I negotiations, the ID port and protocol fields MUST be 817 set to zero or to UDP port 500. If an implementation receives any 818 other values, this MUST be treated as an error and the security 819 association setup MUST be aborted. This event SHOULD be auditable. 821 The following diagram illustrates the content of the Identification 822 Payload. 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 ! Next Payload ! RESERVED ! Payload Length ! 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 ! ID Type ! Protocol ID ! Port ! 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 ~ Identification Data ~ 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Figure 2: Identification Payload Format 835 The Identification Payload fields are defined as follows: 837 o Next Payload (1 octet) - Identifier for the payload type of 838 the next payload in the message. If the current payload is 839 the last in the message, this field will be zero (0). 841 o RESERVED (1 octet) - Unused, must be zero (0). 843 o Payload Length (2 octets) - Length, in octets, of the 844 identification data, including the generic header. 846 o Identification Type (1 octet) - Value describing the 847 identity information found in the Identification Data field. 849 o Protocol ID (1 octet) - Value specifying an associated 850 IP protocol ID (e.g. UDP/TCP). A value of zero means that the 851 Protocol ID field should be ignored. 853 o Port (2 octets) - Value specifying an associated port. 854 A value of zero means that the Port field should be ignored. 856 o Identification Data (variable length) - Value, as indicated 857 by the Identification Type. 859 4.6.2.1 Identification Type Values 861 The following table lists the assigned values for the Identification 862 Type field found in the Identification Payload. 864 ID Type Value 865 ------- ----- 866 RESERVED 0 867 ID_IPV4_ADDR 1 868 ID_FQDN 2 869 ID_USER_FQDN 3 870 ID_IPV4_ADDR_SUBNET 4 871 ID_IPV6_ADDR 5 872 ID_IPV6_ADDR_SUBNET 6 873 ID_IPV4_ADDR_RANGE 7 874 ID_IPV6_ADDR_RANGE 8 875 ID_DER_ASN1_DN 9 876 ID_DER_ASN1_GN 10 877 ID_KEY_ID 11 879 For types where the ID entity is variable length, the size of the ID 880 entity is computed from size in the ID payload header. 882 When an IKE exchange is authenticated using certificates (of any 883 format), any ID's used for input to local policy decisions SHOULD be 884 contained in the certificate used in the authentication of the 885 exchange. 887 4.6.2.2 ID_IPV4_ADDR 889 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 891 4.6.2.3 ID_FQDN 893 The ID_FQDN type specifies a fully-qualified domain name string. An 894 example of a ID_FQDN is, "foo.bar.com". The string should not 895 contain any terminators. 897 4.6.2.4 ID_USER_FQDN 899 The ID_USER_FQDN type specifies a fully-qualified username string, An 900 example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should 901 not contain any terminators. 903 4.6.2.5 ID_IPV4_ADDR_SUBNET 905 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, 906 represented by two four (4) octet values. The first value is an IPv4 907 address. The second is an IPv4 network mask. Note that ones (1s) in 908 the network mask indicate that the corresponding bit in the address 909 is fixed, while zeros (0s) indicate a "wildcard" bit. 911 4.6.2.6 ID_IPV6_ADDR 913 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 914 address. 916 4.6.2.7 ID_IPV6_ADDR_SUBNET 918 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, 919 represented by two sixteen (16) octet values. The first value is an 920 IPv6 address. The second is an IPv6 network mask. Note that ones 921 (1s) in the network mask indicate that the corresponding bit in the 922 address is fixed, while zeros (0s) indicate a "wildcard" bit. 924 4.6.2.8 ID_IPV4_ADDR_RANGE 926 The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, 927 represented by two four (4) octet values. The first value is the 928 beginning IPv4 address (inclusive) and the second value is the ending 929 IPv4 address (inclusive). All addresses falling between the two 930 specified addresses are considered to be within the list. 932 4.6.2.9 ID_IPV6_ADDR_RANGE 934 The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, 935 represented by two sixteen (16) octet values. The first value is the 936 beginning IPv6 address (inclusive) and the second value is the ending 937 IPv6 address (inclusive). All addresses falling between the two 938 specified addresses are considered to be within the list. 940 4.6.2.10 ID_DER_ASN1_DN 942 The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 943 X.500 Distinguished Name [X.501] of the principal whose certificates 944 are being exchanged to establish the SA. 946 4.6.2.11 ID_DER_ASN1_GN 948 The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 949 X.500 GeneralName [X.509] of the principal whose certificates are 950 being exchanged to establish the SA. 952 4.6.2.12 ID_KEY_ID 954 The ID_KEY_ID type specifies an opaque byte stream which may be used 955 to pass vendor-specific information necessary to identify which pre- 956 shared key should be used to authenticate Aggressive mode 957 negotiations. 959 4.6.3 IPSEC Notify Message Types 961 ISAKMP defines two blocks of Notify Message codes, one for errors and 962 one for status messages. ISAKMP also allocates a portion of each 963 block for private use within a DOI. The IPSEC DOI defines the 964 following private message types for its own use. 966 Notify Messages - Error Types Value 967 ----------------------------- ----- 968 RESERVED 8192 970 Notify Messages - Status Types Value 971 ------------------------------ ----- 972 RESPONDER-LIFETIME 24576 973 REPLAY-STATUS 24577 974 INITIAL-CONTACT 24578 976 Notification Status Messages MUST be sent under the protection of an 977 ISAKMP SA: either as a payload in the last Main Mode exchange; in a 978 separate Informational Exchange after Main Mode or Aggressive Mode 979 processing is complete; or as a payload in any Quick Mode exchange. 980 These messages MUST NOT be sent in Aggressive Mode exchanges unless 981 the authentication mode is RSA Encryption, since Aggressive Mode does 982 not otherwise provide the necessary protection to bind the Notify 983 Status Message to the exchange. 985 Implementation Note: the ISAKMP protocol does not guarantee delivery 986 of Notification Status messages when sent in an ISAKMP Informational 987 Exchange. To ensure receipt of any particular message, the sender 988 SHOULD include a Notification Payload in a defined Main Mode, Quick 989 Mode, or Aggressive exchange which is protected by a retransmission 990 timer. 992 4.6.3.1 RESPONDER-LIFETIME 994 The RESPONDER-LIFETIME status message may be used to communicate the 995 IPSEC SA lifetime chosen by the responder. 997 When present, the Notification Payload MUST have the following 998 format: 1000 o Payload Length - set to length of payload + size of data (var) 1001 o DOI - set to IPSEC DOI (1) 1002 o Protocol ID - set to selected Protocol ID from chosen SA 1003 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1004 o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) 1005 o SPI - set to the two ISAKMP cookies 1006 o Notification Data - contains an ISAKMP attribute list with the 1007 responder's actual SA lifetime(s) 1009 Implementation Note: saying that the Notification Data field contains 1010 an attribute list is equivalent to saying that the Notification Data 1011 field has zero length and the Notification Payload has an associated 1012 attribute list. 1014 4.6.3.2 REPLAY-STATUS 1016 The REPLAY-STATUS status message may be used for positive 1017 confirmation of the responder's election on whether or not he is to 1018 perform anti-replay detection. 1020 When present, the Notification Payload MUST have the following 1021 format: 1023 o Payload Length - set to length of payload + size of data (4) 1024 o DOI - set to IPSEC DOI (1) 1025 o Protocol ID - set to selected Protocol ID from chosen SA 1026 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1027 o Notify Message Type - set to REPLAY-STATUS 1028 o SPI - set to the two ISAKMP cookies 1029 o Notification Data - a 4 octet value: 1030 0 = replay detection disabled 1031 1 = replay detection enabled 1033 4.6.3.3 INITIAL-CONTACT 1035 The INITIAL-CONTACT status message may be used when one side wishes 1036 to inform the other that this is the first SA being established with 1037 the remote system. The receiver of this Notification Message might 1038 then elect to delete any existing SA's it has for the sending system 1039 under the assumption that the sending system has rebooted and no 1040 longer has access to the original SA's and their associated keying 1041 material. When used, the content of the Notification Data field 1042 SHOULD be null (i.e. the Payload Length should be set to the fixed 1043 length of Notification Payload). 1045 When present, the Notification Payload MUST have the following 1046 format: 1048 o Payload Length - set to length of payload + size of data (0) 1049 o DOI - set to IPSEC DOI (1) 1050 o Protocol ID - set to selected Protocol ID from chosen SA 1051 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1052 o Notify Message Type - set to INITIAL-CONTACT 1053 o SPI - set to the two ISAKMP cookies 1054 o Notification Data - 1056 4.7 IPSEC Key Exchange Requirements 1058 The IPSEC DOI introduces no additional Key Exchange types. 1060 5. Security Considerations 1062 This entire draft pertains to the Internet Key Exchange protocol 1063 ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to 1064 provide for the derivation of cryptographic keying material in a 1065 secure and authenticated manner. Specific discussion of the various 1066 security protocols and transforms identified in this document can be 1067 found in the associated base documents and in the cipher references. 1069 6. IANA Considerations 1071 This document contains many "magic" numbers to be maintained by the 1072 IANA. This section explains the criteria to be used by the IANA to 1073 assign additional numbers in each of these lists. 1075 6.1 IPSEC Situation Definition 1077 The Situation Definition is a 32-bit bitmask which represents the 1078 environment under which the IPSEC SA proposal and negotiation is 1079 carried out. Requests for assignments of new situations must be 1080 accompanied by a standards-track RFC which describes the 1081 interpretation for the associated bit. 1083 The upper two bits are reserved for private use amongst cooperating 1084 systems. 1086 6.2 IPSEC Security Protocol Identifiers 1088 The Security Protocol Identifier is an 8-bit value which identifies a 1089 security protocol suite being negotiated. Requests for assignments 1090 of new security protocol identifiers must be accompanied by a 1091 standards-track RFC which describes the requested security protocol. 1092 [AH] and [ESP] are examples of security protocol documents. 1094 The values 249-255 are reserved for private use amongst cooperating 1095 systems. 1097 6.3 IPSEC ISAKMP Transform Identifiers 1099 The IPSEC ISAKMP Transform Identifier is an 8-bit value which 1100 identifies a key exchange protocol to be used for the negotiation. 1101 Requests for assignments of new ISAKMP transform identifiers must be 1102 accompanied by a standards-track RFC which describes the requested 1103 key exchange protocol. [IKE] is an example of one such document. 1105 The values 249-255 are reserved for private use amongst cooperating 1106 systems. 1108 6.4 IPSEC AH Transform Identifiers 1110 The IPSEC AH Transform Identifier is an 8-bit value which identifies 1111 a particular algorithm to be used to provide integrity protection for 1112 AH. Requests for assignments of new AH transform identifiers must be 1113 accompanied by a standards-track RFC which describes how to use the 1114 algorithm within the AH framework ([AH]). In addition, the requested 1115 algorithm must be published and in the public domain. If the 1116 requested algorithm is not in the public domain, the addition must be 1117 approved by an IESG action. 1119 The values 249-255 are reserved for private use amongst cooperating 1120 systems. 1122 6.5 IPSEC ESP Transform Identifiers 1124 The IPSEC ESP Transform Identifier is an 8-bit value which identifies 1125 a particular algorithm to be used to provide secrecy protection for 1126 ESP. Requests for assignments of new ESP transform identifiers must 1127 be accompanied by a standards-track RFC which describes how to use 1128 the algorithm within the ESP framework ([ESP]). In addition, the 1129 requested algorithm must be published and in the public domain. If 1130 the requested algorithm is not in the public domain, the addition 1131 must be approved by an IESG action. 1133 The values 249-255 are reserved for private use amongst cooperating 1134 systems. 1136 6.6 IPSEC IPCOMP Transform Identifiers 1138 The IPSEC IPCOMP Transform Identifier is an 8-bit value which 1139 identifier a particular algorithm to be used to provide IP-level 1140 compression before ESP. Requests for assignments of new IPCOMP 1141 transform identifiers must be accompanied by a standards-track RFC 1142 which describes how to use the algorithm within the IPCOMP framework 1143 ([IPCOMP]). In addition, the requested algorithm must be published 1144 and in the public domain. If the requested algorithm is not in the 1145 public domain, the addition must be approved by an IESG action. 1147 The values 249-255 are reserved for private use amongst cooperating 1148 systems. 1150 6.7 IPSEC Security Association Attributes 1152 The IPSEC Security Association Attribute consists of a 16-bit type 1153 and its associated value. IPSEC SA attributes are used to pass 1154 miscellaneous values between ISAKMP peers. Requests for assignments 1155 of new IPSEC SA attributes must be accompanied by an Internet Draft 1156 which describes the attribute encoding (Basic/Variable-Length) and 1157 its legal values. Section 4.5 of this document provides an example 1158 of such a description. 1160 The values 32001-32767 are reserved for private use amongst 1161 cooperating systems. 1163 6.8 IPSEC Labeled Domain Identifiers 1165 The IPSEC Labeled Domain Identifier is a 32-bit value which 1166 identifies a namespace in which the Secrecy and Integrity levels and 1167 categories values are said to exist. Requests for assignments of new 1168 IPSEC Labeled Domain Identifiers should be granted on demand. No 1169 accompanying documentation is required, though Internet Drafts are 1170 encouraged when appropriate. 1172 The values 0x80000000-0xffffffff are reserved for private use amongst 1173 cooperating systems. 1175 6.9 IPSEC Identification Type 1177 The IPSEC Identification Type is an 8-bit value which is used as a 1178 discrimanent for interpretation of the variable-length Identification 1179 Payload. Requests for assignments of new IPSEC Identification Types 1180 must be accompanied by a standard-track RFC which describes how to 1181 use the identification type within IPSEC. 1183 The values 249-255 are reserved for private use amongst cooperating 1184 systems. 1186 6.10 IPSEC Notify Message Types 1188 The IPSEC Notify Message Type is an 8-bit value taken from the range 1189 of values reserved by ISAKMP for each DOI. There is one range for 1190 error message (8192-16383) and a different range for status messages 1191 (24576-32767). Requests for assignments of new Notify Message Types 1192 must be accompanied by an Internet Draft which describes how to use 1193 the identification type within IPSEC. 1195 The values 16001-16383 and the values 32001-32767 are reserved for 1196 private use amongst cooperating systems. 1198 7. Change Log 1200 7.1 Changes from V6 1202 The following changes were made relative to the IPSEC DOI V6: 1204 o added IANA Considerations section 1205 o moved most IANA numbers to IANA Considerations section 1206 o added prohibition on sending (V) encoding for (B) attributes 1207 o added prohibition on sending Key Length attribute for fixed 1208 length ciphers (e.g. DES) 1209 o replaced references to ISAKMP/Oakley with IKE 1210 o renamed ARCFOUR to RC4 1211 o updated Security Considerations section 1212 o updated document references 1214 7.2 Changes from V5 1216 The following changes were made relative to the IPSEC DOI V5: 1218 o changed SPI size in Lifetime Notification text 1219 o changed REPLAY-ENABLED to REPLAY-STATUS 1220 o moved RESPONDER-LIFETIME payload definition from Section 4.5.4 1221 to Section 4.6.3.1 1222 o added explicit payload layout for 4.6.3.3 1223 o added Implementation Note to Section 4.6.3 introduction 1224 o changed AH_SHA text to require SHA-1 in addition to MD5 1225 o updated document references 1227 7.3 Changes from V4 1229 The following changes were made relative to the IPSEC DOI V4: 1231 o moved compatibility AH KPDK authentication method from AH 1232 transform ID to Authentication Algorithm identifier 1233 o added REPLAY-ENABLED notification message type per Architecture 1234 o added INITIAL-CONTACT notification message type per list 1235 o added text to ensure protection for Notify Status messages 1236 o added Lifetime qualification to attribute parsing section 1237 o added clarification that Lifetime notification is optional 1238 o removed private Group Description list (now points at [IKE]) 1239 o replaced Terminology with pointer to RFC-2119 1240 o updated HMAC MD5 and SHA-1 ID references 1241 o updated Section 1 (Abstract) 1242 o updated Section 4.4 (IPSEC Assigned Numbers) 1243 o added restriction for ID port/protocol values for Phase I 1245 7.4 Changes from V3 to V4 1247 The following changes were made relative to the IPSEC DOI V3, that 1248 was posted to the IPSEC mailing list prior to the Munich IETF: 1250 o added ESP transform identifiers for NULL and ARCFOUR 1251 o renamed HMAC Algorithm to Auth Algorithm to accommodate 1252 DES-MAC and optional authentication/integrity for ESP 1253 o added AH and ESP DES-MAC algorithm identifiers 1254 o removed KEY_MANUAL and KEY_KDC identifier definitions 1255 o added lifetime duration MUST follow lifetype attribute to 1256 SA Life Type and SA Life Duration attribute definition 1257 o added lifetime notification and IPSEC DOI message type table 1258 o added optional authentication and confidentiality 1259 restrictions to MAC Algorithm attribute definition 1260 o corrected attribute parsing example (used obsolete attribute) 1261 o corrected several Internet Draft document references 1262 o added ID_KEY_ID per ipsec list discussion (18-Mar-97) 1263 o removed Group Description default for PFS QM ([IKE] MUST) 1265 Acknowledgments 1267 This document is derived, in part, from previous works by Douglas 1268 Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, 1269 and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran 1270 Atkinson also contributed suggestions and, in many cases, text. 1272 References 1274 [AH] Kent, S., Atkinson, R., "IP Authentication Header," draft-ietf- 1275 ipsec-auth-header-03.txt. 1277 [ARCFOUR] Thayer, R., "The ESP ARCFOUR Algorithm," draft-ietf-ipsec- 1278 ciph-arcfour-00.txt. 1280 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 1281 (ESP)," draft-ietf-ipsec-esp-v2-02.txt. 1283 [BLOW] Adams, R., "The ESP Blowfish-CBC Algorithm Using an Explicit 1284 IV," draft-ietf-ipsec-ciph-blowfish-cbc-00.txt. 1286 [CAST] Pereira, R., Carter, G., "The ESP CAST128-CBC Algorithm," 1287 draft-ietf-ipsec-ciph-cast128-cbc-00.txt. 1289 [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm 1290 With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt. 1292 [3DES] Pereira, R., Thayer, R., "The ESP 3DES-CBC Algorithm Using an 1293 Explicit IV," draft-ietf-ipsec-ciph-3des-expiv-00.txt. 1295 [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft- 1296 bitan-auth-des-mac-00.txt. 1298 [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and 1299 AH," draft-ietf-ipsec-auth-hmac-md5-96-02.txt. 1301 [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP 1302 and AH," draft-ietf-ipsec-auth-hmac-sha196-02.txt. 1304 [IDEA] Adams, R., "The ESP IDEA-CBC Algorithm Using Explicit IV," 1305 draft-ietf-ipsec-ciph-idea-cbc-00.txt. 1307 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," 1308 draft-ietf-ipsec-isakmp-oakley-06.txt. 1310 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP 1311 Payload Compression Protocol (IPComp)," draft-ietf-ippcp- 1312 protocol-05.txt. 1314 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1315 "Internet Security Association and Key Management Protocol (ISAKMP)," 1316 draft-ietf-ipsec-isakmp-08.{ps,txt}. 1318 [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft- 1319 ietf-ipsec-oakley-02.txt. 1321 [ROADMAP] Thayer, R., Doraswamy, N., Glenn, R., "IP Security 1322 Documentation Roadmap," draft-ietf-ipsec-doc-roadmap-02.txt. 1324 [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key 1325 Management API, Version 2", draft-mcdonald-pf-key-v2-03.txt. 1327 [RC5] Pereira, R., Baldwin, R., "The ESP RC5-CBC Transform," draft- 1328 ietf-ipsec-ciph-rc5-cbc-00.txt. 1330 [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems 1331 Interconnection - The Directory: Models", CCITT/ITU Recommendation 1332 X.501, 1993. 1334 [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems 1335 Interconnection - The Directory: Authentication Framework", 1336 CCITT/ITU Recommendation X.509, 1993. 1338 Author's Address: 1340 Derrell Piper 1341 Network Alchemy 1342 1521.5 Pacific Ave 1343 Santa Cruz, California, 95060 1344 United States of America 1345 +1 408 460-3822