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