[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4764

   Internet Draft                                       Florent Bersani
   File: draft-bersani-eap-psk-01.txt                France Telecom R&D
   Expires: August 2004                                   February 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 derivation using a pre-
   shared key (PSK). This 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 designed to be itself extensible.
   EAP-PSK is intended to be easy to deploy and well-suited for
   authentication over insecure networks such as IEEE 802.11.






Bersani                  Expires ¡ August 2004                [Page 1]

INTERNET-DRAFT                 EAP PSK             February 2004 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.................................................7
     1.6 Related work................................................7
   2. Protocol overview..............................................8
     2.1 Cryptographic design of EAP-PSK.............................8
          2.1.1 The authentication...................................8
          2.1.2 The key derivation...................................9
          2.1.3 The protected channel...............................10
     2.2 EAP-PSK key hierarchy......................................11
          2.2.1 The PSK.............................................11
          2.2.2 The TEK.............................................11
          2.2.3 The MSK.............................................12
          2.2.4 The EMSK............................................12
          2.2.5 The IV..............................................12
     2.3 EAP-PSK message flow.......................................12
          2.3.1 EAP-PSK basic message flow..........................12
          2.3.2 EAP-PSK advanced message flows......................13
     2.4 Retry behavior.............................................14
     2.5 Fragmentation..............................................14
   3. EAP-PSK state machines........................................15
     3.1 EAP-PSK peer state machine.................................15
          3.1.1 The Init state......................................15
          3.1.2 The ID_sent state...................................16
          3.1.3 The MAC_sent state..................................17
          3.1.4 The P_Channel state.................................17
          3.1.5 The Failure state...................................18
          3.1.6 The Success state...................................18
     3.2 EAP-PSK server state machine...............................18
          3.2.1 The Init state......................................19
          3.2.2 The ID_req state....................................19
          3.2.3 The MAC_req state...................................20
          3.2.4 The P_channel state.................................21
          3.2.5 The Failure state...................................21
          3.2.6 The Success state...................................21
   4. EAP-PSK message format........................................22
     4.1 Table of the Type field of the different attributes........22
     4.2 Format of the different attributes.........................22
          4.2.1 AT_IDREQ............................................22
          4.2.2 AT_IDRES............................................22
          4.2.3 AT_MAC..............................................23
          4.2.4 AT_PCHANNEL.........................................24
          4.2.5 AT_RAND.............................................25
          4.2.6 AT_STATUS...........................................25


Bersani                  Expires ¡ August 2004                [Page 2]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   5. IANA considerations...........................................26
   6. Security considerations.......................................26
     6.1 Identity protection........................................26
     6.2 Mutual authentication......................................27
     6.3 Key derivation.............................................27
     6.4 Dictionary attacks.........................................28
     6.5 Protected channel..........................................28
     6.6 Negotiation attacks........................................28
     6.7 Fast reconnect.............................................28
     6.8 Man-in-the-middle attacks..................................28
     6.9 Generating random numbers..................................29
   7. Security claims...............................................29
   8. Intellectual Property Right Notice............................29
   9. Acknowledgements..............................................30
   10. References...................................................30
     10.1 Normative.................................................30
     10.2 Informative...............................................31
   11. Authors' Addresses...........................................33
   12. Full Copyright Statement.....................................33
   Annex A: Work still to be done on this document..................33
     1. Editorial...................................................33
     2. Security....................................................34
     3. Technical...................................................34
   Annex B: Guidance for PSK generation from a password.............35




























Bersani                  Expires ¡ August 2004                [Page 3]

INTERNET-DRAFT                 EAP PSK             February 2004 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 add to this method the
        required extensions as their need appears
     5. Patent-avoidance: It should be free of any Intellectual Property
        Right claims

   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. This design is quite analogous to the attribute format used
   in [EAP-SIM] or the TLV suggested in [EAP-TLV]. Some of these TLVs
   may be encapsulated in a protected channel (which is itself
   implemented as a dedicated TLV), quite similarly to the ideas
   presented in [PEAP-TLV].

1.2 Caveats

   Since PSK are of frequent use in security protocols, because a PSK
   simply means a cryptographic key in the symmetric cryptographic
   setting (see e.g. [HAC] for an introduction to symmetric vs.
   asymmetric cryptography), 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.


Bersani                  Expires ¡ August 2004                [Page 4]

INTERNET-DRAFT                 EAP PSK             February 2004 2004



   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. It is a rule of the thumb in cryptography
   to use different keys for different applications.

   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
   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 B.

   The definition of the repository of the PSK used by EAP-PSK is also
   outside of the scope of this document. In particular, nothing
   prevents from storing EAP-PSK's PSK on a tamper-resistant device such
   as a smart card rather than having it memorized or written down on a
   sheet of paper. Indeed such a storage on a smart card might allow to
   choose stronger credentials and to avoid their duplication (that is
   to say, for instance, preventing a user from easily sharing its PSK
   with somebody else).

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

   TBC

   This document frequently uses the following terms:

   AES
             Advanced Encryption Standard, a block cipher, please refer
             to [AES] for more details

   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 (or simply Authenticator)
             The end of the EAP link initiating the EAP authentication
             methods. [Note: This terminology is also used in


Bersani                  Expires ¡ August 2004                [Page 5]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


             [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.


   MAC
             Message Authentication Code. Informally, the purpose of a
             MAC is to facilitate, without the use of any additional
             mechanisms, assurances regarding both the source of a
             message and its integrity, please refer to [HAC] for more
             details

   MAP
             Mutual Authentication Protocol. The name of a family of
             protocols that allow mutual authentication and that are
             specified in [EAKD]

   OMAC
             One Key CBC-MAC, a method to generate a message
             authentication code, please refer to [OMAC] for more
             details

   PSK
             Pre-shared key. A pre-shared key is a cryptographic key in
             the symmetric setting that is derived by some out-of-band
             mechanism. It is merely a sequence of binary digits of
             given length that should have been chosen at random.

   PRF
             Pseudo-random function. Please refer for instance to [EAX]
             for a precise cryptographic definition of this term

   PRP
             Pseudo-random permutation. Please refer for instance to
             [EAX] for a precise cryptographic definition of this term

   Temporary Identity
             A temporary identity, contrary to a permanent identity, is


Bersani                  Expires ¡ August 2004                [Page 6]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


             a NAI that the user uses a pseudonym for one EAP dialog.
             This features is used for identity protection. It is the
             server's responsibility to provide the peer with temporary
             identities in case identity protection is required.

1.5 Conventions

   All numbers involved in cryptographic calculations are considered in
   network-byte order.

   || denotes concatenation of strings.

   [String] denotes the 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 infrastructures. There are therefore not easy to deploy
   in case one does not dispose of such infrastructures.

   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.



Bersani                  Expires ¡ August 2004                [Page 7]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   [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 different of EAP-PSK except since it uses both
   symmetric and asymmetric cryptography and it is subject to IPR claims
   by Stanford university.

2. Protocol overview

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 implementations 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. The only parameters of the block cipher that
   EAP-PSK depends on are its block size (128 bits) and its key size
   (128 bits).

   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].



Bersani                  Expires ¡ August 2004                [Page 8]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   It consists of a one and half round trip exchange:

         Bob                                                       Alice
          |                                                          |
          |                           RA                             |
          |<---------------------------------------------------------|
          |                                                          |
          |                     [B||A||RA||RB]                       |
          |--------------------------------------------------------->|
          |                                                          |
          |                        [A||RB]                           |
          |<---------------------------------------------------------|

   where:

     1. RA and RB are random numbers chosen respectively by Alice and
        Bob
     2. A and B are Alice's and Bob's respective identities

   EAP-PSK instantiates this protocol with:

     1. RA and RB 128 bit random numbers chosen respectively by Alice
        and Bob
     2. A and B are Alice's and BobÆs respective permanent full NAIs. It
        was chosen to include their permanent full NAIs in the
        calculation of the MAC (and not the temporary NAIs they may be
        using in case identity protection is enabled) to avoid getting
        out of the setting of the security proof of [EAKD]. Choosing to
        use the permanent full NAIs may possibly endanger identity
        protection (though there doesn't seem to be any trivial attack
        taking advantage of this) but since mutual authentication has a
        security proof and identity protection currently does not, it
        seems reasonable to preserve the existing security proof. [EAKD]
        was chosen for historical reasons (since EAP-PSK was very much
        influenced by EAP-Archie, please refer to section 9) and because
        this scheme enjoyed a security proof.
     3. The MAC algorithm we use is OMAC1 with AES-128 using a 128-bit
        portion of the PSK called AK (see section 2.2) and producing a
        tag length of 128 bits. OMAC was chosen because of its handling
        of arbitrary length messages and its design simplicity (though
        some care must be taken in its implementation to avoid side
        channel attacks, please refer to [EAX]). It also enjoys a
        security proof, which has so far not been found to be flawed and
        is believed to have been extensively reviewed by the
        cryptographic community.

2.1.2 The key derivation

   The key derivation is realized using the modified counter mode.


Bersani                  Expires ¡ August 2004                [Page 9]

INTERNET-DRAFT                 EAP PSK             February 2004 2004



   The modified counter mode is described in [SOBMMO]. This mode was
   chosen because it seems to be one of the rare simple key derivation
   schemes that relies on a block cipher and has a proof of its
   security.

   EAP-PSK instantiates this modified counter mode with all rotation
   values (the ri following [SOBMMO] Figure 3 notation) taken equal to
   zero (no rotations) and the counter values (the ci following [SOBMMO]
   Figure 3 notation) taken respectively equal to the first t integers
   (that is ci=i, starting with i=1).

   The parameter t is taken equal to 9.

   The underlying block cipher used by this counter mode is AES-128.

   The input block to the key derivation is taken to be: [B||A||RA|RB]
   as per section 2.1.1 notation.

   For what regards the output blocks:
     1. The first output block of the key derivation is taken to be the
        TEK
     2. The second to fifth output blocks of the key derivation are
        taken to be the MSK
     3. The sixth to ninth output blocks of the key derivation are taken
        to be the EMSK

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].

   EAX is instantiated with AES-128 as the underlying block cipher keyed
   with the TEK.

   EAX is instantiated within EAP-PSK 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 (i.e a concatenation of EAP-PSK
   attributes).





Bersani                  Expires ¡ August 2004               [Page 10]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   The header H used by EAX (following [EAX] Figure 3 notation) is
   currently unused and thus taken to be the empty string.

   EAX was mainly chosen because it strongly relied on OMAC in its
   design and OMAC had already been chosen in EAP-PSK for the
   authentication part. It was also chosen because of the simplicity of
   its design and the security proof it enjoys. It should however be
   understood that there are currently many other proposed modes for
   authenticated encryption with associated data (including IPR free
   ones, like CCM, CWC or GCM, please refer to [MOSKBC] for more
   details) and that the complexity and novelty of EAX security proof
   may be a concern.

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 two 128-bit
   subkeys, respectively called the authentication key (AK) and the key-
   derivation key (KDK). The protocol uses the AK 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. It should be emphasized that EAP-PSK assumes that AK and KDK
   are cryptographically separated and that its security proof rely on
   this assumption. In case, EAP-PSK's PSK is drawn at random from the
   set of possible keys, this assumption is verified.

   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 a MAC exchanged during
   authentication and the KDK.

   The TEK is a 128 bit key that is used to set a protected channel for
   both mutually authenticated parties to communicate securely within
   the method.



Bersani                  Expires ¡ August 2004               [Page 11]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


2.2.3 The MSK

   EAP-PSK allows for MSK derivation from a MAC exchanged during
   authentication and the KDK.

   As specified in [EKMF], the MSK is 64 bytes long.

2.2.4 The EMSK

   EAP-PSK allows for EMSK derivation from a MAC exchanged during
   authentication and the KDK.

   As specified in [EKMF], the EMSK is 64 bytes long.

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 six messages (i.e. three round
   trips):
     1. The first message is sent by the server to the peer to request
        its identity
     2. The second message is sent by the peer to the server to answer
        the identity request: the peer indicates its identity (temporary
        or permanent) to the server
     3. The third message is sent by the server to the peer and starts
        the mutual authentication procedure: it essentially consists of
        a random value chosen by the server
     4. The fourth message is sent by the peer to the server and
        contains a random value chosen by the peer and an authentication
        tag calculated by the peer over both random values as well as
        the peer and serverÆs permanent full NAIs to prove the identity
        of the peer to the server
     5. The fifth message is sent by the server to the peer and contains
        an authentication tag calculated over the random value chosen by
        the peer and the serverÆs permanent full NAI to prove 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. This
        data at least serves to make sure that the protected channel was
        correctly set up and to give indications on the probable future
        decision of the server. It may also be used to give to the peer
        the next temporary identity it should use.





Bersani                  Expires ¡ August 2004               [Page 12]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


     6. The sixth message is sent by the peer to the server and may also
        contain data encapsulated in a protected channel that has just
        been set up as a result of the authentication procedure

        Peer                                                      Server
          |                                       EAP-PSK/AT_IDREQ   |
          |<---------------------------------------------------------|
          |                                                          |
          |   EAP-PSK/AT_IDRES                                       |
          |--------------------------------------------------------->|
          |                                                          |
          |                                        EAP-PSK/AT_Rand   |
          |<---------------------------------------------------------|
          |                                                          |
          |   EAP-PSK/AT_Rand, AT_MAC                                |
          |--------------------------------------------------------->|
          |                                                          |
          |                            EAP-PSK/AT_MAC, AT_PCHANNEL   |
          |<---------------------------------------------------------|
          |                                                          |
          |   EAP-PSK/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.

   The basic message flow also include a fresh query by the server of
   the peer's identity, since the current revision of EAP ([EAPbis])
   recommends to do so in its section 5.1.

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 after the second message in the basic
        flow when the peer and the server fall out of synchronization on
        the pseudonym the peer uses to protect its identity. Hence, when
        the server does not recognize the identity provided by the peer
        in response to EAP-PSK/AT_IDREQ, the server sends a message to
        the peer asking it to disclose its permanent identity. The peer
        MAY respond to this message if its security policy allows him to
        do so by sending its permanent identity or by resending its




Bersani                  Expires ¡ August 2004               [Page 13]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


        temporary identity or it MAY not respond to this request. 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 sixth 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 up thanks to the authentication. This protected data
        exchange might for instance be of some use if the peerÆs account
        is pre paid and is charged on a per packet or temporal basis: in
        case the peer wants to top it up, it 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
        Authenticator that the peer has connected to. In each message
        exchanged over the protected channel, both parties indicate
        whether the exchange has to continue, may continue or is done
        for them and what their current decision is (unconditional
        success, conditional success or failure). These indications
        mimic the variables presented in [EAP-SM]

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-PSK packets without fragmentation or
   encapsulated in other protocols which take care of fragmentation and
   reassembly.

   However, in case it is needed, fragmentation support might well be
   provided for communication over the protected channel thanks to, for
   instance, an AT_Fragment attribute.





Bersani                  Expires ¡ August 2004               [Page 14]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


3. EAP-PSK state machines

   This section is TBC

   The state diagrams given below are simplistic. Their goal is to give
   a compact description of EAP-PSK.

   Due to its TLV design (i.e. attribute usage), this document only
   specifies the attributes that MUST be included in the requests or
   responses. Though it does not forbid adding other non-mandatory
   attributes, the peer and the server SHOULD for now ignore any non-
   mandatory attribute that are not encapsulated in the AT_PCHANNEL
   attribute.

3.1 EAP-PSK peer state machine

       +-----------+    +-----------+       +-----------+
       |           |    |           |<--+   |           |
   --->|   Init    |--->|  ID_sent  |   |   |  Failure  |<----+
       |           |    |           |---+-->|           |     |
       +-----------+    +-----------+   |   +-----------+     |
                                        |                     |
                                        |                     |
                        +-----------+   |                     |
                        |           |<--+                     |
   +--------------------|  MAC_sent |                         |
   |                    |           |-------------------------+
   |                    +-----------+                         |
   |                                                          |
   +--------------------------+-------------------------------+
   |                          |
   |   +-----------+          |             +-----------+
   |   |           |          |             |           |
   +-->| P_Channel |----------+------------>|  Success  |
       |           |                        |           |
       +-----------+                        +-----------+


3.1.1 The Init state

   The peer starts in the Init state: in this state it awaits the first
   EAP-PSK request of the EAP server. This first request MUST be an EAP-
   PSK packet containing at least one attribute: the AT_IDREQ attribute.
   The peer MUST silently discard any EAP-PSK packet that does not
   contain the AT_IDREQ attribute. If identity protection is a concern,
   the server SHOULD NOT request the peer's permanent identity.

   Upon reception of an EAP-PSK packet that contains the AT_IDREQ
   attribute, depending on the flag set in this attribute, the


Bersani                  Expires ¡ August 2004               [Page 15]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   identities the peer currently has and its security policy the peer
   has three options:
     1. Provide the requested identity if it is able to do so (e.g. if
        it hasn't lost its current temporary identity) and if its
        security policy doesn't prevent him from doing so (e.g. if the
        server directly request the peer's permanent identity, which the
        peer is configured never to disclose)
     2. Provide its permanent identity if its security policy allows him
        to do so, whatever the identity requested by the server was
     3. Silently discard the received packet if the peer cannot or
        doesn't want to answer until either the peer or the server fails
        (for instance due to time out or retry counter or retry counter
        limit) or it receives a packet it can and wants to answer to.
   If the peer chooses option #1 or option #2, it sends the
   corresponding response (i.e. an EAP-PSK packet that MUST contain the
   AT_IDRES attribute) and its EAP-PSK method state moves to ID_send

3.1.2 The ID_sent state

   In this state the peer MAY receive two different types of EAP-PSK
   packets:
     1. An EAP-PSK packet that contains an AT_IDREQ attribute
     2. An EAP-PSK packet that contains an AT_RAND attribute

   For now the two situations described above SHOULD be considered to be
   mutually exclusive (i.e. if the peer receives an EAP-PSK packet that
   contains both AT_IDREQ and AT_RAND attributes), it SHOULD silently
   discard it. However, this point, as much of this document is open to
   discussion and may evolve (see Annex A).

   In case it receives an EAP-PSK packet that contains an AT_IDREQ
   attribute, the peer has the same options as when it received an EAP-
   PSK packet containing and AT_IDREQ attribute while in the Init state.
   The only difference, is that the peer knows that the identity it has
   already sent seems not to have been recognized by the server. [Note:
   the state machine diagram however indicates that in case the peer
   wants then to take option #3 of the Init state while in the ID_sent
   state, it also can go directly to the Failure state without waiting
   for time outs or retry counter limits, this behavior is open to
   discussion, see annex A]. In this situation the peer either stays in
   the ID_sent state or moves to the Failure state.

   In case it receives an EAP-PSK packet that contains an AT_RAND
   attribute, the peer builds an EAP-PSK packet in response that MUST
   contain an AT_MAC attribute and an AT_RAND attribute and moves on to
   the MAC_sent state. To build this AT_MAC, it begins by choosing
   himself a 128 random value, which will be the value of the AT_RAND
   attribute that the peer MUST include in its response. The value of




Bersani                  Expires ¡ August 2004               [Page 16]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   the AT_MAC attribute is then computed according to the following
   formula (please see also section 2.1.1):

                              [B||A||RA||RB]

   where:
     o B stands for the ASCII encoding of the permanent full NAI of the
        peer
     o A stands for the ASCII encoding of the permanent full NAI of the
        server
     o RA stands for the value of the AT_RAND the peer has just
        received
     o RB stands for the random value the peer has just chosen to build
        the AT_RAND it must include in its response

3.1.3 The MAC_sent state

   In this state, the peer MUST receive an EAP-PSK packet that contains
   an AT_MAC attribute and an AT_PCHANNEL attribute.

   Upon reception of an EAP-PSK packet that contains an AT_MAC attribute
   and an AT_PCHANNEL attribute, the peer MUST start by processing the
   AT_MAC attribute. It MUST verify that the value of this attribute is
   equal to the value given by the following formula (please see also
   section 2.1.1):

                                  [A||RB]

   where:
     o A stands for the ASCII encoding of the permanent full NAI of the
        server
     o RB stands for the value of the AT_RAND attribute that the peer
        has just sent to the server

   In case, this verification succeeds the peer moves to the P_channel
   state to process the AT_PCHANNEL attribute. In case, it fails the
   peer moves to the Failure state.

3.1.4 The P_Channel state

   In this state, the peer only processes EAP-PSK messages that contain
   an AT_PCHANNEL attribute. Furthermore, the AT_PCHANNEL MUST be the
   only attribute that the peer processes.

   While processing an AT_PCHANNEL attribute, the peer MUST first check
   the replay counter (see section 2.1.3). If the replay counter
   verifies (that is to say is equal to the value of the last counter
   sent incremented by one starting with a counter value of 0), the peer
   then decrypts the value of the attribute AT_PCHANNEL and processes


Bersani                  Expires ¡ August 2004               [Page 17]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   the attributes encapsulated within. Any EAP-PSK packet that fails to
   verify the replay counter or decrypt the value of the AT_PCHANNEL
   MUST be discarded without any further processing.

   The AT_PCHANNEL attribute MUST contain an AT_STATUS attribute that
   both indicates (adopting EAP state machine terminology, please refer
   to [EAP-SM]):
     o The server's current decision regarding the peer (FAIL,
        COND_SUCC, UNCOND_SUCC)
     o The server's current decision regarding the continuation of the
        method (CONT, MAY_CONT, DONE)

   If the peer receives a valid AT_PCHANNEL attribute, it must answer
   with an EAP-PSK packet that also contains a valid AT_PCHANNEL
   attribute.

   While in this state the peer, depending on its policy, its current
   STATUS variables and the STATUS variables it receives from the
   server,
     o Stay in this state
     o Advance to Failure state
     o Advance to Success state

3.1.5 The Failure state

   In this state, the peer has decided that the current EAP-PSK dialog
   has failed and MUST discard any incoming EAP-PSK packet corresponding
   to that dialog. It waits for time outs, retry counter limits or an
   EAP-Failure packet. This state is an EAP-PSK state and must not be
   confused with a possible EAP state (e.g. Failure state in Figure 3 of
   [EAP-SM]).

3.1.6 The Success state

   In this state, the peer has decided that the current EAP-PSK dialog
   has succeeded and MUST discard any incoming EAP-PSK packet
   corresponding to that dialog. This state is an EAP-PSK state and must
   not be confused with a possible EAP state (e.g. Success state in
   Figure 3 of [EAP-SM]).

3.2 EAP-PSK server state machine











Bersani                  Expires ¡ August 2004               [Page 18]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


       +-----------+    +-----------+       +-----------+
       |           |    |           |<--+   |           |
   --->|   Init    |--->|  ID_req   |   |   |  Failure  |<----+
       |           |    |           |---+-->|           |     |
       +-----------+    +-----------+   |   +-----------+     |
                                        |                     |
                                        |                     |
                        +-----------+   |                     |
                        |           |<--+                     |
   +--------------------|  MAC_req  |                         |
   |                    |           |-------------------------+
   |                    +-----------+                         |
   |                                                          |
   +--------------------------+-------------------------------+
   |                          |
   |   +-----------+          |             +-----------+
   |   |           |          |             |           |
   +-->| P_Channel |----------+------------>|  Success  |
       |           |                        |           |
       +-----------+                        +-----------+


3.2.1 The Init state

   The server starts in the Init state: in this state, it builds an EAP-
   PSK packet that contains an AT_IDREQ attribute. It sets the flags of
   the AT_IDREQ (see section 4) according to its policy. To provide
   identity protection, the server SHOULD not set any of these flags in
   the first request it issues to the peer, that is to say, that the
   server SHOULD accept temporary identities.

   After sending this EAP-PSK packet, the server advances to the ID_req
   state.

3.2.2 The ID_req state

   In this state, the server waits for the response of the peer. The
   response of the peer MUST be an EAP-PSK packet that contains an
   AT_IDRES attribute.

   If the server does not recognize the identity sent by the peer, it
   can either:
     o Send another EAP-PSK packet that contains an AT_IDREQ attribute,
        with flag settings that MAY differ from the first EAP-PSK packet
        containing an AT_IDREQ attribute that was issued
     o Move to Failure state
   If the server ever issues an EAP-PSK packet with the permanent
   identity flag of the AT_IDREQ attribute set, it MUST send this
   attribute again within the EAP-PSK protected channel at the end of


Bersani                  Expires ¡ August 2004               [Page 19]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   the EAP-PSK dialog to allow the detection of attacks against the
   identity protection.

   If the server recognizes the identity sent by the peer, it chooses at
   random a 128 bit value and sends an EAP-PSK packet that MUST contain
   an AT_RAND which value is the random number it has just chosen. It
   then moves to the MAC_req state.

3.2.3 The MAC_req state

   In this state, the server waits for an EAP-PSK packet that contains
   an AT_MAC and an AT_RAND attribute.

   Upon reception of an EAP-PSK packet that contains an AT_MAC attribute
   and an AT_RAND attribute, the server MUST verify that the value of
   the AT_MAC attribute is equal to the value given by the following
   formula (please see also section 2.1.1):

                              [B||A||RA||RB]

   where:
     o B stands for the ASCII encoding of the permanent full NAI of the
        peer
     o A stands for the ASCII encoding of the permanent full NAI of the
        server
     o RA stands for the value of the AT_RAND the server sent before
        entering the MAC_req state
     o RB stands for the value of the AT_RAND the server has just
        received

   In case, this verification succeeds the server send an EAP-PSK that
   contains an AT_MAC and an AT_PCHANNEL attribute and moves to the
   P_channel state. The value of the AT_MAC attribute sent by the server
   is given by the following formula (please see also section 2.1.1):

                                  [A||RB]

   where:
     o A stands for the ASCII encoding of the permanent full NAI of the
        server
     o RB stands for the value of the AT_RAND attribute that the peer
        has just sent to the server
   The AT_PCHANNEL attribute MUST contain an AT_STATUS attribute and is
   calculated according to the procedure specified in section 2.1.3 and
   4. If the server and the peer care about identity protection, it
   SHOULD also contain an AT_IDRES attribute which value gives the peer
   its next temporary identity to use with EAP-PSK.





Bersani                  Expires ¡ August 2004               [Page 20]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   In case, the verification of the AT_MAC sent by the peer fails the
   server moves to the Failure state.

3.2.4 The P_channel state

   In this state, the server only processes EAP-PSK messages that
   contain an AT_PCHANNEL attribute. Furthermore, the AT_PCHANNEL MUST
   be the only attribute that the server processes.

   While processing an AT_PCHANNEL attribute, the server MUST first
   check the replay counter (see section 2.1.3). If the replay counter
   verifies (that is to say is equal to the value of the last counter
   sent incremented by one starting with a counter value of 0), the
   server then decrypts the value of the attribute AT_PCHANNEL and
   processes the attributes encapsulated within. Any EAP-PSK packet that
   fails to verify the replay counter or decrypt the value of the
   AT_PCHANNEL MUST be discarded without any further processing.

   The AT_PCHANNEL attribute MUST contain an AT_STATUS attribute that
   both indicates (adopting EAP state machine terminology, please refer
   to [EAP-SM]):
     o The server's current decision regarding the peer (FAIL,
        COND_SUCC, UNCOND_SUCC)
     o The server's current decision regarding the continuation of the
        method (CONT, MAY_CONT, DONE)

   While in this state the server, depending on its policy, its current
   STATUS variables and the STATUS variables it receives from the peer,
     o Stay in this state
     o Advance to Failure state
     o Advance to Success state

