Working Group U. Chunduri
Internet-Draft A. Tian
Intended status: Standards Track Ericsson Inc.
Expires: September 13, 2012 J. Touch
USC/ISI
March 12, 2012
Using IKEv2 with TCP-AO
draft-chunduri-karp-using-ikev2-with-tcp-ao-01
Abstract
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
changes.
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.
[RFC5926].
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
record.
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
GK:
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-
TBD).
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
protocol.
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
connection.
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
[RFC5996]:
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
randomness.
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
explored.
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
authentication.
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
[I-D.ietf-idr-bgp-multisession]
Scudder, J., Appanna, C., and I. Varlashkin, "Multisession
BGP", draft-ietf-idr-bgp-multisession-06 (work in
progress), March 2011.
[I-D.ietf-karp-routing-tcp-analysis]
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.
[I-D.ietf-karp-threats-reqs]
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
[I-D.mahesh-karp-rkmp]
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
USA
Phone: +1 (408) 750-5678
Email: uma.chunduri@ericsson.com
Albert Tian
Ericsson Inc.
300 Holger Way
San Jose, California 95134
USA
Phone: +1 (408) 750-5210
Email: albert.tian@ericsson.com
Joe Touch
USC/ISI
4676 Admiralty Way,
Marina del Rey, California 90292-6695
USA
Phone: +1 (310) 448-9151
Email: touch@isi.edu
Chunduri, et al. Expires September 13, 2012 [Page 16]