Working Group U. Chunduri Internet-Draft A. Tian Intended status: Standards Track Ericsson Inc. Expires: July 20, 2013 J. Touch USC/ISI January 16, 2013 Using IKEv2 with TCP-AO draft-chunduri-karp-using-ikev2-with-tcp-ao-03 Abstract This document describes a mechanism to secure TCP-based pairwise Routing Protocol (RP) associations using the IKEv2 Key Management Protocol (KMP) integrated with TCP-AO. A Gatekeeper (GK) mechanism is introduced to allow TCP-AO to coordinate with IKEv2 without fundamental modification to either. This document also introduces extensions to IKEv2 and its Security Associations to enable its key negotiation to support TCP-AO. The document also includes a summary of IKEv2 authentication methods available for peer authentication for use in protecting routing protocols. 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 July 20, 2013. Copyright Notice Copyright (c) 2013 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 Chunduri, et al. Expires July 20, 2013 [Page 1] Internet-Draft Using IKEv2 with TCP-AO January 2013 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation and Overview . . . . . . . . . . . . . . . . . . . 4 3. The Gatekeeper . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. RP interface to the Gatekeeper . . . . . . . . . . . . . . 6 3.2. Interface to the PAD . . . . . . . . . . . . . . . . . . . 7 3.3. KMP interface to Gatekeeper . . . . . . . . . . . . . . . 8 3.3.1. Interface to KARP Crypto Key Table . . . . . . . . . . 9 3.4. TCP-AO interface to Gatekeeper . . . . . . . . . . . . . . 10 3.5. Impact of Policy changes . . . . . . . . . . . . . . . . . 11 4. Extensions required for IKEv2 . . . . . . . . . . . . . . . . 11 4.1. Non IPsec DOI . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Security Association Extensions . . . . . . . . . . . 12 4.2. Simple Traffic Selectors Negotiation . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. BGP Multi Session and transport level differentiation . . 13 8.2. Applicable Authentications methods . . . . . . . . . . . . 14 8.2.1. Symmetric key based authentication . . . . . . . . . . 14 8.2.2. Asymmetric key based authentication . . . . . . . . . 15 8.2.3. EAP based authentication . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Chunduri, et al. Expires July 20, 2013 [Page 2] Internet-Draft Using IKEv2 with TCP-AO January 2013 1. Introduction A security threat analysis for TCP-based routing protocols (BGP [RFC4271], PCEP [RFC5440], MSDP [RFC3618] and LDP [RFC5036]) is detailed in [ietf-karp-routing-tcp-analysis]. The KARP design guide [RFC6518] suggests various requirements and options for obtaining keys to protect the routing protocols and recommends using a Key Management Protocol (KMP) to automate key establishment, as well as rekeying to continuously protect the routing protocols. This document analyzes the TCP-based pairwise Routing Protocol (RP) requirements needed to integrate the IKEv2[RFC5996] KMP together with TCP-AO[RFC5925] to protect routing protocols. This document introduces a new Gatekeeper module, which provides a common interface and minimizes the changes for all routing protocols (BGP, PCEP, MSDP and LDP) to be integrated with KMP. The Gatekeeper modules does the SA management and interaction with KMP as well as TCP-AO protocol. The purpose of the Gatekeeper is to act as a shim between IKEv2 and TCP-AO, so that TCP-AO and the Gatekeeper together act like IPsec to IKEv2 (since IKEv2 is designed to tightly interact with IPsec). This document defines this common interface between all TCP-based pairwise routing protocols with Gatekeeper and IKEv2 [RFC5996]. Currently IKEv2 can establish only Security Association (SA) for IPsec. A few extensions are needed for IKEv2 to establish SA for TCP-based routing protocols when TCP-AO is used for protection. Section 4 discusses the summary of extensions required for IKEv2 protocol for key establishment, traffic selectors negotiation and SA establishment to support the keying and parameters needed by TCP-AO. One of the services provided by IKEv2 KMP is peer authentication. This happens before traffic keys are established between IKEv2 peers. As IKEv2 KMP provides a variety of authentications methods; Section 8.2 discusses various Symmetric, Asymmetric and EAP based KMP authentication options available. The goal of Section 8.2 is to summarize vastly scattered information for choosing the right authentication method by operators for peer authentication with low operational overhead and yet secure mechanism especially suitable for routing environments. 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]. Chunduri, et al. Expires July 20, 2013 [Page 3] Internet-Draft Using IKEv2 with TCP-AO January 2013 1.2. Acronyms BGP - Border Gateway Protocol EAP - Extensible Authentication Protocol GKR - Gatekeeper Record IKEv2 - Internet Key Exchange Protocol Version 2 IPsec - Security Architecture for the Internet Protocol KDF - Key Derivation Function KMP - Key Management Protocol (auto key management) LDP - Label Distribution Protocol MKM - Manual Key management Protocols MKT - Master Key Tuples as defined in TCP-AO MSDP - Multicast Source Discovery Protocol PAD - Peer Authorization Database PCEP - Path Computation Element Communication Protocol RP - Routing Protocol SA - Security Association TCP-AO - TCP Authentication Option 2. Motivation and Overview IKEv2 assumes IPsec triggers new SA requests, manages SA timers and rekeys SAs as needed. TCP-AO assumes an external key manager, which could support functions like Master key triggering, SA timers, and rekey triggering to get all the parameters required including Master key to protect the TCP session. To bridge the gap between IKEv2 and TCP-AO, this document defines a Gatekeeper module as described in Section 3. The motivation of this document is to offload Security Association (SA) management and to provide a generic and common interface for all TCP-based RPs to integrate with KMPs in general and specifically with Chunduri, et al. Expires July 20, 2013 [Page 4] Internet-Draft Using IKEv2 with TCP-AO January 2013 IKEv2 KMP. The following diagram depicts the Gatekeeper module interfaces with all protocols involved i.e., TCP-based RPs, IKEv2 KMP, and TCP-AO. This also shows the interaction with various databases viz., Peer Authorization Database (PAD) and Crypto Key Tables interaction with the Gatekeeper. +-----------+ +-------------+ RP Session | PAD | | TCP Based | Configuration +--->| |---+ | RPs |------->-------+ | +-----------+ | |(BGP/LDP/PCEP| | | | | /MSDP) | _|__|_ +----------+ +-------------+ | | Trigger | | |Gate- |----------->| IKEv2 | |keeper| Negotiated | KMP | +-------------+ | | Parameters | | | | | |------------| | | | |______| +----------+ | TCP-AO | | | |------------------+ +----------+ | | MKT Provisioning | |Crypto Key| +-------------+ +--->|Tables | +----------+ Figure 1: KARP KMP: Using IKEv2 with TCP-AO In Figure 1, before initiating the TCP connection, all TCP-based RPs communicate the provisioned configuration to Gatekeeper module. A entry in the KMP peer authentication/authorization is provisioned in PAD as defined in Section 4.4.3 of [RFC4301] and pointer to this entry SHOULD be part of the RP configuration. This facilitates Gatekeeper to issue a corresponding request, with all the proposed alternatives at the RP to the IKEv2 KMP, so IKEv2 can negotiate the needed parameters. When the local peer is acting as a responder, security policy information populated at the Gatekeeper can be referenced through PAD by IKEv2 KMP to create the CHILD_SAs. Either way, the negotiated parameters are kept in the crypto key table database as specified in [ietf-karp-cryoto_key-table] and this information is basis for provisioning MKTs in the TCP-AO. Gatekeeper maintains the KMP SAs and initiates rekey triggers as needed to provision new MKTs for the long-lived TCP sessions protected by TCP-AO. The Gatekeeper installs these new keys in Chunduri, et al. Expires July 20, 2013 [Page 5] Internet-Draft Using IKEv2 with TCP-AO January 2013 TCP-AO consistent with TCP-AO's support for key changes. Section 3 describes in detail the role of Gatekeeper and it's interfaces to all the protocols and the databases it interacts with. Section 3.3.1, Section 3.2 describes the database and the interaction with the Gatekeeper in detail. 3. The Gatekeeper TCP-AO has a different model of security associations and key management than IPsec. IKEv2 is designed to support IPsec's model. This document introduces the Gatekeeper to enable IKEv2 to support key and parameter negotiation that can be used in TCP-AO, as identified in Section 2. The Gatekeeper maintains a Gatekeeper record (GKR) to keep track of TCP-AO MKTs. For long-lived TCP connections MKTs can be rolled over by rekeying creating new MKTs and installing them in TCP-AO. The GKR can be viewed as a superset of MKT; it maintains and tracks the lifetime of the provisioned MKT, and includes other per-connection parameters needed by TCP-AO, such as algorithm, key length, etc. [RFC5926]. It also maintains the reference to PAD and Crypto Key Table entries to facilitate RP security parameters negotiation with IKEv2 KMP. The next section defines the Gatekeeper module interface between TCP- based RPs (BGP, LDP, MSDP, PCEP), interface with IKEv2, TCP-AO and other key databases. 3.1. RP interface to the Gatekeeper When a routing protocol is configured to use TCP-AO with KMP (by not specifying the keys or through some other means), TCP connection identifiers, all configured Message Authentication Code (MAC) algorithms, all configured Key Derivation Function (KDF) parameters, rekey lifetime and the TCP option flag (i.e., all additional parameters specified in [RFC5926]) are provisioned in the Gatekeeper record. This provisioning includes the reference to PAD, which has all the information to authorize and authenticate IKEv2 peer. If the same routing protocol (RP) needs differentiate transport sessions to differently securing separate TCP connections between the same endpoints, TCP connection identifiers either the full socket pair (i.e., local IP address, remote IP address, local TCP port, and remote TCP port) or partial socket pair values (as indicated with wildcards) need to be provisioned. GKRs SHOULD thus support full or partial socket pair specification. Chunduri, et al. Expires July 20, 2013 [Page 6] Internet-Draft Using IKEv2 with TCP-AO January 2013 In general, a full socket pair is not needed for negotiating the TCP-AO MKT with KMP. As specified in Section 3.1 of TCP-AO [RFC5925], socket pair values can be partially specified using ranges, masks, wildcards, or any other suitable indication. These provisioned socket pair parameters are supplied to KMP as context in which to negotiate traffic selectors for which the MKT or Master key should be used in TCP-AO. For more details on cases where a full socket pair is needed before opening the connection, please refer Section 8.1. Provisioning of the Gatekeeper record SHOULD be done before opening the TCP connection. From the RP interface, the record created in Gatekeeper contains only the RP's connection information, and this information is given to KMP (IKEv2) to obtain the negotiated parameters to provision the MKT to protect the underlying TCP session by [RFC5925]. 3.2. Interface to the PAD The Peer Authorization Database (PAD) for IPsec is described in Section 4.4.3 of [RFC4301]. This section describes the embodiments of the same in the context of RP security associations and security policies provisioned at the routing protocols. This is still the link between policies provisioned at the routing protocol and the SAs created by IKEv2 KMP. Instead of the Security Policy Database (SPD), Gatekeeper record holds the data for traffic selectors for child SA creation. Chunduri, et al. Expires July 20, 2013 [Page 7] Internet-Draft Using IKEv2 with TCP-AO January 2013 Gatekeeper Record PAD Entry +------------+ +------------+ | RP1 |------------------------>| Peer X | | | | | | | +--------------->| | +------------+ / +------------+ / +------------+ / | | / | RP2 |---+ | | +------------+ +------------+ +------------+ | | | | | RP1/RP3 |------------------------>| Peer Y | | | | | +------------+ +------------+ Figure 2: KARP KMP: Gatekeeper interface to the PAD As shown in Figure 2, multiple RPs can point to the same peer and in this case, a PAD entry holds the reference to both the corresponding Gatekeeper records. The PAD entry for the IKEv2 peer is used to constrain the creation of child SAs; specifically, the PAD entry specifies how the Gatekeeper record is searched using a traffic selector proposal from a peer. For CHILD_SA creation, peer IP addresses asserted in traffic selector payloads SHOULD be used for Gatekeeper record lookups based on the remote IP address field portion of a Gatekeeper Record entry. 3.3. KMP interface to Gatekeeper As an initiator, IKEv2 expects an external trigger that contains the information required to negotiate security associations. There needs to be a way to trigger the KMP to initiate negotiation with all the provisioned parameters of a Gatekeeper record by a TCP-based RP. A similar trigger is also required to rekey, to maintain the negotiated SAs for long-lived connections. As a responder to the peer IKEv2 requests and CHILD_SA creation; Gatekeeper record is consulted through the reference in PAD. The purpose of this section is to define a common interface between the Gatekeeper and the IKEv2 KMP and also to list all the negotiated parameters to form an entry in the Crypto Key Tables. Chunduri, et al. Expires July 20, 2013 [Page 8] Internet-Draft Using IKEv2 with TCP-AO January 2013 3.3.1. Interface to KARP Crypto Key Table KMP negotiated parameters are kept in the crypto key table database as specified in [ietf-karp-cryoto_key-table]. The database is characterized as a table, where each row represents a single long- lived symmetric cryptographic key or Master key. The Gatekeeper record SHOULD have a reference to the Crypto Key Table Entry. One of the reasons to separate the negotiated parameters in a different table is to alleviate the population manually or through a some external source. The following are the details: 1. At the time of a new connection, a trigger to the KMP occurs to negotiate the session-specific parameters with the needed information on MAC algorithm, KDF parameter, Traffic Selectors, and the TCP option flag from the Gatekeeper record. The Gatekeeper at the peer is expected to have similar provisioning in place for responding to the received KMP request. 2. A KMP session identifier, provided by a successful key negotiation by the KMP, needs to be stored and should be used when the Gatekeeper make decision based on the lifetime to rekey the existing session. 3. MKT IDs (as specified in Section 3.1 of TCP-AO [RFC5925]) require a SendID and a RecvID for each MKT, mutually agreed by the connection endpoints. These 1-byte quantities need to be negotiated by the KMP with the peer to populate in the MKT. These fields are populated as "LocalKeyName" and "PeerKeyName" in the Crypto Key Table entry. 4. Crypto Key Table "Peers" field SHOULD be populated with the peer IP address. 5. KMP-negotiated KDF parameters for each session used to generate traffic keys from master keys to be populated in MKT. The same is referred as "KDF" in a corresponding Crypto Key Table entry. 6. A KMP-negotiated MAC algorithm, MKT connection identifiers (negotiated traffic selectors) and optionally life time for traffic keys for each session, need to be populated in MKT. The same is referred as "AlgID" in corresponding Crypto Key Table entry. 7. The "Key" field defined in Crypto Key Table contains a long-lived symmetric cryptographic key or Master Key in the format of a lower-case hexadecimal string. The size of the Key depends on Chunduri, et al. Expires July 20, 2013 [Page 9] Internet-Draft Using IKEv2 with TCP-AO January 2013 the KDF and the AlgID. 8. IKEv2 does not negotiate rekey lifetime and rekeying is based on local operator policy. The Gatekeeper adds this capability, tracking the key lifetime provisioned at TCP-based RP and explicitly triggering the KMP to rekey when indicated. This rekey trigger then creates a new MKT for the underlying TCP connection. Implementations can proactively negotiate a new MKT Master Key before the lifetime of the current Master key expires. 3.4. TCP-AO interface to Gatekeeper TCP-AO expects an external entity to provision its MKTs in order to protect TCP sessions. The Gatekeeper module provides this function so that all TCP-based RPs can benefit from this common interface. The following are the details of the interface between TCP-AO and the GK: 1. After getting the negotiated parameters and mutually authenticated Master keys from the KMP, the Gatekeeper inserts a corresponding MKT and parameters into TCP-AO. The session- specific parameters include negotiated Connection identifiers, MAC algorithms, KDFs, KeyIDs, the TCP option flag and the Master Key given by the KMP. 2. MKT IDs (as specified in Section 3.1 of TCP-AO [RFC5925]) require a SendID and a RecvID for each MKT, which are mutually agreed by the connection endpoints. These 1-byte quantities need to be part of the MKT when the KMP key(s) are populated in MKT. 3. For long-lived TCP sessions, the Gatekeeper removes the old MKTs from TCP-AO after rekeying the corresponding new MKTs, to continuously protect the underlying TCP sessions. 4. In general, restarted TCP sessions can use existing MKT in TCP-AO i.e., IKEv2 need not be retriggered, since new key and parameter negotiation is not needed due to the protection already provided by TCP-AO (refer Section 5.3.1 of TCP-AO [RFC5925]). However, if GKR and hence TCP-AO MKT is created with full socket pair (in other words without using ranges, masks, wildcards for socket pair values, for the cases as specified in Section 8.1), then IKEv2 needs to be retriggered to get the new master key for the corresponding restarted TCP session. Chunduri, et al. Expires July 20, 2013 [Page 10] Internet-Draft Using IKEv2 with TCP-AO January 2013 3.5. Impact of Policy changes Once the routing session is secured by TCP-AO, any security policy changes initiated by the operator at RP MUST cause a tear down of the existing session and MUST be replaced with a new CHILD_SA at IKEV2 KMP and corresponding new MKT at TCP-AO. Similarly, any changes in the peer Authentication data at PAD MUST cause re-authentication of the peer at IKEv2 KMP with changed credentials and also due to this change, all CHILD_SAs/MKTs need to re-negotiated. 4. Extensions required for IKEv2 There can be two ways to derive a KMP that is suitable for TCP-based routing protocols: a. Create a new KMP for routing protocols, e.g., based on IKEv2 (as proposed in [mahesh-karp-rkmp]). b. Extend IKEv2 to be suitable for TCP-based routing protocols. In this section, we would like to explore option (b). This section summarizes the extensions required for IKEv2 to negotiate non-IPsec SAs for TCP-based routing protocols. The authors acknowledge that some of the items below are already discussed in KARP WG, but the details presented here are different. Routing protocols that use this extended IKEv2 KMP can continuously benefit from the new authentication methods and any other new features which might be added to [RFC5996]. 4.1. Non IPsec DOI IKEv2 is designed for performing mutual authentication with the peers and establishing and maintaining Security Associations for IPsec. IKEv2 defines the IKE_AUTH and CREATE_CHILD_SA exchanges, consisting of payloads and processing guidelines for IPsec Domain of Interpretation (DOI); this need to be generalized to exchange other protocol-specific parameters to be useful for RPs. IKEv2 is designed to be extensible with additional parameters. The extensions proposed here can be deployed within that context, running over the existing IKEv2 port number and using existing IKEv2 tunneling mechanisms where needed. The current IKEv2 CREATE_CHILD_SA exchange can be used to rekey the IKE SA and the master key. This document does not propose any Chunduri, et al. Expires July 20, 2013 [Page 11] Internet-Draft Using IKEv2 with TCP-AO January 2013 changes or extensions to re-establishing IKE SA through the CREATE_CHILD_SA exchange. 4.1.1. Security Association Extensions The IKEv2 Security Association (SA) payload is used to negotiate attributes of a Security Association. This payload contains multiple proposals, as configured in the routing protocol. Possible extensions to be made are: 1. A new Protocol ID, to be added in the proposal substructure with TCP-AO as new protocol (IANA-TBD). 2. An Integrity Algorithm (INTEG), as defined in the transform substructure needs to be mandated for the new TCP-AO Protocol. 3. Authentication algorithms and associated parameters as defined in [RFC5926] should be extended to the current list in IKEv2 Transform Type 3 (Integrity Algorithm), for TCP-AO usage (IANA- TBD). 4. The Diffie-Hellman group (D-H) transform type can be used for TCP-AO proposal as an optional transform. 5. A new transform type is needed to represent the KDF for traffic key derivation by TCP-AO (IANA-TBD) and also needs to be mandated for the new TCP-AO Protocol. KDF algorithms and associated parameters as defined in [RFC5926] should be listed for this new transform in IKEv2 for TCP-AO usage (IANA-TBD). 6. A new transform type is needed to represent the TCP-AO KeyIDs (IANA-TBD). The Initiator KeyID represents the SendID and the Responder KeyID represents the RecvID in the TCP-AO MKT. 7. A new transform type needs to be created to indicate TCP options coverage by TCP-AO (IANA-TBD). 8. The valid transform types (as defined in Section 3.3.3 of [RFC5996]) for TCP-AO with mandatory and optional types need to be listed. 9. Attribute negotiation rules need to be extended for TCP-AO protocol. Chunduri, et al. Expires July 20, 2013 [Page 12] Internet-Draft Using IKEv2 with TCP-AO January 2013 4.2. Simple Traffic Selectors Negotiation The Traffic Selectors defined in IKEv2 [RFC5996] have huge potential to negotiate the particular traffic to be secured, agreeable to both initiator and responder. For a routing protocol SA, traffic selectors negotiation presents a simple case and does not require any changes. A single connection or multiple connections with different source ports can be negotiated with a single CREATE_CHILD_SA exchange. The IP Protocol ID in the traffic selector field (as defined in Section 3.13.1 of [RFC5996]) can always be TCP for the routing protocol SAs. The above is an attempt to summarize the brief list of changes in this approach and this section will be revisited. 5. IANA Considerations This document requests that IANA to allocate new parameters as described in Section 4.1.1. 6. Security Considerations This document does not introduce any new security threats for IKEv2 [RFC5996] or TCP-AO [RFC5925]. For more detailed security considerations please refer the Security Considerations section of the KARP Design Guide [RFC6518] document as well as KARP threat document [I-D.ietf-karp-threats-reqs]. 7. Acknowledgements The authors would like to thank Joel Halpern for his initial discussions and providing feedback on the document. The authors also thank Tero Kivinin and Dan Harkins for reviewing the document and Ron Bonica for his initial requirement discussions. Thanks to Sam Hartman for his KARP working group discussions on this topic. The Gatekeeper module is originally proposed by Joe Touch. 8. Appendix A 8.1. BGP Multi Session and transport level differentiation [ietf-idr-bgp-multisession] describes MP-BGP, which uses multiple TCP sessions between a pair of BGP speakers. Each TCP session is used to Chunduri, et al. Expires July 20, 2013 [Page 13] Internet-Draft Using IKEv2 with TCP-AO January 2013 exchange routes related by some session-based attribute, such as AFI/ SAFI. The reason transport level distinction is required could be because of operator policy. Though it is less likely to see different MAC/KDF parameters for each of these sessions, it is possible rekey lifetimes or TCP option flags for TCP-AO can be different for each of these AFI/SAFI based sessions. If transport level separation is required for all sessions between a pair of BGP speakers, a unique and full socket pair (i.e., a local IP address, a remote IP address, a local TCP port, and a remote TCP port) MUST be known before establishing a TCP connection. The full socket pair is required for both unique MKT creation in TCP-AO, as well as for the KMP to negotiate unique Master keys for each connection. The use of different IP addresses to differentiate connections in multi session BGP is discouraged in [ietf-idr-bgp-multisession] and the destination port is always BGP. As a result, the only option for transport level differentiation is by knowing the source port of the connection being initiated. This is required to negotiate unique KMP SAs by the Gatekeeper, as well as to configure unique TCP-AO MKTs for each TCP connection. How source port lock-down is done is beyond the scope of this document (this is an implementation issue) and this can be achieved in many different ways before making the TCP connection. The Gatekeeper interface, defined in Section 3, is oblivious to this issue and can well accommodate this requirement. 8.2. Applicable Authentications methods One advantage that IKEv2 provides is the largest selection of key management and parameter coordination authentication methods suitable for various environments. The goal of this section is to look at various KMP authentication options available and recommend suitable options for use in negotiating keys and other parameters for routing protocol protection. As some of the authentication mechanisms are optional in IKEv2, one mandatory authentication mechanism from the list below needs to be selected for routing environments to ensure inter-operability and quicker adoption. This section attempts to summarize the available options and constraints surrounding the options. 8.2.1. Symmetric key based authentication IKEv2 [RFC5996] allows for authentication of the IKEv2 peers using a symmetric pre-shared key. For symmetric pre-shared key peer authentication, deployments need to consider the following as per Chunduri, et al. Expires July 20, 2013 [Page 14] Internet-Draft Using IKEv2 with TCP-AO January 2013 [RFC5996]: 1. Deriving a shared secret from a password, name, or other low- entropy source is not secure. These sources are subject to dictionary and social-engineering attacks, among others. 2. The pre-shared key should not be derived solely from a user- chosen password without incorporating another source of randomness. 3. If password-based authentication is used for bootstrapping the IKE_SA, then one of the EAP methods as described in Section 8.2.3 needs to be used. One of the IPsecME WG charter goals is to provide IKEv2 [RFC5996] a secure password authentication mechanism which is protected against off-line dictionary attacks, without requiring the use of certificates or Extensible Authentication Protocol (EAP), even when using the low-entropy shared secrets. There are couple of documents which try to address this issue and the work is still in progress. 8.2.2. Asymmetric key based authentication Another peer authentication mechanism for IKEv2 uses is asymmetric key certificates or public key signatures. This approach relies on a Public Key Infrastructure using X.509 (PKIX) Certificates. If this can be deployed for IKEv2 peer authentication, it will be one of the most secure authentication mechanisms. With this authentication option, there is no need for out-of-band shared keys between peers for mutual authentication. Apart from RSA and DSS digital signatures for public key authentication provided by IKEv2, [RFC4754] introduces Elliptic Curve Digital Signature Algorithm (ECDSA) signatures. ECDSA provides additional benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. 8.2.3. EAP based authentication In addition to supporting authentication using shared secrets and public key signatures, IKEv2 also supports authentication based on the Extensible Authentication Protocol (EAP), defined in [RFC3748]. EAP is an authentication framework that supports multiple authentication mechanisms. IKEv2 provides EAP authentication because public key signatures and shared secrets are not flexible enough to meet the requirements of many deployment scenarios. For KARP KMP, EAP-Only Authentication in IKEv2 as specified in [RFC5998] can be Chunduri, et al. Expires July 20, 2013 [Page 15] Internet-Draft Using IKEv2 with TCP-AO January 2013 explored. By using EAP, IKEv2 KMP can leverage existing authentication infrastructure and credential databases, because EAP allows users to choose a method suitable for existing credentials. Routing protocols today use password-based pre-shared keys to integrity protect the routing protocol messages. The same pre-shared key can be used to bootstrap the KMP and as a potential authentication key in KMP. With appropriate password based EAP methods, stronger keys can be generated without using certificates. For authenticating the nodes running routing protocols, EAP and the IKEv2 endpoints are co-located (so no separate EAP server required). When EAP is deployed, authenticating the IKEv2 responder using both EAP and public key signatures could be redundant. EAP methods that offer mutual authentication and key agreement can be used to provide responder authentication in IKEv2 completely based on EAP. Section 4 of [RFC5998] lists safe EAP methods to support EAP_ONLY_AUTHENTICATION. For routing protocols deployment, because an EAP server is co-located with IKEv2 responder, channel binding capability of the selected EAP method is irrelevant. Various qualified mutual authentication methods are listed in [RFC5998]; of these, a password based methods [RFC4746], [RFC5931], [RFC6124] can offer potential EAP alternative for pre-shared key only authentication. From the list above, Encrypted Key Exchange (EKE) as described in [RFC6124] is relatively lightweight and provides mutual authentication. This method also offers secure and robust authentication, even with an operator provisioned weak password in the presence of a strong adversary. 9. References 9.1. Normative References [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. Chunduri, et al. Expires July 20, 2013 [Page 16] Internet-Draft Using IKEv2 with TCP-AO January 2013 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010. 9.2. Informative References [I-D.ietf-idr-bgp-multisession] Scudder, J., Appanna, C., and I. Varlashkin, "Multisession BGP", draft-ietf-idr-bgp-multisession-07 (work in progress), September 2012. [I-D.ietf-karp-crypto-key-table] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", draft-ietf-karp-crypto-key-table-04 (work in progress), October 2012. [I-D.ietf-karp-routing-tcp-analysis] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide", draft-ietf-karp-routing-tcp-analysis-06 (work in progress), December 2012. [I-D.ietf-karp-threats-reqs] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", draft-ietf-karp-threats-reqs-07 (work in progress), December 2012. [I-D.mahesh-karp-rkmp] Jethanandani, M., Zhang, D., Weis, B., Patel, K., and S. Hartman, "Key Management for Pairwise Routing Protocol", draft-mahesh-karp-rkmp-00 (work in progress), October 2011. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Chunduri, et al. Expires July 20, 2013 [Page 17] Internet-Draft Using IKEv2 with TCP-AO January 2013 Key Management", BCP 107, RFC 4107, June 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication Protocol (EAP) Password Authenticated Exchange", RFC 4746, November 2006. [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, August 2010. [RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol", RFC 6124, February 2011. [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012. Authors' Addresses Uma Chunduri Ericsson Inc. 300 Holger Way San Jose, California 95134 USA Phone: +1 (408) 750-5678 Email: uma.chunduri@ericsson.com Chunduri, et al. Expires July 20, 2013 [Page 18] Internet-Draft Using IKEv2 with TCP-AO January 2013 Albert Tian Ericsson Inc. 300 Holger Way San Jose, California 95134 USA Phone: +1 (408) 750-5210 Email: albert.tian@ericsson.com Joe Touch USC/ISI 4676 Admiralty Way, Marina del Rey, California 90292-6695 USA Phone: +1 (310) 448-9151 Email: touch@isi.edu Chunduri, et al. Expires July 20, 2013 [Page 19]