3.2.5 The Failure state

   In this state, the server has decided that the current EAP-PSK dialog
   has failed and MUST discard any incoming EAP-PSK packet corresponding
   to that dialog. The logical next step is the server sending an EAP
   Failure packet. This state is an EAP-PSK state and must not be
   confused with a possible EAP state (e.g. Failure state in Figure 4 of
   [EAP-SM]).

3.2.6 The Success state

   In this state, the server has decided that the current EAP-PSK dialog
   has succeeded and MUST discard any incoming EAP-PSK packet
   corresponding to that dialog. This state indicates to EAP that EAP-
   PSK has succeeded. This state is an EAP-PSK state and must not be
   confused with a possible EAP state (e.g. Success state in Figure 4 of
   [EAP-SM]).


Bersani                  Expires ¡ August 2004               [Page 21]

INTERNET-DRAFT                 EAP PSK             February 2004 2004



4. EAP-PSK message format

4.1 Table of the Type field of the different attributes

   TBC

   Attribute Name              Type Field Value
   AT_IDREQ                           1
   AT_IDRES                           2
   AT_RAND                            3
   AT_MAC                             4
   AT_PCHANNEL                        5
   AT_STATUS                          6

4.2 Format of the 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.

4.2.1 AT_IDREQ

   The format of the AT_IDREQ 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_IDREQ    | Length = 1    |P|         Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The flag P is set to one when the permanent identity of the peer is
   requested and to 0 otherwise.

   The use of the AT_IDREQ is defined in section 3.

