Network Working Group P. Tran Internet-Draft B. Weis Intended status: Standards Track Cisco Systems Expires: September 10, 2012 March 9, 2012 The Use of G-IKEv2 for Multicast Router Key Management draft-tran-karp-mrmp-01 Abstract The G-IKEv2 key management protocol protects group traffic, usually in the form of IP multicast communications between a set of network devices. This memo defines extensions to G-IKEv2 allowing it 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 September 10, 2012. Copyright Notice Copyright (c) 2012 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 September 10, 2012 [Page 1] Internet-Draft G-IKEv2-MRKM March 2012 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 . . . . . . . . . . . . . . . . . . 5 4.1. Group Security Association Payload . . . . . . . . . . . . 5 4.1.1. GSA TEK Payload . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Tran & Weis Expires September 10, 2012 [Page 2] Internet-Draft G-IKEv2-MRKM March 2012 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 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-IKEv2 for 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_SA_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 primarily an optimization for scalability. This optimization is less desirable for a small group of routing protocol participants. 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 routing protocol using a multicast transport act as GMs. Which device takes the role of GCKS is not specified by this memo, but operationally it is most reliable for one of the GMs to take that role. Additionally, for routing protocol reliability the routers may require the ability to use redundant key servers and to Tran & Weis Expires September 10, 2012 [Page 3] Internet-Draft G-IKEv2-MRKM March 2012 elect a key server from available group members. This memo does not address redundancy, however the protocols in this memo should be compatible with the redundancy strategy described in [I-D.hartman-karp-mrkmp]. 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 extends the G-IKEv2 protocol exchanges, state machine, and policy definitions. 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 IKE_SA_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 IKE_SA_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 substantially the same as the IKE_AUTH exchange defined in RFC 5996, except that the SA, TSi, TSr payloads in IKE_AUTH are not used. Policy and traffic selectors are pushed from the key server to group member using new payloads GSA and KD. For the details of the rest of the exchange please refer to Section 4 of [I-D.yeung-g-ikev2]. Section Section 4 of this document includes additional GSA definitions specifically for the purpose of protecting routing protocol traffic. Group Member (Initiator) Key Server (Responder) ------------------------ ---------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, IDg} --> <-- HDR, SK {IDr, [CERT,] AUTH, GSA, KD} Tran & Weis Expires September 10, 2012 [Page 4] Internet-Draft G-IKEv2-MRKM March 2012 In the GSA_AUTH exchange, the group member sends the identification of the group to which it wants to join or register. 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 the GSA_CLIENT_SERVER exchange. In the GSA_CLIENT_SERVER exchange, the GM will send group ID that it wants to join, where the key server response will include policy (GSA) and key material (KD). Group Member (Initiator) Key Server (Responder) ------------------------ ---------------------- HDR, SK {IDg} --> <-- HDR, SK { GSA, KD, [D]} Once a GSA_AUTH has completed the group member and key server MAY destroy the G-IKEv2 SA. However when the number of group members is small, as is usually the case for routing protocol participants, it is RECOMMENDED for them to maintain the G-IKEv2 association SA for the key server to notify group members that they should re-register in order to obtain new group policy. This notify exchange replaces a seperate rekey mechanism optimized for large group. In some cases, a GCKS may need to change the group policy and/or rekey before current keys expire. In cases where the G-IKEv2 rekey protocol is not used the GCKS can send an INFORMATIONAL exchange with a Notify payload directing the group member to re-register using a REGISTER_REQUESTED status notify message (value TBD). This event triggers a GSA_CLIENT_SERVER exchange, as described above. The response to GSA_CLIENT_SERVER from the KS may include Delete payloads instructing the group member to delete old SAs. 4. Header and Payload Formats The protocol defined in this memo uses a HDR 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 identical to the GSA payload described in Section 4.3 of [I-D.yeung-g-ikev2]. This memo makes no changes to this Tran & Weis Expires September 10, 2012 [Page 5] Internet-Draft G-IKEv2-MRKM March 2012 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1. GSA TEK Payload One of GSA types is the Traffic Encryption Key (TEK) policy. The TEK describes the Traffic Encryption Policy. This document define new protocol ID of TEK protocol specific payload for routing protocol OSPFv2, OSPFv3 and PIM. 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: Tran & Weis Expires September 10, 2012 [Page 6] Internet-Draft G-IKEv2-MRKM March 2012 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) TEK Attribute - Key lifetime, define in (draft-yeung-g-ikev2-03, section 4.5) 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, because the traffic selectors are well known and unchanging values. However it should be noted that a site requiring alternative transforms can use the G-IKEv2 definitions for ESP and AH to define 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! | 0 (last) or 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transform Type | RESERVED | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Attributes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ GSA Life Attributes ~ Tran & Weis Expires September 10, 2012 [Page 7] Internet-Draft G-IKEv2-MRKM March 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 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) Name Number Defined In ---------------------------------------- NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_SHA1_96 2 (RFC2404) TEK Attribute - Key lifetime, define in (draft-yeung-g-ikev2-03, section 4.5) 5. IANA Considerations G-IKEv2 [I-D.yeung-g-ikev2] defines a new registry. This memo adds the following definitions to this registry. (TBD) Tran & Weis Expires September 10, 2012 [Page 8] Internet-Draft G-IKEv2-MRKM March 2012 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. References 8.1. Normative References [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, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 8.2. Informative References [DH] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, V.IT-22 n. 6, June 1977. [I-D.hartman-karp-mrkmp] Zhang, D., Lebovitz, G., and S. Hartman, "Multicast Router Key Management Protocol (MaRK)", draft-hartman-karp-mrkmp-03 (work in progress), January 2012. [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011. Tran & Weis Expires September 10, 2012 [Page 9] Internet-Draft G-IKEv2-MRKM March 2012 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 September 10, 2012 [Page 10]