EAP
Internet Draft H. Tschofenig
D. Kroeselberg
Siemens
Corporate Technology
Document: draft-tschofenig-eap-ikev2-00.txt
Expires: October 2003 April 2003
EAP IKEv2 Method
(EAP-IKEv2)
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
EAP-IKEv2 is an EAP method which reuses the cryptography and the
payloads of IKEv2, creating a flexible EAP method that supports both
symmetric and asymmetric authentication. Furthermore protection of
legacy authentication mechanisms is supported. This EAP method
offers the security benefits of IKEv2 without the goal of
establishing IPsec security associations.
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................2
3. Protocol overview.............................................3
4. Packet Format.................................................6
Tschofenig, Kroselberg Expires - October 2003 [Page 1]
EAP IKEv2 April 2003
5. Key derivation................................................7
6. Security Considerations.......................................7
7. Open Issues...................................................8
8. References....................................................8
Acknowledgments..................................................9
Author's Addresses...............................................9
1. Introduction
IKEv2 [2] is a protocol which consists of two phases:
(1) an authentication and key exchange protocol which establishes an
IKE-SA.
(2) messages and payloads which focus on the negotiation of
parameters in order to establish IPsec security associations (i.e.
Child-SAs). These payloads contain algorithm parameters and traffic
selector fields.
In addition to the above-mentioned parts IKEv2 also includes some
payloads and messages which allow configuration parameters to be
exchanged primarily for remote access scenarios.
The EAP-IKEv2 method defined by this document primarily uses the
IKEv2 payloads and messages used for phase (1).
IKEv2 provides an improvement over IKEv1 [5] as described in
Appendix A of [2]. Important for this document are the reduced
number of initial exchanges, support of legacy authentication,
decreased latency of the initial exchange, optional DoS protection
capability and some other fixes (e.g. hash problem). IKEv2 is a
cryptographically sound protocol that has received a considerable
amount of expert review and that benefits from a long practical
experience with IKE.
The goal of EAP-IKEv2 is to inherit these properties within an
efficient, secure EAP method.
In addition, IKEv2 provides authentication and key exchange
capabilities which allow an entity to use symmetric as well as
asymmetric authentication in addition to legacy authentication
support within a single protocol. Such flexibility is considered
important for an EAP method and is provided by EAP-IKEv2.
[6] provides a good tutorial for IKEv2 design decisions.
2. Terminology
This document does not introduce new terms other than those defined
in [1] or in [2].
Tschofenig, Kroselberg Expires - October 2003 [Page 2]
EAP IKEv2 April 2003
3. Protocol overview
The protocol for symmetric and asymmetric authentication within EAP-
IKEv2 differs from IKEv2 only in the computation of the AUTH
payload. For symmetric authentication no CERT and CERTREQ payloads
are required. Figure 2 depicts such a protocol exchange. The
following types of identities are used in this exchange:
a) The first part of the (outer) EAP message exchange provides
information where the protocol messages described below terminate.
This message exchange primarily is an identity request/response.
b) The identities used within EAP-IKEv2 for both the initiator and
the responder. The initiator identity is often associated with a
user identity such as a fully-qualified RFC 822 email address. The
identity of the responder might be a FQDN. The identity is of
importance for authorization.
For secure legacy authentication an EAP message exchange is
protected with the established IKE-SA as shown in Figure 3. This
exchange again adds EAP identities.
c) This inner EAP message exchange primarily serves the purpose of
client authentication. The two identities used thereby are the EAP
identity (i.e. a NAI) and possibly a separate identity for the
selected EAP method.
The large number of identities is required due to nesting of
authentication methods and due to overloaded function of the
identity for routing (i.e. authentication end point indication).
Hence with this additional (nested) EAP exchange the end point of
the EAP-IKEv2 exchange might not be the same as the end point of the
inner EAP exchange which is protected by the IKE-SA (which in this
case is not protected by the IKE-SA any more between the EAP-IKEv2
endpoint and the endpoint of the inner EAP exchange, but might be
protected by other means that are not considered in this document).
This section illustrates some message exchanges for use in EAP-
IKEv2. They are taken from [2], and are adapted. Since this document
does not describe frameworks or particular architectures the message
exchange takes place between two parties - between the Initiator (I)
and the Responder (R). In context of EAP the Initiator is often
called Authenticating Peer whereas the Responder is referred as
Authenticator.
Tschofenig, Kroselberg Expires - October 2003 [Page 3]
EAP IKEv2 April 2003
The first message flow shows EAP-IKEv2 without the optional DoS
protection exchanges. The core EAP-IKEv2 exchange consists of four
messages (two roundtrips)_only:
I <-- R: EAP-Request/Identity
I --> R: EAP-Response/Identity(Id)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)
I <-- R: EAP-Success
Figure 1: EAP-IKEv2 message flow
The subsequent message flow shows EAP-IKEv2 with the optional DoS
protection. The IKEv2 DoS protection mechanism uses cookies and
keeps the responder stateless when it receives the first IKEv2
message. As a consequence of DoS protection an additional roundtrip
is required.
I <-- R: EAP-Request/Identity
I --> R: EAP-Response/Identity(Id)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,0), N(COOKIE-REQUIRED), N(COOKIE))
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,0), N(COOKIE), SAi1, KEi, Ni)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
Tschofenig, Kroselberg Expires - October 2003 [Page 4]
EAP IKEv2 April 2003
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)
I <-- R: EAP-Success
Figure 2: EAP-IKEv2 with Cookies
The following EAP message exchange is taken from Section 2.16 of [2]
and adapted (TSi, TSr, SAi2 and SAr2 payloads are omitted). It
provides an example of a successful inner EAP exchange using the
EAP-SIM Authentication method [9], which is secured by the IKE-SA.
I <-- R: EAP-Request/Identity
I --> R: EAP-Response/Identity(Id)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SAi1, KEi, Ni)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR, SAr1, KEr, Nr, [CERTREQ])
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {IDi, [CERTREQ,] [IDr,]})
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR, SK {IDr, [CERT,] AUTH, EAP(EAP-Request/Identity})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {EAP(EAP-Response/Identity), [AUTH]}
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR,
SK {EAP(EAP- Request/SIM/Start(AT_VERSION_LIST)),[AUTH]})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP-
Response/SIM/Start(AT_NONCE_MT, AT_SELECTED_VERSION)), [AUTH]})
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP-
Request/SIM/Challenge(AT_RAND, AT_MAC)), [AUTH]})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
Tschofenig, Kroselberg Expires - October 2003 [Page 5]
EAP IKEv2 April 2003
HDR, SK {EAP(EAP-Response/SIM/Challenge(AT_MAC) ), [AUTH]})
I <-- R: EAP-Success
Figure 3: EAP-IKEv2 SLA with EAP-SIM Authentication
Since the goal of this EAP method is not to establish an IPsec SA
some payloads used in IKEv2 are omitted. In particularly the
following messages and payloads are not required:
- Traffic Selectors
- IPsec SA negotiation payloads
(e.g. CREATE_CHILD_SA exchange or SAx2 payloads)
- ECN Notification
- Requesting an internal address on a remote network
(aka ModeCfg or DHCP-based approaches)
- Port handling
- NAT traversal
- Rekeying of IKE-SAs
Some of these messages and payloads are optional in IKEv2.
In general it does not make sense to directly negotiate IPsec SAs
with EAP-IKEv2, as such SAs were unlikely to be used between the EAP
endpoints.
4. Packet Format
The IKEv2 payloads, which are defined in [2], are embedded into the
Data field of the standard EAP Request/Response packets. The Code,
Identifier, Length and Type field is described in [1]. The Type-Data
field carries a one byte Flags field following the IKEv2 payloads.
Each IKEv2 payload starts with a header field HDR (see [2]).
The packet format is shown in Figure 4:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Packet Format
No additional packet formats other than those defined in [2] are
required for this EAP method.
Tschofenig, Kroselberg Expires - October 2003 [Page 6]
EAP IKEv2 April 2003
The Flags field is required to indicate Start and Finish messages
which are required due to the asymmetric nature of IKEv2 and the
Request/Response message handling of EAP.
Currently only two bits in the eight bit Flags field are required.
The remaining bits are set to set to zero.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S F 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
S = EAP-IKEv2 start message
F = EAP-IKEv2 finish message
EAP-IKEv2 messages which have neither an S or an F flag set contain
regular IKEv2 message payloads inside the Data field.
The EAP Type for this EAP method is <TBD>.
5. Key derivation
The EAP-IKEv2 method described in this document generates sessions
keys. These session keys are used to establish an IKE-SA which
provides protection of other payloads. To export a session key as
part of the EAP keying framework [7] it is required to derive
another session key for usage with EAP (sometimes referred as Pre-
Master-Secret). It is good cryptographic security practice to use
different keys for different "applications". Hence we suggest to
reuse the key derivation function suggested in Section 2.17 of [2]
to export the KEYMAT (as a Pre-Master-Secret) for further key
derivation.
The key derivation function defined is KEYMAT = prf+(SK_d, Ni | Nr),
where Ni and Nr are the Nonces from the IKE_SA_INIT exchange.
6. Security Considerations
The security of the proposed EAP method is intentionally based on
IKEv2 [2]. Man-in-the-middle attacks discovered in the context of
tunneled authentication protocols (see [3] and [4]) are applicable
to IKEv2 if legacy authentication with EAP [1] is used. To counter
this threat IKEv2 provides a compound authentication by including
the EAP provided session key inside the AUTH payload.
Further security considerations will be provided with future
versions of this document.
Tschofenig, Kroselberg Expires - October 2003 [Page 7]
EAP IKEv2 April 2003
7. Open Issues
The following open issues have been identified:
- Fragmentation
Currently it is not clear whether fragmentation support has to be
provided although IKEv2 itself does not worry about fragmentation
itself.
- Certificate revocation
IKEv2 allows CRLs to be exchanged. However, it does not provide the
capability to exchange OCSP [8] payloads.
- Session resumption
TLS provides the capability of resuming a session. This offers
primarily performance improvement for a new authentication and key
exchange protocol run. It is for further study whether the concept
of session resumption (i.e. a fast re-authentication procedure) is a
useful context for EAP methods and for the AAA environment in
particular. If it turns out to be useful then one possible approach
is to reuse the dead peer detection informational exchange with is
able to provide fast re-authentication based on the established IKE-
SA. This exchange is cheap in terms of processing complexity and
provides both end points the capability to perform authentication
based on an available IKE-SA.
- Reducing the number of messages
The message flows given in this document finish with an EAP-Success
message. Depending on the outcome of the current mailing list
discussions it is possible that the EAP-Success message can be
omitted if other success indications are available; e.g. mutual
authentication is provided by the IKEv2 method. Furthermore it is
possible to omit the first exchange if the identity can be learned
by other means.
8. References
[1] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[2] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", internet
draft, Internet Engineering Task Force, 2003. Work in progress.
Tschofenig, Kroselberg Expires - October 2003 [Page 8]
EAP IKEv2 April 2003
[3] N. Asokan, V. Niemi, and K. Nyberg, "Man-in-the-middle in
tunnelled authentication," in http://eprint.iacr.org/2002/163/ ,
2002.
[4] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. Aboba,
"The compound authentication binding problem," internet draft,
Internet Engineering Task Force, 2003. Work in progress.
[5] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC
2409, November 1998.
[6] R. Perlman: "Understanding IKEv2: Tutorial, and rationale for
decisions", internet draft, Internet Engineering Task Force, 2003.
Work in progress.
[7] B. Aboba and D. Simon: "EAP Keying Framework", internet draft,
Internet Engineering Task Force, 2003. Work in progress.
[8] Myers, et al.: "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, Internet Engineering
Task Force, 1999.
[9] H. Haverinen, J. Salowey: "EAP SIM Authentication", internet
draft, Internet Engineering Task Force, 2003. Work in progress.
Acknowledgments
Add your name here.
Author's Addresses
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Dirk.Kroeselberg@siemens.com
Tschofenig, Kroselberg Expires - October 2003 [Page 9]