include RFC 5998
This commit is contained in:
parent
f22ba072e8
commit
f054606586
|
@ -1,729 +0,0 @@
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Network Working Group P. Eronen
|
|
||||||
Internet-Draft Nokia
|
|
||||||
Expires: December 28, 2006 H. Tschofenig
|
|
||||||
Siemens
|
|
||||||
June 26, 2006
|
|
||||||
|
|
||||||
|
|
||||||
Extension for EAP Authentication in IKEv2
|
|
||||||
draft-eronen-ipsec-ikev2-eap-auth-05.txt
|
|
||||||
|
|
||||||
Status of this Memo
|
|
||||||
|
|
||||||
By submitting this Internet-Draft, each author represents that any
|
|
||||||
applicable patent or other IPR claims of which he or she is aware
|
|
||||||
have been or will be disclosed, and any of which he or she becomes
|
|
||||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
|
||||||
|
|
||||||
Internet-Drafts are working documents of the Internet Engineering
|
|
||||||
Task Force (IETF), its areas, and its working groups. Note that
|
|
||||||
other groups may also distribute working documents as Internet-
|
|
||||||
Drafts.
|
|
||||||
|
|
||||||
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."
|
|
||||||
|
|
||||||
The list of current Internet-Drafts can be accessed at
|
|
||||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
|
||||||
|
|
||||||
The list of Internet-Draft Shadow Directories can be accessed at
|
|
||||||
http://www.ietf.org/shadow.html.
|
|
||||||
|
|
||||||
This Internet-Draft will expire on December 28, 2006.
|
|
||||||
|
|
||||||
Copyright Notice
|
|
||||||
|
|
||||||
Copyright (C) The Internet Society (2006).
|
|
||||||
|
|
||||||
Abstract
|
|
||||||
|
|
||||||
IKEv2 specifies that EAP authentication must be used together with
|
|
||||||
public key signature based responder authentication. This is
|
|
||||||
necessary with old EAP methods that provide only unilateral
|
|
||||||
authentication using, e.g., one-time passwords or token cards.
|
|
||||||
|
|
||||||
This document specifies how EAP methods that provide mutual
|
|
||||||
authentication and key agreement can be used to provide extensible
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 1]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
responder authentication for IKEv2 based on other methods than public
|
|
||||||
key signatures.
|
|
||||||
|
|
||||||
|
|
||||||
1. Introduction
|
|
||||||
|
|
||||||
The Extensible Authentication Protocol (EAP), defined in [4], is an
|
|
||||||
authentication framework which supports multiple authentication
|
|
||||||
mechanisms. Today, EAP has been implemented at end hosts and routers
|
|
||||||
that connect via switched circuits or dial-up lines using PPP [13],
|
|
||||||
IEEE 802 wired switches [9], and IEEE 802.11 wireless access points
|
|
||||||
[11].
|
|
||||||
|
|
||||||
One of the advantages of the EAP architecture is its flexibility.
|
|
||||||
EAP is used to select a specific authentication mechanism, typically
|
|
||||||
after the authenticator requests more information in order to
|
|
||||||
determine the specific authentication method to be used. Rather than
|
|
||||||
requiring the authenticator (e.g., wireless LAN access point) to be
|
|
||||||
updated to support each new authentication method, EAP permits the
|
|
||||||
use of a backend authentication server which may implement some or
|
|
||||||
all authentication methods.
|
|
||||||
|
|
||||||
IKEv2 [3] is a component of IPsec used for performing mutual
|
|
||||||
authentication and establishing and maintaining security associations
|
|
||||||
for IPsec ESP and AH. In addition to supporting authentication using
|
|
||||||
public key signatures and shared secrets, IKEv2 also supports EAP
|
|
||||||
authentication.
|
|
||||||
|
|
||||||
IKEv2 provides EAP authentication since it was recognized that public
|
|
||||||
key signatures and shared secrets are not flexible enough to meet the
|
|
||||||
requirements of many deployment scenarios. By using EAP, IKEv2 can
|
|
||||||
leverage existing authentication infrastructure and credential
|
|
||||||
databases, since EAP allows users to choose a method suitable for
|
|
||||||
existing credentials, and also makes separation of the IKEv2
|
|
||||||
responder (VPN gateway) from the EAP authentication endpoint (backend
|
|
||||||
AAA server) easier.
|
|
||||||
|
|
||||||
Some older EAP methods are designed for unilateral authentication
|
|
||||||
only (that is, EAP peer to EAP server). These methods are used in
|
|
||||||
conjunction with IKEv2 public key based authentication of the
|
|
||||||
responder to the initiator. It is expected that this approach is
|
|
||||||
especially useful for "road warrior" VPN gateways that use, for
|
|
||||||
instance, one-time passwords or token cards to authenticate the
|
|
||||||
clients.
|
|
||||||
|
|
||||||
However, most newer EAP methods, such as those typically used with
|
|
||||||
IEEE 802.11i wireless LANs, provide mutual authentication and key
|
|
||||||
agreement. Currently, IKEv2 specifies that also these EAP methods
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 2]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
must be used together with public key signature based responder
|
|
||||||
authentication.
|
|
||||||
|
|
||||||
In some environments, requiring the deployment of PKI for just this
|
|
||||||
purpose can be counterproductive. Deploying new infrastructure can
|
|
||||||
be expensive, and it may weaken security by creating new
|
|
||||||
vulnerabilities. Mutually authenticating EAP methods alone can
|
|
||||||
provide a sufficient level of security in many circumstances, and
|
|
||||||
indeed, IEEE 802.11i uses EAP without any PKI for authenticating the
|
|
||||||
WLAN access points.
|
|
||||||
|
|
||||||
This document specifies how EAP methods that offer mutual
|
|
||||||
authentication and key agreement can be used to provide responder
|
|
||||||
authentication in IKEv2 completely based on EAP.
|
|
||||||
|
|
||||||
1.1. Terminology
|
|
||||||
|
|
||||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
||||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
||||||
document are to be interpreted as described in [2].
|
|
||||||
|
|
||||||
|
|
||||||
2. Scenarios
|
|
||||||
|
|
||||||
In this section we describe two scenarios for extensible
|
|
||||||
authentication within IKEv2. These scenarios are intended to be
|
|
||||||
illustrative examples rather than specifying how things should be
|
|
||||||
done.
|
|
||||||
|
|
||||||
Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
|
|
||||||
are co-located. Authenticating the IKEv2 responder using both EAP
|
|
||||||
and public key signatures is redundant. Offering EAP based
|
|
||||||
authentication has the advantage that multiple different
|
|
||||||
authentication and key exchange protocols are available with EAP with
|
|
||||||
different security properties (such as strong password based
|
|
||||||
protocols, protocols offering user identity confidentiality and many
|
|
||||||
more). As an example it is possible to use GSS-API support within
|
|
||||||
EAP [6] to support Kerberos based authentication which effectively
|
|
||||||
replaces the need for KINK [14].
|
|
||||||
|
|
||||||
+------+-----+ +------------+
|
|
||||||
O | IKEv2 | | IKEv2 |
|
|
||||||
/|\ | Initiator |<---////////////////////--->| Responder |
|
|
||||||
/ \ +------------+ IKEv2 +------------+
|
|
||||||
User | EAP Peer | Exchange | EAP Server |
|
|
||||||
+------------+ +------------+
|
|
||||||
|
|
||||||
Figure 1: EAP and IKEv2 endpoints are co-located
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 3]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
Figure 2 shows a typical corporate network access scenario. The
|
|
||||||
initiator (client) interacts with the responder (VPN gateway) in the
|
|
||||||
corporate network. The EAP exchange within IKE runs between the
|
|
||||||
client and the home AAA server. As a result of a successful EAP
|
|
||||||
authentication protocol run, session keys are established and sent
|
|
||||||
from the AAA server to the VPN gateway, and then used to authenticate
|
|
||||||
the IKEv2 SA with AUTH payloads.
|
|
||||||
|
|
||||||
The protocol used between the VPN gateway and AAA server could be,
|
|
||||||
for instance, Diameter [4] or RADIUS [5]. See Section 5 for related
|
|
||||||
security considerations.
|
|
||||||
|
|
||||||
+-------------------------------+
|
|
||||||
| Corporate network |
|
|
||||||
| |
|
|
||||||
+-----------+ +--------+ |
|
|
||||||
| IKEv2 | AAA | Home | |
|
|
||||||
IKEv2 +////----->+ Responder +<---------->+ AAA | |
|
|
||||||
Exchange / | (VPN GW) | (RADIUS/ | Server | |
|
|
||||||
/ +-----------+ Diameter) +--------+ |
|
|
||||||
/ | carrying EAP |
|
|
||||||
| | |
|
|
||||||
| +-------------------------------+
|
|
||||||
v
|
|
||||||
+------+-----+
|
|
||||||
o | IKEv2 |
|
|
||||||
/|\ | Initiator |
|
|
||||||
/ \ | VPN client |
|
|
||||||
User +------------+
|
|
||||||
|
|
||||||
Figure 2: Corporate Network Access
|
|
||||||
|
|
||||||
|
|
||||||
3. Solution
|
|
||||||
|
|
||||||
IKEv2 specifies that when the EAP method establishes a shared secret
|
|
||||||
key, that key is used by both the initiator and responder to generate
|
|
||||||
an AUTH payload (thus authenticating the IKEv2 SA set up by messages
|
|
||||||
1 and 2).
|
|
||||||
|
|
||||||
When used together with public key responder authentication, the
|
|
||||||
responder is in effect authenticated using two different methods: the
|
|
||||||
public key signature AUTH payload in message 4, and the EAP-based
|
|
||||||
AUTH payload later.
|
|
||||||
|
|
||||||
If the initiator does not wish to use public key based responder
|
|
||||||
authentication, it includes an EAP_ONLY_AUTHENTICATION notification
|
|
||||||
payload (type TBD-BY-IANA) in message 3. The SPI size field is set
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 4]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
to zero, and there is no additional data associated with this
|
|
||||||
notification.
|
|
||||||
|
|
||||||
If the responder supports this notification, it omits the public key
|
|
||||||
based AUTH payload and CERT payloads from message 4.
|
|
||||||
|
|
||||||
If the responder does not support the EAP_ONLY_AUTHENTICATION
|
|
||||||
notification, it ignores the notification payload, and includes the
|
|
||||||
AUTH payload in message 4. In this case the initiator can, based on
|
|
||||||
its local policy, choose to either ignore the AUTH payload, or verify
|
|
||||||
it and any associated certificates as usual.
|
|
||||||
|
|
||||||
Both the initiator and responder MUST verify that the EAP method
|
|
||||||
actually used provided mutual authentication and established a shared
|
|
||||||
secret key. The AUTH payloads sent after EAP Success MUST use the
|
|
||||||
EAP-generated key, and MUST NOT use SK_pi or SK_pr.
|
|
||||||
|
|
||||||
An IKEv2 message exchange with this modification is shown below:
|
|
||||||
|
|
||||||
|
|
||||||
Initiator Responder
|
|
||||||
----------- -----------
|
|
||||||
HDR, SAi1, KEi, Ni,
|
|
||||||
[N(NAT_DETECTION_SOURCE_IP),
|
|
||||||
N(NAT_DETECTION_DESTINATION_IP)] -->
|
|
||||||
|
|
||||||
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
|
|
||||||
[N(NAT_DETECTION_SOURCE_IP),
|
|
||||||
N(NAT_DETECTION_DESTINATION_IP)]
|
|
||||||
|
|
||||||
HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
|
|
||||||
N(EAP_ONLY_AUTHENTICATION),
|
|
||||||
[CP(CFG_REQUEST)] } -->
|
|
||||||
|
|
||||||
<-- HDR, SK { IDr, EAP(Request) }
|
|
||||||
|
|
||||||
HDR, SK { EAP(Response) } -->
|
|
||||||
|
|
||||||
<-- HDR, SK { EAP(Request) }
|
|
||||||
|
|
||||||
HDR, SK { EAP(Response) } -->
|
|
||||||
|
|
||||||
<-- HDR, SK { EAP(Success) }
|
|
||||||
|
|
||||||
HDR, SK { AUTH } -->
|
|
||||||
|
|
||||||
<-- HDR, SK { AUTH, SAr2, TSi, TSr,
|
|
||||||
[CP(CFG_REPLY] }
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 5]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
The NAT detection and Configuration payloads are shown for
|
|
||||||
informative purposes only; they do not change how EAP authentication
|
|
||||||
works.
|
|
||||||
|
|
||||||
|
|
||||||
4. IANA considerations
|
|
||||||
|
|
||||||
This document defines a new IKEv2 Notification Payload type,
|
|
||||||
EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must
|
|
||||||
be assigned a new type number from the "status types" range.
|
|
||||||
|
|
||||||
This document does not define any new namespaces to be managed by
|
|
||||||
IANA.
|
|
||||||
|
|
||||||
|
|
||||||
5. Security Considerations
|
|
||||||
|
|
||||||
Security considerations applicable to all EAP methods are discussed
|
|
||||||
in [1]. The EAP Key Management Framework [7] deals with issues that
|
|
||||||
arise when EAP is used as a part of a larger system.
|
|
||||||
|
|
||||||
5.1. Authentication of IKEv2 SA
|
|
||||||
|
|
||||||
It is important to note that the IKEv2 SA is not authenticated by
|
|
||||||
just running an EAP conversation: the crucial step is the AUTH
|
|
||||||
payload based on the EAP-generated key. Thus, EAP methods that do
|
|
||||||
not provide mutual authentication or establish a shared secret key
|
|
||||||
MUST NOT be used with the modifications presented in this document.
|
|
||||||
|
|
||||||
5.2. Authentication with separated IKEv2 responder/EAP server
|
|
||||||
|
|
||||||
As described in Section 2, the EAP conversation can terminate either
|
|
||||||
at the IKEv2 responder or at a backend AAA server.
|
|
||||||
|
|
||||||
If the EAP method terminates at the IKEv2 responder then no key
|
|
||||||
transport via the AAA infrastructure is required. Pre-shared secret
|
|
||||||
and public key based authentication offered by IKEv2 is then replaced
|
|
||||||
by a wider range of authentication and key exchange methods.
|
|
||||||
|
|
||||||
However, typically EAP will be used with a backend AAA server. See
|
|
||||||
[7] for a more complete discussion of the related security issues;
|
|
||||||
here we provide only a short summary.
|
|
||||||
|
|
||||||
When a backend server is used, there are actually two authentication
|
|
||||||
exchanges: the EAP method between the client and the AAA server, and
|
|
||||||
another authentication between the AAA server and IKEv2 gateway. The
|
|
||||||
AAA server authenticates the client using the selected EAP method,
|
|
||||||
and they establish a session key. The AAA server then sends this key
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 6]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
to the IKEv2 gateway over a connection authenticated using, e.g.,
|
|
||||||
IPsec or TLS.
|
|
||||||
|
|
||||||
Some EAP methods do not have any concept of pass-through
|
|
||||||
authenticator (e.g., NAS or IKEv2 gateway) identity, and these two
|
|
||||||
authentications remain quite independent of each other. That is,
|
|
||||||
after the client has verified the AUTH payload sent by the IKEv2
|
|
||||||
gateway, it knows that it is talking to SOME gateway trusted by the
|
|
||||||
home AAA server, but not which one. The situation is somewhat
|
|
||||||
similar if a single cryptographic hardware accelerator, containing a
|
|
||||||
single private key, would be shared between multiple IKEv2 gateways
|
|
||||||
(perhaps in some kind of cluster configuration). In particular, if
|
|
||||||
one of the gateways is compromised, it can impersonate any of the
|
|
||||||
other gateways towards the user (until the compromise is discovered
|
|
||||||
and access rights revoked).
|
|
||||||
|
|
||||||
In some environments it is not desirable to trust the IKEv2 gateways
|
|
||||||
this much (also known as the "Lying NAS Problem"). EAP methods that
|
|
||||||
provide what is called "connection binding" or "channel binding"
|
|
||||||
transport some identity or identities of the gateway (or WLAN access
|
|
||||||
point/NAS) inside the EAP method. Then the AAA server can check that
|
|
||||||
it is indeed sending the key to the gateway expected by the client.
|
|
||||||
A potential solution is described in [16].
|
|
||||||
|
|
||||||
In some deployment configurations, AAA proxies may be present between
|
|
||||||
the IKEv2 gateway and the backend AAA server. These AAA proxies MUST
|
|
||||||
be trusted for secure operation, and therefore SHOULD be avoided when
|
|
||||||
possible; see [4] and [7] for more discussion.
|
|
||||||
|
|
||||||
5.3. Protection of EAP payloads
|
|
||||||
|
|
||||||
Although the EAP payloads are encrypted and integrity protected with
|
|
||||||
SK_e/SK_a, this does not provide any protection against active
|
|
||||||
attackers. Until the AUTH payload has been received and verified, a
|
|
||||||
man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
|
|
||||||
modify the EAP payloads.
|
|
||||||
|
|
||||||
In IEEE 802.11i WLANs, the EAP payloads are neither encrypted nor
|
|
||||||
integrity protected (by the link layer), so EAP methods are typically
|
|
||||||
designed to take that into account.
|
|
||||||
|
|
||||||
In particular, EAP methods that are vulnerable to dictionary attacks
|
|
||||||
when used in WLANs are still vulnerable (to active attackers) when
|
|
||||||
run inside IKEv2.
|
|
||||||
|
|
||||||
5.4. User identity confidentiality
|
|
||||||
|
|
||||||
IKEv2 provides confidentiality for the initiator identity against
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 7]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
passive eavesdroppers, but not against active attackers. The
|
|
||||||
initiator announces its identity first (in message #3), before the
|
|
||||||
responder has been authenticated. The usage of EAP in IKEv2 does not
|
|
||||||
change this situation, since the ID payload in message #3 is used
|
|
||||||
instead of the EAP Identity Request/Response exchange. This is
|
|
||||||
somewhat unfortunate since when EAP is used with public key
|
|
||||||
authentication of the responder, it would be possible to provide
|
|
||||||
active user identity confidentiality for the initiator.
|
|
||||||
|
|
||||||
IKEv2 protects the responder identity even against active attacks.
|
|
||||||
This property cannot be provided when using EAP. If public key
|
|
||||||
responder authentication is used in addition to EAP, the responder
|
|
||||||
reveals its identity before authenticating the initiator. If only
|
|
||||||
EAP is used (as proposed in this document), the situation depends on
|
|
||||||
the EAP method used (in some EAP methods, the server reveals its
|
|
||||||
identity first).
|
|
||||||
|
|
||||||
Hence, if active user identity confidentiality for the initiator is
|
|
||||||
required then EAP methods that offer this functionality have to be
|
|
||||||
used (see [1], Section 7.3).
|
|
||||||
|
|
||||||
|
|
||||||
6. Acknowledgments
|
|
||||||
|
|
||||||
This document borrows some text from [1], [3], and [4]. We would
|
|
||||||
also like to thank Hugo Krawczyk for interesting discussions about
|
|
||||||
this topic.
|
|
||||||
|
|
||||||
|
|
||||||
7. References
|
|
||||||
|
|
||||||
7.1. Normative References
|
|
||||||
|
|
||||||
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
|
|
||||||
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
|
|
||||||
June 2004.
|
|
||||||
|
|
||||||
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
|
||||||
Levels", RFC 2119, March 1997.
|
|
||||||
|
|
||||||
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
|
|
||||||
December 2005.
|
|
||||||
|
|
||||||
[4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
|
|
||||||
Authentication Protocol (EAP) Application", RFC 4072,
|
|
||||||
August 2005.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 8]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
7.2. Informative References
|
|
||||||
|
|
||||||
[5] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
|
|
||||||
In User Service) Support For Extensible Authentication Protocol
|
|
||||||
(EAP)", RFC 3579, September 2003.
|
|
||||||
|
|
||||||
[6] Aboba, B. and D. Simon, "EAP GSS Authentication Protocol",
|
|
||||||
draft-aboba-pppext-eapgss-12 (work in progress), April 2002.
|
|
||||||
|
|
||||||
[7] Aboba, B., "Extensible Authentication Protocol (EAP) Key
|
|
||||||
Management Framework", draft-ietf-eap-keying-13 (work in
|
|
||||||
progress), May 2006.
|
|
||||||
|
|
||||||
[8] Forsberg, D., "Protocol for Carrying Authentication for Network
|
|
||||||
Access (PANA)", draft-ietf-pana-pana-11 (work in progress),
|
|
||||||
March 2006.
|
|
||||||
|
|
||||||
[9] Institute of Electrical and Electronics Engineers, "Local and
|
|
||||||
Metropolitan Area Networks: Port-Based Network Access Control",
|
|
||||||
IEEE Standard 802.1X-2001, 2001.
|
|
||||||
|
|
||||||
[10] Institute of Electrical and Electronics Engineers, "Information
|
|
||||||
technology - Telecommunications and information exchange
|
|
||||||
between systems - Local and metropolitan area networks -
|
|
||||||
Specific Requirements Part 11: Wireless LAN Medium Access
|
|
||||||
Control (MAC) and Physical Layer (PHY) Specifications", IEEE
|
|
||||||
Standard 802.11-1999, 1999.
|
|
||||||
|
|
||||||
[11] Institute of Electrical and Electronics Engineers, "IEEE
|
|
||||||
Standard for Information technology - Telecommunications and
|
|
||||||
information exchange between systems - Local and metropolitan
|
|
||||||
area networks - Specific requirements - Part 11: Wireless
|
|
||||||
Medium Access Control (MAC) and Physical Layer (PHY)
|
|
||||||
specifications: Amendment 6: Medium Access Control (MAC)
|
|
||||||
Security Enhancements", IEEE Standard 802.11i-2004, July 2004.
|
|
||||||
|
|
||||||
[12] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
|
|
||||||
Authentication Dial In User Service (RADIUS)", RFC 2865,
|
|
||||||
June 2000.
|
|
||||||
|
|
||||||
[13] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
|
|
||||||
RFC 1661, July 1994.
|
|
||||||
|
|
||||||
[14] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
|
|
||||||
"Kerberized Internet Negotiation of Keys (KINK)", RFC 4430,
|
|
||||||
March 2006.
|
|
||||||
|
|
||||||
[15] Tschofenig, H., "EAP IKEv2 Method",
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 9]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
draft-tschofenig-eap-ikev2-11 (work in progress), June 2006.
|
|
||||||
|
|
||||||
[16] Arkko, J. and P. Eronen, "Authenticated Service Information for
|
|
||||||
the Extensible Authentication Protocol (EAP)",
|
|
||||||
draft-arkko-eap-service-identity-auth-04 (work in progress),
|
|
||||||
October 2005.
|
|
||||||
|
|
||||||
|
|
||||||
Appendix A. Alternative Approaches
|
|
||||||
|
|
||||||
In this section we list alternatives which have been considered
|
|
||||||
during the work on this document. Finally, the solution presented in
|
|
||||||
Section 3 seems to fit better into IKEv2.
|
|
||||||
|
|
||||||
A.1. Ignore AUTH payload at the initiator
|
|
||||||
|
|
||||||
With this approach, the initiator simply ignores the AUTH payload in
|
|
||||||
message #4 (but obviously must check the second AUTH payload later!).
|
|
||||||
The main advantage of this approach is that no protocol modifications
|
|
||||||
are required and no signature verification is required.
|
|
||||||
|
|
||||||
The initiator could signal the responder (using a NOTIFY payload)
|
|
||||||
that it did not verify the first AUTH payload.
|
|
||||||
|
|
||||||
A.2. Unauthenticated PKs in AUTH payload (message 4)
|
|
||||||
|
|
||||||
The first solution approach suggests the use of unauthenticated
|
|
||||||
public keys in the public key signature AUTH payload (for message 4).
|
|
||||||
|
|
||||||
That is, the initiator verifies the signature in the AUTH payload,
|
|
||||||
but does not verify that the public key indeed belongs to the
|
|
||||||
intended party (using certificates)--since it doesn't have a PKI that
|
|
||||||
would allow this. This could be used with X.509 certificates (the
|
|
||||||
initiator ignores all other fields of the certificate except the
|
|
||||||
public key), or "Raw RSA Key" CERT payloads.
|
|
||||||
|
|
||||||
This approach has the advantage that initiators that wish to perform
|
|
||||||
certificate-based responder authentication (in addition to EAP) may
|
|
||||||
do so, without requiring the responder to handle these cases
|
|
||||||
separately.
|
|
||||||
|
|
||||||
If using RSA, the overhead of signature verification is quite small
|
|
||||||
(compared to g^xy calculation).
|
|
||||||
|
|
||||||
A.3. Use EAP derived session keys for IKEv2
|
|
||||||
|
|
||||||
It has been proposed that when using an EAP methods that provides
|
|
||||||
mutual authentication and key agreement, the IKEv2 Diffie-Hellman
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 10]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
exchange could also be omitted. This would mean that the sessions
|
|
||||||
keys for IPsec SAs established later would rely only on EAP-provided
|
|
||||||
keys.
|
|
||||||
|
|
||||||
It seems the only benefit of this approach is saving some computation
|
|
||||||
time (g^xy calculation). This approach requires designing a
|
|
||||||
completely new protocol (which would not resemble IKEv2 anymore) we
|
|
||||||
do not believe that it should be considered. Nevertheless, we
|
|
||||||
include it for completeness.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 11]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
Authors' Addresses
|
|
||||||
|
|
||||||
Pasi Eronen
|
|
||||||
Nokia Research Center
|
|
||||||
P.O. Box 407
|
|
||||||
FIN-00045 Nokia Group
|
|
||||||
Finland
|
|
||||||
|
|
||||||
Email: pasi.eronen@nokia.com
|
|
||||||
|
|
||||||
|
|
||||||
Hannes Tschofenig
|
|
||||||
Siemens
|
|
||||||
Otto-Hahn-Ring 6
|
|
||||||
Munich, Bayern 81739
|
|
||||||
Germany
|
|
||||||
|
|
||||||
Email: Hannes.Tschofenig@siemens.com
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 12]
|
|
||||||
|
|
||||||
Internet-Draft Extension for EAP in IKEv2 June 2006
|
|
||||||
|
|
||||||
|
|
||||||
Intellectual Property Statement
|
|
||||||
|
|
||||||
The IETF takes no position regarding the validity or scope of any
|
|
||||||
Intellectual Property Rights or other rights that might be claimed to
|
|
||||||
pertain to the implementation or use of the technology described in
|
|
||||||
this document or the extent to which any license under such rights
|
|
||||||
might or might not be available; nor does it represent that it has
|
|
||||||
made any independent effort to identify any such rights. Information
|
|
||||||
on the procedures with respect to rights in RFC documents can be
|
|
||||||
found in BCP 78 and BCP 79.
|
|
||||||
|
|
||||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
|
||||||
assurances of licenses to be made available, or the result of an
|
|
||||||
attempt made to obtain a general license or permission for the use of
|
|
||||||
such proprietary rights by implementers or users of this
|
|
||||||
specification can be obtained from the IETF on-line IPR repository at
|
|
||||||
http://www.ietf.org/ipr.
|
|
||||||
|
|
||||||
The IETF invites any interested party to bring to its attention any
|
|
||||||
copyrights, patents or patent applications, or other proprietary
|
|
||||||
rights that may cover technology that may be required to implement
|
|
||||||
this standard. Please address the information to the IETF at
|
|
||||||
ietf-ipr@ietf.org.
|
|
||||||
|
|
||||||
|
|
||||||
Disclaimer of Validity
|
|
||||||
|
|
||||||
This document and the information contained herein are provided on an
|
|
||||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
||||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|
||||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|
||||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|
||||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
||||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
||||||
|
|
||||||
|
|
||||||
Copyright Statement
|
|
||||||
|
|
||||||
Copyright (C) The Internet Society (2006). This document is subject
|
|
||||||
to the rights, licenses and restrictions contained in BCP 78, and
|
|
||||||
except as set forth therein, the authors retain all their rights.
|
|
||||||
|
|
||||||
|
|
||||||
Acknowledgment
|
|
||||||
|
|
||||||
Funding for the RFC Editor function is currently provided by the
|
|
||||||
Internet Society.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Eronen & Tschofenig Expires December 28, 2006 [Page 13]
|
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,899 @@
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Internet Engineering Task Force (IETF) P. Eronen
|
||||||
|
Request for Comments: 5998 Independent
|
||||||
|
Updates: 5996 H. Tschofenig
|
||||||
|
Category: Standards Track Nokia Siemens Networks
|
||||||
|
ISSN: 2070-1721 Y. Sheffer
|
||||||
|
Independent
|
||||||
|
September 2010
|
||||||
|
|
||||||
|
|
||||||
|
An Extension for EAP-Only Authentication in IKEv2
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
IKEv2 specifies that Extensible Authentication Protocol (EAP)
|
||||||
|
authentication must be used together with responder authentication
|
||||||
|
based on public key signatures. This is necessary with old EAP
|
||||||
|
methods that provide only unilateral authentication using, e.g., one-
|
||||||
|
time passwords or token cards.
|
||||||
|
|
||||||
|
This document specifies how EAP methods that provide mutual
|
||||||
|
authentication and key agreement can be used to provide extensible
|
||||||
|
responder authentication for IKEv2 based on methods other than public
|
||||||
|
key signatures.
|
||||||
|
|
||||||
|
Status of This Memo
|
||||||
|
|
||||||
|
This is an Internet Standards Track document.
|
||||||
|
|
||||||
|
This document is a product of the Internet Engineering Task Force
|
||||||
|
(IETF). It represents the consensus of the IETF community. It has
|
||||||
|
received public review and has been approved for publication by the
|
||||||
|
Internet Engineering Steering Group (IESG). Further information on
|
||||||
|
Internet Standards is available in Section 2 of RFC 5741.
|
||||||
|
|
||||||
|
Information about the current status of this document, any errata,
|
||||||
|
and how to provide feedback on it may be obtained at
|
||||||
|
http://www.rfc-editor.org/info/rfc5998.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 1]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
Copyright Notice
|
||||||
|
|
||||||
|
Copyright (c) 2010 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
|
||||||
|
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.
|
||||||
|
|
||||||
|
This document may contain material from IETF Documents or IETF
|
||||||
|
Contributions published or made publicly available before November
|
||||||
|
10, 2008. The person(s) controlling the copyright in some of this
|
||||||
|
material may not have granted the IETF Trust the right to allow
|
||||||
|
modifications of such material outside the IETF Standards Process.
|
||||||
|
Without obtaining an adequate license from the person(s) controlling
|
||||||
|
the copyright in such materials, this document may not be modified
|
||||||
|
outside the IETF Standards Process, and derivative works of it may
|
||||||
|
not be created outside the IETF Standards Process, except to format
|
||||||
|
it for publication as an RFC or to translate it into languages other
|
||||||
|
than English.
|
||||||
|
|
||||||
|
1. Introduction
|
||||||
|
|
||||||
|
The Extensible Authentication Protocol (EAP), defined in [RFC3748],
|
||||||
|
is an authentication framework that supports multiple authentication
|
||||||
|
mechanisms. Today, EAP has been implemented at end hosts and routers
|
||||||
|
that connect via switched circuits or dial-up lines using PPP
|
||||||
|
[RFC1661], IEEE 802 wired switches [IEEE8021X], and IEEE 802.11
|
||||||
|
wireless access points [IEEE80211i].
|
||||||
|
|
||||||
|
One of the advantages of the EAP architecture is its flexibility.
|
||||||
|
EAP is used to select a specific authentication mechanism, typically
|
||||||
|
after the authenticator requests more information in order to
|
||||||
|
determine the specific authentication method to be used. Rather than
|
||||||
|
requiring the authenticator (e.g., wireless LAN access point) to be
|
||||||
|
updated to support each new authentication method, EAP permits the
|
||||||
|
use of a backend authentication server that may implement some or all
|
||||||
|
authentication methods.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 2]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
IKEv2 ([RFC4306] and [RFC5996]) is a component of IPsec used for
|
||||||
|
performing mutual authentication and establishing and maintaining
|
||||||
|
Security Associations (SAs) for IPsec ESP and Authentication Header
|
||||||
|
(AH). In addition to supporting authentication using public key
|
||||||
|
signatures and shared secrets, IKEv2 also supports EAP
|
||||||
|
authentication.
|
||||||
|
|
||||||
|
IKEv2 provides EAP authentication since it was recognized that public
|
||||||
|
key signatures and shared secrets are not flexible enough to meet the
|
||||||
|
requirements of many deployment scenarios. By using EAP, IKEv2 can
|
||||||
|
leverage existing authentication infrastructure and credential
|
||||||
|
databases, since EAP allows users to choose a method suitable for
|
||||||
|
existing credentials, and also makes separation of the IKEv2
|
||||||
|
responder (VPN gateway) from the EAP authentication endpoint (backend
|
||||||
|
Authentication, Authorization, and Accounting (AAA) server) easier.
|
||||||
|
|
||||||
|
Some older EAP methods are designed for unilateral authentication
|
||||||
|
only (that is, EAP peer to EAP server). These methods are used in
|
||||||
|
conjunction with IKEv2 public-key-based authentication of the
|
||||||
|
responder to the initiator. It is expected that this approach is
|
||||||
|
especially useful for "road warrior" VPN gateways that use, for
|
||||||
|
instance, one-time passwords or token cards to authenticate the
|
||||||
|
clients.
|
||||||
|
|
||||||
|
However, most newer EAP methods, such as those typically used with
|
||||||
|
IEEE 802.11i wireless LANs, provide mutual authentication and key
|
||||||
|
agreement. Currently, IKEv2 specifies that these EAP methods must
|
||||||
|
also be used together with responder authentication based on public
|
||||||
|
key signatures.
|
||||||
|
|
||||||
|
In order for the public key signature authentication of the gateway
|
||||||
|
to be effective, a deployment of Public Key Infrastructure (PKI) is
|
||||||
|
required, which has to include management of trust anchors on all
|
||||||
|
supplicants. In many environments, this is not realistic, and the
|
||||||
|
security of the gateway public key is the same as the security of a
|
||||||
|
self-signed certificate. Mutually authenticating EAP methods alone
|
||||||
|
can provide a sufficient level of security in many circumstances, and
|
||||||
|
in fact, in some deployments, IEEE 802.11i uses EAP without any PKI
|
||||||
|
for authenticating the Wireless Local Area Network (WLAN) access
|
||||||
|
points.
|
||||||
|
|
||||||
|
This document specifies how EAP methods that offer mutual
|
||||||
|
authentication and key agreement can be used to provide responder
|
||||||
|
authentication in IKEv2 completely based on EAP.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 3]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
1.1. Terminology
|
||||||
|
|
||||||
|
All notation in this protocol extension is taken from [RFC4306].
|
||||||
|
|
||||||
|
Numbered messages refer to the IKEv2 message sequence when using EAP.
|
||||||
|
|
||||||
|
Thus:
|
||||||
|
|
||||||
|
o Message 1 is the request message of IKE_SA_INIT.
|
||||||
|
|
||||||
|
o Message 2 is the response message of IKE_SA_INIT.
|
||||||
|
|
||||||
|
o Message 3 is the first request of IKE_AUTH.
|
||||||
|
|
||||||
|
o Message 4 is the first response of IKE_AUTH.
|
||||||
|
|
||||||
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||||
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||||
|
document are to be interpreted as described in [RFC2119].
|
||||||
|
|
||||||
|
2. Scenarios
|
||||||
|
|
||||||
|
In this section, we describe two scenarios for extensible
|
||||||
|
authentication within IKEv2. These scenarios are intended to be
|
||||||
|
illustrative examples rather than specifying how things should be
|
||||||
|
done.
|
||||||
|
|
||||||
|
Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
|
||||||
|
are co-located. Authenticating the IKEv2 responder using both EAP
|
||||||
|
and public key signatures is redundant. Offering EAP-based
|
||||||
|
authentication has the advantage that multiple different
|
||||||
|
authentication and key exchange protocols are available with EAP with
|
||||||
|
different security properties (such as strong password-based
|
||||||
|
protocols, protocols offering user identity confidentiality, and many
|
||||||
|
more).
|
||||||
|
|
||||||
|
+------+-----+ +------------+
|
||||||
|
O | IKEv2 | | IKEv2 |
|
||||||
|
/|\ | Initiator |<---////////////////////--->| Responder |
|
||||||
|
/ \ +------------+ IKEv2 +------------+
|
||||||
|
User | EAP Peer | Exchange | EAP Server |
|
||||||
|
+------------+ +------------+
|
||||||
|
|
||||||
|
Figure 1: EAP and IKEv2 Endpoints Are Co-Located
|
||||||
|
|
||||||
|
Figure 2 shows a typical corporate network access scenario. The
|
||||||
|
initiator (client) interacts with the responder (VPN gateway) in the
|
||||||
|
corporate network. The EAP exchange within IKE runs between the
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 4]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
client and the home AAA server. As a result of a successful EAP
|
||||||
|
authentication protocol run, session keys are established and sent
|
||||||
|
from the AAA server to the VPN gateway, and then used to authenticate
|
||||||
|
the IKEv2 SA with AUTH payloads.
|
||||||
|
|
||||||
|
The protocol used between the VPN gateway and AAA server could be,
|
||||||
|
for instance, Diameter [RFC4072] or RADIUS [RFC3579]. See Section 6
|
||||||
|
for related security considerations.
|
||||||
|
|
||||||
|
+-------------------------------+
|
||||||
|
| Corporate network |
|
||||||
|
| |
|
||||||
|
+-----------+ +--------+ |
|
||||||
|
| IKEv2 | AAA | Home | |
|
||||||
|
IKEv2 +////----->+ Responder +<---------->+ AAA | |
|
||||||
|
Exchange / | (VPN GW) | (RADIUS/ | Server | |
|
||||||
|
/ +-----------+ Diameter) +--------+ |
|
||||||
|
/ | carrying EAP |
|
||||||
|
| | |
|
||||||
|
| +-------------------------------+
|
||||||
|
v
|
||||||
|
+------+-----+
|
||||||
|
o | IKEv2 |
|
||||||
|
/|\ | Initiator |
|
||||||
|
/ \ | VPN client |
|
||||||
|
User +------------+
|
||||||
|
|
||||||
|
Figure 2: Corporate Network Access
|
||||||
|
|
||||||
|
3. Solution
|
||||||
|
|
||||||
|
IKEv2 specifies that when the EAP method establishes a shared secret
|
||||||
|
key, that key is used by both the initiator and responder to generate
|
||||||
|
an AUTH payload (thus authenticating the IKEv2 SA set up by messages
|
||||||
|
1 and 2).
|
||||||
|
|
||||||
|
When used together with public key responder authentication, the
|
||||||
|
responder is, in effect, authenticated using two different methods:
|
||||||
|
the public key signature AUTH payload in message 4, and the EAP-based
|
||||||
|
AUTH payload later.
|
||||||
|
|
||||||
|
If the initiator does not wish to use public-key-based responder
|
||||||
|
authentication, it includes an EAP_ONLY_AUTHENTICATION notification
|
||||||
|
payload (16417) in message 3. The Protocol ID and Security Parameter
|
||||||
|
Index (SPI) size fields are set to zero, and there is no additional
|
||||||
|
data associated with this notification.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 5]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
If the responder supports this notification and chooses to use it, it
|
||||||
|
omits the public-key-based AUTH payload and CERT payloads from
|
||||||
|
message 4.
|
||||||
|
|
||||||
|
If the responder does not support the EAP_ONLY_AUTHENTICATION
|
||||||
|
notification or does not wish to use it, it ignores the notification
|
||||||
|
payload, and includes the AUTH payload in message 4. In this case,
|
||||||
|
the initiator MUST verify that payload and any associated
|
||||||
|
certificates, as per [RFC4306].
|
||||||
|
|
||||||
|
When receiving message 4, the initiator MUST verify that the proposed
|
||||||
|
EAP method is allowed by this specification, and MUST abort the
|
||||||
|
protocol immediately otherwise.
|
||||||
|
|
||||||
|
Both the initiator and responder MUST verify that the EAP method
|
||||||
|
actually used provided mutual authentication and established a shared
|
||||||
|
secret key. The AUTH payloads sent after EAP Success MUST use the
|
||||||
|
EAP-generated key, and MUST NOT use SK_pi or SK_pr (see Section 2.15
|
||||||
|
of [RFC5996]).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 6]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
An IKEv2 message exchange with this modification is shown below:
|
||||||
|
|
||||||
|
Initiator Responder
|
||||||
|
----------- -----------
|
||||||
|
HDR, SAi1, KEi, Ni,
|
||||||
|
[N(NAT_DETECTION_SOURCE_IP),
|
||||||
|
N(NAT_DETECTION_DESTINATION_IP)] -->
|
||||||
|
|
||||||
|
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
|
||||||
|
[N(NAT_DETECTION_SOURCE_IP),
|
||||||
|
N(NAT_DETECTION_DESTINATION_IP)]
|
||||||
|
|
||||||
|
HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
|
||||||
|
N(EAP_ONLY_AUTHENTICATION),
|
||||||
|
[CP(CFG_REQUEST)] } -->
|
||||||
|
|
||||||
|
<-- HDR, SK { IDr, EAP(Request) }
|
||||||
|
|
||||||
|
HDR, SK { EAP(Response) } -->
|
||||||
|
|
||||||
|
<-- HDR, SK { EAP(Request) }
|
||||||
|
|
||||||
|
HDR, SK { EAP(Response) } -->
|
||||||
|
|
||||||
|
<-- HDR, SK { EAP(Success) }
|
||||||
|
|
||||||
|
HDR, SK { AUTH } -->
|
||||||
|
|
||||||
|
<-- HDR, SK { AUTH, SAr2, TSi, TSr,
|
||||||
|
[CP(CFG_REPLY] }
|
||||||
|
|
||||||
|
Note: all notation in the above protocol sequence and elsewhere in
|
||||||
|
this specification is as defined in [RFC4306], and see in particular
|
||||||
|
Sec. 1.2 of [RFC4306] for payload types.
|
||||||
|
|
||||||
|
The NAT detection and Configuration payloads are shown for
|
||||||
|
informative purposes only; they do not change how EAP authentication
|
||||||
|
works.
|
||||||
|
|
||||||
|
An IKE SA that was set up with this extension can be resumed using
|
||||||
|
the mechanism described in [RFC5723]. However, session resumption
|
||||||
|
does not change the authentication method. Therefore, during the
|
||||||
|
IKE_AUTH exchange of the resumed session, this extension MUST NOT be
|
||||||
|
sent by the initiator.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 7]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
4. Safe EAP Methods
|
||||||
|
|
||||||
|
EAP methods to be used with this extension MUST have the following
|
||||||
|
properties:
|
||||||
|
|
||||||
|
1. The method provides mutual authentication of the peers.
|
||||||
|
|
||||||
|
2. The method is key-generating.
|
||||||
|
|
||||||
|
3. The method is resistant to dictionary attacks.
|
||||||
|
|
||||||
|
The authors believe that the following EAP methods are secure when
|
||||||
|
used with the current extension. The list is not inclusive, and
|
||||||
|
there are likely other safe methods that have not been listed here.
|
||||||
|
|
||||||
|
+-------------------------------+-------------------+---------------+
|
||||||
|
| Method Name | Allows Channel | Reference |
|
||||||
|
| | Binding? | |
|
||||||
|
+-------------------------------+-------------------+---------------+
|
||||||
|
| EAP-SIM | No | [RFC4186] |
|
||||||
|
| EAP-AKA | Yes | [RFC4187] |
|
||||||
|
| EAP-AKA' | Yes | [RFC5448] |
|
||||||
|
| EAP-GPSK | Yes | [RFC5433] |
|
||||||
|
| EAP-pwd | No | [RFC5931] |
|
||||||
|
| EAP-EKE | Yes | [EMU-EAP-EKE] |
|
||||||
|
| EAP-PAX | Yes | [RFC4746] |
|
||||||
|
| EAP-SAKE | No | [RFC4763] |
|
||||||
|
| EAP-SRP | No | [EAP-SRP] |
|
||||||
|
| EAP-POTP (mutual | Yes | [RFC4793] |
|
||||||
|
| authentication variant) | | |
|
||||||
|
| EAP-TLS | No | [RFC5216] |
|
||||||
|
| EAP-FAST | No | [RFC4851] |
|
||||||
|
| EAP-TTLS | No | [RFC5281] |
|
||||||
|
+-------------------------------+-------------------+---------------+
|
||||||
|
|
||||||
|
The "Allows channel binding?" column denotes protocols where
|
||||||
|
protected identity information may be sent between the EAP endpoints.
|
||||||
|
This third, optional property of the method provides protection
|
||||||
|
against certain types of attacks (see Section 6.2 for an
|
||||||
|
explanation), and therefore in some scenarios, methods that allow for
|
||||||
|
channel binding are to be preferred. It is noted that at the time of
|
||||||
|
writing, even when such capabilities are provided, they are not fully
|
||||||
|
specified in an interoperable manner. In particular, no RFC
|
||||||
|
specifies what identities should be sent under the protection of the
|
||||||
|
channel binding mechanism, or what policy is to be used to correlate
|
||||||
|
identities at the different layers.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 8]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
5. IANA Considerations
|
||||||
|
|
||||||
|
This document defines a new IKEv2 Notification Payload type,
|
||||||
|
EAP_ONLY_AUTHENTICATION, described in Section 3. This payload has
|
||||||
|
been assigned the type number 16417 from the "Status Types" range.
|
||||||
|
|
||||||
|
6. Security Considerations
|
||||||
|
|
||||||
|
Security considerations applicable to all EAP methods are discussed
|
||||||
|
in [RFC3748]. The EAP Key Management Framework [RFC5247] deals with
|
||||||
|
issues that arise when EAP is used as a part of a larger system.
|
||||||
|
|
||||||
|
6.1. Authentication of IKEv2 SA
|
||||||
|
|
||||||
|
It is important to note that the IKEv2 SA is not authenticated by
|
||||||
|
just running an EAP conversation: the crucial step is the AUTH
|
||||||
|
payload based on the EAP-generated key. Thus, EAP methods that do
|
||||||
|
not provide mutual authentication or establish a shared secret key
|
||||||
|
MUST NOT be used with the modifications presented in this document.
|
||||||
|
|
||||||
|
6.2. Authentication with Separated IKEv2 Responder / EAP Server
|
||||||
|
|
||||||
|
As described in Section 2, the EAP conversation can terminate either
|
||||||
|
at the IKEv2 responder or at a backend AAA server.
|
||||||
|
|
||||||
|
If the EAP method is terminated at the IKEv2 responder, then no key
|
||||||
|
transport via the AAA infrastructure is required. Pre-shared secret
|
||||||
|
and public-key-based authentication offered by IKEv2 is then replaced
|
||||||
|
by a wider range of authentication and key exchange methods.
|
||||||
|
|
||||||
|
However, typically EAP will be used with a backend AAA server. See
|
||||||
|
[RFC5247] for a more complete discussion of the related security
|
||||||
|
issues; here we provide only a short summary.
|
||||||
|
|
||||||
|
When a backend server is used, there are actually two authentication
|
||||||
|
exchanges: the EAP method between the client and the AAA server, and
|
||||||
|
another authentication between the AAA server and IKEv2 gateway. The
|
||||||
|
AAA server authenticates the client using the selected EAP method,
|
||||||
|
and they establish a session key. The AAA server then sends this key
|
||||||
|
to the IKEv2 gateway over a connection authenticated using, e.g.,
|
||||||
|
IPsec or Transport Layer Security (TLS).
|
||||||
|
|
||||||
|
Some EAP methods do not have any concept of pass-through
|
||||||
|
authenticator (e.g., Network Access Server (NAS) or IKEv2 gateway)
|
||||||
|
identity, and these two authentications remain quite independent of
|
||||||
|
each other. That is, after the client has verified the AUTH payload
|
||||||
|
sent by the IKEv2 gateway, it knows that it is talking to SOME
|
||||||
|
gateway trusted by the home AAA server, but not which one. The
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 9]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
situation is somewhat similar if a single cryptographic hardware
|
||||||
|
accelerator, containing a single private key, would be shared between
|
||||||
|
multiple IKEv2 gateways (perhaps in some kind of cluster
|
||||||
|
configuration). In particular, if one of the gateways is
|
||||||
|
compromised, it can impersonate any of the other gateways towards the
|
||||||
|
user (until the compromise is discovered and access rights revoked).
|
||||||
|
|
||||||
|
In some environments it is not desirable to trust the IKEv2 gateways
|
||||||
|
this much (also known as the "Lying NAS Problem"). EAP methods that
|
||||||
|
provide what is called "connection binding" or "channel binding"
|
||||||
|
transport some identity or identities of the gateway (or WLAN access
|
||||||
|
point / NAS) inside the EAP method. Then the AAA server can check
|
||||||
|
that it is indeed sending the key to the gateway expected by the
|
||||||
|
client. A potential solution is described in [EAP-SERVICE], see also
|
||||||
|
[EMU-AAAPAY].
|
||||||
|
|
||||||
|
In some deployment configurations, AAA proxies may be present between
|
||||||
|
the IKEv2 gateway and the backend AAA server. These AAA proxies MUST
|
||||||
|
be trusted for secure operation, and therefore SHOULD be avoided when
|
||||||
|
possible; see Section 2.3.4 of [RFC4072] and Section 4.3.7 of
|
||||||
|
[RFC3579] for more discussion.
|
||||||
|
|
||||||
|
6.3. Protection of EAP Payloads
|
||||||
|
|
||||||
|
Although the EAP payloads are encrypted and integrity protected with
|
||||||
|
SK_e/SK_a, this does not provide any protection against active
|
||||||
|
attackers. Until the AUTH payload has been received and verified, a
|
||||||
|
man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
|
||||||
|
modify the EAP payloads.
|
||||||
|
|
||||||
|
In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted
|
||||||
|
nor integrity protected (by the link layer), so EAP methods are
|
||||||
|
typically designed to take that into account.
|
||||||
|
|
||||||
|
In particular, EAP methods that are vulnerable to dictionary attacks
|
||||||
|
when used in WLANs are still vulnerable (to active attackers) when
|
||||||
|
run inside IKEv2.
|
||||||
|
|
||||||
|
The rules in Section 4 are designed to avoid this potential
|
||||||
|
vulnerability.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 10]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
6.4. Identities and Authenticated Identities
|
||||||
|
|
||||||
|
When using this protocol, each of the peers sends two identity
|
||||||
|
values:
|
||||||
|
|
||||||
|
1. An identity contained in the IKE ID payload.
|
||||||
|
|
||||||
|
2. An identity transferred within the specific EAP method's
|
||||||
|
messages.
|
||||||
|
|
||||||
|
(IKEv2 omits the EAP Identity request/response pair, see Section 3.16
|
||||||
|
of [RFC5996].) The first identity value can be used by the recipient
|
||||||
|
to route AAA messages and/or to select authentication and EAP types.
|
||||||
|
But it is only the second identity that is directly authenticated by
|
||||||
|
the EAP method. The reader is referred to Section 2.16 of [RFC5996]
|
||||||
|
regarding the need to base IPsec policy decisions on the
|
||||||
|
authenticated identity. In the context of the extension described
|
||||||
|
here, this guidance on IPsec policy applies both to the
|
||||||
|
authentication of the client by the gateway and vice versa.
|
||||||
|
|
||||||
|
6.5. User Identity Confidentiality
|
||||||
|
|
||||||
|
IKEv2 provides confidentiality for the initiator identity against
|
||||||
|
passive eavesdroppers, but not against active attackers. The
|
||||||
|
initiator announces its identity first (in message 3), before the
|
||||||
|
responder has been authenticated. The usage of EAP in IKEv2 does not
|
||||||
|
change this situation, since the ID payload in message 3 is used
|
||||||
|
instead of the EAP Identity Request/Response exchange. This is
|
||||||
|
somewhat unfortunate since when EAP is used with public key
|
||||||
|
authentication of the responder, it would be possible to provide
|
||||||
|
active user identity confidentiality for the initiator.
|
||||||
|
|
||||||
|
IKEv2 protects the responder's identity even against active attacks.
|
||||||
|
This property cannot be provided when using EAP. If public key
|
||||||
|
responder authentication is used in addition to EAP, the responder
|
||||||
|
reveals its identity before authenticating the initiator. If only
|
||||||
|
EAP is used (as proposed in this document), the situation depends on
|
||||||
|
the EAP method used (in some EAP methods, the server reveals its
|
||||||
|
identity first).
|
||||||
|
|
||||||
|
Hence, if active user identity confidentiality for the responder is
|
||||||
|
required then EAP methods that offer this functionality have to be
|
||||||
|
used (see [RFC3748], Section 7.3).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 11]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
7. Acknowledgments
|
||||||
|
|
||||||
|
This document borrows some text from [RFC3748], [RFC4306], and
|
||||||
|
[RFC4072]. We would also like to thank Hugo Krawczyk for interesting
|
||||||
|
discussions about this topic, Dan Harkins, and David Harrington for
|
||||||
|
their comments.
|
||||||
|
|
||||||
|
8. References
|
||||||
|
|
||||||
|
8.1. Normative References
|
||||||
|
|
||||||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||||
|
|
||||||
|
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
|
||||||
|
H. Levkowetz, "Extensible Authentication Protocol
|
||||||
|
(EAP)", RFC 3748, June 2004.
|
||||||
|
|
||||||
|
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
|
||||||
|
RFC 4306, December 2005.
|
||||||
|
|
||||||
|
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
|
||||||
|
Protocol Version 2 (IKEv2) Session Resumption",
|
||||||
|
RFC 5723, January 2010.
|
||||||
|
|
||||||
|
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
|
||||||
|
"Internet Key Exchange Protocol Version 2 (IKEv2)",
|
||||||
|
RFC 5996, September 2010.
|
||||||
|
|
||||||
|
8.2. Informative References
|
||||||
|
|
||||||
|
[EAP-SERVICE] Arkko, J. and P. Eronen, "Authenticated Service
|
||||||
|
Information for the Extensible Authentication Protocol
|
||||||
|
(EAP)", Work in Progress, October 2005.
|
||||||
|
|
||||||
|
[EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-
|
||||||
|
SHA1 Authentication Protocol", Work in Progress,
|
||||||
|
July 2001.
|
||||||
|
|
||||||
|
[EMU-AAAPAY] Clancy, C., Lior, A., Zorn, G., and K. Hoeper, "EAP
|
||||||
|
Method Support for Transporting AAA Payloads", Work
|
||||||
|
in Progress, May 2010.
|
||||||
|
|
||||||
|
[EMU-EAP-EKE] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer,
|
||||||
|
"An EAP Authentication Method Based on the EKE
|
||||||
|
Protocol", Work in Progress, August 2010.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 12]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
[IEEE80211i] Institute of Electrical and Electronics Engineers,
|
||||||
|
"IEEE Standard for Information technology -
|
||||||
|
Telecommunications and information exchange between
|
||||||
|
systems - Local and metropolitan area networks -
|
||||||
|
Specific requirements - Part 11: Wireless Medium
|
||||||
|
Access Control (MAC) and Physical Layer (PHY)
|
||||||
|
specifications: Amendment 6: Medium Access Control
|
||||||
|
(MAC) Security Enhancements", IEEE Standard 802.11i-
|
||||||
|
2004, July 2004.
|
||||||
|
|
||||||
|
[IEEE8021X] Institute of Electrical and Electronics Engineers,
|
||||||
|
"Local and Metropolitan Area Networks: Port-Based
|
||||||
|
Network Access Control", IEEE Standard 802.1X-2001,
|
||||||
|
2001.
|
||||||
|
|
||||||
|
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
|
||||||
|
STD 51, RFC 1661, July 1994.
|
||||||
|
|
||||||
|
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
|
||||||
|
Authentication Dial In User Service) Support For
|
||||||
|
Extensible Authentication Protocol (EAP)", RFC 3579,
|
||||||
|
September 2003.
|
||||||
|
|
||||||
|
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
|
||||||
|
Extensible Authentication Protocol (EAP) Application",
|
||||||
|
RFC 4072, August 2005.
|
||||||
|
|
||||||
|
[RFC4186] Haverinen, H. and J. Salowey, "Extensible
|
||||||
|
Authentication Protocol Method for Global System for
|
||||||
|
Mobile Communications (GSM) Subscriber Identity
|
||||||
|
Modules (EAP-SIM)", RFC 4186, January 2006.
|
||||||
|
|
||||||
|
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
|
||||||
|
Protocol Method for 3rd Generation Authentication and
|
||||||
|
Key Agreement (EAP-AKA)", RFC 4187, January 2006.
|
||||||
|
|
||||||
|
[RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication
|
||||||
|
Protocol (EAP) Password Authenticated Exchange",
|
||||||
|
RFC 4746, November 2006.
|
||||||
|
|
||||||
|
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible
|
||||||
|
Authentication Protocol Method for Shared-secret
|
||||||
|
Authentication and Key Establishment (EAP-SAKE)",
|
||||||
|
RFC 4763, November 2006.
|
||||||
|
|
||||||
|
[RFC4793] Nystroem, M., "The EAP Protected One-Time Password
|
||||||
|
Protocol (EAP-POTP)", RFC 4793, February 2007.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 13]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
|
||||||
|
"The Flexible Authentication via Secure Tunneling
|
||||||
|
Extensible Authentication Protocol Method (EAP-FAST)",
|
||||||
|
RFC 4851, May 2007.
|
||||||
|
|
||||||
|
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
|
||||||
|
Authentication Protocol", RFC 5216, March 2008.
|
||||||
|
|
||||||
|
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
|
||||||
|
Authentication Protocol (EAP) Key Management
|
||||||
|
Framework", RFC 5247, August 2008.
|
||||||
|
|
||||||
|
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible
|
||||||
|
Authentication Protocol Tunneled Transport Layer
|
||||||
|
Security Authenticated Protocol Version 0 (EAP-
|
||||||
|
TTLSv0)", RFC 5281, August 2008.
|
||||||
|
|
||||||
|
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible
|
||||||
|
Authentication Protocol - Generalized Pre-Shared Key
|
||||||
|
(EAP-GPSK) Method", RFC 5433, February 2009.
|
||||||
|
|
||||||
|
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
|
||||||
|
Extensible Authentication Protocol Method for 3rd
|
||||||
|
Generation Authentication and Key Agreement (EAP-
|
||||||
|
AKA')", RFC 5448, May 2009.
|
||||||
|
|
||||||
|
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
|
||||||
|
Protocol (EAP) Authentication Using Only A Password",
|
||||||
|
RFC 5931, August 2010.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 14]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
Appendix A. Alternative Approaches
|
||||||
|
|
||||||
|
In this section, we list alternatives that have been considered
|
||||||
|
during the work on this document. We concluded that the solution
|
||||||
|
presented in Section 3 seems to fit better into IKEv2.
|
||||||
|
|
||||||
|
A.1. Ignore AUTH Payload at the Initiator
|
||||||
|
|
||||||
|
With this approach, the initiator simply ignores the AUTH payload in
|
||||||
|
message 4 (but obviously must check the second AUTH payload later!).
|
||||||
|
The main advantage of this approach is that no protocol modifications
|
||||||
|
are required and no signature verification is required. A
|
||||||
|
significant disadvantage is that the EAP method to be used cannot be
|
||||||
|
selected to take this behavior into account.
|
||||||
|
|
||||||
|
The initiator could signal to the responder (using a notification
|
||||||
|
payload) that it did not verify the first AUTH payload.
|
||||||
|
|
||||||
|
A.2. Unauthenticated Public Keys in AUTH Payload (Message 4)
|
||||||
|
|
||||||
|
Another solution approach suggests the use of unauthenticated public
|
||||||
|
keys in the public key signature AUTH payload (for message 4).
|
||||||
|
|
||||||
|
That is, the initiator verifies the signature in the AUTH payload,
|
||||||
|
but does not verify that the public key indeed belongs to the
|
||||||
|
intended party (using certificates) -- since it doesn't have a PKI
|
||||||
|
that would allow this. This could be used with X.509 certificates
|
||||||
|
(the initiator ignores all other fields of the certificate except the
|
||||||
|
public key), or "Raw RSA Key" CERT payloads.
|
||||||
|
|
||||||
|
This approach has the advantage that initiators that wish to perform
|
||||||
|
certificate-based responder authentication (in addition to EAP) may
|
||||||
|
do so, without requiring the responder to handle these cases
|
||||||
|
separately. A disadvantage here, again, is that the EAP method
|
||||||
|
selection cannot take into account the incomplete validation of the
|
||||||
|
responder's certificate.
|
||||||
|
|
||||||
|
If using RSA, the overhead of signature verification is quite small,
|
||||||
|
compared to the g^xy calculation required by the Diffie-Hellman
|
||||||
|
exchange.
|
||||||
|
|
||||||
|
A.3. Using EAP Derived Session Keys for IKEv2
|
||||||
|
|
||||||
|
It has been proposed that when using an EAP method that provides
|
||||||
|
mutual authentication and key agreement, the IKEv2 Diffie-Hellman
|
||||||
|
exchange could also be omitted. This would mean that the session
|
||||||
|
keys for IPsec SAs established later would rely only on EAP-provided
|
||||||
|
keys.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 15]
|
||||||
|
|
||||||
|
RFC 5998 Extension for EAP in IKEv2 September 2010
|
||||||
|
|
||||||
|
|
||||||
|
It seems the only benefit of this approach is saving some computation
|
||||||
|
time (g^xy calculation). This approach requires designing a
|
||||||
|
completely new protocol (which would not resemble IKEv2 anymore); we
|
||||||
|
do not believe that it should be considered. Nevertheless, we
|
||||||
|
include it for completeness.
|
||||||
|
|
||||||
|
Authors' Addresses
|
||||||
|
|
||||||
|
Pasi Eronen
|
||||||
|
Independent
|
||||||
|
|
||||||
|
EMail: pe@iki.fi
|
||||||
|
|
||||||
|
|
||||||
|
Hannes Tschofenig
|
||||||
|
Nokia Siemens Networks
|
||||||
|
Linnoitustie 6
|
||||||
|
Espoo 02600
|
||||||
|
Finland
|
||||||
|
|
||||||
|
Phone: +358 (50) 4871445
|
||||||
|
EMail: Hannes.Tschofenig@gmx.net
|
||||||
|
URI: http://www.tschofenig.priv.at
|
||||||
|
|
||||||
|
|
||||||
|
Yaron Sheffer
|
||||||
|
Independent
|
||||||
|
|
||||||
|
EMail: yaronf.ietf@gmail.com
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Eronen, et al. Standards Track [Page 16]
|
||||||
|
|
Loading…
Reference in New Issue