Network Working Group                                           D. Zhang
Internet-Draft                                                    Huawei
Intended status: Experimental                                 S. Hartman
Expires: January 4, 2012                               Painless Security
                                                            July 3, 2011


             Unicast Router Key Management Protocol (RKMP)
                      draft-zhang-karp-rkmp-00.txt

Abstract

   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 (RKMP) for establishing and managing such
   keys for routing protocols.

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

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



Zhang & Hartman          Expires January 4, 2012                [Page 1]


Internet-Draft                    RKMP                         July 2011


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.2.  Relationship to IKEv2 . . . . . . . . . . . . . . . . . . . 3
     1.3.  Multicast as an Additional Feature  . . . . . . . . . . . . 4
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.1.  Types of Keys . . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Initial Exchanges . . . . . . . . . . . . . . . . . . . . . 4
     2.3.  Child SA Exchange . . . . . . . . . . . . . . . . . . . . . 5
   3.  Initial Exchange Details  . . . . . . . . . . . . . . . . . . . 6
   4.  Child SA Exchange Details . . . . . . . . . . . . . . . . . . . 7
   5.  Interfaces  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9





















Zhang & Hartman          Expires January 4, 2012                [Page 2]


Internet-Draft                    RKMP                         July 2011


1.  Introduction

   Unicast and multicast both are common communication models adopted by
   routing protocols in exchanging routing messages.  Using unicast, a
   message is expected to be sent to a single receiver identified by a
   unique address, while using multicast the same message is sent to a
   number of recipients.

   In [I-D.hartman-karp-mrkmp], an automatic group key management
   mechanism is proposed for securing multicast routing message
   exchanges (MRKMP).  This draft propose a complementary Router Key
   Management Protocol for securing unicast routing messages (RKMP).

   Existing routing protocols using unicast (e.g., BGP, LDP, RSVP-TE)
   have cryptographic authentication mechanisms that use a key shared
   between the routers on the both sides of the communication to protect
   unicast routing message exchanges between the routers.

   RKMP assumes that routers need to be provisioned with some
   credentials for a one-to-one authentication protocol.  Preshared 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, before sending out any routing protocol packets two
   routers needs to perform mutual authentication using their
   provisioned credentials.  If successful, two routers negotiate the
   key material to securing the routing protocol execution.

1.1.  Terminology

1.2.  Relationship to IKEv2

   IKEv2 [RFC4306] provides a protocol for authenticating IPsec security
   associations between two peers.  It currently provides no group
   keying.  IKEv2 is attractive as a basis for this protocol because
   while it is much simpler than IKE [RFC2409], it provides all the
   needed flexibility in one-to-one authentication.

   Unlike IKE, IKEv2 is explicitly designed for IPsec.  The document
   does not separate handling of aspects of the protocol that would be
   needed for IPsec from those that apply to general key management.
   IPsec specific rules are combined with more general requirements.
   While concepts and protocol payloads can be used in a different key
   management protocol, the current structure of IKEv2 does not provide
   a mechanism for applying IKEv2 to a domain of interpretation other
   than IPsec.  In addition, the complexity required in the IKE
   specification when compared to IKEv2 suggests that the generality of



Zhang & Hartman          Expires January 4, 2012                [Page 3]


Internet-Draft                    RKMP                         July 2011


   IKE may not be worth the complexity cost.

   So this protocol borrows concepts and payloads from IKEv2 but does
   not normatively depend on the IKEv2 specification.

1.3.  Multicast as an Additional Feature

   The base RKMP proposed in this draft aims for automatically
   generating keys to secure unicast routing messages.  However, it can
   be easily extended to support authenticating multicast communications
   among routers.  In [I-D.hartman-karp-mrkmp], the extension of RKMP in
   supporting multicast called MRKMP is introduced.  RKMP and MRKMP can
   be combined to construct a integrated key management solution
   supporting both unicast and multicast.


2.  Overview

2.1.  Types of Keys

   The keys adopted in RKMP is listed as follows:

   PSK (Pre-Shared Key) : PSKs are pair-wise unique keys used for
   authenticating one router to the other one during the initial
   exchange.  These keys are configured by some mechanism such as manual
   configuration or a management application outside of the scope of
   RKMP.

   Protocol master key: A protocol master key is the key exported by
   RKMP for use by a routing protocol such as BGP.  This is the key that
   is shared in the key table between the routing protocol and RKMP.

   Transport key: A transport key is the key used to integrity protect
   routing messages in a protocol such as BGP.  In today's routing
   protocol cryptographic authentication mechanisms the transport key
   can be the same as the protocol master key.

