idnits 2.17.00 (12 Aug 2021) /tmp/idnits37373/draft-tschofenig-rsvp-doi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 6946 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: 'IPSDOI' is mentioned on line 700, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'TK03' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tsc03' ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2367 -- Possible downref: Non-RFC (?) normative reference: ref. 'TV03' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bru03' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Downref: Normative reference to an Informational RFC: RFC 3232 ** Downref: Normative reference to an Experimental RFC: RFC 2093 -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF56' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF NSIS Working Group 3 Internet Draft H. Tschofenig 4 Siemens 5 H. Schulzrinne 6 Columbia U. 7 Document: draft-tschofenig-rsvp-doi-00.txt 8 Expires: November 2003 May 2003 10 RSVP Domain of Interpretation for ISAKMP 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 RSVP does not provide dynamic key management for the RSVP Integrity 36 object. It is difficult to provide security for RSVP based on 37 standard security protocols. This draft proposes the usage of the 38 ISAKMP protocol with a new Domain of Interpretation (DoI) and allows 39 to establish the necessary security parameters for the RSVP 40 Integrity object. The Integrity object protects RSVP signaling 41 messages at the application layer and uses this DoI to dynamically 42 establish the necessary security associations. 44 This document also addresses the NSIS NTLP work and protocol design 45 implications. 47 Table of Contents 49 1. Introduction...............................................2 50 1.1 RSVP DoI................................................2 51 1.2 Requirements for a DOI..................................4 52 2. Terminology................................................4 53 3. Definition.................................................4 54 3.1 Naming Scheme...........................................4 55 3.2 Situation Definition....................................5 56 3.2.1 SIT_IDENTITY_ONLY.....................................5 57 3.3 Security Policy Requirements............................5 58 3.3.1 Key Management Issues.................................5 59 3.3.1.1 Static Keying Issues.................................6 60 3.3.1.2 Policy Issues........................................6 61 3.3.1.3 Certificate Management...............................7 62 3.4 RSVP DOI assigned numbers...............................7 63 3.4.1 RSVP DOI Security Protocol Identifier.................7 64 3.4.1.1 PROTO_ISAKMP.........................................8 65 3.4.1.2 PROTO_RSVP_Integrity.................................8 66 3.4.2 RSVP ISAKMP Transform Identifiers.....................8 67 3.4.2.1 KEY_IKE..............................................9 68 3.4.3 RSVP Integrity Transform Identifiers..................9 69 3.4.3.1 AUTH_MD5............................................10 70 3.4.3.2 AUTH_SHA............................................10 71 3.4.3.3 AUTH_DES............................................11 72 3.5 RSVP Security Association Attributes...................11 73 3.5.1 Required Attribute Support...........................12 74 3.5.2 Attribute Parsing Requirement (Lifetime).............12 75 3.5.3 Attribute Negotiation................................13 76 3.5.4 Lifetime Notification................................13 77 3.6 RSVP DOI Payload Content...............................14 78 3.6.1 Identification Payload Content.......................14 79 3.6.2 RSVP DOI Notify Message Types........................15 80 3.6.2.1 RESPONDER-LIFETIME..................................16 81 3.6.2.2 INITIAL-CONTACT.....................................17 82 4. Security Considerations...................................17 83 5. IANA Considerations.......................................18 84 6. Key Derivation............................................18 85 7. Open Issues...............................................18 86 8. References................................................19 87 9. Acknowledgments...........................................21 88 10. Author's Addresses........................................21 90 1. Introduction 92 1.1 RSVP DoI 94 RSVP [RFC2205] offers security based on the RSVP Integrity object as 95 described in [RFC2747] and based on the user identity representation 96 document [RFC3182]. Unfortunately there is still room for 97 improvement for a number of reasons. This document tries to fix some 98 of them, namely providing dynamic authentication and key exchange in 99 order to create the necessary security parameters for the RSVP 100 Integrity object. The mechanism described in this document is 101 executed independently of the RSVP message exchange to avoid 102 modifications to the RSVP protocol itself. 104 It is important to mention that this document is based on the 105 assumption that two RSVP nodes know each other already before they 106 exchange RSVP messages (and therefore knows which security parameter 107 to select). Unfortunately this is not true for all scenarios. Thus 108 in these cases where this assumption does not hold it is not 109 possible to use this mechanisms. This assumption mainly addresses 110 the nature of PATH alike signaling messages (i.e. messages which are 111 addressed to the end host and carry a Router Alert Option 112 [RFC2113]). 114 For a more elaborated discussion of security properties of RSVP the 115 reader is referred to [Tsc03]. Furthermore, this document tries to 116 follow the current NSIS working group documents with regard to their 117 requirements and framework thoughts (see [HF+03] and [Bru03]). 118 Additionally security threats relevant for NSIS are applicable to 119 this work (see [TK03]). 121 At the 56th IETF the NSIS wg chair, John Loughney, gave a 122 presentation on the starting points for NTLP work (see slides 123 available at [IETF56]). One issue addressed the combination of 124 discovery and transport as provided by the RSVP Path message. If 125 this assumption is also used for a future NSIS protocol then this 126 DoI is also applicable. Hence also the work in NSIS can possibly 127 benefit from this document. This draft therefore illustrates 128 implications to security caused by certain design considerations. 130 The basic procedure could therefore described as follows: 132 Whenever an RSVP signaling message has to be sent to the next RSVP 133 aware node and no such security association is already available 134 then a new one has to be dynamically established. RSVP therefore 135 triggers the key management daemon. The RSVP daemon then constructs 136 a RSVP message and interacts with the security association database 137 using some sort of API (e.g. PF_KEY [RFC2367]) to retrieve the 138 session key and other security parameters. Maintenance (creation, 139 deletion, rekeying, possibly dead peer detection, etc.) of the RSVP 140 security association is accomplished by the key management daemon. 141 KINK [TV03], which uses Kerberos, can also be used as an 142 authentication and key exchange protocol in addition to IKE. 144 Note that this draft is strongly aligned with [RFC2407] and reuses 145 the same structure and (if appropriate) the same text. 147 1.2 Requirements for a DOI 149 Within ISAKMP, a Domain of Interpretation is used to group related 150 protocols using ISAKMP to negotiate security associations. Security 151 protocols sharing a DOI choose security protocol and cryptographic 152 transforms from a common namespace and share key exchange protocol 153 identifiers. They also share a common interpretation of DOI- 154 specific payload data content, including the Security Association 155 and Identification payloads. 157 Overall, ISAKMP places the following requirements on a DOI 158 definition: 160 o define the naming scheme for DOI-specific protocol identifiers 161 o define the interpretation for the Situation field 162 o define the set of applicable security policies 163 o define the syntax for DOI-specific SA Attributes (Phase II) 164 o define the syntax for DOI-specific payload contents 165 o define additional Key Exchange types, if needed 166 o define additional Notification Message types, if needed 168 The remainder of this document describes the instantiation of these 169 requirements for using the RSVP Security mechanism specified in 170 [RFC2747] to provide authentication, integrity and replay 171 protection. 173 2. Terminology 175 This document does not introduce new terms. 177 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 178 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 179 document, are to be interpreted as described in [RFC2119]. 181 3. Definition 183 3.1 Naming Scheme 185 Within ISAKMP, all DOI's must be registered with the IANA in the 186 "Assigned Numbers" RFC [RFC3232]. The IANA Assigned Number for the 187 RSVP DOI is TBD (TBD). Within the RSVP DOI, all well-known 188 identifiers MUST be registered with the IANA under the RSVP DOI. 189 Unless otherwise noted, all tables within this document refer to 190 IANA Assigned Numbers for the RSVP DOI. See Section 5 for further 191 information relating to the IANA registry for the RSVP DOI. 193 All multi-octet binary values are stored in network byte order. 195 3.2 Situation Definition 197 Within ISAKMP, the Situation provides information that can be used 198 by the responder to make a policy determination about how to process 199 the incoming Security Association request. For the RSVP DOI, the 200 Situation field is a four (4) octet bitmask with the following 201 values. 203 Situation Value 204 --------- ----- 205 SIT_IDENTITY_ONLY 0x01 207 3.2.1 SIT_IDENTITY_ONLY 209 The SIT_IDENTITY_ONLY type specifies that the security association 210 will be identified by source identity information present in an 211 associated Identification Payload. See Section 4.6.2 of [RFC2407] 212 for a complete description of the various Identification types. All 213 RSVP DOI implementations MUST support SIT_IDENTITY_ONLY by including 214 an Identification Payload in at least one of the Phase I Oakley 215 exchanges ([RFC2409], Section 5) and MUST abort any association 216 setup that does not include an Identification Payload. 218 3.3 Security Policy Requirements 220 The RSVP DOI does not impose specific security policy requirements 221 on any implementation. Host system policy issues are outside of the 222 scope of this document. 224 However, the following sections touch on some of the issues that 225 must be considered when designing an RSVP DOI implementation. This 226 section should be considered only informational in nature. 228 3.3.1 Key Management Issues 230 It is expected that many systems choosing to implement ISAKMP will 231 strive to provide a protected domain of execution for a combined IKE 232 key management daemon. On protected-mode multi-user operating 233 systems, this key management daemon will likely exist as a separate 234 privileged process. 236 In such an environment, a formalized API such as PF_KEY [RFC2367] to 237 communicate keying material (and other security relevant parameters) 238 between the RSVP Daemon, the key management daemon and the key 239 engine may be desirable. 241 3.3.1.1 Static Keying Issues 243 Systems that implement static keys, either for use directly by RSVP, 244 or for authentication purposes (see [RFC2409] Section 5.4), should 245 take steps to protect the static keying material when it is not 246 residing in a protected memory domain or actively in use by the key 247 engine. 249 Depending on the operating system and utility software installed, it 250 may not be possible to protect the static keys once they are 251 available to the keying engine or to the RSVP daemon, however they 252 should not be trivially recoverable on initial system startup 253 without having to satisfy some additional form of authentication. 255 3.3.1.2 Policy Issues 257 It is not realistic to assume that the transition to RSVP DOI will 258 occur overnight. Incremental deployment is, however, possible 259 particularly in intra-domain environments. Systems must be prepared 260 to implement flexible policy lists that describe which systems they 261 desire to speak securely with and which systems they require speak 262 securely to them. This type of authorization behavior particularly 263 addresses intra-domain environments where a strong trust 264 relationship between individual RSVP nodes exists. 266 A minimal approach is probably a static list of IP addresses. For 267 intra-domain communication such an approach might be sufficient in 268 many cases due to the nature of RSVP signaling. A more flexible 269 approach based on wildcard DNS names is given below and might 270 simplify and reduce configuration overhead. 272 For inter-domain environments the authorization procedure must 273 provide some mapping to an authorized identity for which a financial 274 settlement between the interacting domains exist. For inter-domain 275 environments it seems to be more appropriate not to use static lists 276 of IP addresses. A more flexible implementation might consist of a 277 list of wildcard DNS names (e.g. '*.foo.bar'). The wildcard DNS name 278 would be used to match incoming or outgoing IP addresses. 280 The communication between end systems and the attached network is 281 more difficult from an authorization point of view. The reader is 282 referred to a detailed discussion in [TB+03]. For this version of 283 the document RSVP DOI mainly addresses intra-domain and inter-domain 284 communication instead of end host to network communication due to 285 the authorization nature of QoS signaling protocols. A future 286 version of the document might address these issues (and for non-QoS 287 signaling applications) in an appropriate manner. 289 3.3.1.3 Certificate Management 291 Systems implementing a certificate-based authentication scheme will 292 need a mechanism for obtaining and managing a database of 293 certificates. 295 Secure DNS is to be one certificate distribution mechanism, however 296 the pervasive availability of secure DNS zones, in the short term, 297 is doubtful for many reasons. This is primarily applicable for 298 inter-domain communication. For intra-domain environments secure DNS 299 might be a reasonable choice. 301 The ability for RSVP nodes to import certificates that they acquire 302 through secure, out-of-band mechanisms, is also a reasonable 303 procedure. 305 However, manual certificate management should not be done so as to 306 preclude the ability to introduce dynamic certificate discovery 307 mechanisms and/or protocols as they become available. 309 In addition to certificate-based authentication and the distribution 310 of pre-shared secrets between nodes for the purpose of 311 authentication, Kerberos might be used. KINK [TV03] uses Kerberos 312 and as such a trusted third party entity for authentication and key 313 distribution. KINK replaces the first phase of IKE and represents a 314 very efficient and fast alternative to IKE Phase I. Systems 315 implementing the RSVP DOI SHOULD support this DOI using KINK. 317 3.4 RSVP DOI assigned numbers 319 The following sections list the Assigned Numbers for the RSVP DOI: 320 Situation Identifiers, Protocol Identifiers, Transform Identifiers, 321 Security Association Attribute Type Values, Labeled Domain 322 Identifiers, ID Payload Type Values, and Notify Message Type Values. 324 3.4.1 RSVP DOI Security Protocol Identifier 326 The ISAKMP proposal syntax was specifically designed to allow for 327 the simultaneous negotiation of multiple Phase II security protocol 328 suites within a single negotiation. As a result, the protocol suites 329 listed below form the set of protocols that can be negotiated at the 330 same time. It is a host policy decision as to what protocol suites 331 might be negotiated together. 333 Protocol ID Value 334 ----------- ----- 335 RESERVED 0 336 PROTO_ISAKMP 1 337 PROTO_RSVP_Integrity 2 339 All other values unused. 341 3.4.1.1 PROTO_ISAKMP 343 The PROTO_ISAKMP type specifies message protection required during 344 Phase I of the ISAKMP protocol. The specific protection mechanism 345 used for the RSVP DOI is described in [RFC2409]. All implementations 346 within the RSVP DOI MUST support PROTO_ISAKMP. 348 NB: ISAKMP reserves the value one (1) across all DOI definitions. 350 3.4.1.2 PROTO_RSVP_Integrity 352 The PROTO_RSVP_Integrity type provides the necessary parameters for 353 the security association used in RSVP (i.e. the RSVP Integrity 354 Object [RFC2747]). This transform provides data origin 355 authentication, integrity protection and replay detection. 357 Transforms for confidentiality protection are currently not defined. 358 Support for confidentiality protection is currently not provided 359 although useful. Furthermore, transforms providing payload 360 compression do not seem to be useful for a signaling protocol due to 361 the fact that other mechanisms have been standardized which provide 362 similar techniques in a more efficient way (see [RFC2961]). 364 3.4.2 RSVP ISAKMP Transform Identifiers 366 As part of an ISAKMP Phase I negotiation, the initiator's choice of 367 Key Exchange offerings is made using some host system policy 368 description. The actual selection of Key Exchange mechanism is made 369 using the standard ISAKMP Proposal Payload. The following table 370 lists the defined ISAKMP Phase I Transform Identifiers for the 371 Proposal Payload for the RSVP DOI. 373 Transform Value 374 --------- ----- 375 RESERVED 0 376 KEY_IKE 1 378 Within the ISAKMP and RSVP DOI framework it is possible to define 379 key establishment protocols other than IKE (Oakley). Previous 380 versions of this document defined types both for manual keying and 381 for schemes based on use of a generic Key Distribution Center (KDC). 382 These identifiers have been removed from the current document. 384 Extension of the RSVP DOI to include values for additional non- 385 Oakley key establishment protocols (such as the Group Key Management 386 Protocol (GKMP) [RFC2093]) is under consideration. 388 3.4.2.1 KEY_IKE 390 The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman 391 key exchange (IKE) as defined in the [RFC2409] document. All 392 implementations within the RSVP DOI MUST support KEY_IKE. 394 3.4.3 RSVP Integrity Transform Identifiers 396 The RSVP Integrity Object provides data origin authentication, 397 integrity, and replay detection. It consists of the following 398 fields: 400 - Flags 402 The Handshake Flag is the only defined flag and is used to 403 synchronize sequence numbers if the communication gets out-of-sync. 404 The separately defined mechanism is not required. Hence the Flags 405 are set to zero. 407 - Key Identifier 409 The Key Identifier selects the key used for verification of the 410 Keyed Message Digest field. Its length is fixed with 48-bit. 411 According to [RFC2747] is the generation of this Key Identifier 412 field mostly a local decision. 414 The 32-bit SPI field will be used to select the security association 415 for verifying the keyed message digest. Hence the first 32 bit of 416 the 48-bit Key Identifier are the SPI and the last 16 bit are set to 417 zero. 419 - Sequence Number 421 [RFC2747] defines the sequence number used by the RSVP Integrity 422 object as a 64-bit value for which the starting value can be 423 selected arbitrarily. To prevent the need to communicate the 424 sequence number the sequence number MUST start with zero for usage 425 with this protocol. 427 - Keyed Message Digest 429 This field contains the keyed message digest and is a variable 430 length field. 432 The following table lists the defined RSVP Integrity Transform 433 Identifiers for the ISAKMP Proposal Payload for the RSVP DOI. 435 Note: the Authentication Algorithm attribute MUST be specified to 436 identify the appropriate protection suite. For example, AUTH_MD5 can 437 best be thought of as a generic AH transform using MD5. To request 438 the HMAC construction with AUTH, one specifies the AUTH_MD5 439 transform ID along with the Authentication Algorithm attribute set 440 to HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in 441 the following sections. 443 Transform ID Value 444 ------------ ----- 445 RESERVED 0-1 446 AUTH_MD5 2 447 AUTH_SHA 3 448 AUTH_DES 4 450 Note: all mandatory-to-implement algorithms are listed as "MUST" 451 implement (e.g. AUTH_MD5) in the following sections. All other 452 algorithms are optional and MAY be implemented in any particular 453 implementation. 455 3.4.3.1 AUTH_MD5 457 The AUTH_MD5 type specifies a generic AUTH transform using MD5. The 458 actual protection suite is determined in concert with an associated 459 SA attribute list. A generic MD5 transform is currently undefined. 461 All implementations within the RSVP DOI MUST support AUTH_MD5 along 462 with the Auth(HMAC-MD5) attribute. HMAC-MD5 is described in 463 [RFC2104]. 465 Use of AUTH_MD5 with any other Authentication Algorithm attribute 466 value is currently undefined. 468 3.4.3.2 AUTH_SHA 470 The AUTH_SHA type specifies a generic AUTH transform using SHA-1. 471 The actual protection suite is determined in concert with an 472 associated SA attribute list. A generic SHA transform is currently 473 undefined. 475 All implementations within the RSVP DOI MUST support AUTH_SHA along 476 with the Auth(HMAC-SHA) attribute. SHA-1 is described in [SHA1]. 478 Use of AH_SHA with any other Authentication Algorithm attribute 479 value is currently undefined. 481 3.4.3.3 AUTH_DES 483 The AUTH_DES type specifies a generic AUTH transform using DES. The 484 actual protection suite is determined in concert with an associated 485 SA attribute list. A generic DES transform is currently undefined. 487 The RSVP DOI defines AUTH_DES along with the Auth(DES-MAC) attribute 488 to be a DES-MAC transform. Implementations are not required to 489 support this mode. 491 Use of AUTH_DES with any other Authentication Algorithm attribute 492 value is currently undefined. 494 3.5 RSVP Security Association Attributes 496 The following SA attribute definitions are used in Phase II of an 497 IKE negotiation. Attribute types can be either Basic (B) or 498 Variable-Length (V). Encoding of these attributes is defined in the 499 base ISAKMP specification. 501 Attributes described as basic MUST NOT be encoded as variable. 502 Variable length attributes MAY be encoded as basic attributes if 503 their value can fit into two octets. See [RFC2409] for further 504 information on attribute encoding in the RSVP DOI. All restrictions 505 listed in [RFC2409] also apply to the RSVP DOI. 507 Attribute Types 509 class value type 510 ------------------------------------------------- 511 SA Life Type 1 B 512 SA Life Duration 2 V 513 Group Description 3 B 514 Authentication Algorithm 4 B 516 Class Values 518 SA Life Type 519 SA Duration 521 Specifies the time-to-live for the overall security 522 association. When the SA expires, all keys negotiated under 523 the association must be renegotiated. The life 524 type values are: 526 RESERVED 0 527 seconds 1 528 kilobytes 2 529 Values 3-61439 are reserved to IANA. Values 61440-65535 are 530 for private use. For a given Life Type, the value of the 531 Life Duration attribute defines the actual length of the 532 component lifetime -- either a number of seconds, or a number 533 of Kbytes that can be protected. 535 If unspecified, the default value shall be assumed to be 536 28800 seconds (8 hours). 538 An SA Life Duration attribute MUST always follow an SA Life 539 Type which describes the units of duration. 541 Group Description 543 Specifies the Oakley Group to be used in a PFS QM 544 negotiation. For a list of supported values, see Appendix A 545 of [RFC2409]. 547 Authentication Algorithm 548 RESERVED 0 549 HMAC-MD5 1 550 HMAC-SHA 2 551 DES-MAC 3 552 KPDK 4 554 Values 5-61439 are reserved to IANA. Values 61440-65535 are 555 for private use. 557 The default value for the Auth Algorithm is HMAC-MD5. 559 3.5.1Required Attribute Support 561 To ensure basic interoperability, all implementations MUST be 562 prepared to negotiate all of the following attributes. 564 SA Life Type 565 SA Duration 566 Auth Algorithm 568 3.5.2Attribute Parsing Requirement (Lifetime) 570 To allow for flexible semantics, the RSVP DOI requires that a 571 conforming ISAKMP implementation MUST correctly parse an attribute 572 list that contains multiple instances of the same attribute class, 573 so long as the different attribute entries do not conflict with one 574 another. Currently, the only attributes which requires this 575 treatment are Life Type and Duration. 577 To see why this is important, the following example shows the binary 578 encoding of a four entry attribute list that specifies an SA 579 Lifetime of either 100MB or 24 hours. (See Section 3.3 of [RFC2408] 580 for a complete description of the attribute encoding format.) 582 Attribute #1: 583 0x80010001 (AF = 1, type = SA Life Type, value = seconds) 585 Attribute #2: 586 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 587 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) 589 Attribute #3: 590 0x80010002 (AF = 1, type = SA Life Type, value = KB) 592 Attribute #4: 593 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 594 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) 596 If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED 597 Notification Payload SHOULD be returned and the security association 598 setup MUST be aborted. 600 Note that this is the same treatment as suggested in [RFC2407]. 602 3.5.3 Attribute Negotiation 604 If an implementation receives a defined RSVP DOI attribute (or 605 attribute value) which it does not support, an ATTRIBUTES-NOT- 606 SUPPORT SHOULD be sent and the security association setup MUST be 607 aborted, unless the attribute value is in the reserved range. 609 If an implementation receives an attribute value in the reserved 610 range, an implementation MAY choose to continue based on local 611 policy. 613 3.5.4 Lifetime Notification 615 When an initiator offers an SA lifetime greater than what the 616 responder desires based on their local policy, the responder has 617 three choices: 619 1) fail the negotiation entirely; 621 2) complete the negotiation but use a shorter lifetime than what was 622 offered; 624 3) complete the negotiation and send an advisory notification to the 625 initiator indicating the responder's true lifetime. The choice of 626 what the responder actually does is implementation specific 627 and/or based on local policy. 629 To ensure interoperability in the latter case, the RSVP DOI requires 630 the following only when the responder wishes to notify the 631 initiator: if the initiator offers an SA lifetime longer than the 632 responder is willing to accept, the responder SHOULD include an 633 ISAKMP Notification Payload in the exchange that includes the 634 responder's SA payload. Section 3.6.2.1 defines the payload layout 635 for the RESPONDER-LIFETIME Notification Message type which MUST be 636 used for this purpose. 638 3.6 RSVP DOI Payload Content 640 The following sections describe those ISAKMP payloads whose data 641 representations are dependent on the applicable DOI. 643 RSVP DOI does not require any additional payloads. In particular it 644 is not required to exchange Traffic Selector attributes within IKE 645 Phase II as part of the Identification payload. The attributes used 646 in the Phase I Identification payload are sufficient. 648 3.6.1 Identification Payload Content 650 The initiator of the negotiation is identified using the 651 Identification Payload. The responder SHOULD use the initiator's 652 identity to determine the correct security policy for creating SAs. 654 During Phase 1, the ID port and protocol fields MUST be set to zero 655 or to the UDP port that the RSVP DOI is running on. If an 656 implementation receives any other values, this MUST be treated as an 657 error and the negotiation MUST be aborted. 659 The following diagram illustrates the content of the Identification 660 Payload. 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 ! Next Payload ! RESERVED ! Payload Length ! 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 ! ID Type ! Protocol ID ! Port ! 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 ~ Identification Data ~ 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Figure 2: Identification Payload Format 673 The Identification Payload fields are defined as follows: 675 o Next Payload (1 octet) - Identifier for the type of the next 676 payload in the message. If the current payload is the last in 677 the message, this field will be zero (0). 679 o RESERVED (1 octet) - Unused, must be zero (0). 681 o Payload Length (2 octets) - Length, in octets, of the 682 identification data, including the generic header. 684 o Identification Type (1 octet) - Value describing the identity 685 information found in the Identification Data field. 687 o Protocol ID (1 octet) - Value specifying an associated 688 Transport Layer Protocol ID (e.g. UDP/TCP). Value zero means 689 that the Protocol ID field should be ignored. If raw IP is used 690 then this value is set to zero. RSVP also allows UDP to be used. 692 o Port (2 octets) - Value specifying an associated port. A value 693 of zero means that the Port field should be ignored. If raw IP is 694 used with RSVP then the concept of a port is not used. 696 o Identification Data (variable length) - Value, as indicated by 697 the Identification Type. 699 The legal Identification Type field values in Phase 1 are as 700 defined in [IPSDOI]. The table lists the assigned values for the 701 Identification Type field found in the Identification 702 Payload. 704 ID Type Value 705 ------- ----- 706 RESERVED 0 707 ID_IPV4_ADDR 1 708 ID_FQDN 2 709 ID_USER_FQDN 3 710 ID_IPV4_ADDR_SUBNET 4 711 ID_IPV6_ADDR 5 712 ID_IPV6_ADDR_SUBNET 6 713 ID_IPV4_ADDR_RANGE 7 714 ID_IPV6_ADDR_RANGE 8 715 ID_DER_ASN1_DN 9 716 ID_DER_ASN1_GN 10 717 ID_KEY_ID 11 719 The values of the individual Identification Types are described in 720 Section 5.6.2.1 of [RFC2407]. 722 3.6.2 RSVP DOI Notify Message Types 723 ISAKMP defines two blocks of Notify Message codes, one for errors 724 and one for status messages. ISAKMP also allocates a portion of each 725 block for private use within a DOI. The RSVP DOI defines the 726 following private message types for its own use. 728 Notify Messages - Error Types Value 729 ----------------------------- ----- 730 RESERVED 8192 732 Notify Messages - Status Types Value 733 ------------------------------ ----- 734 RESPONDER-LIFETIME 24576 735 INITIAL-CONTACT 24578 737 Notification Status Messages MUST be sent under the protection of an 738 ISAKMP SA: either as a payload in the last Main Mode exchange; in a 739 separate Informational Exchange after Main Mode or Aggressive Mode 740 processing is complete; or as a payload in any Quick Mode exchange. 741 These messages MUST NOT be sent in Aggressive Mode exchange, since 742 Aggressive Mode does not provide the necessary protection to bind 743 the Notify Status Message to the exchange. 745 Note that a Notify payload is fully protected only in Quick Mode, 746 where the entire payload is included in the HASH(n) digest. In Main 747 Mode, while the notify payload is encrypted, it is not currently 748 included in the HASH(n) digests. As a result, an active substitution 749 attack on the Main Mode ciphertext could cause the notify status 750 message type to be corrupted. (This is true, in general, for the 751 last message of any Main Mode exchange.) While the risk is small, a 752 corrupt notify message might cause the receiver to abort the entire 753 negotiation thinking that the sender encountered a fatal error. 754 Implementation Note: the ISAKMP protocol does not guarantee delivery 755 of Notification Status messages when sent in an ISAKMP Informational 756 Exchange. To ensure receipt of any particular message, the sender 757 SHOULD include a Notification Payload in a defined Main Mode or 758 Quick Mode exchange which is protected by a retransmission timer. 760 3.6.2.1 RESPONDER-LIFETIME 762 The RESPONDER-LIFETIME status message may be used to communicate the 763 SA lifetime chosen by the responder. 765 When present, the Notification Payload MUST have the following 766 format: 768 o Payload Length - set to length of payload + size of data (var) 769 o DOI - set to RSVP DOI (TBD) 770 o Protocol ID - set to selected Protocol ID from chosen SA 771 o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP 772 cookies) or four (4) (one SPI) 773 o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) 774 o SPI - set to the two ISAKMP cookies or to the sender's inbound 775 SPI 776 o Notification Data - contains an ISAKMP attribute list with the 777 responder's actual SA lifetime(s) 779 Implementation Note: saying that the Notification Data field 780 contains an attribute list is equivalent to saying that the 781 Notification Data field has zero length and the Notification Payload 782 has an associated attribute list. 784 3.6.2.2 INITIAL-CONTACT 786 The INITIAL-CONTACT status message may be used when one side wishes 787 to inform the other that this is the first SA being established with 788 the remote system. The receiver of this Notification Message might 789 then elect to delete any existing SA's it has for the sending system 790 under the assumption that the sending system has rebooted and no 791 longer has access to the original SA's and their associated keying 792 material. When used, the content of the Notification Data field 793 SHOULD be null (i.e. the Payload Length should be set to the fixed 794 length of Notification Payload). 796 When present, the Notification Payload MUST have the following 797 format: 799 o Payload Length - set to length of payload + size of data (0) 800 o DOI - set to RSVP DOI (TBD) 801 o Protocol ID - set to selected Protocol ID from chosen SA 802 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 803 o Notify Message Type - set to INITIAL-CONTACT 804 o SPI - set to the two ISAKMP cookies 805 o Notification Data - 807 4. Security Considerations 809 This entire memo pertains to the Internet Key Exchange protocol 810 ([RFC2409]), which combines ISAKMP ([RFC2408]) and Oakley 811 ([RFC2412]) to provide for the derivation of cryptographic keying 812 material in a secure and authenticated manner. Specific discussion 813 of the various security protocols and transforms identified in this 814 document can be found in the associated base documents and in the 815 cipher references. 817 Additional security requirements, threats, framework issues and 818 discussion regarding authorizations cannot be discussed within this 819 document. 821 5. IANA Considerations 823 This document contains many "magic" numbers to be maintained by the 824 IANA. 826 A future version of the document will contain a list of the required 827 numbers. 829 6. Key Derivation 831 The RSVP Integrity object requires keying material with can either 832 be procedure by IKE or KINK or other authentication and key exchange 833 protocols supporting the Domain of Interpretation framework. For IKE 834 the key derivation procedure defined in Section 5.5 of [RFC2409] is 835 used. For KINK the key derivation procedure described in Section 8 836 of [TV03] is applicable. 838 7. Open Issues 840 A number of open issues have been identified. Some of these issues 841 result from the fact that reusing of RSVP within NSIS is under 842 investigation. 844 - This document tries to reuse the security of RSVP (namely the RSVP 845 Integrity object) without modifications. Currently RSVP only 846 supports data origin authentication, integrity protection and replay 847 detection based on the RSVP Integrity object. Steve Bellovin 848 expressed interest in adding support for confidentiality protection 849 at the 55th IETF. Confidentiality protection is not included in this 850 document since it would require a new RSVP security object. For this 851 version of the document no parameter negotiation for confidentiality 852 protection is therefore provided. 854 - The Keyed Message Digest field is variable in length but must be a 855 multiple of four octets. The truncated HMAC-SHA-1-96 or the HMAC- 856 MD5-96 does not work with this restriction. Furthermore, it might be 857 desirable specify other integrity algorithms such as RIPEMD-160. 859 - Currently no compression profiles are defined for usage with RSVP. 860 It seems that no such profile is required. 862 - The REPLAY-STATUS notification is not required since replay 863 protection is mandatory. However, in cases of multicast and in case 864 of selective object protection between non-neighboring RSVP nodes it 865 might need to be introduced. This version of the document does not 866 address the security of multicast RSVP signaling messages. 868 - The Identification payload contains the same values as [RFC2407]. 869 It remains for further study whether it might be possible to limit 870 the list. 872 8. References 874 [TK03] H. Tschofenig and D. Kroeselberg: "Security Threats for 875 NSIS", Internet Draft, Internet Engineering Task Force, March 2003. 876 Work in progress. 878 [Tsc03] H. Tschofenig: "RSVP Security Properties", Internet Draft, 879 Internet Engineering Task Force, March 2003. Work in progress. 881 [RFC2408] D. Maughan, M. Schertler, M. Schneider and J. Turner: 882 "Internet Security Association and Key Managment Protocol (ISAKMP)", 883 RFC 2408, November 1998. 885 [RFC2407] D. Piper: "The Internet IP Security Domain of 886 Interpretation for ISAKMP", RFC 2407, November 1998. 888 [RFC2367] D. McDonald, C. Metz, and B. Phan: "PF_KEY key 889 management API, version 2", RFC 2367, Internet Engineering Task 890 Force, July 1998. 892 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 893 "Resource ReSerVation protocol (RSVP) -- version 1 functional 894 specification", RFC 2205, Internet Engineering Task Force, Sept. 895 1997. 897 [TV03] M. Thomas and J. Vilhuber: "Kerberized Internet Negotiation 898 of Keys (KINK)", Internet Draft, Internet Engineering Task Force, 899 Jan. 2003. 901 [Bru03] M. Brunner: "Requirements for QoS signaling protocols", 902 Internet Draft, Internet Engineering Task Force, March 2003. Work in 903 progress. 905 [HF+03] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney and S. 906 Van den Bosch: "Next Steps in Signaling: Framework", Internet Draft, 907 Internet Engineering Task Force, March 2003. Work in progress. 909 [RFC2113] D. Katz: "IP router alert option", RFC 2113, Internet 910 Engineering Task Force, Feb. 1997. 912 [RFC2409] D. Harkins and D. Carrel: "The Internet Key Exchange 913 (IKE)", RFC 2409, Internet Engineering Task Force, Nov. 1998. IKE 915 [RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, and 916 S. Molendini: "RSVP refresh overhead reduction extensions," RFC 917 2961, Internet Engineering Task Force, Apr. 2001. 919 [RFC2104] H. Krawczyk, M. Bellare, and R. Canetti: "HMAC: Keyed- 920 Hashing for Message Authentication", RFC 2104, March 1996. 922 [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, 923 April 1995. 924 http://csrc.nist.gov/fips/fip180-1.txt (ascii) 925 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 927 [RFC2408] D. Maughan, M. Schertler, M. Schneider and J. Turner: 928 "Internet Security Association and Key Management Protocol 929 (ISAKMP)", RFC 2408, Internet Engineering Task Force, November 930 1998. 932 [RFC2412] H. Orman: "The OAKLEY Key Determination Protocol", RFC 933 2412, Internet Engineering Task Force, November 1998. 935 [RFC3232] J. Reynolds: "Assigned Numbers: RFC 1700 is Replaced by 936 an On-line Database", RFC 3232, Internet Engineering Task Force, 937 Jan. 2002. 939 [RFC2747] F. Baker, B. Lindell and M. Talwar: "RSVP Cryptographic 940 Authentication", RC 2747, Internet Engineering Task Force, January, 941 2000. 943 [RFC3182] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. 944 Herzog and R., Hess: "Identity Representation for RSVP", RFC 3182, 945 Internet Engineering Task Force, October, 2001. 947 [RFC2119] S. Bradner: "Key words for use in RFCs to Indicate 948 Requirement Levels", RFC 2119, Internet Engineering Task Force, 949 March 1997. 951 [TB+03] H. Tschofenig, M. Buechli, S. Van den Bosch and H. 952 Schulzrinne: "NSIS Authentication, Authorization and Accounting 953 Issues", , (work in 954 progress), March, 2003. 956 [RFC2093] H. Harney and C. Muckenhirn: "Group Key Management 957 Protocol (GKMP) Specification", RFC 2093, Internet Engineering Task 958 Force, July 1997. 960 [IETF56] J. Loughney: "NSIS IETF 56 Agenda / Starting NTLP Work", in 961 "Proceedings of the Fifty-sixth IETF Meeting"; San Francisco, CA, 962 March 16-21, 2003 ", available at: 963 http://www.ietf.org/proceedings/03mar/slides/nsis-0/sld6.htm 964 9. Acknowledgments 966 This document is largely based on [RFC2407] and hence we would like 967 to thank the author Derrell Piper and the IETF members, which 968 provided input to RFC 2407, for their work. 970 Additionally we would like to thank Jorge Cuellar for his comments 971 to this version of the draft. 973 10. Author's Addresses 975 Hannes Tschofenig 976 Siemens AG 977 Otto-Hahn-Ring 6 978 81739 Munich 979 Germany 980 EMail: Hannes.Tschofenig@siemens.com 982 Henning Schulzrinne 983 Dept. of Computer Science 984 Columbia University 985 1214 Amsterdam Avenue 986 New York, NY 10027 987 USA 988 EMail: schulzrinne@cs.columbia.edu 990 Full Copyright Statement 992 Copyright (C) The Internet Society (2001). All Rights Reserved. 993 This document and translations of it may be copied and furnished to 994 others, and derivative works that comment on or otherwise explain it 995 or assist in its implementation may be prepared, copied, published 996 and distributed, in whole or in part, without restriction of any 997 kind, provided that the above copyright notice and this paragraph 998 are included on all such copies and derivative works. However, this 999 document itself may not be modified in any way, such as by removing 1000 the copyright notice or references to the Internet Society or other 1001 Internet organizations, except as needed for the purpose of 1002 developing Internet standards in which case the procedures for 1003 copyrights defined in the Internet Standards process must be 1004 followed, or as required to translate it into languages other than 1005 English. 1007 The limited permissions granted above are perpetual and will not be 1008 revoked by the Internet Society or its successors or assigns. 1010 This document and the information contained herein is provided on an 1011 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1012 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1013 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1014 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1015 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.