| Network Working Group | M.J. Jethanandani |
| Internet-Draft | Independent |
| Intended status: Standards Track | B.W. Weis |
| Expires: September 07, 2012 | K.P. Patel |
| Cisco Systems | |
| D.Z. Zhang | |
| Huawei | |
| S.H. Hartman | |
| Painless Security | |
| March 08, 2012 |
Key Management for Pairwise Routing Protocol
draft-mahesh-karp-rkmp-01
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 for establishing and managing such keys for routing protocols.
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].
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 07, 2012.
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.
Existing routing protocols using unicast communication model (e.g., BGP, LDP, RSVP-TE) have cryptographic authentication mechanisms that use a key shared between the routers on the both sides of the model to protect routing message exchanges between the routers. Unicast key management today is limited to statically configuring master keys in individual routers. This document defines a Router Key Management Protocol (RKMP) that largely makes use of currently defined IKEv2 [RFC5996] protocol and extends it to allow network devices to automatically exchange key material related information between the network devices.
RKMP assumes that routers need to be provisioned with some credentials for a one-to-one authentication protocol. Pre-shared 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, and before sending out any routing protocol packets the two routers need to perform mutual authentication using their provisioned credentials. If successful, two routers negotiate the key material to secure the routing protocol execution.
Here are some terms that we will be using throughout the document.
SKEYSEED: When a TCP-AO transform is chosen, keying material for the TCP-AO master key is generated as follows, where Ni and Nr are unique to this exchange. The value SK_d is defined in Section 1.2 of IKEv2 [RFC5996], and refers to the value derived from SKEYSEED (defined in Section 2.14 of IKEv2 [RFC5996]). SK_d is used to derive new keys (e.g., for TCP-AO) as follows:
<TCP-AO master key> = prf+(SK_d, Ni | Nr)
The following acronyms and abbreviations are used throughout this document.
-----------------------
=======> | Not Authenticated |==========
|| | No RP Keys | ||
|| ----------------------- IKE_SA_INIT
|| ||
|| ||
|| ||
INFORMATIONAL VV
|| --------------------------
|| | Privacy Keys Exchanged |
|| | No RP Keys |
|| --------------------------
|| ||
|| |-------------------- IKE_AUTH
=========| Authenticated | <============
| RP Keys Derived | ====
-------------------- ||
^^ ||
|| CREATE_CHILD_SA
|| ||
===============
The keys adopted in RKMP are listed as follows:
The exchange of private keying material between two network devices using a dedicated key management protocol is a requirement as articulated in [I-D.ietf-karp-routing-tcp-analysis]. There is no need to define an entirely new protocol for this purpose, when existing mature protocol exchanges and methods have been vetted. This draft makes use of the IKEv2 protocol exchanges, state machine, and policy definitions to define a dedicated key management protocol.
In the following figures, the notations contained in the message are defined as follows.
| Notation | Payload |
|---|---|
| AUTH | Authentication |
| CERT | Certificate |
| CERTREQ | Certificate Request |
| D | Delete |
| HDR | IKEv2 Header (not a payload) |
| IDi | Identification - Initiator |
| IDr | Identification - Responder |
| KE | Key Exchange |
| Ni, Nr | Nonce |
| N | Notify |
| SA | Security Association |
| SK | Encrypted and Authenticated |
| TSi | Traffic Selector - Initiator |
| TSr | Traffic Selector - Responder |
The IKE_SA_INIT exchange defined in Internet Key Exchange Protocol Version 2 [RFC5996] is used in RKMP. The IKE_SA_INIT exchange is a two-message exchange that allows the network devices to negotiate cryptographic algorithms, exchange nonces, and do a Diffe-Hellman (DH) [DH] exchange, for their routing protocols, after which protocols on these network devices can communicate privately. Note that at this point the network devices have not identified their peer. For the details of this exchange, refer to IKE_SA_INIT in Internet Key Exchange Protocol Version 2 [RFC5996].
Peer (Initiator) Peer (Responder)
-------------------- ------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ,]
Next, the network devices perform an IKE_AUTH exchange defined in RFC 5996. However, the SA payloads contain the routing protocol specific security policies rather than IPsec policies (SAi2, SAr2 defined in RFC 5996), and the TS payloads contains routing protocol specific traffic selectors. Policy definitions for routing protocols is described in Section 3; for the details of the rest of the exchange please refer to IKE_AUTH in RFC 5996.
Peer (Initiator) Peer (Responder)
-------------------- ------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The network devices may then destroy the state associated with the IKEv2 SA, continuing to use the RP policy and keying material, or they may choose to retain them for the further use. Note that this policy differs from IKEv2/IPsec, where the deletion of the IKEv2 SA necessitates the deletion of the IPsec SAs. If both the network devices choose to retain them, they may use the IKEv2 SA to subsequently agree upon replacement policy for the same RP, or agree upon policy and keying material for another routing protocol. Either case will require the use of the IKEv2 CREATE_CHILD_SA exchange as defined in RFC 5996.
A CREATE_CHILD_SA exchange therefore can be triggered in order to
Peer (Initiator) Peer (Responder)
-------------------- ------------------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}
A CREATE_CHILD_SA exchange MAY be initiated by either end of the SA after the initial exchanges are completed. All messages in a CREATE_CHILD_SA exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the initial exchange.
For details on the exchange, refer to the CREATE_CHILD_SA exchange as defined in RFC 5996.
Peer (Initiator) Peer (Responder)
------------------- ------------------
HDR, SK {[N,] [D,] ... } -->
<-- HDR, SK {[N,] [D,] ... }
The IKEv2 INFORMATIONAL exchange is also useful for deleting specific IKEv2 SAs or sending status information. The Notify (N) and Delete (D) payloads are as those defined by IKEv2 [IKEV2-PARAMS]. For example, if the Responder refused to accept one of Proposals sent by the Initiator, it would return an INFORMATIONAL exchange of type NO_PROPOSAL_CHOSEN instead of the response to CREATE_CHILD_SA.
The protocol defined in this memo uses IKEv2 payload definitions. However, new security policy definitions are described to support security transforms and policy defined by routing protocol documents.
The Security Association (SA) payload contains a list of Proposals, which describe one or more sets of policy that a router is willing to use to protect a routing protocol. In the Initiator's message, the SAi2 payload contains a list of Proposal payloads (as defined in the next section), each of which contains a single set of policy that can b applied to the packets described in the Traffic Selector (TS) payloads in the same exchange. Each set of policy is given a particular "Proposal Number" uniquely identifying this set of policy.
The responder includes a single Proposal payload in it's SA policy, which denotes the choice it has made amongst the initiator's list of Proposals. Any attributes of a selected transform MUST be returned unmodified as explained in IKEv2 [RFC5996] section 3.3.6. The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not MUST terminate the exchange.
This memo defines new Proposal substructure definitions, which allow protocol participants to exchange proposals for routing protocol policy. Figure 6 defines new Protocol IDs that can be negotiated within an IKEv2 SA payload.
Protocol Protocol ID Reference ---------------------------------------------- TCP-AO TBD-1 RFC 5925 LDP Discovery Key TBD-2
The following section describes the SA Payload Transforms Substructures that are to be used with these Protocol IDs.
Each Proposal has a list of Transform (T) substructures, each of which describe a particular set of cryptographic policy choices. This is useful for an initiator to propose multiple cryptographic choices for the same policy described in its associated Proposal payload.
The TCP-AO [RFC5925] transform payload is specified to negotiate the TCP-AO policies and contains the following fields.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 3 | RESERVED | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SendID |Auth Alg | KDF | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last Transform Substructure in the Proposal.
o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on receipt.
o Transform Length (2 octets) - The length (in octets) of the Transform Substructure including Header and Attributes.
o SendID (1 octet) - The TCP-AO KeyID that the sender will use to represent this Transform. The KeyID will be used to generate the keys independently on each network device at the end of the exchange.
o Auth Alg (1 octet) - The Authentication algorithm defined as a part of this Transform. Initial values are defined in Cryptographic Algorithms for the TCP Authentication Option [RFC5926]. Parenthetical names in Figure 8 refer to the values assigned in the Cryptographic Algorithms for TCP-AO Registration [TCP-AO-REG].
Auth Alg ID ------------------------------ Reserved 0 HMAC-SHA-1-96 (SHA1) 1 AES-128-CMAC-96 (AES128) 2 Standards Action 3-140 Private Use 241-255
o KDF (1 octet) - The KDF defined as a part of this Transform. Values are defined in Cryptographic Algorithms for the TCP Authentication Option [RFC5926].
KDF ID ------------------------------ Reserved 0 KDF_HMAC_SHA1 1 KDF_AES_128_CMAC 2 Standards Action 3-240 Private Use 241-255
o Flags (1 octet) - Indicates specific options for TCP-AO. The bits are as follows:
+-+-+-+-+-+-+-+-+ |O|X|X|X|X|X|X|X| +-+-+-+-+-+-+-+-+
In the description below, a bit being 'set' means its value is '1', while 'cleared' means its value is '0'. 'X' bits MUST be cleared when sending and MUST be ignored on receipt.
When a TCP-AO transform is chosen, keying material for the TCP-AO master key is generated as follows, where Ni and Nr are unique to this exchange. The value SK_D is defined in RFC 5996, and refers to the value derived from SKEYSEED that is used to derive new keys (e.g., for TCP-AO).
<TCP-AO master key> = prf+(SK_d, Ni | Nr)
TBD
The Traffic Selector (TS) payload allows an RP peer to identify packet flows that are to be protected with the policy in the SA payload. Unlike IPsec, routing protocols have well-defined flows, and there is no need to specify them to the specificity of IPsec policy. The document defines a new TS type for routing protocols as shown in Figure 12. The TS payload defined in this document includes only the routing protocol identifier that is to be protected.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS Type | Rtg. Prot. ID | Selector Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Rtg. Prot. ID (1 octet) - Specifies the routing protocol identifier for the current negotiation.
Routing (RT) Protocol Protocol ID Reference ----------------------------------------------- Reserved 0 BGP 1 RFC 4271 LDP 2 RFC 5036 MSDP 3 RFC 3618 PIM PORT 4 PCEP 5 RFC 5440 Unassigned 6-240 Private Use 240-255
RKMP is used to dynamically derive key material information between the two network devices trying to establish or maintain a routing protocol neighbor adjacency. Typically network devices running the routing protocols establish neighbor adjacencies at the routing protocol level. These routing protocols may run different security algorithms that provide transport level security for the protocol neighbor adjacencies. Depending on the security algorithm used, the routing protocols are configured with security algorithm specific keys that are either long term keys or short term session keys. These keys are specific to the security algorithms used to enforce transport level security for the routing protocols.
A routing protocol causes RKMP to execute when it needs key material to establish neighbor adjacency. This can be as a result of the routing protocol neighbor being configured, neighbor changed or updated, a local rekey policy decision, or some other event dictated by the implementation. The key material would allow the network devices to then independently generate the same key and establish a RKMP neighbor adjacency between them. This is typically done by the Initiator (RKMP speaker) initiating a RKMP RP_INIT exchange mentioned in the section 2.1 towards its RKMP peer. As part of RP_INIT exchange, RKMP will send a message to the RKMP peer's IKEv2 port. The format of the message is explained in section 3. The procedure to exchange key information is explained in section 3. Once the key material information is successfully exchanged by both the RKMP speaker, the RKMP neighbor adjacency may be torn down or kept around as explained in section 3.
The master key data received from RKMP peers are stored in the separate Key Management Database known as KMDB. KMDB follows the guidelines inDatabase of Long Lived Symmetric Cryptographic Keys [I-D.ietf-karp-crypto-key-table], and each entry consists of Key specific information, Security algorithm to which the Key is applicable to, Routing Protocol Clients of interest, and the announcing RKMP Peer. KMDB is also used to notify the routing protocols about the key updates. Typically key material information is exchanged whenever a routing protocol is about to create a new neighbor adjacency. This is considered as an Initial Key exchange mode. Key material information is also exchanged to refresh existing key data on an already existing neighbor adjacency. This is considered as Key rollover exchange mode. The following sections describes their detail behavior.
Routing protocols informs RKMP of its new neighbor adjacency. It does so by creating a local entry in KMDB which consists of a Security algorithm, Key specific information, routing protocol client and the routing protocol neighbor. Upon a successful creation of such an entry RKMP initiates RKMP peering with the neighbor and starts initial RKMP RP_INIT exchange explained in section 2.1 followed by the RP_AUTH exchanged explained in section 2.2. Once the key related information is successfully exchanged, KMDB may invoke the routing protocol client to provide key specific information updates if any.
The procedure for key selection and rollover exchange has been described in Section 3 of Database of Long-Lived Symmetric Cryptographic Keys [I-D.ietf-karp-crypto-key-table]. Details of how RP interact with KMDB and deals with multiple keys during rollover are also described in that section.
Protocol interaction between RKMP and its client routing protocols is typically done using KMDB. Routing protocols update KMDB by installing a new Key related information or purging an existing Key specific information. As part of the KMDB update, RKMP initiates peering connections with its appropriate RKMP peers to announce the updated key related information. RKMP may also receive an updated key related information from its peers which gets installed in KMDB. Whenever RKMP updates KMDB with updated key information from its peers, it notifies client routing protocols of its updates.
New Protocol-IDs (as described in Figure 6) are to be allocated in the IKEv2 Security Protocol Identifiers registry.
A new Traffic Selector Type (as described in Figure 13) is to be allocated in the IKEv2 Traffic Selector Types registry.
Several new registries are to be defined as part of a new RKMP Protocol Registry. These are described in Figure 8, Figure 9, and Figure 13.
TBD
During the development of TCP-AO, Gregory Lebovitz noted that a protocol based on an IKEv2 exchange would be a good automated key management method for deriving a TCP-AO master key.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5925] | Touch, J., Mankin, A. and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. |
| [RFC5926] | Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010. |
| [RFC5996] | Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |
| [IKEV2-PARAMS] | Internet Key Exchange Version 2 (IKEv2) Parameters", . | , "
| [DH] | Diffie, W.D. and M.H. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, V.IT-22 n. 6, June 1977. |
| [I-D.ietf-karp-crypto-key-table] | Housley, R and T Polk, "Database of Long-Lived Symmetric Cryptographic Keys", Internet-Draft draft-ietf-karp-crypto-key-table-02, October 2011. |
| [I-D.ietf-karp-routing-tcp-analysis] | Jethanandani, M, Patel, K and L Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Guide", Internet-Draft draft-ietf-karp-routing-tcp-analysis-00, June 2011. |
| [TCP-AO-REG] | Internet Key Exchange Version 2 (IKEv2) Parameters", . | , "