idnits 2.17.1 draft-weis-gdoi-for-rsvp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2008) is 5900 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) ** Obsolete normative reference: RFC 3547 (Obsoleted by RFC 6407) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-00 -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC Working Group B. Weis 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track February 22, 2008 5 Expires: August 25, 2008 7 Group Domain of Interpretation (GDOI) support for RSVP 8 draft-weis-gdoi-for-rsvp-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 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/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 25, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This memo describes the policy required for the Group Domain of 42 Interpretation (GDOI) group key management system to distribute 43 security policy for RSVP. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 50 2. GDOI Operations . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. SA TEK payload for RSVP . . . . . . . . . . . . . . . . . . . 6 53 3.1. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 7 54 3.2. Sequence Number Types . . . . . . . . . . . . . . . . . . 7 55 3.3. Optional Attributes . . . . . . . . . . . . . . . . . . . 7 57 4. Key Packet definition for RSVP . . . . . . . . . . . . . . . . 8 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . . . 14 72 1. Introduction 74 The Group Domain of Interpretation (GDOI) is a group key management 75 protocol fitting into the Multicast Security Group Key Management 76 Architecture . GDOI is used to disseminate group security policy and 77 keying material to group members for use with a particular 78 cryptographic system. 80 The RSVP protocol provides a means for establishing resource 81 reservations between cooperating systems. To ensure the integrity of 82 the associated reservation and admission control mechanisms, the RSVP 83 Authentication mechanisms defined in [RFC2747] and [RFC3097] may be 84 used. These protect RSVP message integrity hop-by-hop and provide 85 node authentication as well as replay protection, thereby protecting 86 against corruption and spoofing of RSVP messages. 88 [RFC2747] discusses several approaches for key distribution. First, 89 the RSVP Authentication shared keys can be distributed manually. 90 This is the base option and its support is mandated for any 91 implementation. However, in some environments, this approach may 92 become a burden if keys frequently change over time. Alternatively, 93 a standard key management protocol for secure shared key distribution 94 can be used. However, existing shared key distribution protocols may 95 not be appropriate in all environments because of the complexity or 96 operational burden they involve. In effect, this impedes the 97 practical use of RSVP Authentication. 99 Another issue with RSVP Authentication is that shared key cannot be 100 used among RSVP routers when those are interconnected via routers 101 that do not run RSVP. This is because, in this situation, an RSVP 102 router does not always know the RSVP next hop for an RSVP message at 103 the time of forwarding it. 105 Such limitations with the current RSVP security mechanisms are 106 further discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 108 Since RSVP nodes effectively acts as a group of cooperating systems, 109 they can benefit from sharing the same keying material. 110 [I-D.ietf-tsvwg-rsvp-security-groupkeying] presents a framework for 111 RSVP security using dynamic group keying and discusses its 112 applicability. In line with this framework, the present document 113 describes extension to GDOI for distribution of security policy and 114 keying material for RSVP. 116 1.1. Requirements notation 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. GDOI Operations 124 The GDOI group key management protocol [RFC3547]) actively manages 125 keys for a set of group members. In the case of RSVP, the set of 126 group members belonging to a single group are routers and/or hosts 127 that are trusted to establish reservations for a set of applications, 128 and also trust the other group members to act appropriately within 129 the group (e.g., not to spoof other group members). A given group 130 need not include all of the RSVP nodes passing a reservation. For 131 example, the group may be comprised of routers in a single ISP, where 132 the RSVP packets are protected using a different model between ISPs. 133 Similarly, different groups may be used for different sets of RSVP 134 nodes. Whether or not the group key is used and which RSVP nodes 135 belong to a given group should depend on the trust model between the 136 co-operating systems. 138 GDOI begins operation when group members "register" to a GDOI key 139 server using the GDOI GROUPKEY_PULL protocol. The key server first 140 authenticates and authorizes each group member. GDOI also derives 141 encryption keys shrared privately between the key server and the 142 group member. These keys are used to protect the group policy and 143 keying material as it is distributed to the group member. In the 144 case of RSVP, the group policy consists of policy and keying material 145 intended for use with the [RFC2747] [RFC3097] INTEGRITY Option. 147 The GDOI key server also distributes policy and keys that describe 148 how it will distribute updates to group policy in a "rekey" message, 149 also known as the GDOI GROUPKEY_PUSH message. Rekey messages are 150 typically distributed as IP multicast packets. They provide 151 replacement RSVP policy and keying material (e.g., when RSVP keys 152 expire) or to remove (i.e., revoke) group members in a non-disruptive 153 manner. 155 Both the GDOI registration and GDOI rekey protocols distribute 156 cryptosystem policy in an SA TEK payload. Each SA TEK payload 157 describes a particular type of cryptographic system policy, and this 158 memo describes a new type for the RSVP INTEGRITY Option. Keying 159 material is distributed in KD payload Key Packets. This memo 160 describes how those keys are distributed for the RSVP INTEGRITY 161 Option. 163 3. SA TEK payload for RSVP 165 RFC 2747 describes a number of policy items that make up an RSVP 166 security association. When a centralized group key management system 167 such as GDOI is used, the same RSVP policy is distributed to all 168 group members. The following SA TEK payload distributes this policy. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 173 ! Key Identifier ! 174 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 175 ! ! MAC Algorithm ! Seq. Num. Type! 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 177 ! Key Lifetime ! 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 179 ! Optional Attributes ~ 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 182 The SA TEK Payload fields are defined as follows: 184 o Key Identifier (6 octets) -- Value describing the identity of the 185 key. The group member will use this value as the Key Identifier 186 in the RFC 2747 INTEGRITY Object. The key identifier will 187 uniquely define the particular key distributed in the KD payload. 189 o MAC Algorithm (1 octet) -- Value specifying which Message 190 Authentication Code (MAC) is used to generate the Keyed Message 191 Digest field of the RFC 2747 INTEGRITY Object . MAC Algorithm 192 types are defined below. Values are defined in the IANA 193 Considerations section. 195 o Sequence Number Type (1 octet) -- Value specifying how the 196 sequence number field is constructed. Sequence Number Types are 197 defined below. Values are defined in the IANA Considerations 198 section. 200 o Key Lifetime (4 octets) -- Value specifying the remaining lifetime 201 of the SA TEK, in seconds. If the KeyStartValid optional 202 attribute is included in the SA TEK, this lifetime specifies the 203 entire lifetime of the SA TEK. Otherwise, it represents the 204 partial remaining lifetime. 206 o Optional Attributes (Variable) -- Optional TLV attributes, as 207 defined below. 209 3.1. MAC Algorithm 211 The following MAC algorithms are defined for use with this TEK. 213 o HMAC-MD5. The MD5 algorithm used with an HMAC construction 214 [RFC2104]. This MAC algorithm is considered weak, but is required 215 by a conforming RFC 2747 implementation. 217 o HMAC-SHA1. The SHA1 algorithm used with an HMAC construction 218 [RFC2104]. 220 3.2. Sequence Number Types 222 The following methods of constructing sequence numbers is defined for 223 use with this TEK. 225 o COUNTER. This corresponds to the Simple Sequence Numbers method 226 defined in Section 3.1 of RFC 2747. When COUNTER based sequence 227 numbers are used, each group member maintains its own sequence 228 number for a given group in order to set the sequence number field 229 in RSVP messages generated in this group. Therefore, an RSVP 230 receiver MUST track received sequence numbers separately for each 231 RSVP neighbour in order to reliably distinguish between new and 232 replay messages. 234 o TIME. This corresponds to the Sequence Numbers Based on a Real 235 Time Clock method described in Section 3.2 of RFC 2747 or the 236 Sequence Numbers Based on a Network Recovered Clock method 237 described in Section 3.3 or RFC 2747. 239 3.3. Optional Attributes 241 The following attributes may be present in the TEK Payload. The 242 attributes must follow the format defined in ISAKMP [RFC2408] Section 243 3.3. In the table, attributes that are defined as TV are marked as 244 Basic (B); attributes that are defined as TLV are marked as Variable 245 (V). Values are defined in the IANA Considerations section. 247 o KeyStartValid (V). This attribute specifies an real time in the 248 future when the TEK will take effect [RFC2747]. Note that the 249 corresponding KeyEndValid time defined in RFC 2747 is not 250 distributed by GDOI, but is computed by adding the Key Lifetime 251 value to KeyStartValid. The KeyStartValid value is represented as 252 the number of seconds since since 0 hours, 0 minutes, 0 seconds, 253 January 1, 1970. 255 4. Key Packet definition for RSVP 257 Keying material for the RSVP INTEGRITY Option is distributed in a Key 258 Packet as part of the GDOI KD payload. The Key packet is formed as 259 follows. 261 o KD Type. The type of KD MUST be TEK. 263 o SPI. The Key Identifier is placed in the SPI field. 265 o Key. The keying material for the MAC algorithm is placed in a 266 TEK_INTEGRITY_KEY attribute. 268 The Key Packet MUST NOT contain a TEK_ALGORITHM_KEY or 269 TEK_SOURCE_AUTH_KEY attribute. 271 5. IANA Considerations 273 A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned 274 from the RESERVED space. The new algorithm id should be called 275 GDOI_PROTO_RSVP_INTEGRITY, and refers to the INTEGRITY Object defined 276 in [RFC2747]. 278 Terms describing policies for allocating new name space types below 279 are defined in [RFC2434]. 281 The following MAC Algorithms are defined as a part of this memo. 283 MAC Algorithm Type Value 284 ------------------ ----- 285 RESERVED 0 286 HMAC-MD5 1 287 HMAC-SHA1 2 288 Standards Action 3-127 289 Private Use 128-255 291 The following Sequence Number Types are defined as a part of this 292 memo. 294 Sequence Number Type Value 295 -------------------- ----- 296 RESERVED 0 297 COUNTER 1 298 TIME 2 299 Standards Action 3-127 300 Private Use 128-255 302 The following Optional Attributes are defined as part of this memo. 304 Optional Attribute Value 305 ------------------ ----- 306 RESERVED 0 307 KeyStartValid 1 308 Standards Action 2-127 309 Private Use 128-255 311 6. Security Considerations 313 This memo describes the passing of policy and keying material used by 314 an RSVP speaker to produce an RFC 2747 INTEGRITY Object. This policy 315 and keying material is protected by the GDOI protocol described in 316 [RFC3547]. The security considerations in that memo apply fully to 317 this memo as well. 319 7. Acknowledgements 321 Francois Le Faucheur originated the idea of using GDOI for RSVP. He 322 also provided text for the Introduction section summarizing key 323 distribution issues with RSVP message integrity. 325 8. References 327 8.1. Normative References 329 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 330 Authentication", RFC 2747, January 2000. 332 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 333 Authentication -- Updated Message Type Value", RFC 3097, 334 April 2001. 336 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 337 Group Domain of Interpretation", RFC 3547, July 2003. 339 8.2. Informative References 341 [GDOI-REG] 342 Internet Assigned Numbers Authority, "Group Domain of 343 Interpretation (GDOI) Payload Type Values", IANA Registry, 344 December 2004, 345 . 347 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 348 Behringer, M. and F. Faucheur, "Applicability of Keying 349 Methods for RSVP Security", 350 draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in 351 progress), November 2007. 353 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 354 Hashing for Message Authentication", RFC 2104, 355 February 1997. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 361 Security Association and Key Management Protocol 362 (ISAKMP)", RFC 2408, November 1998. 364 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 365 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 366 October 1998. 368 Author's Address 370 Brian Weis 371 Cisco Systems 372 170 W. Tasman Drive 373 San Jose, California 95134-1706 374 USA 376 Phone: +1-408-526-4796 377 Email: bew@cisco.com 379 Full Copyright Statement 381 Copyright (C) The IETF Trust (2008). 383 This document is subject to the rights, licenses and restrictions 384 contained in BCP 78, and except as set forth therein, the authors 385 retain all their rights. 387 This document and the information contained herein are provided on an 388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 390 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 391 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 392 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 Intellectual Property 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org. 419 Acknowledgment 421 Funding for the RFC Editor function is provided by the IETF 422 Administrative Support Activity (IASA).