4.2.2 AT_IDRES

   The format of the AT_IDRES attribute is shown below.









Bersani                  Expires ¡ August 2004               [Page 22]

INTERNET-DRAFT                 EAP PSK             February 2004 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_IDRES    |    Length     | Actual Identity Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                          Identity                             :
      :   .                                                           :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_IDRES is defined in Section 3.

   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 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.

4.2.3 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 128 bit 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.1.1.

   The format of the AT_MAC 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_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




Bersani                  Expires ¡ August 2004               [Page 23]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   looking at any other attributes (apart from the attributes that may
   be necessary to the verification of the MAC i.e AT_RANDs).

   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 3.

4.2.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.

       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 nonce is calculated as specified in section 2.1.3.

   The tag is 128 bit long. It is calculated as specified in 2.1.3 and
   in [EAX].

   The payload consists in the cipher text resulting from the encryption
   in the EAX mode of operation of the information that the peer and the


Bersani                  Expires ¡ August 2004               [Page 24]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   server wish to exchange over the protected channel under Nonce and
   the derived TEK (see Section 2.1). The information that the peer and
   the server may exchange over the protected channel consists of a
   concatenation of EAP-PSK attributes.

4.2.5 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.

   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.2.6 AT_STATUS

   The format of the AT_STATUS attribute is shown below.

       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_STATUS   |     Length    |Dec|Con|       Reserved        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   There MUST be exactly one AT_STATUS encapsulated in each AT_PCHANNEL.

   The two bit Dec flag is set to:
     o 00 if the current decision is FAIL
     o 01 if the current decision is COND_SUCC
     o 10 if the current decision is UNCOND_SUCC


