One document matched: draft-tschofenig-eap-ikev2-01.txt
Differences from draft-tschofenig-eap-ikev2-00.txt
EAP
Internet Draft H. Tschofenig
D. Kroeselberg
Siemens
Corporate Technology
Document: draft-tschofenig-eap-ikev2-01.txt
Expires: December 2003 June 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.
Tschofenig, Kroselberg Expires - December 2003 [Page 1]
EAP IKEv2 June 2003
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................3
3. Protocol overview.............................................3
4. Identities used in EAP-IKEv2..................................6
5. Packet Format.................................................8
6. Key derivation................................................9
7. Security Considerations.......................................9
8. Open Issues..................................................10
9. References...................................................10
Acknowledgments.................................................11
Author's Addresses..............................................11
Full Copyright Statement........................................12
1. Introduction
IKEv2 [2] is a protocol which consists of two exchanges:
(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 uses the IKEv2
payloads and messages used for the initial IKEv2 exchange which
establishes an IKE-SA.
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 Denial-of-
Service (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
Tschofenig, Kroselberg Expires - December 2003 [Page 2]
EAP IKEv2 June 2003
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.
EAP-IKEv2 therefore provides
a) a well-known IKEv2 symmetric/asymmetric authentication and
b) a new EAP tunneling method.
2. Terminology
This document does not introduce new terms other than those defined
in [1] or in [2].
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [10].
3. Protocol overview
This section provides some overview over EAP-IKEv2 message
exchanges. Note that some payloads are omitted (such as SAi2 and
SAr2 ) which are mandatory for IKEv2 but are not required in EAP-
IKEv2 since they are used to establish an IPsec SA.
IKEv2 uses the same protocol message exchanges for both symmetric
and asymmetric authentication. The difference lies only in the
computation of the AUTH payload. See Section 2.15 of [2] for more
information about the details of the AUTH payload computation. It is
even possible to combine symmetric (e.g. from the client to the
server) with asymmetric authentication (e.g. from the server to the
client) in a single protocol exchange. Additionally, for symmetric
authentication no CERT and CERTREQ payloads are required. Figure 1
depicts such a protocol exchange.
Message exchanges are reused 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.
The first message flow shows EAP-IKEv2 without the optional DoS
protection exchanges. The DoS protection mechanism prevents the
responder from allocating state and performing heavy cryptographic
operations based on the first incoming message. The core EAP-IKEv2
exchange (message (4) - (7)) consists of four messages (two round
Tschofenig, Kroselberg Expires - December 2003 [Page 3]
EAP IKEv2 June 2003
trips)_only. The first two messages constitute the standard EAP
identity exchange and are not mandatory if the EAP server is known.
1) I <-- R: EAP-Request/Identity
2) I --> R: EAP-Response/Identity(Id)
3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)
4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH})
8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)
9) I <-- R: EAP-Success
Figure 1: EAP-IKEv2 message flow
The subsequent message flow shows EAP-IKEv2 with DoS protection
enabled. 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 round trip (message
(5) and (6)) is required.
1) I <-- R: EAP-Request/Identity
2) I --> R: EAP-Response/Identity(Id)
3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)
4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,0), N(COOKIE-REQUIRED), N(COOKIE))
6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,0), N(COOKIE), SAi1, KEi, Ni)
7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
Tschofenig, Kroselberg Expires - December 2003 [Page 4]
EAP IKEv2 June 2003
HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
9) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH})
10) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)
11) I <-- R: EAP-Success
Figure 2: EAP-IKEv2 with Cookies
The Secure Legacy Authentication (SLA) EAP message exchange shown in
Figure 3 is taken from Section 2.16 of [2] and adapted. It provides
an example of a successful inner EAP exchange using the EAP-SIM
Authentication method [8], which is secured by the IKE-SA.
Implementations MUST ensure that infinite recursions of EAP and EAP-
IKEv2 exchanges are not allowed. (TBD: some limit necessary)
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 {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(
HDR, SK {EAP(EAP-Response/SIM/Challenge(AT_MAC) ), [AUTH]})
Tschofenig, Kroselberg Expires - December 2003 [Page 5]
EAP IKEv2 June 2003
I <-- R: EAP-Success
Figure 3: EAP-IKEv2 SLA with EAP-SIM Authentication
Please note that the message flow in Figure 3 does not include an
EAP-Request/Identity and the corresponding EAP-Response/Identity
message inside the EAP-IKEv2 tunnel. Although it would be possible
to perform such an exchange IKEv2 suggests using the IDi payload for
this purpose. As a consequence the initiators identity is not
protected against active attacks.
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
- Port handling
- NAT traversal
Rekeying of IKE-SAs might be required but requires further study.
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.
IKEv2 also provides functionality for the initiator to request
address information from the responder as described in Section 2.19
of [2]. Using this functionality it is possible for an end host to
securely request address configuration information from the local
network.
4. Identities used in EAP-IKEv2
A number of identities are used in IKEv2 and particularly when EAP
is used. This section describes their function within the different
exchanges. Note that EAP-IKEv2 does not introduce more identities
than any other tunneling approach. Figure 4 shows which identities
are used during the individual phases of the protocol.
+-------+ +-------------+ +---------+ +--------+
|Client | |Front-End | |Local AAA| |Home AAA|
| | |Authenticator| |Server | |Server |
+-------+ +-------------+ +---------+ +--------+
Tschofenig, Kroselberg Expires - December 2003 [Page 6]
EAP IKEv2 June 2003
EAP/Identity-Request
<---------------------
(a) EAP/Identity-Response
---------------------------------->
Tunnel-Establishment
(b) (Identities of IKEv2 are used)
Server (Network) Authentication
<----------------------------------
...
---------------------------------->
+---------------------------------+
| Secure Tunnel |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Secure Legacy Authentication |
| protected with the IKE-SA |
(c) | (Identities of the tunneled |
| EAP method are used) |
| Client Authentication |
|---------------------------------+---------------->
|<--------------------------------+-----------------
+---------------------------------+
Figure 4: Identities used in EAP-IKEv2
a) The first part of the (outer) EAP message exchange provides
information about the identities of the EAP endpoints. This message
exchange mainly is an identity request/response. This exchange is
optional if the EAP server is known already or can be learned by
other means.
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 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.
Tschofenig, Kroselberg Expires - December 2003 [Page 7]
EAP IKEv2 June 2003
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).
5. 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 5:
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 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packet Format
No additional packet formats other than those defined in [2] are
required for this EAP method.
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 four bits of the eight bit flags field are defined. The
remaining bits are set to zero.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S F L M 0 0 0 0|
+-+-+-+-+-+-+-+-+
Tschofenig, Kroselberg Expires - December 2003 [Page 8]
EAP IKEv2 June 2003
S = EAP-IKEv2 start message
F = EAP-IKEv2 finish message
L = Length included
M = More fragments
EAP-IKEv2 messages which have neither the S nor the F flag set
contain regular IKEv2 message payloads inside the Data field.
With regard to fragmentation we follow the suggestions and
descriptions given in Section 2.8 of [9]: The L indicates that a
length field is present and the M flag indicates fragments. The L
flag MUST be set for the first fragment and the M flag MUST be set
on all fragments expect for the last one. Each fragment sent must
subsequently be acknowledged.
The Message Length field is four octets long and present only if the
L bit is set. This field provides the total message length that is
being fragmented.
The EAP Type for this EAP method is <TBD>.
6. 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.
7. 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. An example of the security issues which
are pending at the moment is active user identity confidentiality
Tschofenig, Kroselberg Expires - December 2003 [Page 9]
EAP IKEv2 June 2003
for the initiator (particularly for tunneling of EAP packets
protected by the IKE-SA).
8. Open Issues
The following issues are still under consideration:
- 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, which 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. In some cases it might be possible to skip these messages.
Furthermore it is possible to omit the first exchange if the
identity can be learned by other means.
- Fragmentation
Fragments sent must subsequently be acknowledged. Typically an empty
EAP packet is used. This, however, adds a vulnerability to the
protocol.
- EAP-IKEv2 Finish Message
It might be advisable to protect the EAP-IKEv2 finish message since
a key is already available.
- Rekeying
As mentioned in Section 3 it might be useful to keep rekeying
functionality of IKEv2.
9. References
[1] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
Tschofenig, Kroselberg Expires - December 2003 [Page 10]
EAP IKEv2 June 2003
[2] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", internet
draft, Internet Engineering Task Force, 2003. Work in progress.
[3] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in
tunnelled authentication", In the Proceedings of the 11th
International Workshop on Security Protocols, Cambridge, UK, April
2003. To be published in the Springer-Verlag LNCS series.
[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] H. Haverinen, J. Salowey: "EAP SIM Authentication", internet
draft, Internet Engineering Task Force, 2003. Work in progress.
[9] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected EAP
Protocol (PEAP)", internet draft, Internet Engineering Task Force,
March 2003. Work in progress.
[10] S. Bradner: "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Internet Engineering Task Force, March 1997.
Acknowledgments
We would like to thank Jari Arkko and Paoulo Pagliusi for their
comments to the initial version of this draft.
Additionally we would like to thank members of the PANA design team
(namely D. Forsberg, Y. Ohba and A. Yegin) for their comments and
input to this draft.
Author's Addresses
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
Tschofenig, Kroselberg Expires - December 2003 [Page 11]
EAP IKEv2 June 2003
EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Dirk.Kroeselberg@siemens.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig, Kroselberg Expires - December 2003 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-22 05:34:43 |