Network Working Group Y. Ohba
Internet-Draft Toshiba
Expires: September 4, 2007 S. Das
Telcordia
R. Lopez
Univ. of Murcia
March 3, 2007
An EAP Method for EAP Extension (EAP-EXT)
draft-ohba-hokey-emu-eap-ext-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Ohba, et al. Expires September 4, 2007 [Page 1]
Internet-Draft EAP-EXT Method March 2007
Abstract
This document describes an EAP method that is used for extending EAP
functionality. The extended functionality includes HOKEY re-
authentication and MSK channel binding. The proposed EAP method
(EAP-EXT) also allows sequencing of multiple EAP methods within
itself. EAP-EXT can generate MSK (Master Session Key) and EMSK
(Extended Master Session Key) in cases where inner method(s)
implementations generate MSK but do not generate EMSK.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. EAP-EXT Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. MSK and EMSK exported from EAP-EXT . . . . . . . . . . . . 8
4.2. EAP-EXT-AUTH-KEY . . . . . . . . . . . . . . . . . . . . . 8
4.3. EAP-EXT-ENC-KEY . . . . . . . . . . . . . . . . . . . . . 8
4.4. HOKEY-REAUTH-KEY . . . . . . . . . . . . . . . . . . . . . 9
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 10
6. EAP-EXT TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Method TLV . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. AUTH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Peer-ID TLV . . . . . . . . . . . . . . . . . . . . . . . 13
6.4. Server-ID TLV . . . . . . . . . . . . . . . . . . . . . . 13
6.5. Reauth-Key-Lifetime TLV . . . . . . . . . . . . . . . . . 13
6.6. PRF TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.7. Channel-Binding-Mechanism TLV . . . . . . . . . . . . . . 14
6.8. Channel-Binding-Data TLV . . . . . . . . . . . . . . . . . 14
6.9. Encryption-Algorithm TLV . . . . . . . . . . . . . . . . . 14
6.10. Integrity-Algorithm TLV . . . . . . . . . . . . . . . . . 15
6.11. Encrypted TLV . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Ohba, et al. Expires September 4, 2007 [Page 2]
Internet-Draft EAP-EXT Method March 2007
1. Introduction
EAP (Extensible Authentication Protocol) is an authentication
protocol which supports multiple authentication algorithms known as
"EAP methods" [RFC3748]. In EAP, an EAP peer and an EAP server
generates EAP keying material, i.e., MSK (Master Session Key) and
EMSK (Extended Master Session Key) upon successful authentication. A
detailed framework for the generation, transport and usage of MSK is
described in [I-D.ietf-eap-keying].
Additional functionalities such as HOKEY re-authentication
[I-D.vidya-eap-er] and MSK channel binding [I-D.ietf-eap-keying] can
be supported by extending EAP functionality. There can be two
approaches for extending EAP functionality. One approach is to
define new EAP Codes to realize the extended EAP functionality in
addition to the existing ones, i.e., Request, Response, Success and
Failure. This approach, however, requires changes to [RFC3748] and
may also require changes to authenticators and lower layer protocols.
The other approach is to define a new EAP method to realize the
extended functionality. For both approaches, it may be desirable
that these extended functionalities are backward compatible. In such
cases, a mechanism for negotiating the capabilities on the extended
functionalities between an EAP peer and an EAP server may be needed.
This document describes an EAP method that is used for extending EAP
functionality. The extended functionality includes HOKEY re-
authentication and MSK channel binding. The proposed EAP method
(EAP-EXT) also allows sequencing of multiple EAP methods within
itself. EAP-EXT can generate MSK and EMSK in cases where inner
method(s) implementations generate MSK but do not generate EMSK.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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].
Ohba, et al. Expires September 4, 2007 [Page 3]
Internet-Draft EAP-EXT Method March 2007
2. EAP-EXT Overview
EAP-EXT provides capabilities exchange. One bit (R-bit) is used for
indicating HOKEY re-authentication capability. One bit (C-bit) is
used for indicating channel binding capability.
When EAP-EXT is used, the precedent EAP-Identity exchange MAY be
omitted if the identity of the peer is known to the server before the
server sends the first EAP-Request. Out of band mechanisms for
providing the identity of the peer may be used e.g., transferring the
identity of the peer between authenticators and servers.
In EAP-EXT, extended EAP capabilities such as HOKEY re-authentication
and MSK channel binding are exchanged between the peer and the
server. At the same time, at least one EAP method (e.g., EAP-TLS) is
run inside EAP-EXT for authenticating the peer. Inner method(s) are
carried in Method TLVs (Type-Length-Values). Until an inner method
generates EAP keying material, no AUTH TLV is included and the
capabilities are non-protected. Hence, if there is only one inner
EAP method, additional EAP-EXT exchange(s) with an AUTH TLV need(s)
to be performed after completion of the inner method and before
sending an EAP-Success or an EAP-Failure message.
After an inner EAP method generates EAP keying material, EAP-EXT
messages MUST be protected with an AUTH TLV. AUTH TLVs in EAP-EXT
messages MUST be computed using EAP-EXT-KEY generated from EAP keying
material of the latest successful inner method. This means that if
there are multiple inner EAP methods that are sequentially run inside
EAP-EXT, a new EAP-EXT-KEY is generated each time an inner EAP method
in the sequence generates EAP keying material. Any inner EAP method
MUST be capable of generating EAP keying material.
At the end of a successful EAP-EXT run, EAP keying material is
derived from the MSK generated by the last successful inner EAP
method and is exported to the EAP layer. The pseudo random function
used for deriving the EAP keying material and USRKs (Usage Specific
Root Keys) [I-D.salowey-eap-emsk-deriv] MAY be negotiated within EAP-
EXT using PRF TLVs. F-bit is used for indicating the end of EXP-EXT
exchange.
Figure 1 shows an example of EAP-EXT message sequence with a single
inner EAP method and with PRF negotiation. Figure 2 shows an example
of EAP-EXT message sequence with multiple inner EAP methods and
without PRF negotiation.
Ohba, et al. Expires September 4, 2007 [Page 4]
Internet-Draft EAP-EXT Method March 2007
Peer Server
| EAP-Request/Identity (optional) |
|<---------------------------------------------------|
| EAP-Response/Identity (optional) |
|--------------------------------------------------->|
| EAP-Request/EXT{Cap.(R,C),PRF(1,2),Method(Type X),|
| CBM(1,2),CBD,IAL(x)} |
|<---------------------------------------------------|
| EAP-Response/EXT{Cap.(R,C),PRF(1),Method(Type X), |
| CBM(1)} |
|--------------------------------------------------->|
| ... |
| EAP-Request/EXT{F,Cap.(R,C),PRF(1,2),Enc(Peer-ID, |
| Server-ID,Reauth-Key-Lifetime), |
| CBM(1,2),CBD,IAL(x),AUTH} |
|<---------------------------------------------------|
| EAP-Response/EXT{F,Cap.(R,C),PRF(2),CBM(1), |
| AUTH} |
|--------------------------------------------------->|
| EAP-Success |
|<---------------------------------------------------|
F: F-bit is set
Cap.(R,C): R-bit and C-bit of Capabilities field are set
PRF(1,2): PRF TLV carrying PRF numbers 1 and 2
PRF(1): PRF TLV carrying PRF numbers 1
Method(Type X): Method TLV carrying method Type X
Peer-ID: Peer-ID TLV
Server-ID: Server-ID TLV
Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV
AUTH: AUTH TLV
CBM(1,2): Channel-Binding-Mechanism TLV with
channel binding mechanism numbers 1 and 2
CBM(1): Channel-Binding-Mechanism TLV with
channel binding mechanism number 1
CBD: Channel-Binding-Data TLV
IAL(x): Intergrity-Algorithm TLV with algorithm x.
Enc(...): Encrypted TLV
Figure 1: EAP-EXT message sequence with a single inner method and PRF
negotiation
Ohba, et al. Expires September 4, 2007 [Page 5]
Internet-Draft EAP-EXT Method March 2007
Peer Server
| EAP-Request/Identity (optional) |
|<----------------------------------------------------|
| EAP-Response/Identity (optional) |
|---------------------------------------------------->|
| EAP-Request/EXT{Cap.(R,C),Method(Type=X),CBM(1,2), |
| CBD,IAL(x)} |
|<----------------------------------------------------|
| EAP-Response/EXT{Cap.(R,C),Method(Type=X),CBM(2), |
| CBD} |
|---------------------------------------------------->|
| .... |
| EAP-Request/EXT{Cap.(R,C),Method(Type=Y), |
| CBM(1,2),CBD,IAL(x),AUTH} |
|<----------------------------------------------------|
| EAP-Response/EXT{Cap.(R,C),Method(Type=Y), |
| CBM(2),CBD,AUTH} |
|---------------------------------------------------->|
| .... |
| EAP-Request/EXT{F,Cap.(R,C),Method(Type=Y), |
| Enc(Peer-ID, Server-ID, |
| Reauth-Key-Lifetime), CBM(1,2), |
| CBD,IAL(x),AUTH} |
|<----------------------------------------------------|
| EAP-Response/EXT{F,Cap.(R,C),Method(Type=Y), |
| CBM(2),CBD,AUTH} |
|---------------------------------------------------->|
| EAP-Success |
|<----------------------------------------------------|
F: F-bit is set
Cap.(R,C): R-bit and C-bit of Capabilities field are set
Method(Type-X): Method TLV carrying method Type X
Method(Type-Y): Method TLV carrying method Type Y
Peer-ID: Peer-ID TLV
Server-ID: Server-ID TLV
Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV
AUTH: AUTH TLV
CBM(1,2): Channel-Binding-Mechanism TLV with
channel binding mechanism numbers 1 and 2
CBM(2): Channel-Binding-Mechanism TLV with
channel binding mechanism number 2
CBD: Channel-Binding-Data TLV
IAL(x): Intergrity-Algorithm TLV with algorithm x.
Enc(...): Encrypted TLV
Figure 2: EAP-EXT message sequence with multiple inner methods and
without PRF negotiation
Ohba, et al. Expires September 4, 2007 [Page 6]
Internet-Draft EAP-EXT Method March 2007
3. Error Handling
An error may happen for several reasons, e.g., due to failure of
inner EAP method authentication or a malformed, unknown or missing
EAP-EXT TLV. An error may be detected either by the peer or by the
server. An EAP-EXT message that caused an error is referred to as an
erroneous message. EAP-EXT messages with E-bit set are used for
error indications. These messages are referred to as error
indications. An error indication MUST contain an AUTH TLV, and
SHOULD NOT contain other TLVs.
Any erroneous message (including an erroneous error indication)
without a valid AUTH TLV MUST be silently discarded.
For an erroneous Request with a valid AUTH TLV, the peer sends an
error indication Response. For an erroneous Response with a valid
AUTH TLV, the server sends an error indication Request which is
responded by the peer with an error indication Response. The server
returns an EAP-Failure message in response to an error indication
Response with a valid AUTH TLV.
Ohba, et al. Expires September 4, 2007 [Page 7]
Internet-Draft EAP-EXT Method March 2007
4. Keys
EAP-EXT defines the following types of keys.
4.1. MSK and EMSK exported from EAP-EXT
A set of 64-octet MSK and 64-octet EMSK to be exported from EAP-EXT
is derived from MSK_i, the MSK generated by the last successful inner
EAP method, using the KDF defined in [I-D.salowey-eap-emsk-deriv] in
the following way.
(MSK, EMSK) = KDF(MSK_i, "EAP-EXT-EAP-Keying-Material", 128)
4.2. EAP-EXT-AUTH-KEY
EAP-EXT-AUTH-KEY is used for computing AUTH TLVs for integrity
protecting EAP-EXT messages. EAP-EXT-AUTH-KEY is used within EAP-EXT
only and is never exported. The EAP-EXT-AUTH-KEY is derived from the
MSK generated by the last successful inner EAP method (MSK_i), using
the prf+ defined in [RFC4306] in the following way.
EAP-EXT-AUTH-KEY = prf+(MSK_i, "EAP-EXT-Authentication-Key",length);
The default hash algorithm for prf+ is PRF_HMAC_SHA2_256.
The field length will depend upon the integrity algorithm selected by
the EAP Server during the EAP-EXT exchange. When HMAC-SHA-256
[sha256] is used for the integrity algorithm, length=32.
4.3. EAP-EXT-ENC-KEY
EAP-EXT-ENC-KEY is used for ciphering the content of Encrypted TLVs.
It is derived from MSK_i, the MSK generated by the last successful
inner EAP method, using the KDF defined in
[I-D.salowey-eap-emsk-deriv] in the following way.
EAP-EXT-ENC-KEY = prf+(MSK_i, "EAP-EXT-Encryption-Key",length);
The PRF used to generate EAP-EXT-AUTH-KEY is determined by the
integrity algorithm selected by the EAP server during the EAP-EXT
exchange. The default hash algorithm for prf+ is PRF_HMAC_SHA2_256.
The field length will depend upon the negotiated encryption algorithm
negotiated during EAP-EXT exchange. For example, when AES-CBC-128 is
used, length=16.
Ohba, et al. Expires September 4, 2007 [Page 8]
Internet-Draft EAP-EXT Method March 2007
4.4. HOKEY-REAUTH-KEY
HOKEY-REAUTH-KEY is used as the pre-shared key required for the HOKEY
re-authentication mechanism [I-D.vidya-eap-er]. The length of HOKEY-
REAUTH-KEY depends on the HOKEY re-authentication mechanism. The
HOKEY-REAUTH-KEY is derived from the EMSK exported from EAP-EXT using
the USRK derivation algorithm defined in [I-D.salowey-eap-emsk-deriv]
as follows.
HOKEY-REAUTH-KEY = KDF(EMSK, "EAP-EXT-Reauthentication-Key", length)
Ohba, et al. Expires September 4, 2007 [Page 9]
Internet-Draft EAP-EXT Method March 2007
5. Message Format
EAP-EXT uses EAP Type XX (To be assigned by IANA). The message
format including the common EAP fields (i.e., Code, Identifier,
Length and Type) defined in [RFC3748] is shown below.
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 | Version |F|E| Reserved | Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV(s) (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
F
This bit MUST be set to indicate that this is the last EAP-EXT
message from the sender. Otherwise, this bit MUST NOT be set.
E
This bit is set when the message is an error indication. When
this bit is set, F-bit MUST also be set. See Section 3 for
detailed description on error indications.
Version
This 8-bit field indicates the version of the EAP-EXT method.
This document defines Version 1.
Reserved
This 6-bit field is reserved for future extensions. This field
MUST be set to zero by the sender and the recipient MUST ignore
this field.
Capabilities
This field The Capabilities field contains extended EAP
capabilities. The Capabilities field the following format.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R C r r r r r r|
+-+-+-+-+-+-+-+-+
Ohba, et al. Expires September 4, 2007 [Page 10]
Internet-Draft EAP-EXT Method March 2007
Each bit corresponds to a particular capability. The semantics of
each bit is as follows.
R
This bit is set to indicate that the sender supports HOKEY re-
authentication [I-D.vidya-eap-er]. When this bit is set in the
final Request/EXT message (i.e., the Request/EXT with F-bit is
set), the message MUST include a Server-ID TLV and a Peer-ID
TLV and MAY include a Reauth-Key-Lifetime AVP. If this bit is
set in the final Request/EXT and Response/EXT exchange, the
peer and the server MUST generate an HOKEY-REAUTH-KEY. The
Server-ID and Peer-ID contained in the Server-ID and Peer-ID
TLVs and the HOKEY-REAUTH-KEY is used for HOKEY re-
authentication.
C
This bit is set to indicate that the sender supports a channel
binding mechanism for MSK. When this bit is set in a Request/
EXT message, one Channel-Binding-Mechanism TLV MUST also be
included to indicate the channel binding mechanism(s) supported
by the server. If the peer supports and wants to enable one of
the channel binding mechanism(s) supported by the server, it
sends a Response/EXT message with this bit set and one Channel-
Binding-Mechanism TLV containing the selected channel binding
mechanism. If this bit is set in the final Request/EXT and
Response/EXT exchange with successful negotiation of one
channel binding mechanism and the EAP-EXT method completes with
success, the peer and the server MUST enable the negotiated
channel binding mechanism.
Other bits are reserved for future use, and MUST be set to zero by
the sender and MUST be ignored by the recipient.
TLV
Zero, one or more TLVs (Type-Length-Value's). The TLV format of
is as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Ohba, et al. Expires September 4, 2007 [Page 11]
Internet-Draft EAP-EXT Method March 2007
Type
This field indicates the type of this TLV.
Length
This field indicates the length of this TLV in octets,
including the Type and Length fields of the TLV.
Value
This field contains data specific to the TLV Type.
Ohba, et al. Expires September 4, 2007 [Page 12]
Internet-Draft EAP-EXT Method March 2007
6. EAP-EXT TLVs
The following TLVs are defined.
6.1. Method TLV
The Method TLV (Type 1) contains an EAP Method payload starting from
Type field.
6.2. AUTH TLV
The AUTH TLV (Type 2) contains integrity data used for protecting
EAP-EXT messages. The EAP-EXT-KEY is used for computing AUTH TLVs.
The TLV-Value field is computed over the entire EAP message including
this field. Before computing the integrity data, this field MUST be
initialized to all zeros. The length of this field depends on the
integrity algorithm in use. When the integrity check fails, the
message MUST be silently discarded. The default integrity algorithm
is HMAC-SHA-256 [sha256].
6.3. Peer-ID TLV
The Peer-ID TLV (Type 3) contains the identity of the peer used for
HOKEY re-authentication.
6.4. Server-ID TLV
The Server-ID TLV (Type 4) contains the identity of the server used
for HOKEY re-authentication.
6.5. Reauth-Key-Lifetime TLV
The Reauth-Key-Lifetime TLV (Type 5) contains the lifetime of HOKEY-
REAUTH-KEY in seconds.
6.6. PRF TLV
The PRF TLV (Type 6) contains one or more one-octet PRF numbers
defined in [I-D.salowey-eap-emsk-deriv]. When this TLV is carried in
a Request, it indicates the PRF number(s) supported by the server.
When this TLV is carried in a Request/EXT message, the corresponding
Response/EXT message MAY contain this TLV. A PRF TLV in a Response/
EXT message MUST contain exactly one PRF number that is supported and
selected by the peer among the PRF numbers in the Request/EXT
message. If the PRF number is successfully negotiated using the PRF
TLV exchange described above, the negotiated PRF number is used for
KDF to derive EAP keying material to be exported by EAP-EXT and
USRKs. Otherwise, the default PRF specified in
Ohba, et al. Expires September 4, 2007 [Page 13]
Internet-Draft EAP-EXT Method March 2007
[I-D.salowey-eap-emsk-deriv] is used for KDF.
6.7. Channel-Binding-Mechanism TLV
The Channel-Binding-Mechanism TLV (Type 7) contains one or more one-
octet channel binding mechanism numbers. When this TLV is carried in
a Request/EXT message, it indicates the channel binding mechanism
number(s) supported by the server. When this TLV is carried in a
Request/EXT message, the corresponding Response/EXT message MAY
contain this TLV. A Channel-Binding-Mechanism TLV in a Response/EXT
message MUST contain exactly one channel binding mechanism number
that is supported and selected by the peer among the channel binding
mechanism numbers in the Request/EXT message. If the channel binding
mechanism is successfully negotiated using the Channel-Binding-
Mechanism TLV exchange described above, the negotiated channel
binding mechanism is enabled.
The following channel binding mechanism numbers are defined in this
document.
1 [I-D.ohba-eap-channel-binding]
2 [arkko-eap-service-identity-auth]
For channel binding mechanism 1, the default hash algorithm for prf+
is PRF_HMAC_SHA2_256.
For channel binding mechanism 2, an additional Channel-Binding-Data
TLV is carried in Requests and Responses.
6.8. Channel-Binding-Data TLV
The Channel-Binding-Data TLV (Type 8) contains octet string data used
for [arkko-eap-service-identity-auth].
6.9. Encryption-Algorithm TLV
The Encryption-Algorithm TLV allows negotiation of encryption
algorithms used for ciphering Encrypted TLVs. When this TLV is
carried in a Request/EXT, it indicates the cryptographic algorithms
supported by the EAP server. When this TLV is carried in a Request/
EXT message, the corresponding Response/EXT message MAY contain this
TLV. An Encryption-Algorithm TLV in a Response/EXT message MUST
contain exactly one encryption algorithm number supported and
selected by the peer among the options in the Encryption-Algorithm
TLV contained in the Request/EXT message. Note that the EAP Server
MAY force the EAP Peer to use the default encryption algorithm (AES-
CBC-128). In such a case, the EAP peer does not include the
Ohba, et al. Expires September 4, 2007 [Page 14]
Internet-Draft EAP-EXT Method March 2007
Encryption-Algorithm TLV in the Request/EXT message and, in the same
way, the EAP peer does not include it in the Response/EXT either.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Encr-Algorithm TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Algorithms ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It contains one or more one-octet numbers defined in the following
list:
0 Reserved
1 AES-CBC-128 (default)
2 AES-CBC-256
3 3DES
4 IDEA
Note that if the algorithms are not successfully negotiated using the
Encryption-Algorithm TLV, the default encryption algorithm is used
instead.
6.10. Integrity-Algorithm TLV
The EAP-EXT method does not allow integrity algorithm negotiation for
simplicity and in order to avoid bidding-down attacks. However, the
EAP server can select from different integrity algorithms and inform
the EAP peer about this selection through the Integrity-Algorithm
TLV. If the EAP server does not include this TLV the default value
is HMAC-SHA-256.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Intgr-Algorithm TLV | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Intgr.Algorithm|
+-+-+-+-+-+-+-+-+
It contains one or more one-octet numbers defined in the following
list:
Ohba, et al. Expires September 4, 2007 [Page 15]
Internet-Draft EAP-EXT Method March 2007
0 Reserved
1 HMAC-SHA-1
2 HMAC-SHA-224
3 HMAC-SHA-256 (default)
4 HMAC-SHA-384
5 HMAC-SHA-512
6.11. Encrypted TLV
The Encrypted TLV (Type 10) contains one or more plaintext TLVs
encrypted with EAP-EXT-ENC-KEY. The length of this field depends on
the encryption algorithm in use.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Encrypted TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Data... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It contains one or more one-octet numbers defined in the following
list:
Type
(10) Encrypted TLV
Length
4 + IV Length + Encrypted Data Length.
IV
The IV is an Octet string of random bits, most significant bit
first. The length of IV depends on the encryption algorithm in
use. For example, for AES-CBC-128 the IV is 16 bytes (128 bits).
Ohba, et al. Expires September 4, 2007 [Page 16]
Internet-Draft EAP-EXT Method March 2007
Encrypted Data
Encrypted TLV of variable length. The encrypted data consists of
one or more plaintext TLVs ciphered with EAP-EXT-ENC-KEY. Note
that depending on the encryption algorithm and the length of
plaintext data, padding data may be added to the plaintext data
before the ciphering operation.
Ohba, et al. Expires September 4, 2007 [Page 17]
Internet-Draft EAP-EXT Method March 2007
7. Security Considerations
Capability exchange before an inner EAP method exports EAP keying
material is unprotected. Hence, additional protected message
exchange after creation of EAP keying material is mandated to avoid
the capabilities information to be altered by an attacker without
being detected by the peer and the server.
EAP-EXT allows sequencing of multiple EAP methods inside it. It is
known that a compound authentication method that consists of multiple
nested or sequential authentication methods without cryptographically
binding them has a vulnerability to man-in-the-middle attack. EAP-
EXT is able to create the required cryptographically binding by
protecting each inner EAP method together with the outer EAP method
(i.e., EAP-EXT) with a key generated by its precedent successful
inner method in the sequence and finally exporting EAP keying
material derived from that is generated by the last successful inner
EAP method. In order to achieve cryptographic binding, EAP-EXT
requires inner EAP methods to be capable of generating EAP keying
material.
This method exports MSK and EMSK that are computed from MSK of an
inner method. Therefore, the strength of exported MSK and EMSK
altogether is the same as that of the MSK of the inner method.
Ohba, et al. Expires September 4, 2007 [Page 18]
Internet-Draft EAP-EXT Method March 2007
8. IANA Considerations
TBD.
Ohba, et al. Expires September 4, 2007 [Page 19]
Internet-Draft EAP-EXT Method March 2007
9. Acknowledgments
The authors would like to thank Bernard Aboba and Jari Arkko for
their valuable inputs.
Ohba, et al. Expires September 4, 2007 [Page 20]
Internet-Draft EAP-EXT Method March 2007
10. References
10.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.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007.
[I-D.vidya-eap-er]
Narayanan, V. and L. Dondeti, "EAP Extensions for
Efficient Re-authentication", draft-vidya-eap-er-02 (work
in progress), January 2007.
[I-D.ohba-eap-channel-binding]
Ohba, Y., "Channel Binding Mechanism based on Parameter
Binding in Key Derivation",
draft-ohba-eap-channel-binding-02 (work in progress),
December 2006.
[I-D.salowey-eap-emsk-deriv]
Salowey, J., "Specification for the Derivation of Usage
Specific Root Keys (USRK) from an Extended Master Session
Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in
progress), June 2006.
[sha256] National Institute of Standards and Technology, "Secure
Hash Standard", August 2002.
10.2. Informative References
[arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", http://tools.ietf.org/html/
draft-arkko-eap-service-identity-auth-04, October 2005.
Ohba, et al. Expires September 4, 2007 [Page 21]
Internet-Draft EAP-EXT Method March 2007
Authors' Addresses
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com
Subir Das
Telcordia
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 2483
Email: subir@research.telcordia.com
Rafael Marin Lopez
Faculty of Computer Science
University of Murcia
Murcia 30100
Spain
Phone: +34968398501
Email: rafa@dif.um.es
Ohba, et al. Expires September 4, 2007 [Page 22]
Internet-Draft EAP-EXT Method March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ohba, et al. Expires September 4, 2007 [Page 23]