idnits 2.17.00 (12 Aug 2021) /tmp/idnits30843/draft-ietf-ipsec-ipsec-doi-02.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 (2022-05-20) 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) 2022 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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 74: '... - MUST...' RFC 2119 keyword, line 79: '... - SHOULD...' RFC 2119 keyword, line 86: '... - MAY...' RFC 2119 keyword, line 99: '...nown identifiers MUST be registered wi...' RFC 2119 keyword, line 127: '... implementations MUST support SIT_IDEN...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 28, 1997) is 9212 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: 'STD-2' is mentioned on line 97, but not defined == Unused Reference: 'RFC-1825' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'RFC-1826' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC-1827' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'RFC-1828' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'RFC-1829' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC-2065' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'RFC-2085' is defined on line 897, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Downref: Normative reference to an Historic RFC: RFC 1828 ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-ah-hmac-sha-03 -- Possible downref: Normative reference to a draft: ref. 'HMACSHA' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-esp-des-md5 is -02, but you're referring to -03. -- Possible downref: Normative reference to a draft: ref. 'Hughes' == Outdated reference: draft-ietf-ipsec-isakmp-oakley has been published as RFC 2409 == Outdated reference: draft-ietf-ipsec-isakmp has been published as RFC 2408 -- Possible downref: Normative reference to a draft: ref. 'Naganand' == Outdated reference: draft-ietf-ipsec-oakley has been published as RFC 2412 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'OAKLEY') == Outdated reference: draft-mcdonald-pf-key-v2 has been published as RFC 2367 ** 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 (==), 7 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-02.txt February 28, 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 and processing guidelines that occur 36 within a given Domain of Interpretation (DOI). This document details 37 the Internet IP Security DOI, which is defined to cover the IP 38 security protocols that use ISAKMP to negotiate their security 39 associations. 41 2. Introduction 43 Within ISAKMP, a Domain of Interpretation is used to group related 44 protocols using ISAKMP to negotiate security associations. Security 45 protocols sharing a DOI choose security protocol and cryptographic 46 transforms from a common namespace and share key exchange protocol 47 identifiers. They also share a common interpretation of DOI-specific 48 payload data content, including the Security Association and 49 Identification payloads. 51 Overall, ISAKMP places the following requirements on a DOI 52 definition: 54 o define the naming scheme for DOI-specific protocol identifiers 55 o define the interpretation for the Situation field 56 o define the set of applicable security policies 57 o define the syntax for DOI-specific SA Attributes (phase II) 58 o define the syntax for DOI-specific payload contents 59 o define additional mappings or Key Exchange types, if needed 61 The remainder of this document details the instantiation of these 62 requirements for using the IP Security (IPSEC) protocols to provide 63 data origin authentication and/or data confidentiality for IP packets 64 sent between cooperating host systems and/or firewalls. 66 3. Terms and Definitions 68 3.1 Requirements Terminology 70 In this document, the words that are used to define the significance 71 of each particular requirement are usually capitalised. These words 72 are: 74 - MUST 76 This word or the adjective "REQUIRED" means that the item is an 77 absolute requirement of the specification. 79 - SHOULD 81 This word or the adjective "RECOMMENDED" means that there might 82 exist valid reasons in particular circumstances to ignore this 83 item, but the full implications should be understood and the case 84 carefully weighed before taking a different course. 86 - MAY 88 This word or the adjective "OPTIONAL" means that this item is 89 truly optional. One vendor might choose to include the item 90 because a particular marketplace requires it or because it 91 enhances the product, for example; another vendor may omit the 92 same item. 94 4.1 IPSEC Naming Scheme 96 Within ISAKMP, all DOI's must be registered with the IANA in the 97 ``Assigned Numbers'' RFC [STD-2]. The IANA Assigned Number for the 98 Internet IP Security DOI is one (1). Within the IPSEC DOI, all 99 well-known identifiers MUST be registered with the IANA under the 100 Internet IP Security DOI. Unless otherwise noted, all tables within 101 this document refer to IANA Assigned Numbers for the IPSEC DOI. 103 All multi-octet binary values are stored in network byte order. 105 4.2 IPSEC Situation Definition 107 Within ISAKMP, the Situation provides information that can be used by 108 the responder to make a policy determination about how to process the 109 incoming Security Association request. For the IPSEC DOI, the 110 Situation field is a four (4) octet bitmask with the following 111 values. 113 Situation Value 114 --------- ----- 115 SIT_IDENTITY_ONLY 0x01 116 SIT_SECRECY 0x02 117 SIT_INTEGRITY 0x04 119 All other values are reserved to IANA. 121 4.2.1 SIT_IDENTITY_ONLY 123 The SIT_IDENTITY_ONLY type specifies that the security association 124 will be identified by source identity information present in an 125 associated Identification Payload. See Section 4.6.2 for a complete 126 description of the various Identification types. All IPSEC DOI 127 implementations MUST support SIT_IDENTITY_ONLY by including an 128 Identification Payload in at least one of the phase I Oakley 129 exchanges ([IO], Section 5) and MUST abort any association setup that 130 does not include an Identification Payload. 132 If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the 133 situation consists only of the 4 octet situation bitmap and does not 134 include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) 135 or any subsequent label information. Conversely, if the initiator 136 supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain 137 Identifier MUST be included in the situation payload. 139 4.2.2 SIT_SECRECY 141 The SIT_SECRECY type specifies that the security association is being 142 negotiated in an environment that requires labeled secrecy. If 143 SIT_SECRECY is present in the Situation bitmap, the Situation field 144 will be followed by variable-length data that includes a sensitivity 145 level and compartment bitmask. See Section 4.6.1 for a complete 146 description of the Security Association Payload format. 148 If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be 149 set in the Situation bitmap and no secrecy level or category bitmaps 150 shall be included. 152 If a responder does not support SIT_SECRECY, a SITUATION-NOT- 153 SUPPORTED Notification Payload SHOULD be returned and the security 154 association setup MUST be aborted. 156 4.2.3 SIT_INTEGRITY 158 The SIT_INTEGRITY type specifies that the security association is 159 being negotiated in an environment that requires labeled integrity. 160 If SIT_INTEGRITY is present in the Situation bitmap, the Situation 161 field will be followed by variable-length data that includes an 162 integrity level and compartment bitmask. If SIT_SECRECY is also in 163 use for the association, the integrity information immediately 164 follows the variable-length secrecy level and categories. See 165 section 4.6.1 for a complete description of the Security Association 166 Payload format. 168 If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST 169 NOT be set in the Situation bitmap and no integrity level or category 170 bitmaps shall be included. 172 If a responder does not support SIT_INTEGRITY, a SITUATION-NOT- 173 SUPPORTED Notification Payload SHOULD be returned and the security 174 association setup MUST be aborted. 176 4.3 IPSEC Security Policy Requirement 178 The IPSEC DOI does not impose specific security policy requirements 179 on any implementation. Host system policy issues are outside of the 180 scope of this document. 182 However, the following sections touch on some of the issues that must 183 be considered when designing an IPSEC DOI host implementation. This 184 section should be considered only informational in nature. 186 4.3.1 Key Management Issues 188 It is expected that many systems choosing to implement ISAKMP will 189 strive to provide a protected domain of execution for a combined 190 ISAKMP/Oakley key management daemon. On protected-mode multiuser 191 operating systems, this key management daemon will likely exist as a 192 separate privileged process. 194 In such an environment, a formalized API to introduce keying material 195 into the TCP/IP kernel may be desirable. The PF_KEY API [PFKEY] is 196 an example of one such API that provides an abstracted key management 197 interface. 199 4.3.2 Static Keying Issues 201 Host systems that implement static keys, either for use directly by 202 IPSEC, or for authentication purposes (see [IO] Section 5.3), should 203 take steps to protect the static keying material when it is not 204 residing in a protected memory domain or actively in use by the 205 TCP/IP kernel. 207 For example, on a laptop, one might choose to store the static keys 208 in a configuration store that is, itself, encrypted under a private 209 password. 211 Depending on the operating system and utility software installed, it 212 may not be possible to protect the static keys once they've been 213 loaded into the TCP/IP kernel, however they should not be trivially 214 recoverable on initial system startup without having to satisfy some 215 additional form of authentication. 217 4.3.3 Host Policy Issues 219 It is not realistic to assume that the transition to IPSEC will occur 220 overnight. Host systems must be prepared to implement flexible 221 policy lists that describe which systems they desire to speak 222 securely with and which systems they require speak securely to them. 223 Some notion of proxy firewall addresses may also be required. 225 A minimal approach is probably a static list of IP addresses, network 226 masks, and a security required flag or flags. 228 A more flexible implementation might consist of a list of wildcard 229 DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional 230 firewall address. The wildcard DNS name would be used to match 231 incoming or outgoing IP addresses, the in/out bitmask would be used 232 to determine whether or not security was to be applied and in which 233 direction, and the optional firewall address would be used to 234 indicate whether or not tunnel mode would be needed to talk to the 235 target system though an intermediate firewall. 237 4.3.4 Certificate Management 238 Host systems implementing a certificate-based authentication scheme 239 will need a mechanism for obtaining and managing a database of 240 certificates. 242 Secure DNS is to be one certificate distribution mechanism, however 243 the pervasive availability of secure DNS zones, in the short term, is 244 doubtful for many reasons. What's far more likely is that hosts will 245 need an ability to import certificates that they acquire through 246 secure, out-of-band mechanisms, as well as an ability to export their 247 own certificates for use by other systems. 249 However, manual certificate management should not be done so as to 250 preclude the ability to introduce dynamic certificate discovery 251 mechanisms and/or protocols as they become available. 253 4.4 IPSEC Assigned Numbers 255 The following sections list the Assigned Numbers for the IPSEC DOI 256 Security Protocol Identifiers, Transform Identifiers, and Security 257 Association Attribute Types. 259 4.4.1 IPSEC Security Protocol Identifiers 261 The ISAKMP proposal syntax was specifically designed to allow for the 262 simultaneous negotiation of multiple security protocol suites within 263 a single negotiation. As a result, the protocol suites listed below 264 form the set of protocols that can be negotiated at the same time. 265 It is a host policy decision as to what protocol suites might be 266 negotiated together. 268 The following table lists the values for the Security Protocol 269 Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC 270 DOI. 272 Protocol ID Value 273 ----------- ----- 274 RESERVED 0 275 PROTO_ISAKMP 1 276 PROTO_IPSEC_AH 2 277 PROTO_IPSEC_ESP 3 279 The size of this field is one octet. The values 4-248 are reserved 280 to IANA. Values 249-255 are reserved for private use. 282 4.4.1.1 PROTO_ISAKMP 284 The PROTO_ISAKMP type specifies message protection required during 285 Phase I of the ISAKMP protocol. The specific protection mechanism 286 used for the IPSEC DOI is described in [IO]. All implementations 287 within the IPSEC DOI MUST support PROTO_ISAKMP. 289 NB: ISAKMP reserves the value one (1) across all DOI definitions. 291 4.4.1.2 PROTO_IPSEC_AH 293 The PROTO_IPSEC_AH type specifies IP packet data origin 294 authentication. The default AH transform includes data origin 295 authentication and replay prevention. For export control 296 considerations, confidentiality MUST NOT be provided by any 297 PROTO_IPSEC_AH transform. 299 4.4.1.3 PROTO_IPSEC_ESP 301 The PROTO_IPSEC_ESP type specifies IP packet confidentiality. Data 302 origin authentication, if required, must be provided as part of the 303 ESP transform. The default ESP transform includes data origin 304 authentication, confidentiality, and replay prevention. 306 4.4.2 IPSEC ISAKMP Transform Values 308 As part of an ISAKMP Phase I negotiation, the initiator's choice of 309 Key Exchange offerings is made using some host system policy 310 description. The actual selection of Key Exchange mechanism is made 311 using the standard ISAKMP Proposal Payload. The following table 312 lists the defined ISAKMP Phase I Transform Identifiers for the 313 Proposal Payload for the IPSEC DOI. 315 Transform Value 316 --------- ----- 317 RESERVED 0 318 KEY_OAKLEY 1 319 KEY_MANUAL 2 320 KEY_KDC 3 322 The size of this field is one octet. The values 4-248 are reserved 323 to IANA. Values 249-255 are reserved for private use. 325 4.4.2.1 KEY_OAKLEY 327 The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman 328 key exchange as defined in the [IO] document. All implementations 329 within the IPSEC DOI MUST support KEY_OAKLEY. 331 4.4.2.2 KEY_MANUAL 333 The KEY_MANUAL type specifies that a shared secret key mechanism is 334 to be used in lieu of a dynamic key mechanism. Specific details of a 335 static key establishment protocol will be described in a future 336 document. 338 4.4.2.3 KEY_KDC 340 The KEY_KDC type specifies that a secret-key based Key Distribution 341 Center will be used to provide dynamic key exchange through a 342 Kerberos-like ticket protocol. Specific details of a KDC-based key 343 establishment protocol will be described in a future document. 345 4.4.3 IPSEC AH Transform Values 347 The Authentication Header Protocol (AH) defines one mandatory and 348 several optional transforms used to provide data origin 349 authentication. The following table lists the defined AH Transform 350 Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. 352 Transform ID Value 353 ------------ ----- 354 RESERVED 0 355 AH_MD5_KPDK 1 356 AH_MD5 2 357 AH_SHA 3 359 The size of this field is one octet. The values 4-248 are reserved 360 to IANA. Values 249-255 are reserved for private use. 362 4.4.3.1 AH_MD5_KPDK 364 The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key) 365 described in RFC-1826 and RFC-1828. This mode MAY be used for 366 compatibility with existing implementations. Implementations are not 367 required to support this mode. 369 4.4.3.2 AH_MD5 371 The AH_MD5 type specifies a generic AH transform using MD5. The 372 actual protection suite is determined in concert with an associated 373 SA attribute list. A generic MD5 transform is currently undefined. 375 All implementations within the IPSEC DOI MUST support AH_MD5 along 376 with the HMAC and REPLAY attributes. This suite is defined as the 377 HMAC-MD5 transform described in RFC-2085. 379 4.4.3.3 AH_SHA 381 The AH_SHA type specifies a generic AH transform using SHA-1. The 382 actual protection suite is determined in concert with an associated 383 SA attribute list. A generic SHA transform is currently undefined. 385 All implementations within the IPSEC DOI are strongly encouraged to 386 support AH_SHA along with the HMAC and REPLAY attributes. This suite 387 is defined as the HMAC-SHA transform described in [HMACSHA]. 389 4.4.4 IPSEC ESP Transform Identifiers 391 The Encapsulating Security Protocol (ESP) defines one mandatory and 392 several optional transforms used to provide data confidentiality. 393 The following table lists the defined ESP Transform Identifiers for 394 the ISAKMP Proposal Payload for the IPSEC DOI. 396 Transform ID Value 397 ------------ ----- 398 RESERVED 0 399 ESP_DES_CBC 1 400 ESP_DES 2 401 ESP_3DES 3 402 ESP_RC5 4 404 The size of this field is one octet. The values 5-248 are reserved 405 to IANA. Values 249-255 are reserved for private use. 407 4.4.4.1 ESP_DES_CBC 409 The ESP_DES_CBC type specifies the DES-CBC transform defined in RFC- 410 1827 and RFC-1829. This mode MAY be used for compatibility with 411 existing implementations. Implementations are not required to 412 support this mode. 414 4.4.4.2 ESP_DES 416 The ESP_DES type specifies a generic DES transform using DES-CBC. 417 The actual protection suite is determined in concert with an 418 associated SA attribute list. A generic transform is currently 419 undefined. 421 All implementations within the IPSEC DOI MUST support ESP_DES along 422 with the HMAC and REPLAY attributes. This suite is defined as the 423 [Hughes] transform. 425 4.4.4.3 ESP_3DES 427 The ESP_3DES type specifies a generic triple-DES transform. The 428 actual protection suite is determined in concert with an associated 429 SA attribute list. The generic transform is currently undefined. 431 All implementations within the IPSEC are strongly encouraged to 432 support ESP_3DES along with the HMAC and REPLAY attributes. This 433 suite is defined as the [Naganand] transform. 435 4.4.4.4 ESP_RC5 437 The ESP_RC5 type specifies the RC5 transform defined in [RC5]. 439 4.5 IPSEC Security Association Attributes 441 The following SA attribute definitions are used in phase II of an 442 ISAKMP/Oakley negotiation. Attribute types can be either Basic (B) 443 or Variable-Length (V). Encoding of these attributes is defined in 444 the base ISAKMP specification. 446 Attribute Classes 448 class value type 449 ------------------------------------------------- 450 Auth Key Life Type 1 B 451 Auth Key Life Duration 2 B/V 452 Enc Key Life Type 3 B 453 Enc Key Life Duration 4 B/V 454 SA Life Type 5 B 455 SA Life Duration 6 B/V 456 Replay Protection 7 B 457 Group Description 8 B 458 CA Distinguished Name 9 B 459 Encapsulation Mode 10 B 460 HMAC Algorithm 11 B 462 Class Values 464 Auth Key Life Type 465 Auth Key Duration 467 Specifies the time-to-live for the authentication key(s) 468 used in the corresponding AH HMAC transform. 470 Enc Key Life Type 471 Enc Key Duration 473 Specifies the time-to-live for the encryption key(s) 474 using in the corresponding ESP transform. 476 SA Life Type 477 SA Duration 478 Specifies the time-to-live for the overall security 479 association. When the SA expires, all keys negotiated 480 under the association (AH or ESP) must be renegotiated 481 regardless of the time-to-live remaining for the keys. 483 RESERVED 0 484 seconds 1 485 kilobytes 2 487 Values 3-61439 are reserved to IANA. Values 61440-65535 488 are for experimental use. For a given "Life Type," the 489 value of the "Life Duration" attribute defines the actual 490 length of the component lifetime -- either a number of 491 seconds, or a number of Kbytes that can be protected. 493 If unspecified, the default value shall be assumed to be 494 28800 seconds (8 hours) for Auth, Enc, and SA lifetime. 496 Replay Protection 497 RESERVED 0 498 required 1 499 disallowed 2 501 Values 3-61439 are reserved to IANA. Values 61440-65535 502 are for private use among mutually consenting parties. 504 There is no default value for Replay Protection, as it 505 must be specified to correctly identify the applicable 506 transform. 508 Group Description 509 RESERVED 0 510 default group 1 512 Values 2-61439 are reserved to IANA. Values 61440-65535 513 are for private use among mutually consenting parties. 515 If unspecified, the default value shall be assumed to be 516 the default Oakley group ([IO], Section 5.5.1). 518 CA Distinguished Name 519 RESERVED 0 520 DNS Security 1 522 Values 2-61439 are reserved to IANA. Values 61440-65535 523 are for private use among mutually consenting parties. 525 If unspecified, the default value shall be assumed to be 526 DNS Security (Section 4.8). 528 Encapsulation Mode 529 RESERVED 0 530 Tunnel 1 531 Transport 2 533 Values 3-61439 are reserved to IANA. Values 61440-65535 534 are for private use among mutually consenting parties. 536 If unspecified, the default value shall be assumed to be 537 unspecified (host-dependent). 539 HMAC Algorithm 540 RESERVED 0 541 MD5 1 542 SHA-1 2 544 Values 3-61439 are reserved to IANA. Values 61440-65535 545 are for private use among mutually consenting parties. 547 There is no default value for HMAC Algorithm, as it 548 must be specified to correctly identify the applicable 549 transform. 551 4.5.1 Required Attribute Support 553 To ensure basic interoperability, all implementations MUST support 554 all of the following attributes: 556 Auth Key Life Type 557 Auth Key Duration 558 Enc Key Life Type 559 Enc Key Duration 560 SA Life Type 561 SA Duration 562 Replay Protection 563 HMAC Algorithm (MD5 required, SHA-1 optional) 565 4.5.2 Attribute List Parsing Requirement 567 To allow for flexible semantics, the IPSEC DOI requires that a 568 conforming ISAKMP implementation MUST correctly parse an attribute 569 list that contains multiple instances of the same attribute class, so 570 long as the different attribute entries do not conflict with one 571 another. 573 To see why this is important, the following example shows the binary 574 encoding of a four entry attribute list that specifies an Encryption 575 Key Lifetime of either 100MB or 24 hours. (See Section 3.3 of 576 [ISAKMP] for a complete description of the attribute encoding 577 format.) 579 Attribute #1: 580 0x80030001 (AF = 1, type = Enc Key Life Type, value = seconds) 582 Attribute #2: 583 0x00040004 (AF = 0, type = Enc Key Duration, length = 4 bytes) 584 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) 586 Attribute #3: 587 0x80030002 (AF = 1, type = Enc Key Life Type, value = KB) 589 Attribute #4: 590 0x00040004 (AF = 0, type = Enc Key Duration, length = 4 bytes) 591 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) 593 If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED 594 Notification Payload SHOULD be returned and the security association 595 setup MUST be aborted. 597 4.6 IPSEC Payload Content 599 The following sections describe those ISAKMP payloads whose data 600 representations are dependent on the applicable DOI. 602 4.6.1 Security Association Payload 604 The following diagram illustrates the content of the Security 605 Association Payload for the IPSEC DOI. See Section 4.2 for a 606 description of the Situation bitmap. 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 ! Next Payload ! RESERVED ! Payload Length ! 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 ! Domain of Interpretation (IPSEC) | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 ! Situation (bitmap) ! 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 ! Labeled Domain Identifier ! 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 ! Secrecy Length (in octets) ! RESERVED ! 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 ~ Secrecy Level ~ 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 ! Secrecy Cat. Length (in bits) ! RESERVED ! 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 ~ Secrecy Category Bitmap ~ 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 ! Integrity Length (in octets) ! RESERVED ! 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 ~ Integrity Level ~ 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 ! Integ. Cat. Length (in bits) ! RESERVED ! 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 ~ Integrity Category Bitmap ~ 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 Figure 1: Security Association Payload Format 637 The Security Association Payload is defined as follows: 639 o Next Payload (2 octets) - Identifier for the payload type of 640 the next payload in the message. If the current payload is 641 the last in the message, this field will be zero (0). 643 o RESERVED (1 octet) - Unused, must be zero (0). 645 o Payload Length (2 octets) - Length, in octets, of the current 646 payload, including the generic header. 648 o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, 649 which has been assigned the value one (1). 651 o Situation (4 octets) - Bitmask used to interpret the 652 remainder of the Security Association Payload. See Section 653 4.2 for a complete list of values. 655 o Labeled Domain Identifier (4 octets) - IANA Assigned Number 656 used to interpret the Secrecy and Integrity information. 658 o Secrecy Length (2 octets) - Specifies the length, in octets, 659 of the secrecy level identifier. 661 o Secrecy Category Length (2 octets) - Specifies the length, in 662 bits, of the secrecy category (compartment) bitmap. 664 o Secrecy Category Bitmap (variable length) - A bitmap used to 665 designate secrecy categories (compartments) that are 666 required. 668 o Integrity Length (2 octets) - Specifies the length, in 669 octets, of the integrity level identifier. 671 o Integrity Category Length (2 octets) - Specifies the length, 672 in bits, of the integrity category (compartment) bitmap. 674 o Integrity Category Bitmap (variable length) - A bitmap used 675 to designate integrity categories (compartments) that are 676 required. 678 4.6.1.1 Labeled Domain Identifier Values 680 The following table lists the assigned values for the Labeled Domain 681 Identifier field contained in the Situation field of the Security 682 Association Payload. 684 Domain Value 685 ------- ----- 686 RESERVED 0 688 The values 1-0x7fffffff are reserved to IANA. Values 0x8000000- 689 0xffffffff are reserved for private use. 691 4.6.2 Identification Payload Content 693 The Identification Payload is used to identify the initiator of the 694 Security Association. The identity of the initiator SHOULD be used 695 by the responder to determine the correct host system security policy 696 requirement for the association. For example, a host might choose to 697 require data origin authentication without confidentiality (AH) from 698 a certain set of IP addresses and full authentication with 699 confidentiality (Hughes) from another range of IP addresses. The 700 Identification Payload provides information that can be used by the 701 responder to make this decision. 703 The following diagram illustrates the content of the Identification 704 Payload. 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 ! Next Payload ! RESERVED ! Payload Length ! 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 ! ID Type ! Protocol ID ! Port ! 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 ~ Identification Data ~ 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Figure 2: Identification Payload Format 717 The Identification Payload field is defined as follows: 719 o Next Payload (2 octets) - Identifier for the payload type of 720 the next payload in the message. If the current payload is 721 the last in the message, this field will be zero (0). 723 o RESERVED (1 octet) - Unused, must be zero (0). 725 o Payload Length (2 octets) - Length, in octets, of the 726 identification data, including the generic header. 728 o Identification Type (1 octet) - Value describing the 729 identity information found in the Identification Data field. 731 o Protocol ID (1 octet) - Value specifying an associated 732 IP protocol ID (e.g. UDP/TCP). A value of zero means that the 733 Protocol ID field should be ignored. 735 o Port (2 octets) - Value specifying an associated port. 736 A value of zero means that the Port field should be ignored. 738 o RESERVED (1 octet) - Unused, must be zero (0). 740 4.6.2.1 Identification Type Values 742 The following table lists the assigned values for the Identification 743 Type field found in the Identification Payload. 745 ID Type Value 746 ------- ----- 747 RESERVED 0 748 ID_IPV4_ADDR 1 749 ID_FQDN 2 750 ID_USER_FQDN 3 751 ID_IPV4_ADDR_SUBNET 4 752 ID_IPV6_ADDR 5 753 ID_IPV6_ADDR_SUBNET 6 754 ID_IPV4_ADDR_RANGE 7 755 ID_IPV6_ADDR_RANGE 8 757 The size of this field is one octet. The values 9-248 are reserved 758 to IANA. Values 249-255 are reserved for private use. 760 4.6.2.2 ID_IPV4_ADDR 762 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 764 4.6.2.3 ID_FQDN 766 The ID_FQDN type specifies a fully-qualified domain name string. An 767 example of a ID_FQDN is, "foo.bar.com". 769 4.6.2.4 ID_USER_FQDN 771 The ID_USER_FQDN type specifies a fully-qualified username string, An 772 example of a ID_USER_FQDN is, "piper@foo.bar.com". 774 4.6.2.5 ID_IPV4_ADDR_SUBNET 776 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, 777 represented by two four (4) octet values. The first value is an IPv4 778 address. The second is an IPv4 network mask. Note that ones (1s) in 779 the network mask indicate that the corresponding bit in the address 780 is fixed, while zeros (0s) indicate a "wildcard" bit. 782 4.6.2.6 ID_IPV6_ADDR 784 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 785 address. 787 4.6.2.7 ID_IPV6_ADDR_SUBNET 789 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, 790 represented by two sixteen (16) octet values. The first value is an 791 IPv6 address. The second is an IPv6 network mask. Note that ones 792 (1s) in the network mask indicate that the corresponding bit in the 793 address is fixed, while zeros (0s) indicate a "wildcard" bit. 795 4.6.2.8 ID_IPV4_ADDR_RANGE 797 The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, 798 represented by two four (4) octet values. The first value is the 799 beginning IPv4 address (inclusive) and the second value is the ending 800 IPv4 address (inclusive). All addresses falling between the two 801 specified addresses are considered to be within the list. 803 4.6.2.9 ID_IPV6_ADDR_RANGE 805 The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, 806 represented by two sixteen (16) octet values. The first value is the 807 beginning IPv6 address (inclusive) and the second value is the ending 808 IPv6 address (inclusive). All addresses falling between the two 809 specified addresses are considered to be within the list. 811 4.7 IPSEC Security Parameter Index (SPI) Encoding 813 ISAKMP defines the SPI field as eight octets in length, however the 814 IPSEC transforms use only four octets. 816 All implementation MUST use the following mapping for the ISAKMP SPI 817 field in the IPSEC DOI. 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 ! SPI ! 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 ! RESERVED ! 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Figure 3: ISAKMP SPI Encoding 828 The ISAKMP SPI field is defined as follows: 830 o SPI - Security Parameter Index (4 octets) - contains the 831 SPI value which identifies the security association. 833 o RESERVED (4 octets) - Unused, must be zero (0). 835 4.8 IPSEC Certificate Authorities 837 The ISAKMP Certificate Request Payload allows either side of an 838 ISAKMP negotiation to request its peer to provide a certificate chain 839 needed to authenticate itself. The Certificate Request Payload 840 includes a list of acceptable Certificate Types and Certificate 841 Authorities. Appropriate certificate chains are then returned in a 842 Certificate Payload response. 844 The IPSEC DOI defines the following Certificate Authorities for the 845 processing of Certificate Request Payloads. See Section 4.5 for 846 details on the specific data attribute type values for these CAs. 848 Certificate Authority 849 --------------------- 850 DNS Security 852 4.8.1 DNS Security 854 This CA type represents the combination of KEY and SIG records, as 855 defined in RFC-2065, that can be used for authentication. The 856 particular encoding required to formulate the Certificate Payload 857 (response) is TBD. 859 4.9 IPSEC Key Exchange Requirements 861 The IPSEC DOI introduces no additional Key Exchange types. 863 5. Security Considerations 864 This entire draft pertains to a hybrid protocol, combining Oakley 865 ([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive keying 866 material for security associations in a secure and authenticated 867 manner. Specific discussion of the various security protocols and 868 transforms identified in this document can be found in the associated 869 base documents. 871 Acknowledgements 873 This document is derived, in part, from previous works by Douglas 874 Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, 875 and Dave Carrel. 877 References 879 [RFC-1825] Atkinson, R., "Security Architecture for the Internet 880 Protocol," RFC-1825, August 1995. 882 [RFC-1826] Atkinson, R., "IP Authentication Header," RFC-1826, August 883 1995. 885 [RFC-1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)," 886 RFC-1827, August 1995. 888 [RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed 889 MD5," RFC-1828, August 1995. 891 [RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC 892 Transform," RFC-1829, August 1995. 894 [RFC-2065] Eastlake 3rd, D., Kaufman, C., "Domain Name System 895 Security Extensions," RFC-2065, January 1997. 897 [RFC-2085] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with 898 Replay Prevention," RFC-2085, February 1997. 900 [HMACSHA] Chang, S., Glenn, R., "HMAC-SHA IP Authentication with 901 Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-03.txt. 903 [Hughes] Hughes, J., Editor, "Combined DES-CBC, HMAC and Replay 904 Prevention Transform," draft-ietf-ipsec-esp-des-md5-03.txt. 906 [IO] Carrel, D., Harkins, D., "The Resolution of ISAKMP with Oakley," 907 draft-ietf-ipsec-isakmp-oakley-03.txt. 909 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 910 "Internet Security Association and Key Management Protocol (ISAKMP)," 911 draft-ietf-ipsec-isakmp-07.{ps,txt}. 913 [Naganand] Daraswamy, N., "Combined 3DES-CBC, HMAC and Replay 914 Detection Security Transform," draft-ietf-ipsec-esp-3des-md5-00.txt. 916 [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," 917 draft-ietf-ipsec-oakley-01.txt. 919 [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key 920 Management API, Version 2", draft-mcdonald-pf-key-v2-00.txt, work in 921 progress. 923 [RC5] Howard, B., Baldwin, R., "The ESP RC5-CBC Transform," draft- 924 baldwin-esp-rc5-00.txt. 926 Author's Address: 928 Derrell Piper 929 cisco Systems 930 101 Cooper St. 931 Santa Cruz, California, 95060 932 United States of America 933 +1 408 457-5384