2.2.  Initial Exchanges

   When a router intends to send an routing message to a remote one but
   there is no valid RKMP_SA shared between the router and its partner,
   the router will perform initial exchanges with its partner to derive
   .

   The initial exchanges is based on IKEv2's IKE_SA_INIT and IKE_SA_AUTH
   exchanges, which are referred to as RKMP_SA_INIT and RKMP_SA_AUTH
   exchanges respectively.  During the initial exchanges, an initiating
   router attempts to authenticate to the router which it intends to



Zhang & Hartman          Expires January 4, 2012                [Page 4]


Internet-Draft                    RKMP                         July 2011


   exchange unicast routing messages with.  Messages are unicast from
   the initiator to the responding router.  Unicast RKMP messages form a
   request/response protocol; the party sending the messages is
   responsible for retransmissions.

   The initial exchanges provide capability negotiation, specifically
   including supported cryptographic suites for the key management
   protocol.  Identification of the initiator and responder is also
   exchanged.  A symmetric key is established to provide integrity,
   confidenality and authenticity protection for key management
   messages.  These negotiation results compose a RKMP SA.  While
   routing security does not typically require confidentiality, the key
   management protocol does because keys are exchanged and these must be
   protected.

   During authentcation, the identity of each party is cryptographically
   verified.  This can be done using, e.g., a preshared key, asymmetric
   keys or self-signing certificates.  Other mechanisms may be added as
   a future extension.

   The authentication exchange can also generate a SA for a routing
   protocol (called a child SA generally) .  In the typical case, a
   router can obtain the needed key material (e.g., protocol master keys
   and maybe transport keys) for securing the desired routing protocol
   which in two round-trips.

2.3.  Child SA Exchange

   The child SA exchange is analogous to the CREATE_CHILD_SA exchange in
   IKEv2 and consists of a single request/response pair.  However, the
   CREATE_CHILD_SA exchange in IKEv2 is designated for IPsec while the
   child SA exchange can be used to generate SAs to secure various
   routing protocols.

   A child SA exchange can be triggered in order to 1) rekey an antique
   protocol master key and establish a new equivalent one, 2) generate
   needed key material for a newly executed routing protocol based on an
   existing RKMP_SA, or 3) rekey an RMKP_SA and establish a new
   equivalent RMKP_SA.

   A child SA exchange MAY be initiated by either end of the RKMP_SA
   after the initial exchanges are completed.  All messages in a child
   SA exchange are cryptographically protected using the cryptographic
   algorithms and keys negotiated in the the initial exchange.







Zhang & Hartman          Expires January 4, 2012                [Page 5]


Internet-Draft                    RKMP                         July 2011


3.  Initial Exchange Details

   In the remainder of this document, the notations of the payloads
   contained in the messages are consistent with what have defined in
   Section 1.2 of [RFC4306].

   The initial exchanges are decrypted as follows:

   The payloads included in the first pair of exchanged messages (i.e.,
   the RKMP_SA_INIT exchange) are identical to what have been specified
   in the IKE_SA_INIT exchange [RFC4306].  During the RKMP_SA_INIT
   exchange, the two communicating partners needs to identify the
   cryptographic suite they both support, exchange nonces in order to
   check each other's aliveness, and exchange their public keys.  After
   the exchange, both partners can use the Diffie-Hellman algorithm to
   agree upon a shared secret from which all keys for securing
   subsequent messages are derived.
          Initiator                          Responder
          -----------                        -----------
       HDR, SAi1, KEi, Ni      -->

                                   <-- HDR, SAr1, KEr, Nr, [CERTREQ]

       HDR, SK {IDi, [CERT,]
       [CERTREQ,] [IDr,],AUTH,
       SAi2}                   -->
                                   <-- HDR, SK {IDr, [CERT,] AUTH,
                                       SAr2}


   The second pair of exchanged messages (i.e., the RKMP_SA_AUTH
   exchange) employ most of the payload specified in the IKE_SA_AUTH
   exchange.  However, the traffic selector payloads in the original
   IKE_SA_AUTH exchange is removed.  The objective of exchanging of
   traffic selector payloads is to guarantee the consistence of the
   Security Policy Databases (SPD) on the communicating partners.
   Therefore, when an IP packet is received by an IPsec subsystem and
   matches a "protect" selector in its Security Policy Database (SPD),
   the subsystem will have to protect that packet with IPsec.  However,
   this is not the scenario that RKMP needs to consider.  In addition,
   because RKMP is designed for cryptographic keys for routing protocols
   instead of IPsec, more values of the protocol ID field in the
   Security Association payload needs to be defined to represent
   different routing protocols.







