[Search] [pdf|bibtex] [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: July 20, 2013                                          J. Touch
                                                        January 16, 2013

                        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 July 20, 2013.

Copyright Notice

   Copyright (c) 2013 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 July 20, 2013                 [Page 1]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

   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 . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  RP interface to the Gatekeeper . . . . . . . . . . . . . .  6
     3.2.  Interface to the PAD . . . . . . . . . . . . . . . . . . .  7
     3.3.  KMP interface to Gatekeeper  . . . . . . . . . . . . . . .  8
       3.3.1.  Interface to KARP Crypto Key Table . . . . . . . . . .  9
     3.4.  TCP-AO interface to Gatekeeper . . . . . . . . . . . . . . 10
     3.5.  Impact of Policy changes . . . . . . . . . . . . . . . . . 11
   4.  Extensions required for IKEv2  . . . . . . . . . . . . . . . . 11
     4.1.  Non IPsec DOI  . . . . . . . . . . . . . . . . . . . . . . 11
       4.1.1.  Security Association Extensions  . . . . . . . . . . . 12
     4.2.  Simple Traffic Selectors Negotiation . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  BGP Multi Session and transport level differentiation  . . 13
     8.2.  Applicable Authentications methods . . . . . . . . . . . . 14
       8.2.1.  Symmetric key based authentication . . . . . . . . . . 14
       8.2.2.  Asymmetric key based authentication  . . . . . . . . . 15
       8.2.3.  EAP based authentication . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

Chunduri, et al.          Expires July 20, 2013                 [Page 2]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

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

   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",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Chunduri, et al.          Expires July 20, 2013                 [Page 3]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

1.2.  Acronyms

   BGP     -  Border Gateway Protocol

   EAP     -  Extensible Authentication Protocol

   GKR     -  Gatekeeper Record

   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

   PAD     -  Peer Authorization Database

   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 July 20, 2013                 [Page 4]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

   IKEv2 KMP.

   The following diagram depicts the Gatekeeper module interfaces with
   all protocols involved i.e., TCP-based RPs, IKEv2 KMP, and TCP-AO.
   This also shows the interaction with various databases viz., Peer
   Authorization Database (PAD) and Crypto Key Tables interaction with
   the Gatekeeper.

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

                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.  A
   entry in the KMP peer authentication/authorization is provisioned in
   PAD as defined in Section 4.4.3 of [RFC4301] and pointer to this
   entry SHOULD be part of the RP configuration.  This facilitates
   Gatekeeper to issue a corresponding request, with all the proposed
   alternatives at the RP to the IKEv2 KMP, so IKEv2 can negotiate the
   needed parameters.  When the local peer is acting as a responder,
   security policy information populated at the Gatekeeper can be
   referenced through PAD by IKEv2 KMP to create the CHILD_SAs.  Either
   way, the negotiated parameters are kept in the crypto key table
   database as specified in [ietf-karp-cryoto_key-table] and this
   information is basis for provisioning MKTs in the TCP-AO.

   Gatekeeper 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

Chunduri, et al.          Expires July 20, 2013                 [Page 5]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

   TCP-AO consistent with TCP-AO's support for key changes.

   Section 3 describes in detail the role of Gatekeeper and it's
   interfaces to all the protocols and the databases it interacts with.
   Section 3.3.1, Section 3.2 describes the database and the interaction
   with the Gatekeeper in detail.

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.

   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 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.
   [RFC5926].  It also maintains the reference to PAD and Crypto Key
   Table entries to facilitate RP security parameters negotiation with
   IKEv2 KMP.

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

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
   record.  This provisioning includes the reference to PAD, which has
   all the information to authorize and authenticate IKEv2 peer.

   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.

Chunduri, et al.          Expires July 20, 2013                 [Page 6]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

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

3.2.  Interface to the PAD

   The Peer Authorization Database (PAD) for IPsec is described in
   Section 4.4.3 of [RFC4301].  This section describes the embodiments
   of the same in the context of RP security associations and security
   policies provisioned at the routing protocols.  This is still the
   link between policies provisioned at the routing protocol and the SAs
   created by IKEv2 KMP.  Instead of the Security Policy Database (SPD),
   Gatekeeper record holds the data for traffic selectors for child SA

Chunduri, et al.          Expires July 20, 2013                 [Page 7]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

                   Gatekeeper Record                         PAD Entry

                   +------------+                         +------------+
                   |  RP1       |------------------------>|  Peer X    |
                   |            |                         |            |
                   |            |        +--------------->|            |
                   +------------+       /                 +------------+
                   +------------+     /
                   |            |    /
                   |   RP2      |---+
                   |            |

                   +------------+                         +------------+
                   |            |                         |            |
                   |   RP1/RP3  |------------------------>|   Peer Y   |
                   |            |                         |            |
                   +------------+                         +------------+

            Figure 2: KARP KMP: Gatekeeper interface to the PAD

   As shown in Figure 2, multiple RPs can point to the same peer and in
   this case, a PAD entry holds the reference to both the corresponding
   Gatekeeper records.  The PAD entry for the IKEv2 peer is used to
   constrain the creation of child SAs; specifically, the PAD entry
   specifies how the Gatekeeper record is searched using a traffic
   selector proposal from a peer.  For CHILD_SA creation, peer IP
   addresses asserted in traffic selector payloads SHOULD be used for
   Gatekeeper record lookups based on the remote IP address field
   portion of a Gatekeeper Record entry.

3.3.  KMP interface to Gatekeeper

   As an initiator, 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.  As a responder to the peer IKEv2
   requests and CHILD_SA creation; Gatekeeper record is consulted
   through the reference in PAD.

   The purpose of this section is to define a common interface between
   the Gatekeeper and the IKEv2 KMP and also to list all the negotiated
   parameters to form an entry in the Crypto Key Tables.

Chunduri, et al.          Expires July 20, 2013                 [Page 8]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

3.3.1.  Interface to KARP Crypto Key Table

   KMP negotiated parameters are kept in the crypto key table database
   as specified in [ietf-karp-cryoto_key-table].  The database is
   characterized as a table, where each row represents a single long-
   lived symmetric cryptographic key or Master key.  The Gatekeeper
   record SHOULD have a reference to the Crypto Key Table Entry.  One of
   the reasons to separate the negotiated parameters in a different
   table is to alleviate the population manually or through a some
   external source.

   The following are the details:

   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
       Gatekeeper 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.
       These fields are populated as "LocalKeyName" and "PeerKeyName" in
       the Crypto Key Table entry.

   4.  Crypto Key Table "Peers" field SHOULD be populated with the peer
       IP address.

   5.  KMP-negotiated KDF parameters for each session used to generate
       traffic keys from master keys to be populated in MKT.  The same
       is referred as "KDF" in a corresponding Crypto Key Table entry.

   6.  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.  The
       same is referred as "AlgID" in corresponding Crypto Key Table

   7.  The "Key" field defined in Crypto Key Table contains a long-lived
       symmetric cryptographic key or Master Key in the format of a
       lower-case hexadecimal string.  The size of the Key depends on

Chunduri, et al.          Expires July 20, 2013                 [Page 9]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

       the KDF and the AlgID.

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

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

Chunduri, et al.          Expires July 20, 2013                [Page 10]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

3.5.  Impact of Policy changes

   Once the routing session is secured by TCP-AO, any security policy
   changes initiated by the operator at RP MUST cause a tear down of the
   existing session and MUST be replaced with a new CHILD_SA at IKEV2
   KMP and corresponding new MKT at TCP-AO.  Similarly, any changes in
   the peer Authentication data at PAD MUST cause re-authentication of
   the peer at IKEv2 KMP with changed credentials and also due to this
   change, all CHILD_SAs/MKTs need to re-negotiated.

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

   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

Chunduri, et al.          Expires July 20, 2013                [Page 11]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

   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.

   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

Chunduri, et al.          Expires July 20, 2013                [Page 12]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

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

Chunduri, et al.          Expires July 20, 2013                [Page 13]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

   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.

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

Chunduri, et al.          Expires July 20, 2013                [Page 14]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013


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

Chunduri, et al.          Expires July 20, 2013                [Page 15]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013


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

Chunduri, et al.          Expires July 20, 2013                [Page 16]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

   [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-07 (work in
              progress), September 2012.

              Housley, R., Polk, T., Hartman, S., and D. Zhang,
              "Database of Long-Lived Symmetric Cryptographic Keys",
              draft-ietf-karp-crypto-key-table-04 (work in progress),
              October 2012.

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

              Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
              Authentication for Routing Protocols (KARP) Overview,
              Threats, and Requirements",
              draft-ietf-karp-threats-reqs-07 (work in progress),
              December 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

Chunduri, et al.          Expires July 20, 2013                [Page 17]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

              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.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

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

Authors' Addresses

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

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

Chunduri, et al.          Expires July 20, 2013                [Page 18]

Internet-Draft           Using IKEv2 with TCP-AO            January 2013

   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 July 20, 2013                [Page 19]