Internet DRAFT - draft-vanderveen-eap-make
draft-vanderveen-eap-make
M.Vanderveen
Internet Draft H.Soliman
Expires: February 2006 Flarion Technologies
August 2005
Extensible Authentication Protocol Method for
Mutual Authentication and Key Establishment (EAP-MAKE)
<draft-vanderveen-eap-make-00.txt>
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 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
Abstract
This document specifies an Extensible Authentication Protocol (EAP)
mechanism for mutual authentication and key establishment (MAKE)
based on static pre-shared secret data.
Table of Contents
1. Introduction.....................................................3
2. Terminology......................................................3
3. Protocol Description.............................................3
3.1. Overview and Motivation of EAP-MAKE.........................3
3.2. Protocol Operation..........................................4
3.2.1. Successful Exchange....................................4
Vanderveen, et al. [Page 1]
INTERNET-DRAFT EAP-MAKE August 2005
3.2.2. Authentication Failure.................................7
3.2.3. Identity Management (Informative)......................9
3.2.4. Obtaining Peer Identity...............................10
3.2.5. Key Hierarchy.........................................12
3.2.6. Key Derivation........................................13
3.2.7. Ciphersuite Negotiation...............................14
3.2.8. Message Integrity and Encryption......................15
3.2.9. Retry Behavior........................................18
3.2.10. Fragmentation........................................18
3.2.11. Error Cases..........................................19
3.3. Message Formats............................................19
3.3.1. Message Format Summary................................19
3.3.2. Expanded Types........................................20
3.3.3. Attribute Format......................................21
3.3.4. Use of AT_ENCR_DATA Attribute.........................22
3.3.5. EAP.Request/MAKE/Challenge Format.....................22
3.3.6. EAP.Response/MAKE/Challenge Format....................24
3.3.7. EAP.Request/MAKE/Confirm Format.......................26
3.3.8. EAP.Response/MAKE/Confirm Format......................28
3.3.9. EAP.Response/MAKE/Auth-Reject Format..................29
3.3.10. EAP.Request/MAKE/Identity Format.....................30
3.3.11. EAP.Response/MAKE/Identity Format....................31
3.3.12. Other EAP Messages Format............................32
4. IANA Considerations.............................................33
5. Security Considerations.........................................33
5.1. Denial-of-service Attacks..................................33
5.2. Root Secret Considerations.................................34
5.3. Mutual Authentication......................................34
5.4. Integrity Protection.......................................34
5.5. Replay Protection..........................................35
5.6. Confidentiality............................................35
5.7. Key Derivation, Strength...................................35
5.8. Dictionary Attacks.........................................36
5.9. Man-in-the-middle Attacks..................................36
5.10. Result Indication Protection..............................36
5.11. Cryptographic Separation of Keys..........................36
5.12. Session Independence......................................36
5.13. Identity Protection.......................................37
5.14. Channel Binding...........................................37
5.15. Negotiation Attacks.......................................37
5.16. Random Number Generation..................................38
6. Security Claims.................................................38
7. Acknowledgements................................................39
8. References......................................................39
8.1. Normative References.......................................39
8.2. Informative References.....................................40
Vanderveen, et. al [Page 2]
INTERNET-DRAFT EAP-MAKE August 2005
1. Introduction
The Extensible Authentication Protocol (EAP), described in [EAP],
provides a standard mechanism for support of multiple authentication
methods. EAP is also used within IEEE 802 networks through the IEEE
802.11i [IEEE802.11i] framework.
EAP supports several authentication schemes, including smart cards,
Kerberos, Public Key, One Time Passwords, TLS, and others. This
document defines a new authentication scheme, called the EAP-MAKE.
EAP-MAKE supports mutual authentication and session key derivation,
based on a static pre-shared key.
2. Terminology
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", "MUST", "MUST NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 [KEYWORDS].
In addition to the terms used in [EAP], this document frequently uses
the following terms and abbreviations:
MIC
Message Integrity Check
MMS
MAKE Master Secret
NAI
Network Access Identifier
3. Protocol Description
3.1. Overview and Motivation of EAP-MAKE
The EAP-MAKE authentication protocol is a native EAP authentication
method. That is, a stand-alone version of EAP-MAKE outside of EAP is
not defined. EAP-MAKE is designed to enable mutual authentication,
based on pre-shared keys and well-known public cryptographic
algorithms. This method is ideal for subscription-based public access
networks, e.g. cellular networks.
Regarding the name of this method, its abbreviation is the same as a
method that was published in an Internet-Draft in 2001. The draft has
not been renewed since then. The name EAP-MAKE was chosen in 2002 for
a method implemented for commercial deployment at Flarion
Technologies, without awareness of the aforementioned draft.
Vanderveen, et. al [Page 3]
INTERNET-DRAFT EAP-MAKE August 2005
EAP-MAKE assumes a long-term or pre-shared secret known only to the
Peer and the Server. This pre-shared secret is called the Root
Secret. The Root Secret consists of a 16-byte part Root-Secret-A, and
16-byte part Root-Secret-B. The Root-Secret-A secret is reserved for
use local to the EAP-MAKE method, i.e. to mutually authenticate the
EAP Peer and EAP Server. The Root-Secret-B secret is used to derive
other quantities such the Master Session Key (MSK) and Extended
Master Session Key (EMSK). Root-Secret-B and Root-Secret-A MUST be
cryptographically separate.
When a Backend Authentication Server is used, the Server typically
communicates with the Server using an AAA protocol. The AAA
communications are outside the scope of this draft.
Some of the advantages of EAP-MAKE consist of:
o based on well-established Bellare-Rogaway mutual authentication
protocol.
o supports key derivation for local EAP method use and for export
to other third parties to use them independently of EAP.
o employs only two request/response exchanges.
o relies on the IEEE 802.11i function for key derivation and
message integrity. This way a device implementing a lower-layer
secure association protocol compliant with IEEE 802.11i standard will
not need additional cryptographic code.
o encryption algorithm is securely negotiated (with no extra
messages) but encryption use is optional.
o keys used for authentication and those used for encryption are
cryptographically separate.
o user identity anonymity can be optionally supported.
o no synchronization (e.g. of counters) needed between server and
peer.
o no one-time key pre-processing step.
3.2. Protocol Operation
EAP-MAKE uses four messages consisting of two EAP request/response
exchanges. The EAP.Success and EAP.Failure messages shown in the
figures are not part of the EAP-MAKE method. As a convention, method
attributes are named AT_XX, where XX is the name of the parameter the
attribute value is set to.
3.2.1. Successful Exchange
A successful EAP-MAKE authentication exchange is depicted in
Figure 1. The following steps take place:
Vanderveen, et. al [Page 4]
INTERNET-DRAFT EAP-MAKE August 2005
Peer Server
| |
| EAP.Request/MAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/MAKE/Challenge |
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| EAP.Request/MAKE/Confirm |
| (AT_SPI_S, AT_ENCR_DATA, AT_MIC_S)|
3 |<---------------------------------------------------------|
| |
| EAP.Response/MAKE/Confirm |
| (AT_MIC_P) |
4 |--------------------------------------------------------->|
| |
| |
| EAP-Success |
5 |<---------------------------------------------------------|
| |
Figure 1. EAP-MAKE authentication procedure (with ciphersuite
negotiation).
1. The EAP server sends the first message of the EAP-MAKE
exchange. This message is an EAP.Request message of type MAKE
and subtype Challenge. The EAP.Request/MAKE/Challenge message
contains the attributes: AT_RAND_S, whose value is a nonce
freshly generated by the Server; and AT_SERVERID, which carries
an identifier of the Server (a fully-qualified domain name,
such as the realm of the user NAI [NAI]). The AT_SERVERID
attribute is OPTIONAL but SHOULD be included in this message.
The purpose of the AT_SERVERID is to aid the Peer in selecting
the correct security association (i.e., Root-Secret, PEERID and
SERVERID) to use during this EAP phase.
2. The Peer responds by sending an EAP.Response message of type
MAKE and subtype Challenge. The EAP.Response/MAKE/Challenge
message contains the attributes: AT_RAND_P, which carries a
nonce freshly generated by the Peer; AT_PEERID, which carries a
Peer identifier; AT_SPI_P, which carries a list of one or more
ciphersuites supported by the Peer; and AT_MIC_P, containing a
message integrity check. The AT_SPI_P and AT_PEERID attributes
are OPTIONAL. The AT_PEERID attribute SHOULD be included, in
order to cover the case of multi-homed hosts. A supported
ciphersuite is represented by a value local to the EAP-MAKE
method, or "Security Parameter Index", see section 3.2.8.3. The
Peer uses both nonces, along with the Root-Secret-A key, to
derive a MAKE Master Secret (MMS) and Temporary EAP Keys
Vanderveen, et. al [Page 5]
INTERNET-DRAFT EAP-MAKE August 2005
(TEKs), which also include the TEK-Auth and TEK-Cipher keys.
The MIC_P value is computed based on both nonces RAND_S and
RAND_P and the entire EAP packet, using the key TEK-Auth, see
section 3.2.6.
3. Upon receipt of the EAP.Response/MAKE/Challenge message, the
Server uses both nonces RAND_S and RAND_P, along with the Root-
Secret-A key, to compute the MMS and TEK in exactly the same
way the Peer did. Following that, the Server computes the
Peer's signature MIC_P in exactly the same way the Peer did.
The Server then compares the computed MIC_P with the MIC_P it
received from the Peer. If they match, the Server considers the
Peer authenticated. If encryption is needed, the Server selects
the strongest ciphersuite from the Peer's ciphersuite list
SPI_P, or a suitable ciphersuite if the Peer did not include
the AT_SPI_P attribute. The Server sends an EAP. Request
message of type MAKE and subtype Confirm, containing the
attributes: AT_SPI_S, carrying the ciphersuite chosen by the
Server; AT_ENCR_DATA, containing encrypted data; and AT_MIC_S,
carrying a message integrity check. The AT_SPI_S and
AT_ENCR_DATA are OPTIONAL attributes, included if
confidentiality and/or user identity anonymity is desired.
Other OPTIONAL attributes that MAY be included are
AT_NEXT_TMPID, AT_MSK_LIFE. As before, the MIC_S value is
computed using both nonces RAND_S and RAND_P and the entire EAP
packet, using the key TEK-Auth.
4. If the Peer receives the EAP.Request/MAKE/Confirm message
indicating successful authentication by the Server, the Peer
computes the MIC_S in the same manner as the Server did. The
Peer then compares the received MIC_S with the MIC_S it
computed. If they match, the Peer considers the Server
authenticated, and it sends an EAP.Response message of type
MAKE and subtype Confirm, with the attribute AT_MIC_P
containing a message integrity check, computed in the same
manner as before.
5. After a successful EAP-MAKE exchange, the Server
concludes the EAP conversation by sending an EAP.Success
message to the Peer.
All EAP-MAKE messages contain a Session ID, which is chosen by the
Server and sent in the first message, and replicated in subsequent
messages until an EAP.Success or EAP.Failure is sent. Upon receipt of
an EAP-MAKE message, both Peer and Server MUST check the format of
the message to ensure it is both well-formed and contains a valid
Session ID.
Note that the Session ID is introduced mainly for replay protection
purposes, as it uniquely identifies a session between a Peer and the
Vanderveen, et. al [Page 6]
INTERNET-DRAFT EAP-MAKE August 2005
Server. In most cases, there is a one-to-one relationship between the
Session ID and the Peer/Server pair.
The parameters used by the EAP-MAKE method are summarized in the
table below:
Name Length(bytes) Description
---------+---------------+-------------
RAND_P 16 Peer nonce
RAND_S 16 Server nonce
MIC_P 16 Peer MIC
MIC_S 16 Server MIC
SPI_P variable Peer ciphersuite preference(s)
SPI_S variable Server chosen ciphersuite
PEERID variable Peer identifier
SERVERID variable Server identifier (FQDN)
3.2.2. Authentication Failure
If the Authenticator receives an EAP Failure message from the Server,
the Server MUST terminate the connection with the Peer immediately.
The Server considers the Peer to have failed authentication if
either of the two received signatures MIC_P does not match the
computed signature MIC_P.
The Server SHOULD deny authorization for a Peer that does not
advertise any of the ciphersuites that are considered acceptable
(e.g. by local system policy), and send an EAP.Failure message.
In case of authentication failure, the Server MUST send an
EAP.Failure message to the Peer as in Figure 2. The following steps
take place:
Peer Server
| |
| EAP.Request/MAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/MAKE/Challenge |
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| +-------------------------------------------+
| | Server finds MIC_P invalid. |
| +-------------------------------------------+
| |
| EAP-Failure |
3 |<---------------------------------------------------------|
Vanderveen, et. al [Page 7]
INTERNET-DRAFT EAP-MAKE August 2005
| |
Figure 2. EAP-MAKE authentication procedure, Peer fails
authentication.
1. As in step 1 of Figure 1.
2. As in step 2 of Figure 2.
3. Upon receipt of the EAP.Response/MAKE/Challenge message, the
Server uses both nonces RAND_S and RAND_P, along with the Root-
Secret-A key, to compute the MMS and TEK in exactly the same way
the Peer did. Following that, the Server computes the Peer's
signature MIC_P in exactly the same way the Peer did. The Server
then compares the computed MIC_P with the MIC_P it received from
the Peer. Since they do not match, the Server considers the Peer
to have failed authentication, and sends an EAP.Failure message
back to the Peer.
If the AT_SPI_S attribute does not contain one of the SPI values that
the Peer listed in the previous message, or if the Peer did not
include an AT_SPI_P attribute and yet it does not accept the
ciphersuite the Server has chosen, then the Peer SHOULD silently
discard this message. Alternatively, the Peer MAY send a MAKE/Auth-
Reject message back to the Server; in response to this message, the
Server MUST send an EAP.Failure message to the Peer.
The AT_SPI_S attribute MUST be included if encryption is to be used.
The Server knows whether encryption is to be used or not, as it is
usually the Server that needs to protect some data intended for the
Peer (e.g. temporary ID, group keys, etc). If the Peer receives an
AT_SPI_S attribute and yet there is no AT_ENCR_DATA attribute, the
Peer SHOULD process the message and skip the AT_SPI_S attribute.
The Peer considers the Server to have failed authentication if
the received and the computed MIC_S values not to match. In this
case, the Peer MUST send to the Server an EAP.Response message of
type MAKE and subtype Auth-Reject, indicating an authentication
failure. To this message the Server MUST send an EAP.Failure message
to the Peer as in Figure 3. The following steps take place:
Peer Server
| |
| EAP.Request/MAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/MAKE/Challenge |
Vanderveen, et. al [Page 8]
INTERNET-DRAFT EAP-MAKE August 2005
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| EAP.Request/MAKE/Confirm |
| (AT_SPI_S, AT_ENCR_DATA, AT_MIC_S)|
3 |<---------------------------------------------------------|
| |
+-----------------------------------------------+ |
| Peer finds MIC_S invalid. | |
+-----------------------------------------------+ |
| |
| EAP.Response/MAKE/Auth-Reject |
4 |--------------------------------------------------------->|
| |
| EAP-Failure |
5 |<---------------------------------------------------------|
| |
Figure 3. EAP-MAKE authentication procedure, Server fails
authentication.
1. As in step 1 of Figure 1.
2. As in step 2 of Figure 1.
3. As in step 3 of Figure 1.
4. The Peer receives a EAP.Request/MAKE/Confirm message indicating
successful authentication by the Server. The Peer computes the
MIC_S in the same manner as the Server did. The Peer then compares
the received MIC_S with the MIC_S it computed. Since they do not
match, the Peer considers the Server to have failed
authentication. In this case the Peer responds with an
EAP.Response message of type MAKE and subtype Auth-Reject,
indicating authentication failure.
5. Upon receipt of a EAP.Response/MAKE/Auth-Reject message, the
Server sends an EAP.Failure message back to the Peer.
3.2.3. Identity Management (Informative)
It may be advisable to assign a temporary identifier (TempID) to a
Peer when user anonymity is desired. The TempID is delivered to the
Peer in the EAP.Request/MAKE/Confirm message. The TempID follows the
format any NAI [NAI] and is generated by the EAP Server that engages
in the EAP-MAKE authentication task with the Peer. EAP servers SHOULD
be configurable with TempID spaces that can be distinguished from the
permanent identity space. For instance, a specific realm could be
assigned for TempIDs (e.g. tmp.example.biz).
A TempID is not assigned an explicit lifetime. The TempID is valid
until the Server requests the permanent identifier, or the Peer
triggers the start of a new EAP session by sending in its permanent
identifier. A Peer MUST be able to trigger an EAP session at any time
using its permanent identifier. A new TempID assigned during a
Vanderveen, et. al [Page 9]
INTERNET-DRAFT EAP-MAKE August 2005
successful EAP session MUST replace the existing TempID for future
transactions between the Peer and the Server.
Note that the delivery of a TempID does not imply that the Server
considers the Peer authenticated; the Server still has to check the
MIC in the EAP.Response/MAKE/Confirm message. In case the EAP phase
ends with an EAP.Failure message, then the Server and the Peer MUST
consider the TempID that was just delivered as invalid. Hence, the
Peer MUST NOT use this TempID next time it tries to authenticate with
the Server.
3.2.4. Obtaining Peer Identity
The types of identities that a Peer may possess are permanent and
temporary identities, referred to as PermID and TempID, respectively.
A PermID can be an NAI associated with the Root Secret, and is long-
lived. A TempID is an identifier generated through the EAP method and
that the Peer can use to identify itself during subsequent EAP
sessions with the Server. The purpose of the TempID is to allow for
user anonymity support. The use of TempIDs is optional in the EAP-
MAKE method.
The Server MAY request the Peer ID via the EAP.Request/MAKE/Identity
message, as shown in Figure 4. This case may happen if, for example,
the Server wishes to initiate an EAP-MAKE session for a Peer it does
not have a subscriber identifier for. The following steps take place:
Peer Server
| |
| +---------------------------------+
| | Server wishes to initiate |
| | an EAP-MAKE session |
| | |
| +---------------------------------+
| |
| EAP.Request/MAKE/Identity |
| (AT_ANY_ID_REQ, AT_SERVER_ID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/MAKE/Identity |
| (AT_PEERID) |
2 |--------------------------------------------------------->|
| |
+--------------------------------------------------------------+
| If identity found, normal EAP-MAKE authentication follows. |
+--------------------------------------------------------------+
Figure 4: Server requests Peer identity.
Vanderveen, et. al [Page 10]
INTERNET-DRAFT EAP-MAKE August 2005
1. The Server sends an EAP.Request message of type MAKE and subtype
Identity, with the attribute AT_ANY_ID_REQ, indicating a request
for any Peer identifier.
2. The Peer constructs an EAP.Response message of type MAKE and
subtype Identity, with the attribute AT_PEER_ID containing any
Peer identifier (PermID or TempID).
If the Server cannot find the Peer identity reported in the
EAP.Response/MAKE/Identity message, or it does not recognize the
format of the Peer identifier, the Server MAY send an EAP.Failure
message to the Peer.
If the Server is unable to look up a Peer by its TempID, or if policy
dictates that the Peer should now use its permanent id, then the
Server may specifically ask for the permanent identifier, as in
Figure 5. The following steps occur:
Peer Server
| |
| +---------------------------------+
1 | | Server obtains TempID but |
| | requires PermID |
| +---------------------------------+
| |
| EAP.Request/MAKE/Identity |
| (AT_PERM_ID_REQ, AT_SERVERID) |
2 |<---------------------------------------------------------|
| |
| EAP.Response/MAKE/Identity |
| (AT_PEERID) |
3 |--------------------------------------------------------->|
| |
| +---------------------------------+
| | Server finds and uses |
| | Peer PermID to start a |
| | EAP-MAKE authentication phase |
| +---------------------------------+
|
+---------------------------------------------------------------+
| Normal EAP-MAKE authentication follows. |
+---------------------------------------------------------------+
Figure 5. Server is given a TempID as Peer Identity. Server requires
a PermID.
1. The Peer (or the Authenticator on behalf of the Peer) sends an
EAP.Request message of type Identity and includes the TempID.
2. The Server requires a PermID instead, so it sends an
EAP.Request message of type MAKE and subtype Identity with
attributes AT_PERM_ID_REQ and AT_SERVERID.
Vanderveen, et. al [Page 11]
INTERNET-DRAFT EAP-MAKE August 2005
3. The Peer sends an EAP.Response message of type MAKE and subtype
Identity containing the attribute AT_PEERID carrying the Peer
PermID.
3.2.5. Key Hierarchy
EAP-MAKE uses a three-level key hierarchy.
Level 1 contains the pre-shared secret called Root Secret. This is a
32-byte high-entropy string partitioned into the Root-Secret-A part
(16 bytes) and the Root-Secret-B part (16 bytes).
Level 2 contains the key derivation key called the MAKE Master Secret
(MMS). MMS-A is derived from the Root-Secret-A key and the Peer and
Server nonces using the EAP-MAKE Key-Derivation Function (KDF), and
similarly for MMS-B. The MMS is known only to the Peer and Server,
and is not made known to other parties.
Level 3 contains session keys, such as Transient EAP Keys (TEK),
Master Session Key (MSK) and Extended MSK (EMSK). TEKs are keys for
use local to the EAP method only. They are derived from the MMS-A and
the nonces using the EAP-MAKE KDF. They are partitioned into a 16-
byte TEK-Auth, used to compute the MICs, and a 16-byte TEK-Cipher,
used to encrypt selected attributes. Since the MMS is fresh, so are
the derived TEKs.
+--------------------+ +--------------------+
| Root-Secret-A | | Root-Secret-B |
| (pre-shared secret)| | (pre-shared secret)|
+--------------------+ +--------------------+
| |
V V
+-------------------+ +--------------------+
| MAKE Master Secret|<---RAND_S------------->| MAKE Master Secret |
| (MMS-A) | | | (MMS-B) |
| |<-------]---RAND_P----->| |
+-------------------+ | | +--------------------+
| | | |
V | | V
+--------------------+ | | +--------------------+
| Transient EAP Keys |<------+-----+-------->| Session Keys: |
| TEK-Auth,TEK-Cipher|<------------+-------->| MSK, EMSK |
+--------------------+ +--------------------+
Figure 6. Key hierarchy for the EAP-MAKE method.
On another branch of level 3 of the key hierarchy are the MSK and
EMSK, each mandated to be 64 bytes long. They are derived from the
MMS-B and the nonces using the EAP-MAKE KDF. Again, since the MMS is
fresh, so are the derived MSK/EMSK. The MSK is meant to be exported
and relayed to other parties. The EMSK is reserved for future use,
Vanderveen, et. al [Page 12]
INTERNET-DRAFT EAP-MAKE August 2005
such as derivation of application-specific keys, and is not shared
with other parties. The AAA-Key introduced in [EAP] is derived from
the MSK by the EAP AAA server. As in many existing methods, the AAA-
Key and MSK are equivalent and thus are used interchangeably. That
is, EAP-MAKE defines the AAA-Key as follows:
AAA-Key = MSK
The EAP-MAKE key material is summarized in the table below.
Key Size Scope Lifetime Use
(bytes)
===================================================================
Root-Secret-A 16 Peer, Server device Derive TEK
--------------------------------------------------------------------
Root-Secret-B 16 Peer, Server device Derive MSK, EMSK
--------------------------------------------------------------------
TEK-Auth 16 Peer, Server MSK Life Sign MICs
--------------------------------------------------------------------
TEK-Cipher 16 Peer, Server MSK Life Encrypt attribute
--------------------------------------------------------------------
MSK/AAA-Key 64 Peer, Server, MSK Life Derive keys for
Authenticator Lower-layer use
--------------------------------------------------------------------
EMSK 64 Peer, Server MSK Life Reserved
--------------------------------------------------------------------
A key name format is not provided in this version.
Since this version of EAP-MAKE does not support fast re-
authentication, the lifetime of the TEKs is to extend only until the
next EAP mutual authentication. The MSK lifetime dictates when the
next mutual authentication should take place. The Server MAY convey
the MSK lifetime to the Peer in the AT_MSK_LIFE attribute. Note that
EAP-MAKE does not support key lifetime negotiation.
3.2.6. Key Derivation
3.2.6.1. Key-Derivation Function
For the rest of this document, KDF-X denotes the EAP-MAKE Key-
Derivation Function whose output is X bytes. This function is the
same as the pseudo-random function of [IEEE802.11i].
The function takes three strings of bytes of arbitrary lengths: a
Key, a Label, and a Msg, and outputs a string of bytes of length X
Out as follows:
Out = KDF-X (Key, Label, Msg)
Vanderveen, et. al [Page 13]
INTERNET-DRAFT EAP-MAKE August 2005
The KDF is a keyed hash function with key "Key" and operating on
input "Label | Msg". The convention followed herein is that
concatenation is denoted by |, and [x...y] denotes bytes x through y.
The label is an ASCII character string. It is included in the exact
form it is given without a length byte or trailing null character.
Below, "Length" denotes a single unsigned octet with values between 0
and 255. The following functions are defined (see [HMAC], [SHA1]):
H-SHA1(Key, Label, Msg, Length) := HMAC-SHA1(Key, Label|Msg|Length)
KDF-16(Key, Label, Msg) := KDF(Key, Label, Msg, 16)
KDF-32(Key, Label, Msg) := KDF(Key, Label, Msg, 32)
KDF-128(Key, Label, Msg) := KDF(Key, Label, Msg, 128)
KDF(Key, Label, Msg, Length)
R := [] ;; null string
for i := 1 to (Length+19)/20 do
R := R | H-SHA1(Key, Label, Msg, i)
return R[0...(Length-1)]
3.2.6.2. Transient EAP Keys Derivation
The Peer and Server derive the MMS and then the TEK as follows:
MMS-A = KDF-16 (Root-Secret-A, "MAKE Master Secret A", RAND_P|RAND_S)
TEK = KDF-32 (MMS-A, "Transient EAP Key", RAND_S | RAND_P)
TEK-Auth = TEK[0...15]
TEK-Cipher = TEK[16...31]
3.2.6.3. Extended/Master Session Key Derivation
The Peer and the Server derive the MSK/EMSK, as follows:
MMS-B = KDF-16 (Root-Secret-B, "MAKE Master Secret B", RAND_P|RAND_S)
Session-Key-Block=KDF-128(MMS-B, "Master Session Key", RAND_S|RAND_P)
MSK = Session-Key-Block[0...63]
EMSK = Session-Key-Block[64...127]
The derivation above affords the required cryptographic separation
between the MSK and EMSK. That is, knowledge of the EMSK does not
immediately lead to knowledge of the MSK, nor does knowledge of the
MSK immediately lead to knowledge of the EMSK.
3.2.7. Ciphersuite Negotiation
A ciphersuite is identified by a numeric value called the Security
Parameter Index (SPI). The SPI is used here in the EAP-MAKE method in
order to negotiate a ciphersuite between the Peer and the Server for
EAP message protection only. Obviously, this ciphersuite can only be
used late in the EAP conversation, after it has been agreed upon by
both the Peer and the Server.
Vanderveen, et. al [Page 14]
INTERNET-DRAFT EAP-MAKE August 2005
The EAP method may or may not need to use this ciphersuite, since
attribute encryption is optional. For example, if the temporary
identifier needs to be delivered to the Peer and needs to be
encrypted, then the negotiated ciphersuite will be used for this
task. If there are no attributes that need encryption as they are
passed to the Peer, then this ciphersuite is never used.
As with most other methods employing ciphersuite negotiation, the
following exchange is employed: the Peer sends an ordered list of one
or more supported ciphersuites, starting with the most preferred one,
in a field SPI_P. The Server then sends back the one ciphersuite
chosen in a field SPI_S. The Server SHOULD choose the strongest
ciphersuite supported by both of them.
Protected ciphersuite negotiation is achieved via the MAKE/Challenge
and MAKE/Confirm messages. In the EAP.Response/MAKE/Challenge the
Peer sends a list of supported ciphersuites, SPI_P, and signs that
with a MIC. In the EAP.Request/MAKE/Confirm, the Server sends one
selected ciphersuite, SPI_S, and signs that with a MIC. Finally, the
Peer confirms the selected ciphersuite and readiness to use it in a
signed EAP.Response/MAKE/Confirm message. The negotiation is secure
because of the Message Integrity Checks that cover the entire EAP
message.
3.2.8. Message Integrity and Encryption
This section specifies the EAP/MAKE attributes used for message
integrity and attribute encryption: AT_MIC_S, AT_MIC_P, AT_IV,
AT_ENCR_DATA and AT_PADDING. Only the AT_MIC_S and AT_MIC_P are
mandatory to use during the EAP-MAKE exchange.
Because the TEKs necessary for protection of the attributes and for
message authentication are derived using the nonces RAND_S and
RAND_P, the AT_MIC_S and AT_MIC_P attributes can only be used in the
EAP.Response/MAKE/Challenge message and any messages sent thereafter.
3.2.8.1. The AT_MIC_S and AT_MIC_P Attributes
The AT_MIC_S and AT_MIC_P attributes are used for EAP-MAKE message
integrity. The AT_MIC_S attribute MUST be included in all EAP-MAKE
packets that the Server sends whenever key material (TEK) has been
derived. That is, the AT_MIC_S attribute MUST be included in the
EAP.Request/MAKE/Confirm message. The AT_MIC_S MUST NOT be included
in EAP.Request/MAKE/Challenge messages, or EAP.Request/MAKE/Identity
messages.
The AT_MIC_P attribute MUST be included in all EAP-MAKE packets the
Peer sends whenever key material (TEK) has been derived. That is, the
AT_MIC_P attribute MUST be included in the
EAP.Response/MAKE/Challenge and EAP.Response/MAKE/Confirm messages.
Vanderveen, et. al [Page 15]
INTERNET-DRAFT EAP-MAKE August 2005
The AT_MIC_P attribute MUST NOT be included in the
EAP.Response/MAKE/Auth-Reject message since the Peer has not
confirmed that it has the same TEK as the Server.
Messages that do not meet the conditions specified above MUST be
silently discarded upon reception.
The value field of the AT_MIC_S and AT_MIC_P attributes contain a
message integrity check (MIC). The MIC is calculated over the entire
EAP packet, prepended with the Server nonce and identifier and the
Peer nonce and identifier. The value field of the MIC attribute is
set to zero when calculating the MIC. Including the Server and Peer
nonces and identifiers aids in detecting replay and man-in-the-middle
attacks.
The existence of two MIC attributes in EAP-MAKE instead of one is an
implementation choice, since the way the MICs are computed is
different for the Peer and the Server.
The Peer computes its signature MIC_P as follows:
MIC_P = KDF-16 (TEK-Auth, "Peer MIC", RAND_S | RAND_P |
PEERID | SERVERID | <EAP-packet>),
while the Server computes its signature MIC_S as
MIC_S = KDF-16 (TEK-Auth, "Server MIC", RAND_P |RAND_S |
SERVERID | PEERID | <EAP-packet>).
Here <EAP-packet> denotes the entire EAP packet, used as a string of
bytes, with the MIC value field set to zero. The PEERID and SERVERID
respectively are the ones carried in the corresponding attributes in
the MAKE/Challenge messages. If the AT_PEERID and AT_SERVERID were
not included in the MAKE/Challenge messages, and this message was not
preceded by a MAKE/Identity exchange, it is assumed that the Server
and the Peer have agreed on their identities as part of the "security
association" established via out-of-band means.
The Server and Peer identity are included in the computation of the
signed responses so that the Peer and Server can verify each other's
identities, and the possession of a common secret, the TEK-Auth.
However, since the AT_SERVERID is not explicitly signed with a MIC by
the Server, EAP-MAKE does not claim channel binding.
3.2.8.2. The AT_IV, AT_ENCR_DATA and AT_PADDING Attributes
The AT_IV and AT_ENCR_DATA attributes can be used to transmit
encrypted information between the Server and the Peer. The value
field of AT_IV contains an initialization vector (IV) if one is
required by the encryption algorithm used. The AT_IV attribute is not
mandatory to be included whenever the AT_ENCR_DATA attribute is.
Vanderveen, et. al [Page 16]
INTERNET-DRAFT EAP-MAKE August 2005
However, the AT_IV attribute MUST NOT be included unless the
AT_ENCR_DATA is included. Messages that do not meet this condition
MUST be silently discarded.
Attributes can be encrypted only after a ciphersuite has been agreed
on, i.e. in any message starting with the Server's
EAP.Request/MAKE/Confirm message. The attributes MUST be encrypted
using algorithms corresponding to the SPI value specified by the
AT_SPI_S attribute. The attributes MUST be encrypted using the TEK-
Cipher key, whose derivation is specified in Section 3.2.6.2.
If an IV is required by the encryption algorithm, then the sender of
the AT_IV attribute MUST NOT reuse the IV value from previous EAP-
MAKE packets. The sender MUST choose a new value for each AT_IV
attribute. The sender SHOULD use a good random number generator to
generate the initialization vector (see [RFC1750] for guidelines).
The value field of the AT_ENCR_DATA attribute consists of bytes
encrypted using the ciphersuite specified in the AT_SPI_S attribute.
The encryption key is the TEK-Cipher and the plaintext consists of
one or more concatenated EAP-MAKE attributes.
The AT_PADDING attribute MUST be included in any EAP-MAKE message
that does not align on a 32-bit boundary. It does not have to be the
last attribute. The AT_PADDING is also used to achieve alignment if
one is required by the encryption algorithm.
The default encryption algorithm, as described in Section 3.2.8.3,
requires the length of the plaintext to be a multiple of 16 bytes.
The sender MAY need to include the AT_PADDING attribute as the last
attribute within the value field of the AT_ENCR_DATA attribute. The
length of the padding is chosen so that the length of the value field
of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes. The
AT_PADDING attribute SHOULD NOT be included if the total length of
other attributes present within the AT_ENCR_DATA attribute is a
multiple of 16 bytes. The length of the AT_PADDING attribute includes
the Attribute Type and Attribute Length fields. The actual pad bytes
in the value field are set to zero (0x00) on sending. The recipient
of the message MUST verify that the pad bytes are zero after
decryption and MUST silently discard the message otherwise.
The MIC computed on the entire EAP message can be used to obviate the
need for special integrity protection or message authentication of
the encrypted attributes.
An example of the AT_ENCR_DATA attribute is shown in Section 3.3.4.
3.2.8.3. Security Parameter Index (SPI) Considerations
An SPI value is a variable-length string identifying at least an
encryption algorithm and possibly a "security association". EAP-MAKE
Vanderveen, et. al [Page 17]
INTERNET-DRAFT EAP-MAKE August 2005
does not mandate the format of the SPI; it only mandates that the
default encryption algorithm be supported if encryption is supported.
That is, if an implementation compliant with this draft supports
encryption, then it MUST support the AES-CBC cipher.
The default encryption algorithm AES-CBC involves the AES block
cipher [AES] in the Cipher-Block-Chaining (CBC) mode of operation
[CBC].
The Peer in the EAP-MAKE method can send up to four SPI values in its
SPI_P field. Because the length of the AT_SPI_P and AT_SPI_S
attributes must each be a multiple of 2 bytes, the sender pads the
value field with zero bytes when necessary (the AT_PADDING attribute
is not used here). For example, the value field of the AT_SPI_S
contains one byte with the chosen SPI, followed by one byte of zeros.
3.2.9. Retry Behavior
As with other EAP methods, the Server is in charge of retry behavior.
That is, if the Server does not receive a reply from the Peer, then
the Server MUST resend the EAP.Request for which it has not yet
received an EAP.Response. The Peer MUST NOT resend EAP.Response
messages, unless the Peer receives a duplicate EAP.Request message
for which it already sent an EAP.Response, as required by [EAP].
For example, assume that the initial EAP.Request/MAKE/Challenge
message sent by the Server is lost and so the Peer does not receive
it. The Peer does not take any action. After an appropriate time-out,
the Server re-sends the EAP.Request/MAKE/Challenge message.
Eventually, the Peer receives this message. In response to it, the
Peer sends an EAP.Response/MAKE/Challenge message or an
EAP.Response/MAKE/Identity message. If this message is lost as well,
then the Server eventually re-sends the original
EAP.Request/MAKE/Challenge message.
Retry behavior makes it possible for a Peer to receive duplicate
EAP.Request messages, and to also send duplicate EAP.Response
messages, without reprocessing. Both the Peer and the Server state
machines should be able to deal with this effect.
3.2.10. Fragmentation
The EAP-MAKE method does not require fragmentation, as the messages
do not get excessively long. That is, EAP packets are well within the
limit of the maximum transmission unit of other layers (link,
network). The only variable fields are those carrying NAIs, which are
limited by their length field to 256 bytes.
Vanderveen, et. al [Page 18]
INTERNET-DRAFT EAP-MAKE August 2005
3.2.11. Error Cases
Malformed messages: As a general rule, if a Peer or Server receives
an EAP-MAKE packet that contains an error, the implementation SHOULD
silently discard this packet, not change state, nor send any EAP
messages to the other party. Examples of such errors include a
missing mandatory attribute, an attribute that is not allowed in this
type of message, and unrecognized subtypes or attributes.
Time-Outs: If the Server fails to receive a response, it MAY try to
re-transmit the corresponding request. The number of re-transmissions
is implementation-dependent.
Non-matching Session Id: If a Peer or Server receives an EAP-MAKE
packet with a Session Id field not matching the Session Id from the
previous packet in this session, that entity SHOULD silently discard
this packet (not applicable for the first message of an EAP-MAKE
session).
Peer Authorization Failure: It may be possible that a Peer is not
authorized for services, such as when the terminal device is reported
stolen. In that case, the Server SHOULD send an EAP.Failure message.
Unexpected EAP.Success: A Server MUST NOT send an EAP-Success message
before the MAKE/Challenge and MAKE/Confirm rounds. The Peer MUST
silently discard any EAP.Success packets before the Peer has
successfully authenticated the Server via the
EAP.Response/MAKE/Confirm packet.
The Peer and Server SHOULD log all error cases.
3.3. Message Formats
3.3.1. Message Format Summary
A summary of the EAP packet format [EAP] is shown below for
convenience. The fields are transmitted from left to right.
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=EAP-MAKE | Version=2 | Session ID | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 - Request
Vanderveen, et. al [Page 19]
INTERNET-DRAFT EAP-MAKE August 2005
2 - Response
Identifier
The identifier field is one octet and aids in matching
responses with requests.
Length
The Length field is two octets and indicates the number of
octets in an EAP message including the Code, Identifier,
Length, Type, and Data fields.
Type
TBD
Version
The EAP-MAKE method as described herein is version 2.
Session ID
The Session ID is a 1-byte random number that MUST be freshly
generated by the Server that must match all EAP messages in a
particular EAP conversation.
Subtype
EAP-MAKE subtype: MAKE/Challenge, MAKE/Confirm, MAKE/Auth-
Reject, and MAKE/Identity. All messages of type "EAP-MAKE" that
are not of these subtypes MUST silently discarded.
Message Name Subtype Value (decimal)
=============================================
MAKE/Challenge 1
MAKE/Confirm 2
MAKE/Auth-Reject 3
MAKE/Identity 4
All EAP-MAKE packets SHOULD align on a 32-bit boundary. To this end,
the AT_PADDING attribute is used (described in section 3.2.8.2.).
3.3.2. Expanded Types
The format of the EAP-MAKE messages following the Expanded Types is
as follows (note the pad byte for 32-bit alignment):
Vanderveen, et. al [Page 20]
INTERNET-DRAFT EAP-MAKE August 2005
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 | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad=0x0 | Version=2 | Session ID | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.3. Attribute Format
The EAP-MAKE attributes that are part of the EAP-MAKE packet follow
the Type-Length-Value format with 1-byte Type, 1-byte Length, and
variable-length Value (up to 255 bytes). The Length field is in
octets and includes the length of the Type and Length fields. The
EAP-MAKE attribute format 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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1-byte unsigned integer, See Table below.
Length
The total number of octets in the attribute, including Type and
Length.
Value
Attribute-specific.
Attr. Name Length
(bytes) Skippable Description
-----------------------------------------------------------------
AT_RAND_S 18 No Server Nonce RAND_S
AT_RAND_P 18 No Peer Nonce RAND_P
AT_MIC_S 10 No Server Signature/MIC
AT_MIC_P 10 No Peer Signature/MIC
AT_SERVERID variable No Server FQDN
AT_PEERID variable No Peer NAI (tmp, perm)
AT_SPI_S variable No Server chosen SPI SPI_S
Vanderveen, et. al [Page 21]
INTERNET-DRAFT EAP-MAKE August 2005
AT_SPI_P variable No Peer SPI list SPI_P
AT_ENCR_DATA Variable Yes Contains encrypted attributes
AT_IV Variable Yes IV for encrypted attributes
AT_PADDING 2 to 18 Yes Padding for encrypted attributes
AT_NEXT_TMPID variable Yes TempID for next EAP-MAKE phase
AT_ANY_ID_REQ 4 No Requires any Peer Id (tmp, perm)
AT_PERM_ID_REQ 4 No Requires Peer's permanent Id/NAI
AT_MSK_LIFE 6 Yes MSK Lifetime in seconds
3.3.4. Use of AT_ENCR_DATA Attribute
An example of the AT_ENCR_DATA attribute as used in the
EAP.Request/MAKE/Confirm message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Initialization Vector |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}e
| AT_NEXT_TMPID | Length | |}n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |}c
| |}r
. Peer TempID |}y
. |}p
. |}t
|}e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}d
| AT_MIC_S | Length = 10 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_S |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |AT_PADDING | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.5. EAP.Request/MAKE/Challenge Format
The format of the EAP.Request/MAKE/Challenge packet is shown below.
Vanderveen, et. al [Page 22]
INTERNET-DRAFT EAP-MAKE August 2005
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=EAP-MAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RAND_S | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| RAND_S |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_SERVERID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
| Server ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
Code
1 for Request
Identifier
A random number. See [EAP].
Length
The length of the entire EAP packet in octets.
Type
EAP-MAKE
Version
2
Session ID
A random number chosen by the server to identify this EAP-
Session.
Subtype
Vanderveen, et. al [Page 23]
INTERNET-DRAFT EAP-MAKE August 2005
1 for MAKE/Challenge
AT_RAND_S
The value field of this attribute contains the Server nonce
RAND_S parameter. The RAND_S attribute MUST be present in
EAP.Request/MAKE/Challenge.
AT_SERVERID
The value field of this attribute contains the Server identifier
(e.g. a non-null terminated string). The AT_SERVERID attribute
SHOULD be present in EAP.Request/MAKE Challenge.
3.3.6. EAP.Response/MAKE/Challenge Format
The format of the EAP.Response/MAKE/Challenge packet 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=EAP-MAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RAND_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| RAND_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_PEERID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Peer NAI :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_SPI_P | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPIP | AT_MIC_P | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_P |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
Vanderveen, et. al [Page 24]
INTERNET-DRAFT EAP-MAKE August 2005
Code
2 for Response
Identifier
A number that MUST match the Identifier field from the
corresponding Request.
Length
The length of the entire EAP packet in octets.
Type
EAP-MAKE
Version
2
Session ID
A number matching all other EAP messages in this EAP session.
Subtype
1 for MAKE/Challenge
AT_RAND_P
The value field of this attribute contains the Peer nonce RAND_P
parameter. The AT_RAND_P attribute MUST be present in the
EAP.Response/MAKE/Challenge.
AT_PEERID
The value field of this attribute contains the NAI of the Peer.
The Peer identity follows the same Network Access Identifier
format that is used in EAP.Response/Identity, i.e. including the
NAI realm portion. The identity is the permanent identity, or a
temporary identity. The identity does not include any
terminating null characters. The AT_PEERID attribute is optional
in the EAP.Response/MAKE/Challenge.
AT_SPI_P
Vanderveen, et. al [Page 25]
INTERNET-DRAFT EAP-MAKE August 2005
The value field of this attribute contains the Peer's
ciphersuite list SPI_P parameter. The AT_SPI_P attribute is
optional in the EAP.Response/MAKE/Challenge.
AT_MIC_P
The value field of this attribute contains the Peer signature
MIC_P parameter. The AT_MIC_P attribute MUST be present in the
EAP.Response/MAKE/Challenge.
3.3.7. EAP.Request/MAKE/Confirm Format
The format of the EAP.Request/MAKE/Confirm packet 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=EAP-MAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SPI_S | Length | SPI_S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length | Initialization Vector ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data... |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MSK_LIFE | Length=6 | MSK Lifetime... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_MIC_S | Length=18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_S |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
Code
Vanderveen, et. al [Page 26]
INTERNET-DRAFT EAP-MAKE August 2005
1 for Request
Identifier
A random number. See [EAP].
Length
The length of the entire EAP packet in octets.
Type
EAP-MAKE
Version
2
Session ID
A number matching all other EAP messages in this EAP session.
Subtype
2 for MAKE Confirm
AT_SPI_S
The value field of this attribute contains the Server chosen
ciphersuite SPI_S parameter. The AT_SPI_S attribute is optional
in the EAP.Request/MAKE/Confirm.
AT_IV
This attribute is optional to use in this message. The value
field of this attribute contains the Initialization Vector that
is used with the encrypted data following.
AT_ENCR_DATA
This attribute is optional to use in this message. The encrypted
data, if present, may contain an attribute AT_NEXT_TMPID,
containing the NAI the Peer should use in the next EAP
authentication.
AT_MSK_LIFE
This attribute is optional to use in this message. The value
field of this attribute contains the MSK Lifetime in seconds.
Vanderveen, et. al [Page 27]
INTERNET-DRAFT EAP-MAKE August 2005
AT_MIC_S
The value field of this attribute contains the Server signature
MIC_S parameter. The AT_MIC_S attribute MUST be present in the
EAP.Request/MAKE/Confirm.
3.3.8. EAP.Response/MAKE/Confirm Format
The format of the EAP.Response/MAKE/Confirm packet 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=EAP-MAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MIC_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_PADDING | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
Code
2 for Response
Identifier
A number that MUST match the Identifier field from the
corresponding Request.
Length
The length of the entire EAP packet in octets.
Type
EAP-MAKE
Version
2
Vanderveen, et. al [Page 28]
INTERNET-DRAFT EAP-MAKE August 2005
Session ID
A number matching all other EAP messages in this EAP session.
Subtype
2 for MAKE Confirm
AT_MIC_P
The value field of this attribute contains the Peer's signature
MIC_P parameter. The AT_MIC_P attribute MUST be present in the
EAP.Response/MAKE/Confirm.
AT_PADDING
The value field is set to zero. Added to achieve 32-bit
alignment of the EAP-MAKE packet.
3.3.9. EAP.Response/MAKE/Auth-Reject Format
The format of the EAP.Response/MAKE/Auth-Reject packet 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=EAP-MAKE | Version=2 | Session ID | Subtype=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
Code
2 for Response
Identifier
A number that MUST match the Identifier field from the
corresponding Request.
Length
The length of the entire EAP packet in octets.
Vanderveen, et. al [Page 29]
INTERNET-DRAFT EAP-MAKE August 2005
Type
EAP-MAKE
Version
2
Session ID
A number matching all other EAP messages in this EAP session.
Subtype
3 for MAKE/Auth-Reject
3.3.10. EAP.Request/MAKE/Identity Format
The format of the EAP.Request/MAKE/Identity 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=EAP-MAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_PERM..._REQ | Length = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_ANY_ID_REQ | Length = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_SERVERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Server ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
Code
1 for Request
Identifier
A random number. See [EAP].
Length
The length of the entire EAP packet in octets.
Type
Vanderveen, et. al [Page 30]
INTERNET-DRAFT EAP-MAKE August 2005
EAP-MAKE
Version
2
Session ID
A number matching all other EAP messages in this EAP session.
Subtype
4 for MAKE/Identity
AT_PERM_ID_REQ
The AT_PERM_ID_REQ attribute is optional, to be included in
cases where the Server requires the Peer to give its permanent
identifier (i.e. PermID). The AT_PERM_ID_REQ MUST NOT be
included if the AT_ANY_ID_REQ attribute is included. The value
field only contains two reserved bytes, which are set to zero
on sending and ignored on reception.
AT_ANY_ID_REQ
The AT_ANY_ID_REQ attribute is optional, to be included in cases
where the Server requires the Peer to send any identifier (e.g.
PermID, TempID). The AT_ANY_ID_REQ MUST NOT be included if
AT_PERM_ID_REQ is included. The value field only contains two
reserved bytes, which are set to zero on sending and ignored on
reception. One of the AT_PERM_ID_REQ and AT_ANY_ID_REQ MUST be
included.
AT_SERVERID
The value field of this attribute contains the identifier/realm
of the Server. The AT_SERVERID attribute is optional but
RECOMMENDED to include in the EAP.Request/MAKE/Identity.
3.3.11. EAP.Response/MAKE/Identity Format
The format of the EAP.Response/MAKE/Identity 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=EAP-MAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vanderveen, et. al [Page 31]
INTERNET-DRAFT EAP-MAKE August 2005
| AT_PEERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Peer NAI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
Code
2 for Response
Identifier
A number that MUST match the Identifier field from the
corresponding Request.
Length
The length of the entire EAP packet.
Type
EAP-MAKE
Version
2
Session ID
A number matching all other EAP messages in this EAP session.
Subtype
4 for MAKE/Identity
AT_PEERID
The value field of this attribute contains the NAI of the Peer.
The AT_PEERID attribute MUST be present in
EAP.Response/MAKE/Identity.
3.3.12. Other EAP Messages Format
The format of the EAP.Request/Identity and EAP.Response/Identity
packets is described in [EAP].The user ID (e.g. NAI) should be
present in this packet.
The format of the EAP-Success and EAP-Failure packet is also shown in
[EAP].
Vanderveen, et. al [Page 32]
INTERNET-DRAFT EAP-MAKE August 2005
4. IANA Considerations
This memo requires IANA to allocate a new EAP Type for EAP-MAKE.
EAP-MAKE messages include an 8-bit Subtype field. The Subtype is a
new numbering space for which IANA administration. The following
Subtypes are specified:
MAKE/Challenge.................1
MAKE/Confirm...................2
MAKE/Auth-Reject...............3
MAKE/Identity..................4
The Subtype-specific data is composed of attributes, which have an 8-
bit type number. The attribute type is a new numbering space for
which IANA administration. The following attribute types are
specified:
AT_RAND_S.......................................1
AT_RAND_P.......................................2
AT_MIC_S........................................3
AT_MIC_P........................................4
AT_SERVERID.....................................5
AT_PEERID.......................................6
AT_SPI_S........................................7
AT_SPI_P........................................8
AT_ANY_ID_REQ...................................9
AT_PERM_ID_REQ.................................10
AT_ENCR_DATA..................................128
AT_IV.........................................129
AT_PADDING....................................130
AT_NEXT_TMPID.................................131
AT_MSK_LIFE... ...............................132
5. Security Considerations
The EAP specification [EAP] describes the security vulnerabilities of
EAP, which does not include its method-specific security mechanisms.
This section discusses the claimed security properties of the EAP-
MAKE method, along with vulnerabilities and security recommendations.
5.1. Denial-of-service Attacks
Since EAP-MAKE is not a tunneling method, the EAP.Response/MAKE/Auth-
Reject, EAP.Success and EAP.Failure packets are not integrity or
replay protected. This makes it possible for an attacker to spoof
such messages. Note that EAP.Response/MAKE/Auth-Reject and
EAP.Failure messages cannot be signed in cases where there is an
Vanderveen, et. al [Page 33]
INTERNET-DRAFT EAP-MAKE August 2005
authentication failure, indicating that the Server and Peer do not
agree on a common key.
Most importantly, an attacker cannot cause a Peer to accept an
EAP.Success packet as indication that the Server considers the mutual
authentication to have been achieved. This is because a Peer does not
accept EAP.Success packets before it has authenticated the Server or
after it has considered the Server to have failed authentication.
5.2. Root Secret Considerations
If the Root Secret is known to any party other than the Server and
Peer, then the mutual authentication and key establishment using EAP-
MAKE is compromised.
EAP-MAKE does not address how the Root Secret is generated or
distributed to the Server and Peer. It is RECOMMENDED that the
entropy of the Root Secret be maximized. The Root Secret SHOULD be
machine-generated.
If the Root Secret is derived from a low-entropy, guessable quantity
such as a human-selected password, then the EAP-MAKE key derivation
is subject to on-line and off-line dictionary attacks. To help
identify whether such a password has been compromised,
implementations SHOULD keep a log of the number of EAP-MAKE messages
received with invalid MIC fields. In these cases, a procedure for
updating the Root Secret securely SHOULD be in place.
5.3. Mutual Authentication
Mutual authentication is accomplished via the MAKE/Challenge and
MAKE/Confirm messages. The EAP.Request/MAKE/Challenge contains the
Server nonce RAND_S, the EAP.Response/MAKE/Challenge contains the
Peer nonce RAND_P, along with the Peer MIC or signature MIC_P, and
the EAP.Request/MAKE/Confirm contains the Server MIC or signature
MIC_S. Both signatures MIC_S and MIC_P are computed using both nonces
RAND_S and RAND_P and keyed by the TEK, a shared secret derived from
the Root Secret. The Server considers the Peer authenticated if the
MIC_P it computes matches the one that the Peer sends. Similarly, the
Peer considers the Server authenticated if the MIC_S it computes
matches the one that the Server sends. The way the MICs are computed
involves a keyed one-way hash function, which makes it
computationally hard for an attacker to produce the correct MIC
without knowledge of the shared secret.
5.4. Integrity Protection
Integrity protection of EAP-MAKE messages is accomplished through the
use of the Message Integrity Checks (MIC), which are present in every
message as soon as a common shared secret (TEK) is available, i.e.
any message after the EAP.Request/MAKE/Challenge. An adversary cannot
Vanderveen, et. al [Page 34]
INTERNET-DRAFT EAP-MAKE August 2005
modify any of the MIC-protected messages without causing the
recipient to encounter a MIC failure. The extent of the integrity
protection is commensurate with the security of the KDF used to
derive the MIC, the length and entropy of the shared secret used by
the KDF, and the length of the MIC.
5.5. Replay Protection
The first message of most session establishment protocols such as
EAP-MAKE is subject to replay. A replayed EAP.Request/MAKE/Challenge
message results in the Peer sending an EAP.Response/MAKE/Challenge
message back, which contains a MIC that was computed using the
attacker's chosen nonce. This poses a minimal risk to the compromise
of the TEK-Auth key, and this EAP Session cannot proceed successfully
as the Peer will find the Server's MIC invalid.
Replay protection is achieved via the Session ID field and the MIC
present in each EAP packet. The Session ID MUST be generated anew by
the Server for each EAP session. Session Ids also aid in
identification of possible multiple EAP sessions between a Peer and
the Server. It prevents replay between sessions. Within the same
session, messages can be replayed by an attacker, but the state
machine should be able to handle these cases. Note that a replay
within a session is indistinguishable to a recipient from a network
malfunction (e.g. message first lost, then re-transmitted, so
recipient thinks it is a duplicate message).
Replay protection between EAP sessions and within an EAP session is
also accomplished via the MIC, which cover not only the entire EAP
packet (including the Session ID) but also the nonces RAND_S and
RAND_P. Thus, the recipient of an EAP message can be assured that the
message it just received is the one just sent by the other Peer and
not a replay, since it contains a valid signature (MIC) of the
recipient's nonce and the other Peer nonce. As before, the extent of
replay protection is commensurate with the security of the KDF used
to derive the MIC, the length and entropy of the shared secret used
by the KDF, and the length of the MIC.
5.6. Confidentiality
Confidentiality of EAP-MAKE attributes is supported through the use
of the AT_ENCR_DATA and AT_IV attributes. A ciphersuite is negotiated
securely (see section 3.2.7) and can be used to encrypt any
attributes as needed. The default ciphersuite contains a strong
cipher based on AES.
5.7. Key Derivation, Strength
EAP-MAKE derives a Master Key (for EAP use) and Master Session Key,
as well as other lower-level keys such as TEKs. Some of the lower
Vanderveen, et. al [Page 35]
INTERNET-DRAFT EAP-MAKE August 2005
level keys may or may not be used. The strength (entropy) of all
these keys is at most the strength of the Root Secret.
The entropy of the MSK and of the EMSK, assuming that the Server and
Peer 128-bit nonces are generated using good random number
generators, is at most 256-bits.
5.8. Dictionary Attacks
Dictionary attacks are not feasible to mount on the EAP-MAKE method
because passwords are not used: instead, the Root Secret is machine-
generated. This does not necessarily pose provisioning problems.
5.9. Man-in-the-middle Attacks
Resistance to man-in-the-middle attacks is provided through the
integrity protection that each EAP message carries (i.e. Message
Integrity Check field) as soon as a common key for this EAP session
has been derived through mutual authentication. As before, the extent
of this resistance is commensurate with the strength of the MIC
itself. Man-in-the-middle attacks associated with the use of any EAP
method within a tunneling or sequencing protocol are beyond the scope
of this document.
5.10. Result Indication Protection
EAP-MAKE provides result indication protection in that it provides
result indications, integrity protection, and replay protection. The
Server indicates that it has successfully authenticated the Peer by
sending the EAP.Request/MAKE/Confirm message which is integrity and
replay protected. The Peer indicates that it has successfully
authenticated the Server by sending the EAP.Response/MAKE/Confirm
message, which is also integrity and replay protected.
5.11. Cryptographic Separation of Keys
The TEKs used to protect EAP-MAKE packets (TEK-Auth, TEK-Cipher), the
Master Session Key, and the Extended Master Session Key are
cryptographically separate. Information about any of these keys does
not lead to information about any other keys. We also note that it is
infeasible to calculate the Root Secret from any or all of the TEKs,
the MSK, or the EMSK.
5.12. Session Independence
Within each EAP-MAKE session, fresh keying material is generated. The
keying material exported by this method from two independent EAP-MAKE
sessions is cryptographically separate, as explained below.
Both the Server and the Peer SHOULD generate fresh random numbers
(i.e. nonces) for the EAP-MAKE exchange. If either entity re-uses a
Vanderveen, et. al [Page 36]
INTERNET-DRAFT EAP-MAKE August 2005
random number from a previous session, then the fact that the other
does use a freshly generated random number implies that the TEKs,
MSK, and EMSK derived within this session are cryptographically
separate from the corresponding keys derived in the previous
exchange.
Therefore, compromise of MSK or EMSK on one exchange does not
compromise the MSK and EMSK of previous or subsequent exchanges
between a Peer and a Server.
5.13. Identity Protection
As seen from Section 3.2.3., the Server may assign a temporary NAI to
a Peer in order to achieve user anonymity. This identifier may be
used by the Peer next time it engages in an EAP-MAKE authentication
phase with the Server. The TempID is protected by sending it
encrypted, within an AT_ENCR_DATA attribute, and signed by the Server
with a MIC. Thus, an eavesdropper cannot link the original PermID
that the Peer first sends (e.g. on power-up) to any subsequent TempID
values sent in the clear to the Server.
The Server and Peer MAY be configured such that only TempID
identities are exchanged after one initial EAP-MAKE phase that uses
the Peer permanent identity. In this case, in order to achieve
maximum identity protection, the TempID should be stored in non-
volatile memory in the Peer and Server. Thus compliance with this
draft does not preclude nor mandates Peer identity protection across
the lifetime of the Peer.
5.14. Channel Binding
The Server identifier and Peer identifier MAY be sent in the
MAKE/Challenge messages. However, since there is no established
authentication key at the time of the first message, the Server
identifier is not integrity protected here.
All subsequent EAP-MAKE messages exchanged during a successful EAP-
MAKE phase are integrity-protected as they contain a Message
Integrity Check (MIC). The MIC is computed over the EAP message and
also over the Server and Peer identities. In that, both EAP endpoints
can verify the identity of the other party.
5.15. Negotiation Attacks
The ciphersuite negotiation is protected in order to minimize the
risk of down-negotiation or man-in-the-middle attacks where an
attacker manages to get the Peer and Server to agree on the weakest
possible ciphersuite (allowed in the system), even though they are
both capable of supporting stronger ciphersuites.
Vanderveen, et. al [Page 37]
INTERNET-DRAFT EAP-MAKE August 2005
The negotiation is secure because of the Message Integrity Checks
(MICs) that cover the entire EAP messages used for ciphersuite
negotiation (see Section 3.2.7.). The extent of the security of the
negotiation is commensurate with the security of the KDF used to
derive the MICs, the length and entropy of the shared secret used by
the KDF, and the length of the MICs.
5.16. Random Number Generation
EAP-MAKE supports key derivation from a 32-byte Root Secret. The
entropy of all other keys derived from it is reduced somewhat through
the use of keyed hash functions (e.g. KDF). Thus, assuming
optimistically that the effective key strength of the Root Secret is
32 bytes, the effective key strengths of the derived keys is at most
the effective key strength of the Root Secret quantities they are
derived from: EMSK, at most 16 bytes; MSK, at most 16 bytes.
6. Security Claims
This section provides the security claims as required by [EAP].
[a] Mechanism: EAP-MAKE is a challenge/response authentication and
key establishment mechanism based on a symmetric pre-shared
secret.
[b] Security claims. EAP-MAKE provides:
Mutual authentication (Section 5.3)
Integrity protection (Section 5.4)
Replay protection (Section 5.5)
Confidentiality (optional, Section 5.6 and Section 5.13)
Key derivation (Section 5.7)
Dictionary attack protection (Section 5.8)
Protected result indication of successful authentication from
Server and from Peer (Section 5.10)
Session independence (Section 5.12)
Protected ciphersuite negotiation (Section 5.15)
[c] Key strength. EAP-MAKE supports key derivation with 256-bit
effective key strength (Section 5.7.)
Vanderveen, et. al [Page 38]
INTERNET-DRAFT EAP-MAKE August 2005
[d] Description of key hierarchy: see Section 3.2.5.
[e] Indication of vulnerabilities: EAP-Make does not provide:
Fast reconnect
Fragmentation
Channel binding
Cryptographic binding
7. Acknowledgements
Thanks to R. Dynarski for his comments.
8. References
8.1. Normative References
[AES] National Institute of Standards and Technology, "Federal
Information Processing Standards (FIPS) Publication 197,
Advanced Encryption Standard (AES)", November 2001.
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and
Levkowetz, H. "Extensible Authentication Protocol (EAP)
", RFC 3748, June 2004.
[HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[IEEE802.11i]"IEEE Standard for Information Technology-
Telecommunications and Information Exchange between
Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer
(PHY) specifications: Amendment 6: Medium Access Control
(MAC) Security Enhancements", June 2004.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CBC] National Institute of Standards and Technology, NIST
Special Publication 800-38A, "Recommendation for Block
Cipher Modes of Operation - Methods and Techniques",
December 2001.
http://csrc.nist.gov/publications/nistpubs/800-a/sp800-38a.pdf
Vanderveen, et. al [Page 39]
INTERNET-DRAFT EAP-MAKE August 2005
[SHA1] National Institute of Standards and Technology, U.S.
Department of Commerce, Federal Information Processing
Standard (FIPS) Publication 180-1, "Secure Hash
Standard", April 1995.
8.2. Informative References
[NAI] Aboba, B., and Beadles, M., "The Network Access
Identifier", RFC NAI, January 1999.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses
Michaela Vanderveen
Flarion Technologies
135 Rte. 202/206 South
Bedminster, NJ 07921
USA
E-mail: mcv@flarion.com
Hesham Soliman
Flarion Technologies
135 Rte. 202/206 South
Bedminster, NJ 07921
USA
E-mail: h.soliman@flarion.com
Intellectual Property Statement
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
Vanderveen, et. al [Page 40]
INTERNET-DRAFT EAP-MAKE August 2005
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Vanderveen, et. al [Page 41]
