Internet DRAFT - draft-otto-eap-skl
draft-otto-eap-skl
Network Working Group T. Otto
Internet-Draft TU Braunschweig
Expires: April 9, 2006 October 6, 2005
The EAP-SKL protocol
draft-otto-eap-skl-03.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 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 April 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes EAP-SKL, an Extensible Authentication
Protocol (EAP) method which provides mutual authentication and key
derivation based on a pre-shared secret. EAP-SKL relies on the
cryptographic protocol SKEME (Secure Key Exchange MEchanism
protocol), and hence may benefit from its simplicity and the provable
security. EAP-SKL complies with the mandatory requirements for an
EAP method which is intented for deployment in Wireless LAN
environments.
Otto Expires April 9, 2006 [Page 1]
Internet-Draft The EAP-SKL protocol October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.2. EAP Terminology . . . . . . . . . . . . . . . . . . . . . 4
2. Cryptographic Considerations . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
4. Packet formats . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Computational costs . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. T-PRF . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Otto Expires April 9, 2006 [Page 2]
Internet-Draft The EAP-SKL protocol October 2005
1. Introduction
IEEE 802.11i makes use of IEEE 802.1X which in turn chooses the
Extensible Authentication Protocol (EAP) for carrying authentication
messages. EAP itself is only a framework, and runs over various link
layers, like IEEE 802.3 Ethernet, IEEE 802.11 Wireless LAN or PPP.
In fact, the proper authentication is performed by so called EAP
methods.
In 1998, when RFC 2284 was adopted, an usage of EAP outside of wired
networks was not taken into account. EAP was thoroughly reviewed,
which yielded in May 2004 in RFC 3748. For compatibility reasons,
these three EAP methods are still part of the EAP specification, even
if declared as deprecated. EAP-MD5, for instance, lacks of mutual
authentication and derivation of session keying material, as mandated
in [RFC3748].
It has been widely recognized that this state is dissatisfying. In
particular, it lacks of a pre-shared key EAP method, which is simple
(that is lightweight in terms of bandwidth, latency and computational
costs as well as easy in deployment) and, at the same time, provides
enough security strength to be used in hostile environments like the
Internet or Wireless LAN. Such an EAP method could possibly serve as
a replacement for the deprecated EAP-MD5.
EAP-SKL attempts to be an straightforward EAP method with as much
features as needed but as few as possible. More precisely, EAP-SKL
takes all mandatory requirements into account, with main focus on
mutual authentication and adequate session key derivation. Current
pre-shared key EAP methods are EAP-FAST, EAP-SIM/AKA, EAP-PSK, EAP-
PAX, EAP-TLS (with appropriate extensions) as well as EAP-IKEv2,
where EAP-SKL claims to be the simplest one. Further informations
about EAP methods can be found in the comprehensive compilation
[I-D.bersani-eap-synthesis-sharedkeymethods].
Furthermore, EAP-SKL relies on only one cryptographic primitive,
namely the hash function SHA-1 ([FIPS.180-1.1994]) and optionally the
Diffie-Hellman key agreement protocol ([RFC2631]). The choice of
SKEME as an appropriate key establishment protocol makes it possible
to fully abstain from block ciphers and stream ciphers. Of course,
this restricts EAP-SKL's ability to solely perform the mutual
authentication task, and does not allow for encrypted communication,
like, for instance, EAP-PSK does so. The author is convinced that
there are many deployment scenarios, where indeed nothing more than
minimalistic functionality is required and desired. Consequently,
and in contrast to many other EAP methods, EAP-SKL does not
implement, for instance, version negotiation, fragmentation, session
resuming, protected result indication or end-user identity hiding.
Otto Expires April 9, 2006 [Page 3]
Internet-Draft The EAP-SKL protocol October 2005
Nevertheless, there is a single feature which is highly desireable in
some cases, namely Perfect Forward Secrecy.
The rest of this document is organized as follows. In the remaining
section 1, some terminology is introduced. Section 2 highlights the
cryptographic background of EAP-SKL. Section 3 and 4 cover the EAP-
SKL protocol and the packet format of the messages. Section 5 and 6
are IANA Considerations and Security Considerations, respectively.
1.1. Requirements notation
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].
1.2. EAP Terminology
This section contains variables and abbreviations which will be
referenced in later sections. For the exact meaning of the roles
"peer", "Supplicant", "backend authentication server" and "EAP
server" please refer to the EAP specification [RFC3748]. In this
document, the words peer and client are used equivalently. The EAP
conversation takes place between the client and the EAP server.
Ko: 160-bit symmetric key; shared between client and EAP server. Ko
is the most longlife credential within EAP-SKL.
MK: Master Key; shared between the client and EAP server from which
all other EAP method session keys are derived.
MSK: Master Session Key; generated from the MK and exported by the
EAP method to the authenticator.
EMSK: Extended Master Session Key; also generated from the MK. It
contains additional keying material.
G: public Diffie-Hellman group
g: public generator of group G
x: 256-bit nonce generated by the client
y: 256-bit nonce generated by the server
.: (dot); string or binary data concatenation.
^: modular exponentiation
Otto Expires April 9, 2006 [Page 4]
Internet-Draft The EAP-SKL protocol October 2005
"": NULL string
PRF: Pseudo-random function
F_Ko: pseudorandom function (PRF) keyed with Ko
H: hash function
SK: session key
id_P: client's identity
id_S: EAP server's identity
PFS: Perfect forward secrecy
The corresponding instantiation by EAP-SKL is described in Section 2.
Otto Expires April 9, 2006 [Page 5]
Internet-Draft The EAP-SKL protocol October 2005
2. Cryptographic Considerations
This section describes the cryptographic design of EAP-SKL. The
cryptographic protocol SKEME was chosen to realize mutual
authentication and session key establishment. SKEME provides four
operational modes, which offers high flexibility. More precisely, it
allows the usage of PKIs, KDC and manual (pre-shared) distribution of
keying material for an initial keying relationship.
Since EAP-SKL is a pre-shared key authentication method, only the
corresponding two modes of SKEME are implemented. The one, from now
on referred to as "mode 1", provides Perfect Forward Secrecy (PFS)
and hence incorporates a Diffie-Hellman (DH) Key Exchange, which is
known to be computational expensive. If this property is not needed,
the other mode, referred to as "mode 2", is chosen. This mode
achieves freshness by exchanging random values (nonces), and in
absence of asymmetric cryptography mode 2 is notably efficient. In a
nutshell, mode 1 provides a better security strength but higher
computational costs, whereas mode 2 performs very fast but with fewer
security strength. See section 4 for more details.
The notation introduced by [SKEME] is maintained to avoid confusion.
There is a collision-resistant hash function, H, a pseudorandom
function using key Ko, F_Ko, and as parameters for the DH key
exchange g, x, y, m, where g is the generator, m the modulus, and x
and y are the client's and EAP server's private DH key, respectively.
In EAP-SKL, H is SHA-1 and F_Ko over message M is SHA-1(Ko.M).
In the next section, the two modes of EAP-SKL are described. For
mode 2, the session key is computed via
SK =F_Ko(F_Ko(value_S.value_P.id_P.id_S)),
that is, a keyed PRF is applied twice on an input. This idea has
finally lead to the HMAC-construction. A HMAC (hash-based MAC) over
the input "text" is defined as
HMAC(K;text) = H(K XOR opad . H(K XOR ipad . text)).
The output of SHA-1 and subsequently of HMAC-SHA1 is 160 bit.
As recommended in [RFC2104], the length of K should be equal to the
hash output length, less is explicitely discouraged (as itwould
decrease the the security strength). Therefore, EAP-SKL mandates the
length of Ko to be 160 bit.
Furthermore, SK corresponds to the EAP Master Key (MK), which remains
solely within the EAP method.
Otto Expires April 9, 2006 [Page 6]
Internet-Draft The EAP-SKL protocol October 2005
Finally, the DH key exchange parameters have been chosen in
accordance to [RFC3766]. The strength of the DH key exchange is
based on the modulus size as well as the exponent size. An 3000-bit
MODP public-key scheme corresponds roughly to a 128-bit symmetric-key
scheme. EAP-SKL utilizes the 3072-bit MODP Group (id 15), defined in
[RFC3526]. According to [RFC3526], the exponent size used in the DH
key exchange should have double the entropy of the strength of the
entire system, in particular the size of any symmetric key that will
be derived from it (SK, MSK, EMSK). Since EAP-SKL has an effective
key strength of 128 bit, the DH exponents (private keys) MUST have at
least 256 bit. As cyclic group, g=2 is chosen (has advantage for
hardware accelerated computation).
SKEME | EAP-SKL
-------------+--------------------
g | 2
m | 3072-bit MODP Group
x, y | 256 bit
H | SHA-1
F_Ko(M) | SHA-1(Ko.M)
F_Ko(F_Ko(M))| HMAC-SHA1(Ko;arg)
-------------+--------------------
Figure 1
The rest of this section provides further details about the two
modes.
Before any run of EAP-SKL, client and EAP server must agree on some
160-bit pre-shared key, referred to as Ko. How Ko is established, is
beyond the scope of EAP-SKL and thus must be realized by some secure
out-of-band mechanism. At the end of a successful authentication,
both client and EAP server have independently derived a session key,
SK, in length of 160 bit. This key in turn is adequately expanded to
generate the required keying material, that is a 64-byte MSK and a
64-byte EMSK.
This is realized by a pseudorandom function, T-PRF, which is based on
SHA-1 and widely accepted. EAP-FAST and PEAP make, for instance, use
of this function. Please see Appendix A for internals of T-PRF.
T-PRF is invoked with the parameters (Key, S, OutputLength), where S
= label + 0x00 + seed.
EAP-SKL calls T-PRF with the following parameters: TPRF(Ko, "EAP-SKL"
+0x00+ SK, 128).
Otto Expires April 9, 2006 [Page 7]
Internet-Draft The EAP-SKL protocol October 2005
Since T-PRF generates in each iteration 20 byte random data, EAP-SKL
let T-PRF iterate 7 times and then skip the last 12 byte. Figure 2
illustrates the keying material in EAP-SKL.
+---------+
| Ko | 160 bit
+---------+
|
+===================+
| |
| EAP-SKL |
| |
+===================+
|
+---------+
| SK | 160 bit
+---------+
|
|
+---------+
| T-PRF | pseudorandom function
+---------+
|
| 7*20 byte, 0..139
|
| +---------+ -+
+-----------| MSK | 64 byte |
| 0..63 +---------+ | exported
| | by EAP-SKL
| +---------+ |
+-----------| EMSK | 64 byte |
64..127 +---------+ -+
Figure 2
Otto Expires April 9, 2006 [Page 8]
Internet-Draft The EAP-SKL protocol October 2005
3. Protocol Overview
The message flow of EAP-SKL is shown in Figure 3. The conversation
begins with the exchange of EAP Identity messages, where "id" is
reserved for special tasks, like routing purposes or session
resumption.
P <--- S: EAP-Request/Identity (1)
P ---> S: EAP-Response/Identity(id) (2)
P <--- S: EAP-Request/EAP-SKL (Start) (3)
P ---> S: EAP-Response/EAP-SKL (id_P,value_P) (4)
P <--- S: EAP-Request/EAP-SKL(id_S,value_S,
F_Ko(value_P.value_S.id_S.id_P)) (5)
P ---> S: EAP-Response(F_Ko(value_S.value_P.id_P.id_S)) (6)
P <--- S: EAP-Success (7)
Figure 3
The respective values of value_S and value_P and thus the derivation
of SK depend on the chosen mode (Figure 4).
| PFS | value_P | value_S | SK | H(M) | F_Ko(M)
-------+-----+---------+---------+-----------+---------+-----------
mode 1 | yes | g^x | g^y | H(g^xy) | |
-------+-----+---------+---------+-----------+ SHA-1(M)| SHA-1(Ko.M)
mode 2 | no | nonce_P | nonce_S | F_Ko(arg) | |
-------+-----+---------+---------+-----------+---------+-----------
where arg = F_Ko(value_S.value_P.id_P.id_S).
Figure 4
The choice of the mode is left solely to the EAP server. The client
finds this out by the type of the received TLV payload in message
(3). If the client does not agree with the proposed mode, he
indicates this by sending EAP-Response/Nak. Subsequently, the
authentication conversation is aborted.
After the initial identity request/response, the EAP server sends in
message 3 an indication which mode to choose. In Message 4, the peer
sends his freshness parameter (either a DH public key or a nonce).
Message 5 contains the server`s identity, the server`s freshness
parameter, and a MAC. This is verified by the peer, if the
verification is successful, it responds with message 6, which also
contains a MAC. The EAP server does the same computatation. If the
outcome is equal to received MAC, the EAP server is sure to talk to a
legitimate client and finish the EAP conversation with an EAP-
Otto Expires April 9, 2006 [Page 9]
Internet-Draft The EAP-SKL protocol October 2005
Success. Otherwise, the authentication has failed and an EAP-Failure
is sent.
The derivation of SK is, in general SK=F_Ko(arg). But for mode 1,
[SKEME] offers the alternative SK=H(g^xy), which is chosen here.
For mode 1, it holds SK = H(g^(xy)) = SHA-1(g^xy).
For mode 2, we have
SK = F_Ko(arg) = F_Ko(F_Ko(value_S.value_P.id_P.id_S)) =^! HMAC-
SHA1(Ko;arg).
Note that the client has already computed "arg" in message (4) and
thus can reuse the result, which would save computational costs.
Otto Expires April 9, 2006 [Page 10]
Internet-Draft The EAP-SKL protocol October 2005
4. Packet formats
EAP-SKL messages are encapsulated within the payload of EAP-Request
and EAP-Response frames, respectively. Therefore, a generic Type-
length-value (TLV) attribute format is chosen (figure Figure 5).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | length | value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: value (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
Length contains the length of the TLV in byte.
+---------------+--------+-------------------------+---------------+
| attribute name| type | used for | payload size |
+---------------+--------+-------------------------+---------------+
| AT_START | 0 | start | 1 byte |
| AT_ID | 1 | id_P | max. 607 byte |
| AT_NONCE | 2 | nonce_P, nonce_S | 384 byte |
| AT_DH | 3 | DH public key, g^x, g^y | 384 byte |
| AT_MAC | 4 | HMAC-SHA1 | 20 byte |
+---------------+--------+-------------------------+---------------+
Figure 6
That is, the EAP packet payload of messages (2)-(6) consists of one
or more TLVs, as shown in Figure 7. In case of mode 1, messages (3)
and (4) contain AT_DH TLVs, in case of mode 2 AT_NONCE TLVs.
AT_START has a payload of one byte, 0x01 for mode 1, 0x02 for mode 2.
P <--- S: AT_START (3)
P ---> S: AT_ID . AT_NONCE/AT_DH (4)
P <--- S: AT_ID . AT_NONCE/AT_DH . AT_MAC (5)
P ---> S: AT_MAC (6)
Figure 7
Otto Expires April 9, 2006 [Page 11]
Internet-Draft The EAP-SKL protocol October 2005
5. Computational costs
This section briefly considers the computational costs for the
client. Modular exponentiations are known to be computationally
expensive, SHA-1 computations are in contrast to this very
lightweight.
| mod exp. | SHA-1
-------+----------+------
mode 1 | 2 | 9
-------+----------+------
mode 2 | 0 | 11
-------+----------+------
Figure 8
In mode 1, the peer performs 9 SHA-1 calculations, namely 1x for
computing the MAC in message 6, 1x for verification of the MAC in
message 5, and 7x for T-PRF. In mode 2, the peer requires 11 SHA-1
calculations. Overall, especially the computational costs of mode 2
become obvious.
Next, we consider the amount of bytes what each side generates and
transmits. Only messages 3 to 6 are analyzed. An EAP-Request or
EAP-Response frame consists of the fields Code, Identifier, Length,
Type, which are 1+1+2+1=5 bytes in total, followed by a variable
length payload. Only this payload is considered.
size/byte | | mode 1 | mode 2
-----------+--------+---------+---------
| msg 4 | 390+idP | 390+idP
peer +--------+---------+---------
| msg 6 | 23 | 23
-----------+--------+---------+---------
| msg 3 | 4 | 4
EAP +--------+---------+---------
server | msg 5 | 413+idS | 413+idS
-----------+--------+---------+----------
Figure 9
The Diffie-Hellman public key with 384 byte (=3072 bit) size must be
considered as heavyweight, compared to the lightweight EAP frame
structure. An EAP-Request (resp. Response) has 5+sizeof(payload)
bytes length, an EAP-Success or EAP-Failure only 4 bytes.
Otto Expires April 9, 2006 [Page 12]
Internet-Draft The EAP-SKL protocol October 2005
6. Security Considerations
This section analyzes the security of EAP-SKL. In particular, it is
shown that EAP-SKL complies with all mandatory requirements for EAP
methods used in IEEE 802.11 wireless LAN deployments, as outlined in
RFC 4017.
Mechanism:
EAP-SKL belongs to the category of pre-shared key EAP methods.
Mutual authentication:
EAP-SKL provides mutual authentication. If both parties can
verify the received HMAC, the other side is identified and
authenticated. Since the MAC is computed over a string which
contains fresh random values previously generated, both MACs are
interlocked adequately.
Key derivation:
EAP-SKL generates the required keying material, namely a 64 byte
MSK and a 64 byte EMSK, which are exported for derivation of
further keying material.
Replay protection:
EAP-SKL is resistant to replay attacks.
Assume an attacker has captured a whole, successful conversation
of EAP-SKL. First, we investigate what happens if the attacker
wants to impersonate the legitimate client. If value_S of the
captured session is different from the current one, the attack
fails in computing the MAC in message (4). Suppose now, value_S
is the same. It follows that replay of the captures message (4)
as well as (6) are recognized as valid ones by the EAP server and
thus the attacker will receive an EAP-Success. Unfortunately, he
can not derive from HMAC-SHA1(Ko;"success".SK) the session key SK
and thus can not derive MSK and EMSK. The attack ends here, that
is although the EAP authentication has been successful, subsequent
conversation attempts will fail.
This replay attack is avoided by strengthening the server's
implementation. The space for value_P is large enough to reject
any authentication request with the same value_P. Therefore, the
server implementation should maintain a table with all previously
received (id_P,value_P) pairs. With this precaution, a replayed
session is recognized as a such and appropriate countermeasures
Otto Expires April 9, 2006 [Page 13]
Internet-Draft The EAP-SKL protocol October 2005
can take place.
Confidentiality:
EAP-SKL does not provide confidentiality in terms of [RFC3748],
section 7.2.1. The term "confidentiality" refers to encryption of
EAP messages and successful and failure result indications.
Key strength:
The effective key strength of EAP-SKL is 128 bit (see also Section
2).
Resistance to dictionary attacks:
EAP-SKL relies on a pre-shared key, which consists of random data.
It is highly discouraged to generate this random data from a
dictionary entry by applying some pseudorandom function.
Protection against man-in-the-middle attacks:
If the link layer is a shared media, there is generally a
possibility for a third party (MitM) to place between two parties
who want to communicate. The trust relation is established by
deriving some common secret, which a third party can not derive
from the captured conversation. For EAP-SKL, this is the session
key SK, whose lifetime is the session. Without knowledge of Ko
this common secret can not be derived. And without knowledge of
Ko and SK, both MSK and EMSK can not be derived.
Assume now, a MitM sits between peer and EAP Server, and
intercepts all server messages and relays them to the peer. This
works fine for the whole conversation, that is for messages (1) to
(7). But, since the MitM does not know SK, this attack has only
denial-of-service character.
Protected ciphersuite negotiation:
EAP-SKL does not support ciphersuite negotiation.
Fast reconnect:
EAP-SKL does not support fast reconnect.
Otto Expires April 9, 2006 [Page 14]
Internet-Draft The EAP-SKL protocol October 2005
Cryptographic binding:
EAP-SKL performs exactly one authentication and hence this
technique is not applicable.
Fragmentation:
An EAP method may assume a mimimum EAP MTU of 1020 byte. Message
(4) is the largest one. An EAP Request or Response packet begins
with four fields (Code, Identifier, Length and Type), with total 5
byte, followed by the payload. value_P as modulo 3072 can be at
most 384 byte, and finally HMAC-SHA1 produces a 20-byte MAC.
These are 409 byte, so that AT_ID MAY NOT exceed 1020-409=611
byte. The encapsulated id_P thus may not exceed 611-4=607 byte.
End-user identity hiding:
EAP-SKL does not provide end-user identity hiding. The identity
of the client is sent in plaintext.
Otto Expires April 9, 2006 [Page 15]
Internet-Draft The EAP-SKL protocol October 2005
7. IANA Considerations
This document introduces one new IANA consideration. It requires
IANA to allocate a new EAP Type for EAP-SKL.
Otto Expires April 9, 2006 [Page 16]
Internet-Draft The EAP-SKL protocol October 2005
8. Acknowledgment
The author would like to thank Dieter Stolte for useful comments on
the initial version of this draft.
Otto Expires April 9, 2006 [Page 17]
Internet-Draft The EAP-SKL protocol October 2005
9. References
9.1. Normative References
[FIPS.180-1.1994]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, May 1994.
[I-D.cam-winget-eap-fast]
Salowey, J., "EAP Flexible Authentication via Secure
Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-02 (work
in progress), April 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", June 1996.
9.2. Informative References
[I-D.bersani-eap-psk]
Tschofenig, H. and F. Bersani, "The EAP-PSK Protocol: a
Pre-Shared Key EAP Method", draft-bersani-eap-psk-09 (work
in progress), August 2005.
[I-D.bersani-eap-synthesis-sharedkeymethods]
Bersani, F., "EAP shared key methods: a tentative
Otto Expires April 9, 2006 [Page 18]
Internet-Draft The EAP-SKL protocol October 2005
synthesis of those proposed so far",
draft-bersani-eap-synthesis-sharedkeymethods-00 (work in
progress), April 2004.
[I-D.clancy-eap-pax]
Clancy, C. and W. Arbaugh, "EAP Password Authenticated
Exchange", draft-clancy-eap-pax-04 (work in progress),
June 2005.
[I-D.tschofenig-eap-ikev2]
Tschofenig, H., "EAP IKEv2 Method (EAP-IKEv2)",
draft-tschofenig-eap-ikev2-07 (work in progress),
July 2005.
[PRF] Adams, Carlisle et al., "On the Security of Key Derivation
Functions, LNCS 3225, Springer", 2004.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
Otto Expires April 9, 2006 [Page 19]
Internet-Draft The EAP-SKL protocol October 2005
Appendix A. T-PRF
The following description of T-PRF corresponds to [I-D.cam-winget-
eap-fast], Appendix A.
PRF(key, label, seed) = HMAC-SHA1(key, label + "\0" + seed)
Where '+' indicates concatenation and "\0" is a NULL character.
Label is intended to be a unique label for each different use of the
T-PRF.
To generate the desired OutputLength octet length of key material,
the T-PRF is iterated as follows:
T-PRF (Key, S, OutputLength) = T1 + T2 + T3 + T4 + ...
Where S = label + 0x00 + seed; and
T1 = HMAC-SHA1 (Key, S + OutputLength + 0x01)
T2 = HMAC-SHA1 (Key, T1 + S + OutputLength + 0x02)
T3 = HMAC-SHA1 (Key, T2 + S + OutputLength + 0x03)
T4 = HMAC-SHA1 (Key, T3 + S + OutputLength + 0x04)
OutputLength is a two octet value that is represented in big endian
order. The NULL character, 0x00 shall be present when a label string
is provided.
Since each Ti generates 20 byte of keying material, the last Tn is
truncated to accommodate the desired length specified by
OutputLength. EAP-SKL has to derive 128 byte, so i is set to 7 and
the last 12 byte are skipped.
Otto Expires April 9, 2006 [Page 20]
Internet-Draft The EAP-SKL protocol October 2005
Author's Address
Thomas Otto
TU Braunschweig
38106 Braunschweig
Germany
Phone:
Email: t.otto@tu-bs.de
Otto Expires April 9, 2006 [Page 21]
Internet-Draft The EAP-SKL protocol October 2005
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
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Otto Expires April 9, 2006 [Page 22]