Network Working Group P. Tran Internet-Draft B. Weis Intended status: Standards Track Cisco Systems Expires: April 26, 2012 October 24, 2011 The Use of G-IKEv2 for Multicast Router Key Management draft-tran-karp-mrmp-00 Abstract The G-IKEv2 key management protocol protects group traffic, usually in the form of IP multicast communications between a set of network devices. G-IKEv2 can be used to protect the communications of routing protocols using a one-to-many or many-to-many communications model. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 26, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Tran & Weis Expires April 26, 2012 [Page 1] Internet-Draft G-IKEv2-MRKM October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Overview of Group Key Management . . . . . . . . . . . . . . . 3 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Header and Payload Formats . . . . . . . . . . . . . . . . . . 6 4.1. Group Security Association Payload . . . . . . . . . . . . 6 4.1.1. GSA TEK Payload . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Tran & Weis Expires April 26, 2012 [Page 2] Internet-Draft G-IKEv2-MRKM October 2011 1. Introduction The G-IKEv2 protocol [I-D.yeung-g-ikev2] has been defined to distribute group policy and keys to a group of network devices. It re-uses IKEv2 protocols, incorporating payloads similar to GDOI [RFC6407]. This memo describes a mode of using G-IKEv2 to protect routing protocols using one-to-many communication models (e.g., OSPF, PIM), and is known as G-IKEv2for Multicast Router Key Management (G-IKEv2-MRKM). 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Overview of Group Key Management When a group of network devices need to communicate using multicast communications, the devices need to share keying material and the policy associated with that keying material. A group key management (GKM) protocol is used to securely distribute this keying material and associated policy. Typically each network device (also known as a group member (GM)) needing to participate in the group "register" to a group controller/key server (GCKS), during which mutual authentication and authorization occur. The GCKS also distributes current group policy and keying material to the group member over an authenticated and encrypted session. When G-IKEv2 is used, this is achieved in four messages: two to setup the encrypted session (identical to the IKEv2 [RFC5996] IKE_INIT protocol, and two to authenticate, authorize, and distribute group policy to the GM (similar in construction to the IKEv2 IKE_AUTH protocol). A GKM protocol typically uses a "rekey" protocol to efficiently distribute replacement keying material and associated policy to GMs. However, this is primarly an optimization for scalability. Because there are likely to be network devices communicating in a routing protocol, this protocol is less desirable. In this memo, we describe how the group can utilize the registration protocol for both initial keying and rekeying purposes. G-IKEv2-MRKM is a GKM use case where a group of network routers participating in a multicast routing protocol act as GMs. The choice of a GCKS is not restricted by this memo, but operationally it is most reliable for one of the GMs to take that role. Tran & Weis Expires April 26, 2012 [Page 3] Internet-Draft G-IKEv2-MRKM October 2011 3. Exchanges The exchange of private keying material between two network devices using a dedicated key management protocol is a common requirement. There is no need to define an entirely new protocol for routing protocols having this requirement when existing mature protocol exchanges and methods have been vetted. This memo makes use of the G-IKEv2 protocol exchanges, state machine, and policy definitions whenever possible. However, as G-IKEv2 was developed exclusively for the use of IPsec, these protocol exchanges are incorporated by reference into the present key protocol definitions, and are exchanged using a different exchange type Group Initial Exchange (GSA_INIT) and Group member Authentication exchange (GSA_AUTH) [I-D.yeung-g-ikev2]. The use of exchange type will clearly differentiate this protocol from IKEv2. The following two exchanges enable the group member to register to the key server to get the policy, traffic selector and keys used to communicate with others group member. The GSA_INIT exchange is a two-message exchange allows the group member and key server devices to negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange [DH]. At the conclusion of the GSA_INIT, the group member (e.g., router) and key server can exchange private messages. For the details of this exchange, refer to IKE_SA_INIT in RFC 5996. Group Member(Initiator) Key Server (Responder) -------------------- ---------------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ,] Next, the group member and key server devices perform a GSA_AUTH, which is substancially the same as the IKE_AUTH exchange defined in RFC 5996, except that the SA, TSi, TSr payloads are not presented as policy and traffic selectors are pushed from the key server to group member using new payloads GSA and KD. The IDg, SEQ, GSA, and KD payloads are described in Section 4 of [I-D.yeung-g-ikev2]; for the details of the rest of the exchange please refer to IKE-AUTH in RFC 5996. Section Section 4 of this document includes additional GSA definitions specifically for the purpose of protecting routing protocol traffic. Tran & Weis Expires April 26, 2012 [Page 4] Internet-Draft G-IKEv2-MRKM October 2011 Group Member (Initiator) Key Server (Responder) -------------------- ---------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, IDg} --> <-- HDR, SK {IDr, [CERT,] AUTH, SEQ], GSA, KD} In the GSA_AUTH exchange, the group member sends the group identification that it wants to join or register to. The key server authenticates and authorizes the group member and pushes the policy, traffic selector in GSA payload, and the key in the KD payload to the group member. At the successful conclusion of the GSA_AUTH exchange, the group member has policy and keying material to securely communicate with others group members that also registered with the key server. With this IKEv2 SA established between GM and KS, the GM can request for policy and keys of an additional group using GSA_PULL exchange. In GSA_PULL exchange, the GM will send group ID that it wants to join, the key server response will include sequence (SEQ), policy (GSA) and key material (KD). Group Member (Initiator) Key Server (Responder) -------------------- ---------------------- HDR, SK {IDg} -- <-- HDR, SK { [ SEQ ], GSA, KD} The group member and key server need to maintain the group association SA (GSA) to further communicate securely or the registration process above need to be repeated. Before the policy and traffic key expired, the key server can use multicast GSA_REKEY message to PUSH the fresh policy and keys to all its group members. This exchange is protected by the KEK policy and key sent from the key server to group member during registration. The key server will include sequence (SEQ), policy (GSA), and keying material (KD) payloads in the rekey message. A rekey message might be necessary if a key lifetime is about to expire, due to concern that a key might have been compromised, or some other reason. Group Member (Initiator) Key Server (Responder) -------------------- ---------------------- <- HDR, SK {SEQ, GSA, KD, AUTH} The KS can delete group member by sending Delete (D) payloads in the GSA_REKEY message . The Delete (D) payloads are defined in Section 4 of [I-D.yeung-g-ikev2]. Group Member (Initiator) Server (Responder) ------------------- ------------------ <-- HDR, SK {[D,] ... , AUTH} Tran & Weis Expires April 26, 2012 [Page 5] Internet-Draft G-IKEv2-MRKM October 2011 4. Header and Payload Formats The protocol defined in this memo uses a HDR identical to that defined in RFC5996. GSA exchange types and payloads described in this section are added to same IANA registry containing G-IKEv2 definitions. 4.1. Group Security Association Payload The Group Security Assocation (GSA) payload contains one or more sets of policy that a router is willing to use to protect a routing protocol. It is identitcal to the GSA payload described in Section 4.3 of [I-D.yeung-g-ikev2]. This memo makes no changes to this payload. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! GSA Attribute Next Payload ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 4.1.1. GSA TEK Payload One of GSA attribute "next payload" types is the Traffic Encryption Key (TEK) payload. The TEK payload describes the Traffic Encryption Policy. This document define new protocol ID of TEK protocol specific payload for routing protocol OSPFv2, OSPFv3 and PIM. Tran & Weis Expires April 26, 2012 [Page 6] Internet-Draft G-IKEv2-MRKM October 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Type ! RESERVED ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Protocol-ID ! TEK Protocol-Specific Payload ! +-+-+-+-+-+-+-+-+ ~ ~ ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Protocol ID Value ----------- ----- RESERVED 0 GSA_PROTO_IPSEC_ESP 1 GSA_PROTO_IPSEC_AH 2 GSA_PROTO_OSPFv2 TBD GSA_PROTO_OSPFv3 TBD GSA_PROTO_PIM TBD 4.1.1.1. TEK OSPFv2 Protocol-Specific Payload TEK OSPFv2 Protocol Specific Payload contains SPI, the authentication algorithm and key lifetime. The TEK OSPF protocol specific payload is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI ! RESERVED | Auth algo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! GSA life Attributes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! SPI - (1 octet) Secure Parameter Index will be used in OSPFv2 header as Key ID (RFC 2328, Appendix D) Auth algo - (2 octets) Authentication Algorithm Keyed-MD5 (defined in RFC 2328, Appendix D) HMAC-SHA-1 (defined in RFC 5709, Section 3) HMAC-SHA-256 (defined in RFC 5709, Section 3) HMAC-SHA-384 (defined in RFC 5709, Section 3) HMAC-SHA-512 (defined in RFC 5709, Section 3) GSA Life Attribute - Key lifetime, define in (draft-yeung-g-ikev2-03, section 4.5) Tran & Weis Expires April 26, 2012 [Page 7] Internet-Draft G-IKEv2-MRKM October 2011 4.1.1.2. TEK OSPFv3 and PIM IPsec Protocol-Specific Payload OSPFv3 and PIM IPSEC protocol specific payload similiar to GIKEv2 TEK payload for ESP and AH. This payload doesn't include the traffic selector as protocol-ID value in the GSA TEK payload already indicate OSPFv3 or PIM traffic. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! | 0 (last) or 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Attributes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ GSA Life Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! SPI (4 octets) - Secure Parameter Index Transform - Same sa G-IKEv2 TEK transform define in (draft-yeung-g-ikev2-03, section 4.5) Where transform type can be 1 (Encryption Algorithm) for ESP and/or 3 (Integrity Algorithm) for AH. Description Trans. Used In Type ---------------------------------------------------------------- Encryption Algorithm (ENCR) 1 ESP Integrity Algorithm (INTEG) 3 AH, optional in ESP Extended Sequence Numbers (ESN) 5 AH and ESP Transform Type 1 (Encryption Algorithm) Name Number Defined In --------------------------------------------------- ENCR_NULL 11 (RFC2410) ENCR_AES_CBC 12 (RFC3602) Transform Type 3 (Integrity Algorithm) Tran & Weis Expires April 26, 2012 [Page 8] Internet-Draft G-IKEv2-MRKM October 2011 Name Number Defined In ---------------------------------------- NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) GSA Life Attribute - Key lifetime, define in (draft-yeung-g-ikev2-03, section 4.5) 5. IANA Considerations TBD 6. Security Considerations This document describes a use case of group key management using G-IKEv2. The security considerations in [I-D.yeung-g-ikev2] directly apply to this memo. 7. Acknowledgements Sam Hartman and Dacheng Zhang previously published the MRKMP protocol [I-D.hartman-karp-mrkmp], which includes many operations and protocol elements in common with this memo. 8. Normative References [I-D.hartman-karp-mrkmp] Hartman, S. and D. Zhang, "Multicast Router Key Management Protocol (MRKMP)", draft-hartman-karp-mrkmp-01 (work in progress), March 2011. [I-D.yeung-g-ikev2] Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key Management using IKEv2", draft-yeung-g-ikev2-03 (work in progress), July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, Tran & Weis Expires April 26, 2012 [Page 9] Internet-Draft G-IKEv2-MRKM October 2011 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011. Authors' Addresses Paulina Tran Cisco Systems 170 Tasman Drive San Jose, California CA USA Phone: +1 (408) 526-8902 Fax: Email: ptran@cisco.com URI: Brian Weis Cisco Systems 170 Tasman Drive San Jose, California CA USA Phone: +1 (408) 526-4796 Fax: Email: bew@cisco.com URI: Tran & Weis Expires April 26, 2012 [Page 10]