Working Group U. Chunduri Internet-Draft A. Tian Intended status: Informational Ericsson Inc. Expires: April 8, 2013 October 5, 2012 KARP KMP: Simplified Peer Authentication draft-chunduri-karp-kmp-router-fingerprints-01 Abstract This document describes the usage of Router Fingerprint Authentication (RFA) with public keys as a potential peer authentication method with KARP Key Management Protocol (KMP). The advantage of RFA is, neither it requires out-of-band, mutually agreeable symmetric keys nor a full PKI based system (trust anchor or CA certificates) for mutual authentication of the peers with KARP KMP deployments. Usage of Router Fingerprints give a significant operational improvement from symmetric key based systems and yet provide a secure authentication technique. 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 8, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Chunduri & Tian Expires April 8, 2013 [Page 1] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 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 . . . . . . . . . . . . . . . . . . . 4 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Router Fingerprint . . . . . . . . . . . . . . . . . . . . . . 4 3. Usage of Router Fingerprints with KARP KMP . . . . . . . . . . 5 3.1. Impact on the PAD . . . . . . . . . . . . . . . . . . . . . 6 4. Publishing Router Fingerprints . . . . . . . . . . . . . . . . 6 5. Scope of Fingerprints usage with RPs . . . . . . . . . . . . . 6 6. Fingerprint Revocation . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Chunduri & Tian Expires April 8, 2013 [Page 2] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 1. Introduction A Key Management Protocol (KMP) framework for TCP-based pair wise routing protocols (BGP [RFC4271], PCEP [RFC5440], MSDP [RFC3618] and LDP [RFC5036]) is detailed in [chunduri-karp-using-ikev2-with-tcp-ao]. Usage of IKEv2[RFC5996] as the KMP is also described in the same document. This draft explores a simple and secure authentication method, which can be used for KARP KMP deployments. Currently operators don't often change the manual keys deployed for protecting the Routing Protocol (RP) messages because of various reasons as noted in Section 2.3 of KARP threat document [I-D.ietf- karp-threats-reqs]. One of the KARP WG goals is to define mechanisms to support key changes for all RPs which use either Manual Key Management (MKM) or KMP with out much operational overhead. Apart from Peer's identity verification, authentication and parameter negotiation, deployment of KMP can be more useful, when it comes to rekey the keys used by RPs. Rekeying can be achieved with out the operator's intervention and as per the provisioned rekey policy. But for the operators, usage of IKEv2 KMP opens up numerous possibilities for peer authentication and manual symmetric keys not only to bootstrap KMP but used for peer authentication. Various other peer authentication mechanisms with the advantages/drawbacks of each mechanisms are described in the Appendix of the [chunduri-karp-using- ikev2-with-tcp-ao] document. If symmetric pre-shared keys are used by IKEv2 KMP to authenticate the peer before generating the shared key(s), apart from the other issues with symmetric keys, the problem still remain the same when it comes to changing these keys. To reduce the operational costs for changing the keys at peering points with relatively large number of peers for various TCP based RPs, this document describes the use of one of the available IKEv2 KMP peer authentication methods with raw or x.509 encoded public keys (to be called as Router Fingerprints in the rest of the document). Router Fingerprint Authentication (RFA) mechanism in conjunction with KARP KMP require neither out-of-band symmetric keys nor a fully functional PKI based system with trust anchor certificates as explained further in Section 2. Section 2 describes the Router Fingerprints in the context of various KMPs and specifically for IKEv2 KMP. Generation and usage of the Router Fingerprints is described in Section 3 and Section 4 describes an error free method for publishing the Router Fingerprints. Chunduri & Tian Expires April 8, 2013 [Page 3] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 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 CRL - Certificate Revocation List. EBGP - External BGP (BGP connection between external peers). EE - End Entity. IBGP - Internal BGP (BGP connection between internal peers). KMP - Key Management Protocol (auto key management). MKM - Manual Key management Protocols. PAD - Peer Authorization Database. RFA - Router Fingerprint Authentication. RP - Routing Protocol. 2. Router Fingerprint Router Fingerprint is a sequence of bytes used to authenticate the public key before using the same to authenticate the peer in the context of KMP. Various forms of the fingerprint mechanism based on the public keys are already in use as defined in [RFC4252] and [RFC4253]. Fingerprints are also used primarily for root key authentication in x.509 based PKI [RFC5280]. This documents only highlights the usage of raw public key based authentication mechanism already defined in [RFC5996] for KARP deployments. To generate a fingerprint: 1. A router needs to generate an asymmetric Private/Public key pair. Asymmetric crypto algorithms based on RSA [RFC3447] or for shorter and still secure keys Elliptic Curve Cryptography (ECC) [RFC4492] can be used for generating the Private/Public key pair. Chunduri & Tian Expires April 8, 2013 [Page 4] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 2. Once the Asymmetric key pair is generated, the public key can be encoded with any additional data (specific to the router) and can be in the form of more easily administrable X.509 PKI Certificate profile and to be specific as specified in the SubjectPublicKeyInfo structure in Section 4.1 of [RFC5280]. This does not force use of X.509 or full compliance with [RFC5280] since formatting any public key as a SubjectPublicKeyInfo is relatively straightforward and well supported by libraries. 3. The result should be hashed with a cryptographic hash function, preferably SHA-256 or hash functions with similar strength (see more discussion on choosing preferred hash function in Section 8). The fingerprint generated is not a secret and can be distributed publicly. This is further discussed in Section 4. 3. Usage of Router Fingerprints with KARP KMP To use Router Fingerprints authentication with KARP KMP, a Private/ Public key-pair MUST be generated by the router as specified in Section 2. Base IKEv2 [RFC5996] standard supports only raw RSA based public keys. The type of the public keys and encoding has to be more generic to deploy this peer authentication method. With current specification [RFC5996] when sender needs to get the certificate of the receiver, Certificate Request payload (CERTREQ as specified in [RFC5996]) is sent with cert encoding set to "Raw RSA Key" and Certification Authority field is empty. The receiver of this CERTREQ payload, (currently) uses PKCS #1 encoding for the generated RSA Public Key and sends the same in CERT payload as Certificate Data with Certificate Encoding set to "Raw RSA Key" as described in Section 3.6 of IKEv2 [RFC5996]. Once the public key of the sender is received, the verification MUST be done with the already published/stored fingerprints of the sender. As noted above the current IKEv2[RFC5996] specification only supports raw RSA public keys. [I-D.kivinen-ipsecme-oob-pubkey] enhances support for other types of public keys and also defines new encoding format to carry the public key fingerprint in the CERT payload. For RPs to use Router Fingerprint Authentication in the context of IKEv2 MUST follow the encoding format as specified in [I-D.kivinen-ipsecme- oob-pubkey]. Chunduri & Tian Expires April 8, 2013 [Page 5] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 3.1. Impact on the PAD The Peer Authorization Database (PAD) and the role it plays in peer authentication is defined in section 4.4.3 of [RFC4301]. One of the functions of the PAD is to provide the authentication data for each peer. [RFC4301] supports X.509 certificate or pre-shared secret authentication data types. So, it is necessary (and one more reason) to encode the raw public keys as X.509 certificates before sending the same in CERT payload. Though the public key received is in the form of x.509 certificate, for RFA, the PAD entry need not contain a trust anchor via which the end entity (EE) certificate or the public key for the peer must be verifiable. The PAD entry MUST rather contain the published fingerprint of the peer. 4. Publishing Router Fingerprints The router fingerprint generated is not a secret and can be exchanged out-of-band or can be distributed publicly. Please refer to Section 5 for the generic usage and scope of the RFA in routing environments. In the case of inter-domain routing using EBGP [RFC4271] and if the routers are outside of the SIDR [I-D.ietf-sidr- bgpsec-overview] environment, fingerprint can also be exchanged out- of-band through Service Level Agreements (SLAs) at the RP peering points. A KARP KMP deployment using router fingerprints need to resort to out-of-band public key validation procedure to verify authenticity of the keys being used. The router fingerprints should be part of the KMP PAD to validate the public key received in the KMP messages. For conveying router fingerprints data bytes in a clear unambiguous way PGP (Pretty Good Privacy) wordlists can be used. 5. Scope of Fingerprints usage with RPs The fingerprint method described in this document in general is more suitable for intra domain deployments. This includes KMP usage for E.g., for IBGP [RFC4271] and LDP [RFC5036] peers, where KARP KMP can be deployed with out having to configure either manual pre-shared keys to bootstrap KMP or full PKI with trust anchor certificates. This method also can be potentially used between EBGP [RFC4271] speakers outside of the SIDR ([I-D.ietf-sidr-bgpsec-overview]) deployment scope, where full PKI infrastructure is not available to deploy with KARP KMP and at the same time, still operators want to avoid provisioning manual keys. Chunduri & Tian Expires April 8, 2013 [Page 6] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 6. Fingerprint Revocation The idea of RFA in the context of KARP KMP is to deploy a better authentication mechanism than the mutually shared symmetric keys between two routers. This SHOULD be used especially where number of peers using this method is relatively smaller and operationally manageable. Any changes in the router fingerprints SHOULD be administered manually by the operator. When there are a large number of peers, the need for router fingerprint changes may increase. This may be for reasons of key compromises or other potential changes to the routers. In such environments, operators SHOULD look to full PKI with trust anchor certificates and CRL profiles as specified in the [RFC5280]. In this context, RFA mechanism should be only seen as substantial improvement from mutually shared manual keying authentication methods. 7. IANA Considerations This document defines no new namespaces. 8. Security Considerations If collision attacks are perceived as a threat, the hash function to generate the fingerprints SHOULD also possess the property of collision-resistance. To mitigate preimage attacks, the cryptographic hash function used for a fingerprint SHOULD possess the property of second preimage resistance. If generated fingerprints are truncated to make those short, the truncated fingerprints MUST be long enough to preserve the relevant properties of the hash function against brute-force search attacks. Considering the above facts, it's recommended to use SHA-256 or similar hash functions with good security properties to generate the fingerprints. 9. Acknowledgements The authors would like to thank Jari Arkko for initial and valuable discussions on operationally simplified authentication mechanisms in general and RFA mechanism as described in this document in particular. Authors would like to acknowledge Joel Halpern for supporting this work and providing continuous feedback on the draft, including the usefulness of this approach in routing environments. Chunduri & Tian Expires April 8, 2013 [Page 7] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 Thanks to Tero Kivinen for extended discussions on applicability and usage of authentication method described for KARP KMP. 10. References 10.1. Normative References [I-D.chunduri-karp-using-ikev2-with-tcp-ao] Chunduri, U., Tian, A., and J. Touch, "Using IKEv2 with TCP-AO", draft-chunduri-karp-using-ikev2-with-tcp-ao-01 (work in progress), March 2012. [I-D.kivinen-ipsecme-oob-pubkey] Kivinen, T., Wouters, P., and H. Tschofenig, "More Raw Public Keys for IKEv2", draft-kivinen-ipsecme-oob-pubkey-00 (work in progress), March 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 10.2. Informative References [I-D.ietf-karp-threats-reqs] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", draft-ietf-karp-threats-reqs-05 (work in progress), May 2012. [I-D.ietf-sidr-bgpsec-overview] Lepinski, M. and S. Turner, "An Overview of BGPSEC", draft-ietf-sidr-bgpsec-overview-02 (work in progress), May 2012. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. Chunduri & Tian Expires April 8, 2013 [Page 8] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [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. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [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 & Tian Expires April 8, 2013 [Page 9] Internet-Draft KARP KMP: Simplified Peer Authentication October 2012 Albert Tian Ericsson Inc. 300 Holger Way San Jose, California 95134 USA Phone: +1 (408) 750-5210 Email: albert.tian@ericsson.com Chunduri & Tian Expires April 8, 2013 [Page 10]