< draft-tschofenig-eap-ikev2-01.txt   draft-tschofenig-eap-ikev2-02.txt >
EAP EAP
Internet Draft H. Tschofenig Internet Draft H. Tschofenig
D. Kroeselberg D. Kroeselberg
Siemens Siemens
Corporate Technology Y. Ohba
Document: draft-tschofenig-eap-ikev2-01.txt Toshiba
Expires: December 2003 June 2003 Document: draft-tschofenig-eap-ikev2-02.txt
Expires: April 2002 October 2003
EAP IKEv2 Method EAP IKEv2 Method
(EAP-IKEv2) (EAP-IKEv2)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 8 skipping to change at page 2, line 8
EAP-IKEv2 is an EAP method which reuses the cryptography and the EAP-IKEv2 is an EAP method which reuses the cryptography and the
payloads of IKEv2, creating a flexible EAP method that supports both payloads of IKEv2, creating a flexible EAP method that supports both
symmetric and asymmetric authentication. Furthermore protection of symmetric and asymmetric authentication. Furthermore protection of
legacy authentication mechanisms is supported. This EAP method legacy authentication mechanisms is supported. This EAP method
offers the security benefits of IKEv2 without the goal of offers the security benefits of IKEv2 without the goal of
establishing IPsec security associations. establishing IPsec security associations.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................2
2. Terminology...................................................3 2. IKEv2 and EAP-IKEv2 Overview..................................3
3. Protocol overview.............................................3 3. Terminology...................................................4
4. Identities used in EAP-IKEv2..................................6 4. Protocol overview.............................................4
5. Packet Format.................................................8 5. Identities used in EAP-IKEv2..................................7
6. Key derivation................................................9 6. Packet Format.................................................9
7. Security Considerations.......................................9 7. Retransmission...............................................10
8. Open Issues..................................................10 8. Key derivation...............................................10
9. References...................................................10 9. Error Handling...............................................11
Acknowledgments.................................................11 10. Security Considerations.....................................13
Author's Addresses..............................................11 11. Open Issues.................................................13
Full Copyright Statement........................................12 12. Normative References........................................13
13. Informative References......................................14
Acknowledgments.................................................14
Author's Addresses..............................................15
Full Copyright Statement........................................15
1. Introduction 1. Introduction
IKEv2 [2] is a protocol which consists of two exchanges: This document specifies the EAP-IKEv2 authentication method. EAP-
IKEv2 is a flexible EAP method which makes the IKEv2 protocolĘs
features available for scenarios using EAP-based authentication.
The main advantage of EAP-IKEv2 is that it does not define a new
cryptographic protocol, but re-uses the IKEv2 authentication
protocol, and thereby provides strong, well-analyzed, cryptographic
properties as well as broad flexibility. This includes the support
of authentication methods and configuration payloads for remote
access scenarios.
EAP-IKEv2 can be used directly to mutually authenticate EAP peers.
This may be based on either symmetric methods using pre-shared keys,
or on asymmetric methods based on public/private key pairs,
Certificates and CRLs. In addition, EAP-IKEv2 supports two-phased
authentication schemes by establishing a server-authenticated secure
tunnel, and by subsequently protecting an EAP authentication
allowing for legacy client authentication methods. Hence, EAP-IKEv2
provides a secure EAP tunneling method.
A non-goal of EAP-IKEv2 (and basically the major difference to plain
IKEv2) is the establishment of IPsec security associations, as this
would not make much sense in the standard AAA three-party scenario,
consisting of an EAP peer, an authenticator (NAS) and a back-end
authentication server terminating EAP. IPsec SA establishment may be
required locally (i.e., between the EAP peer and some access
server). However, SA establishment within an EAP method would only
provide SAs between the EAP peer and the back-end authentication
server. Other approaches as e.g., those of the IETF PANA group are
considered more appropriate in this case.
2. IKEv2 and EAP-IKEv2 Overview
IKEv2 [Kau03] is a protocol which consists of two exchanges:
(1) an authentication and key exchange protocol which establishes an (1) an authentication and key exchange protocol which establishes an
IKE-SA. IKE-SA.
(2) messages and payloads which focus on the negotiation of (2) messages and payloads which focus on the negotiation of
parameters in order to establish IPsec security associations (i.e. parameters in order to establish IPsec security associations (i.e.,
Child-SAs). These payloads contain algorithm parameters and traffic Child-SAs). These payloads contain algorithm parameters and traffic
selector fields. selector fields.
In addition to the above-mentioned parts IKEv2 also includes some In addition to the above-mentioned parts IKEv2 also includes some
payloads and messages which allow configuration parameters to be payloads and messages which allow configuration parameters to be
exchanged primarily for remote access scenarios. exchanged primarily for remote access scenarios.
The EAP-IKEv2 method defined by this document uses the IKEv2 The EAP-IKEv2 method defined by this document uses the IKEv2
payloads and messages used for the initial IKEv2 exchange which payloads and messages used for the initial IKEv2 exchange which
establishes an IKE-SA. establishes an IKE-SA.
IKEv2 provides an improvement over IKEv1 [5] as described in IKEv2 provides an improvement over IKEv1 [RFC2409] as described in
Appendix A of [2]. Important for this document are the reduced Appendix A of [Kau03]. Important for this document are the reduced
number of initial exchanges, support of legacy authentication, number of initial exchanges, support of legacy authentication,
decreased latency of the initial exchange, optional Denial-of- decreased latency of the initial exchange, optional Denial-of-
Service (DoS) protection capability and some other fixes (e.g. hash Service (DoS) protection capability and some other fixes (e.g., hash
problem). IKEv2 is a cryptographically sound protocol that has problem). IKEv2 is a cryptographically sound protocol that has
received a considerable amount of expert review and that benefits received a considerable amount of expert review and that benefits
from a long practical experience with IKE. from a long practical experience with IKE.
The goal of EAP-IKEv2 is to inherit these properties within an The goal of EAP-IKEv2 is to inherit these properties within an
efficient, secure EAP method. efficient, secure EAP method.
In addition, IKEv2 provides authentication and key exchange In addition, IKEv2 provides authentication and key exchange
capabilities which allow an entity to use symmetric as well as capabilities which allow an entity to use symmetric as well as
asymmetric authentication in addition to legacy authentication asymmetric authentication within a single protocol. Such flexibility
support within a single protocol. Such flexibility is considered is considered important for an EAP method and is provided by EAP-
important for an EAP method and is provided by EAP-IKEv2. IKEv2.
[6] provides a good tutorial for IKEv2 design decisions. [Per03] provides a good tutorial for IKEv2 design decisions.
EAP-IKEv2 therefore provides EAP-IKEv2 therefore provides
a) a well-known IKEv2 symmetric/asymmetric authentication and a) well-known IKEv2 symmetric/asymmetric authentication and
b) a new EAP tunneling method. b) a new EAP tunneling method.
2. Terminology EAP-IKEv2 provides a secure fragmentation mechanism in which
integrity protection is performed for each fragment of an IKEv2
message.
3. Terminology
This document does not introduce new terms other than those defined This document does not introduce new terms other than those defined
in [1] or in [2]. in [RFC2284] or in [Kau03].
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [10]. document, are to be interpreted as described in [RFC2119].
3. Protocol overview 4. Protocol overview
This section provides some overview over EAP-IKEv2 message This section provides some overview over EAP-IKEv2 message
exchanges. Note that some payloads are omitted (such as SAi2 and exchanges. Note that some payloads are omitted (such as SAi2 and
SAr2 ) which are mandatory for IKEv2 but are not required in EAP- SAr2) which are mandatory for IKEv2 but are not required in EAP-
IKEv2 since they are used to establish an IPsec SA. IKEv2 since they are used to establish an IPsec SA.
IKEv2 uses the same protocol message exchanges for both symmetric IKEv2 uses the same protocol message exchanges for both symmetric
and asymmetric authentication. The difference lies only in the and asymmetric authentication. The difference lies only in the
computation of the AUTH payload. See Section 2.15 of [2] for more computation of the AUTH payload. See Section 2.15 of [Kau03] for
information about the details of the AUTH payload computation. It is more information about the details of the AUTH payload computation.
even possible to combine symmetric (e.g. from the client to the It is even possible to combine symmetric (e.g., from the client to
server) with asymmetric authentication (e.g. from the server to the the server) with asymmetric authentication (e.g., from the server to
client) in a single protocol exchange. Additionally, for symmetric the client) in a single protocol exchange. Figure 1 depicts such a
authentication no CERT and CERTREQ payloads are required. Figure 1 protocol exchange.
depicts such a protocol exchange.
Message exchanges are reused from [2], and are adapted. Since this Message exchanges are reused from [Kau03], and are adapted. Since
document does not describe frameworks or particular architectures this document does not describe frameworks or particular
the message exchange takes place between two parties - between the architectures the message exchange takes place between two parties -
Initiator (I) and the Responder (R). In context of EAP the Initiator between the Initiator (I) and the Responder (R). In context of EAP
is often called Authenticating Peer whereas the Responder is the Initiator is often called Authenticating Peer whereas the
referred as Authenticator. Responder is referred as Authenticator.
The first message flow shows EAP-IKEv2 without the optional DoS The first message flow shows EAP-IKEv2 without the optional DoS
protection exchanges. The DoS protection mechanism prevents the protection exchanges. The core EAP-IKEv2 exchange (message (4) -
responder from allocating state and performing heavy cryptographic (7)) consists of four messages (two round trips)_only. The first two
operations based on the first incoming message. The core EAP-IKEv2 messages constitute the standard EAP identity exchange and are not
exchange (message (4) - (7)) consists of four messages (two round mandatory if the EAP server is known.
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 1) I <-- R: EAP-Request/Identity
2) I --> R: EAP-Response/Identity(Id) 2) I --> R: EAP-Response/Identity(Id)
3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) 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) 4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH}) HDR(A,B), SK {IDr, [CERT,] AUTH})
8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish) 8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)
9) I <-- R: EAP-Success 9) I <-- R: EAP-Success
Figure 1: EAP-IKEv2 message flow Figure 1: EAP-IKEv2 message flow
The subsequent message flow shows EAP-IKEv2 with DoS protection The subsequent message flow shows EAP-IKEv2 with DoS protection
enabled. The IKEv2 DoS protection mechanism uses cookies and keeps enabled. The IKEv2 DoS protection mechanism uses cookies and keeps
the responder stateless when it receives the first IKEv2 message. As the responder stateless when it receives the first IKEv2 message,
a consequence of DoS protection an additional round trip (message preventing it from performing heavy cryptographic operations based
(5) and (6)) is required. on this first incoming message. As a consequence of DoS protection
an additional round trip (message (5) and (6)) is required.
1) I <-- R: EAP-Request/Identity 1) I <-- R: EAP-Request/Identity
2) I --> R: EAP-Response/Identity(Id) 2) I --> R: EAP-Response/Identity(Id)
3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) 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) 4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
skipping to change at page 5, line 19 skipping to change at page 6, line 12
9) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 9) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH}) HDR(A,B), SK {IDr, [CERT,] AUTH})
10) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish) 10) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)
11) I <-- R: EAP-Success 11) I <-- R: EAP-Success
Figure 2: EAP-IKEv2 with Cookies Figure 2: EAP-IKEv2 with Cookies
The Secure Legacy Authentication (SLA) EAP message exchange shown in The Secure Legacy Authentication (SLA) EAP message exchange shown in
Figure 3 is taken from Section 2.16 of [2] and adapted. It provides Figure 3 is taken from Section 2.16 of [Kau03] and adapted. It
an example of a successful inner EAP exchange using the EAP-SIM provides an example of a successful inner EAP exchange using the
Authentication method [8], which is secured by the IKE-SA. EAP-SIM Authentication method [HS03], which is secured by the IKE-
SA.
Implementations MUST ensure that infinite recursions of EAP and EAP- Implementations MUST ensure that infinite recursions of EAP and EAP-
IKEv2 exchanges are not allowed. (TBD: some limit necessary) IKEv2 exchanges are not allowed. (TBD: some limit necessary)
I <-- R: EAP-Request/Identity I <-- R: EAP-Request/Identity
I --> R: EAP-Response/Identity(Id) I --> R: EAP-Response/Identity(Id)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)
I --> R: EAP-Response/EAP-Type=EAP-IKEv2( I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SAi1, KEi, Ni) HDR, SAi1, KEi, Ni)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
HDR, SAr1, KEr, Nr, [CERTREQ]) HDR, SAr1, KEr, Nr, [CERTREQ])
I --> R: EAP-Response/EAP-Type=EAP-IKEv2( I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {IDi, [CERTREQ,] [IDr,]}) HDR, SK {IDi, [CERTREQ,] [IDr,]})
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR,
SK {EAP(EAP- Request/SIM/Start(AT_VERSION_LIST)),[AUTH]}) SK {IDr, [CERT,] AUTH, EAP(EAP-Request /SIM
/Start(AT_VERSION_LIST))})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP-
Response/SIM/Start(AT_NONCE_MT, AT_SELECTED_VERSION)), [AUTH]}) Response/SIM/Start(AT_NONCE_MT, AT_SELECTED_VERSION)),
[AUTH]})
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP-
Request/SIM/Challenge(AT_RAND, AT_MAC)), [AUTH]}) Request/SIM/Challenge(AT_RAND, AT_MAC)), [AUTH]})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2( I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {EAP(EAP-Response/SIM/Challenge(AT_MAC) ), [AUTH]}) HDR, SK {EAP(EAP-Response/SIM/Challenge(AT_MAC) ), [AUTH]})
I <-- R: EAP-Success I <-- R: EAP-Success
Figure 3: EAP-IKEv2 SLA with EAP-SIM Authentication Figure 3: EAP-IKEv2 SLA with EAP-SIM Authentication
Please note that the message flow in Figure 3 does not include an Please note that the message flow in Figure 3 does not include an
EAP-Request/Identity and the corresponding EAP-Response/Identity EAP-Request/Identity and the corresponding EAP-Response/Identity
skipping to change at page 6, line 22 skipping to change at page 7, line 18
to perform such an exchange IKEv2 suggests using the IDi payload for to perform such an exchange IKEv2 suggests using the IDi payload for
this purpose. As a consequence the initiators identity is not this purpose. As a consequence the initiators identity is not
protected against active attacks. protected against active attacks.
Since the goal of this EAP method is not to establish an IPsec SA Since the goal of this EAP method is not to establish an IPsec SA
some payloads used in IKEv2 are omitted. In particularly the some payloads used in IKEv2 are omitted. In particularly the
following messages and payloads are not required: following messages and payloads are not required:
- Traffic Selectors - Traffic Selectors
- IPsec SA negotiation payloads - IPsec SA negotiation payloads
(e.g. CREATE_CHILD_SA exchange or SAx2 payloads) (e.g., CREATE_CHILD_SA exchange or SAx2 payloads)
- ECN Notification - ECN Notification
- Port handling - Port handling
- NAT traversal - NAT traversal
Rekeying of IKE-SAs might be required but requires further study.
Some of these messages and payloads are optional in IKEv2. Some of these messages and payloads are optional in IKEv2.
In general it does not make sense to directly negotiate IPsec SAs 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 with EAP-IKEv2, as such SAs were unlikely to be used between the EAP
endpoints. endpoints.
IKEv2 also provides functionality for the initiator to request IKEv2 also provides functionality for the initiator to request
address information from the responder as described in Section 2.19 address information from the responder as described in Section 2.19
of [2]. Using this functionality it is possible for an end host to of [Kau03]. Using this functionality it is possible for an end host
securely request address configuration information from the local to securely request address configuration information from the local
network. network.
4. Identities used in EAP-IKEv2 5. Identities used in EAP-IKEv2
A number of identities are used in IKEv2 and particularly when EAP A number of different places allow to convey identity information in
is used. This section describes their function within the different IKEv2, when combined with EAP. This section describes their function
exchanges. Note that EAP-IKEv2 does not introduce more identities within the different exchanges of EAP-IKEv2. Note that EAP-IKEv2
than any other tunneling approach. Figure 4 shows which identities does not introduce more identities than any other tunneling
are used during the individual phases of the protocol. approach. Figure 4 shows which identities are used during the
individual phases of the protocol.
+-------+ +-------------+ +---------+ +--------+ +-------+ +-------------+ +---------+ +--------+
|Client | |Front-End | |Local AAA| |Home AAA| |Client | |Front-End | |Local AAA| |Home AAA|
| | |Authenticator| |Server | |Server | | | |Authenticator| |Server | |Server |
+-------+ +-------------+ +---------+ +--------+ +-------+ +-------------+ +---------+ +--------+
EAP/Identity-Request EAP/Identity-Request
<--------------------- <---------------------
(a) EAP/Identity-Response (a) EAP/Identity-Response
----------------------------------> ---------------------------------->
Tunnel-Establishment Tunnel-Establishment
(b) (Identities of IKEv2 are used) (b) (Identities of IKEv2 are used)
Server (Network) Authentication Server (Network) Authentication
<---------------------------------- <----------------------------------
... ...
----------------------------------> ---------------------------------->
+---------------------------------+ +---------------------------------+
| Secure Tunnel | | Secure Tunnel |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
skipping to change at page 7, line 42 skipping to change at page 8, line 37
exchange mainly is an identity request/response. This exchange is exchange mainly is an identity request/response. This exchange is
optional if the EAP server is known already or can be learned by optional if the EAP server is known already or can be learned by
other means. other means.
b) The identities used within EAP-IKEv2 for both the initiator and b) The identities used within EAP-IKEv2 for both the initiator and
the responder. The initiator identity is often associated with a the responder. The initiator identity is often associated with a
user identity such as a fully-qualified RFC 822 email address. The user identity such as a fully-qualified RFC 822 email address. The
identity of the responder might be a FQDN. The identity is of identity of the responder might be a FQDN. The identity is of
importance for authorization. importance for authorization.
For secure legacy authentication an EAP message exchange is c) For secure legacy authentication an EAP message exchange is
protected with the established IKE-SA as shown in Figure 3. This protected with the established IKE-SA as shown in Figure 3. This
exchange again adds EAP identities. exchange again adds EAP identities.
c) This inner EAP message exchange serves the purpose of client This inner EAP message exchange serves the purpose of client
authentication. The two identities used thereby are the EAP identity authentication. The two identities used thereby are the EAP identity
(i.e. a NAI) and possibly a separate identity for the selected EAP (i.e., a NAI) and possibly a separate identity for the selected EAP
method. method.
The large number of identities is required due to nesting of The large number of identities is required due to nesting of
authentication methods and due to overloaded function of the authentication methods and due to overloaded function of the
identity for routing (i.e. authentication end point indication). identity for routing (i.e., authentication end point indication).
The number of recursions of EAP and IKEv2 is limited, see Section 4.
Hence with this additional (nested) EAP exchange the end point of 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 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 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 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 endpoint and the endpoint of the inner EAP exchange, but might be
protected by other means that are not considered in this document). protected by other means that are not considered in this document).
5. Packet Format 6. Packet Format
The IKEv2 payloads, which are defined in [2], are embedded into the The IKEv2 payloads, which are defined in [Kau03], are embedded into
Data field of the standard EAP Request/Response packets. The Code, the Data field of the standard EAP Request/Response packets. The
Identifier, Length and Type field is described in [1]. The Type-Data Code, Identifier, Length and Type field is described in [RFC2284].
field carries a one byte Flags field following the IKEv2 payloads. The Type-Data field carries a one byte Flags field following the
Each IKEv2 payload starts with a header field HDR (see [2]). IKEv2 payloads. Each IKEv2 payload starts with a header field HDR
(see [Kau03]).
The packet format is shown in The packet format is shown in Figure 5.
Figure 5:
0 1 2 3 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 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 | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length | | Type | Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Data ... | | Message Length | Data ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Checksum Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packet Format Figure 5: Packet Format
No additional packet formats other than those defined in [2] are No additional packet formats other than those defined in [Kau03] are
required for this EAP method. required for this EAP method.
The Flags field is required to indicate Start and Finish messages The Flags field is required to indicate Start and Finish messages
which are required due to the asymmetric nature of IKEv2 and the which are required due to the asymmetric nature of IKEv2 and the
Request/Response message handling of EAP. Request/Response message handling of EAP.
Currently four bits of the eight bit flags field are defined. The Currently five bits of the eight bit flags field are defined. The
remaining bits are set to zero. remaining bits are set to zero.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S F L M 0 0 0 0| |S F L M 0 0 0 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S = EAP-IKEv2 start message S = EAP-IKEv2 start message
F = EAP-IKEv2 finish message F = EAP-IKEv2 finish message
L = Length included L = Length included
M = More fragments M = More fragments
I = Integrity Checksum Data included
EAP-IKEv2 messages which have neither the S nor the F flag set EAP-IKEv2 messages which have neither the S nor the F flag set
contain regular IKEv2 message payloads inside the Data field. contain regular IKEv2 message payloads inside the Data field.
With regard to fragmentation we follow the suggestions and With regard to fragmentation we follow the suggestions and
descriptions given in Section 2.8 of [9]: The L indicates that a descriptions given in Section 2.8 of [PS+03]: The L indicates that a
length field is present and the M flag indicates fragments. The L 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 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 on all fragments expect for the last one. Each fragment sent must
subsequently be acknowledged. subsequently be acknowledged.
The Message Length field is four octets long and present only if the 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 L bit is set. This field provides the total message length that is
being fragmented. being fragmented (i.e., the length of the Data field.).
The Integrity Checksum Data is the cryptographic checksum of the
entire EAP message starting with the Code field through the Data
field. This field presents only if the I bit is set. The field
immediately follows the Data field without adding any padding octet
before or after itself. The checksum MUST be computed for each
fragment (including the case where the entire IKEv2 message is
carried in a single fragment) by using the same key (i.e., SK_ai or
SK_ar) that is used for computing the checksum for the IKEv2
Encrypted payload in the encapsulated IKEv2 message. The Integrity
Checksum Data field is omitted for other packets. To minimize DoS
attacks on fragmented packets, messages that are not protected
SHOULD NOT be fragmented. Note that IKE_SA_INIT messages are the
only ones that are not encrypted or integrity protected, however,
such messages are not likely to be fragmented since they do not
carry certificates.
The EAP Type for this EAP method is <TBD>. The EAP Type for this EAP method is <TBD>.
6. Key derivation 7. Retransmission
The EAP-IKEv2 method described in this document generates sessions Since EAP authenticators support a timer-based retransmission
mechanism for EAP Requests and EAP peers retransmit the last valid
EAP Response when receiving a duplicate EAP Request message, IKEv2
messages MUST NOT be retransmitted based on timers, when used as EAP
authentication method.
8. Key derivation
The EAP-IKEv2 method described in this document generates session
keys. These session keys are used to establish an IKE-SA which keys. These session keys are used to establish an IKE-SA which
provides protection of other payloads. To export a session key as provides protection of subsequent EAP-IKEv2 payloads. To export a
part of the EAP keying framework [7] it is required to derive session key as part of the EAP keying framework [AS+03] it is
another session key for usage with EAP (sometimes referred as Pre- required to derive additional session keys for usage with EAP (i.e.,
Master-Secret). It is good cryptographic security practice to use MSK, EMSK and IV). It is good cryptographic security practice to use
different keys for different "applications". Hence we suggest to different keys for different "applications". Hence we suggest
reuse the key derivation function suggested in Section 2.17 of [2] reusing the key derivation function suggested in Section 2.17 of
to export the KEYMAT (as a Pre-Master-Secret) for further key [Kau03] to create keying material KEYMAT.
derivation.
The key derivation function defined is KEYMAT = prf+(SK_d, Ni | Nr), 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. where Ni and Nr are the Nonces from the IKE_SA_INIT exchange.
7. Security Considerations According to [AS+03] the keying material of MSK, EMSK and IV have to
be at minimum 64, 64 and 64 octets long.
The security of the proposed EAP method is intentionally based on The produced keying material for MSK, EMSK and IV MUST be twice the
IKEv2 [2]. Man-in-the-middle attacks discovered in the context of minimum size (i.e., 128 octets).
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 9. Error Handling
versions of this document. An example of the security issues which
are pending at the moment is active user identity confidentiality
for the initiator (particularly for tunneling of EAP packets
protected by the IKE-SA).
8. Open Issues As described in the IKEv2 specification, there are many kinds of
errors that can occur during IKE processing (i.e., processing the
Data field of EAP-IKEv2 Request and Response messages) and detailed
processing rules. EAP-IKEv2 follows the error handling rules
specified in the IKEv2 specification for errors on the Data field of
EAP-IKEv2 messages, with the following additional rules:
The following issues are still under consideration: o For an IKEv2 error that triggers an initiation of an IKEv2
exchange (i.e., an INFORMATIONAL exchange), an EAP-IKEv2 message
that contains the IKEv2 request that is generated for the IKEv2
exchange MUST be sent to the peering entity. In this case, the
EAP message that caused the IKEv2 error MUST be treated as a
valid EAP message.
- Session resumption o For an IKEv2 error for which the IKEv2 message that caused the
error is discarded without triggering an initiation of an IKEv2
exchange, the EAP message that carries the the erroneous IKEv2
message MUST be treated as an invalid EAP message and discarded
as if it were not received at EAP layer.
For an error occurred outside the Data field of EAP-IKEv2 messages,
including defragmentation failures, integrity check failures, errors
in Flag and Message Length fields, the EAP message that caused the
error MUST be treated as an invalid EAP message and discarded as if
it were not received at EAP layer.
When the EAP-IKEv2 method runs on a backend EAP server, an
outstanding EAP Request is not retransmitted based on timer and thus
there is a possibility of EAP conversation stall when the EAP server
receives an invalid EAP Response. To avoid this, the EAP server MAY
retransmit the outstanding EAP Request in response to an invalid EAP
Response. Alternatively, the EAP server MAY send a new EAP Request
in response to an invalid EAP Response with assigning a new
Identifier and putting the last transmitted IKEv2 message in the
Data field.
10. Fast Resume
TLS provides the capability of resuming a session. This offers TLS provides the capability of resuming a session. This offers
primarily performance improvement for a new authentication and key primarily performance improvement for a new authentication and key
exchange protocol run. It is for further study whether the concept exchange protocol run. In order to resume a session two approaches
of session resumption (i.e. a fast re-authentication procedure) is a can be taken:
useful context for EAP methods and for the AAA environment in
particular. If it turns out to be useful then one possible approach a) Generic approach
is to reuse the dead peer detection informational exchange, which is b) Method-specific approach
able to provide fast re-authentication based on the established IKE-
SA. This exchange is cheap in terms of processing complexity and The idea of approach (a) is to
provides both end points the capability to perform authentication - force each EAP method to create an EAP SA. This SA is kept at the
based on an available IKE-SA. EAP peer and the EAP server and is used for subsequent exchanges.
- built this functionality into EAP itself.
Approach (b) is already used by existing methods using TLS. Choosing
(b) does not require any changes to EAP itself since each EAP method
has to implement its own mechanism.
So far it has not been decided which approach should be suggested
for EAP. In any case it seems that a generic approach contains some
difficulties since EAP methods need to negotiate the necessary
parameters with are required to build the EAP SA (lifetime,
algorithms, identifiers, etc.). Furthermore, it is necessary to
cover error cases which happen if the wrong AAA server is selected
(due to failover or load balancing) and the EAP SA is not found.
For both cases it is necessary to establish to keep some state
information. An additional motivation for establishing state is the
ability to provide passive user identity confidentiality as
exercised in [AH03]. Subsequent protocol exchanges use a pseudonym
instead of the long-term user identity.
Additionally it is necessary to list some requirements for
establishing an EAP SA and for running a fast resume. For example,
does the fast resume exchange need to provide key agreement or key
transport functionality?
Once the above-raised issues have been addressed in the EAP working
group a solution will be added to EAP-IKEv2.
11. Security Considerations
The security of the proposed EAP method is intentionally based on
IKEv2 [Kau03]. Man-in-the-middle attacks discovered in the context
of tunneled authentication protocols (see [AN03] and [PL+03]) are
applicable to IKEv2 if legacy authentication with EAP [RFC2284] is
used. To counter this threat IKEv2 provides a compound
authentication by including the EAP provided session key inside the
AUTH payload.
12. Open Issues
The following issues are still under consideration:
- Reducing the number of messages - Reducing the number of messages
The message flows given in this document finish with an EAP-Success The message flows given in this document finish with an EAP-Success
message. In some cases it might be possible to skip these messages. message. In some cases it might be possible to skip these messages.
Furthermore it is possible to omit the first exchange if the Furthermore it is possible to omit the first exchange if the
identity can be learned by other means. identity can be learned by other means.
- Fragmentation - Notifications
Fragments sent must subsequently be acknowledged. Typically an empty IKEv2 provides the concept of notifications to exchange messages at
EAP packet is used. This, however, adds a vulnerability to the any time (e.g., dead peer detection). It remains for further study
protocol. which of these messages are required for this EAP method.
- EAP-IKEv2 Finish Message - Roles of initiator and responder
It might be advisable to protect the EAP-IKEv2 finish message since Figure 4 shows the initiator starting the EAP-IKEv2 exchange.
a key is already available. However, there is also the possibility to have the EAP server to
start the exchange which saves roundtrips. It remains for further
study to analyze the resulting security properties.
- Rekeying 13. Normative References
As mentioned in Section 3 it might be useful to keep rekeying [RFC2284] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication
functionality of IKEv2. Protocol (EAP)", RFC 2284, March 1998.
9. References [Kau03] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol",
internet draft, Internet Engineering Task Force, October 2003. Work
in progress.
[1] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication [RFC2119] S. Bradner: "Key words for use in RFCs to Indicate
Protocol (EAP)", RFC 2284, March 1998. Requirement Levels", RFC 2119, Internet Engineering Task Force,
March 1997.
[2] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", internet 14. Informative References
draft, Internet Engineering Task Force, 2003. Work in progress.
[3] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in [AN03] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in
tunnelled authentication", In the Proceedings of the 11th tunnelled authentication", In the Proceedings of the 11th
International Workshop on Security Protocols, Cambridge, UK, April International Workshop on Security Protocols, Cambridge, UK, April
2003. To be published in the Springer-Verlag LNCS series. 2003. To be published in the Springer-Verlag LNCS series.
[4] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. Aboba, [PL+03] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B.
"The compound authentication binding problem," internet draft, Aboba, "The compound authentication binding problem," internet
Internet Engineering Task Force, 2003. Work in progress. draft, Internet Engineering Task Force, 2003. Work in progress.
[5] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange
2409, November 1998. (IKE)", RFC 2409, November 1998.
[6] R. Perlman: "Understanding IKEv2: Tutorial, and rationale for [Per03] R. Perlman: "Understanding IKEv2: Tutorial, and rationale
decisions", internet draft, Internet Engineering Task Force, 2003. for decisions", internet draft, Internet Engineering Task Force,
Work in progress. 2003. Work in progress.
[7] B. Aboba and D. Simon: "EAP Keying Framework", internet draft, [AS+03] B. Aboba, D. Simon and J. Arkko: " EAP Key Management
Internet Engineering Task Force, 2003. Work in progress. Framework", internet draft, Internet Engineering Task Force,
October, 2003. Work in progress.
[8] H. Haverinen, J. Salowey: "EAP SIM Authentication", internet [HS03] H. Haverinen, J. Salowey: "EAP SIM Authentication", internet
draft, Internet Engineering Task Force, 2003. Work in progress. draft, Internet Engineering Task Force, 2003. Work in progress.
[9] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected EAP [PS+03] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected
Protocol (PEAP)", internet draft, Internet Engineering Task Force, EAP Protocol (PEAP)", internet draft, Internet Engineering Task
March 2003. Work in progress. Force, March 2003. Work in progress.
[10] S. Bradner: "Key words for use in RFCs to Indicate Requirement [AH03] J. Arkko and H. Haverinen: "EAP AKA Authentication", internet
Levels", RFC 2119, Internet Engineering Task Force, March 1997. draft, Internet Engineering Task Force, June 2003. Work in
progress.
Acknowledgments Acknowledgments
We would like to thank Jari Arkko and Paoulo Pagliusi for their We would like to thank Bernard Aboba, Jari Arkko, Paoulo Pagliusi
comments to the initial version of this draft. and John Vollbrecht for their comments to this draft.
Additionally we would like to thank members of the PANA design team Additionally we would like to thank members of the PANA design team
(namely D. Forsberg, Y. Ohba and A. Yegin) for their comments and (namely D. Forsberg and A. Yegin) for their comments and input to
input to this draft. the initial version of the draft.
Finally we would like to thank the members of the EAP keying design
team for their discussion in the area of the EAP Key Management
Framework.
Author's Addresses Author's Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munich 81739 Munich
Germany Germany
EMail: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg Dirk Kroeselberg
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munich 81739 Munich
Germany Germany
EMail: Dirk.Kroeselberg@siemens.com EMail: Dirk.Kroeselberg@siemens.com
Yoshihiro Ohba
Toshiba America Research, Inc.
P.O. Box 136
Convent Station, NJ, 07961-0136
USA
Phone: +1 973 829 5174
Email: yohba@tari.toshiba.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
 End of changes. 74 change blocks. 
165 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/