[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 03 04 05

Working Group                                                U. Chunduri
Internet-Draft                                                   A. Tian
Intended status: Informational                             Ericsson Inc.
Expires: January 31, 2013                                  July 30, 2012


                KARP KMP: Simplified Peer Authentication
             draft-chunduri-karp-kmp-router-fingerprints-00

Abstract

   This document describes the usage of Router Fingerprint
   Authentication (RFA) with public keys.  This can be used as a peer
   authentication method with KARP Key Management Protocol (KMP).  KARP
   KMP automates key negotiation for securing TCP-based pairwise Routing
   Protocols (RPs) like BGP, LDP.  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 January 31, 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



Chunduri & Tian         Expires January 31, 2013                [Page 1]


Internet-Draft  KARP KMP: Simplified Peer Authentication       July 2012


   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 . . . . . . . . . . . . . . . . . . . 4
     1.2.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Router Fingerprint  . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Usage of Router Fingerprints with KARP KMP  . . . . . . . . . . 5
   4.  Impact on the PAD . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Publishing Router Fingerprints  . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8



























Chunduri & Tian         Expires January 31, 2013                [Page 2]


Internet-Draft  KARP KMP: Simplified Peer Authentication       July 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, the usage of IKEv2 KMP opens up numerous possibilities for peer
   authentication.  Various 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 100s of peers, 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 5 describes
   an error free method for publishing the Router Fingerprints.







Chunduri & Tian         Expires January 31, 2013                [Page 3]


Internet-Draft  KARP KMP: Simplified Peer Authentication       July 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

   EE      -  End Entity

   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 need 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.

   2.  Once the Asymmetric key pair is generated, if needed, the public
       key can be in the form of raw public key as specified in
       [RFC5996] or 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 [RFC5280].





Chunduri & Tian         Expires January 31, 2013                [Page 4]


Internet-Draft  KARP KMP: Simplified Peer Authentication       July 2012


   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 7).

   The fingerprint generated is not a secret and can be distributed
   publicly.  This is further discussed in Section 5.


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, 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].


4.  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 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



Chunduri & Tian         Expires January 31, 2013                [Page 5]


Internet-Draft  KARP KMP: Simplified Peer Authentication       July 2012


   peer must be verifiable.  The PAD entry MUST rather contain the
   published finger print of the peer.


5.  Publishing Router Fingerprints

   The router fingerprint generated is not a secret and can be exchanged
   out-of-band through Service Level Agreements (SLAs) at the RP peering
   points or can be distributed publicly.  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 Peer Authorization
   Database (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.


6.  IANA Considerations

   This document defines no new namespaces.


7.  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.


8.  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.  Thanks to Tero Kivinen for extended discussion on
   applicability and usage of authentication method described for KARP
   KMP.  Thanks to Joel Halpern for supporting this work and providing
   continuous feedback.



Chunduri & Tian         Expires January 31, 2013                [Page 6]


Internet-Draft  KARP KMP: Simplified Peer Authentication       July 2012


9.  References

9.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.

9.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.

   [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.

   [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.



Chunduri & Tian         Expires January 31, 2013                [Page 7]


Internet-Draft  KARP KMP: Simplified Peer Authentication       July 2012


   [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


   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 January 31, 2013                [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/