idnits 2.17.00 (12 Aug 2021) /tmp/idnits18432/draft-tschofenig-rsvp-doi-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 2003) is 6786 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 684, 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) -- 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 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 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-01.txt 8 Expires: April 2002 October 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..................................3 52 2. Terminology................................................4 53 3. Definition.................................................4 54 3.1 Naming Scheme...........................................4 55 3.2 Situation Definition....................................4 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.................................5 60 3.3.1.2 Policy Issues........................................6 61 3.3.1.3 Certificate Management...............................6 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.........................................7 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..............................................8 68 3.4.3 RSVP Integrity Transform Identifiers..................8 69 3.4.3.1 AUTH_MD5............................................10 70 3.4.3.2 AUTH_SHA............................................10 71 3.4.3.3 AUTH_DES............................................10 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...............................13 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.....................................16 82 4. Security Considerations...................................17 83 5. IANA Considerations.......................................17 84 6. Key Derivation............................................18 85 7. Open Issues...............................................18 86 8. Normative References......................................18 87 9. Informative References....................................20 88 10. Acknowledgments...........................................20 89 11. Author's Addresses........................................21 91 1. Introduction 93 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. With this extension 103 administrators have the choice between manual RSVP security 104 establishment (see [RFC2205]) and dynamic authentication and key 105 exchange based on shared secrets, Kerberos or public key based 106 authentication. 108 A detailed discussion of security properties of RSVP is referred to 109 [Tsc03]. This document tries to follow the current NSIS working 110 group documents with regard to their requirements and framework 111 thoughts (see [HF+03] and [Bru03]). Additionally security threats 112 relevant for NSIS are applicable to this work (see [TK03]). 114 The basic procedure for establishing an RSVP security association 115 can be described as follows: 117 Whenever an RSVP signaling message has to be sent to the next RSVP 118 aware node and no security association is already available then a 119 new one has to be dynamically established. RSVP therefore triggers 120 the key management daemon. The RSVP daemon then constructs a RSVP 121 message and interacts with the security association database using 122 some sort of API (e.g. PF_KEY [RFC2367]) to retrieve the session key 123 and other security parameters. Maintenance (creation, deletion, 124 rekeying, possibly dead peer detection, etc.) of the RSVP security 125 association is accomplished by the key management daemon. KINK 126 [TV03], which uses Kerberos, can also be used as an authentication 127 and key exchange protocol in addition to IKE. 129 Note that this draft is strongly aligned with [RFC2407] and reuses 130 the same structure and (if appropriate) the same text. 132 1.2 Requirements for a DOI 134 Within ISAKMP, a Domain of Interpretation is used to group related 135 protocols using ISAKMP to negotiate security associations. Security 136 protocols sharing a DOI choose security protocol and cryptographic 137 transforms from a common namespace and share key exchange protocol 138 identifiers. They also share a common interpretation of DOI- 139 specific payload data content, including the Security Association 140 and Identification payloads. 142 Overall, ISAKMP places the following requirements on a DOI 143 definition: 145 o define the naming scheme for DOI-specific protocol identifiers 146 o define the interpretation for the Situation field 147 o define the set of applicable security policies 148 o define the syntax for DOI-specific SA Attributes (Phase II) 149 o define the syntax for DOI-specific payload contents 150 o define additional Key Exchange types, if needed 151 o define additional Notification Message types, if needed 153 The remainder of this document describes the instantiation of these 154 requirements for using the RSVP Security mechanism specified in 155 [RFC2747] to provide authentication, integrity and replay 156 protection. 158 2. Terminology 160 This document does not introduce new terms. 162 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 163 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 164 document, are to be interpreted as described in [RFC2119]. 166 3. Definition 168 3.1 Naming Scheme 170 Within ISAKMP, all DOI's must be registered with the IANA in the 171 "Assigned Numbers" RFC [RFC3232]. The IANA Assigned Number for the 172 RSVP DOI is TBD (TBD). Within the RSVP DOI, all well-known 173 identifiers MUST be registered with the IANA under the RSVP DOI. 174 Unless otherwise noted, all tables within this document refer to 175 IANA Assigned Numbers for the RSVP DOI. See Section 5 for further 176 information relating to the IANA registry for the RSVP DOI. 178 All multi-octet binary values are stored in network byte order. 180 3.2 Situation Definition 182 Within ISAKMP, the Situation provides information that can be used 183 by the responder to make a policy determination about how to process 184 the incoming Security Association request. For the RSVP DOI, the 185 Situation field is a four (4) octet bitmask with the following 186 values. 188 Situation Value 189 --------- ----- 190 SIT_IDENTITY_ONLY 0x01 192 3.2.1 SIT_IDENTITY_ONLY 194 The SIT_IDENTITY_ONLY type specifies that the security association 195 will be identified by source identity information present in an 196 associated Identification Payload. See Section 4.6.2 of [RFC2407] 197 for a complete description of the various Identification types. All 198 RSVP DOI implementations MUST support SIT_IDENTITY_ONLY by including 199 an Identification Payload in at least one of the Phase I Oakley 200 exchanges ([RFC2409], Section 5) and MUST abort any association 201 setup that does not include an Identification Payload. 203 3.3 Security Policy Requirements 205 The RSVP DOI does not impose specific security policy requirements 206 on any implementation. Host system policy issues are outside of the 207 scope of this document. 209 However, the following sections touch on some of the issues that 210 must be considered when designing an RSVP DOI implementation. This 211 section should be considered only informational in nature. 213 3.3.1 Key Management Issues 215 It is expected that many systems choosing to implement ISAKMP will 216 strive to provide a protected domain of execution for a combined IKE 217 key management daemon. On protected-mode multi-user operating 218 systems, this key management daemon will likely exist as a separate 219 privileged process. 221 In such an environment, a formalized API such as PF_KEY [RFC2367] to 222 communicate keying material (and other security relevant parameters) 223 between the RSVP Daemon, the key management daemon and the key 224 engine may be desirable. 226 3.3.1.1 Static Keying Issues 228 Systems that implement static keys, either for use directly by RSVP, 229 or for authentication purposes (see [RFC2409] Section 5.4), should 230 take steps to protect the static keying material when it is not 231 residing in a protected memory domain or actively in use by the key 232 engine. 234 Depending on the operating system and utility software installed, it 235 may not be possible to protect the static keys once they are 236 available to the keying engine or to the RSVP daemon, however they 237 should not be trivially recoverable on initial system startup 238 without having to satisfy some additional form of authentication. 240 3.3.1.2 Policy Issues 242 It is not realistic to assume that the transition to RSVP DOI will 243 occur overnight. Incremental deployment is, however, possible 244 particularly in intra-domain environments. Systems must be prepared 245 to implement flexible policy lists that describe which systems they 246 desire to speak securely with and which systems they require speak 247 securely to them. This type of authorization behavior particularly 248 addresses intra-domain environments where a strong trust 249 relationship between individual RSVP nodes exists. 251 A minimal approach is probably a static list of IP addresses. For 252 intra-domain communication such an approach might be sufficient in 253 many cases due to the nature of RSVP signaling. A more flexible 254 approach based on wildcard DNS names is given below and might 255 simplify and reduce configuration overhead. 257 For inter-domain environments the authorization procedure must 258 provide some mapping to an authorized identity for which a financial 259 settlement between the interacting domains exist. For inter-domain 260 environments it seems to be more appropriate not to use static lists 261 of IP addresses. A more flexible implementation might consist of a 262 list of wildcard DNS names (e.g. '*.foo.bar'). The wildcard DNS name 263 would be used to match incoming or outgoing IP addresses. 265 The communication between end systems and the attached network is 266 more difficult from an authorization point of view. The reader is 267 referred to a detailed discussion in [TB+03a] and in [TB+03b]. For 268 this version of the document RSVP DOI mainly addresses intra-domain 269 and inter-domain communication instead of end host to network 270 communication due to the authorization nature of QoS signaling 271 protocols. A future version of the document might address these 272 issues (and for non-QoS signaling applications) in an appropriate 273 manner. 275 3.3.1.3 Certificate Management 277 Systems implementing a certificate-based authentication scheme will 278 need a mechanism for obtaining and managing a database of 279 certificates. 281 Secure DNS is to be one certificate distribution mechanism, however 282 the pervasive availability of secure DNS zones, in the short term, 283 is doubtful for many reasons. This is primarily applicable for 284 inter-domain communication. For intra-domain environments secure DNS 285 might be a reasonable choice. 287 The ability for RSVP nodes to import certificates that they acquire 288 through secure, out-of-band mechanisms, is also a reasonable 289 procedure. 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. 295 In addition to certificate-based authentication and the distribution 296 of pre-shared secrets between nodes for the purpose of 297 authentication, Kerberos might be used. KINK [TV03] uses Kerberos 298 and as such a trusted third party entity for authentication and key 299 distribution. KINK replaces the first phase of IKE and represents a 300 very efficient and fast alternative to IKE Phase I. Systems 301 implementing the RSVP DOI SHOULD support this DOI using KINK. 303 3.4 RSVP DOI assigned numbers 305 The following sections list the Assigned Numbers for the RSVP DOI: 306 Situation Identifiers, Protocol Identifiers, Transform Identifiers, 307 Security Association Attribute Type Values, Labeled Domain 308 Identifiers, ID Payload Type Values, and Notify Message Type Values. 310 3.4.1 RSVP DOI Security Protocol Identifier 312 The ISAKMP proposal syntax was specifically designed to allow for 313 the simultaneous negotiation of multiple Phase II security protocol 314 suites within a single negotiation. As a result, the protocol suites 315 listed below form the set of protocols that can be negotiated at the 316 same time. It is a host policy decision as to what protocol suites 317 might be negotiated together. 319 Protocol ID Value 320 ----------- ----- 321 RESERVED 0 322 PROTO_ISAKMP 1 323 PROTO_RSVP_Integrity 2 325 All other values unused. 327 3.4.1.1 PROTO_ISAKMP 329 The PROTO_ISAKMP type specifies message protection required during 330 Phase I of the ISAKMP protocol. The specific protection mechanism 331 used for the RSVP DOI is described in [RFC2409]. All implementations 332 within the RSVP DOI MUST support PROTO_ISAKMP. 334 NB: ISAKMP reserves the value one (1) across all DOI definitions. 336 3.4.1.2 PROTO_RSVP_Integrity 338 The PROTO_RSVP_Integrity type provides the necessary parameters for 339 the security association used in RSVP (i.e. the RSVP Integrity 340 Object [RFC2747]). This transform provides data origin 341 authentication, integrity protection and replay detection. 343 Transforms for confidentiality protection are currently not defined. 344 Support for confidentiality protection is currently not provided 345 although useful. Furthermore, transforms providing payload 346 compression do not seem to be useful for a signaling protocol due to 347 the fact that other mechanisms have been standardized which provide 348 similar techniques in a more efficient way (see [RFC2961]). 350 3.4.2 RSVP ISAKMP Transform Identifiers 352 As part of an ISAKMP Phase I negotiation, the initiator's choice of 353 Key Exchange offerings is made using some host system policy 354 description. The actual selection of Key Exchange mechanism is made 355 using the standard ISAKMP Proposal Payload. The following table 356 lists the defined ISAKMP Phase I Transform Identifiers for the 357 Proposal Payload for the RSVP DOI. 359 Transform Value 360 --------- ----- 361 RESERVED 0 362 KEY_IKE 1 364 Within the ISAKMP and RSVP DOI framework it is possible to define 365 key establishment protocols other than IKE (Oakley). Previous 366 versions of this document defined types both for manual keying and 367 for schemes based on use of a generic Key Distribution Center (KDC). 368 These identifiers have been removed from the current document. 370 Extension of the RSVP DOI to include values for additional non- 371 Oakley key establishment protocols (such as the Group Key Management 372 Protocol (GKMP) [RFC2093]) is under consideration. 374 3.4.2.1 KEY_IKE 376 The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman 377 key exchange (IKE) as defined in the [RFC2409] document. All 378 implementations within the RSVP DOI MUST support KEY_IKE. 380 3.4.3 RSVP Integrity Transform Identifiers 381 The RSVP Integrity Object provides data origin authentication, 382 integrity, and replay detection. It consists of the following 383 fields: 385 - Flags 387 The Handshake Flag is the only defined flag and is used to 388 synchronize sequence numbers if the communication gets out-of-sync. 389 The separately defined mechanism is not required. Hence the Flags 390 are set to zero. 392 - Key Identifier 394 The Key Identifier selects the key used for verification of the 395 Keyed Message Digest field. Its length is fixed with 48-bit. 396 According to [RFC2747] is the generation of this Key Identifier 397 field mostly a local decision. 399 The 32-bit SPI field will be used to select the security association 400 for verifying the keyed message digest. Hence the first 32 bit of 401 the 48-bit Key Identifier are the SPI and the last 16 bit are set to 402 zero. 404 - Sequence Number 406 [RFC2747] defines the sequence number used by the RSVP Integrity 407 object as a 64-bit value for which the starting value can be 408 selected arbitrarily. To prevent the need to communicate the 409 sequence number the sequence number MUST start with zero for usage 410 with this protocol. 412 - Keyed Message Digest 414 This field contains the keyed message digest and is a variable 415 length field. 417 The following table lists the defined RSVP Integrity Transform 418 Identifiers for the ISAKMP Proposal Payload for the RSVP DOI. 420 Note: the Authentication Algorithm attribute MUST be specified to 421 identify the appropriate protection suite. For example, AUTH_MD5 can 422 best be thought of as a generic AH transform using MD5. To request 423 the HMAC construction with AUTH, one specifies the AUTH_MD5 424 transform ID along with the Authentication Algorithm attribute set 425 to HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in 426 the following sections. 428 Transform ID Value 429 ------------ ----- 430 RESERVED 0-1 431 AUTH_MD5 2 432 AUTH_SHA 3 433 AUTH_DES 4 435 Note: all mandatory-to-implement algorithms are listed as "MUST" 436 implement (e.g. AUTH_MD5) in the following sections. All other 437 algorithms are optional and MAY be implemented in any particular 438 implementation. 440 3.4.3.1 AUTH_MD5 442 The AUTH_MD5 type specifies a generic AUTH transform using MD5. The 443 actual protection suite is determined in concert with an associated 444 SA attribute list. A generic MD5 transform is currently undefined. 446 All implementations within the RSVP DOI MUST support AUTH_MD5 along 447 with the Auth(HMAC-MD5) attribute. HMAC-MD5 is described in 448 [RFC2104]. 450 Use of AUTH_MD5 with any other Authentication Algorithm attribute 451 value is currently undefined. 453 3.4.3.2 AUTH_SHA 455 The AUTH_SHA type specifies a generic AUTH transform using SHA-1. 456 The actual protection suite is determined in concert with an 457 associated SA attribute list. A generic SHA transform is currently 458 undefined. 460 All implementations within the RSVP DOI MUST support AUTH_SHA along 461 with the Auth(HMAC-SHA) attribute. SHA-1 is described in [SHA1]. 463 Use of AH_SHA with any other Authentication Algorithm attribute 464 value is currently undefined. 466 3.4.3.3 AUTH_DES 468 The AUTH_DES type specifies a generic AUTH transform using DES. The 469 actual protection suite is determined in concert with an associated 470 SA attribute list. A generic DES transform is currently undefined. 472 The RSVP DOI defines AUTH_DES along with the Auth(DES-MAC) attribute 473 to be a DES-MAC transform. Implementations are not required to 474 support this mode. 476 Use of AUTH_DES with any other Authentication Algorithm attribute 477 value is currently undefined. 479 3.5 RSVP Security Association Attributes 481 The following SA attribute definitions are used in Phase II of an 482 IKE negotiation. Attribute types can be either Basic (B) or 483 Variable-Length (V). Encoding of these attributes is defined in the 484 base ISAKMP specification. 486 Attributes described as basic MUST NOT be encoded as variable. 487 Variable length attributes MAY be encoded as basic attributes if 488 their value can fit into two octets. See [RFC2409] for further 489 information on attribute encoding in the RSVP DOI. All restrictions 490 listed in [RFC2409] also apply to the RSVP DOI. 492 Attribute Types 494 class value type 495 ------------------------------------------------- 496 SA Life Type 1 B 497 SA Life Duration 2 V 498 Group Description 3 B 499 Authentication Algorithm 4 B 501 Class Values 503 SA Life Type 504 SA Duration 506 Specifies the time-to-live for the overall security 507 association. When the SA expires, all keys negotiated under 508 the association must be renegotiated. The life 509 type values are: 511 RESERVED 0 512 seconds 1 513 kilobytes 2 515 Values 3-61439 are reserved to IANA. Values 61440-65535 are 516 for private use. For a given Life Type, the value of the 517 Life Duration attribute defines the actual length of the 518 component lifetime -- either a number of seconds, or a number 519 of Kbytes that can be protected. 521 If unspecified, the default value shall be assumed to be 522 28800 seconds (8 hours). 524 An SA Life Duration attribute MUST always follow an SA Life 525 Type which describes the units of duration. 527 Group Description 528 Specifies the Oakley Group to be used in a PFS QM 529 negotiation. For a list of supported values, see Appendix A 530 of [RFC2409]. 532 Authentication Algorithm 533 RESERVED 0 534 HMAC-MD5 1 535 HMAC-SHA 2 536 DES-MAC 3 537 KPDK 4 539 Values 5-61439 are reserved to IANA. Values 61440-65535 are 540 for private use. 542 The default value for the Auth Algorithm is HMAC-MD5. 544 3.5.1 Required Attribute Support 546 To ensure basic interoperability, all implementations MUST be 547 prepared to negotiate all of the following attributes. 549 SA Life Type 550 SA Duration 551 Auth Algorithm 553 3.5.2 Attribute Parsing Requirement (Lifetime) 555 To allow for flexible semantics, the RSVP DOI requires that a 556 conforming ISAKMP implementation MUST correctly parse an attribute 557 list that contains multiple instances of the same attribute class, 558 so long as the different attribute entries do not conflict with one 559 another. Currently, the only attributes which requires this 560 treatment are Life Type and Duration. 562 To see why this is important, the following example shows the binary 563 encoding of a four entry attribute list that specifies an SA 564 Lifetime of either 100MB or 24 hours. (See Section 3.3 of [RFC2408] 565 for a complete description of the attribute encoding format.) 567 Attribute #1: 568 0x80010001 (AF = 1, type = SA Life Type, value = seconds) 570 Attribute #2: 571 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 572 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) 574 Attribute #3: 575 0x80010002 (AF = 1, type = SA Life Type, value = KB) 577 Attribute #4: 578 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) 579 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) 581 If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED 582 Notification Payload SHOULD be returned and the security association 583 setup MUST be aborted. 585 Note that this is the same treatment as suggested in [RFC2407]. 587 3.5.3 Attribute Negotiation 589 If an implementation receives a defined RSVP DOI attribute (or 590 attribute value) which it does not support, an ATTRIBUTES-NOT- 591 SUPPORT SHOULD be sent and the security association setup MUST be 592 aborted, unless the attribute value is in the reserved range. 594 If an implementation receives an attribute value in the reserved 595 range, an implementation MAY choose to continue based on local 596 policy. 598 3.5.4 Lifetime Notification 600 When an initiator offers an SA lifetime greater than what the 601 responder desires based on their local policy, the responder has 602 three choices: 604 1) fail the negotiation entirely; 606 2) complete the negotiation but use a shorter lifetime than what was 607 offered; 609 3) complete the negotiation and send an advisory notification to the 610 initiator indicating the responder's true lifetime. The choice of 611 what the responder actually does is implementation specific 612 and/or based on local policy. 614 To ensure interoperability in the latter case, the RSVP DOI requires 615 the following only when the responder wishes to notify the 616 initiator: if the initiator offers an SA lifetime longer than the 617 responder is willing to accept, the responder SHOULD include an 618 ISAKMP Notification Payload in the exchange that includes the 619 responder's SA payload. Section 3.6.2.1 defines the payload layout 620 for the RESPONDER-LIFETIME Notification Message type which MUST be 621 used for this purpose. 623 3.6 RSVP DOI Payload Content 624 The following sections describe those ISAKMP payloads whose data 625 representations are dependent on the applicable DOI. 627 RSVP DOI does not require any additional payloads. In particular it 628 is not required to exchange Traffic Selector attributes within IKE 629 Phase II as part of the Identification payload. The attributes used 630 in the Phase I Identification payload are sufficient. 632 3.6.1 Identification Payload Content 634 The initiator of the negotiation is identified using the 635 Identification Payload. The responder SHOULD use the initiator's 636 identity to determine the correct security policy for creating SAs. 638 During Phase 1, the ID port and protocol fields MUST be set to zero 639 or to the UDP port that the RSVP DOI is running on. If an 640 implementation receives any other values, this MUST be treated as an 641 error and the negotiation MUST be aborted. 643 The following diagram illustrates the content of the Identification 644 Payload. 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 ! Next Payload ! RESERVED ! Payload Length ! 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 ! ID Type ! Protocol ID ! Port ! 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 ~ Identification Data ~ 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Figure 2: Identification Payload Format 657 The Identification Payload fields are defined as follows: 659 o Next Payload (1 octet) - Identifier for the type of the next 660 payload in the message. If the current payload is the last in 661 the message, this field will be zero (0). 663 o RESERVED (1 octet) - Unused, must be zero (0). 665 o Payload Length (2 octets) - Length, in octets, of the 666 identification data, including the generic header. 668 o Identification Type (1 octet) - Value describing the identity 669 information found in the Identification Data field. 671 o Protocol ID (1 octet) - Value specifying an associated 672 Transport Layer Protocol ID (e.g. UDP/TCP). Value zero means 673 that the Protocol ID field should be ignored. If raw IP is used 674 then this value is set to zero. RSVP also allows UDP to be used. 676 o Port (2 octets) - Value specifying an associated port. A value 677 of zero means that the Port field should be ignored. If raw IP is 678 used with RSVP then the concept of a port is not used. 680 o Identification Data (variable length) - Value, as indicated by 681 the Identification Type. 683 The legal Identification Type field values in Phase 1 are as 684 defined in [IPSDOI]. The table lists the assigned values for the 685 Identification Type field found in the Identification 686 Payload. 688 ID Type Value 689 ------- ----- 690 RESERVED 0 691 ID_IPV4_ADDR 1 692 ID_FQDN 2 693 ID_USER_FQDN 3 694 ID_IPV4_ADDR_SUBNET 4 695 ID_IPV6_ADDR 5 696 ID_IPV6_ADDR_SUBNET 6 697 ID_IPV4_ADDR_RANGE 7 698 ID_IPV6_ADDR_RANGE 8 699 ID_DER_ASN1_DN 9 700 ID_DER_ASN1_GN 10 701 ID_KEY_ID 11 703 The values of the individual Identification Types are described in 704 Section 5.6.2.1 of [RFC2407]. 706 3.6.2 RSVP DOI Notify Message Types 708 ISAKMP defines two blocks of Notify Message codes, one for errors 709 and one for status messages. ISAKMP also allocates a portion of each 710 block for private use within a DOI. The RSVP DOI defines the 711 following private message types for its own use. 713 Notify Messages - Error Types Value 714 ----------------------------- ----- 715 RESERVED 8192 717 Notify Messages - Status Types Value 718 ------------------------------ ----- 719 RESPONDER-LIFETIME 24576 720 INITIAL-CONTACT 24578 722 Notification Status Messages MUST be sent under the protection of an 723 ISAKMP SA: either as a payload in the last Main Mode exchange; in a 724 separate Informational Exchange after Main Mode or Aggressive Mode 725 processing is complete; or as a payload in any Quick Mode exchange. 726 These messages MUST NOT be sent in Aggressive Mode exchange, since 727 Aggressive Mode does not provide the necessary protection to bind 728 the Notify Status Message to the exchange. 730 Note that a Notify payload is fully protected only in Quick Mode, 731 where the entire payload is included in the HASH(n) digest. In Main 732 Mode, while the notify payload is encrypted, it is not currently 733 included in the HASH(n) digests. As a result, an active substitution 734 attack on the Main Mode ciphertext could cause the notify status 735 message type to be corrupted. (This is true, in general, for the 736 last message of any Main Mode exchange.) While the risk is small, a 737 corrupt notify message might cause the receiver to abort the entire 738 negotiation thinking that the sender encountered a fatal error. 739 Implementation Note: the ISAKMP protocol does not guarantee delivery 740 of Notification Status messages when sent in an ISAKMP Informational 741 Exchange. To ensure receipt of any particular message, the sender 742 SHOULD include a Notification Payload in a defined Main Mode or 743 Quick Mode exchange which is protected by a retransmission timer. 745 3.6.2.1 RESPONDER-LIFETIME 747 The RESPONDER-LIFETIME status message may be used to communicate the 748 SA lifetime chosen by the responder. 750 When present, the Notification Payload MUST have the following 751 format: 753 o Payload Length - set to length of payload + size of data (var) 754 o DOI - set to RSVP DOI (TBD) 755 o Protocol ID - set to selected Protocol ID from chosen SA 756 o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP 757 cookies) or four (4) (one SPI) 758 o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) 759 o SPI - set to the two ISAKMP cookies or to the sender's inbound 760 SPI 761 o Notification Data - contains an ISAKMP attribute list with the 762 responder's actual SA lifetime(s) 764 Implementation Note: saying that the Notification Data field 765 contains an attribute list is equivalent to saying that the 766 Notification Data field has zero length and the Notification Payload 767 has an associated attribute list. 769 3.6.2.2 INITIAL-CONTACT 770 The INITIAL-CONTACT status message may be used when one side wishes 771 to inform the other that this is the first SA being established with 772 the remote system. The receiver of this Notification Message might 773 then elect to delete any existing SA's it has for the sending system 774 under the assumption that the sending system has rebooted and no 775 longer has access to the original SA's and their associated keying 776 material. When used, the content of the Notification Data field 777 SHOULD be null (i.e. the Payload Length should be set to the fixed 778 length of Notification Payload). 780 When present, the Notification Payload MUST have the following 781 format: 783 o Payload Length - set to length of payload + size of data (0) 784 o DOI - set to RSVP DOI (TBD) 785 o Protocol ID - set to selected Protocol ID from chosen SA 786 o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) 787 o Notify Message Type - set to INITIAL-CONTACT 788 o SPI - set to the two ISAKMP cookies 789 o Notification Data - 791 4. Security Considerations 793 This entire memo pertains to the Internet Key Exchange protocol 794 [RFC2409], which combines ISAKMP [RFC2408] and Oakley [RFC2412] to 795 provide for the derivation of cryptographic keying material in a 796 secure manner. Specific discussion of the various security protocols 797 and transforms identified in this document can be found in the 798 indicated documents. 800 It is important to mention that this document is based on the 801 assumption that two RSVP nodes know each other already before they 802 exchange RSVP messages (and therefore knows which security parameter 803 to select). Unfortunately this is not true for all scenarios. Thus 804 in these cases where this assumption does not hold it is not 805 possible to use this mechanisms directly. This assumption mainly 806 addresses the nature of PATH alike signaling messages (i.e. messages 807 which are addressed to the end host and carry a Router Alert Option 808 [RFC2113]). 810 Security requirements, threats, framework issues and authorization 811 aspects are found in separate documents (see [TK03], [HF+03], 812 [TB+03a] and [TB+03b]). 814 5. IANA Considerations 816 This document contains many "magic" numbers to be maintained by the 817 IANA. 819 A future version of the document will contain a list of the required 820 numbers. 822 6. Key Derivation 824 The RSVP Integrity object requires keying material with can either 825 be procedure by IKE or KINK or other authentication and key exchange 826 protocols supporting the Domain of Interpretation framework. For IKE 827 the key derivation procedure defined in Section 5.5 of [RFC2409] is 828 used. For KINK the key derivation procedure described in Section 8 829 of [TV03] is applicable. 831 7. Open Issues 833 A number of open issues have been identified. Some of these issues 834 result from the fact that reusing of RSVP within NSIS is under 835 investigation. 837 - This document tries to reuse the security of RSVP (namely the RSVP 838 Integrity object) without modifications. Currently RSVP only 839 supports data origin authentication, integrity protection and replay 840 detection based on the RSVP Integrity object. Steve Bellovin 841 expressed interest in adding support for confidentiality protection 842 at the 55th IETF. Confidentiality protection is not included in this 843 document since it would require a new RSVP security object. For this 844 version of the document no parameter negotiation for confidentiality 845 protection is therefore provided. 847 - The Keyed Message Digest field is variable in length but must be a 848 multiple of four octets. The truncated HMAC-SHA-1-96 or the HMAC- 849 MD5-96 does not work with this restriction. Furthermore, it might be 850 desirable specify other integrity algorithms such as RIPEMD-160. 852 - Currently no compression profiles are defined for usage with RSVP. 853 It seems that no such profile is required. 855 - The REPLAY-STATUS notification is not required since replay 856 protection is mandatory. However, in cases of multicast and in case 857 of selective object protection between non-neighboring RSVP nodes it 858 might need to be introduced. This version of the document does not 859 address the security of multicast RSVP signaling messages. 861 - The Identification payload contains the same values as [RFC2407]. 862 It remains for further study whether it might be possible to limit 863 the list. 865 8. Normative References 867 [TK03] H. Tschofenig and D. Kroeselberg: "Security Threats for 868 NSIS", Internet Draft, Internet Engineering Task Force, June 2003. 869 Work in progress. 871 [Tsc03] H. Tschofenig: "RSVP Security Properties", Internet Draft, 872 Internet Engineering Task Force, March 2003. Work in progress. 874 [RFC2408] D. Maughan, M. Schertler, M. Schneider and J. Turner: 875 "Internet Security Association and Key Managment Protocol (ISAKMP)", 876 RFC 2408, November 1998. 878 [RFC2407] D. Piper: "The Internet IP Security Domain of 879 Interpretation for ISAKMP", RFC 2407, November 1998. 881 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 882 "Resource ReSerVation protocol (RSVP) -- version 1 functional 883 specification", RFC 2205, Internet Engineering Task Force, Sept. 884 1997. 886 [TV03] M. Thomas and J. Vilhuber: "Kerberized Internet Negotiation 887 of Keys (KINK)", Internet Draft, Internet Engineering Task Force, 888 Jan. 2003. 890 [Bru03] M. Brunner: "Requirements for QoS signaling protocols", 891 Internet Draft, Internet Engineering Task Force, August 2003. Work 892 in progress. 894 [RFC2409] D. Harkins and D. Carrel: "The Internet Key Exchange 895 (IKE)", RFC 2409, Internet Engineering Task Force, Nov. 1998. IKE 897 [RFC2104] H. Krawczyk, M. Bellare, and R. Canetti: "HMAC: Keyed- 898 Hashing for Message Authentication", RFC 2104, March 1996. 900 [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, 901 April 1995. 902 http://csrc.nist.gov/fips/fip180-1.txt (ascii) 903 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 905 [RFC2408] D. Maughan, M. Schertler, M. Schneider and J. Turner: 906 "Internet Security Association and Key Management Protocol 907 (ISAKMP)", RFC 2408, Internet Engineering Task Force, November 1998. 909 [RFC2412] H. Orman: "The OAKLEY Key Determination Protocol", RFC 910 2412, Internet Engineering Task Force, November 1998. 912 [RFC3232] J. Reynolds: "Assigned Numbers: RFC 1700 is Replaced by 913 an On-line Database", RFC 3232, Internet Engineering Task Force, 914 Jan. 2002. 916 [RFC2747] F. Baker, B. Lindell and M. Talwar: "RSVP Cryptographic 917 Authentication", RC 2747, Internet Engineering Task Force, January, 918 2000. 920 [RFC2119] S. Bradner: "Key words for use in RFCs to Indicate 921 Requirement Levels", RFC 2119, Internet Engineering Task Force, 922 March 1997. 924 9. Informative References 926 [RFC2367] D. McDonald, C. Metz, and B. Phan: "PF_KEY key 927 management API, version 2", RFC 2367, Internet Engineering Task 928 Force, July 1998. 930 [TB+03a] H. Tschofenig, M. Buechli, S. Van den Bosch and H. 931 Schulzrinne: "NSIS Authentication, Authorization and Accounting 932 Issues", Internet Draft, Internet Engineering Task Force, March 933 2003. Work in progress. 935 [TB+03b] H. Tschofenig, M. Buechli, S. Van den Bosch, H. 936 Schulzrinne and T. Chen: "QoS NSLP Authorization Issues", Internet 937 Draft, Internet Engineering Task Force, June 2003. Work in progress. 939 [RFC2093] H. Harney and C. Muckenhirn: "Group Key Management 940 Protocol (GKMP) Specification", RFC 2093, Internet Engineering Task 941 Force, July 1997. 943 [HF+03] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney and S. 944 Van den Bosch: "Next Steps in Signaling: Framework", Internet Draft, 945 Internet Engineering Task Force, September 2003. Work in progress. 947 [RFC2113] D. Katz: "IP router alert option", RFC 2113, Internet 948 Engineering Task Force, Feb. 1997. 950 [RFC3182] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. 951 Herzog and R., Hess: "Identity Representation for RSVP", RFC 3182, 952 Internet Engineering Task Force, October, 2001. 954 [RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, and 955 S. Molendini: "RSVP refresh overhead reduction extensions," RFC 956 2961, Internet Engineering Task Force, Apr. 2001. 958 10. Acknowledgments 960 This document is largely based on [RFC2407] and hence we would like 961 to thank the author Derrell Piper and the IETF members, which 962 provided input to RFC 2407, for their work. 964 Additionally, we would like to thank Jorge Cuellar and Gerald 965 Volkmann for their comments to the draft. 967 11. Author's Addresses 969 Hannes Tschofenig 970 Siemens AG 971 Otto-Hahn-Ring 6 972 81739 Munich 973 Germany 974 EMail: Hannes.Tschofenig@siemens.com 976 Henning Schulzrinne 977 Dept. of Computer Science 978 Columbia University 979 1214 Amsterdam Avenue 980 New York, NY 10027 981 USA 982 EMail: schulzrinne@cs.columbia.edu 984 Full Copyright Statement 986 Copyright (C) The Internet Society (2001). All Rights Reserved. 987 This document and translations of it may be copied and furnished to 988 others, and derivative works that comment on or otherwise explain it 989 or assist in its implementation may be prepared, copied, published 990 and distributed, in whole or in part, without restriction of any 991 kind, provided that the above copyright notice and this paragraph 992 are included on all such copies and derivative works. However, this 993 document itself may not be modified in any way, such as by removing 994 the copyright notice or references to the Internet Society or other 995 Internet organizations, except as needed for the purpose of 996 developing Internet standards in which case the procedures for 997 copyrights defined in the Internet Standards process must be 998 followed, or as required to translate it into languages other than 999 English. 1001 The limited permissions granted above are perpetual and will not be 1002 revoked by the Internet Society or its successors or assigns. 1004 This document and the information contained herein is provided on an 1005 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1006 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1007 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1008 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1009 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.