Working Group U. Chunduri Internet-Draft A. Tian Intended status: Informational Ericsson Inc., Expires: April 27, 2012 October 25, 2011 Using IKEv2 with TCP-AO draft-chunduri-karp-using-ikev2-with-tcp-ao-00 Abstract This document analyzes the TCP based pairwise Routing Protocol (RP) requirements for IKEv2 Key Management Protocol (KMP). This document discusses the various authentication methods available for peer authentication in IKEv2 KMP and the specific Security Association (SA) requirements for IKEv2 protocol to protect the TCP based pairwise RPs. 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 27, 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 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 Chunduri & Tian Expires April 27, 2012 [Page 1] Internet-Draft Using IKEv2 with TCP-AO October 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicable Authentications methods . . . . . . . . . . . . . . 4 2.1. Symmetric key based authentication . . . . . . . . . . . . 4 2.2. Asymmetric key based authentication . . . . . . . . . . . 5 2.3. EAP based authentication . . . . . . . . . . . . . . . . . 5 3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. RP interface to TCP-AO . . . . . . . . . . . . . . . . . . 6 3.2. TCP-AO interface to KMP . . . . . . . . . . . . . . . . . 6 4. Extensions required for IKEv2 protocol . . . . . . . . . . . . 7 4.1. Non IPSec DOI . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Security Association Extensions . . . . . . . . . . . 8 4.2. Simple Traffic Selectors Negotiation . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Chunduri & Tian Expires April 27, 2012 [Page 2] Internet-Draft Using IKEv2 with TCP-AO October 2011 1. Introduction Threat analysis for TCP based routing protocols (BGP [RFC4271], PCEP [RFC5440], MSDP [RFC3618] and LDP [RFC5036]) is detailed in [ietf- karp-routing-tcp-analysis]. KARP design guide [ietf-karp-design- guide] suggests various requirements and options for getting keys to protect the routing protocols and recommends using KMP to automate the key establishment and rekeying to protect the routing protocols. This document analyzes the TCP based pairwise Routing Protocol (RP) requirements for IKEv2[RFC5996] Key Management Protocol (KMP). 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 raft of authentications methods, Section 2 discusses various Symmetric, Asymmetric and EAP based KMP authentication options available for all TCP based routing protocols. This document also provides guidelines for designing suitable approach for routing environments. This document analyzes one approach, which minimizes the changes for routing protocols (BGP, PCEP, MSDP and LDP) to be integrated with KMP. This document defines the interface between all TCP based pairwise routing protocols and the TCP-AO [RFC5925]. The interface between IKEv2 KMP and the TCP-AO for session parameter negotiation, key establishment and rekeying is also defined in Section 3. Currently IKEv2 can establish only Security Association (SA) for IP Security (IPSec). Few extensions are needed for IKEv2 to establish SA for TCP based routing protocols that use TCP-AO. Section 4 discusses a brief summary of the extensions required for IKEv2 protocol for key establishment, traffic selectors negotiation and Security Association (SA) establishment for TCP based routing protocols. 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]. 1.2. Acronyms EAP - Extensible Authentication Protocol Chunduri & Tian Expires April 27, 2012 [Page 3] Internet-Draft Using IKEv2 with TCP-AO October 2011 KDF - Key Derivation Function KMP - Key Management Protocol (auto key management) MKM - Manual Key management Protocols NONCE - Number Once 2. Applicable Authentications methods One advantage that IKEv2 provides is the largest selection of authentication methods suitable for various environments. The goal of this section is to look at various KMP authentications options available and recommend suitable options for deployment with routing protocols. As some of the authentication mechanisms are optional in IKEv2, one mandatory authentication mechanism from the list below need 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. 2.1. Symmetric key based authentication IKEv2 [RFC5996] allow for authentication of the IKEv2 peers using a symmetric pre-shared key. For symmetric pre-shared key based peer authentication, the deployments need to consider the following as per [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 for bootstrapping the IKE_SA, then one of the EAP methods as described in Section 2.3 need 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. Chunduri & Tian Expires April 27, 2012 [Page 4] Internet-Draft Using IKEv2 with TCP-AO October 2011 2.2. Asymmetric key based authentication Another peer authentication mechanism for IKEv2 is with asymmetric key certificates or public key signatures. This approach will use the 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 key between the 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. 2.3. EAP based authentication In addition to supporting authentication using shared secrets and public key signatures, IKEv2 also supports authentication based on Extensible Authentication Protocol (EAP), defined in [RFC3748]. EAP is an authentication framework that supports multiple authentication mechanisms. IKEv2 provides EAP authentication since it was recognized that 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 explored. By using EAP, IKEv2 KMP can leverage existing authentication infrastructure and credential databases, since EAP allows users to choose a method suitable for existing credentials. Routing protocols today use password based pre-shared key 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 (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, as EAP server is co-located with IKEv2 responder, channel binding capability Chunduri & Tian Expires April 27, 2012 [Page 5] Internet-Draft Using IKEv2 with TCP-AO October 2011 of the selected EAP method is irrelevant. Various qualified mutual authentication methods are listed in [RFC5998] and out of these, password based methods [RFC4746], [RFC5931], [RFC6124] can offer potential EAP alternative for pre-shared key only authentication. Out of the list above, Encrypted Key Exchange (EKE) as described in [RFC6124] is relatively light weight and provides mutual authentication. This method also offers a secure and robust authentication, even with a operator provisioned weak password in the presence of a strong adversary. 3. Interfaces Section 1.2 of TCP-AO [RFC5925] says "..we recommend the use of IPsec and IKE, especially where IKE's level of existing support for parameter negotiation, session key negotiation, or rekeying are desired." - but such interface is not defined. As IKEv2 [RFC5996] is being discussed as the potential KMP for routing protocols, this section defines the interface between IKEv2 KMP and TCP-AO. This section also analyzes the interface between TCP based routing protocols (BGP, LDP, MSDP, PCEP) and the TCP-AO module. 3.1. RP interface to TCP-AO When a routing protocol is configured to use KMP (by not specifying the keys or through some other means), configured authentication algorithms and rekey life time is provisioned in the TCP-AO MKT. This can be achieved at the time of opening the socket. With this, the MKT created in TCP-AO contains all the configured information other than the keys to protect the underlying session. 3.2. TCP-AO interface to KMP There needs to be a way to trigger the KMP to initiate negotiation with provisioned parameters, to rekey and to maintain the negotiated sessions. In this section, we define a common interface between TCP-AO and KMP that can be used by all TCP based routing protocols. (An alternative approach is to define an interface for each routing protocols to trigger KMP directly. This alternative is not of scope for this document.) Following are the details of the interface between TCP-AO and KMP: 1. When the first SYN packet on the session is initiated, a trigger to negotiate the session specific parameters with all provisioned authentication algorithms and optionally key lifetime should be given to KMP. Chunduri & Tian Expires April 27, 2012 [Page 6] Internet-Draft Using IKEv2 with TCP-AO October 2011 2. A KMP session identifier need to be stored and should be used for rekeying the existing session. 3. MKT IDs as specified in Section 3.1 of TCP-AO [RFC5925], requires 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 MKT when the KMP key(s) are populated in MKT. 4. KMP negotiated authentication algorithm and optionally life time for traffic keys for each session, need to be populated in MKT. 5. Trigger may also be needed at the time of rekeying any particular session. Implementations can pro-actively negotiate new traffic keys before the life time of current traffic keys expire. 4. Extensions required for IKEv2 protocol There can be two ways to derive a KMP that is suitable for TCP based routing protocols: a. To create a new KMP for routing protocols based on IKEv2 as proposed in [mahesh-karp-rkmp]. b. Extend IKEv2 to make it 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. Authors acknowledge, some of the items below are already discussed in KARP WG but the details presented here are different. Routing protocols by deploying extended IKEv2 KMP, can continuously benefit from the new authentication methods and any other new features which might be added. 4.1. Non IPSec DOI IKEv2 is designed for performing mutual authentication with the peer and establishing and maintaining Security Associations for IPSec. IKEv2 defined IKE_AUTH and CREATE_CHILD_SA exchange, consist of payloads, and processing guidelines for IPSec Domain of Interpretation (DOI) and this need to be generalized to exchange other protocol specific parameters. IKEv2 CREATE_CHILD_SA exchange today can also be used to rekey the IKE SA and the master key. This document do not propose any changes Chunduri & Tian Expires April 27, 2012 [Page 7] Internet-Draft Using IKEv2 with TCP-AO October 2011 or extensions to re-establishing IKE SA through CREATE_CHILD_SA exchange. 4.1.1. Security Association Extensions The Security Association (SA) payload, is used to negotiate attributes of a Security Association. This contains multiple proposals as configured in the routing protocol. Possible extensions to be made are: 1. Protocol ID, to be added in the proposal substructure with TCP-AO as new protocol. 2. Integrity Algorithm (INTEG), defined in the transform substructure need to be mandated for the new TCP-AO Protocol. Authentication algorithms as defined in [RFC5926] should be extended to the current list in IKEv2. 3. New transform type need to be created to represent the TCP-AO KeyIDs. Initiator KeyID represents the SendID and the Responder KeyID represents the RecvID in the TCP-AO MKT. 4. Diffie-Hellman group (D-H) transform type can be used for TCP_AO proposal as an optional transform. 5. Valid transform types for TCP-AO with mandatory and optional types need to be listed. Attribute negotiation rules need to be extended for TCP-AO protocol. 4.2. Simple Traffic Selectors Negotiation The Traffic Selectors defined in IKEv2 [RFC5996] has huge potential to negotiate the particular traffic to be secured, agreeable to both initiator and responder. But for routing protocol SA, traffic selectors negotiation present a simple case and does not require any changes. A single connection or multiple connections with a different source port to be protected, can be negotiated with one 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 with the approach and this section will be revisited further. 5. IANA Considerations This document defines no new namespaces. Chunduri & Tian Expires April 27, 2012 [Page 8] Internet-Draft Using IKEv2 with TCP-AO October 2011 6. Security Considerations This document does not introduce any new security threats for IKEv2 [RFC5925] or TCP-AO [RFC5996] protocol. For more detailed security considerations please refer the Security Considerations section of the KARP Design Guide [I-D.ietf-karp-design-guide] document as well as KARP threat document [I-D.ietf-karp-threats-reqs]. 7. Acknowledgements The authors would like to thank Joel Halpern for initial discussions and providing feedback on the document. 8. References 8.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. [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. 8.2. Informative References [I-D.ietf-karp-design-guide] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", draft-ietf-karp-design-guide-02 (work in progress), March 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 Chunduri & Tian Expires April 27, 2012 [Page 9] Internet-Draft Using IKEv2 with TCP-AO October 2011 Guide", draft-ietf-karp-routing-tcp-analysis-00 (work in progress), June 2011. [I-D.ietf-karp-threats-reqs] Lebovitz, G., Bhatia, M., and R. White, "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", draft-ietf-karp-threats-reqs-03 (work in progress), June 2011. [I-D.mahesh-karp-rkmp] Jethanandani, M., Weis, B., Patel, K., Zhang, D., 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 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. [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. Chunduri & Tian Expires April 27, 2012 [Page 10] Internet-Draft Using IKEv2 with TCP-AO October 2011 [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. Authors' Addresses Uma Chunduri Ericsson Inc., 300 Holger Way, San Jose, California 95134 USA Phone: 408 750-5678 Email: uma.chunduri@ericsson.com Albert Tian Ericsson Inc., 300 Holger Way, San Jose, California 95134 USA Phone: 408 750-5210 Email: albert.tian@ericsson.com Chunduri & Tian Expires April 27, 2012 [Page 11]