idnits 2.17.1 draft-ietf-ipsec-ipsec-doi-09.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-03-28) 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 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 76: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 77: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 85: '...nown identifiers MUST be registered wi...' RFC 2119 keyword, line 113: '... implementations MUST support SIT_IDEN...' RFC 2119 keyword, line 115: '... exchanges ([IKE], Section 5) and MUST abort any association setup...' (50 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 (May 12, 1998) is 9452 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 79, but not defined == Missing Reference: 'STD-2' is mentioned on line 83, but not defined == Missing Reference: 'RFC-1510' is mentioned on line 318, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Missing Reference: 'RFC-2093' is mentioned on line 319, but not defined == Missing Reference: 'DESMAC' is mentioned on line 1272, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-05 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-04 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-04 == Outdated reference: A later version (-03) exists of draft-ietf-ipsec-ciph-cbc-02 -- Unexpected draft version: The latest known version of draft-ietf-ipsec-ciph-des-expiv is -01, but you're referring to -02. -- Unexpected draft version: The latest known version of draft-ietf-ipsec-auth-hmac-md5-96 is -02, but you're referring to -03. -- Unexpected draft version: The latest known version of draft-ietf-ipsec-auth-hmac-sha196 is -02, but you're referring to -03. == 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') ** 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') Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 6 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-09.txt May 12, 1998 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 view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Distribution of this memo is unlimited. This draft will expire six 29 months from date of issue. 31 1. Abstract 33 The Internet Security Association and Key Management Protocol 34 (ISAKMP) defines a framework for security association management and 35 cryptographic key establishment for the Internet. This framework 36 consists of defined exchanges, payloads, and processing guidelines 37 that occur within a given Domain of Interpretation (DOI). This 38 document defines the Internet IP Security DOI (IPSEC DOI), which 39 instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate 40 security associations. 42 For a list of changes since the previous version of the IPSEC DOI, 43 please see Section 7. 45 2. Introduction 47 Within ISAKMP, a Domain of Interpretation is used to group related 48 protocols using ISAKMP to negotiate security associations. Security 49 protocols sharing a DOI choose security protocol and cryptographic 50 transforms from a common namespace and share key exchange protocol 51 identifiers. They also share a common interpretation of DOI-specific 52 payload data content, including the Security Association and 53 Identification payloads. 55 Overall, ISAKMP places the following requirements on a DOI 56 definition: 58 o define the naming scheme for DOI-specific protocol identifiers 59 o define the interpretation for the Situation field 60 o define the set of applicable security policies 61 o define the syntax for DOI-specific SA Attributes (Phase II) 62 o define the syntax for DOI-specific payload contents 63 o define additional Key Exchange types, if needed 64 o define additional Notification Message types, if needed 66 The remainder of this document details the instantiation of these 67 requirements for using the IP Security (IPSEC) protocols to provide 68 authentication, integrity, and/or confidentiality for IP packets sent 69 between cooperating host systems and/or firewalls. 71 For a description of the overall IPSEC architecture, see [ARCH], 72 [AH], and [ESP]. 74 3. Terms and Definitions 76 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 77 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 78 document, are to be interpreted as described in [RFC 2119]. 80 4.1 IPSEC Naming Scheme 82 Within ISAKMP, all DOI's must be registered with the IANA in the 83 ``Assigned Numbers'' RFC [STD-2]. The IANA Assigned Number for the 84 Internet IP Security DOI (IPSEC DOI) is one (1). Within the IPSEC 85 DOI, all well-known identifiers MUST be registered with the IANA 86 under the IPSEC DOI. Unless otherwise noted, all tables within this 87 document refer to IANA Assigned Numbers for the IPSEC DOI. See 88 Section 6 for further information relating to the IANA registry for 89 the IPSEC DOI. 91 All multi-octet binary values are stored in network byte order. 93 4.2 IPSEC Situation Definition 95 Within ISAKMP, the Situation provides information that can be used by 96 the responder to make a policy determination about how to process the 97 incoming Security Association request. For the IPSEC DOI, the 98 Situation field is a four (4) octet bitmask with the following 99 values. 101 Situation Value 102 --------- ----- 103 SIT_IDENTITY_ONLY 0x01 104 SIT_SECRECY 0x02 105 SIT_INTEGRITY 0x04 107 4.2.1 SIT_IDENTITY_ONLY 109 The SIT_IDENTITY_ONLY type specifies that the security association 110 will be identified by source identity information present in an 111 associated Identification Payload. See Section 4.6.2 for a complete 112 description of the various Identification types. All IPSEC DOI 113 implementations MUST support SIT_IDENTITY_ONLY by including an 114 Identification Payload in at least one of the Phase I Oakley 115 exchanges ([IKE], Section 5) and MUST abort any association setup 116 that does not include an Identification Payload. 118 If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the 119 situation consists only of the 4 octet situation bitmap and does not 120 include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) 121 or any subsequent label information. Conversely, if the initiator 122 supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain 123 Identifier MUST be included in the situation payload. 125 4.2.2 SIT_SECRECY 127 The SIT_SECRECY type specifies that the security association is being 128 negotiated in an environment that requires labeled secrecy. If 129 SIT_SECRECY is present in the Situation bitmap, the Situation field 130 will be followed by variable-length data that includes a sensitivity 131 level and compartment bitmask. See Section 4.6.1 for a complete 132 description of the Security Association Payload format. 134 If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be 135 set in the Situation bitmap and no secrecy level or category bitmaps 136 shall be included. 138 If a responder does not support SIT_SECRECY, a SITUATION-NOT- 139 SUPPORTED Notification Payload SHOULD be returned and the security 140 association setup MUST be aborted. 142 4.2.3 SIT_INTEGRITY 144 The SIT_INTEGRITY type specifies that the security association is 145 being negotiated in an environment that requires labeled integrity. 146 If SIT_INTEGRITY is present in the Situation bitmap, the Situation 147 field will be followed by variable-length data that includes an 148 integrity level and compartment bitmask. If SIT_SECRECY is also in 149 use for the association, the integrity information immediately 150 follows the variable-length secrecy level and categories. See 151 section 4.6.1 for a complete description of the Security Association 152 Payload format. 154 If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST 155 NOT be set in the Situation bitmap and no integrity level or category 156 bitmaps shall be included. 158 If a responder does not support SIT_INTEGRITY, a SITUATION-NOT- 159 SUPPORTED Notification Payload SHOULD be returned and the security 160 association setup MUST be aborted. 162 4.3 IPSEC Security Policy Requirements 164 The IPSEC DOI does not impose specific security policy requirements 165 on any implementation. Host system policy issues are outside of the 166 scope of this document. 168 However, the following sections touch on some of the issues that must 169 be considered when designing an IPSEC DOI host implementation. This 170 section should be considered only informational in nature. 172 4.3.1 Key Management Issues 174 It is expected that many systems choosing to implement ISAKMP will 175 strive to provide a protected domain of execution for a combined IKE 176 key management daemon. On protected-mode multiuser operating 177 systems, this key management daemon will likely exist as a separate 178 privileged process. 180 In such an environment, a formalized API to introduce keying material 181 into the TCP/IP kernel may be desirable. The IP Security 182 architecture does not place any requirements for structure or flow 183 between a host TCP/IP kernel and its key management provider. 185 4.3.2 Static Keying Issues 187 Host systems that implement static keys, either for use directly by 188 IPSEC, or for authentication purposes (see [IKE] Section 5.4), should 189 take steps to protect the static keying material when it is not 190 residing in a protected memory domain or actively in use by the 191 TCP/IP kernel. 193 For example, on a laptop, one might choose to store the static keys 194 in a configuration store that is, itself, encrypted under a private 195 password. 197 Depending on the operating system and utility software installed, it 198 may not be possible to protect the static keys once they've been 199 loaded into the TCP/IP kernel, however they should not be trivially 200 recoverable on initial system startup without having to satisfy some 201 additional form of authentication. 203 4.3.3 Host Policy Issues 205 It is not realistic to assume that the transition to IPSEC will occur 206 overnight. Host systems must be prepared to implement flexible 207 policy lists that describe which systems they desire to speak 208 securely with and which systems they require speak securely to them. 209 Some notion of proxy firewall addresses may also be required. 211 A minimal approach is probably a static list of IP addresses, network 212 masks, and a security required flag or flags. 214 A more flexible implementation might consist of a list of wildcard 215 DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional 216 firewall address. The wildcard DNS name would be used to match 217 incoming or outgoing IP addresses, the in/out bitmask would be used 218 to determine whether or not security was to be applied and in which 219 direction, and the optional firewall address would be used to 220 indicate whether or not tunnel mode would be needed to talk to the 221 target system though an intermediate firewall. 223 4.3.4 Certificate Management 224 Host systems implementing a certificate-based authentication scheme 225 will need a mechanism for obtaining and managing a database of 226 certificates. 228 Secure DNS is to be one certificate distribution mechanism, however 229 the pervasive availability of secure DNS zones, in the short term, is 230 doubtful for many reasons. What's far more likely is that hosts will 231 need an ability to import certificates that they acquire through 232 secure, out-of-band mechanisms, as well as an ability to export their 233 own certificates for use by other systems. 235 However, manual certificate management should not be done so as to 236 preclude the ability to introduce dynamic certificate discovery 237 mechanisms and/or protocols as they become available. 239 4.4 IPSEC Assigned Numbers 241 The following sections list the Assigned Numbers for the IPSEC DOI: 242 Situation Identifiers, Protocol Identifiers, Transform Identifiers, 243 AH, ESP, and IPCOMP Transform Identifiers, Security Association 244 Attribute Type Values, Labeled Domain Identifiers, ID Payload Type 245 Values, and Notify Message Type Values. 247 4.4.1 IPSEC Security Protocol Identifier 249 The ISAKMP proposal syntax was specifically designed to allow for the 250 simultaneous negotiation of multiple Phase II security protocol 251 suites within a single negotiation. As a result, the protocol suites 252 listed below form the set of protocols that can be negotiated at the 253 same time. It is a host policy decision as to what protocol suites 254 might be negotiated together. 256 The following table lists the values for the Security Protocol 257 Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC 258 DOI. 260 Protocol ID Value 261 ----------- ----- 262 RESERVED 0 263 PROTO_ISAKMP 1 264 PROTO_IPSEC_AH 2 265 PROTO_IPSEC_ESP 3 266 PROTO_IPCOMP 4 268 4.4.1.1 PROTO_ISAKMP 270 The PROTO_ISAKMP type specifies message protection required during 271 Phase I of the ISAKMP protocol. The specific protection mechanism 272 used for the IPSEC DOI is described in [IKE]. All implementations 273 within the IPSEC DOI MUST support PROTO_ISAKMP. 275 NB: ISAKMP reserves the value one (1) across all DOI definitions. 277 4.4.1.2 PROTO_IPSEC_AH 279 The PROTO_IPSEC_AH type specifies IP packet authentication. The 280 default AH transform provides data origin authentication, integrity 281 protection, and replay detection. For export control considerations, 282 confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform. 284 4.4.1.3 PROTO_IPSEC_ESP 286 The PROTO_IPSEC_ESP type specifies IP packet confidentiality. 287 Authentication, if required, must be provided as part of the ESP 288 transform. The default ESP transform includes data origin 289 authentication, integrity protection, replay detection, and 290 confidentiality. 292 4.4.1.4 PROTO_IPCOMP 294 The PROTO_IPCOMP type specifies IP payload compression. 296 4.4.2 IPSEC ISAKMP Transform Identifiers 298 As part of an ISAKMP Phase I negotiation, the initiator's choice of 299 Key Exchange offerings is made using some host system policy 300 description. The actual selection of Key Exchange mechanism is made 301 using the standard ISAKMP Proposal Payload. The following table 302 lists the defined ISAKMP Phase I Transform Identifiers for the 303 Proposal Payload for the IPSEC DOI. 305 Transform Value 306 --------- ----- 307 RESERVED 0 308 KEY_IKE 1 310 Within the ISAKMP and IPSEC DOI framework it is possible to define 311 key establishment protocols other than IKE (Oakley). Previous 312 versions of this document defined types both for manual keying and 313 for schemes based on use of a generic Key Distribution Center (KDC). 314 These identifiers have been removed from the current document. 316 The IPSEC DOI can still be extended later to include values for 317 additional non-Oakley key establishment protocols for ISAKMP and 318 IPSEC, such as Kerberos [RFC-1510] or the Group Key Management 319 Protocol (GKMP) [RFC-2093]. 321 4.4.2.1 KEY_IKE 323 The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman 324 key exchange (IKE) as defined in the [IKE] document. All 325 implementations within the IPSEC DOI MUST support KEY_IKE. 327 4.4.3 IPSEC AH Transform Identifiers 329 The Authentication Header Protocol (AH) defines one mandatory and 330 several optional transforms used to provide authentication, 331 integrity, and replay detection. The following table lists the 332 defined AH Transform Identifiers for the ISAKMP Proposal Payload for 333 the IPSEC DOI. 335 Note: the Authentication Algorithm attribute MUST be specified to 336 identify the appropriate AH protection suite. For example, AH_MD5 337 can best be thought of as a generic AH transform using MD5. To 338 request the HMAC construction with AH, one specifies the AH_MD5 339 transform ID along with the Authentication Algorithm attribute set to 340 HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the 341 following sections. 343 Transform ID Value 344 ------------ ----- 345 RESERVED 0-1 346 AH_MD5 2 347 AH_SHA 3 348 AH_DES 4 350 4.4.3.1 AH_MD5 352 The AH_MD5 type specifies a generic AH transform using MD5. The 353 actual protection suite is determined in concert with an associated 354 SA attribute list. A generic MD5 transform is currently undefined. 356 All implementations within the IPSEC DOI MUST support AH_MD5 along 357 with the Auth(HMAC-MD5) attribute. This suite is defined as the 358 HMAC-MD5-96 transform described in [HMACMD5]. 360 The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH 361 transform (Key/Pad/Data/Key) described in RFC-1826. This mode MAY be 362 negotiated for compatibility with older implementations. 363 Implementations are not required to support this mode. 365 Use of AH_MD5 with any other Authentication Algorithm attribute value 366 is currently undefined. 368 4.4.3.2 AH_SHA 369 The AH_SHA type specifies a generic AH transform using SHA-1. The 370 actual protection suite is determined in concert with an associated 371 SA attribute list. A generic SHA transform is currently undefined. 373 All implementations within the IPSEC DOI MUST support AH_SHA along 374 with the Auth(HMAC-SHA) attribute. This suite is defined as the 375 HMAC-SHA-1-96 transform described in [HMACSHA]. 377 Use of AH_SHA with any other Authentication Algorithm attribute value 378 is currently undefined. 380 4.4.3.3 AH_DES 382 The AH_DES type specifies a generic AH transform using DES. The 383 actual protection suite is determined in concert with an associated 384 SA attribute list. A generic DES transform is currently undefined. 386 The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute 387 to be a DES-MAC transform. Implementations are not required to 388 support this mode. 390 Use of AH_DES with any other Authentication Algorithm attribute value 391 is currently undefined. 393 4.4.4 IPSEC ESP Transform Identifiers 395 The Encapsulating Security Payload (ESP) defines one mandatory and 396 many optional transforms used to provide data confidentiality. The 397 following table lists the defined ESP Transform Identifiers for the 398 ISAKMP Proposal Payload for the IPSEC DOI. 400 Note: when authentication, integrity protection, and replay detection 401 are required, the Authentication Algorithm attribute MUST be 402 specified to identify the appropriate ESP protection suite. For 403 example, to request HMAC-MD5 authentication with 3DES, one specifies 404 the ESP_3DES transform ID with the Authentication Algorithm attribute 405 set to HMAC-MD5. 407 Transform ID Value 408 ------------ ----- 409 RESERVED 0 410 ESP_DES_IV64 1 411 ESP_DES 2 412 ESP_3DES 3 413 ESP_RC5 4 414 ESP_IDEA 5 415 ESP_CAST 6 416 ESP_BLOWFISH 7 417 ESP_3IDEA 8 418 ESP_DES_IV32 9 419 ESP_RC4 10 420 ESP_NULL 11 422 4.4.4.1 ESP_DES_IV64 424 The ESP_DES_IV64 type specifies the DES-CBC transform defined in 425 RFC-1827 and RFC-1829 using a 64-bit IV. This mode MAY be negotiated 426 for compatibility with older implementations. Implementations are 427 not required to support this mode. 429 4.4.4.2 ESP_DES 431 The ESP_DES type specifies a generic DES transform using DES-CBC. 432 The actual protection suite is determined in concert with an 433 associated SA attribute list. A generic transform is currently 434 undefined. 436 All implementations within the IPSEC DOI MUST support ESP_DES along 437 with the Auth(HMAC-MD5) attribute. This suite is defined as the 438 [DES] transform, with authentication and integrity provided by HMAC 439 MD5. 441 4.4.4.3 ESP_3DES 443 The ESP_3DES type specifies a generic triple-DES transform. The 444 actual protection suite is determined in concert with an associated 445 SA attribute list. The generic transform is currently undefined. 447 All implementations within the IPSEC DOI are strongly encouraged to 448 support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite 449 is defined as the [ESPCBC] transform, with authentication and 450 integrity provided by HMAC MD5. 452 4.4.4.4 ESP_RC5 454 The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC]. 456 4.4.4.5 ESP_IDEA 458 The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC]. 460 4.4.4.6 ESP_CAST 462 The ESP_CAST type specifies the CAST transform defined in [ESPCBC]. 464 4.4.4.7 ESP_BLOWFISH 465 The ESP_BLOWFISH type specifies the BLOWFISH transform defined in 466 [ESPCBC]. 468 4.4.4.8 ESP_3IDEA 470 The ESP_3IDEA type is reserved for triple-IDEA. 472 4.4.4.9 ESP_DES_IV32 474 The ESP_DES_IV32 type specifies the DES-CBC transform defined in 475 RFC-1827 and RFC-1829 using a 32-bit IV. This mode MAY be negotiated 476 for compatibility with older implementations. Implementations are 477 not required to support this mode. 479 4.4.4.10 ESP_RC4 481 The ESP_RC4 type is reserved for RC4.p 483 4.4.4.11 ESP_NULL 485 The ESP_NULL type specifies no confidentiality is to be provided by 486 ESP. ESP_NULL is used when ESP is being used to tunnel packets which 487 require only authentication, integrity protection, and replay 488 detection. 490 All implementations within the IPSEC DOI MUST support ESP_NULL. The 491 ESP NULL transform is defined in [ESPNULL]. See the Authentication 492 Algorithm attribute description in Section 4.5 for additional 493 requirements relating to the use of ESP_NULL. 495 4.4.5 IPSEC IPCOMP Transform Identifiers 497 The IP Compression (IPCOMP) transforms define optional compression 498 algorithms that can be negotiated to provide for IP payload 499 compression ([IPCOMP]). The following table lists the defined IPCOMP 500 Transform Identifiers for the ISAKMP Proposal Payload within the 501 IPSEC DOI. 503 Transform ID Value 504 ------------ ----- 505 RESERVED 0 506 IPCOMP_OUI 1 507 IPCOMP_DEFLATE 2 508 IPCOMP_LZS 3 509 IPCOMP_V42BIS 4 511 4.4.5.1 IPCOMP_OUI 512 The IPCOMP_OUI type specifies a proprietary compression transform. 513 The IPCOMP_OUI type must be accompanied by an attribute which further 514 identifies the specific vendor algorithm. 516 4.4.5.2 IPCOMP_DEFLATE 518 The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate 519 algorithm. 521 4.4.5.3 IPCOMP_LZS 523 The IPCOMP_LZS type specifies the use of the Stac Electronics LZS 524 algorithm. 526 4.4.5.4 IPCOMP_V42BIS 528 The IPCOMP_V42BIS type specifies the use of V42bis compression. 530 4.5 IPSEC Security Association Attributes 532 The following SA attribute definitions are used in Phase II of an IKE 533 negotiation. Attribute types can be either Basic (B) or Variable- 534 Length (V). Encoding of these attributes is defined in the base 535 ISAKMP specification. 537 Attributes described as basic MUST NOT be encoded as variable. 538 Variable length attributes MAY be encoded as basic attributes if 539 their value can fit into two octets. See [IKE] for further 540 information on attribute encoding in the IPSEC DOI. All restrictions 541 listed in [IKE] also apply to the IPSEC DOI. 543 Attribute Types 545 class value type 546 ------------------------------------------------- 547 SA Life Type 1 B 548 SA Life Duration 2 V 549 Group Description 3 B 550 Encapsulation Mode 4 B 551 Authentication Algorithm 5 B 552 Key Length 6 B 553 Key Rounds 7 B 554 Compress Dictionary Size 8 B 555 Compress Private Algorithm 9 V 557 Class Values 559 SA Life Type 560 SA Duration 562 Specifies the time-to-live for the overall security 563 association. When the SA expires, all keys negotiated under 564 the association (AH or ESP) must be renegotiated. The life 565 type values are: 567 RESERVED 0 568 seconds 1 569 kilobytes 2 571 Values 3-61439 are reserved to IANA. Values 61440-65535 are 572 for private use. For a given Life Type, the value of the 573 Life Duration attribute defines the actual length of the 574 component lifetime -- either a number of seconds, or a number 575 of Kbytes that can be protected. 577 If unspecified, the default value shall be assumed to be 578 28800 seconds (8 hours). 580 An SA Life Duration attribute MUST always follow an SA Life 581 Type which describes the units of duration. 583 See Section 4.5.4 for additional information relating to 584 lifetime notification. 586 Group Description 588 Specifies the Oakley Group to be used in a PFS QM 589 negotiation. For a list of supported values, see Appendix A 590 of [IKE]. 592 Encapsulation Mode 593 RESERVED 0 594 Tunnel 1 595 Transport 2 597 Values 3-61439 are reserved to IANA. Values 61440-65535 are 598 for private use. 600 If unspecified, the default value shall be assumed to be 601 unspecified (host-dependent). 603 Authentication Algorithm 604 RESERVED 0 605 HMAC-MD5 1 606 HMAC-SHA 2 607 DES-MAC 3 608 KPDK 4 610 Values 5-61439 are reserved to IANA. Values 61440-65535 are 611 for private use. 613 There is no default value for Auth Algorithm, as it must be 614 specified to correctly identify the applicable AH or ESP 615 transform, except in the following case. 617 When negotiating ESP without authentication, the Auth 618 Algorithm attribute MUST NOT be included in the proposal. 620 When negotiating ESP without confidentiality, the Auth 621 Algorithm attribute MUST be included in the proposal and 622 the ESP transform ID must be ESP_NULL. 624 Key Length 625 RESERVED 0 627 There is no default value for Key Length, as it must be 628 specified for transforms using ciphers with variable key 629 lengths. For fixed length ciphers, the Key Length attribute 630 MUST NOT be sent. 632 Key Rounds 633 RESERVED 0 635 There is no default value for Key Rounds, as it must be 636 specified for transforms using ciphers with varying 637 numbers of rounds. 639 Compression Dictionary Size 640 RESERVED 0 642 Specifies the log2 maximum size of the dictionary. 644 There is no default value for dictionary size. 646 Compression Private Algorithm 648 Specifies a private vendor compression algorithm. The first 649 three (3) octets must be an IEEE assigned company_id (OUI). 650 The next octet may be a vendor specific compression subtype, 651 followed by zero or more octets of vendor data. 653 4.5.1 Required Attribute Support 655 To ensure basic interoperability, all implementations MUST be 656 prepared to negotiate all of the following attributes. 658 SA Life Type 659 SA Duration 660 Auth Algorithm 662 4.5.2 Attribute Parsing Requirement (Lifetime) 664 To allow for flexible semantics, the IPSEC DOI requires that a 665 conforming ISAKMP implementation MUST correctly parse an attribute 666 list that contains multiple instances of the same attribute class, so 667 long as the different attribute entries do not conflict with one 668 another. Currently, the only attributes which requires this 669 treatment are Life Type and Duration. 671 To see why this is important, the following example shows the binary 672 encoding of a four entry attribute list that specifies an SA Lifetime 673 of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a 674 complete description of the attribute encoding format.) 676 Attribute #1: 677 0x80010001 (AF = 1, type = SA Life Type, value = seconds) 679 Attribute #2: 680 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 681 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) 683 Attribute #3: 684 0x80010002 (AF = 1, type = SA Life Type, value = KB) 686 Attribute #4: 687 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 688 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) 690 If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED 691 Notification Payload SHOULD be returned and the security association 692 setup MUST be aborted. 694 4.5.3 Attribute Negotiation 696 If an implementation receives a defined IPSEC DOI attribute (or 697 attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT 698 SHOULD be sent and the security association setup MUST be aborted, 699 unless the attribute value is in the reserved range. 701 If an implementation receives an attribute value in the reserved 702 range, an implementation MAY chose to continue based on local policy. 704 4.5.4 Lifetime Notification 706 When an initiator offers an SA lifetime greater than what the 707 responder desires based on their local policy, the responder has 708 three choices: 1) fail the negotiation entirely; 2) complete the 709 negotiation but use a shorter lifetime than what was offered; 3) 710 complete the negotiation and send an advisory notification to the 711 initiator indicating the responder's true lifetime. The choice of 712 what the responder actually does is implementation specific and/or 713 based on local policy. 715 To ensure interoperability in the latter case, the IPSEC DOI requires 716 the following only when the responder wishes to notify the initiator: 717 if the initiator offers an SA lifetime longer than the responder is 718 willing to accept, the responder SHOULD include an ISAKMP 719 Notification Payload in the exchange that includes the responder's 720 IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the 721 RESPONDER-LIFETIME Notification Message type which MUST be used for 722 this purpose. 724 4.6 IPSEC Payload Content 726 The following sections describe those ISAKMP payloads whose data 727 representations are dependent on the applicable DOI. 729 4.6.1 Security Association Payload 731 The following diagram illustrates the content of the Security 732 Association Payload for the IPSEC DOI. See Section 4.2 for a 733 description of the Situation bitmap. 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 ! Next Payload ! RESERVED ! Payload Length ! 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 ! Domain of Interpretation (IPSEC) | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 ! Situation (bitmap) ! 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 ! Labeled Domain Identifier ! 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 ! Secrecy Length (in octets) ! RESERVED ! 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 ~ Secrecy Level ~ 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 ! Secrecy Cat. Length (in bits) ! RESERVED ! 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 ~ Secrecy Category Bitmap ~ 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 ! Integrity Length (in octets) ! RESERVED ! 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 ~ Integrity Level ~ 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 ! Integ. Cat. Length (in bits) ! RESERVED ! 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 ~ Integrity Category Bitmap ~ 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 Figure 1: Security Association Payload Format 764 The Security Association Payload is defined as follows: 766 o Next Payload (1 octet) - Identifier for the payload type of 767 the next payload in the message. If the current payload is 768 the last in the message, this field will be zero (0). 770 o RESERVED (1 octet) - Unused, must be zero (0). 772 o Payload Length (2 octets) - Length, in octets, of the current 773 payload, including the generic header. 775 o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, 776 which has been assigned the value one (1). 778 o Situation (4 octets) - Bitmask used to interpret the 779 remainder of the Security Association Payload. See Section 780 4.2 for a complete list of values. 782 o Labeled Domain Identifier (4 octets) - IANA Assigned Number 783 used to interpret the Secrecy and Integrity information. 785 o Secrecy Length (2 octets) - Specifies the length, in octets, 786 of the secrecy level identifier. 788 o RESERVED (2 octets) - Unused, must be zero (0). 790 o Secrecy Level (variable length) - Specifies the mandatory 791 secrecy level required. The secrecy level MUST be padded 792 with zero (0) to align on the next 32-bit boundary. 794 o Secrecy Category Length (2 octets) - Specifies the length, in 795 bits, of the secrecy category (compartment) bitmap, excluding 796 pad bits. 798 o RESERVED (2 octets) - Unused, must be zero (0). 800 o Secrecy Category Bitmap (variable length) - A bitmap used to 801 designate secrecy categories (compartments) that are 802 required. The bitmap MUST be padded with zero (0) to align 803 on the next 32-bit boundary. 805 o Integrity Length (2 octets) - Specifies the length, in 806 octets, of the integrity level identifier. 808 o RESERVED (2 octets) - Unused, must be zero (0). 810 o Integrity Level (variable length) - Specifies the mandatory 811 integrity level required. The integrity level MUST be padded 812 with zero (0) to align on the next 32-bit boundary. 814 o Integrity Category Length (2 octets) - Specifies the length, 815 in bits, of the integrity category (compartment) bitmap, 816 excluding pad bits. 818 o RESERVED (2 octets) - Unused, must be zero (0). 820 o Integrity Category Bitmap (variable length) - A bitmap used 821 to designate integrity categories (compartments) that are 822 required. The bitmap MUST be padded with zero (0) to align 823 on the next 32-bit boundary. 825 4.6.1.1 IPSEC Labeled Domain Identifiers 827 The following table lists the assigned values for the Labeled Domain 828 Identifier field contained in the Situation field of the Security 829 Association Payload. 831 Domain Value 832 ------- ----- 833 RESERVED 0 835 4.6.2 Identification Payload Content 837 The Identification Payload is used to identify the initiator of the 838 Security Association. The identity of the initiator SHOULD be used 839 by the responder to determine the correct host system security policy 840 requirement for the association. For example, a host might choose to 841 require authentication and integrity without confidentiality (AH) 842 from a certain set of IP addresses and full authentication with 843 confidentiality (ESP) from another range of IP addresses. The 844 Identification Payload provides information that can be used by the 845 responder to make this decision. 847 During Phase I negotiations, the ID port and protocol fields MUST be 848 set to zero or to UDP port 500. If an implementation receives any 849 other values, this MUST be treated as an error and the security 850 association setup MUST be aborted. This event SHOULD be auditable. 852 The following diagram illustrates the content of the Identification 853 Payload. 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 ! Next Payload ! RESERVED ! Payload Length ! 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 ! ID Type ! Protocol ID ! Port ! 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 ~ Identification Data ~ 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Figure 2: Identification Payload Format 866 The Identification Payload fields are defined as follows: 868 o Next Payload (1 octet) - Identifier for the payload type of 869 the next payload in the message. If the current payload is 870 the last in the message, this field will be zero (0). 872 o RESERVED (1 octet) - Unused, must be zero (0). 874 o Payload Length (2 octets) - Length, in octets, of the 875 identification data, including the generic header. 877 o Identification Type (1 octet) - Value describing the 878 identity information found in the Identification Data field. 880 o Protocol ID (1 octet) - Value specifying an associated 881 IP protocol ID (e.g. UDP/TCP). A value of zero means that the 882 Protocol ID field should be ignored. 884 o Port (2 octets) - Value specifying an associated port. 885 A value of zero means that the Port field should be ignored. 887 o Identification Data (variable length) - Value, as indicated 888 by the Identification Type. 890 4.6.2.1 Identification Type Values 892 The following table lists the assigned values for the Identification 893 Type field found in the Identification Payload. 895 ID Type Value 896 ------- ----- 897 RESERVED 0 898 ID_IPV4_ADDR 1 899 ID_FQDN 2 900 ID_USER_FQDN 3 901 ID_IPV4_ADDR_SUBNET 4 902 ID_IPV6_ADDR 5 903 ID_IPV6_ADDR_SUBNET 6 904 ID_IPV4_ADDR_RANGE 7 905 ID_IPV6_ADDR_RANGE 8 906 ID_DER_ASN1_DN 9 907 ID_DER_ASN1_GN 10 908 ID_KEY_ID 11 910 For types where the ID entity is variable length, the size of the ID 911 entity is computed from size in the ID payload header. 913 When an IKE exchange is authenticated using certificates (of any 914 format), any ID's used for input to local policy decisions SHOULD be 915 contained in the certificate used in the authentication of the 916 exchange. 918 4.6.2.2 ID_IPV4_ADDR 920 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 922 4.6.2.3 ID_FQDN 924 The ID_FQDN type specifies a fully-qualified domain name string. An 925 example of a ID_FQDN is, "foo.bar.com". The string should not 926 contain any terminators. 928 4.6.2.4 ID_USER_FQDN 930 The ID_USER_FQDN type specifies a fully-qualified username string, An 931 example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should 932 not contain any terminators. 934 4.6.2.5 ID_IPV4_ADDR_SUBNET 936 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, 937 represented by two four (4) octet values. The first value is an IPv4 938 address. The second is an IPv4 network mask. Note that ones (1s) in 939 the network mask indicate that the corresponding bit in the address 940 is fixed, while zeros (0s) indicate a "wildcard" bit. 942 4.6.2.6 ID_IPV6_ADDR 943 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 944 address. 946 4.6.2.7 ID_IPV6_ADDR_SUBNET 948 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, 949 represented by two sixteen (16) octet values. The first value is an 950 IPv6 address. The second is an IPv6 network mask. Note that ones 951 (1s) in the network mask indicate that the corresponding bit in the 952 address is fixed, while zeros (0s) indicate a "wildcard" bit. 954 4.6.2.8 ID_IPV4_ADDR_RANGE 956 The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, 957 represented by two four (4) octet values. The first value is the 958 beginning IPv4 address (inclusive) and the second value is the ending 959 IPv4 address (inclusive). All addresses falling between the two 960 specified addresses are considered to be within the list. 962 4.6.2.9 ID_IPV6_ADDR_RANGE 964 The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, 965 represented by two sixteen (16) octet values. The first value is the 966 beginning IPv6 address (inclusive) and the second value is the ending 967 IPv6 address (inclusive). All addresses falling between the two 968 specified addresses are considered to be within the list. 970 4.6.2.10 ID_DER_ASN1_DN 972 The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 973 X.500 Distinguished Name [X.501] of the principal whose certificates 974 are being exchanged to establish the SA. 976 4.6.2.11 ID_DER_ASN1_GN 978 The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 979 X.500 GeneralName [X.509] of the principal whose certificates are 980 being exchanged to establish the SA. 982 4.6.2.12 ID_KEY_ID 984 The ID_KEY_ID type specifies an opaque byte stream which may be used 985 to pass vendor-specific information necessary to identify which pre- 986 shared key should be used to authenticate Aggressive mode 987 negotiations. 989 4.6.3 IPSEC Notify Message Types 990 ISAKMP defines two blocks of Notify Message codes, one for errors and 991 one for status messages. ISAKMP also allocates a portion of each 992 block for private use within a DOI. The IPSEC DOI defines the 993 following private message types for its own use. 995 Notify Messages - Error Types Value 996 ----------------------------- ----- 997 RESERVED 8192 999 Notify Messages - Status Types Value 1000 ------------------------------ ----- 1001 RESPONDER-LIFETIME 24576 1002 REPLAY-STATUS 24577 1003 INITIAL-CONTACT 24578 1005 Notification Status Messages MUST be sent under the protection of an 1006 ISAKMP SA: either as a payload in the last Main Mode exchange; in a 1007 separate Informational Exchange after Main Mode or Aggressive Mode 1008 processing is complete; or as a payload in any Quick Mode exchange. 1009 These messages MUST NOT be sent in Aggressive Mode exchange, since 1010 Aggressive Mode does not provide the necessary protection to bind the 1011 Notify Status Message to the exchange. 1013 Nota Bene: a Notify payload is fully protected only in Quick Mode, 1014 where the entire payload is included in the HASH(n) digest. In Main 1015 Mode, while the notify payload is encrypted, it is not currently 1016 included in the HASH(n) digests. As a result, an active substitution 1017 attack on the Main Mode ciphertext could cause the notify status 1018 message type to be corrupted. (This is true, in general, for the 1019 last message of any Main Mode exchange.) While the risk is small, a 1020 corrupt notify message might cause the receiver to abort the entire 1021 negotiation thinking that the sender encountered a fatal error. 1023 Implementation Note: the ISAKMP protocol does not guarantee delivery 1024 of Notification Status messages when sent in an ISAKMP Informational 1025 Exchange. To ensure receipt of any particular message, the sender 1026 SHOULD include a Notification Payload in a defined Main Mode or Quick 1027 Mode exchange which is protected by a retransmission timer. 1029 4.6.3.1 RESPONDER-LIFETIME 1031 The RESPONDER-LIFETIME status message may be used to communicate the 1032 IPSEC SA lifetime chosen by the responder. 1034 When present, the Notification Payload MUST have the following 1035 format: 1037 o Payload Length - set to length of payload + size of data (var) 1038 o DOI - set to IPSEC DOI (1) 1039 o Protocol ID - set to selected Protocol ID from chosen SA 1040 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1041 o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) 1042 o SPI - set to the two ISAKMP cookies 1043 o Notification Data - contains an ISAKMP attribute list with the 1044 responder's actual SA lifetime(s) 1046 Implementation Note: saying that the Notification Data field contains 1047 an attribute list is equivalent to saying that the Notification Data 1048 field has zero length and the Notification Payload has an associated 1049 attribute list. 1051 4.6.3.2 REPLAY-STATUS 1053 The REPLAY-STATUS status message may be used for positive 1054 confirmation of the responder's election on whether or not he is to 1055 perform anti-replay detection. 1057 When present, the Notification Payload MUST have the following 1058 format: 1060 o Payload Length - set to length of payload + size of data (4) 1061 o DOI - set to IPSEC DOI (1) 1062 o Protocol ID - set to selected Protocol ID from chosen SA 1063 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1064 o Notify Message Type - set to REPLAY-STATUS 1065 o SPI - set to the two ISAKMP cookies 1066 o Notification Data - a 4 octet value: 1067 0 = replay detection disabled 1068 1 = replay detection enabled 1070 4.6.3.3 INITIAL-CONTACT 1072 The INITIAL-CONTACT status message may be used when one side wishes 1073 to inform the other that this is the first SA being established with 1074 the remote system. The receiver of this Notification Message might 1075 then elect to delete any existing SA's it has for the sending system 1076 under the assumption that the sending system has rebooted and no 1077 longer has access to the original SA's and their associated keying 1078 material. When used, the content of the Notification Data field 1079 SHOULD be null (i.e. the Payload Length should be set to the fixed 1080 length of Notification Payload). 1082 When present, the Notification Payload MUST have the following 1083 format: 1085 o Payload Length - set to length of payload + size of data (0) 1086 o DOI - set to IPSEC DOI (1) 1087 o Protocol ID - set to selected Protocol ID from chosen SA 1088 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1089 o Notify Message Type - set to INITIAL-CONTACT 1090 o SPI - set to the two ISAKMP cookies 1091 o Notification Data - 1093 4.7 IPSEC Key Exchange Requirements 1095 The IPSEC DOI introduces no additional Key Exchange types. 1097 5. Security Considerations 1099 This entire draft pertains to the Internet Key Exchange protocol 1100 ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to 1101 provide for the derivation of cryptographic keying material in a 1102 secure and authenticated manner. Specific discussion of the various 1103 security protocols and transforms identified in this document can be 1104 found in the associated base documents and in the cipher references. 1106 6. IANA Considerations 1108 This document contains many "magic" numbers to be maintained by the 1109 IANA. This section explains the criteria to be used by the IANA to 1110 assign additional numbers in each of these lists. All values not 1111 explicitly defined in previous sections are reserved to IANA. 1113 6.1 IPSEC Situation Definition 1115 The Situation Definition is a 32-bit bitmask which represents the 1116 environment under which the IPSEC SA proposal and negotiation is 1117 carried out. Requests for assignments of new situations must be 1118 accompanied by an RFC which describes the interpretation for the 1119 associated bit. 1121 If the RFC is not on the standards-track (i.e., it is an 1122 informational or experimental RFC), it must be explicitly reviewed 1123 and approved by the IESG before the RFC is published and the 1124 transform identifier is assigned. 1126 The upper two bits are reserved for private use amongst cooperating 1127 systems. 1129 6.2 IPSEC Security Protocol Identifiers 1131 The Security Protocol Identifier is an 8-bit value which identifies a 1132 security protocol suite being negotiated. Requests for assignments 1133 of new security protocol identifiers must be accompanied by an RFC 1134 which describes the requested security protocol. [AH] and [ESP] are 1135 examples of security protocol documents. 1137 If the RFC is not on the standards-track (i.e., it is an 1138 informational or experimental RFC), it must be explicitly reviewed 1139 and approved by the IESG before the RFC is published and the 1140 transform identifier is assigned. 1142 The values 249-255 are reserved for private use amongst cooperating 1143 systems. 1145 6.3 IPSEC ISAKMP Transform Identifiers 1147 The IPSEC ISAKMP Transform Identifier is an 8-bit value which 1148 identifies a key exchange protocol to be used for the negotiation. 1149 Requests for assignments of new ISAKMP transform identifiers must be 1150 accompanied by an RFC which describes the requested key exchange 1151 protocol. [IKE] is an example of one such document. 1153 If the RFC is not on the standards-track (i.e., it is an 1154 informational or experimental RFC), it must be explicitly reviewed 1155 and approved by the IESG before the RFC is published and the 1156 transform identifier is assigned. 1158 The values 249-255 are reserved for private use amongst cooperating 1159 systems. 1161 6.4 IPSEC AH Transform Identifiers 1163 The IPSEC AH Transform Identifier is an 8-bit value which identifies 1164 a particular algorithm to be used to provide integrity protection for 1165 AH. Requests for assignments of new AH transform identifiers must be 1166 accompanied by an RFC which describes how to use the algorithm within 1167 the AH framework ([AH]). 1169 If the RFC is not on the standards-track (i.e., it is an 1170 informational or experimental RFC), it must be explicitly reviewed 1171 and approved by the IESG before the RFC is published and the 1172 transform identifier is assigned. 1174 The values 249-255 are reserved for private use amongst cooperating 1175 systems. 1177 6.5 IPSEC ESP Transform Identifiers 1179 The IPSEC ESP Transform Identifier is an 8-bit value which identifies 1180 a particular algorithm to be used to provide secrecy protection for 1181 ESP. Requests for assignments of new AH transform identifiers must 1182 be accompanied by an RFC which describes how to use the algorithm 1183 within the ESP framework ([ESP]). 1185 If the RFC is not on the standards-track (i.e., it is an 1186 informational or experimental RFC), it must be explicitly reviewed 1187 and approved by the IESG before the RFC is published and the 1188 transform identifier is assigned. 1190 The values 249-255 are reserved for private use amongst cooperating 1191 systems. 1193 6.6 IPSEC IPCOMP Transform Identifiers 1195 The IPSEC IPCOMP Transform Identifier is an 8-bit value which 1196 identifier a particular algorithm to be used to provide IP-level 1197 compression before ESP. Requests for assignments of new IPCOMP 1198 transform identifiers must be accompanied by an RFC which describes 1199 how to use the algorithm within the IPCOMP framework ([IPCOMP]). In 1200 addition, the requested algorithm must be published and in the public 1201 domain. 1203 If the RFC is not on the standards-track (i.e., it is an 1204 informational or experimental RFC), it must be explicitly reviewed 1205 and approved by the IESG before the RFC is published and the 1206 transform identifier is assigned. 1208 The values 1-47 are reserved for algorithms for which an RFC has been 1209 approved for publication. The values 48-63 are reserved for private 1210 use amongst cooperating systems. The values 64-255 are reserved for 1211 future expansion. 1213 6.7 IPSEC Security Association Attributes 1215 The IPSEC Security Association Attribute consists of a 16-bit type 1216 and its associated value. IPSEC SA attributes are used to pass 1217 miscellaneous values between ISAKMP peers. Requests for assignments 1218 of new IPSEC SA attributes must be accompanied by an Internet Draft 1219 which describes the attribute encoding (Basic/Variable-Length) and 1220 its legal values. Section 4.5 of this document provides an example 1221 of such a description. 1223 The values 32001-32767 are reserved for private use amongst 1224 cooperating systems. 1226 6.8 IPSEC Labeled Domain Identifiers 1228 The IPSEC Labeled Domain Identifier is a 32-bit value which 1229 identifies a namespace in which the Secrecy and Integrity levels and 1230 categories values are said to exist. Requests for assignments of new 1231 IPSEC Labeled Domain Identifiers should be granted on demand. No 1232 accompanying documentation is required, though Internet Drafts are 1233 encouraged when appropriate. 1235 The values 0x80000000-0xffffffff are reserved for private use amongst 1236 cooperating systems. 1238 6.9 IPSEC Identification Type 1240 The IPSEC Identification Type is an 8-bit value which is used as a 1241 discriminant for interpretation of the variable-length Identification 1242 Payload. Requests for assignments of new IPSEC Identification Types 1243 must be accompanied by an RFC which describes how to use the 1244 identification type within IPSEC. 1246 If the RFC is not on the standards-track (i.e., it is an 1247 informational or experimental RFC), it must be explicitly reviewed 1248 and approved by the IESG before the RFC is published and the 1249 transform identifier is assigned. 1251 The values 249-255 are reserved for private use amongst cooperating 1252 systems. 1254 6.10 IPSEC Notify Message Types 1256 The IPSEC Notify Message Type is a 16-bit value taken from the range 1257 of values reserved by ISAKMP for each DOI. There is one range for 1258 error messages (8192-16383) and a different range for status messages 1259 (24576-32767). Requests for assignments of new Notify Message Types 1260 must be accompanied by an Internet Draft which describes how to use 1261 the identification type within IPSEC. 1263 The values 16001-16383 and the values 32001-32767 are reserved for 1264 private use amongst cooperating systems. 1266 7. Change Log 1268 7.1 Changes from V8 1270 o update IPCOMP identifier range to better reflect IPCOMP draft 1271 o update IANA considerations per Jeff/Ted's suggested text 1272 o eliminate references to DES-MAC ID ([DESMAC]) 1273 o correct bug in Notify section; ISAKMP Notify values are 16-bits 1275 7.2 Changes from V7 1277 o corrected name of IPCOMP (IP Payload Compression) 1278 o corrected references to [ESPCBC] 1279 o added missing Secrecy Level and Integrity Level to Figure 1 1280 o removed ID references to PF_KEY and ARCFOUR 1281 o updated Basic/Variable text to align with [IKE] 1282 o updated document references and add intro pointer to [ARCH] 1283 o updated Notification requirements; remove aggressive reference 1284 o added clarification about protection for Notify payloads 1285 o restored RESERVED to ESP transform ID namespace; moved ESP_NULL 1286 o added requirement for ESP_NULL support and [ESPNULL] reference 1287 o added clarification on Auth Alg use with AH/ESP 1288 o added restriction against using conflicting AH/Auth combinations 1290 7.3 Changes from V6 1292 The following changes were made relative to the IPSEC DOI V6: 1294 o added IANA Considerations section 1295 o moved most IANA numbers to IANA Considerations section 1296 o added prohibition on sending (V) encoding for (B) attributes 1297 o added prohibition on sending Key Length attribute for fixed 1298 length ciphers (e.g. DES) 1299 o replaced references to ISAKMP/Oakley with IKE 1300 o renamed ESP_ARCFOUR to ESP_RC4 1301 o updated Security Considerations section 1302 o updated document references 1304 7.4 Changes from V5 1306 The following changes were made relative to the IPSEC DOI V5: 1308 o changed SPI size in Lifetime Notification text 1309 o changed REPLAY-ENABLED to REPLAY-STATUS 1310 o moved RESPONDER-LIFETIME payload definition from Section 4.5.4 1311 to Section 4.6.3.1 1312 o added explicit payload layout for 4.6.3.3 1313 o added Implementation Note to Section 4.6.3 introduction 1314 o changed AH_SHA text to require SHA-1 in addition to MD5 1315 o updated document references 1317 7.5 Changes from V4 1319 The following changes were made relative to the IPSEC DOI V4: 1321 o moved compatibility AH KPDK authentication method from AH 1322 transform ID to Authentication Algorithm identifier 1323 o added REPLAY-ENABLED notification message type per Architecture 1324 o added INITIAL-CONTACT notification message type per list 1325 o added text to ensure protection for Notify Status messages 1326 o added Lifetime qualification to attribute parsing section p o 1327 added clarification that Lifetime notification is optional 1328 o removed private Group Description list (now points at [IKE]) 1329 o replaced Terminology with pointer to RFC-2119 1330 o updated HMAC MD5 and SHA-1 ID references 1331 o updated Section 1 (Abstract) 1332 o updated Section 4.4 (IPSEC Assigned Numbers) 1333 o added restriction for ID port/protocol values for Phase I 1335 7.6 Changes from V3 to V4 1337 The following changes were made relative to the IPSEC DOI V3, that 1338 was posted to the IPSEC mailing list prior to the Munich IETF: 1340 o added ESP transform identifiers for NULL and ARCFOUR 1341 o renamed HMAC Algorithm to Auth Algorithm to accommodate 1342 DES-MAC and optional authentication/integrity for ESP 1343 o added AH and ESP DES-MAC algorithm identifiers 1344 o removed KEY_MANUAL and KEY_KDC identifier definitions 1345 o added lifetime duration MUST follow lifetype attribute to 1346 SA Life Type and SA Life Duration attribute definition 1347 o added lifetime notification and IPSEC DOI message type table 1348 o added optional authentication and confidentiality 1349 restrictions to MAC Algorithm attribute definition 1350 o corrected attribute parsing example (used obsolete attribute) 1351 o corrected several Internet Draft document references 1352 o added ID_KEY_ID per ipsec list discussion (18-Mar-97) 1353 o removed Group Description default for PFS QM ([IKE] MUST) 1355 Acknowledgments 1357 This document is derived, in part, from previous works by Douglas 1358 Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, 1359 and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran 1360 Atkinson also contributed suggestions and, in many cases, text. 1362 References 1364 [AH] Kent, S., Atkinson, R., "IP Authentication Header," draft-ietf- 1365 ipsec-auth-header-05.txt. 1367 [ARCH] Kent, S., Atkinson, R., "Security Architecture for the 1368 Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt. 1370 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 1371 (ESP)," draft-ietf-ipsec-esp-v2-04.txt. 1373 [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 1374 Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt. 1376 [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its 1377 Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt. 1379 [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm 1380 With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt. 1382 [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and 1383 AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt. 1385 [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP 1386 and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt. 1388 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," 1389 draft-ietf-ipsec-isakmp-oakley-06.txt. 1391 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP 1392 Payload Compression Protocol (IPComp)," draft-ietf-ippcp- 1393 protocol-05.txt. 1395 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1396 "Internet Security Association and Key Management Protocol (ISAKMP)," 1397 draft-ietf-ipsec-isakmp-09.{ps,txt}. 1399 [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft- 1400 ietf-ipsec-oakley-02.txt. 1402 [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems 1403 Interconnection - The Directory: Models", CCITT/ITU Recommendation 1404 X.501, 1993. 1406 [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems 1407 Interconnection - The Directory: Authentication Framework", 1408 CCITT/ITU Recommendation X.509, 1993. 1410 Author's Address: 1412 Derrell Piper 1413 Network Alchemy 1414 1521.5 Pacific Ave 1415 Santa Cruz, California, 95060 1416 United States of America 1417 +1 408 460-3822