MSEC Working Group B. Weis Internet-Draft Cisco Systems Intended status: Standards Track February 22, 2008 Expires: August 25, 2008 Group Domain of Interpretation (GDOI) support for RSVP draft-weis-gdoi-for-rsvp-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Weis Expires August 25, 2008 [Page 1]
Internet-Draft GDOI-RSVP February 2008 Abstract This memo describes the policy required for the Group Domain of Interpretation (GDOI) group key management system to distribute security policy for RSVP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. GDOI Operations . . . . . . . . . . . . . . . . . . . . . . . 5 3. SA TEK payload for RSVP . . . . . . . . . . . . . . . . . . . 6 3.1. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Sequence Number Types . . . . . . . . . . . . . . . . . . 7 3.3. Optional Attributes . . . . . . . . . . . . . . . . . . . 7 4. Key Packet definition for RSVP . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Weis Expires August 25, 2008 [Page 2]
Internet-Draft GDOI-RSVP February 2008 1. Introduction The Group Domain of Interpretation (GDOI) is a group key management protocol fitting into the Multicast Security Group Key Management Architecture . GDOI is used to disseminate group security policy and keying material to group members for use with a particular cryptographic system. The RSVP protocol provides a means for establishing resource reservations between cooperating systems. To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097] may be used. These protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. [RFC2747] discusses several approaches for key distribution. First, the RSVP Authentication shared keys can be distributed manually. This is the base option and its support is mandated for any implementation. However, in some environments, this approach may become a burden if keys frequently change over time. Alternatively, a standard key management protocol for secure shared key distribution can be used. However, existing shared key distribution protocols may not be appropriate in all environments because of the complexity or operational burden they involve. In effect, this impedes the practical use of RSVP Authentication. Another issue with RSVP Authentication is that shared key cannot be used among RSVP routers when those are interconnected via routers that do not run RSVP. This is because, in this situation, an RSVP router does not always know the RSVP next hop for an RSVP message at the time of forwarding it. Such limitations with the current RSVP security mechanisms are further discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Since RSVP nodes effectively acts as a group of cooperating systems, they can benefit from sharing the same keying material. [I-D.ietf-tsvwg-rsvp-security-groupkeying] presents a framework for RSVP security using dynamic group keying and discusses its applicability. In line with this framework, the present document describes extension to GDOI for distribution of security policy and keying material for RSVP. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Weis Expires August 25, 2008 [Page 3]
Internet-Draft GDOI-RSVP February 2008 document are to be interpreted as described in [RFC2119]. Weis Expires August 25, 2008 [Page 4]
Internet-Draft GDOI-RSVP February 2008 2. GDOI Operations The GDOI group key management protocol [RFC3547]) actively manages keys for a set of group members. In the case of RSVP, the set of group members belonging to a single group are routers and/or hosts that are trusted to establish reservations for a set of applications, and also trust the other group members to act appropriately within the group (e.g., not to spoof other group members). A given group need not include all of the RSVP nodes passing a reservation. For example, the group may be comprised of routers in a single ISP, where the RSVP packets are protected using a different model between ISPs. Similarly, different groups may be used for different sets of RSVP nodes. Whether or not the group key is used and which RSVP nodes belong to a given group should depend on the trust model between the co-operating systems. GDOI begins operation when group members "register" to a GDOI key server using the GDOI GROUPKEY_PULL protocol. The key server first authenticates and authorizes each group member. GDOI also derives encryption keys shrared privately between the key server and the group member. These keys are used to protect the group policy and keying material as it is distributed to the group member. In the case of RSVP, the group policy consists of policy and keying material intended for use with the [RFC2747] [RFC3097] INTEGRITY Option. The GDOI key server also distributes policy and keys that describe how it will distribute updates to group policy in a "rekey" message, also known as the GDOI GROUPKEY_PUSH message. Rekey messages are typically distributed as IP multicast packets. They provide replacement RSVP policy and keying material (e.g., when RSVP keys expire) or to remove (i.e., revoke) group members in a non-disruptive manner. Both the GDOI registration and GDOI rekey protocols distribute cryptosystem policy in an SA TEK payload. Each SA TEK payload describes a particular type of cryptographic system policy, and this memo describes a new type for the RSVP INTEGRITY Option. Keying material is distributed in KD payload Key Packets. This memo describes how those keys are distributed for the RSVP INTEGRITY Option. Weis Expires August 25, 2008 [Page 5]
Internet-Draft GDOI-RSVP February 2008 3. SA TEK payload for RSVP RFC 2747 describes a number of policy items that make up an RSVP security association. When a centralized group key management system such as GDOI is used, the same RSVP policy is distributed to all group members. The following SA TEK payload distributes this policy. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Key Identifier ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! MAC Algorithm ! Seq. Num. Type! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Key Lifetime ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Optional Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The SA TEK Payload fields are defined as follows: o Key Identifier (6 octets) -- Value describing the identity of the key. The group member will use this value as the Key Identifier in the RFC 2747 INTEGRITY Object. The key identifier will uniquely define the particular key distributed in the KD payload. o MAC Algorithm (1 octet) -- Value specifying which Message Authentication Code (MAC) is used to generate the Keyed Message Digest field of the RFC 2747 INTEGRITY Object . MAC Algorithm types are defined below. Values are defined in the IANA Considerations section. o Sequence Number Type (1 octet) -- Value specifying how the sequence number field is constructed. Sequence Number Types are defined below. Values are defined in the IANA Considerations section. o Key Lifetime (4 octets) -- Value specifying the remaining lifetime of the SA TEK, in seconds. If the KeyStartValid optional attribute is included in the SA TEK, this lifetime specifies the entire lifetime of the SA TEK. Otherwise, it represents the partial remaining lifetime. o Optional Attributes (Variable) -- Optional TLV attributes, as defined below. Weis Expires August 25, 2008 [Page 6]
Internet-Draft GDOI-RSVP February 2008 3.1. MAC Algorithm The following MAC algorithms are defined for use with this TEK. o HMAC-MD5. The MD5 algorithm used with an HMAC construction [RFC2104]. This MAC algorithm is considered weak, but is required by a conforming RFC 2747 implementation. o HMAC-SHA1. The SHA1 algorithm used with an HMAC construction [RFC2104]. 3.2. Sequence Number Types The following methods of constructing sequence numbers is defined for use with this TEK. o COUNTER. This corresponds to the Simple Sequence Numbers method defined in Section 3.1 of RFC 2747. When COUNTER based sequence numbers are used, each group member maintains its own sequence number for a given group in order to set the sequence number field in RSVP messages generated in this group. Therefore, an RSVP receiver MUST track received sequence numbers separately for each RSVP neighbour in order to reliably distinguish between new and replay messages. o TIME. This corresponds to the Sequence Numbers Based on a Real Time Clock method described in Section 3.2 of RFC 2747 or the Sequence Numbers Based on a Network Recovered Clock method described in Section 3.3 or RFC 2747. 3.3. Optional Attributes The following attributes may be present in the TEK Payload. The attributes must follow the format defined in ISAKMP [RFC2408] Section 3.3. In the table, attributes that are defined as TV are marked as Basic (B); attributes that are defined as TLV are marked as Variable (V). Values are defined in the IANA Considerations section. o KeyStartValid (V). This attribute specifies an real time in the future when the TEK will take effect [RFC2747]. Note that the corresponding KeyEndValid time defined in RFC 2747 is not distributed by GDOI, but is computed by adding the Key Lifetime value to KeyStartValid. The KeyStartValid value is represented as the number of seconds since since 0 hours, 0 minutes, 0 seconds, January 1, 1970. Weis Expires August 25, 2008 [Page 7]
Internet-Draft GDOI-RSVP February 2008 4. Key Packet definition for RSVP Keying material for the RSVP INTEGRITY Option is distributed in a Key Packet as part of the GDOI KD payload. The Key packet is formed as follows. o KD Type. The type of KD MUST be TEK. o SPI. The Key Identifier is placed in the SPI field. o Key. The keying material for the MAC algorithm is placed in a TEK_INTEGRITY_KEY attribute. The Key Packet MUST NOT contain a TEK_ALGORITHM_KEY or TEK_SOURCE_AUTH_KEY attribute. Weis Expires August 25, 2008 [Page 8]
Internet-Draft GDOI-RSVP February 2008 5. IANA Considerations A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned from the RESERVED space. The new algorithm id should be called GDOI_PROTO_RSVP_INTEGRITY, and refers to the INTEGRITY Object defined in [RFC2747]. Terms describing policies for allocating new name space types below are defined in [RFC2434]. The following MAC Algorithms are defined as a part of this memo. MAC Algorithm Type Value ------------------ ----- RESERVED 0 HMAC-MD5 1 HMAC-SHA1 2 Standards Action 3-127 Private Use 128-255 The following Sequence Number Types are defined as a part of this memo. Sequence Number Type Value -------------------- ----- RESERVED 0 COUNTER 1 TIME 2 Standards Action 3-127 Private Use 128-255 The following Optional Attributes are defined as part of this memo. Optional Attribute Value ------------------ ----- RESERVED 0 KeyStartValid 1 Standards Action 2-127 Private Use 128-255 Weis Expires August 25, 2008 [Page 9]
Internet-Draft GDOI-RSVP February 2008 6. Security Considerations This memo describes the passing of policy and keying material used by an RSVP speaker to produce an RFC 2747 INTEGRITY Object. This policy and keying material is protected by the GDOI protocol described in [RFC3547]. The security considerations in that memo apply fully to this memo as well. Weis Expires August 25, 2008 [Page 10]
Internet-Draft GDOI-RSVP February 2008 7. Acknowledgements Francois Le Faucheur originated the idea of using GDOI for RSVP. He also provided text for the Introduction section summarizing key distribution issues with RSVP message integrity. Weis Expires August 25, 2008 [Page 11]
Internet-Draft GDOI-RSVP February 2008 8. References 8.1. Normative References [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. 8.2. Informative References [GDOI-REG] Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, December 2004, <http://www.iana.org/assignments/gdoi-payloads>. [I-D.ietf-tsvwg-rsvp-security-groupkeying] Behringer, M. and F. Faucheur, "Applicability of Keying Methods for RSVP Security", draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in progress), November 2007. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Weis Expires August 25, 2008 [Page 12]
Internet-Draft GDOI-RSVP February 2008 Author's Address Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-526-4796 Email: bew@cisco.com Weis Expires August 25, 2008 [Page 13]
Internet-Draft GDOI-RSVP February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Weis Expires August 25, 2008 [Page 14]