Zhang & Hartman          Expires January 4, 2012                [Page 6]


Internet-Draft                    RKMP                         July 2011


4.  Child SA Exchange Details

   The Child SA exchange takes advantage of the payloads of the
   CREATE_CHILD_SA exchange while removing the traffic selector
   payloads.  In addition, in order to support different routing
   protocols more values of the protocol ID field in the Security
   Association payload needs to be defined.

        Initiator                            Responder
       -----------                          -----------
       HDR, SK {[N], SA, Ni,
       [KEi]}                -->
                                <--    HDR, SK {SA, Nr, [KEr]}

   Note that in IPsec the value used to identify a particular SA is
   referred to as a Security Parameter Index (SPI).  However, the values
   identifying a SA in other routing protocols may be named differently.
   For example, in RIPv2, OSPFv2 and IS-IS, such values are denoted as
   key identifiers.  RKMP follows IKEV2 and uses SPIs to denote the
   values identifying SAs in different routing protocols.


5.  Interfaces

   This section introduces three groups of interfaces: the interface to
   routing protocols, the interface to RKMP, and the interface to the
   key table.

   The interface to RKMP includes following methods:

   RKMP_generateSA: This method is called when a routing protocol
   expects RKMP to generate a new routing protocol SA and store it into
   the key table.  As parameters, the protocol ID, the addresses of the
   Interfaces that two routers will be used to exchange messages need to
   be inputed.  RKMP will send the SPI of the SA back to the routing
   protocol.  After getting the SPI, the routing protocol can use it to
   derive the correspondent key material from the key table.

   RKMP_rekeySA: This method can be called when a routing protocol
   intends to proactively rekey an child SA which is still in its valid
   period.  The protocol ID and the SPI of the SA which intends to be
   rekeyed are inputted as parameters.  If the child SA is found, RKMP
   will return the SPI of the new generated equivalent SA to the routing
   protocol.  If there is no correspondent child SA being found, RKMP
   will return zero back.

   The interface to the key table includes following methods:




Zhang & Hartman          Expires January 4, 2012                [Page 7]


Internet-Draft                    RKMP                         July 2011


   Keytable_getSA: This method is called when a routing protocol intends
   to get key material to secure a routing message sent to a remote
   router.  As parameters, the protocol ID, the addresses of the
   Interfaces that two router will be used to exchange messages need to
   be inputted.  (If the SPI of the SA is available, the routing
   protocol can also input the SPI to indentify the desired SA.  It is
   assumed here that an SA can be uniquely identified by its SPI and the
   associated routing protocol ID.)  The contents of the associated
   routing protocol SA will be returned.

   Keytable_delete: This method is called when a routing protocol
   intends to delete un-useful child SAs to release occupied resources.
   The protocol ID and the SPI of the SA to be deleted are inputted as
   parameters to identify the child SA which will be deleted.  If the
   inputted SPI is zero, all the child SAs used by the routing protocol
   will be deleted.

   Keytable_insertSA: This method is called when RKMP have generated a
   new routing protocol SA and intends to store it into the key table.
   If there is already a SA with the identical SPI, the inserting
   operation will be failed.

   Keytable_rekeySA: This method is called when RKMP have generated a
   equivalent SA and intends to use it take place of the existing one
   maintained in the key table.

   The interface to a routing protocol includes following methods:

   RP_revokeSA: This method is called when RKMP deams that the RKMP
   security association has failed and then discards all state
   associated with the RKMP SA and any child SAs negotiated using that
   RKMP SA.  After being invoked, the routing protocol will not use
   existing SAs to secure routing protocols messages.


6.  Security Considerations


7.  IANA Considerations

   The values of the protocol ID fields in the payloads need to be
   assigned by IANA to present various routing protocols.


8.  Acknowledgements


9.  References



Zhang & Hartman          Expires January 4, 2012                [Page 8]


Internet-Draft                    RKMP                         July 2011


9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

9.2.  Informative References

   [I-D.hartman-karp-mrkmp]
              Hartman, S. and D. Zhang, "Multicast Router Key Management
              Protocol (MRKMP)", draft-hartman-karp-mrkmp-01 (work in
              progress), March 2011.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.


Authors' Addresses

   Dacheng Zhang
   Huawei
   Beijing
   China

   Email: zhangdacheng@huawei.com


   Sam Hartman
   Painless Security

   Email: hartmans@painless-security.com


















Zhang & Hartman          Expires January 4, 2012                [Page 9]