Bersani                  Expires ¡ August 2004               [Page 25]

INTERNET-DRAFT                 EAP PSK             February 2004 2004



   The two bit Con flag is set to:
     o 00 if the current continuation state is CONT
     o 01 if the current continuation state is MAY_CONT
     o 10 if the current continuation state is DONE

5. IANA considerations

   This document introduces one new IANA consideration.

   It requires IANA to allocate a new EAP Type for EAP-PSK.

6. Security considerations

   The EAP base protocol [EAPbis] 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-PSK as well as vulnerabilities and security
   recommendations.

6.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-IDREQ
   attribute to attempt to learn the peer's permanent identity by
   setting the permanent identity flag.

   However, it is 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 ¡ August 2004               [Page 26]

INTERNET-DRAFT                 EAP PSK             February 2004 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).

6.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, AK, is only used for
   that purpose, making thus this part cryptographically independent of
   the other parts.

6.3 Key derivation

   EAP-PSK supports key derivation.

   The key hierarchy is specified in Section 2.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 ri and ci) 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 a dedicated key, the KDK.

   The input block to the key derivation is taken to be: [B||A||RA|RB].
   The reasons that motivated such a choice are:
     o This value is exactly 128 bit long since the tag length chosen
        for OMAC is 128 bits




Bersani                  Expires ¡ August 2004               [Page 27]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


     o This value is believed to be fresh for each new EAP-PSK dialog
        since it depends on RA and RB which are two values chosen at
        random by the peer and the server through OMAC which is believed
        to be a PRF
     o This value is believed not to be under the control either of the
        peer or the server since it is produced by OMAC which is
        believed to be a PRF and it takes into account both the inputs
        of the peer and the server

   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, hence the output blocks are cryptographically
   separated.

