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

Versions: 00 01 02 03 04 05 06

Working Group                                                U. Chunduri
Internet-Draft                                                   A. Tian
Intended status: Standards Track                           Ericsson Inc.
Expires: September 13, 2012                                     J. Touch
                                                          March 12, 2012

                        Using IKEv2 with TCP-AO


   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 September 13, 2012.

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, et al.       Expires September 13, 2012               [Page 1]

Internet-Draft           Using IKEv2 with TCP-AO              March 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  . . . . . . . . . . . . . . . . . .  3
     1.2.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Motivation and Overview  . . . . . . . . . . . . . . . . . . .  4
   3.  The Gatekeeper . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  RP interface to the Gatekeeper . . . . . . . . . . . . . .  6
     3.2.  KMP interface to Gatekeeper  . . . . . . . . . . . . . . .  7
     3.3.  TCP-AO interface to Gatekeeper . . . . . . . . . . . . . .  8
   4.  Extensions required for IKEv2  . . . . . . . . . . . . . . . .  8
     4.1.  Non IPsec DOI  . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.1.  Security Association Extensions  . . . . . . . . . . .  9
     4.2.  Simple Traffic Selectors Negotiation . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  BGP Multi Session and transport level differentiation  . . 11
     8.2.  Applicable Authentications methods . . . . . . . . . . . . 12
       8.2.1.  Symmetric key based authentication . . . . . . . . . . 12
       8.2.2.  Asymmetric key based authentication  . . . . . . . . . 12
       8.2.3.  EAP based authentication . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Chunduri, et al.       Expires September 13, 2012               [Page 2]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

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 in [RFC5996].
   Gatekeeper interface with IKEv2 KMP and the TCP-AO for session
   parameter negotiation, key establishment and rekeying is also defined
   in [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",

Chunduri, et al.       Expires September 13, 2012               [Page 3]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Acronyms

   BGP     -  Border Gateway Protocol

   EAP     -  Extensible Authentication Protocol

   GKR     -  Gatekeeper Reccord

   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

   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 September 13, 2012               [Page 4]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

   IKEv2 KMP.

   The following diagram depicts the Gatekeeper module interfaces with
   all protocols involved i.e., TCP-based RPs, IKEv2 KMP, and TCP-AO.

      +-------------+ RP Session
      | TCP Based   | Configuration
      |    RPs      |------->--------+
      |(BGP/LDP/PCEP|                |
      |    /MSDP)   |              __|___             +----------+
      +-------------+             |      |  Trigger   |          |
                                  |Gate- |----------->| IKEv2    |
                                  |keeper| Negotiated |  KMP     |
      +-------------+             |      | Parameters |          |
      |             |             |      |<-----------|          |
      |             |             |______|            +----------+
      |  TCP-AO     |                |
      |             |--------<-------+
      |             | MKT Provisioning

                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.  The
   Gatekeeper then issues a corresponding request with all the proposed
   alternatives at the RP to the IKEv2 KMP, so IKEv2 can negotiated the
   needed parameters.  These negotiated parameters are used to provision
   MKTs in the TCP-AO, as well as to establish timers and other needed
   state local to the Gatekeeper.  Gatekeeper then 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 TCP-AO consistent with TCP-AO's support for key

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.

Chunduri, et al.       Expires September 13, 2012               [Page 5]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

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

   The next section defines the Gatekeeper module interface between TCP-
   based RPs (BGP, LDP, MSDP, PCEP), interface with IKEv2 and TCP-AO.

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

   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.

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

Chunduri, et al.       Expires September 13, 2012               [Page 6]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

3.2.  KMP interface to Gatekeeper

   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.  The purpose of this section is to define a
   common interface between the Gatekeeper and the IKEv2 KMP that can be
   used by all TCP-based RPs.

   The following are the details of the interface between KMP and GK:

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

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

   5.  KMP-negotiated KDF parameters for each session used to generate
       traffic keys from master keys to be populated in MKT.

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

Chunduri, et al.       Expires September 13, 2012               [Page 7]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

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

   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.

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

Chunduri, et al.       Expires September 13, 2012               [Page 8]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

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

   4.  The Diffie-Hellman group (D-H) transform type can be used for
       TCP-AO proposal as an optional transform.

Chunduri, et al.       Expires September 13, 2012               [Page 9]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

   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

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

Chunduri, et al.       Expires September 13, 2012              [Page 10]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

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

   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.

Chunduri, et al.       Expires September 13, 2012              [Page 11]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

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

   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

   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

Chunduri, et al.       Expires September 13, 2012              [Page 12]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

   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

   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

   From the list above, Encrypted Key Exchange (EKE) as described in

Chunduri, et al.       Expires September 13, 2012              [Page 13]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

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

   [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

              Scudder, J., Appanna, C., and I. Varlashkin, "Multisession
              BGP", draft-ietf-idr-bgp-multisession-06 (work in
              progress), March 2011.

              Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Security According to KARP Design
              Guide", draft-ietf-karp-routing-tcp-analysis-00 (work in
              progress), June 2011.

              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.

Chunduri, et al.       Expires September 13, 2012              [Page 14]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

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

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

Chunduri, et al.       Expires September 13, 2012              [Page 15]

Internet-Draft           Using IKEv2 with TCP-AO              March 2012

Authors' Addresses

   Uma Chunduri
   Ericsson Inc.
   300 Holger Way
   San Jose, California  95134

   Phone: +1 (408) 750-5678
   Email: uma.chunduri@ericsson.com

   Albert Tian
   Ericsson Inc.
   300 Holger Way
   San Jose, California  95134

   Phone: +1 (408) 750-5210
   Email: albert.tian@ericsson.com

   Joe Touch
   4676 Admiralty Way,
   Marina del Rey, California  90292-6695

   Phone: +1 (310) 448-9151
   Email: touch@isi.edu

Chunduri, et al.       Expires September 13, 2012              [Page 16]

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