idnits 2.17.1 draft-ietf-ipsec-ipsec-doi-06.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-19) 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 ([IO], Section 5) and MUST abort any association setup that...' (42 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 (November 14, 1997) is 9653 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 327, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Missing Reference: 'RFC-2093' is mentioned on line 328, but not defined == Unused Reference: 'AH' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'ESP' is defined on line 1154, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-02 -- Possible downref: Normative reference to a draft: ref. 'ARCFOUR' == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-01 -- Possible downref: Normative reference to a draft: ref. 'BLOW' -- Possible downref: Normative reference to a draft: ref. 'CAST' == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-ciph-des-expiv-00 -- Possible downref: Normative reference to a draft: ref. '3DES' -- Possible downref: Normative reference to a draft: ref. 'DESMAC' == Outdated reference: A later version (-02) exists of draft-ietf-ipsec-auth-hmac-md5-96-01 == Outdated reference: A later version (-02) exists of draft-ietf-ipsec-auth-hmac-sha196-01 -- Possible downref: Normative reference to a draft: ref. 'IDEA' == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-04 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IO') == 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') ** 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: 18 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Derrell Piper 3 INTERNET-DRAFT cisco Systems 4 draft-ietf-ipsec-ipsec-doi-06.txt November 14, 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 5. 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. 88 All multi-octet binary values are stored in network byte order. 90 4.2 IPSEC Situation Definition 92 Within ISAKMP, the Situation provides information that can be used by 93 the responder to make a policy determination about how to process the 94 incoming Security Association request. For the IPSEC DOI, the 95 Situation field is a four (4) octet bitmask with the following 96 values. 98 Situation Value 99 --------- ----- 100 SIT_IDENTITY_ONLY 0x01 101 SIT_SECRECY 0x02 102 SIT_INTEGRITY 0x04 104 All other values are reserved to IANA. 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 ([IO], Section 5) and MUST abort any association setup that 115 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 175 ISAKMP/Oakley key management daemon. On protected-mode multiuser 176 operating systems, this key management daemon will likely exist as a 177 separate 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 [IO] Section 5.3), 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 Identifiers 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 The size of this field is one octet. The values 5-248 are reserved 271 to IANA. Values 249-255 are reserved for private use. 273 4.4.1.1 PROTO_ISAKMP 275 The PROTO_ISAKMP type specifies message protection required during 276 Phase I of the ISAKMP protocol. The specific protection mechanism 277 used for the IPSEC DOI is described in [IO]. All implementations 278 within the IPSEC DOI MUST support PROTO_ISAKMP. 280 NB: ISAKMP reserves the value one (1) across all DOI definitions. 282 4.4.1.2 PROTO_IPSEC_AH 284 The PROTO_IPSEC_AH type specifies IP packet authentication. The 285 default AH transform provides data origin authentication, integrity 286 protection, and replay prevention. For export control 287 considerations, confidentiality MUST NOT be provided by any 288 PROTO_IPSEC_AH transform. 290 4.4.1.3 PROTO_IPSEC_ESP 292 The PROTO_IPSEC_ESP type specifies IP packet confidentiality. 293 Authentication, if required, must be provided as part of the ESP 294 transform. The default ESP transform includes data origin 295 authentication, integrity protection, replay prevention, and 296 confidentiality. 298 4.4.1.4 PROTO_IPCOMP 300 The PROTO_IPCOMP type specifies IP packet compression. 302 4.4.2 IPSEC ISAKMP Transform Values 304 As part of an ISAKMP Phase I negotiation, the initiator's choice of 305 Key Exchange offerings is made using some host system policy 306 description. The actual selection of Key Exchange mechanism is made 307 using the standard ISAKMP Proposal Payload. The following table 308 lists the defined ISAKMP Phase I Transform Identifiers for the 309 Proposal Payload for the IPSEC DOI. 311 Transform Value 312 --------- ----- 313 RESERVED 0 314 KEY_OAKLEY 1 316 The size of this field is one octet. The values 2-248 are reserved 317 to IANA. Values 249-255 are reserved for private use. 319 Within the ISAKMP and IPSEC DOI framework it is possible to define 320 key establishment protocols other than Oakley. Previous versions of 321 this document defined types both for manual keying and for schemes 322 based on use of a generic Key Distribution Center (KDC). These 323 identifiers have been removed from the current document. 325 The IPSEC DOI can still be extended later to include values for 326 additional non-Oakley key establishment protocols for ISAKMP and 327 IPSEC, such as Kerberos [RFC-1510] or the Group Key Management 328 Protocol (GKMP) [RFC-2093]. 330 4.4.2.1 KEY_OAKLEY 332 The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman 333 key exchange as defined in the [IO] document. All implementations 334 within the IPSEC DOI MUST support KEY_OAKLEY. 336 4.4.3 IPSEC AH Transform Values 338 The Authentication Header Protocol (AH) defines one mandatory and 339 several optional transforms used to provide authentication, 340 integrity, and replay detection. The following table lists the 341 defined AH Transform Identifiers for the ISAKMP Proposal Payload for 342 the IPSEC DOI. 344 Transform ID Value 345 ------------ ----- 346 RESERVED 0-1 347 AH_MD5 2 348 AH_SHA 3 349 AH_DES 4 351 The size of this field is one octet. The values 5-248 are reserved 352 to IANA. Values 249-255 are reserved for private use. 354 4.4.3.1 AH_MD5 356 The AH_MD5 type specifies a generic AH transform using MD5. The 357 actual protection suite is determined in concert with an associated 358 SA attribute list. A generic MD5 transform is currently undefined. 360 All implementations within the IPSEC DOI MUST support AH_MD5 along 361 with the Auth(HMAC-MD5) attribute. This suite is defined as the 362 HMAC-MD5-96 transform described in [HMACMD5]. 364 The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH 365 transform (Key/Pad/Data/Key) described in RFC-1826. This mode MAY be 366 negotiated for compatibility with older implementations. 367 Implementations are not required to support this mode. 369 4.4.3.2 AH_SHA 371 The AH_SHA type specifies a generic AH transform using SHA-1. The 372 actual protection suite is determined in concert with an associated 373 SA attribute list. A generic SHA transform is currently undefined. 375 All implementations within the IPSEC DOI MUST support AH_SHA along 376 with the Auth(HMAC-SHA) attribute. This suite is defined as the 377 HMAC-SHA-1-96 transform described in [HMACSHA]. 379 4.4.3.3 AH_DES 381 The AH_DES type specifies a generic AH transform using DES. The 382 actual protection suite is determined in concert with an associated 383 SA attribute list. A generic DES transform is currently undefined. 385 The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute 386 to be the DES-MAC transform described in [DESMAC]. Implementations 387 are not required to support this mode. 389 4.4.4 IPSEC ESP Transform Identifiers 391 The Encapsulating Security Payload (ESP) defines one mandatory and 392 many optional transforms used to provide data confidentiality. The 393 following table lists the defined ESP Transform Identifiers for the 394 ISAKMP Proposal Payload for the IPSEC DOI. 396 Transform ID Value 397 ------------ ----- 398 ESP_NULL 0 399 ESP_DES_IV64 1 400 ESP_DES 2 401 ESP_3DES 3 402 ESP_RC5 4 403 ESP_IDEA 5 404 ESP_CAST 6 405 ESP_BLOWFISH 7 406 ESP_3IDEA 8 407 ESP_DES_IV32 9 408 ESP_ARCFOUR 10 410 The size of this field is one octet. The values 11-248 are reserved 411 to IANA. Values 249-255 are reserved for private use. 413 4.4.4.1 ESP_NULL 415 The ESP_NULL type specifies no confidentiality is to be provided by 416 ESP. ESP_NULL is used when ESP is being used to tunnel packets which 417 require only authentication and integrity protection. See the Auth 418 Algorithm attribute description in Section 4.5 for additional 419 requirements relating to the use of ESP_NULL. 421 4.4.4.2 ESP_DES_IV64 423 The ESP_DES_IV64 type specifies the DES-CBC transform defined in 424 RFC-1827 and RFC-1829 using a 64-bit IV. This mode MAY be negotiated 425 for compatibility with older implementations. Implementations are 426 not required to support this mode. 428 4.4.4.3 ESP_DES 430 The ESP_DES type specifies a generic DES transform using DES-CBC. 431 The actual protection suite is determined in concert with an 432 associated SA attribute list. A generic transform is currently 433 undefined. 435 All implementations within the IPSEC DOI MUST support ESP_DES along 436 with the Auth(HMAC-MD5) attribute. This suite is defined as the 437 [DES] transform, with authentication and integrity provided by HMAC 438 MD5. 440 4.4.4.4 ESP_3DES 442 The ESP_3DES type specifies a generic triple-DES transform. The 443 actual protection suite is determined in concert with an associated 444 SA attribute list. The generic transform is currently undefined. 446 All implementations within the IPSEC DOI are strongly encourage to 447 support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite 448 is defined as the [3DES] transform, with authentication and integrity 449 provided by HMAC MD5. 451 4.4.4.5 ESP_RC5 453 The ESP_RC5 type specifies the RC5 transform defined in [RC5]. 455 4.4.4.6 ESP_IDEA 457 The ESP_IDEA type specifies the IDEA transform defined in [IDEA]. 459 4.4.4.7 ESP_CAST 461 The ESP_CAST type specifies the CAST transform defined in [CAST]. 463 4.4.4.8 ESP_BLOWFISH 464 The ESP_BLOWFISH type specifies the BLOWFISH transform defined in 465 [BLOW]. 467 4.4.4.9 ESP_3IDEA 469 The ESP_3IDEA type is reserved for triple-IDEA. 471 4.4.4.10 ESP_DES_IV32 473 The ESP_DES_IV32 type specifies the DES-CBC transform defined in 474 RFC-1827 and RFC-1829 using a 32-bit IV. This mode MAY be negotiated 475 for compatibility with older implementations. Implementations are 476 not required to support this mode. 478 4.4.4.11 ESP_ARCFOUR 480 The ESP_ARCFOUR type specifies the ARCFOUR transform defined in 481 [ARCFOUR]. 483 4.4.5 IPSEC IPCOMP Transform Identifiers 485 The IP Compression (IPCOMP) transforms define optional compression 486 algorithms that can be negotiated to provide for IP compression 487 before ESP encryption. The following table lists the defined IPCOMP 488 Transform Identifiers for the ISAKMP Proposal Payload within the 489 IPSEC DOI. 491 Transform ID Value 492 ------------ ----- 493 RESERVED 0 494 IPCOMP_OUI 1 495 IPCOMP_DEFLATE 2 496 IPCOMP_LZS 3 497 IPCOMP_V42BIS 4 499 The size of this field is one octet. The values 5-248 are reserved 500 to IANA. Values 249-255 are reserved for private use. 502 4.4.5.1 IPCOMP_OUI 504 The IPCOMP_OUI type specifies a proprietary compression transform. 505 The IPCOMP_OUI type must be accompanied by an attribute which further 506 identifies the specific vendor algorithm. 508 4.4.5.2 IPCOMP_DEFLATE 510 The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate 511 algorithm. 513 4.4.5.3 IPCOMP_LZS 515 The IPCOMP_LZS type specifies the use of the Stac Electronics LZS 516 algorithm. 518 4.4.5.4 IPCOMP_V42BIS 520 The IPCOMP_V42BIS type specifies the use of V42bis compression. 522 4.5 IPSEC Security Association Attributes 524 The following SA attribute definitions are used in phase II of an 525 ISAKMP/Oakley negotiation. Attribute types can be either Basic (B) 526 or Variable-Length (V). Encoding of these attributes is defined in 527 the base ISAKMP specification. 529 Attribute Types 531 class value type 532 ------------------------------------------------- 533 SA Life Type 1 B 534 SA Life Duration 2 B/V 535 Group Description 3 B 536 Encapsulation Mode 4 B 537 Authentication Algorithm 5 B 538 Key Length 6 B 539 Key Rounds 7 B 540 Compress Dictionary Size 8 B 541 Compress Private Algorithm 9 B/V 543 The size of this field is two octets, with the high bit reserved for 544 the ISAKMP B/V encoding. The values 10-32000 are reserved to IANA. 545 Values 32001-32767 are for experimental use. 547 Class Values 549 SA Life Type 550 SA Duration 552 Specifies the time-to-live for the overall security 553 association. When the SA expires, all keys negotiated under 554 the association (AH or ESP) must be renegotiated. The life 555 type values are: 557 RESERVED 0 558 seconds 1 559 kilobytes 2 560 Values 3-61439 are reserved to IANA. Values 61440-65535 are 561 for experimental use. For a given Life Type, the value of 562 the Life Duration attribute defines the actual length of the 563 component lifetime -- either a number of seconds, or a number 564 of Kbytes that can be protected. 566 If unspecified, the default value shall be assumed to be 567 28800 seconds (8 hours). 569 An SA Life Duration attribute MUST always follow an SA Life 570 Type which describes the units of duration. 572 See Section 4.5.4 for additional information relating to 573 lifetime notification. 575 Group Description 577 Specifies the Oakley Group to be used in a PFS QM 578 negotiation. For a list of supported values, see Appendix A 579 of [IO]. 581 Encapsulation Mode 582 RESERVED 0 583 Tunnel 1 584 Transport 2 586 Values 3-61439 are reserved to IANA. Values 61440-65535 are 587 for private use among mutually consenting parties. 589 If unspecified, the default value shall be assumed to be 590 unspecified (host-dependent). 592 Authentication Algorithm 593 RESERVED 0 594 HMAC-MD5 1 595 HMAC-SHA-1 2 596 DES-MAC 3 597 KPDK 4 599 Values 5-61439 are reserved to IANA. Values 61440-65535 are 600 for private use among mutually consenting parties. 602 There is no default value for Auth Algorithm, as it must be 603 specified to correctly identify the applicable AH or ESP 604 transform, except in the following case. 606 When negotiating ESP without authentication, the Auth 607 Algorithm attribute MUST NOT be included in the proposal. 609 When negotiating ESP without confidentiality, the Auth 610 Algorithm attribute MUST be included in the proposal and 611 the ESP transform ID must be ESP_NULL. 613 Key Length 614 RESERVED 0 616 There is no default value for Key Length, as it must be 617 specified for transforms using ciphers with variable key 618 lengths. 620 Key Rounds 621 RESERVED 0 623 There is no default value for Key Rounds, as it must be 624 specified for transforms using ciphers with varying 625 numbers of rounds. 627 Compression Dictionary Size 628 RESERVED 0 630 Specifies the log2 maximum size of the dictionary. 632 There is no default value for dictionary size. 634 Compression Private Algorithm 636 Specifies a private vendor compression algorithm. The first 637 three (3) octets must be an IEEE assigned company_id (OUI). 638 The next octet may be a vendor specific compression subtype, 639 followed by zero or more octets of vendor data. 641 4.5.1 Required Attribute Support 643 To ensure basic interoperability, all implementations MUST be 644 prepared to negotiate all of the following attributes. 646 SA Life Type 647 SA Duration 648 Auth Algorithm 650 4.5.2 Attribute Parsing Requirement (Lifetime) 652 To allow for flexible semantics, the IPSEC DOI requires that a 653 conforming ISAKMP implementation MUST correctly parse an attribute 654 list that contains multiple instances of the same attribute class, so 655 long as the different attribute entries do not conflict with one 656 another. Currently, the only attributes which requires this 657 treatment are Life Type and Duration. 659 To see why this is important, the following example shows the binary 660 encoding of a four entry attribute list that specifies an SA Lifetime 661 of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a 662 complete description of the attribute encoding format.) 664 Attribute #1: 665 0x80010001 (AF = 1, type = SA Life Type, value = seconds) 667 Attribute #2: 668 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 669 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) 671 Attribute #3: 672 0x80010002 (AF = 1, type = SA Life Type, value = KB) 674 Attribute #4: 675 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 676 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) 678 If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED 679 Notification Payload SHOULD be returned and the security association 680 setup MUST be aborted. 682 4.5.3 Attribute Negotiation 684 If an implementation receives a defined IPSEC DOI attribute (or 685 attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT 686 SHOULD be sent and the security association setup MUST be aborted, 687 unless the attribute value is in the reserved range. 689 If an implementation receives an attribute value in the reserved 690 range, an implementation MAY chose to continue based on local policy. 692 4.5.4 Lifetime Notification 694 When an initiator offers an SA lifetime greater than what the 695 responder desires based on their local policy, the responder has 696 three choices: 1) fail the negotiation entirely; 2) complete the 697 negotiation but use a shorter lifetime than what was offered; 3) 698 complete the negotiation and send an advisory notification to the 699 initiator indicating the responder's true lifetime. The choice of 700 what the responder actually does is implementation specific and/or 701 based on local policy. 703 To ensure interoperability in the latter case, the IPSEC DOI requires 704 the following only when the responder wishes to notify the initiator: 706 if the initiator offers an SA lifetime longer than the responder is 707 willing to accept, the responder SHOULD include an ISAKMP 708 Notification Payload in the exchange that includes the responder's 709 IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the 710 RESPONDER-LIFETIME Notification Message type which MUST be used for 711 this purpose. 713 4.6 IPSEC Payload Content 715 The following sections describe those ISAKMP payloads whose data 716 representations are dependent on the applicable DOI. 718 4.6.1 Security Association Payload 720 The following diagram illustrates the content of the Security 721 Association Payload for the IPSEC DOI. See Section 4.2 for a 722 description of the Situation bitmap. 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 ! Next Payload ! RESERVED ! Payload Length ! 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 ! Domain of Interpretation (IPSEC) | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 ! Situation (bitmap) ! 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 ! Labeled Domain Identifier ! 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 ! Secrecy Length (in octets) ! RESERVED ! 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 ~ Secrecy Level ~ 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 ! Secrecy Cat. Length (in bits) ! RESERVED ! 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 ~ Secrecy Category Bitmap ~ 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 ! Integrity Length (in octets) ! RESERVED ! 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 ~ Integrity Level ~ 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 ! Integ. Cat. Length (in bits) ! RESERVED ! 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 ~ Integrity Category Bitmap ~ 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Figure 1: Security Association Payload Format 753 The Security Association Payload is defined as follows: 755 o Next Payload (1 octet) - Identifier for the payload type of 756 the next payload in the message. If the current payload is 757 the last in the message, this field will be zero (0). 759 o RESERVED (1 octet) - Unused, must be zero (0). 761 o Payload Length (2 octets) - Length, in octets, of the current 762 payload, including the generic header. 764 o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, 765 which has been assigned the value one (1). 767 o Situation (4 octets) - Bitmask used to interpret the 768 remainder of the Security Association Payload. See Section 769 4.2 for a complete list of values. 771 o Labeled Domain Identifier (4 octets) - IANA Assigned Number 772 used to interpret the Secrecy and Integrity information. 774 o Secrecy Length (2 octets) - Specifies the length, in octets, 775 of the secrecy level identifier. 777 o RESERVED (2 octets) - Unused, must be zero (0). 779 o Secrecy Category Length (2 octets) - Specifies the length, in 780 bits, of the secrecy category (compartment) bitmap, excluding 781 pad bits. 783 o RESERVED (2 octets) - Unused, must be zero (0). 785 o Secrecy Category Bitmap (variable length) - A bitmap used to 786 designate secrecy categories (compartments) that are 787 required. The bitmap MUST be padded with zero (0) to the 788 next 32-bit boundary. 790 o Integrity Length (2 octets) - Specifies the length, in 791 octets, of the integrity level identifier. 793 o RESERVED (2 octets) - Unused, must be zero (0). 795 o Integrity Category Length (2 octets) - Specifies the length, 796 in bits, of the integrity category (compartment) bitmap, 797 excluding pad bits. 799 o RESERVED (2 octets) - Unused, must be zero (0). 801 o Integrity Category Bitmap (variable length) - A bitmap used 802 to designate integrity categories (compartments) that are 803 required. The bitmap MUST be padded with zero (0) to the 804 next 32-bit boundary. 806 4.6.1.1 Labeled Domain Identifier Values 808 The following table lists the assigned values for the Labeled Domain 809 Identifier field contained in the Situation field of the Security 810 Association Payload. 812 Domain Value 813 ------- ----- 814 RESERVED 0 816 The values 1-0x7fffffff are reserved to IANA. Values 817 0x8000000-0xffffffff are reserved for private use. 819 4.6.2 Identification Payload Content 821 The Identification Payload is used to identify the initiator of the 822 Security Association. The identity of the initiator SHOULD be used 823 by the responder to determine the correct host system security policy 824 requirement for the association. For example, a host might choose to 825 require authentication and integrity without confidentiality (AH) 826 from a certain set of IP addresses and full authentication with 827 confidentiality (ESP) from another range of IP addresses. The 828 Identification Payload provides information that can be used by the 829 responder to make this decision. 831 During Phase I negotiations, the ID port and protocol fields MUST be 832 set to zero or to UDP port 500. If an implementation receives any 833 other values, this MUST be treated as an error and the security 834 association setup MUST be aborted. This event SHOULD be auditable. 836 The following diagram illustrates the content of the Identification 837 Payload. 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 ! Next Payload ! RESERVED ! Payload Length ! 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 ! ID Type ! Protocol ID ! Port ! 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 ~ Identification Data ~ 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Figure 2: Identification Payload Format 850 The Identification Payload fields are defined as follows: 852 o Next Payload (1 octet) - Identifier for the payload type of 853 the next payload in the message. If the current payload is 854 the last in the message, this field will be zero (0). 856 o RESERVED (1 octet) - Unused, must be zero (0). 858 o Payload Length (2 octets) - Length, in octets, of the 859 identification data, including the generic header. 861 o Identification Type (1 octet) - Value describing the 862 identity information found in the Identification Data field. 864 o Protocol ID (1 octet) - Value specifying an associated 865 IP protocol ID (e.g. UDP/TCP). A value of zero means that the 866 Protocol ID field should be ignored. 868 o Port (2 octets) - Value specifying an associated port. 869 A value of zero means that the Port field should be ignored. 871 o Identification Data (variable length) - Value, as indicated 872 by the Identification Type. 874 4.6.2.1 Identification Type Values 876 The following table lists the assigned values for the Identification 877 Type field found in the Identification Payload. 879 ID Type Value 880 ------- ----- 881 RESERVED 0 882 ID_IPV4_ADDR 1 883 ID_FQDN 2 884 ID_USER_FQDN 3 885 ID_IPV4_ADDR_SUBNET 4 886 ID_IPV6_ADDR 5 887 ID_IPV6_ADDR_SUBNET 6 888 ID_IPV4_ADDR_RANGE 7 889 ID_IPV6_ADDR_RANGE 8 890 ID_DER_ASN1_DN 9 891 ID_DER_ASN1_GN 10 892 ID_KEY_ID 11 894 The size of this field is one octet. The values 12-248 are reserved 895 to IANA. Values 249-255 are reserved for private use. 897 For types where the ID entity is variable length, the size of the ID 898 entity is computed from size in the ID payload header. 900 When an ISAKMP/Oakley exchange is authenticated using certificates 901 (of any format), any ID's used for input to local policy decisions 902 SHOULD be contained in the certificate used in the authentication of 903 the exchange. 905 4.6.2.2 ID_IPV4_ADDR 907 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 909 4.6.2.3 ID_FQDN 911 The ID_FQDN type specifies a fully-qualified domain name string. An 912 example of a ID_FQDN is, "foo.bar.com". The string should not 913 contain any terminators. 915 4.6.2.4 ID_USER_FQDN 917 The ID_USER_FQDN type specifies a fully-qualified username string, An 918 example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should 919 not contain any terminators. 921 4.6.2.5 ID_IPV4_ADDR_SUBNET 923 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, 924 represented by two four (4) octet values. The first value is an IPv4 925 address. The second is an IPv4 network mask. Note that ones (1s) in 926 the network mask indicate that the corresponding bit in the address 927 is fixed, while zeros (0s) indicate a "wildcard" bit. 929 4.6.2.6 ID_IPV6_ADDR 931 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 932 address. 934 4.6.2.7 ID_IPV6_ADDR_SUBNET 936 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, 937 represented by two sixteen (16) octet values. The first value is an 938 IPv6 address. The second is an IPv6 network mask. Note that ones 939 (1s) in the network mask indicate that the corresponding bit in the 940 address is fixed, while zeros (0s) indicate a "wildcard" bit. 942 4.6.2.8 ID_IPV4_ADDR_RANGE 944 The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, 945 represented by two four (4) octet values. The first value is the 946 beginning IPv4 address (inclusive) and the second value is the ending 947 IPv4 address (inclusive). All addresses falling between the two 948 specified addresses are considered to be within the list. 950 4.6.2.9 ID_IPV6_ADDR_RANGE 952 The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, 953 represented by two sixteen (16) octet values. The first value is the 954 beginning IPv6 address (inclusive) and the second value is the ending 955 IPv6 address (inclusive). All addresses falling between the two 956 specified addresses are considered to be within the list. 958 4.6.2.10 ID_DER_ASN1_DN 960 The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 961 X.500 Distinguished Name [X.501] of the principal whose certificates 962 are being exchanged to establish the SA. 964 4.6.2.11 ID_DER_ASN1_GN 966 The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 967 X.500 GeneralName [X.509] of the principal whose certificates are 968 being exchanged to establish the SA. 970 4.6.2.12 ID_KEY_ID 972 The ID_KEY_ID type specifies an opaque byte stream which may be used 973 to pass vendor-specific information necessary to identify which pre- 974 shared key should be used to authenticate Aggressive mode 975 negotiations. 977 4.6.3 IPSEC DOI Notify Message Types 979 ISAKMP defines two blocks of Notify Message codes, one for errors and 980 one for status messages. ISAKMP also allocates a portion of each 981 block for private use within a DOI. The IPSEC DOI defines the 982 following private message types for its own use. 984 Notify Messages - Error Types Value 985 ----------------------------- ----- 986 RESERVED 8192 988 Notify Messages - Status Types Value 989 ------------------------------ ----- 990 RESPONDER-LIFETIME 24576 991 REPLAY-STATUS 24577 992 INITIAL-CONTACT 24578 994 Notification Status Messages MUST be sent under the protection of an 995 ISAKMP SA: either as a payload in the last Main Mode exchange; in a 996 separate Informational Exchange after Main Mode or Aggressive Mode 997 processing is complete; or as a payload in any Quick Mode exchange. 998 These messages MUST NOT be sent in Aggressive Mode exchanges unless 999 the authentication mode is RSA Encryption, since Aggressive Mode does 1000 not otherwise provide the necessary protection to bind the Notify 1001 Status Message to the exchange. 1003 Implementation Note: the ISAKMP protocol does not guarantee delivery 1004 of Notification Status messages when sent in an ISAKMP Informational 1005 Exchange. To ensure receipt of any particular message, the sender 1006 SHOULD include a Notification Payload in a defined Main Mode, Quick 1007 Mode, or Aggressive exchange which is protected by a retransmission 1008 timer. 1010 4.6.3.1 RESPONDER-LIFETIME 1012 The RESPONDER-LIFETIME status message may be used to communicate the 1013 IPSEC SA lifetime chosen by the responder. 1015 When present, the Notification Payload MUST have the following 1016 format: 1018 o Payload Length - set to length of payload + size of data (var) 1019 o DOI - set to IPSEC DOI (1) 1020 o Protocol ID - set to selected Protocol ID from chosen SA 1021 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1022 o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) 1023 o SPI - set to the two ISAKMP cookies 1024 o Notification Data - contains an ISAKMP attribute list with the 1025 responder's actual SA lifetime(s) 1027 Implementation Note: saying that the Notification Data field contains 1028 an attribute list is equivalent to saying that the Notification Data 1029 field has zero length and the Notification Payload has an associated 1030 attribute list. 1032 4.6.3.2 REPLAY-STATUS 1034 The REPLAY-STATUS status message may be used for positive 1035 confirmation of the responder's election on whether or not he is to 1036 perform anti-replay detection. 1038 When present, the Notification Payload MUST have the following 1039 format: 1041 o Payload Length - set to length of payload + size of data (4) 1042 o DOI - set to IPSEC DOI (1) 1043 o Protocol ID - set to selected Protocol ID from chosen SA 1044 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1045 o Notify Message Type - set to REPLAY-STATUS 1046 o SPI - set to the two ISAKMP cookies 1047 o Notification Data - a 4 octet value: 1048 0 = replay detection disabled 1049 1 = replay detection enabled 1051 4.6.3.3 INITIAL-CONTACT 1053 The INITIAL-CONTACT status message may be used when one side wishes 1054 to inform the other that this is the first SA being established with 1055 the remote system. The receiver of this Notification Message might 1056 then elect to delete any existing SA's it has for the sending system 1057 under the assumption that the sending system has rebooted and no 1058 longer has access to the original SA's and their associated keying 1059 material. When used, the content of the Notification Data field 1060 SHOULD be null (i.e. the Payload Length should be set to the fixed 1061 length of Notification Payload). 1063 When present, the Notification Payload MUST have the following 1064 format: 1066 o Payload Length - set to length of payload + size of data (0) 1067 o DOI - set to IPSEC DOI (1) 1068 o Protocol ID - set to selected Protocol ID from chosen SA 1069 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1070 o Notify Message Type - set to INITIAL-CONTACT 1071 o SPI - set to the two ISAKMP cookies 1072 o Notification Data - 1074 4.7 IPSEC Key Exchange Requirements 1076 The IPSEC DOI introduces no additional Key Exchange types. 1078 5. Change Log 1080 5.1 Changes from V5 1082 The following changes were made relative to the IPSEC DOI V5: 1084 o corrected SPI size in Lifetime Notification text 1085 o changed REPLAY-ENABLED to REPLAY-STATUS 1086 o moved RESPONDER-LIFETIME payload definition from Section 4.5.4 1087 to Section 4.6.3.1 1088 o added explicit payload layout for 4.6.3.3 1089 o added Implementation Note to Section 4.6.3 introduction 1090 o changed AH_SHA text to require SHA-1 in addition to MD5 1091 o updated references 1093 5.2 Changes from V4 1095 The following changes were made relative to the IPSEC DOI V4: 1097 o moved compatibility AH KPDK authentication method from AH 1098 transform ID to Authentication Algorithm identifier 1099 o added REPLAY-ENABLED notification message type per Architecture 1100 o added INITIAL-CONTACT notification message type per list 1101 o added text to ensure protection for Notify Status messages 1102 o added Lifetime qualification to attribute parsing section 1103 o added clarification that Lifetime notification is optional 1104 o removed private Group Description list (now points at [IO]) 1105 o replaced Terminology with pointer to RFC-2119 1106 o updated HMAC MD5 and SHA-1 ID references 1107 o updated Section 1 (Abstract) 1108 o updated Section 4.4 (IPSEC Assigned Numbers) 1109 o added restriction for ID port/protocol values for Phase I 1111 5.3 Changes from V3 to V4 1113 The following changes were made relative to the IPSEC DOI V3, that 1114 was posted to the IPSEC mailing list prior to the Munich IETF: 1116 o added ESP transform identifiers for NULL and ARCFOUR 1117 o renamed HMAC Algorithm to Auth Algorithm to accommodate 1118 DES-MAC and optional authentication/integrity for ESP 1119 o added AH and ESP DES-MAC algorithm identifiers 1120 o removed KEY_MANUAL and KEY_KDC identifier definitions 1121 o added lifetime duration MUST follow lifetype attribute to 1122 SA Life Type and SA Life Duration attribute definition 1123 o added lifetime notification and IPSEC DOI message type table 1124 o added optional authentication and confidentiality 1125 restrictions to MAC Algorithm attribute definition 1126 o corrected attribute parsing example (used obsolete attribute) 1127 o corrected several Internet Draft document references 1128 o added ID_KEY_ID per ipsec list discussion (18-Mar-97) 1129 o removed Group Description default for PFS QM ([IO] MUST) 1131 6. Security Considerations 1133 This entire draft pertains to a negotiated key management protocol, 1134 combining Oakley ([OAKLEY]) with ISAKMP ([ISAKMP]), which negotiates 1135 and derives keying material for security associations in a secure and 1136 authenticated manner. Specific discussion of the various security 1137 protocols and transforms identified in this document can be found in 1138 the associated base documents and in the cipher references. 1140 Acknowledgements 1141 This document is derived, in part, from previous works by Douglas 1142 Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, 1143 and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran 1144 Atkinson also contributed suggestions and, in many cases, text. 1146 References 1148 [AH] Kent, S., Atkinson, R., "IP Authentication Header," draft-ietf- 1149 ipsec-auth-header-02.txt. 1151 [ARCFOUR] Thayer, R., "The ESP ARCFOUR Algorithm," draft-ietf-ipsec- 1152 ciph-arcfour-00.txt. 1154 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 1155 (ESP)," draft-ietf-ipsec-esp-v2-01.txt. 1157 [BLOW] Adams, R., "The ESP Blowfish-CBC Algorithm Using an Explicit 1158 IV," draft-ietf-ipsec-ciph-blowfish-cbc-00.txt. 1160 [CAST] Pereira, R., Carter, G., "The ESP CAST128-CBC Algorithm," 1161 draft-ietf-ipsec-ciph-cast128-cbc-00.txt. 1163 [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm 1164 With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-00.txt. 1166 [3DES] Pereira, R., Thayer, R., "The ESP 3DES-CBC Algorithm Using an 1167 Explicit IV," draft-ietf-ipsec-ciph-3des-expiv-00.txt. 1169 [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft- 1170 bitan-auth-des-mac-00.txt. 1172 [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and 1173 AH," draft-ietf-ipsec-auth-hmac-md5-96-01.txt. 1175 [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP 1176 and AH," draft-ietf-ipsec-auth-hmac-sha196-01.txt. 1178 [IDEA] Adams, R., "The ESP IDEA-CBC Algorithm Using Explicit IV," 1179 draft-ietf-ipsec-ciph-idea-cbc-00.txt. 1181 [IO] Harkins, D., Carrel, D., "The Resolution of ISAKMP with Oakley," 1182 draft-ietf-ipsec-isakmp-oakley-04.txt. 1184 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1185 "Internet Security Association and Key Management Protocol (ISAKMP)," 1186 draft-ietf-ipsec-isakmp-08.{ps,txt}. 1188 [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft- 1189 ietf-ipsec-oakley-02.txt. 1191 [ROADMAP] Thayer, R., Doraswamy, N., Glenn, R., "IP Security 1192 Documentation Roadmap," draft-ietf-ipsec-doc-roadmap-01.txt. 1194 [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key 1195 Management API, Version 2", draft-mcdonald-pf-key-v2-03.txt. 1197 [RC5] Pereira, R., Baldwin, R., "The ESP RC5-CBC Transform," draft- 1198 ietf-ipsec-ciph-rc5-cbc-00.txt. 1200 [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems 1201 Interconnection - The Directory: Models", CCITT/ITU Recommendation 1202 X.501, 1993. 1204 [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems 1205 Interconnection - The Directory: Authentication Framework", 1206 CCITT/ITU Recommendation X.509, 1993. 1208 Author's Address: 1210 Derrell Piper 1211 cisco Systems 1212 101 Cooper St 1213 Santa Cruz, California, 95060 1214 United States of America 1215 +1 408 457-5384