6.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 B 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.

6.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.

6.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.

6.7 Fast reconnect

   EAP-PSK shall provide fast reconnect. TBC.

6.8 Man-in-the-middle attacks





Bersani                  Expires ¡ August 2004               [Page 28]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   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.

   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.

6.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.

7. Security claims

   This section provides the security claims required by [EAPbis].

   [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
   256 bit Pre-shared Key

   [c] Security claims. The security properties of the method are
   discussed in Section 6.

   [d] Key strength. EAP-PSK supports key derivation with 128-bit
   effective key strength.

   [e] Description of key hierarchy. Please see Section 2.2.

   [f] Indication of vulnerabilities. Vulnerabilities are discussed in
   Section 6.

8. Intellectual Property Right Notice

   The author neither has, nor is of aware of, any patents or pending
   patents relevant to material included in this draft.





Bersani                  Expires ¡ August 2004               [Page 29]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


9. 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 and especially: Jesse Walker, Russ Housley
   Henry Haverinen and Joseph Salowey.

   Many thanks to Aur‰lien Magniez, Henri Gilbert, Laurent Butti, J‰rŸme
   Razniewski and Olivier Charles for their feedback on this document.

10. References

10.1 Normative

   [AES]         Federal Information Processing Standards (FIPS)
                 Publication 197, " Specification for the Advanced
                 Encryption Standard (AES)", National Institute of
                 Standards and Technology, November 26, 2001.

   [EAP]         Blunk, L. and Vollbrecht, J., "PPP Extensible
                 Authentication Protocol (EAP)", RFC 2284, March 1998.

   [EAPbis]      Blunk, L. et al., "Extensible Authentication Protocol
                 (EAP)", Internet-Draft (work in progress), February
                 2004, http://ietf.levkowetz.com/drafts/eap/rfc2284bis/
                 draft-ietf-eap-rfc2284bis-09.txt

   [EAP-SM]      Vollbrecht, J. et al., "State Machines for EAP Peer and
                 Authenticator", Internet-Draft (work in progress),
                 October 2003, draft-ietf-eap-statemachine-01

   [EAKD]        Bellare, M, and P. Rogaway, "Entity Authentication and
                 Key Distribution", CRYPTO 93, LNCS 773, pp232-249,
                 Springer-Verlag, Berlin, 1994.

   [EAX]         Bellare, M. et al., "The EAX mode of operation",
                 January 2004,
                 http://www.cs.ucsd.edu/users/mihir/papers/eax.pdf

   [EKMF]        Aboba, B. et al., "EAP Key Management Framework",
                 Internet-Draft (work in progress), October 2003, draft-
                 ietf-eap-keying-01.txt

   [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.


Bersani                  Expires ¡ August 2004               [Page 30]

INTERNET-DRAFT                 EAP PSK             February 2004 2004




   [PPP]         Simpson, W., Editor, "The Point-to-Point Protocol
                 (PPP)", STD 51, RFC 1661, July 1994.

   [RFC1750]     Eastlake, D. et al., "Randomness Recommendations for
                 Security", RFC 1750, December 1994.

   [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.

10.2 Informative

   [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

   [EAP-TLV]     Hiller, T. et al., "A Container Type for the Extensible
                 Authentication Protocol (EAP)", Internet-Draft (work in
                 progress), May 2003, draft-hiller-eap-tlv-01.txt

   [HAC]         Menezes, A. et al., ôHandbook of Applied Cryptographyö,
                 CRC Press, 1996.



Bersani                  Expires ¡ August 2004               [Page 31]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


   [IEEE 802.1X] IEEE STD 802.1X, Standards for Local and Metropolitan
                 Area Networks: Port Based Access Control, June 14, 2001

   [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

   [MOSKBC]      National Institute of Standards and Technology, "Modes
                 of operation for symmetric key block ciphers",
                 http://www.csrc.nist.gov/CryptoToolkit/modes/

   [MTAP]        Asokan, N. et al., ôMan-in-the-middle in Tunnelled
                 Authentication Protocolsö,
                 http://eprint.iacr.org/2002/163

   [PEAP]        Palekar, A. et al., ôProtected EAP Protocol (PEAP)ö,
                 Internet-Draft (work in progress), October 2003, draft-
                 josefsson-pppext-eap-tls-eap-07.txt

   [PEAP-TLV]    Salowey, J., "Protected EAP TLV", Internet-Draft (work
                 in progress), June 2003, draft-salowey-eap-
                 protectedtlv-02.txt

   [PKCS5]       RSA laboratories, ôPKCS #5 v2.0: Password-Based
                 Cryptography Standardö

   [PWD]         National Institute of Standards and Technology (NIST).


Bersani                  Expires ¡ August 2004               [Page 32]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


                 ôFIPS PUB 112: Password Usageö. May 30, 1985.

   [WPA]         Wi-Fi Alliance, ôWi-Fi Protected Accessö, version 2.0,
                 April 2003

11. Authors' Addresses

   Florent Bersani                   florent.bersani@francetelecom.com
   France Telecom R&D
   38, rue du General Leclerc
   92794 Issy Les Moulineaux Cedex 9
   France

12. 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

     1. Clarify the conventions used for the cryptographic calculations.
     2. Make this draft more self-contained.
     3. Provide test vectors




Bersani                  Expires ¡ August 2004               [Page 33]

INTERNET-DRAFT                 EAP PSK             February 2004 2004


     4. Complete the cross-references in the text (page, section,
        reference numbers)
     5. Harmonize the terminology (e. g. octets or bytes)
     6. Complete the terminology section (e.g. with temporary identity)
     7. Number the figures

2. Security

     1. Study alternative ways to produce the input blocks to the key
        derivation procedure.
     2. Validate the mechanism to prevent abrupt ending of the
        conversation on the protected channel.
     3. Discuss use of other cryptographic algorithms
     4. Discuss the choice of AES-128 and OMAC1 and a tag length of 128
        bits (e.g. why don't we use a truncated tag)
     5. Should we use the authentication capacity of associated data of
        EAX that is currently left aside?
     6. Discuss identity protection
     7. Specify the how long the same protected channel may be used
        without security compromise (a pretty long time I bet but it
        should be explicitly evaluated and stated)
     8. Specify how long the same protected channel may be used without
        security compromise (a pretty long time I bet but it should be
        explicitly evaluated and stated)
     9. Study DOS attacks resistance

3. Technical

     1. Discuss possibility to enhance network efficiency for instance
        by including the AT_IDREQ and AT_RAND attribute in the first
        packet.
     2. Should the peer be allowed to move directly from the Init state
        to the failure state to avoid lengthy time outs or retries?
     3. Specify how fast reconnect should be implemented
     4. Introduce version negotiation
     5. Is it desirable to have all attributes aligned on 32 bit
        boundaries?
     6. Harmonize with other standards or draft standards (e. g. EAP and
        EAP Key management framework)
     7. Should the AT_STATUS remain a separate attribute from
        AT_PCHANNEL?
     8. Should an intermediary state be included in the state machine
        that would handle the entry in the P_Channel state?
     9. Specify all that remain TBC, e.g. the different notification
        messages.
     10. Make sure that the interface of this EAP method with the EAP
        state machine works well
     11. Define more attributes



Bersani                  Expires ¡ August 2004               [Page 34]

INTERNET-DRAFT                 EAP PSK             February 2004 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 (please refer to [HAC] for a
   description of this hash) 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 xor
        of the peerÆs and the server's NAI as Salt.
     3. 5000 as c
     4. 48 as dkLen














Bersani                  Expires ¡ August 2004               [Page 35]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/