900 lines
33 KiB
Plaintext
900 lines
33 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|