One document matched: draft-bersani-eap-psk-00.txt
Internet Draft Florent Bersani
File: draft-bersani-eap-psk-00.txt France Telecom R&D
Expires: May 2004 January 2004
The EAP PSK Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document specifies an Extensible Authentication Protocol (EAP)
method for authentication and session key distribution using a pre-
shared key (PSK). The PSK is used by a unique underlying
cryptographic primitive, a block cipher, which is instantiated with
AES-128.
EAP-PSK performs mutual authentication and session key derivation. It
provides identity protection and shall provide fast reconnect in
future versions. It provides a secure communication channel within
EAP in case the authentication is successful. This secure channel can
be used to allow for instance protected result indications.
EAP-PSK is intended to be easy to deploy and well-suited for
authentication over insecure networks.
Bersani Expires - May 2004 [Page 1]
INTERNET-DRAFT EAP PSK January 2004
Table of Contents
1. Introduction...................................................4
1.1 Design goals for EAP-PSK...................................4
1.2 Caveats....................................................4
1.3 Specification of requirements..............................5
1.4 Terminology................................................5
1.5 Conventions................................................5
1.6 Related work...............................................6
2. Protocol Overview..............................................7
2.1 Cryptographic design of EAP-PSK............................7
2.1.1 The authentication............................. .....7
2.1.2 The key derivation................................ ..8
2.1.3 The protected channel............................. ..8
2.2 EAP-PSK Key hierarchy......................................9
2.2.1 The PSK.......................................... ...9
2.2.2 The TEK.......................................... ...9
2.2.3 The MSK.............................................10
2.2.4 The EMSK............................................10
2.2.5 The IV..............................................10
2.3 EAP-PSK message flow......................................10
2.3.1 EAP-PSK basic message flow..........................10
2.3.2 EAP-PSK advanced message flows......................11
2.4 Retry Behavior............................................12
2.5 Fragmentation.............................................12
3. EAP-PSK message format........................................12
3.1 Expected attributes by message............................12
3.2 Table of attributes Type field............................13
3.3 Format of different attributes............................13
3.3.1 AT-MAC..............................................13
3.3.2 AT-NOT..............................................14
3.3.3 AT-NTID.............................................14
3.3.4 AT-PCHANNEL.........................................15
3.3.5 AT-PIDREQ...........................................16
3.3.6 AT-PIDRES...........................................17
3.3.7 AT-RAND.............................................17
4. IANA considerations...........................................18
5. Security considerations.......................................18
5.1 Identity Protection.......................................18
5.2 Mutual Authentication.....................................19
5.3 Key Derivation............................................19
5.4 Dictionary Attacks........................................20
5.5 Protected channel.........................................20
5.6 Negotiation attacks.......................................20
5.7 Fast reconnect............................................20
5.8 Man-in-the-middle Attacks.................................20
5.9 Generating Random Numbers.................................21
6. Security claims...............................................21
7. Acknowledgements..............................................21
8. References....................................................22
9. Authors' Addresses............................................24
Bersani Expires û May 2004 [Page 2]
INTERNET-DRAFT EAP PSK January 2004
10. Full Copyright Statement.....................................24
Annex A: Work still to be done on this document..................24
1. Editorial..................................................24
2. Security...................................................25
3. Technical..................................................25
Annex B: Guidance for PSK generation from a password.............26
Bersani Expires û May 2004 [Page 3]
INTERNET-DRAFT EAP PSK January 2004
1. Introduction
1.1 Design goals for EAP-PSK
The Extensible Authentication Protocol, [EAP], provides a standard
mechanism for support of additional authentication methods within
[PPP]. EAP is also used within IEEE 802 networks through the [IEEE
802.1X] framework.
EAP supports many authentication mechanisms usually called EAP
methods. This document specifies an EAP method that uses a pre-shared
key (PSK).
Design goals for this method were:
1. Simplicity: It should be easy to implement and to deploy without
any pre-existing infrastructure.
2. Wide applicability: It should be possible to use this method to
authenticate over any network. In particular, it should be
suitable for [IEEE 802.11] wireless LANs and comply to [IEEE
802REQ]
3. Security: It should be conservative in its cryptographic design
and enjoy security proofs
4. Extensibility: It should be possible to complement this method
with the required extensions as their need appears
5. Patent-avoidance: It should be free of any IPR claims and its
specification should be released to the public domain
Thus EAP-PSK relies on a single cryptographic primitive, [AES], and
performs mutual authentication and session key derivation. It also
provides identity protection and shall provide fast reconnect in
future versions. It provides a secure communication channel within
EAP in case the authentication is successful. This secure channel can
be used to allow for instance protected result indications. It uses a
Type-Length-Value design to ensure that it will be easy to extend.
1.2 Caveats
Since PSK are of frequent use in security protocols, because a PSK
simply means a cryptographic key in the symmetric setting, attention
should be paid not to confuse EAP-PSK with any other protocols that
may also refer to a PSK, for instance [WPA] when used in its PSK
mode.
EAP-PSKÆs PSK should also not be confused with the PSKs possibly used
by other protocols relying on PSKs: EAP-PSKÆs PSK should be
cryptographically separated from any other PSK or else the security
of EAP-PSK might be voided.
The generation of the PSK used by EAP-PSK is outside of the scope of
this document. The PSK SHOULD be generated by a good source of
randomness (see [RFC 1750]). In particular, a PSK should not be
Bersani Expires û May 2004 [Page 4]
INTERNET-DRAFT EAP PSK January 2004
confused with a password. However, in case one wants to generate the
PSK from a password, although this is strongly discouraged, guidance
to do so is provided in annex A.
The definition of the repository of the PSK used by EAP-PSK is also
outside of the scope of the document. In particular, nothing prevents
from storing the PSK on a tamper-resistant device such as a smart
card rather than having it memorized or written down on a sheet of
paper.
1.3 Specification of requirements
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 [RFC 2219].
1.4 Terminology
This document frequently uses the following terms:
TBC
Backend Authentication Server
A backend authentication server is an entity that provides
an authentication service to an authenticator. When used,
this server typically executes EAP Methods for the
Authenticator. [This terminology is also used in
[IEEE 802.1X.].]
EAP Authenticator
The end of the EAP link initiating the EAP authentication
methods. [Note: This terminology is also used in
[IEEE 802.1X.], and has the same meaning in this
document].
EAP Peer (or simply Peer)
The end of the EAP Link that responds to the
authenticator. [Note: In [IEEE 802.1X], this end is
known as the Supplicant.]
EAP Server (or simply Server)
The entity that terminates the EAP authentication with the
peer. In the case where there is no Backend Authentication
Server, this term refers to the EAP Authenticator. Where
the EAP Authenticator operates in pass-through, it refers
to the Backend Authentication Server.
1.5 Conventions
All numbers involved in cryptographic calculations are considered in
network-byte order.
Bersani Expires û May 2004 [Page 5]
INTERNET-DRAFT EAP PSK January 2004
|| denotes concatenation of strings.
[String] denotes MAC of String calculated as specified by the
context.
** denotes integer exponentiation.
ôiö denotes the unsigned binary representation on 128 bits of the
integer I in network byte order. Therefore this notation only makes
sense when i is between 0 and 2**128-1.
1.6 Related work
There exist other EAP methods which also somehow rely on PSKs:
[EAP-SIM] and [EAP-AKA] are two of them, which do not directly
compete with EAP-PSK since they are designed to take advantage of the
GSM and UMTS infrastructure. There are therefore not easy to deploy
in case one does not dispose of such infrastructure.
EAP-MD5, described in [EAP], is another one, which has however been
deprecated for security reasons: it is not safe to use it over
insecure networks.
EAP-OTP, described in [EAP], and other One-Time Password methods such
as [EAP-SecurID] may also rely on PSKs but they also do not directly
compete with EAP-PSK since they require additional elements (e.g. the
One-Time password generator and server) on the client and on the
server side.
[LEAP] (Lightweight EAP) also known as EAP-Cisco Wireless is quite
similar to EAP-PSK. However it is a proprietary protocol that has
been shown to bear cryptographic weaknesses (see for instance
[LEAPVUL]).
[EAP-SKE] is quite similar to EAP-PSK. This method is still work in
progress and has put emphasis on network efficiency in roaming
situations. Work could be done to merge EAP-PSK and EAP-SKE.
[EAP-Archie] is very similar to EAP-PSK. This method is still work in
progress and has very much inspired this work. EAP-PSK makes
amendments to the cryptographic parts specified in EAP-Archie and
provides the protected channel and the TLV approach as new features.
Work could be done to merge EAP-PSK and EAP-Archie.
[EAP-SRP] is quite similar to EAP-PSK except that it uses both
symmetric and asymmetric cryptography and that it is subject to IPR
claims by Stanford university.
Bersani Expires û May 2004 [Page 6]
INTERNET-DRAFT EAP PSK January 2004
2. Protocol Overview
EAP-PSK is a native EAP method, that is a stand-alone version of EAP-
PSK outside of EAP is not defined.
2.1 Cryptographic design of EAP-PSK
EAP-PSK rely on a single cryptographic primitive, a block cipher,
which is instantiated with AES-128. This instantiation has been
chosen because:
1. AES-128 is standardized and its implementation are widely
available
2. AES-128 has been carefully reviewed by the community and is
believed to be secure
For a description of AES-128, please refer to [AES].
However, in case it should be needed, new instantiations of EAP-PSK
could easily be proposed as it does not intricately depend on the
chosen block cipher.
EAP-PSK uses three cryptographic parts:
1. An authentication protocol to mutually authenticate the
communicating parties, that follows the design presented in
[EAKD] under the name MAP1 instantiated with [OMAC] and [AES]
2. A key derivation protocol to derive keying material according to
the EAP Key Management Framework [EKMF], that uses the modified
counter mode presented in [SOBMMO]
3. An authenticated encryption protocol with associated data to
provide a protected channel for both mutually authenticated
parties to communicate securely within the method, that uses the
[EAX] mode of operation
2.1.1 The authentication
The authentication protocol used by EAP-PSK is the Mutual
Authentication Protocol 1.
The Mutual Authentication Protocol 1 (MAP1) is described in [EAKD].
It consists of a one and half round trip exchange:
Bersani Expires û May 2004 [Page 7]
INTERNET-DRAFT EAP PSK January 2004
B A
| |
| RA |
|<---------------------------------------------------------|
| |
| [B||A||RA|RB] |
|--------------------------------------------------------->|
| |
| [A||RB] |
|<---------------------------------------------------------|
where:
1. RA and RB are random numbers chosen respectively by A and B
2. A and B are A and B respective identities
EAP-PSK instantiates this protocol with:
1. RA and RB 128 bit random numbers chosen respectively by A and B
2. A and B are A and BÆs respective permanent full NAIs
3. The MAC algorithm used in [] is OMAC1 with AES-128 using KCK and
producing a tag length of 128 bits
2.1.2 The key derivation
The key derivation is realized using the modified counter mode.
The modified counter mode is described in [SOBMMO].
EAP-PSK instantiates this modified counter mode with all rotation
values (the ris following [SOBMMO] Figure 3 notation) taken equal to
zero (no rotations) and the counter values (the cis following
[SOBMMO] Figure 3 notation) taken respectively equal to the the first
t integers (that is ci=i, starting with c1).
The parameter t is taken equal to 4 across all key derivations.
The underlying block cipher used by this counter mode is AES-128.
The input block to the different key derivations (see next section
for EAP-PSKÆs key hierarchy) is taken to be:
1. [B||A||RA|RB||ö1ö] for the TEK derivation
2. [B||A||RA|RB||ö2ö] for the MSK derivation
3. [B||A||RA|RB||ö3ö] for the EMSK derivation
2.1.3 The protected channel
To provide a protected channel within EAP-PSK in case of a successful
authentication, EAP-PSK uses the EAX mode of operation described in
[EAX].
Bersani Expires û May 2004 [Page 8]
INTERNET-DRAFT EAP PSK January 2004
EAX is instantiated with AES-128 as the underlying block cipher keyed
with the 128 first bits of the TEK.
EAX is instantiated within EAP with a tag length of 128 bits.
The nonce N used by EAX (following [EAX] Figure 3 notation) is a
counter starting with ô0ö and incremented by the one at each
subsequent EAP-PSK message (except retransmissions of course) within
one EAP-PSK dialog. Thus, N can be considered a replay counter.
The message M used by EAX (following [EAX] Figure 3 notation)
consists of the message that one party wishes to send to the other
over the protected channel.
The header H used by EAX (following [EAX] Figure 3 notation) is
currently unused and is taken to be the Type field of the AT-PCHANNEL
attribute within which M is encapsulated (see EAP-PSK message format
section).
2.2 EAP-PSK Key hierarchy
This section instantiates the EAP Key hierarchy described in [EKMF]
for EAP-PSK.
2.2.1 The PSK
EAP-PSK uses a long-lived 256-bit secret shared between the EAP Peer
and the EAP Server called the PSK.
The PSK has an internal structure. It consists of one 128-bit subkey
and a 128-bit subkey, respectively called the key-confirmation key
(KCK) and the key-derivation key (KDK). The protocol uses the KCK to
mutually authenticate the EAP Peer and the EAP Server. The protocol
uses the KDK to derive keying material between the EAP Peer and the
EAP Server.
EAP-PSK assumes that the PSK is known only to the EAP Peer and EAP
Server, and the security properties of the protocol may be
compromised if it has wider distribution.
The protocol also assumes the EAP Server and EAP Peer identify the
correct PSK to use with the other by their respective [NAI]s.
2.2.2 The TEK
EAP-PSK allows for TEK derivation from the random values exchanged
during authentication and the KDK.
Bersani Expires û May 2004 [Page 9]
INTERNET-DRAFT EAP PSK January 2004
The TEK is a 128 bit key that MAY be used to set a protected channel
for both mutually authenticated parties to communicate securely
within the method.
2.2.3 The MSK
EAP-PSK allows for MSK derivation from the random values exchanged
during authentication and the KDK.
2.2.4 The EMSK
EAP-PSK allows for EMSK derivation from the random values exchanged
during authentication and the KDK.
2.2.5 The IV
EAP-PSK does not derive any IV.
2.3 EAP-PSK message flow
2.3.1 EAP-PSK basic message flow
Basically, EAP-PSK is comprised of four messages:
1. A first message sent by the server to the peer which starts the
mutual authentication procedure and essentially consists of a
random value chosen by the server
2. A second message sent by the peer to the server which contains a
random value chosen by the peer and an authentication tag over
both random values as well as the peer and serverÆs permanent
full NAIs that proves the identity of the peer to the server
3. A third message sent by the server to the peer that contains an
authentication tag calculated over the random value chosen by
the peer and the serverÆs permanent full NAI that proves the
identity of the server to the peer. This message may also
contain data encapsulated in a protected channel that has just
been set up as a result of the authentication procedure
4. A fourth message sent by the peer to the server that may also
contain data encapsulated in a protected channel that has just
been set up as a result of the authentication procedure
Bersani Expires û May 2004 [Page 10]
INTERNET-DRAFT EAP PSK January 2004
Peer Server
| |
| EAP-PSK/AT-RandS |
|<---------------------------------------------------------|
| |
| EAP-PSK/AT-RandP, AT-MAC |
|--------------------------------------------------------->|
| |
| EAP-PSK/AT-MAC, AT-PCHANNEL |
|<---------------------------------------------------------|
| |
| EAP-PKS/AT-PCHANNEL |
|--------------------------------------------------------->|
| |
This basic message flow could be comprised of only three messages,
were it not the request/response nature of EAP that prevents the
third message to be the last one. We take advantage of this situation
by mandating the setup of a protected channel over which result
indications must be sent.
2.3.2 EAP-PSK advanced message flows
EAP-PSK provides different advanced features that may lead to
different message flows:
1. Identity protection. This feature might add an additional
roundtrip to the basic message flow when used. This additional
round trip is inserted before the first message in the basic
flow when the peer and the server fall out of synchronization on
the pseudonym the peer MUST use to protect its identity. Hence,
when the server does not recognize the identity provided by the
peer in response to EAP-Request/Identity, the server sends a
message to the peer asking it to disclose its permanent
identity. The peer MAY respond to this message if his security
policy allows him to do so by sending his permanent identity.
The basic message flow then proceeds.
2. Fast reconnect. TBC
3. Conversation over the protected channel. This feature might add
some round trips to the basic message flow when used. These
additional round trips are inserted after the fourth message in
the basic message flow. They consist in exchanging data between
the peer and the server over the protected channel that has been
set thanks to the authentication. This protected data exchange
might for instance be of some use if the peerÆs account is pre
paid and his charged on a per packet or temporal basis: in case
the peer wants to top it up, he can do so, e.g. by making a
financial transaction with the server. This protected data
exchange might also be used to check the identity of the claimed
NAS that the peer has connected to.
Bersani Expires û May 2004 [Page 11]
INTERNET-DRAFT EAP PSK January 2004
2.4 Retry Behavior
EAP-PSK complies to the EAP retry behavior described in [EAP], that
is: the EAP Server is responsible for retry behavior. This means that
if the EAP Server does not receive a reply from the peer, it MUST
resend the EAP-Request for which it has not yet received an EAP-
Response. However, the EAP Peer MUST NOT resend EAP-Response messages
without first being prompted by the EAP Server.
As a result, it is possible that an EAP Peer will receive duplicate
EAP-Request messages, and may send duplicate EAP-Responses. Both the
EAP Peer and the EAP Server should be engineered to handle this
possibility.
2.5 Fragmentation
EAP-PSK does not support fragmentation or reassembly.
Therefore it is to be used either over networks which MTU is enough
to convey encapsulated EAP-Archie packets without fragmentation or
encapsulated in other protocols which take care of fragmentation and
reassembly.
3. EAP-PSK message format
3.1 Expected attributes by message
TBC
The first message received by the peer is either comprised of AT-
PIDREQ or AT-RAND.
In case it consists of AT-PIDREQ, the peer MAY then send a message
containing AT-PID or abort the conversation according to its identity
protection policy. If the peer send AT-PID, the conversation should
then proceed normally that is to say the server sends AT-RAND to the
peer f it has recognized its identity or abort the conversation if
not.
In case it consists of AT-RAND, the peer MUST send a response
containing its own AT-RAND along with AT-MAC calculated over the
fields specified in section 2.
The server then checks the validity of AT-MAC sent by the peer. If it
is a valid MAC, then the server sends a message containing its own
AT-MAC calculated over the fields specified in section 2 and AT-
PCHANNEL with at least an AT-Notification encapsulated to indicate to
the peer the success or failure of the authentication and
authorization. If it is not valid, the server MUST abort the
conversation.
Bersani Expires û May 2004 [Page 12]
INTERNET-DRAFT EAP PSK January 2004
The peer then checks the validity of the AT-MAC sent by the server.
If it is a valid MAC then the peer decapsulate the data contained in
AT-PCHANNEL. If it is not valid, the peer MUST discard the message
without further examination and abort the conversation.
The peer and the server MAY exchange further messages each containing
only an AT-PCHANNEL attribute. TBC.
3.2 Table of attributes Type field
TBC
Attribute Name Type Field Value
AT-RAND 1
AT-PIDREQ 2
AT-PIDRES 3
AT-MAC 4
AT-PCHANNEL 5
AT-NTID 6
3.3 Format of different attributes
This section presents the respective formats of the different
attributes listed in alphabetical order.
Within the different attribute formats, reserved bytes are specified.
These reserved bytes are essentially here for word alignment on 32
bit boundaries. They are set to zero when sending and ignored on
reception.
3.3.1 AT-MAC
The AT-MAC attribute is used for authentication within EAP-PSK.
The value field of the AT-MAC attribute contains two reserved bytes
followed by a keyed message authentication code (MAC). The MAC is
calculated over message-specific data.
The contents of the message-specific data that are MACed are
specified separately for each EAP/PSK message in Section 2.
The format of the AT-MAC attribute is shown below.
Bersani Expires û May 2004 [Page 13]
INTERNET-DRAFT EAP PSK January 2004
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-MAC | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the AT-MAC attribute is expected to be included in an EAP-PSK
message, the recipient MUST process the AT-MAC attribute before
looking at any other attributes.
If the message authentication code is absent or invalid, then the
recipient MUST ignore all other attributes in the message and operate
as specified in Section TBC.
3.3.2 AT-NOT
The format of the AT_NOT attribute 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-NOT | Length = 1 | Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains a two-byte notification.
code.
The different notification codes remain TBC.
3.3.3 AT-NTID
The format of the AT-NTID attribute is shown below.
Bersani Expires û May 2004 [Page 14]
INTERNET-DRAFT EAP PSK January 2004
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-NTID | Length | Actual Identity Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Identity :
: . :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use of the AT-NTID is defined in Section 2.
The value field of this attribute begins with 2-byte actual identity
length, which specifies the length of the identity in bytes. This
field is followed by the subscriber identity of the indicated actual
length.
The identity is the peer next temporary identity (i.e. pseudonym)
chosen by the server.
The identity does not include any terminating null characters.
Because the length of the attribute must be a multiple of 4 bytes,
the sender pads the identity with zero bytes when necessary.
3.3.4 AT-PCHANNEL
AT-PCHANNEL_is used to transmit information between the peer and
server over a protected channel, that is to say a channel that
provides confidentiality, data origin authentication and replay
protection.
The format of the AT-PCHANNEL attribute is shown below.
Bersani Expires û May 2004 [Page 15]
INTERNET-DRAFT EAP PSK January 2004
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-PCHANNEL | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Nonce |
| |
| |
|---------------------------------------------------------------|
| |
| Tag |
| |
| |
|---------------------------------------------------------------|
| |
| Payload |
: :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the AT-PCHANNEL attribute consists of one reserved
bytes followed by a 4 byte nonce, a 4 byte tag and a variable length
payload.
The payload consists in the ciphertext resulting from the encryption
in the EAX mode of operation of the information that the peer and the
server wish to exchange over the protected channel under Nonce and
the first 128 bits of the derived TEK (see Section 2.).
The information that the peer and the server may exchange over the
protected channel consists of a concatenation of EAP-PSK attributes
in the TLV format.
3.3.5 AT-PIDREQ
The format of the AT-PIDREQ attribute 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-PIDREQ | Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use of the AT-PIDREQ is defined in section 2.
Bersani Expires û May 2004 [Page 16]
INTERNET-DRAFT EAP PSK January 2004
3.3.6 AT-PIDRES
The format of the AT-PIDRES attribute 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-PIDRES | Length | Actual Identity Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Identity :
: . :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use of the AT-PIDRES is defined in Section 2.
The value field of this attribute begins with 2-byte actual identity
length, which specifies the length of the identity in bytes. This
field is followed by the subscriber identity of the indicated actual
length.
The identity is the peer permanent identity that is to the say the
peerÆs permanent NAI.
The identity does not include any terminating null characters.
Because the length of the attribute must be a multiple of 4 bytes,
the sender pads the identity with zero bytes when necessary.
3.3.7 AT-RAND
The format of the AT_RAND attribute 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_RAND | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| RAND |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the AT-RAND attribute contains two reserved bytes
followed by a 16 byte random number generated either by the peer or
the server freshly for this EAP-PSK authentication exchange. The
random numbers are used as a mean to authenticate and indirectly as a
seed value for the new keying material.
Bersani Expires û May 2004 [Page 17]
INTERNET-DRAFT EAP PSK January 2004
The server MUST choose a fresh RAND value and send it to the peer at
the beginning of the EAP-PSK exchange. The peer MUST also choose a
fresh RAND value and send it to the server at the beginning of the
EAP-PSK exchange.
The randomness of the RAND values are critical for the security of
EAP-PSK.
4. IANA considerations
This document introduces one new IANA consideration.
It requires IANA to allocate a new EAP Type for EAP-PSK.
5. Security considerations
The EAP base protocol [EAP] highlights several attacks that are
possible against the EAP protocol as there is no inherent security
mechanisms provided. This section discusses the claimed security
properties of EAP SIM as well as vulnerabilities and security
recommendations.
5.1 Identity Protection
EAP-PSK includes optional identity privacy support that protects the
privacy of the peer identity against passive eavesdropping.
The peer and the server SHOULD store the pseudonym in a non-volatile
memory so that it can be maintained across reboots.
An active attacker that impersonates the server may use the AT-PIDREQ
attribute to attempt to learn the peer's permanent identity.
However, itÆs a matter of policy for the peer to accept to respond to
such requests or not: the peer can refuse to send its permanent
identity if it believes that the server should be able to recognize
its temporary identity. If identity protection is a concern then the
peer MUST NOT send its permanent identity. Any other policy allows
identity protection compromise.
If the peer and server cannot guarantee that the pseudonym will be
maintained reliably and identity privacy is required then additional
protection from an external security mechanism such as Protected
Extensible Authentication Protocol (PEAP) [PEAP] may be used. If an
external security mechanism is in use the identity privacy features
of EAP-PSK may not be useful. The security considerations of using
an external security mechanism with EAP-PSK are beyond the scope of
this document.
Bersani Expires û May 2004 [Page 18]
INTERNET-DRAFT EAP PSK January 2004
It should also be kept in mind that the layers below EAP-PSK may
disclose elements that can lead to identity protection compromise
(e.g. the peerÆs [IEEE 802.3] Medium Access Control Address).
5.2 Mutual Authentication
EAP-PSK provides mutual authentication.
The server believes the peer is authentic because it can calculate a
valid MAC and the peer believes that the server is authentic because
it can calculate a correct MAC.
The authentication protocol used in EAP-PSK, MAP1, enjoys a security
proof in the provable security paradigm, see [EAKD].
The MAC algorithm used in the instantiation of MAP1 within EAP-PSK,
OMAC1, also enjoys a security proof in the provable security
paradigm, see [OMAC].
The underlying block cipher used, AES-128, is widely believed to be a
secure block cipher.
Finally, the key used for mutual authentication, KCK, is only used
for that purpose, making thus this part cryptographically independent
of the other parts.
5.3 Key Derivation
EAP-PSK supports key derivation.
The key hierarchy is specified in Section 2.
The mechanism used for key derivation is the modified counter mode.
The instantiation of the modified counter in EAP-PSK (i.e. the
selected ris and cis) comply with the conditions stated in [SOBMMO]
so that the security proof in the provable security paradigm of
[SOBMMO] holds.
The underlying block cipher used, AES-128, is widely believed to be a
secure block cipher.
The key derivation mechanism uses two different keys KDK1 and KDK2:
1. KDK1 is used to produce the input blocks that are fed to the
modified counter mode
2. KDK2 is used in the modified counter mode to expand the input
blocks
Bersani Expires û May 2004 [Page 19]
INTERNET-DRAFT EAP PSK January 2004
The input blocks are produced from the MAC sent by the peer during
the authentication part of EAP-PSK so that neither the peer nor the
server have full control over them, since this MAC is calculated over
fields that include random values chosen respectively by the peer and
the server. The input blocks are believed to be cryptographically
separated from one another because they are produced as MAC of
distinct messages (see section 2) and the MAC algorithm used (OMAC1)
is proved to be a secure PRF if the underlying block cipher is a
secure PRP, see [OMAC].
The key derivation scheme is believed to be secure since the modified
counter mode is proved to be a PRF if the underlying block cipher is
a secure PRP.
5.4 Dictionary Attacks
Because EAP-PSK is not a password protocol, it is not vulnerable to
dictionary attacks: EAP-PSKÆs PSK MUST NOT be derived from a
password. Derivation of EAP-PSKÆs PSK may lead to dictionary attacks.
In case, EAP-PSKÆs PSK is however derived from a password, guidance
is provided in Annex A how to do so. It is also believed that MAP1
makes dictionary attacks harder, since the first value that is MACed
should not be predictable neither for the peer nor the server or
anybody else.
5.5 Protected channel
EAP-PSK provides a protected channel over which the peer and the
server can securely exchange information, in case of a successful
authentication.
This protected channel provides confidentiality, data origin
authentication, replay protection and confirmation of the end of the
conversation.
5.6 Negotiation attacks
EAP-PSK does not protect from negotiation attacks since it currently
does not provide version negotiation as only one version is
specified.
5.7 Fast reconnect
EAP-PSK shall provide fast reconnect. TBC.
5.8 Man-in-the-middle Attacks
Due to the use of symmetric cryptography and the security proofs of
its cryptographic components, EAP-PSK is believed not to be
vulnerable to man-in-the-middle attacks.
Bersani Expires û May 2004 [Page 20]
INTERNET-DRAFT EAP PSK January 2004
There are man-in-the-middle attacks associated with the use of any
EAP method within a tunneled protocol such as PEAP, or within a
sequence of EAP methods followed by each other (see [MTAP]). This
specification does not address these attacks. If EAP-PSK is used with
a tunneling protocol or as part of a sequence of methods, there
should be cryptographic binding provided between the protocols and
EAP-PSK to prevent man-in-the-middle attacks. However the mechanism
how the binding is provided is beyond the scope of this document.
5.9 Generating Random Numbers
An EAP-PSK implementation SHOULD use a good source of randomness to
generate the random numbers required in the protocol. Please see [RFC
1750] for more information on generating random numbers for security
applications.
6. Security claims
This section provides the security claims required by [EAP].
[a] Intended use. EAP-PSK is intended for use over both physically
insecure networks and physically or otherwise secure networks.
Applicable media include but are not limited to PPP, IEEE 802 wired
networks and IEEE 802.11.
[b] Mechanism. EAP-PSK is based on symmetric cryptography and uses a
384 bit Pre-shared Key
[c] Security claims. The security properties of the method are
discussed in Section 5.
[d] Key strength. EAP-PSK supports key derivation with 128-bit
effective key strength.
[e] Description of key hierarchy. Please see Section 2.
[f] Indication of vulnerabilities. Vulnerabilities are discussed in
Section 5.
7. Acknowledgements
This EAP method has been inspired by [EAP-SIM] and [EAP-Archie]. It
also considerably reused extracts of these documents. Many thanks to
their respective authors.
Many thanks to Laurent Butti, J‰rŸme Razniewski and Olivier Charles
for their feedback on this document.
Bersani Expires û May 2004 [Page 21]
INTERNET-DRAFT EAP PSK January 2004
8. References
[AES] Federal Information Processing Standards (FIPS)
Publication 197, " Specification for the Advanced
Encryption Standard (AES)", National Institute of
Standards and Technology, November 26, 2001.
[PPP] Simpson, W., Editor, "The Point-to-Point Protocol
(PPP)", STD 51, RFC 1661, July 1994.
[EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[EAP-AKA] Arkko, J. Haverinen, H., ôEAP AKA Authenticationö,
Internet-Draft (work in progress), October 2003,
draft-arkko-pppext-eap-aka-11.txt
[EAP-Archie] Walker, J. and Housley, R., ôThe EAP Archie Protocolö,
Internet-Draft (work in progress), June 2003, draft-
jwalker-eap-archie-01.txt,
[EAP-SecurID] Josefsson, S., ôThe EAP SecurID(r) Mechanismö,
Internet-Draft (work in progress), February 2002,
draft-josefsson-eap-securid-01.txt
[EAP-SIM] Haverinen, H. Salowey, J., "EAP SIM Authentication",
Internet-Draft (work in progress),October 2003, draft-
haverinen-pppext-eap-sim-12.txt
[EAP-SKE] Salgarelli, L., ôEAP SKE authentication and key
exchange protocolö, Internet-Draft (work in progress),
May 2003, draft-salgarelli-pppext-eap-ske-03.txt
[EAP-SRP] Carlson, J. et al., ôEAP SRP-SHA1 Authentication
Protocolô,Internet-Draft (work in progress), draft-
ietf-pppext-eap-srp-04.txt
[EAKD] Bellare, M, and P. Rogaway, "Entity Authentication and
Key Distribution", CRYPTO 93, LNCS 773, pp232-249,
Springer-Verlag, Berlin, 1994.
[EKMF] Aboba, B., et al., "EAP Key Management Framework",
draft-ietf-eap-keying-01.txt, October 2003
[HAC] Menezes, A. et al., ôHandbook of Applied Cryptographyö,
CRC Press, 1996.
[IEEE 802.1X] IEEE STD 802.1X, Standards for Local and Metropolitan
Area Networks: Port Based Access Control, June 14, 2001
Bersani Expires û May 2004 [Page 22]
INTERNET-DRAFT EAP PSK January 2004
[IEEE 802.3] Institute of Electrical and Electronics Engineers,
"Information Technology - IEEE Standard for Information
technology--Telecommunications and information exchange
between systems--Local and metropolitan area networksù
Specific requirements--Part 3: Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method
and Physical Layer Specificationsö
[IEEE 802.11] Institute of Electrical and Electronics Engineers,
"Information Technology - Telecommunications and
Information Exchange between Systems - Local and
Metropolitan Area Network - Specific Requirements û
Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE Standard
802.11
[IEEE 802REQ] Stanley, Dorothy et al., ôEAP Method Requirements for
Wireless LANsö, Internet-Draft (work in progress),
January 2004, draft-walker-ieee802-req-00.txt
[LEAP] Macnally, C., ôCisco LEAP protocol descriptionö,
September 2001
[LEAPVUL] Wright, J., ôWeaknesses in LEAP Challenge/Responseö,
Defcon 2003
[MTAP] Asokan, N. et al., ôMan-in-the-middle in Tunnelled
Authentication Protocolsö,
http://eprint.iacr.org/2002/163
[NAI] Aboba, B., and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[OMAC] Iwata, T., and Kurosawa., K., ôOMAC: One-Key CBC MACö
Fast Software Encryption, FSE 2003, LNCS, Springer-
Verlag.
[PEAP] Palekar, A. et al., ôProtected EAP Protocol (PEAP)ö,
Internet-Draft (work in progress), October 2003, draft-
josefsson-pppext-eap-tls-eap-07.txt
[PKCS5] RSA laboratories, ôPKCS #5 v2.0: Password-Based
Cryptography Standardö
[PWD] National Institute of Standards and Technology (NIST).
ôFIPS PUB 112: Password Usageö. May 30, 1985.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December
1994.
Bersani Expires û May 2004 [Page 23]
INTERNET-DRAFT EAP PSK January 2004
[RFC 2219] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SOBMMO] Gilbert, H., ôThe Security of One-Block-to-Many Modes
of Operationö, Fast Software Encryption, FSE 2003,
LNCS, Springer-Verlag.
[WPA] Wi-Fi Alliance, ôWi-Fi Protected Accessö, version 2.0,
April 2003
9. Authors' Addresses
Florent Bersani florent.bersani@francetelecom.com
France Telecom R&D
38, rue du G‰n‰ral Leclerc
92794 Issy Les Moulineaux Cedex 9
France
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Annex A: Work still to be done on this document
1. Editorial
Bersani Expires û May 2004 [Page 24]
INTERNET-DRAFT EAP PSK January 2004
Clarify the conventions on the cryptographic calculations.
Make this draft more self-contained.
Complete the cross-references in the text (page, section, reference
numbers)
Harmonize the terminology (e. g. octets or bytes)
Complete the terminology section (e.g. with temporary identity)
Number the figures
2. Security
Study alternative ways to produce the input blocks to the key
derivation procedure.
Is it possible to use the KCK to produce the input blocks to the key
derivation without endangering the security properties of the
protocol?
Specify the mechanism to prevent abrupt ending of the conversation on
the protected channel.
Discuss use of other cryptographic algorithms
Discuss the choice of AES-128-128 and OMAC1 and a tag length of 128
bits (e.g. should the tag be truncated or not,à).
Study DOS attacks resistance
3. Technical
Discuss possibility to enhance network efficiency by removing the
additional identity protection message requesting the permanent
identity and replacing it with a query attribute included in the
first message of the basic message flow.
Specify how fast reconnect should be implemented
Introduce version negotiation
Is it desirable to have all attributes aligned on 32 bit boundaries?
Harmonize with other standards or draft standards (e. g. EAP and EAP
Key management framework)
Specify all that remain TBC, e.g. the different notification
messages.
Bersani Expires û May 2004 [Page 25]
INTERNET-DRAFT EAP PSK January 2004
Annex B: Guidance for PSK generation from a password
It is formally discouraged to use a password to generate a PSK, since
this commonly lead to exhaustive search or dictionary attacks that
would not otherwise be possible.
However, we provide guidance on how to generate the PSK from a
password.
Guidance on how passwords should be selected is provided in [PWD].
The technique presented herein is drawn from [PKCS5]. It is intended
to mitigate the risks associated with password usage in cryptography,
typically dictionary attacks.
If the binary representation in ASCII of the password is strictly
fewer than 128 bit long (which by the way means that the chosen
password is probably weak because it is too short) then its is padded
to 128 bits with zeroes.
If the binary representation in ASCII of the password is strictly
more than 128 bit long, then it is hashed down to exactly 128 bit
using the Matyas-Meyer-Oseas hash (see [HAC]) with
IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has been
arbitrarily selected).
We now assume that we have a 128 bit number derived from the initial
password (that can be the password itself if its binary
representation in ASCII is exactly 128 bit long). We shall call this
number P128.
EAP-PSKÆs PSK is derived thanks to PBKDF2 instantiated with
(following the notations in [PKCS5]):
1. P128 as P
2. The first 96 bits of the binary ASCII representation of the
peerÆs NAI as Salt (therefore before using a password within
EAP-PSK, two parties should agree as to whom is the peer and
whom is the server for the procedure described in this annex).
3. 5000 as c
4. 48 as dkLen
Bersani Expires û May 2004 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-23 09:08:19 |