Network Working Group P. Tran Internet-Draft B. Weis Intended status: Standards Track Cisco Systems Expires: April 25, 2013 October 22, 2012 The Use of G-IKEv2 for Multicast Router Key Management draft-tran-karp-mrmp-02 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 routing protocols between a group of network devices. 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 25, 2013. 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 April 25, 2013 [Page 1] Internet-Draft G-IKEv2-MRKM October 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 . . . . . . . . . . . . . . . . . . 6 4.1. Group Security Association Payload . . . . . . . . . . . . 6 4.1.1. GSA TEK Policy . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Tran & Weis Expires April 25, 2013 [Page 2] Internet-Draft G-IKEv2-MRKM October 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 (e.g., OSPF, PIM) and is known as G-IKEv2 for Multicast Router Key Management (G-IKEv2-MRKM). Two models of group security are discussed. 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 "registers" 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. Many routing protocols are designed such that each participating network device sources network packet that one or more peers receive, often using link-local multicast addresses. Using GKM terminology, this is an M-to-N communication model [RFC3740], which provides for many senders and receivers. However, varying group security models are possible. Two relevant examples are: o Multiple-sender security associations. Each network devices protects packets using the same keying material and policy, distributed by a single GCKS. When network devices require high reliability a single GCKS is not sufficient, so may require an election among currently available authorized members to choose a GCKS before network communications can be protected. This approach is taken in [I-D.hartman-karp-mrkmp]. A simpler approach may be found by requiring all election messages to be authenticated, which effectively sets up a full mesh of authenticated connections. Tran & Weis Expires April 25, 2013 [Page 3] Internet-Draft G-IKEv2-MRKM October 2012 o Single-sender security associations. Each network device sending routing protocol packets acts as its own key server, essentially converting an M-to-N communication model to M 1-to-N groups (where M is the number of authorized members participating in the routing protocol). A full mesh of authenticated connections is again required, but the lack of an election protocol may result in a simpler system. The methods in the memo support both Multiple-sender security associations and single-sender security associations. The G-IKEv2 GKM protocol provides for a GM receiving security associations from a GCKS in two IKEv2 exchanges: the IKE_SA_INIT exchange [RFC5996] to setup the encrypted session, and the GSA_AUTH exchange [I-D.yeung-g-ikev2] (similar in construction to the IKEv2 IKE_AUTH protocol) to authenticate, authorize, and distribute group policy. 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,] Figure 1: IKEv2 IKE_SA_INIT Exchange Next, the group member and key server devices perform a GSA_AUTH, which is substantially the same as the IKE_AUTH exchange defined in Tran & Weis Expires April 25, 2013 [Page 4] Internet-Draft G-IKEv2-MRKM October 2012 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} Figure 2: G-IKEv2 GSA_AUTH Exchange 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 ]} Figure 3: G-IKEv2 GSA_CLIENT_SERVER Exchange 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 separate 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 Tran & Weis Expires April 25, 2013 [Page 5] Internet-Draft G-IKEv2-MRKM October 2012 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. Alternatively, the GCKS policy may support the G-IKEv2 group maintenance channel and the GCKS can distribute a GSA_REKEY exchange with new policy and keying material (see Section 3.3 of [I-D.yeung-g-ikev2]). 4. Header and Payload Formats The protocol defined in this memo uses IKEv2 and G-IKEv2 payload definitions. However, new security policy definitions are described to support security transforms and policy defined by routing protocol documents. When a routing protocol indicates the use of ESP or AH, existing G-IKEv2 SA Payload types suffice. 4.1. Group Security Association Payload The Group Security Association (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 payload. 4.1.1. GSA TEK Policy One of the GSA types is the Traffic Encryption Key (TEK) policy. The TEK describes the Traffic Encryption Policy defined by a supported security protocol. Some routing protocol definitions (i.e., OSPFv3 [RFC4552], LMP [RFC4204], and PIM [RFC5796]) describe the use of ESP and AH, which are supported by existing G-IKEv2 TEK policy definitions. However, a number of routing protocol specific security transforms exist and these require new TEK definitions. Section 4.5 of [I-D.yeung-g-ikev2] defines the TEK payload as a Protocol-ID followed by a TEK Protocol-Specific Payload, replicated in Figure 4 for reference. Tran & Weis Expires April 25, 2013 [Page 6] Internet-Draft G-IKEv2-MRKM October 2012 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 ! +-+-+-+-+-+-+-+-+ ~ ~ ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 4: GSA TEK Payload This memo extends the list of Protocol-ID values to include a set of routing protocols that use group keys, shown in Figure 5. Protocol-ID Value ----------- ----- RESERVED 0 GSA_PROTO_IPSEC_ESP 1 GSA_PROTO_IPSEC_AH 2 GSA_PROTO_OSPFv2 TBD1 GSA_PROTO_OSPFv3 TBD2 GSA_PROTO_IS_IS TBD3 GSA_PROTO_LDP_HELLO TBD4 GSA_PROTO_RSVP_TE TBD5 GSA_PROTO_BFD TBD6 Figure 5: Routing Protocol-ID Values 4.1.1.1. TEK Protocol-Specific Payload The policy for each of the new Protocol-ID types defines in this memo are sufficiently similar that a single Routing Protocol (RP) protocol-specific payload that can be defined to convey the required policy. Figure 6 defines the RP-TEK payload. Tran & Weis Expires April 25, 2013 [Page 7] Internet-Draft G-IKEv2-MRKM October 2012 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 Size | SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! TEK Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 6: RP TEK Protocol-Specific Payload The RP-TEK fields are defined as follows: o SPI Size (1 octet) - Equal to the size, in octets, of the SPI defined by the corresponding protocol. o SPI (variable) - The SPI defined by the GCKS representing this TEK. In many cases, the SPI is referred to as a Key ID by routing protocol specifications. o Source & Destination Traffic Selectors - The traffic selectors describe the source and the destination of the protecting traffic. The format and values are defined in IKEv2 [RFC5996], section 3.13.1. o Transforms - One or more substructures specifying the transform information. The format is defined in IKEv2 [RFC5996], section 3.3.2. o TEK Attributes - Contains TEK policy attributes associated with the group. The following sections describe the possible attributes. Any or all attributes may be optional, depending on the group policy. [RFC5996], section 3.3.5. Attributes Tran & Weis Expires April 25, 2013 [Page 8] Internet-Draft G-IKEv2-MRKM October 2012 Attribute Type Value Attribute Format ------------------------------------------------------------ Life Duration 1 TLV Specifies the time-to-live for the overall security association. When the TEK expires, all keys downloaded under the association (AH or ESP) must be re-rekeyed. The life duration attribute defines the actual length of the component lifetime in seconds that can be protected. If unspecified, there is no lifetime defined for the TEK. Attribute Type Value Attribute Format ------------------------------------------------------------ Replay Protection 2 TV Some routing protocols (e.g., RSVP-TE) define multiple replay protection methods. Possible values of the Replay Protection attribute are: +-------+---------+ |Number |Name | +-------+---------+ | 0 |NONE | | 1 |COUNTER | | 2 |TIME | +-------+---------+ Figure 7: RP Replay Method Attributes 4.1.1.2. Transforms Policy for each of the routing protocols differs, but it possible to summarize the policy into one or more transform types. The following sections describe this policy. 4.1.1.2.1. Integrity Algorithms Routing protocols include an integrity algorithm, often but not always an HMAC construction. The following table represents current integrity algorithms specified by each routing protocol considered in the KARP charter. Tran & Weis Expires April 25, 2013 [Page 9] Internet-Draft G-IKEv2-MRKM October 2012 +--------+-------------------------------------------------+----------+ | RP | Integrity Algorithm Name(s) | RFC | +--------+---------------------------------+---------------+----------+ | OSPFv2 |Keyed-MD5 | RFC 2328 | | |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| RFC 5709 | | OSPFv3 |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| RFC 6506 | | IS-IS |HMAC-MD5 | RFC 5304 | | |HMAC-SHA-1,HMAC-SHA-224,HMAC-SHA-256,HMAC-SHA-384| RFC 5310 | | |HMAC-SHA-512 | RFC 5310 | | LDP |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| (LDP I-D)| | RSVP-TE|HMAC-MD5 | RFC 2747 | | BFD |Keyed-MD5, Keyed-SHA1,Meticulous-Keyed-SHA1 | RFC 5880 | | |HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512 | (BFD I-D)| +-------+----------------------------------+---------------+----------+ (LDP I-D) [I-D.ietf-mpls-ldp-hello-crypto-auth] (BFD I-D) [I-D.ietf-bfd-generic-crypto-auth] Figure 8: Survey of RP Integrity Algorithms None of these are currently represented as current IKEv2 INTEG transform values, primarily because the output has not been defined by the routing protocol transforms to be truncated. Since these transforms are mutually exclusive to the transforms defined in the Transform Type 3 - Integrity Algorithm Transform IDs IKEv2 IANA table, and to reduce confusion between IPsec integrity transform values and routing protocol transform values, this memo defines a new transform to describe the routing protocol integrity transforms. Transform IDs for the RP-INTEG Transform attributes types are shown in Figure 9. Attributes +-------+-----------------------+ |Number | Name | +-------+-----------------------+ | 0 |RP_AUTH_HMAC_MD5 | | 1 |RP_AUTH_HMAC_SHA1 | | 2 |RP_AUTH_HMAC_SHA2_224 | | 3 |RP_AUTH_HMAC_SHA2_256 | | 4 |RP_AUTH_HMAC_SHA2_384 | | 5 |RP_AUTH_HMAC_SHA2_512 | | 6 |RP_AUTH_KEYED_MD5 | | 7 |RP_AUTH_KEYED_SHA1 | | 8 |RP_AUTH_MET_KEYED_SHA1 | +-------+-----------------------+ Figure 9: RP-INTEG Transform IDs Tran & Weis Expires April 25, 2013 [Page 10] Internet-Draft G-IKEv2-MRKM October 2012 4.1.1.2.2. Extended Sequence Numbers Some routing protocol transforms have introduced a 64-bit sequence number. This can be signaled using the Extended Sequence Numbers Transform. No changes are required to the Extended Sequence Numbers Transform. 5. IANA Considerations G-IKEv2 [I-D.yeung-g-ikev2] defines a new registry. This memo adds the following definitions to this registry. (TBD) A new IKEv2 Transform (RP_INTEG) is defined for declaring routing protocol integrity algorithms. 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-05 (work in progress), October 2012. [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. Tran & Weis Expires April 25, 2013 [Page 11] Internet-Draft G-IKEv2-MRKM October 2012 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] Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router Key Management Protocol (MaRK)", draft-hartman-karp-mrkmp-05 (work in progress), September 2012. [I-D.ietf-bfd-generic-crypto-auth] Bhatia, M., Manral, V., and D. Zhang, "BFD Generic Cryptographic Authentication", draft-ietf-bfd-generic-crypto-auth-03 (work in progress), October 2012. [I-D.ietf-mpls-ldp-hello-crypto-auth] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", draft-ietf-mpls-ldp-hello-crypto-auth-00 (work in progress), August 2012. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006. [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011. Tran & Weis Expires April 25, 2013 [Page 12] Internet-Draft G-IKEv2-MRKM October 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 April 25, 2013 [Page 13]