1 2 3 4 5 6 7Network Working Group D. Piper 8Request for Comments: 2407 Network Alchemy 9Category: Standards Track November 1998 10 11 12 The Internet IP Security Domain of Interpretation for ISAKMP 13 14Status of this Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22Copyright Notice 23 24 Copyright (C) The Internet Society (1998). All Rights Reserved. 25 26IESG Note 27 28 Section 4.4.4.2 states, "All implememtations within the IPSEC DOI 29 MUST support ESP_DES...". Recent work in the area of cryptanalysis 30 suggests that DES may not be sufficiently strong for many 31 applications. Therefore, it is very likely that the IETF will 32 deprecate the use of ESP_DES as a mandatory cipher suite in the near 33 future. It will remain as an optional use protocol. Although the 34 IPsec working group and the IETF in general have not settled on an 35 alternative algorithm (taking into account concerns of security and 36 performance), implementers may want to heed the recommendations of 37 section 4.4.4.3 on the use of ESP_3DES. 38 391. Abstract 40 41 The Internet Security Association and Key Management Protocol 42 (ISAKMP) defines a framework for security association management and 43 cryptographic key establishment for the Internet. This framework 44 consists of defined exchanges, payloads, and processing guidelines 45 that occur within a given Domain of Interpretation (DOI). This 46 document defines the Internet IP Security DOI (IPSEC DOI), which 47 instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate 48 security associations. 49 50 For a list of changes since the previous version of the IPSEC DOI, 51 please see Section 7. 52 53 54 55 56 57 58Piper Standards Track [Page 1] 59 60RFC 2407 IP Security Domain of Interpretation November 1998 61 62 632. Introduction 64 65 Within ISAKMP, a Domain of Interpretation is used to group related 66 protocols using ISAKMP to negotiate security associations. Security 67 protocols sharing a DOI choose security protocol and cryptographic 68 transforms from a common namespace and share key exchange protocol 69 identifiers. They also share a common interpretation of DOI-specific 70 payload data content, including the Security Association and 71 Identification payloads. 72 73 Overall, ISAKMP places the following requirements on a DOI 74 definition: 75 76 o define the naming scheme for DOI-specific protocol identifiers 77 o define the interpretation for the Situation field 78 o define the set of applicable security policies 79 o define the syntax for DOI-specific SA Attributes (Phase II) 80 o define the syntax for DOI-specific payload contents 81 o define additional Key Exchange types, if needed 82 o define additional Notification Message types, if needed 83 84 The remainder of this document details the instantiation of these 85 requirements for using the IP Security (IPSEC) protocols to provide 86 authentication, integrity, and/or confidentiality for IP packets sent 87 between cooperating host systems and/or firewalls. 88 89 For a description of the overall IPSEC architecture, see [ARCH], 90 [AH], and [ESP]. 91 923. Terms and Definitions 93 94 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 95 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 96 document, are to be interpreted as described in [RFC 2119]. 97 984.1 IPSEC Naming Scheme 99 100 Within ISAKMP, all DOI's must be registered with the IANA in the 101 "Assigned Numbers" RFC [STD-2]. The IANA Assigned Number for the 102 Internet IP Security DOI (IPSEC DOI) is one (1). Within the IPSEC 103 DOI, all well-known identifiers MUST be registered with the IANA 104 under the IPSEC DOI. Unless otherwise noted, all tables within this 105 document refer to IANA Assigned Numbers for the IPSEC DOI. See 106 Section 6 for further information relating to the IANA registry for 107 the IPSEC DOI. 108 109 All multi-octet binary values are stored in network byte order. 110 111 112 113 114Piper Standards Track [Page 2] 115 116RFC 2407 IP Security Domain of Interpretation November 1998 117 118 1194.2 IPSEC Situation Definition 120 121 Within ISAKMP, the Situation provides information that can be used by 122 the responder to make a policy determination about how to process the 123 incoming Security Association request. For the IPSEC DOI, the 124 Situation field is a four (4) octet bitmask with the following 125 values. 126 127 Situation Value 128 --------- ----- 129 SIT_IDENTITY_ONLY 0x01 130 SIT_SECRECY 0x02 131 SIT_INTEGRITY 0x04 132 1334.2.1 SIT_IDENTITY_ONLY 134 135 The SIT_IDENTITY_ONLY type specifies that the security association 136 will be identified by source identity information present in an 137 associated Identification Payload. See Section 4.6.2 for a complete 138 description of the various Identification types. All IPSEC DOI 139 implementations MUST support SIT_IDENTITY_ONLY by including an 140 Identification Payload in at least one of the Phase I Oakley 141 exchanges ([IKE], Section 5) and MUST abort any association setup 142 that does not include an Identification Payload. 143 144 If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the 145 situation consists only of the 4 octet situation bitmap and does not 146 include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) 147 or any subsequent label information. Conversely, if the initiator 148 supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain 149 Identifier MUST be included in the situation payload. 150 1514.2.2 SIT_SECRECY 152 153 The SIT_SECRECY type specifies that the security association is being 154 negotiated in an environment that requires labeled secrecy. If 155 SIT_SECRECY is present in the Situation bitmap, the Situation field 156 will be followed by variable-length data that includes a sensitivity 157 level and compartment bitmask. See Section 4.6.1 for a complete 158 description of the Security Association Payload format. 159 160 If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be 161 set in the Situation bitmap and no secrecy level or category bitmaps 162 shall be included. 163 164 If a responder does not support SIT_SECRECY, a SITUATION-NOT- 165 SUPPORTED Notification Payload SHOULD be returned and the security 166 association setup MUST be aborted. 167 168 169 170Piper Standards Track [Page 3] 171 172RFC 2407 IP Security Domain of Interpretation November 1998 173 174 1754.2.3 SIT_INTEGRITY 176 177 The SIT_INTEGRITY type specifies that the security association is 178 being negotiated in an environment that requires labeled integrity. 179 If SIT_INTEGRITY is present in the Situation bitmap, the Situation 180 field will be followed by variable-length data that includes an 181 integrity level and compartment bitmask. If SIT_SECRECY is also in 182 use for the association, the integrity information immediately 183 follows the variable-length secrecy level and categories. See 184 section 4.6.1 for a complete description of the Security Association 185 Payload format. 186 187 If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST 188 NOT be set in the Situation bitmap and no integrity level or category 189 bitmaps shall be included. 190 191 If a responder does not support SIT_INTEGRITY, a SITUATION-NOT- 192 SUPPORTED Notification Payload SHOULD be returned and the security 193 association setup MUST be aborted. 194 1954.3 IPSEC Security Policy Requirements 196 197 The IPSEC DOI does not impose specific security policy requirements 198 on any implementation. Host system policy issues are outside of the 199 scope of this document. 200 201 However, the following sections touch on some of the issues that must 202 be considered when designing an IPSEC DOI host implementation. This 203 section should be considered only informational in nature. 204 2054.3.1 Key Management Issues 206 207 It is expected that many systems choosing to implement ISAKMP will 208 strive to provide a protected domain of execution for a combined IKE 209 key management daemon. On protected-mode multiuser operating 210 systems, this key management daemon will likely exist as a separate 211 privileged process. 212 213 In such an environment, a formalized API to introduce keying material 214 into the TCP/IP kernel may be desirable. The IP Security 215 architecture does not place any requirements for structure or flow 216 between a host TCP/IP kernel and its key management provider. 217 218 219 220 221 222 223 224 225 226Piper Standards Track [Page 4] 227 228RFC 2407 IP Security Domain of Interpretation November 1998 229 230 2314.3.2 Static Keying Issues 232 233 Host systems that implement static keys, either for use directly by 234 IPSEC, or for authentication purposes (see [IKE] Section 5.4), should 235 take steps to protect the static keying material when it is not 236 residing in a protected memory domain or actively in use by the 237 TCP/IP kernel. 238 239 For example, on a laptop, one might choose to store the static keys 240 in a configuration store that is, itself, encrypted under a private 241 password. 242 243 Depending on the operating system and utility software installed, it 244 may not be possible to protect the static keys once they've been 245 loaded into the TCP/IP kernel, however they should not be trivially 246 recoverable on initial system startup without having to satisfy some 247 additional form of authentication. 248 2494.3.3 Host Policy Issues 250 251 It is not realistic to assume that the transition to IPSEC will occur 252 overnight. Host systems must be prepared to implement flexible 253 policy lists that describe which systems they desire to speak 254 securely with and which systems they require speak securely to them. 255 Some notion of proxy firewall addresses may also be required. 256 257 A minimal approach is probably a static list of IP addresses, network 258 masks, and a security required flag or flags. 259 260 A more flexible implementation might consist of a list of wildcard 261 DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional 262 firewall address. The wildcard DNS name would be used to match 263 incoming or outgoing IP addresses, the in/out bitmask would be used 264 to determine whether or not security was to be applied and in which 265 direction, and the optional firewall address would be used to 266 indicate whether or not tunnel mode would be needed to talk to the 267 target system though an intermediate firewall. 268 2694.3.4 Certificate Management 270 271 Host systems implementing a certificate-based authentication scheme 272 will need a mechanism for obtaining and managing a database of 273 certificates. 274 275 Secure DNS is to be one certificate distribution mechanism, however 276 the pervasive availability of secure DNS zones, in the short term, is 277 doubtful for many reasons. What's far more likely is that hosts will 278 279 280 281 282Piper Standards Track [Page 5] 283 284RFC 2407 IP Security Domain of Interpretation November 1998 285 286 287 need an ability to import certificates that they acquire through 288 secure, out-of-band mechanisms, as well as an ability to export their 289 own certificates for use by other systems. 290 291 However, manual certificate management should not be done so as to 292 preclude the ability to introduce dynamic certificate discovery 293 mechanisms and/or protocols as they become available. 294 2954.4 IPSEC Assigned Numbers 296 297 The following sections list the Assigned Numbers for the IPSEC DOI: 298 Situation Identifiers, Protocol Identifiers, Transform Identifiers, 299 AH, ESP, and IPCOMP Transform Identifiers, Security Association 300 Attribute Type Values, Labeled Domain Identifiers, ID Payload Type 301 Values, and Notify Message Type Values. 302 3034.4.1 IPSEC Security Protocol Identifier 304 305 The ISAKMP proposal syntax was specifically designed to allow for the 306 simultaneous negotiation of multiple Phase II security protocol 307 suites within a single negotiation. As a result, the protocol suites 308 listed below form the set of protocols that can be negotiated at the 309 same time. It is a host policy decision as to what protocol suites 310 might be negotiated together. 311 312 The following table lists the values for the Security Protocol 313 Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC 314 DOI. 315 316 Protocol ID Value 317 ----------- ----- 318 RESERVED 0 319 PROTO_ISAKMP 1 320 PROTO_IPSEC_AH 2 321 PROTO_IPSEC_ESP 3 322 PROTO_IPCOMP 4 323 3244.4.1.1 PROTO_ISAKMP 325 326 The PROTO_ISAKMP type specifies message protection required during 327 Phase I of the ISAKMP protocol. The specific protection mechanism 328 used for the IPSEC DOI is described in [IKE]. All implementations 329 within the IPSEC DOI MUST support PROTO_ISAKMP. 330 331 NB: ISAKMP reserves the value one (1) across all DOI definitions. 332 333 334 335 336 337 338Piper Standards Track [Page 6] 339 340RFC 2407 IP Security Domain of Interpretation November 1998 341 342 3434.4.1.2 PROTO_IPSEC_AH 344 345 The PROTO_IPSEC_AH type specifies IP packet authentication. The 346 default AH transform provides data origin authentication, integrity 347 protection, and replay detection. For export control considerations, 348 confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform. 349 3504.4.1.3 PROTO_IPSEC_ESP 351 352 The PROTO_IPSEC_ESP type specifies IP packet confidentiality. 353 Authentication, if required, must be provided as part of the ESP 354 transform. The default ESP transform includes data origin 355 authentication, integrity protection, replay detection, and 356 confidentiality. 357 3584.4.1.4 PROTO_IPCOMP 359 360 The PROTO_IPCOMP type specifies IP payload compression as defined in 361 [IPCOMP]. 362 3634.4.2 IPSEC ISAKMP Transform Identifiers 364 365 As part of an ISAKMP Phase I negotiation, the initiator's choice of 366 Key Exchange offerings is made using some host system policy 367 description. The actual selection of Key Exchange mechanism is made 368 using the standard ISAKMP Proposal Payload. The following table 369 lists the defined ISAKMP Phase I Transform Identifiers for the 370 Proposal Payload for the IPSEC DOI. 371 372 Transform Value 373 --------- ----- 374 RESERVED 0 375 KEY_IKE 1 376 377 Within the ISAKMP and IPSEC DOI framework it is possible to define 378 key establishment protocols other than IKE (Oakley). Previous 379 versions of this document defined types both for manual keying and 380 for schemes based on use of a generic Key Distribution Center (KDC). 381 These identifiers have been removed from the current document. 382 383 The IPSEC DOI can still be extended later to include values for 384 additional non-Oakley key establishment protocols for ISAKMP and 385 IPSEC, such as Kerberos [RFC-1510] or the Group Key Management 386 Protocol (GKMP) [RFC-2093]. 387 388 389 390 391 392 393 394Piper Standards Track [Page 7] 395 396RFC 2407 IP Security Domain of Interpretation November 1998 397 398 3994.4.2.1 KEY_IKE 400 401 The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman 402 key exchange (IKE) as defined in the [IKE] document. All 403 implementations within the IPSEC DOI MUST support KEY_IKE. 404 4054.4.3 IPSEC AH Transform Identifiers 406 407 The Authentication Header Protocol (AH) defines one mandatory and 408 several optional transforms used to provide authentication, 409 integrity, and replay detection. The following table lists the 410 defined AH Transform Identifiers for the ISAKMP Proposal Payload for 411 the IPSEC DOI. 412 413 Note: the Authentication Algorithm attribute MUST be specified to 414 identify the appropriate AH protection suite. For example, AH_MD5 415 can best be thought of as a generic AH transform using MD5. To 416 request the HMAC construction with AH, one specifies the AH_MD5 417 transform ID along with the Authentication Algorithm attribute set to 418 HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the 419 following sections. 420 421 Transform ID Value 422 ------------ ----- 423 RESERVED 0-1 424 AH_MD5 2 425 AH_SHA 3 426 AH_DES 4 427 428 Note: all mandatory-to-implement algorithms are listed as "MUST" 429 implement (e.g. AH_MD5) in the following sections. All other 430 algorithms are optional and MAY be implemented in any particular 431 implementation. 432 4334.4.3.1 AH_MD5 434 435 The AH_MD5 type specifies a generic AH transform using MD5. The 436 actual protection suite is determined in concert with an associated 437 SA attribute list. A generic MD5 transform is currently undefined. 438 439 All implementations within the IPSEC DOI MUST support AH_MD5 along 440 with the Auth(HMAC-MD5) attribute. This suite is defined as the 441 HMAC-MD5-96 transform described in [HMACMD5]. 442 443 The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH 444 transform (Key/Pad/Data/Key) described in RFC-1826. 445 446 447 448 449 450Piper Standards Track [Page 8] 451 452RFC 2407 IP Security Domain of Interpretation November 1998 453 454 455 Use of AH_MD5 with any other Authentication Algorithm attribute value 456 is currently undefined. 457 4584.4.3.2 AH_SHA 459 460 The AH_SHA type specifies a generic AH transform using SHA-1. The 461 actual protection suite is determined in concert with an associated 462 SA attribute list. A generic SHA transform is currently undefined. 463 464 All implementations within the IPSEC DOI MUST support AH_SHA along 465 with the Auth(HMAC-SHA) attribute. This suite is defined as the 466 HMAC-SHA-1-96 transform described in [HMACSHA]. 467 468 Use of AH_SHA with any other Authentication Algorithm attribute value 469 is currently undefined. 470 4714.4.3.3 AH_DES 472 473 The AH_DES type specifies a generic AH transform using DES. The 474 actual protection suite is determined in concert with an associated 475 SA attribute list. A generic DES transform is currently undefined. 476 477 The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute 478 to be a DES-MAC transform. Implementations are not required to 479 support this mode. 480 481 Use of AH_DES with any other Authentication Algorithm attribute value 482 is currently undefined. 483 4844.4.4 IPSEC ESP Transform Identifiers 485 486 The Encapsulating Security Payload (ESP) defines one mandatory and 487 many optional transforms used to provide data confidentiality. The 488 following table lists the defined ESP Transform Identifiers for the 489 ISAKMP Proposal Payload for the IPSEC DOI. 490 491 Note: when authentication, integrity protection, and replay detection 492 are required, the Authentication Algorithm attribute MUST be 493 specified to identify the appropriate ESP protection suite. For 494 example, to request HMAC-MD5 authentication with 3DES, one specifies 495 the ESP_3DES transform ID with the Authentication Algorithm attribute 496 set to HMAC-MD5. For additional processing requirements, see Section 497 4.5 (Authentication Algorithm). 498 499 500 501 502 503 504 505 506Piper Standards Track [Page 9] 507 508RFC 2407 IP Security Domain of Interpretation November 1998 509 510 511 Transform ID Value 512 ------------ ----- 513 RESERVED 0 514 ESP_DES_IV64 1 515 ESP_DES 2 516 ESP_3DES 3 517 ESP_RC5 4 518 ESP_IDEA 5 519 ESP_CAST 6 520 ESP_BLOWFISH 7 521 ESP_3IDEA 8 522 ESP_DES_IV32 9 523 ESP_RC4 10 524 ESP_NULL 11 525 526 Note: all mandatory-to-implement algorithms are listed as "MUST" 527 implement (e.g. ESP_DES) in the following sections. All other 528 algorithms are optional and MAY be implemented in any particular 529 implementation. 530 5314.4.4.1 ESP_DES_IV64 532 533 The ESP_DES_IV64 type specifies the DES-CBC transform defined in 534 RFC-1827 and RFC-1829 using a 64-bit IV. 535 5364.4.4.2 ESP_DES 537 538 The ESP_DES type specifies a generic DES transform using DES-CBC. 539 The actual protection suite is determined in concert with an 540 associated SA attribute list. A generic transform is currently 541 undefined. 542 543 All implementations within the IPSEC DOI MUST support ESP_DES along 544 with the Auth(HMAC-MD5) attribute. This suite is defined as the 545 [DES] transform, with authentication and integrity provided by HMAC 546 MD5 [HMACMD5]. 547 5484.4.4.3 ESP_3DES 549 550 The ESP_3DES type specifies a generic triple-DES transform. The 551 actual protection suite is determined in concert with an associated 552 SA attribute list. The generic transform is currently undefined. 553 554 All implementations within the IPSEC DOI are strongly encouraged to 555 support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite 556 is defined as the [ESPCBC] transform, with authentication and 557 integrity provided by HMAC MD5 [HMACMD5]. 558 559 560 561 562Piper Standards Track [Page 10] 563 564RFC 2407 IP Security Domain of Interpretation November 1998 565 566 5674.4.4.4 ESP_RC5 568 569 The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC]. 570 5714.4.4.5 ESP_IDEA 572 573 The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC]. 574 5754.4.4.6 ESP_CAST 576 577 The ESP_CAST type specifies the CAST transform defined in [ESPCBC]. 578 5794.4.4.7 ESP_BLOWFISH 580 581 The ESP_BLOWFISH type specifies the BLOWFISH transform defined in 582 [ESPCBC]. 583 5844.4.4.8 ESP_3IDEA 585 586 The ESP_3IDEA type is reserved for triple-IDEA. 587 5884.4.4.9 ESP_DES_IV32 589 590 The ESP_DES_IV32 type specifies the DES-CBC transform defined in 591 RFC-1827 and RFC-1829 using a 32-bit IV. 592 5934.4.4.10 ESP_RC4 594 595 The ESP_RC4 type is reserved for RC4. 596 5974.4.4.11 ESP_NULL 598 599 The ESP_NULL type specifies no confidentiality is to be provided by 600 ESP. ESP_NULL is used when ESP is being used to tunnel packets which 601 require only authentication, integrity protection, and replay 602 detection. 603 604 All implementations within the IPSEC DOI MUST support ESP_NULL. The 605 ESP NULL transform is defined in [ESPNULL]. See the Authentication 606 Algorithm attribute description in Section 4.5 for additional 607 requirements relating to the use of ESP_NULL. 608 6094.4.5 IPSEC IPCOMP Transform Identifiers 610 611 The IP Compression (IPCOMP) transforms define optional compression 612 algorithms that can be negotiated to provide for IP payload 613 compression ([IPCOMP]). The following table lists the defined IPCOMP 614 Transform Identifiers for the ISAKMP Proposal Payload within the 615 616 617 618Piper Standards Track [Page 11] 619 620RFC 2407 IP Security Domain of Interpretation November 1998 621 622 623 IPSEC DOI. 624 625 Transform ID Value 626 ------------ ----- 627 RESERVED 0 628 IPCOMP_OUI 1 629 IPCOMP_DEFLATE 2 630 IPCOMP_LZS 3 631 6324.4.5.1 IPCOMP_OUI 633 634 The IPCOMP_OUI type specifies a proprietary compression transform. 635 The IPCOMP_OUI type must be accompanied by an attribute which further 636 identifies the specific vendor algorithm. 637 6384.4.5.2 IPCOMP_DEFLATE 639 640 The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate 641 algorithm as specified in [DEFLATE]. 642 6434.4.5.3 IPCOMP_LZS 644 645 The IPCOMP_LZS type specifies the use of the Stac Electronics LZS 646 algorithm as specified in [LZS]. 647 6484.5 IPSEC Security Association Attributes 649 650 The following SA attribute definitions are used in Phase II of an IKE 651 negotiation. Attribute types can be either Basic (B) or Variable- 652 Length (V). Encoding of these attributes is defined in the base 653 ISAKMP specification. 654 655 Attributes described as basic MUST NOT be encoded as variable. 656 Variable length attributes MAY be encoded as basic attributes if 657 their value can fit into two octets. See [IKE] for further 658 information on attribute encoding in the IPSEC DOI. All restrictions 659 listed in [IKE] also apply to the IPSEC DOI. 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674Piper Standards Track [Page 12] 675 676RFC 2407 IP Security Domain of Interpretation November 1998 677 678 679 Attribute Types 680 681 class value type 682 ------------------------------------------------- 683 SA Life Type 1 B 684 SA Life Duration 2 V 685 Group Description 3 B 686 Encapsulation Mode 4 B 687 Authentication Algorithm 5 B 688 Key Length 6 B 689 Key Rounds 7 B 690 Compress Dictionary Size 8 B 691 Compress Private Algorithm 9 V 692 693 Class Values 694 695 SA Life Type 696 SA Duration 697 698 Specifies the time-to-live for the overall security 699 association. When the SA expires, all keys negotiated under 700 the association (AH or ESP) must be renegotiated. The life 701 type values are: 702 703 RESERVED 0 704 seconds 1 705 kilobytes 2 706 707 Values 3-61439 are reserved to IANA. Values 61440-65535 are 708 for private use. For a given Life Type, the value of the 709 Life Duration attribute defines the actual length of the 710 component lifetime -- either a number of seconds, or a number 711 of Kbytes that can be protected. 712 713 If unspecified, the default value shall be assumed to be 714 28800 seconds (8 hours). 715 716 An SA Life Duration attribute MUST always follow an SA Life 717 Type which describes the units of duration. 718 719 See Section 4.5.4 for additional information relating to 720 lifetime notification. 721 722 Group Description 723 724 Specifies the Oakley Group to be used in a PFS QM 725 negotiation. For a list of supported values, see Appendix A 726 of [IKE]. 727 728 729 730Piper Standards Track [Page 13] 731 732RFC 2407 IP Security Domain of Interpretation November 1998 733 734 735 Encapsulation Mode 736 RESERVED 0 737 Tunnel 1 738 Transport 2 739 740 Values 3-61439 are reserved to IANA. Values 61440-65535 are 741 for private use. 742 743 If unspecified, the default value shall be assumed to be 744 unspecified (host-dependent). 745 746 Authentication Algorithm 747 RESERVED 0 748 HMAC-MD5 1 749 HMAC-SHA 2 750 DES-MAC 3 751 KPDK 4 752 753 Values 5-61439 are reserved to IANA. Values 61440-65535 are 754 for private use. 755 756 There is no default value for Auth Algorithm, as it must be 757 specified to correctly identify the applicable AH or ESP 758 transform, except in the following case. 759 760 When negotiating ESP without authentication, the Auth 761 Algorithm attribute MUST NOT be included in the proposal. 762 763 When negotiating ESP without confidentiality, the Auth 764 Algorithm attribute MUST be included in the proposal and the 765 ESP transform ID must be ESP_NULL. 766 767 Key Length 768 RESERVED 0 769 770 There is no default value for Key Length, as it must be 771 specified for transforms using ciphers with variable key 772 lengths. For fixed length ciphers, the Key Length attribute 773 MUST NOT be sent. 774 775 Key Rounds 776 RESERVED 0 777 778 There is no default value for Key Rounds, as it must be 779 specified for transforms using ciphers with varying numbers 780 of rounds. 781 782 783 784 785 786Piper Standards Track [Page 14] 787 788RFC 2407 IP Security Domain of Interpretation November 1998 789 790 791 Compression Dictionary Size 792 RESERVED 0 793 794 Specifies the log2 maximum size of the dictionary. 795 796 There is no default value for dictionary size. 797 798 Compression Private Algorithm 799 800 Specifies a private vendor compression algorithm. The first 801 three (3) octets must be an IEEE assigned company_id (OUI). 802 The next octet may be a vendor specific compression subtype, 803 followed by zero or more octets of vendor data. 804 8054.5.1 Required Attribute Support 806 807 To ensure basic interoperability, all implementations MUST be 808 prepared to negotiate all of the following attributes. 809 810 SA Life Type 811 SA Duration 812 Auth Algorithm 813 8144.5.2 Attribute Parsing Requirement (Lifetime) 815 816 To allow for flexible semantics, the IPSEC DOI requires that a 817 conforming ISAKMP implementation MUST correctly parse an attribute 818 list that contains multiple instances of the same attribute class, so 819 long as the different attribute entries do not conflict with one 820 another. Currently, the only attributes which requires this 821 treatment are Life Type and Duration. 822 823 To see why this is important, the following example shows the binary 824 encoding of a four entry attribute list that specifies an SA Lifetime 825 of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a 826 complete description of the attribute encoding format.) 827 828 Attribute #1: 829 0x80010001 (AF = 1, type = SA Life Type, value = seconds) 830 831 Attribute #2: 832 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 833 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) 834 835 Attribute #3: 836 0x80010002 (AF = 1, type = SA Life Type, value = KB) 837 838 839 840 841 842Piper Standards Track [Page 15] 843 844RFC 2407 IP Security Domain of Interpretation November 1998 845 846 847 Attribute #4: 848 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 849 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) 850 851 If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED 852 Notification Payload SHOULD be returned and the security association 853 setup MUST be aborted. 854 8554.5.3 Attribute Negotiation 856 857 If an implementation receives a defined IPSEC DOI attribute (or 858 attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT 859 SHOULD be sent and the security association setup MUST be aborted, 860 unless the attribute value is in the reserved range. 861 862 If an implementation receives an attribute value in the reserved 863 range, an implementation MAY chose to continue based on local policy. 864 8654.5.4 Lifetime Notification 866 867 When an initiator offers an SA lifetime greater than what the 868 responder desires based on their local policy, the responder has 869 three choices: 1) fail the negotiation entirely; 2) complete the 870 negotiation but use a shorter lifetime than what was offered; 3) 871 complete the negotiation and send an advisory notification to the 872 initiator indicating the responder's true lifetime. The choice of 873 what the responder actually does is implementation specific and/or 874 based on local policy. 875 876 To ensure interoperability in the latter case, the IPSEC DOI requires 877 the following only when the responder wishes to notify the initiator: 878 if the initiator offers an SA lifetime longer than the responder is 879 willing to accept, the responder SHOULD include an ISAKMP 880 Notification Payload in the exchange that includes the responder's 881 IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the 882 RESPONDER-LIFETIME Notification Message type which MUST be used for 883 this purpose. 884 8854.6 IPSEC Payload Content 886 887 The following sections describe those ISAKMP payloads whose data 888 representations are dependent on the applicable DOI. 889 8904.6.1 Security Association Payload 891 892 The following diagram illustrates the content of the Security 893 Association Payload for the IPSEC DOI. See Section 4.2 for a 894 description of the Situation bitmap. 895 896 897 898Piper Standards Track [Page 16] 899 900RFC 2407 IP Security Domain of Interpretation November 1998 901 902 903 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 ! Next Payload ! RESERVED ! Payload Length ! 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 ! Domain of Interpretation (IPSEC) | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 ! Situation (bitmap) ! 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 ! Labeled Domain Identifier ! 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 ! Secrecy Length (in octets) ! RESERVED ! 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 ~ Secrecy Level ~ 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 ! Secrecy Cat. Length (in bits) ! RESERVED ! 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 ~ Secrecy Category Bitmap ~ 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 ! Integrity Length (in octets) ! RESERVED ! 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 ~ Integrity Level ~ 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 ! Integ. Cat. Length (in bits) ! RESERVED ! 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 ~ Integrity Category Bitmap ~ 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 930 Figure 1: Security Association Payload Format 931 932 The Security Association Payload is defined as follows: 933 934 o Next Payload (1 octet) - Identifier for the payload type of 935 the next payload in the message. If the current payload is the 936 last in the message, this field will be zero (0). 937 938 o RESERVED (1 octet) - Unused, must be zero (0). 939 940 o Payload Length (2 octets) - Length, in octets, of the current 941 payload, including the generic header. 942 943 o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, 944 which has been assigned the value one (1). 945 946 o Situation (4 octets) - Bitmask used to interpret the remainder 947 of the Security Association Payload. See Section 4.2 for a 948 complete list of values. 949 950 951 952 953 954Piper Standards Track [Page 17] 955 956RFC 2407 IP Security Domain of Interpretation November 1998 957 958 959 o Labeled Domain Identifier (4 octets) - IANA Assigned Number used 960 to interpret the Secrecy and Integrity information. 961 962 o Secrecy Length (2 octets) - Specifies the length, in octets, of 963 the secrecy level identifier, excluding pad bits. 964 965 o RESERVED (2 octets) - Unused, must be zero (0). 966 967 o Secrecy Level (variable length) - Specifies the mandatory 968 secrecy level required. The secrecy level MUST be padded with 969 zero (0) to align on the next 32-bit boundary. 970 971 o Secrecy Category Length (2 octets) - Specifies the length, in 972 bits, of the secrecy category (compartment) bitmap, excluding 973 pad bits. 974 975 o RESERVED (2 octets) - Unused, must be zero (0). 976 977 o Secrecy Category Bitmap (variable length) - A bitmap used to 978 designate secrecy categories (compartments) that are required. 979 The bitmap MUST be padded with zero (0) to align on the next 980 32-bit boundary. 981 982 o Integrity Length (2 octets) - Specifies the length, in octets, 983 of the integrity level identifier, excluding pad bits. 984 985 o RESERVED (2 octets) - Unused, must be zero (0). 986 987 o Integrity Level (variable length) - Specifies the mandatory 988 integrity level required. The integrity level MUST be padded 989 with zero (0) to align on the next 32-bit boundary. 990 991 o Integrity Category Length (2 octets) - Specifies the length, in 992 bits, of the integrity category (compartment) bitmap, excluding 993 pad bits. 994 995 o RESERVED (2 octets) - Unused, must be zero (0). 996 997 o Integrity Category Bitmap (variable length) - A bitmap used to 998 designate integrity categories (compartments) that are required. 999 The bitmap MUST be padded with zero (0) to align on the next 1000 32-bit boundary. 1001 10024.6.1.1 IPSEC Labeled Domain Identifiers 1003 1004 The following table lists the assigned values for the Labeled Domain 1005 Identifier field contained in the Situation field of the Security 1006 Association Payload. 1007 1008 1009 1010Piper Standards Track [Page 18] 1011 1012RFC 2407 IP Security Domain of Interpretation November 1998 1013 1014 1015 Domain Value 1016 ------- ----- 1017 RESERVED 0 1018 10194.6.2 Identification Payload Content 1020 1021 The Identification Payload is used to identify the initiator of the 1022 Security Association. The identity of the initiator SHOULD be used 1023 by the responder to determine the correct host system security policy 1024 requirement for the association. For example, a host might choose to 1025 require authentication and integrity without confidentiality (AH) 1026 from a certain set of IP addresses and full authentication with 1027 confidentiality (ESP) from another range of IP addresses. The 1028 Identification Payload provides information that can be used by the 1029 responder to make this decision. 1030 1031 During Phase I negotiations, the ID port and protocol fields MUST be 1032 set to zero or to UDP port 500. If an implementation receives any 1033 other values, this MUST be treated as an error and the security 1034 association setup MUST be aborted. This event SHOULD be auditable. 1035 1036 The following diagram illustrates the content of the Identification 1037 Payload. 1038 1039 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 ! Next Payload ! RESERVED ! Payload Length ! 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 ! ID Type ! Protocol ID ! Port ! 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 ~ Identification Data ~ 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 1048 Figure 2: Identification Payload Format 1049 1050 The Identification Payload fields are defined as follows: 1051 1052 o Next Payload (1 octet) - Identifier for the payload type of 1053 the next payload in the message. If the current payload is the 1054 last in the message, this field will be zero (0). 1055 1056 o RESERVED (1 octet) - Unused, must be zero (0). 1057 1058 o Payload Length (2 octets) - Length, in octets, of the 1059 identification data, including the generic header. 1060 1061 o Identification Type (1 octet) - Value describing the identity 1062 information found in the Identification Data field. 1063 1064 1065 1066Piper Standards Track [Page 19] 1067 1068RFC 2407 IP Security Domain of Interpretation November 1998 1069 1070 1071 o Protocol ID (1 octet) - Value specifying an associated IP 1072 protocol ID (e.g. UDP/TCP). A value of zero means that the 1073 Protocol ID field should be ignored. 1074 1075 o Port (2 octets) - Value specifying an associated port. A value 1076 of zero means that the Port field should be ignored. 1077 1078 o Identification Data (variable length) - Value, as indicated by 1079 the Identification Type. 1080 10814.6.2.1 Identification Type Values 1082 1083 The following table lists the assigned values for the Identification 1084 Type field found in the Identification Payload. 1085 1086 ID Type Value 1087 ------- ----- 1088 RESERVED 0 1089 ID_IPV4_ADDR 1 1090 ID_FQDN 2 1091 ID_USER_FQDN 3 1092 ID_IPV4_ADDR_SUBNET 4 1093 ID_IPV6_ADDR 5 1094 ID_IPV6_ADDR_SUBNET 6 1095 ID_IPV4_ADDR_RANGE 7 1096 ID_IPV6_ADDR_RANGE 8 1097 ID_DER_ASN1_DN 9 1098 ID_DER_ASN1_GN 10 1099 ID_KEY_ID 11 1100 1101 For types where the ID entity is variable length, the size of the ID 1102 entity is computed from size in the ID payload header. 1103 1104 When an IKE exchange is authenticated using certificates (of any 1105 format), any ID's used for input to local policy decisions SHOULD be 1106 contained in the certificate used in the authentication of the 1107 exchange. 1108 11094.6.2.2 ID_IPV4_ADDR 1110 1111 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 1112 11134.6.2.3 ID_FQDN 1114 1115 The ID_FQDN type specifies a fully-qualified domain name string. An 1116 example of a ID_FQDN is, "foo.bar.com". The string should not 1117 contain any terminators. 1118 1119 1120 1121 1122Piper Standards Track [Page 20] 1123 1124RFC 2407 IP Security Domain of Interpretation November 1998 1125 1126 11274.6.2.4 ID_USER_FQDN 1128 1129 The ID_USER_FQDN type specifies a fully-qualified username string, An 1130 example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should 1131 not contain any terminators. 1132 11334.6.2.5 ID_IPV4_ADDR_SUBNET 1134 1135 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, 1136 represented by two four (4) octet values. The first value is an IPv4 1137 address. The second is an IPv4 network mask. Note that ones (1s) in 1138 the network mask indicate that the corresponding bit in the address 1139 is fixed, while zeros (0s) indicate a "wildcard" bit. 1140 11414.6.2.6 ID_IPV6_ADDR 1142 1143 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 1144 address. 1145 11464.6.2.7 ID_IPV6_ADDR_SUBNET 1147 1148 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, 1149 represented by two sixteen (16) octet values. The first value is an 1150 IPv6 address. The second is an IPv6 network mask. Note that ones 1151 (1s) in the network mask indicate that the corresponding bit in the 1152 address is fixed, while zeros (0s) indicate a "wildcard" bit. 1153 11544.6.2.8 ID_IPV4_ADDR_RANGE 1155 1156 The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, 1157 represented by two four (4) octet values. The first value is the 1158 beginning IPv4 address (inclusive) and the second value is the ending 1159 IPv4 address (inclusive). All addresses falling between the two 1160 specified addresses are considered to be within the list. 1161 11624.6.2.9 ID_IPV6_ADDR_RANGE 1163 1164 The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, 1165 represented by two sixteen (16) octet values. The first value is the 1166 beginning IPv6 address (inclusive) and the second value is the ending 1167 IPv6 address (inclusive). All addresses falling between the two 1168 specified addresses are considered to be within the list. 1169 11704.6.2.10 ID_DER_ASN1_DN 1171 1172 The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 1173 X.500 Distinguished Name [X.501] of the principal whose certificates 1174 are being exchanged to establish the SA. 1175 1176 1177 1178Piper Standards Track [Page 21] 1179 1180RFC 2407 IP Security Domain of Interpretation November 1998 1181 1182 11834.6.2.11 ID_DER_ASN1_GN 1184 1185 The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 1186 X.500 GeneralName [X.509] of the principal whose certificates are 1187 being exchanged to establish the SA. 1188 11894.6.2.12 ID_KEY_ID 1190 1191 The ID_KEY_ID type specifies an opaque byte stream which may be used 1192 to pass vendor-specific information necessary to identify which pre- 1193 shared key should be used to authenticate Aggressive mode 1194 negotiations. 1195 11964.6.3 IPSEC Notify Message Types 1197 1198 ISAKMP defines two blocks of Notify Message codes, one for errors and 1199 one for status messages. ISAKMP also allocates a portion of each 1200 block for private use within a DOI. The IPSEC DOI defines the 1201 following private message types for its own use. 1202 1203 Notify Messages - Error Types Value 1204 ----------------------------- ----- 1205 RESERVED 8192 1206 1207 Notify Messages - Status Types Value 1208 ------------------------------ ----- 1209 RESPONDER-LIFETIME 24576 1210 REPLAY-STATUS 24577 1211 INITIAL-CONTACT 24578 1212 1213 Notification Status Messages MUST be sent under the protection of an 1214 ISAKMP SA: either as a payload in the last Main Mode exchange; in a 1215 separate Informational Exchange after Main Mode or Aggressive Mode 1216 processing is complete; or as a payload in any Quick Mode exchange. 1217 These messages MUST NOT be sent in Aggressive Mode exchange, since 1218 Aggressive Mode does not provide the necessary protection to bind the 1219 Notify Status Message to the exchange. 1220 1221 Nota Bene: a Notify payload is fully protected only in Quick Mode, 1222 where the entire payload is included in the HASH(n) digest. In Main 1223 Mode, while the notify payload is encrypted, it is not currently 1224 included in the HASH(n) digests. As a result, an active substitution 1225 attack on the Main Mode ciphertext could cause the notify status 1226 message type to be corrupted. (This is true, in general, for the 1227 last message of any Main Mode exchange.) While the risk is small, a 1228 corrupt notify message might cause the receiver to abort the entire 1229 negotiation thinking that the sender encountered a fatal error. 1230 1231 1232 1233 1234Piper Standards Track [Page 22] 1235 1236RFC 2407 IP Security Domain of Interpretation November 1998 1237 1238 1239 Implementation Note: the ISAKMP protocol does not guarantee delivery 1240 of Notification Status messages when sent in an ISAKMP Informational 1241 Exchange. To ensure receipt of any particular message, the sender 1242 SHOULD include a Notification Payload in a defined Main Mode or Quick 1243 Mode exchange which is protected by a retransmission timer. 1244 12454.6.3.1 RESPONDER-LIFETIME 1246 1247 The RESPONDER-LIFETIME status message may be used to communicate the 1248 IPSEC SA lifetime chosen by the responder. 1249 1250 When present, the Notification Payload MUST have the following 1251 format: 1252 1253 o Payload Length - set to length of payload + size of data (var) 1254 o DOI - set to IPSEC DOI (1) 1255 o Protocol ID - set to selected Protocol ID from chosen SA 1256 o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP 1257 cookies) or four (4) (one IPSEC SPI) 1258 o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) 1259 o SPI - set to the two ISAKMP cookies or to the sender's inbound 1260 IPSEC SPI 1261 o Notification Data - contains an ISAKMP attribute list with the 1262 responder's actual SA lifetime(s) 1263 1264 Implementation Note: saying that the Notification Data field contains 1265 an attribute list is equivalent to saying that the Notification Data 1266 field has zero length and the Notification Payload has an associated 1267 attribute list. 1268 12694.6.3.2 REPLAY-STATUS 1270 1271 The REPLAY-STATUS status message may be used for positive 1272 confirmation of the responder's election on whether or not he is to 1273 perform anti-replay detection. 1274 1275 When present, the Notification Payload MUST have the following 1276 format: 1277 1278 o Payload Length - set to length of payload + size of data (4) 1279 o DOI - set to IPSEC DOI (1) 1280 o Protocol ID - set to selected Protocol ID from chosen SA 1281 o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP 1282 cookies) or four (4) (one IPSEC SPI) 1283 o Notify Message Type - set to REPLAY-STATUS 1284 o SPI - set to the two ISAKMP cookies or to the sender's inbound 1285 IPSEC SPI 1286 o Notification Data - a 4 octet value: 1287 1288 1289 1290Piper Standards Track [Page 23] 1291 1292RFC 2407 IP Security Domain of Interpretation November 1998 1293 1294 1295 0 = replay detection disabled 1296 1 = replay detection enabled 1297 12984.6.3.3 INITIAL-CONTACT 1299 1300 The INITIAL-CONTACT status message may be used when one side wishes 1301 to inform the other that this is the first SA being established with 1302 the remote system. The receiver of this Notification Message might 1303 then elect to delete any existing SA's it has for the sending system 1304 under the assumption that the sending system has rebooted and no 1305 longer has access to the original SA's and their associated keying 1306 material. When used, the content of the Notification Data field 1307 SHOULD be null (i.e. the Payload Length should be set to the fixed 1308 length of Notification Payload). 1309 1310 When present, the Notification Payload MUST have the following 1311 format: 1312 1313 o Payload Length - set to length of payload + size of data (0) 1314 o DOI - set to IPSEC DOI (1) 1315 o Protocol ID - set to selected Protocol ID from chosen SA 1316 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 1317 o Notify Message Type - set to INITIAL-CONTACT 1318 o SPI - set to the two ISAKMP cookies 1319 o Notification Data - <not included> 1320 13214.7 IPSEC Key Exchange Requirements 1322 1323 The IPSEC DOI introduces no additional Key Exchange types. 1324 13255. Security Considerations 1326 1327 This entire memo pertains to the Internet Key Exchange protocol 1328 ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to 1329 provide for the derivation of cryptographic keying material in a 1330 secure and authenticated manner. Specific discussion of the various 1331 security protocols and transforms identified in this document can be 1332 found in the associated base documents and in the cipher references. 1333 13346. IANA Considerations 1335 1336 This document contains many "magic" numbers to be maintained by the 1337 IANA. This section explains the criteria to be used by the IANA to 1338 assign additional numbers in each of these lists. All values not 1339 explicitly defined in previous sections are reserved to IANA. 1340 1341 1342 1343 1344 1345 1346Piper Standards Track [Page 24] 1347 1348RFC 2407 IP Security Domain of Interpretation November 1998 1349 1350 13516.1 IPSEC Situation Definition 1352 1353 The Situation Definition is a 32-bit bitmask which represents the 1354 environment under which the IPSEC SA proposal and negotiation is 1355 carried out. Requests for assignments of new situations must be 1356 accompanied by an RFC which describes the interpretation for the 1357 associated bit. 1358 1359 If the RFC is not on the standards-track (i.e., it is an 1360 informational or experimental RFC), it must be explicitly reviewed 1361 and approved by the IESG before the RFC is published and the 1362 transform identifier is assigned. 1363 1364 The upper two bits are reserved for private use amongst cooperating 1365 systems. 1366 13676.2 IPSEC Security Protocol Identifiers 1368 1369 The Security Protocol Identifier is an 8-bit value which identifies a 1370 security protocol suite being negotiated. Requests for assignments 1371 of new security protocol identifiers must be accompanied by an RFC 1372 which describes the requested security protocol. [AH] and [ESP] are 1373 examples of security protocol documents. 1374 1375 If the RFC is not on the standards-track (i.e., it is an 1376 informational or experimental RFC), it must be explicitly reviewed 1377 and approved by the IESG before the RFC is published and the 1378 transform identifier is assigned. 1379 1380 The values 249-255 are reserved for private use amongst cooperating 1381 systems. 1382 13836.3 IPSEC ISAKMP Transform Identifiers 1384 1385 The IPSEC ISAKMP Transform Identifier is an 8-bit value which 1386 identifies a key exchange protocol to be used for the negotiation. 1387 Requests for assignments of new ISAKMP transform identifiers must be 1388 accompanied by an RFC which describes the requested key exchange 1389 protocol. [IKE] is an example of one such document. 1390 1391 If the RFC is not on the standards-track (i.e., it is an 1392 informational or experimental RFC), it must be explicitly reviewed 1393 and approved by the IESG before the RFC is published and the 1394 transform identifier is assigned. 1395 1396 The values 249-255 are reserved for private use amongst cooperating 1397 systems. 1398 1399 1400 1401 1402Piper Standards Track [Page 25] 1403 1404RFC 2407 IP Security Domain of Interpretation November 1998 1405 1406 14076.4 IPSEC AH Transform Identifiers 1408 1409 The IPSEC AH Transform Identifier is an 8-bit value which identifies 1410 a particular algorithm to be used to provide integrity protection for 1411 AH. Requests for assignments of new AH transform identifiers must be 1412 accompanied by an RFC which describes how to use the algorithm within 1413 the AH framework ([AH]). 1414 1415 If the RFC is not on the standards-track (i.e., it is an 1416 informational or experimental RFC), it must be explicitly reviewed 1417 and approved by the IESG before the RFC is published and the 1418 transform identifier is assigned. 1419 1420 The values 249-255 are reserved for private use amongst cooperating 1421 systems. 1422 14236.5 IPSEC ESP Transform Identifiers 1424 1425 The IPSEC ESP Transform Identifier is an 8-bit value which identifies 1426 a particular algorithm to be used to provide secrecy protection for 1427 ESP. Requests for assignments of new ESP transform identifiers must 1428 be accompanied by an RFC which describes how to use the algorithm 1429 within the ESP framework ([ESP]). 1430 1431 If the RFC is not on the standards-track (i.e., it is an 1432 informational or experimental RFC), it must be explicitly reviewed 1433 and approved by the IESG before the RFC is published and the 1434 transform identifier is assigned. 1435 1436 The values 249-255 are reserved for private use amongst cooperating 1437 systems. 1438 14396.6 IPSEC IPCOMP Transform Identifiers 1440 1441 The IPSEC IPCOMP Transform Identifier is an 8-bit value which 1442 identifier a particular algorithm to be used to provide IP-level 1443 compression before ESP. Requests for assignments of new IPCOMP 1444 transform identifiers must be accompanied by an RFC which describes 1445 how to use the algorithm within the IPCOMP framework ([IPCOMP]). In 1446 addition, the requested algorithm must be published and in the public 1447 domain. 1448 1449 If the RFC is not on the standards-track (i.e., it is an 1450 informational or experimental RFC), it must be explicitly reviewed 1451 and approved by the IESG before the RFC is published and the 1452 transform identifier is assigned. 1453 1454 1455 1456 1457 1458Piper Standards Track [Page 26] 1459 1460RFC 2407 IP Security Domain of Interpretation November 1998 1461 1462 1463 The values 1-47 are reserved for algorithms for which an RFC has been 1464 approved for publication. The values 48-63 are reserved for private 1465 use amongst cooperating systems. The values 64-255 are reserved for 1466 future expansion. 1467 14686.7 IPSEC Security Association Attributes 1469 1470 The IPSEC Security Association Attribute consists of a 16-bit type 1471 and its associated value. IPSEC SA attributes are used to pass 1472 miscellaneous values between ISAKMP peers. Requests for assignments 1473 of new IPSEC SA attributes must be accompanied by an Internet Draft 1474 which describes the attribute encoding (Basic/Variable-Length) and 1475 its legal values. Section 4.5 of this document provides an example 1476 of such a description. 1477 1478 The values 32001-32767 are reserved for private use amongst 1479 cooperating systems. 1480 14816.8 IPSEC Labeled Domain Identifiers 1482 1483 The IPSEC Labeled Domain Identifier is a 32-bit value which 1484 identifies a namespace in which the Secrecy and Integrity levels and 1485 categories values are said to exist. Requests for assignments of new 1486 IPSEC Labeled Domain Identifiers should be granted on demand. No 1487 accompanying documentation is required, though Internet Drafts are 1488 encouraged when appropriate. 1489 1490 The values 0x80000000-0xffffffff are reserved for private use amongst 1491 cooperating systems. 1492 14936.9 IPSEC Identification Type 1494 1495 The IPSEC Identification Type is an 8-bit value which is used as a 1496 discriminant for interpretation of the variable-length Identification 1497 Payload. Requests for assignments of new IPSEC Identification Types 1498 must be accompanied by an RFC which describes how to use the 1499 identification type within IPSEC. 1500 1501 If the RFC is not on the standards-track (i.e., it is an 1502 informational or experimental RFC), it must be explicitly reviewed 1503 and approved by the IESG before the RFC is published and the 1504 transform identifier is assigned. 1505 1506 The values 249-255 are reserved for private use amongst cooperating 1507 systems. 1508 1509 1510 1511 1512 1513 1514Piper Standards Track [Page 27] 1515 1516RFC 2407 IP Security Domain of Interpretation November 1998 1517 1518 15196.10 IPSEC Notify Message Types 1520 1521 The IPSEC Notify Message Type is a 16-bit value taken from the range 1522 of values reserved by ISAKMP for each DOI. There is one range for 1523 error messages (8192-16383) and a different range for status messages 1524 (24576-32767). Requests for assignments of new Notify Message Types 1525 must be accompanied by an Internet Draft which describes how to use 1526 the identification type within IPSEC. 1527 1528 The values 16001-16383 and the values 32001-32767 are reserved for 1529 private use amongst cooperating systems. 1530 15317. Change Log 1532 15337.1 Changes from V9 1534 1535 o add explicit reference to [IPCOMP], [DEFLATE], and [LZS] 1536 o allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed 1537 at an IPSEC SPI in addition to the ISAKMP "SPI" 1538 o added padding exclusion to Secrecy and Integrity Length text 1539 o added forward reference to Section 4.5 in Section 4.4.4 1540 o update document references 1541 15427.2 Changes from V8 1543 1544 o update IPCOMP identifier range to better reflect IPCOMP draft 1545 o update IANA considerations per Jeff/Ted's suggested text 1546 o eliminate references to DES-MAC ID ([DESMAC]) 1547 o correct bug in Notify section; ISAKMP Notify values are 16-bits 1548 15497.3 Changes from V7 1550 1551 o corrected name of IPCOMP (IP Payload Compression) 1552 o corrected references to [ESPCBC] 1553 o added missing Secrecy Level and Integrity Level to Figure 1 1554 o removed ID references to PF_KEY and ARCFOUR 1555 o updated Basic/Variable text to align with [IKE] 1556 o updated document references and add intro pointer to [ARCH] 1557 o updated Notification requirements; remove aggressive reference 1558 o added clarification about protection for Notify payloads 1559 o restored RESERVED to ESP transform ID namespace; moved ESP_NULL 1560 o added requirement for ESP_NULL support and [ESPNULL] reference 1561 o added clarification on Auth Alg use with AH/ESP 1562 o added restriction against using conflicting AH/Auth combinations 1563 15647.4 Changes from V6 1565 1566 The following changes were made relative to the IPSEC DOI V6: 1567 1568 1569 1570Piper Standards Track [Page 28] 1571 1572RFC 2407 IP Security Domain of Interpretation November 1998 1573 1574 1575 o added IANA Considerations section 1576 o moved most IANA numbers to IANA Considerations section 1577 o added prohibition on sending (V) encoding for (B) attributes 1578 o added prohibition on sending Key Length attribute for fixed 1579 length ciphers (e.g. DES) 1580 o replaced references to ISAKMP/Oakley with IKE 1581 o renamed ESP_ARCFOUR to ESP_RC4 1582 o updated Security Considerations section 1583 o updated document references 1584 15857.5 Changes from V5 1586 1587 The following changes were made relative to the IPSEC DOI V5: 1588 1589 o changed SPI size in Lifetime Notification text 1590 o changed REPLAY-ENABLED to REPLAY-STATUS 1591 o moved RESPONDER-LIFETIME payload definition from Section 4.5.4 1592 to Section 4.6.3.1 1593 o added explicit payload layout for 4.6.3.3 1594 o added Implementation Note to Section 4.6.3 introduction 1595 o changed AH_SHA text to require SHA-1 in addition to MD5 1596 o updated document references 1597 15987.6 Changes from V4 1599 1600 The following changes were made relative to the IPSEC DOI V4: 1601 1602 o moved compatibility AH KPDK authentication method from AH 1603 transform ID to Authentication Algorithm identifier 1604 o added REPLAY-ENABLED notification message type per Architecture 1605 o added INITIAL-CONTACT notification message type per list 1606 o added text to ensure protection for Notify Status messages 1607 o added Lifetime qualification to attribute parsing section 1608 o added clarification that Lifetime notification is optional 1609 o removed private Group Description list (now points at [IKE]) 1610 o replaced Terminology with pointer to RFC-2119 1611 o updated HMAC MD5 and SHA-1 ID references 1612 o updated Section 1 (Abstract) 1613 o updated Section 4.4 (IPSEC Assigned Numbers) 1614 o added restriction for ID port/protocol values for Phase I 1615 16167.7 Changes from V3 to V4 1617 1618 The following changes were made relative to the IPSEC DOI V3, that 1619 was posted to the IPSEC mailing list prior to the Munich IETF: 1620 1621 o added ESP transform identifiers for NULL and ARCFOUR 1622 1623 1624 1625 1626Piper Standards Track [Page 29] 1627 1628RFC 2407 IP Security Domain of Interpretation November 1998 1629 1630 1631 o renamed HMAC Algorithm to Auth Algorithm to accommodate 1632 DES-MAC and optional authentication/integrity for ESP 1633 o added AH and ESP DES-MAC algorithm identifiers 1634 o removed KEY_MANUAL and KEY_KDC identifier definitions 1635 o added lifetime duration MUST follow lifetype attribute to 1636 SA Life Type and SA Life Duration attribute definition 1637 o added lifetime notification and IPSEC DOI message type table 1638 o added optional authentication and confidentiality 1639 restrictions to MAC Algorithm attribute definition 1640 o corrected attribute parsing example (used obsolete attribute) 1641 o corrected several Internet Draft document references 1642 o added ID_KEY_ID per ipsec list discussion (18-Mar-97) 1643 o removed Group Description default for PFS QM ([IKE] MUST) 1644 1645Acknowledgments 1646 1647 This document is derived, in part, from previous works by Douglas 1648 Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, 1649 and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran 1650 Atkinson also contributed suggestions and, in many cases, text. 1651 1652References 1653 1654 [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 1655 2402, November 1998. 1656 1657 [ARCH] Kent, S., and R. Atkinson, "Security Architecture for the 1658 Internet Protocol", RFC 2401, November 1998. 1659 1660 [DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 1661 2394, August 1998. 1662 1663 [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security 1664 Payload (ESP)", RFC 2406, November 1998. 1665 1666 [ESPCBC] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher 1667 Algorithms", RFC 2451, November 1998. 1668 1669 [ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and 1670 Its Use With IPsec", RFC 2410, November 1998. 1671 1672 [DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher 1673 Algorithm With Explicit IV", RFC 2405, November 1998. 1674 1675 [HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP 1676 and AH", RFC 2403, November 1998. 1677 1678 1679 1680 1681 1682Piper Standards Track [Page 30] 1683 1684RFC 2407 IP Security Domain of Interpretation November 1998 1685 1686 1687 [HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within 1688 ESP and AH", RFC 2404, November 1998. 1689 1690 [IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange 1691 (IKE)", RFC 2409, November 1998. 1692 1693 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 1694 Payload Compression Protocol (IPComp)", RFC 2393, August 1695 1998. 1696 1697 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 1698 "Internet Security Association and Key Management Protocol 1699 (ISAKMP)", RFC 2408, November 1998. 1700 1701 [LZS] Friend, R., and R. Monsour, "IP Payload Compression Using 1702 LZS", RFC 2395, August 1998. 1703 1704 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 1705 2412, November 1998. 1706 1707 [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems 1708 Interconnection - The Directory: Models", CCITT/ITU 1709 Recommendation X.501, 1993. 1710 1711 [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems 1712 Interconnection - The Directory: Authentication 1713 Framework", CCITT/ITU Recommendation X.509, 1993. 1714 1715Author's Address 1716 1717 Derrell Piper 1718 Network Alchemy 1719 1521.5 Pacific Ave 1720 Santa Cruz, California, 95060 1721 United States of America 1722 1723 Phone: +1 408 460-3822 1724 EMail: ddp@network-alchemy.com 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738Piper Standards Track [Page 31] 1739 1740RFC 2407 IP Security Domain of Interpretation November 1998 1741 1742 1743Full Copyright Statement 1744 1745 Copyright (C) The Internet Society (1998). All Rights Reserved. 1746 1747 This document and translations of it may be copied and furnished to 1748 others, and derivative works that comment on or otherwise explain it 1749 or assist in its implementation may be prepared, copied, published 1750 and distributed, in whole or in part, without restriction of any 1751 kind, provided that the above copyright notice and this paragraph are 1752 included on all such copies and derivative works. However, this 1753 document itself may not be modified in any way, such as by removing 1754 the copyright notice or references to the Internet Society or other 1755 Internet organizations, except as needed for the purpose of 1756 developing Internet standards in which case the procedures for 1757 copyrights defined in the Internet Standards process must be 1758 followed, or as required to translate it into languages other than 1759 English. 1760 1761 The limited permissions granted above are perpetual and will not be 1762 revoked by the Internet Society or its successors or assigns. 1763 1764 This document and the information contained herein is provided on an 1765 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1766 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1767 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1768 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1769 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794Piper Standards Track [Page 32] 1795 1796