Network Working Group D. Zhang Internet-Draft Huawei Intended status: Experimental S. Hartman Expires: January 4, 2012 Painless Security July 3, 2011 Unicast Router Key Management Protocol (RKMP) draft-zhang-karp-rkmp-00.txt Abstract When running routing protocols such as BGP or RSVP-TE, two routers need to exchange routing messages in a unicast (one-to-one) fashion. In order to authenticate these messages using symmetric cryptography, a secret key needs to be established. This document defines a Router Key Management Protocol (RKMP) for establishing and managing such keys for routing protocols. 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]. 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 January 4, 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 Zhang & Hartman Expires January 4, 2012 [Page 1] Internet-Draft RKMP July 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Relationship to IKEv2 . . . . . . . . . . . . . . . . . . . 3 1.3. Multicast as an Additional Feature . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Types of Keys . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Initial Exchanges . . . . . . . . . . . . . . . . . . . . . 4 2.3. Child SA Exchange . . . . . . . . . . . . . . . . . . . . . 5 3. Initial Exchange Details . . . . . . . . . . . . . . . . . . . 6 4. Child SA Exchange Details . . . . . . . . . . . . . . . . . . . 7 5. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Zhang & Hartman Expires January 4, 2012 [Page 2] Internet-Draft RKMP July 2011 1. Introduction Unicast and multicast both are common communication models adopted by routing protocols in exchanging routing messages. Using unicast, a message is expected to be sent to a single receiver identified by a unique address, while using multicast the same message is sent to a number of recipients. In [I-D.hartman-karp-mrkmp], an automatic group key management mechanism is proposed for securing multicast routing message exchanges (MRKMP). This draft propose a complementary Router Key Management Protocol for securing unicast routing messages (RKMP). Existing routing protocols using unicast (e.g., BGP, LDP, RSVP-TE) have cryptographic authentication mechanisms that use a key shared between the routers on the both sides of the communication to protect unicast routing message exchanges between the routers. RKMP assumes that routers need to be provisioned with some credentials for a one-to-one authentication protocol. Preshared keys or asymmetric keys and an authorization list are expected to be common deployments. If two routers running a routing protocol have not authenticated each other yet, before sending out any routing protocol packets two routers needs to perform mutual authentication using their provisioned credentials. If successful, two routers negotiate the key material to securing the routing protocol execution. 1.1. Terminology 1.2. Relationship to IKEv2 IKEv2 [RFC4306] provides a protocol for authenticating IPsec security associations between two peers. It currently provides no group keying. IKEv2 is attractive as a basis for this protocol because while it is much simpler than IKE [RFC2409], it provides all the needed flexibility in one-to-one authentication. Unlike IKE, IKEv2 is explicitly designed for IPsec. The document does not separate handling of aspects of the protocol that would be needed for IPsec from those that apply to general key management. IPsec specific rules are combined with more general requirements. While concepts and protocol payloads can be used in a different key management protocol, the current structure of IKEv2 does not provide a mechanism for applying IKEv2 to a domain of interpretation other than IPsec. In addition, the complexity required in the IKE specification when compared to IKEv2 suggests that the generality of Zhang & Hartman Expires January 4, 2012 [Page 3] Internet-Draft RKMP July 2011 IKE may not be worth the complexity cost. So this protocol borrows concepts and payloads from IKEv2 but does not normatively depend on the IKEv2 specification. 1.3. Multicast as an Additional Feature The base RKMP proposed in this draft aims for automatically generating keys to secure unicast routing messages. However, it can be easily extended to support authenticating multicast communications among routers. In [I-D.hartman-karp-mrkmp], the extension of RKMP in supporting multicast called MRKMP is introduced. RKMP and MRKMP can be combined to construct a integrated key management solution supporting both unicast and multicast. 2. Overview 2.1. Types of Keys The keys adopted in RKMP is listed as follows: PSK (Pre-Shared Key) : PSKs are pair-wise unique keys used for authenticating one router to the other one during the initial exchange. These keys are configured by some mechanism such as manual configuration or a management application outside of the scope of RKMP. Protocol master key: A protocol master key is the key exported by RKMP for use by a routing protocol such as BGP. This is the key that is shared in the key table between the routing protocol and RKMP. Transport key: A transport key is the key used to integrity protect routing messages in a protocol such as BGP. In today's routing protocol cryptographic authentication mechanisms the transport key can be the same as the protocol master key. 2.2. Initial Exchanges When a router intends to send an routing message to a remote one but there is no valid RKMP_SA shared between the router and its partner, the router will perform initial exchanges with its partner to derive . The initial exchanges is based on IKEv2's IKE_SA_INIT and IKE_SA_AUTH exchanges, which are referred to as RKMP_SA_INIT and RKMP_SA_AUTH exchanges respectively. During the initial exchanges, an initiating router attempts to authenticate to the router which it intends to Zhang & Hartman Expires January 4, 2012 [Page 4] Internet-Draft RKMP July 2011 exchange unicast routing messages with. Messages are unicast from the initiator to the responding router. Unicast RKMP messages form a request/response protocol; the party sending the messages is responsible for retransmissions. The initial exchanges provide capability negotiation, specifically including supported cryptographic suites for the key management protocol. Identification of the initiator and responder is also exchanged. A symmetric key is established to provide integrity, confidenality and authenticity protection for key management messages. These negotiation results compose a RKMP SA. While routing security does not typically require confidentiality, the key management protocol does because keys are exchanged and these must be protected. During authentcation, the identity of each party is cryptographically verified. This can be done using, e.g., a preshared key, asymmetric keys or self-signing certificates. Other mechanisms may be added as a future extension. The authentication exchange can also generate a SA for a routing protocol (called a child SA generally) . In the typical case, a router can obtain the needed key material (e.g., protocol master keys and maybe transport keys) for securing the desired routing protocol which in two round-trips. 2.3. Child SA Exchange The child SA exchange is analogous to the CREATE_CHILD_SA exchange in IKEv2 and consists of a single request/response pair. However, the CREATE_CHILD_SA exchange in IKEv2 is designated for IPsec while the child SA exchange can be used to generate SAs to secure various routing protocols. A child SA exchange can be triggered in order to 1) rekey an antique protocol master key and establish a new equivalent one, 2) generate needed key material for a newly executed routing protocol based on an existing RKMP_SA, or 3) rekey an RMKP_SA and establish a new equivalent RMKP_SA. A child SA exchange MAY be initiated by either end of the RKMP_SA after the initial exchanges are completed. All messages in a child SA exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the the initial exchange. Zhang & Hartman Expires January 4, 2012 [Page 5] Internet-Draft RKMP July 2011 3. Initial Exchange Details In the remainder of this document, the notations of the payloads contained in the messages are consistent with what have defined in Section 1.2 of [RFC4306]. The initial exchanges are decrypted as follows: The payloads included in the first pair of exchanged messages (i.e., the RKMP_SA_INIT exchange) are identical to what have been specified in the IKE_SA_INIT exchange [RFC4306]. During the RKMP_SA_INIT exchange, the two communicating partners needs to identify the cryptographic suite they both support, exchange nonces in order to check each other's aliveness, and exchange their public keys. After the exchange, both partners can use the Diffie-Hellman algorithm to agree upon a shared secret from which all keys for securing subsequent messages are derived. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],AUTH, SAi2} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2} The second pair of exchanged messages (i.e., the RKMP_SA_AUTH exchange) employ most of the payload specified in the IKE_SA_AUTH exchange. However, the traffic selector payloads in the original IKE_SA_AUTH exchange is removed. The objective of exchanging of traffic selector payloads is to guarantee the consistence of the Security Policy Databases (SPD) on the communicating partners. Therefore, when an IP packet is received by an IPsec subsystem and matches a "protect" selector in its Security Policy Database (SPD), the subsystem will have to protect that packet with IPsec. However, this is not the scenario that RKMP needs to consider. In addition, because RKMP is designed for cryptographic keys for routing protocols instead of IPsec, more values of the protocol ID field in the Security Association payload needs to be defined to represent different routing protocols. Zhang & Hartman Expires January 4, 2012 [Page 6] Internet-Draft RKMP July 2011 4. Child SA Exchange Details The Child SA exchange takes advantage of the payloads of the CREATE_CHILD_SA exchange while removing the traffic selector payloads. In addition, in order to support different routing protocols more values of the protocol ID field in the Security Association payload needs to be defined. Initiator Responder ----------- ----------- HDR, SK {[N], SA, Ni, [KEi]} --> <-- HDR, SK {SA, Nr, [KEr]} Note that in IPsec the value used to identify a particular SA is referred to as a Security Parameter Index (SPI). However, the values identifying a SA in other routing protocols may be named differently. For example, in RIPv2, OSPFv2 and IS-IS, such values are denoted as key identifiers. RKMP follows IKEV2 and uses SPIs to denote the values identifying SAs in different routing protocols. 5. Interfaces This section introduces three groups of interfaces: the interface to routing protocols, the interface to RKMP, and the interface to the key table. The interface to RKMP includes following methods: RKMP_generateSA: This method is called when a routing protocol expects RKMP to generate a new routing protocol SA and store it into the key table. As parameters, the protocol ID, the addresses of the Interfaces that two routers will be used to exchange messages need to be inputed. RKMP will send the SPI of the SA back to the routing protocol. After getting the SPI, the routing protocol can use it to derive the correspondent key material from the key table. RKMP_rekeySA: This method can be called when a routing protocol intends to proactively rekey an child SA which is still in its valid period. The protocol ID and the SPI of the SA which intends to be rekeyed are inputted as parameters. If the child SA is found, RKMP will return the SPI of the new generated equivalent SA to the routing protocol. If there is no correspondent child SA being found, RKMP will return zero back. The interface to the key table includes following methods: Zhang & Hartman Expires January 4, 2012 [Page 7] Internet-Draft RKMP July 2011 Keytable_getSA: This method is called when a routing protocol intends to get key material to secure a routing message sent to a remote router. As parameters, the protocol ID, the addresses of the Interfaces that two router will be used to exchange messages need to be inputted. (If the SPI of the SA is available, the routing protocol can also input the SPI to indentify the desired SA. It is assumed here that an SA can be uniquely identified by its SPI and the associated routing protocol ID.) The contents of the associated routing protocol SA will be returned. Keytable_delete: This method is called when a routing protocol intends to delete un-useful child SAs to release occupied resources. The protocol ID and the SPI of the SA to be deleted are inputted as parameters to identify the child SA which will be deleted. If the inputted SPI is zero, all the child SAs used by the routing protocol will be deleted. Keytable_insertSA: This method is called when RKMP have generated a new routing protocol SA and intends to store it into the key table. If there is already a SA with the identical SPI, the inserting operation will be failed. Keytable_rekeySA: This method is called when RKMP have generated a equivalent SA and intends to use it take place of the existing one maintained in the key table. The interface to a routing protocol includes following methods: RP_revokeSA: This method is called when RKMP deams that the RKMP security association has failed and then discards all state associated with the RKMP SA and any child SAs negotiated using that RKMP SA. After being invoked, the routing protocol will not use existing SAs to secure routing protocols messages. 6. Security Considerations 7. IANA Considerations The values of the protocol ID fields in the payloads need to be assigned by IANA to present various routing protocols. 8. Acknowledgements 9. References Zhang & Hartman Expires January 4, 2012 [Page 8] Internet-Draft RKMP July 2011 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 9.2. Informative 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. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. Authors' Addresses Dacheng Zhang Huawei Beijing China Email: zhangdacheng@huawei.com Sam Hartman Painless Security Email: hartmans@painless-security.com Zhang & Hartman Expires January 4, 2012 [Page 9]