INTERNET-DRAFT                 EAP-PSK                      June 2004



   Internet Draft                                       Florent Bersani
   File: draft-bersani-eap-psk-02.txt                France Telecom R&D
   Expires: December 2004                                     June 2004

          The EAP-PSK Protocol: a Pre-Shared Key (PSK) EAP Method


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3667.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at:
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire in December 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document specifies an Extensible Authentication Protocol (EAP)
   method for mutual 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 provides a secure communication channel within EAP in case
   the authentication is successful. This channel is used to implement
   protected result indications and may be used by future extensions.
   EAP-PSK is designed to be easy to deploy and well-suited for
   authentication over insecure networks such as IEEE 802.11.
   It is proposed as a replacement for MD5-Challenge.


Bersani                 Expires û December 2004               [Page 1]


INTERNET-DRAFT                 EAP-PSK                      June 2004


Table of Contents

   1. Introduction..................................................4
     1.1 Design goals for EAP-PSK...................................4
     1.2 Caveats....................................................5
     1.3 Specification of requirements..............................6
     1.4 Terminology................................................6
     1.5 Conventions................................................9
     1.6 Related work..............................................10
   2. Protocol overview............................................12
     2.1 EAP-PSK key hierarchy.....................................12
          2.1.1 The PSK............................................12
          2.1.2 The TEK............................................13
          2.1.3 The MSK............................................13
          2.1.4 The EMSK...........................................13
          2.1.5 The IV.............................................13
     2.2 Cryptographic design of EAP-PSK...........................13
          2.2.1 The authenticated key exchange.....................14
          2.2.2 The protected channel..............................17
     2.3 EAP-PSK message flow......................................23
          2.3.1 EAP-PSK standard authentication....................23
          2.3.2 EAP-PSK extended authentication....................24
     2.4 Identity protection.......................................25
     2.5 Fast reconnect............................................25
     2.6 Fragmentation.............................................26
   3. EAP-PSK state machines.......................................26
     3.1 Conventions for the state machines........................27
          3.1.1 Rules of operation for the state machines..........27
          3.1.2 Graphical representation...........................27
          3.1.3 Table representation...............................28
     3.2 EAP-PSK peer state machine................................29
          3.2.1 Variables and procedures...........................29
          3.2.2 Graphical representation...........................37
          3.2.3 Table representation...............................37
     3.3 EAP-PSK server state machine..............................38
          3.3.1 Variables and Procedures...........................39
          3.3.2 Graphical representation...........................45
          3.3.3 Table representation...............................45
   4. EAP-PSK message format.......................................45
     4.1 General format of an EAP-PSK message......................45
     4.2 Generic format of an EAP-PSK attribute....................46
     4.3 Table of the Type field of the different attributes.......47
     4.4 Format of the different EAP-PSK attributes................47
          4.4.1 AT_EXT.............................................47
          4.4.2 AT_ID..............................................48
          4.4.3 AT_MAC.............................................48
          4.4.4 AT_PCHANNEL........................................49
          4.4.5 AT_RAND............................................50
          4.4.6 AT_STATUS..........................................50


Bersani                 Expires û December 2004               [Page 2]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   5. IANA considerations..........................................51
     5.1 Allocation of an EAP-Request/Response Type for EAP-PSK....52
     5.2 Allocation of EXT_Type numbers............................52
   6. Security considerations......................................52
     6.1 Identity protection.......................................52
     6.2 Mutual authentication.....................................54
     6.3 Key derivation............................................54
     6.4 Dictionary attacks........................................55
     6.5 Protected channel.........................................56
     6.6 Negotiation attacks.......................................56
     6.7 Man-in-the-middle attacks.................................57
     6.8 Random numbers generation.................................57
     6.9 Denial of Service resistance..............................57
     6.10 Implementation of EAP-PSK................................58
     6.11 Exposition of the PSK....................................59
     6.12 Channel binding..........................................59
     6.13 Fragmentation............................................59
   7. Security claims..............................................60
   8. Intellectual Property Right Notice...........................61
   9. Acknowledgements.............................................61
   10. References..................................................61
     10.1 Normative................................................61
     10.2 Informative..............................................62
   11. Authors' Addresses..........................................65
   Annex A: Generation of the PSK from a password - Discouraged....67
   Annex B: Generation of the PSK from a 128 bit shared key........68

























Bersani                 Expires û December 2004               [Page 3]


INTERNET-DRAFT                 EAP-PSK                      June 2004


1. Introduction

1.1 Design goals for EAP-PSK

   The Extensible Authentication Protocol (EAP) [EAP] provides an
   authentication framework which supports multiple authentication
   methods.

   This document specifies an EAP method called EAP-PSK that uses a pre-
   shared key (PSK).

   Design goals for this method were:
     o Simplicity: it should be easy to implement and to deploy without
        any pre-existing infrastructure
     o 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 [IEEE802.11] wireless LANs
     o Security: it should be conservative in its cryptographic design
        and enjoy security proofs
     o Extensibility: it should be possible to easily extend this
        method as the need to do so appears
     o Patent-avoidance: it should be free of any Intellectual Property
        Right claims
     o Reduced time to market: since some of the protocols that rely on
        EAP are nearly completed (e.g. IEEE 802.11i [IEEE802.11i]), it
        is crucial that a simple shared key method be provided as
        quickly as possible

   For the sake of simplicity, EAP-PSK has thus chosen to rely on a
   single cryptographic primitive, AES-128 [AES]. The restriction to
   such a primitive (and in particular, the choice not to use asymmetric
   cryptography like Diffie-Hellman key exchange) should make EAP-PSK
   light-weight and well suited for any type of device, especially those
   with low processing power and memory. However, as further discussed
   in section 6, this prevents EAP-PSK from offering possibly nice
   features such as identity protection or Perfect Forward Secrecy
   (PFS). This choice has been deliberately made as a trade off between
   simplicity and security.
   For the sake of simplicity, EAP-PSK also made the assumption that the
   peer knows the identity of the server it is authenticating to (see
   section 2.2.1). This assumption probably prevents EAP-PSK to
   efficiently deal with sophisticated usage scenarios like peer-to-peer
   ad-hoc mode, that were deemed inessential and infrequent.

   The level of security offered by EAP-PSK is however compatible with
   its use over any type of network, and in particular wireless
   networks. Indeed, it performs mutual authentication and session key
   derivation and has been designed in the EAP threat model where the
   attacker has full control over the communication channel.


Bersani                 Expires û December 2004               [Page 4]


INTERNET-DRAFT                 EAP-PSK                      June 2004



   Since the design of authenticated key exchange is notoriously known
   to be hard and error prone, EAP-PSK does not invent any new mechanism
   but builds on existing protocols that have been proposed and reviewed
   by the cryptographic community and enjoy proofs of security in the
   cryptographic provable security paradigm.

   To allow for simple extensions, EAP-PSK uses a Type-Length-Value
   design: new attributes may thus be easily added to EAP-PSK. This
   design is quite analogous to the attribute format used in EAP-SIM
   [EAP-SIM], EAP-TTLS [EAP-TTLS] or PEAP [PEAP] and EAP-FAST [EAP-FAST]
   (please refer to EAP-TLV [EAP-TLV]). EAP-PSK provides a hook to
   implement these extensions (see section 2.3.2).

   There has been a trend to play Russian dolls with protocols (IEEE
   802.11i which uses IEEE 802.1X [IEEE802.1X] which in turn uses EAP
   which itself uses EAP methods). The problem is, that now that the
   outer dolls are quite complete, mature and standard inner dolls tend
   to lack. To fill this gap as quickly as possible, EAP-PSK chose not
   to implement any functionality that was deemed superfluous (e.g.
   identity protection or password support) and that might have thus
   unnecessarily delayed its release.

1.2 Caveats

   The reader is strongly advised to keep the following points in mind:
     o The level of security provided by EAP-PSK is still to be
        assessed
     o EAP-PSK should not be confused with other protocols that also
        have the word "PSK" in their name
     o The PSK used by EAP-PSK MUST be chosen at random among the set
        of possible keys
     o The PSK used by EAP-PSK MUST be cryptographically separated from
        keys used by any other protocol
     o EAP-PSK does not mandate in any way how the PSK is to be stored
     o The "network quality" of EAP-PSK is still to be assessed

   As has already been said in section 1.1, the design of authenticated
   key exchange protocols is error prone. Great care should thus be
   taken regarding EAP-PSK. It is still work in progress and has to be
   reviewed by cryptographic experts before it can be trusted, although
   it reuses existing protocols that are deemed secure.

   Since PSK are of frequent use in security protocols, because a PSK
   simply means a cryptographic key in the symmetric cryptography
   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



Bersani                 Expires û December 2004               [Page 5]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   instance Wi-Fi Protected Access (WPA) [WPA] when used in its PSK
   mode.

   Although, the generation of the PSK used by EAP-PSK is outside of the
   scope of this document, it is reminded that the PSK MUST be generated
   by a good source of randomness (see [RFC 1750]) for security
   properties to hold. In particular, a PSK MUST NOT be confused with a
   password (see section 6.4 for further discussion).

   The PSK used by EAP-PSK MUST be cryptographically separated from keys
   used by any other protocol otherwise 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 definition of the repository of the PSK used by EAP-PSK is
   outside of the scope of this document. In particular, nothing
   prevents from storing the PSK used by EAP-PSK on a tamper-resistant
   device such as a smart card rather than having it memorized or
   written down on a sheet of paper. It is reminded that the choice of
   the repository used for the PSK may have serious security impacts
   (see section 6.11 for a brief discussion).

   Finally, the "network quality" of EAP-PSK e.g. its correctness from a
   non-cryptographic point of view, its efficiency or the soundness of
   its non-cryptographic design (e.g. its attribute format) is still to
   be evaluated by expert network engineers.

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:

   AAA       Authentication, Authorization and Accounting, please refer
             to [RFC 2989] for more details

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

   AKEP
             Authenticated Key Exchange Protocols. The name of a family
             of protocols that allow authenticated key exchange and that
             are specified in [EAKD]



Bersani                 Expires û December 2004               [Page 6]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   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
             [IEEE802.1X])

   EAP
             Extensible Authentication Protocol, please refer to [EAP]
             for more details

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

   Extended Master Session Key (EMSK)
             Additional keying material derived between the EAP client
             and server that is exported by the EAP method. The EMSK is
             at least 64 bytes in length.  The EMSK is reserved for
             future uses that are not defined yet and is not provided to
             a third party.

   IV
             Initialization Vector. A quantity of at least 64 octets,
             suitable for use in an initialization vector field, that is
             derived between the peer and EAP server. Since the IV is a
             known value in methods such as EAP-TLS [EAP-TLS], it cannot
             be used by itself for computation of any quantity that
             needs to remain secret. As a result, its use has been
             deprecated and EAP methods are not required to generate it.
             However, when it is generated it MUST be unpredictable

   MAC
             Message Authentication Code. Informally, the purpose of a
             MAC is to facilitate, without the use of any additional


Bersani                 Expires û December 2004               [Page 7]


INTERNET-DRAFT                 EAP-PSK                      June 2004


             mechanisms, assurances regarding both the source of a
             message and its integrity, please refer to [HAC] for more
             details. IEEE 802 specifications use the acronym MIC
             (Message Integrity Check) to avoid confusion with their
             acronym MAC (Medium Access Control)

   Master Session Key (MSK)
             Keying material that is derived between the EAP peer and
             server and exported by the EAP method.  The MSK is at least
             64 bytes in length.  In existing implementations a AAA
             server acting as an EAP server transports the MSK to the
             authenticator.

   NAI
             Network Access Identifier, the NAI is used to identify the
             parties communicating, see [NAI]

   OMAC
             One Key CBC-MAC, a method to generate a Message
             Authentication Code (MAC, see this word here above), please
             refer to [OMAC] for more details

   Perfect Forward Secrecy
             The confidence that the compromise of a long-term private
             key does not compromise any earlier session keys. In other
             words, once an EAP dialog is finished and its corresponding
             keys are forgotten, even someone who has recorded all of
             the data from the connection and gets access to all of the
             long-term keys of the peer and the server cannot
             reconstruct the keys used to protect the conversation
             without doing a brute force search of the session key
             space.

   PSK
             Pre-shared key. A pre-shared key is a cryptographic key in
             the symmetric setting that is derived by some prior
             mechanism and shared between the parties before the
             protocol using it takes place. It is merely a sequence of
             binary digits of given length that have been chosen
             at random.

   PRF
             Pseudo-random function. Please refer for instance to [EAX]
             for a precise cryptographic definition of this term.
             Informally a family of functions is pseudo-random if there
             is no efficient procedure to distinguish between a member
             of this family chosen at random and a function with the
             same domain and range chosen at random. By improper though
             common extension, a member of a family of pseudo-random


Bersani                 Expires û December 2004               [Page 8]


INTERNET-DRAFT                 EAP-PSK                      June 2004


             functions is itself called a pseudo-random function

   Protected result indication
             Informally, protected result indication means that the peer
             and the server share the same view on the success or not of
             the authentication. This feature has been introduced
             because EAP-Success/Failure packets are not protected. See
             [EAP], section 7.16, for more details.

   PRP
             Pseudo-random permutation. Please refer for instance to
             [EAX] for a precise cryptographic definition of this term.
             Informally a family of permutations is pseudo-random if
             there is no efficient procedure to distinguish between a
             member of this family chosen at random and a permutation
             with the same domain chosen at random. By improper though
             common extension, a member of a family of pseudo-random
             permutations is itself called a pseudo-random permutation

   Transient EAP Keys (TEKs)
             Session keys which are used to establish a protected
             channel between the EAP peer and server during the EAP
             authentication exchange. The TEKs are appropriate for use
             with the ciphersuite negotiated between EAP peer and server
             for use in protecting the EAP conversation.  Note that the
             ciphersuite used to set up the protected channel between
             the EAP peer and server during EAP authentication is
             unrelated to the ciphersuite used to subsequently protect
             data sent between the EAP peer and authenticator.

1.5 Conventions

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

   || denotes concatenation of strings (and not the logical OR).

   MAC(K,String) denotes the MAC of String under the key K (the
   algorithm used in this document to compute the MAC is OMAC1 with AES-
   128, see section 2.2.1)

   [String] denotes the concatenation of String with the MAC of String
   calculated as specified by the context. Hence,
   [String]=String||MAC(K,String) where K is specified by the context.

   ** denotes integer exponentiation.





Bersani                 Expires û December 2004               [Page 9]


INTERNET-DRAFT                 EAP-PSK                      June 2004


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

   <i> denotes the unsigned binary representation on 32 bits of the
   integer i in network byte order. Therefore this notation only makes
   sense when i is between 0 and 2**32-1.

1.6 Related work

   So far, at the time this document is written, only three EAP methods
   are standards track EAP methods per IETF terminology (please, refer
   to [RFC2026]), namely:
     o MD5-Challenge (EAP-Request/Response type 4), defined in [EAP],
        which uses a MD5 challenge similar to [CHAP]
     o OTP (EAP-Request/Response type 5), defined in [EAP], which aims
        at providing One-Time Password support
     o GTC (EAP-Request/Response type 6), defined in [EAP], which aims
        at providing Generic Token Card Support

   Unfortunately, all three are deprecated for security reasons that are
   partly explained in [EAP].

   Myriads of EAP methods have however been otherwise proposed, some as
   informational RFCs (e.g. [EAP-TLS]) - which thus aren't standards
   (see [RFC 1796] and [RFC 2026]), some as individual Internet-Drafts
   submissions (e.g. [PEAP] or this document) and some even undocumented
   (e.g. Rob EAP which has EAP-Request/Response type 31).

   Although it may be considered good news for mankind creativity, this
   situation is quite a pity because it is not easy at all for the
   profane (and sometimes for the expert as well):
        o To choose the/an EAP method that suits a specific usage
           scenario
        o To know whether the EAP method it has selected is mature,
           still evolving or, worse, abandoned
        o To be sure that the EAP method it has selected is not broken
           from a functional or a secure point of view
        o To be sure that he will find implementations of the EAP
           method it has chosen on a wide range of platforms and that
           these implementations will be interoperable

   A recommended reading on do's and don'ts for authentication methods
   is [SAM].

   Anyway, sad as it may be, no secure and mature shared key EAP method
   exists, which is all the more regrettable that shared key methods are
   supposed to be the simplest ones!



Bersani                 Expires û December 2004              [Page 10]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   Yet, a good many proposals for such shared key methods exist, that we
   briefly review here after (please refer to [SKM] for a more thorough
   synthesis on EAP methods).

   Among the existing proposed shared key methods, we distinguish
   between those which:
        o Are broken from a security point of view e.g. LEAP [LEAP] -
           see [LEAPVUL] - or EAP-MSCHAPv2 [EAP-MSCHAPv2]
        o Would normally require additional infrastructure to work e.g.
           EAP-SIM, EAP-AKA [EAP-AKA] or OTP/token card methods like
           [EAP-SecurID]
        o Are abandoned but have provided the basis for EAP-PSK e.g.
           EAP-Archie [EAP-Archie]
        o Are not shared key methods but often confused with them,
           namely the password methods e.g. EAP-SRP [EAP-SRP] or SPEKE
           [SPEKE] - which very unfortunately seem to have serious IPR
           concerns
        o Are possible alternatives to EAP-PSK (i.e. claimed to be
           secure and subject of active work), namely EAP-FAST [EAP-
           FAST], EAP-IKEv2 [EAP-IKEv2] or EAP-TLS (when shared
           key/password support will be added to TLS)

   What makes then EAP-PSK different from the related work mentioned
   here above? Essentially, the fact that EAP-PSK does not wish to be
   the shared key solution but rather wishes to stimulate the community
   to standardize such a solution by fully opening its development
   process (see Annex C). Indeed, EAP-PSK tries to borrow all the best
   parts of the existing proposals and merge them into a single method.

   In its attempt to retain the strengths of the other proposed shared
   key EAP methods, EAP-PSK is currently faced with some issues, such
   as:
        o Should a "new" shared key authentication and key exchange
           mechanism be used in EAP-PSK or is there any standard and
           well-reviewed such mechanism at IETF that could be cut-and-
           paste?
        o Should there be a single EAP method that allows a variety of
           authentication mechanisms or as many EAP methods as
           authentication mechanisms?
        o What should be the security requirements for a shared key EAP
           method?

   The first question above is not about inventing a new cryptographic
   authenticated key exchange protocol - we have strictly forbidden us
   to do so - but rather about finding a cryptographic mechanism among
   the existing ones that has been integrated in a "real-world" standard
   at IETF. In fact and very surprisingly, apart from the deprecated
   shared key mechanisms such as [CHAP], the possible IETF candidates,
   namely IKEv2 and TLS with shared key/password, do not seem to be


Bersani                 Expires û December 2004              [Page 11]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   appropriate. Firstly, these mechanisms raise the "unifying" question
   in EAP (see next paragraph) as they are themselves designed to allow
   for a variety of authentication methods (public-key certificates,
   shared keys, passwords). Secondly, they have some specific concerns:
   IKEv2 mandates use of public key cryptography (namely Diffie-Hellman
   key exchange) and shared key/password support in TLS is still work in
   progress.

   As EAP is already a framework, it seems natural to have different
   methods for different situations, as a single method for all
   situations would simply be a another framework redundant with EAP.
   However the latter seems to be the trend (e.g. PEAP/EAP-TTLS/EAP-FAST
   allow virtually any authentication method for the peer and TLS or
   IKEv2 could handle public key or shared key and even password
   authentication). Is this trend regrettable? We call this the
   "unifying question".

   Last, although some work has been done to clarify the requirements on
   EAP methods ([IEEE802REQ]), it is still unclear in our opinion what
   the real-world constraints are, e.g. should an EAP method try to
   adjust to legacy devices or credentials (like EAP-FAST)?

   More on these issues can be found at
   http://perso.rd.francetelecom.fr/bersani/EAP_PSK/EAP-PSK.htm

   Any feedback to the author will be most appreciated.

2. Protocol overview

2.1 EAP-PSK key hierarchy

   This section instantiates the EAP Key hierarchy described in [EKMF]
   for EAP-PSK.

2.1.1  The PSK

   EAP-PSK uses a long-lived 32 byte secret key called the PSK that is
   shared between the EAP Peer and the EAP Server.

   This PSK has an internal structure. It consists of two 16 byte
   subkeys, respectively called the authentication key (AK) and the key-
   derivation key (KDK). Hence, PSK=AK||KDK

   The protocol uses the AK to mutually authenticate the EAP Peer and
   the EAP Server and the KDK to derive keying material between the EAP
   Peer and the EAP Server. It should be emphasized again that EAP-PSK
   assumes that AK and KDK are cryptographically separated and that its
   security proof relies on this assumption. In case the PSK is drawn at



Bersani                 Expires û December 2004              [Page 12]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   random from the set of possible keys (i.e. 32 byte strings), this
   assumption is verified.

   EAP-PSK assumes that the PSK is known only to the EAP Peer and EAP
   Server. 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 each other by their respective Network Access
   Identifiers (NAIs - see [RFC 2486]).

2.1.2  The TEK

   EAP-PSK allows for TEK derivation thanks to a random number exchanged
   during authentication and the KDK.

   There is only one TEK used within an EAP-PSK dialog.

   The TEK used within an EAP-PSK dialog is a 16 byte key that is used
   to set up a protected channel for both mutually authenticated parties
   to communicate securely.

2.1.3  The MSK

   EAP-PSK allows for MSK derivation thanks to a random number exchanged
   during authentication and the KDK.

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

2.1.4  The EMSK

   EAP-PSK allows for EMSK derivation thanks to a random number
   exchanged during authentication and the KDK.

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

2.1.5  The IV

   EAP-PSK does not derive any IV.

2.2 Cryptographic design of EAP-PSK

   EAP-PSK relies on a single cryptographic primitive, a block cipher,
   which is instantiated with AES-128. AES-128 has been chosen because:
        o It is standardized and implementations are widely available
        o It has been carefully reviewed by the community and is
           believed to be secure




Bersani                 Expires û December 2004              [Page 13]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   However, in case it should be needed, new instantiations of EAP-PSK
   with other block ciphers could easily be proposed as EAP-PSK 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). For the sake of simplicity, it has
   been chosen not to allow the negotiation of other block ciphers for
   EAP-PSK.

   For a detailed description of AES-128, please refer to [AES].

   EAP-PSK uses two cryptographic parts:
     o An authenticated key exchange protocol to mutually authenticate
        the communicating parties, that follows the design presented in
        [EAKD] under the name AKEP2 instantiated with OMAC1 [OMAC], the
        modified counter mode [SOBMMO] and AES-128
     o A secure channel protocol for both mutually authenticated
        parties to communicate, that uses the EAX [EAX] mode of
        operation with AES-128

2.2.1  The authenticated key exchange

   The authentication protocol used by EAP-PSK is the Authenticated Key
   Exchange Protocol 2 (AKEP2) described in [EAKD].

   It consists of a one and half round trip exchange depicted in Figure
   1.

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

   Figure 1: Overview of AKEP2

   In Figure 1:

     o RA and RB are random numbers chosen respectively by Alice and
        Bob
     o A and B are Alice's and Bob's respective identities
     o The MACs (see section 1.5 for the notation []) are calculated
        using a dedicated key

   EAP-PSK instantiates this protocol with:


Bersani                 Expires û December 2004              [Page 14]


INTERNET-DRAFT                 EAP-PSK                      June 2004



     o RA and RB taken to be 128 bit random numbers chosen respectively
        by Alice and Bob
     o A and B taken to be Alice's and BobÆs respective NAIs
     o The MAC algorithm we use is OMAC1 with AES-128 using a 128-bit
        portion of the PSK called AK (see section2.1.1) and producing a
        tag length of 128 bits.
     o The modified counter mode of operation of AES-128 to derive the
        keying material resulting from this exchange.

   OMAC was chosen because of its handling of arbitrary length messages
   and its design simplicity. It also enjoys a security proof, which has
   not been found to be flawed so far and is believed to have been
   extensively reviewed by the cryptographic community. For a detailed
   description of OMAC, please refer to [OMAC].

   Since in AKEP2 the key exchange is "implicit", we have to specify the
   cryptographic derivation of the session keys from RB. This
   cryptographic derivation is realized using the modified counter mode
   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. The modified counter mode is a length increasing
   function, i.e. it expands a 1-block input value into a longer t-block
   output, where t>=2.

   Figure 2 below depicts the modified counter mode as a black box used
   by EAP-PSK.

                RB                                      KDK
       Input Block (128 bits)              Key Derivation Key (128 bits)
                 |                                       |
                 v                                       v
         +-------------------------------------------------------------+
         |                                                             |
         |                    Modified Counter Mode                    |
         |                                                             |
         +------------------------------------------------------------+
              |                   |                         |
              v                   v                         v
         +---------+   +---------------------+   +---------------------+
         |   TEK   |   |         MSK         |   |         EMSK        |
         +---------+   +---------------------+   +---------------------+

   Figure 2: The modified counter mode as a black box for EAP-PSK

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



Bersani                 Expires û December 2004              [Page 15]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The input block to the key derivation is taken to be RB as specified
   in AKEP2 (see section 6.3 for a discussion of the implications of
   this choice).

   The key used for key derivation is a portion of the PSK called the
   KDK, see section 2.1.1.

   For what regards the output blocks, using [EKMF] terminology:
     o The first output block is the TEK that will be used by the
        current instance of EAP-PSK
     o The second to fifth output blocks of the key derivation are the
        Master Session Key (MSK)
     o The sixth to ninth output blocks of the key derivation are the
        Extended Master Session Key (EMSK)

   We hereafter describe precisely the parameters with which we use the
   modified counter mode in EAP-PSK using the same notations as in
   [SOBMO].

   All rotation values (the ri per [SOBMMO] Figure 3 notation) are set
   to zero (no rotations) and the counter values (the ci per [SOBMMO]
   Figure 3 notation) are respectively set to the first t integers (that
   is ci="i", starting with i=1). The ri were taken equal to zero for
   the sake of simplicity. While we take the ri to be all zeroes, taking
   ci="i" ensures that the security proof holds (because it implies that
   that the ci are all distinct).

   The parameter t of [SOBMO] is set to 9 so that the amount of keying
   material needed is exactly generated (i.e. with a 128 bit block
   length, a 1 block TEK, a 4 block MSK and a 4 block EMSK).

   Figure 3 below depicts the modified counter mode used for key
   derivation within EAP-PSK showing its internals.


















Bersani                 Expires û December 2004              [Page 16]


INTERNET-DRAFT                 EAP-PSK                      June 2004


                RB
       Input Block (128 bits)
                 |
                 |
         +----------------+
         |                |
         | AES-128(KDK,.) |
         |                |
         +----------------+
                  |
                  |
                  +---------------------+--..................--+
                  |                     |                      |
                  |                     |                      |
              +-------+            +-------+               +-------+
     c1="1" ->|  XOR  |   c2="2" ->|  XOR  | ...  c9="9" ->|  XOR  |
   (128 bits) +-------+ (128 bits) +-------+    (128 bits) +-------+
                  |                    |                       |
                  |                    |                       |
         +----------------+   +----------------+      +----------------+
         |                |   |                |      |                |
         | AES-128(KDK,.) |   | AES-128(KDK,.) |......| AES-128(KDK,.) |
         |                |   |                |      |                |
         +----------------+   +----------------+      +----------------+
                  |                    |                       |
                  |                    |                       |
            Output Block #1      Output Block #2         Output Block #9
              (128 bits)           (128 bits)   ......     (128 bits)
                 TEK              MSK Block #1            EMSK Block #4

   Figure 3: EAP-PSK Key derivation with the modified counter mode

2.2.2  The protected channel

   EAP-PSK provides a secure channel called "the protected channel" in
   case of a successful authentication for both parties to communicate
   over. This protected channel is provided to allow protected result
   indications and future extensions of EAP-PSK (such as account
   reporting and provisioning).

   Figure 4 below describes the protected channel as a black box for
   EAP-PSK when used in the encryption way.









Bersani                 Expires û December 2004              [Page 17]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   +-----------+ +----------------+ +---------------------+ +----------+
   |  Nonce N  | |    Header H    | | Plain Text Payload  | |   TEK    |
   |  32 bits  | |    9 bytes     | |  Variable length v  | | 128 bits |
   +-----------+ +----------------+ +---------------------+ +----------+
         |                 |                       |             |
         v                 v                       v             v
   +-------------------------------------------------------------------+
   |                                                                   |
   |                           Protected Channel                       |
   |                                                                   |
   +-------------------------------------------------------------------+
         |                           |                           |
         v                           v                           v
   +-----------+ +----------------------------------------+ +----------+
   |  Nonce N  | |           Encrypted Payload            | |   Tag    |
   |  32 bits  | |           Variable length v            | | 128 bits |
   +-----------+ +----------------------------------------+ +----------+

   Figure 4: The protected channel in the encryption way used as a
   black-box by EAP-PSK

   The nonce N is used to provide cryptographic security to the
   encryption and to the MAC as well as to provide protection replay
   (indeed we take for nonce N a 32 bit sequence number that is
   monotonically incremented).

   The Header H consists in the first 5 bytes of the EAP request or
   response packet (i.e. the Code, Identifier, Length and Type fields)
   followed by the first 4 bytes of AT_PCHANNEL (i.e. the EAP-PSK
   Attribute Type for AT_PCHANNEL, its length and Reserved fields - see
   section 4.4.4).

   The Plain Text payload is the payload that is to be encaspulated
   (once it has been encrypted) as the AT_PCHANNEL payload (see section
   4.4.4).

   The Tag is a MAC that protects both the Header and the payload. It is
   included in the AT_PCHANNEL Tag field (see section 4.4.4).

   Figure 5 below describes the protected channel as a black box for
   EAP-PSK when used in the decryption way










Bersani                 Expires û December 2004              [Page 18]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   +---------+ +----------+ +-----------------+ +----------+ +---------+
   | Nonce N | | Header H | |Encrypted Payload| |   Tag    | |   TEK   |
   | 32 bits | | 9 bytes  | |Variable length v| | 128 bits | | 128 bits|
   +---------+ +----------+ +-----------------+ +----------+ +---------+
        |           |                |               |            |
        v           v                v               v            v
   +-------------------------------------------------------------------+
   |                                                                   |
   |                           Protected Channel                       |
   |                                                                   |
   +-------------------------------------------------------------------+
                                     |
                                     v
                 +----------------------------------------+
                 |          Plain Text Payload            |
                 |           Variable length v            |
                 +----------------------------------------+
                                     or
                 +----------------------------------------+
                 |                INVALID                 |
                 |                                        |
                 +----------------------------------------+

   Figure 5: The protected channel in the decryption way used as a
   black-box by EAP-PSK

   The decryption process returns either the plain text payload or
   invalid if the replay counter does not have the expected value or if
   the tag does not match its expected value.

   EAP-PSK uses the EAX mode of operation described in [EAX] to provide
   this protected channel.

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

   We hereafter describe the parameters with which we use EAX in EAP-PSK
   using the same notations as in [EAX].

   EAX is instantiated with AES-128 as the underlying block cipher keyed
   with the TEK (see section 2.1.2).



Bersani                 Expires û December 2004              [Page 19]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The tag length is chosen to be 128 bits for EAX within EAP-PSK.

   The nonce N used by EAX (following [EAX] Figure 3 notation) is a
   counter starting with <0> and incremented at each subsequent EAP-PSK
   message (except retransmissions of course) within one EAP-PSK dialog.
   Thus, N can be considered a replay counter. The nonce N was taken on
   32 bits to simplify implementations (i.e. to avoid 128 bit
   arithmetic). Since EAX uses a 128 bit nonce, N is padded with 96 zero
   bits for its high order bits.
   Thus, the maximum number of messages that can be exchanged over the
   same protected channel is 2**32 (which should not be a limitation in
   practice as 2**32 is approximately equal to 4 billions). Indeed, the
   32 low order bits of N are not allowed to wrap up. In the unlikely
   yet possible event of the server having sent an EAP-PSK message with
   the 32 low order bits of N set to 2**32-2, it MUST NOT send any
   further message on this protected channel (which would cause the
   nonce to wrap up and reuse the value 0): either the conversation is
   finished after the server receives the EAP-PSK answer from the peer
   with the 32 low order bits of N set to 2**32-1 and the server
   proceeds (typically by sending an EAP message of type success or
   failure), or the conversation is not finished and MUST then be
   aborted (a new EAP-PSK dialog MAY subsequently be started to try
   again to successfully authenticate).

   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. the AT_PCHANNEL payload, which can
   be an AT_STATUS or an AT_STATUS and an AT_EXT - see section 4.4.4).

   The header H used by EAX (following [EAX] Figure 3 notation) is taken
   to be the EAP header of the EAP packet in which the EAP-PSK packet is
   encapsulated followed by the first four bytes of the AT_PCHANNEL
   header. Although it may appear unorthodox that an upper layer (EAP-
   PSK) protects some information of the lower layer (EAP), this was
   chosen to comply with [EAP] recommendation (see section 7.5. of
   [EAP]) and seems to be existing practice at IETF (e.g. see [AH])

   Before giving a detailed presentation of EAX, we first present in
   Figure 6 the notation we use for EAX encryption building block: the
   counter mode. Figure 6 depicts the counter mode of operation with
   AES-128 as the underlying primitive which is used for encryption in
   EAP-PSK protected channel. This counter mode is part of the EAX mode
   of operation that is depicted in Figure 8. This counter mode should
   not be confused with the modified counter mode used for key
   derivation.






Bersani                 Expires û December 2004              [Page 20]


INTERNET-DRAFT                 EAP-PSK                      June 2004


                   Message M
              (Variable length V)
                       |
              +----------------+
              |                |
       St  -->|  CTR(TEK,.,.)  |
   (128 bits) |                |
              +----------------+
                       |
                 Cipher Text C
              (Variable length V)

   Figure 6: The counter mode used in EAP-PSK protected channel

   The counter mode CTR takes three input values:
     o TEK, which is the key used to encrypt the counter thanks to AES-
        128
     o St, which is a 128 bit value taken to be the starting point of
        the counter
     o M, which is a variable length message to encrypt

   The counter mode CTR produces one output value:
     o C, which is the variable length cipher text resulting from the
        encryption of the message

   In Figure 7 below, we present, a notation used in to depict OMAC1
   which is intensively used in EAX.

                   Message M
              (Variable length V)
                       |
              +----------------+
              |                |
              |  OMAC1(TEK, P) |
              |                |
              +----------------+
                       |
                    Tag T
                  (128 bits)

   Figure 7: OMAC1 used in EAP-PSK protected channel

   OMAC1 takes three input values:
     o TEK, which is the key used by the underlying AES-128
     o M, which is a variable length message to process
     o P, which is an variable length prefix (possibly the empty
        string) to pre-pend to M

   OMAC1 produces one output value:


Bersani                 Expires û December 2004              [Page 21]


INTERNET-DRAFT                 EAP-PSK                      June 2004


     o T, which is a 128 bit tag resulting from the processing of the
        message.

   In Figure 8 below, we finally present the internals of EAX as used by
   EAP-PSK.

              Nonce N              Message M            Header H
            (128 bits)        (Variable Length V)       (9 bytes)
                |                      |                    |
      +-------------------+            |          +-------------------+
      |                   |            |          |                   |
      |   OMAC1(TEK,"0")  |            |          |   OMAC1(TEK,"1")  |
      |                   |            |          |                   |
      +-------------------+            |          +-------------------+
                |                      |                    |
                |             +----------------+            |
                |             |                |            |
                +------------>|  CTR(TEK,.,.)  |            |
                |             |                |            |
                |             +----------------+            |
                |                      |                    |
                |                      |                    |
                |                Cipher Text C              |
                |             (Variable Length V)           |
                |                      |                    |
                |                      |                    |
                |            +-------------------+          |
                |            |                   |          |
                |            |   OMAC1(TEK,"2")  |          |
                |            |                   |          |
                |            +-------------------+          |
                |                      |                    |
                |                      |                    |
                |                      |                    |
                |                  +-------+                |
                +----------------->|  XOR  |<---------------+
                                   +-------+
                                       |
                                     Tag T
                                   (128 bits)

   Figure 8: EAP-PSK Protected channel using EAX

   EAX takes three inputs:
     o The Nonce N that is used to provide security to encryption and
        authentication and to provide a replay counter
     o The Header H that will be authenticated but not encrypted
     o The Message M that will be authenticated and encrypted



Bersani                 Expires û December 2004              [Page 22]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   EAX takes a key, the TEK

   EAX produces two outputs:
     o The Cipher Text C, that is the result of the encryption of
        message M
     o The Tag, that is the MAC of H and M

2.3 EAP-PSK message flow

   EAP-PSK allows basically two different types of message flows:
     o The simple "standard authentication", which should be used most
        of the time
     o The "extended authentication", which consists in using a hook
        EAP-PSK provides (namely AT_EXT, see section 4.4.1) to extend it

2.3.1  EAP-PSK standard authentication

   Basically, EAP-PSK standard authentication is comprised of four
   messages (i.e. two round trips):
     o The first message is sent by the server to the peer an consists
        in a random challenge (AT_RAND)
     o The second message is sent by the peer to the server to state
        its identity (AT_ID), to send another random challenge
        (AT_RAND), and to authenticate itself by proving it is able to
        compute AT_MAC, which is a function of the two aforementioned
        challenges and the PSK
     o The third message is sent by the server to the peer to
        authenticate itself by proving it is able to compute another
        AT_MAC, which is computed as a function of the peer's challenge
        and the PSK (AT_MAC), to confirm the liveness of the derived
        session keys and to give a protected result indication of the
        authentication (AT_PCHANNEL)
     o The fourth message is sent by the peer to the server to confirm
        the liveness of the derived session keys and to give a protected
        result indication of the authentication (AT_PCHANNEL)

   Figure 9 below depicts the EAP-PSK standard authentication














Bersani                 Expires û December 2004              [Page 23]


INTERNET-DRAFT                 EAP-PSK                      June 2004


        Peer                                                      Server
          |                                        EAP-PSK/AT_RAND   |
          |<---------------------------------------------------------|
          |                                                          |
          |   EAP-PSK/AT_ID, AT_RAND, AT_MAC                         |
          |--------------------------------------------------------->|
          |                                                          |
          |                            EAP-PSK/AT_MAC, AT_PCHANNEL   |
          |<---------------------------------------------------------|
          |                                                          |
          |   EAP-PSK/AT_PCHANNEL                                    |
          |--------------------------------------------------------->|
          |                                                          |

   Figure 9: EAP-PSK standard authentication

   In Figure 9, AT_ID, AT_RAND, AT_MAC and AT_PCHANNEL stand for the
   different attributes that are exchanged. In particular, although two
   attributes may be of the same type (i.e. AT_RAND in message #1 and
   #2, AT_MAC in messages #2 and #3 or AT_PCHANNEL in messages #3 and
   #4), it should be understood that this does not mean that their
   payload is the same. For instance, AT_RAND in message #1 contains a
   random number chosen by the server whereas AT_RAND in message #2
   contains a random number chosen by the peer, which is with very high
   probability different from the one chosen by the server.

   This basic message flow could be comprised of only three messages,
   like AKEP2 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 includes a statement by the peer of its
   identity, in addition to the EAP-Request/Response Identity that has
   already occurred, as recommended in section 5.1 of [EAP].

   The exact behavior of the standard authentication is specified and
   discussed in section 3.

2.3.2  EAP-PSK extended authentication

   In order to remain simple and yet to be extensible to meet future
   requirements, EAP-PSK provides a hook: AT_EXT which is a generic
   attribute that can be used by extensions. This attribute is
   encapsulated in AT_PCHANNEL. It may be included in the AT_PCHANNEL of
   the third message of the EAP-PSK standard authentication and, if it
   is, it will be included in all subsequent AT_PCHANNEL attributes.

   See section 3, 5 and 6 for more discussion.



Bersani                 Expires û December 2004              [Page 24]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   Although AT_EXT support is mandatory, no particular extension is
   currently defined. Hence, the support of any particular extension
   type (EXT_Type, see section 4.4.1) is optionnal.

   Figure 10 below depicts an extended authentication

        Peer                                                      Server
          |                                        EAP-PSK/AT_RAND   |
          |<---------------------------------------------------------|
          |                                                          |
          |   EAP-PSK/AT_ID, AT_RAND, AT_MAC                         |
          |--------------------------------------------------------->|
          |                                                          |
          |         EAP-PSK/AT_MAC, AT_PCHANNEL(AT_STATUS, AT_ExT)   |
          |<---------------------------------------------------------|
          |                                                          |
          |   EAP-PSK/AT_PCHANNEL(AT_STATUS, AT_EXT)                 |
          |--------------------------------------------------------->|
          |                                                          |
          |                 EAP-PSK/AT_PCHANNEL(AT_STATUS, AT_ExT)   |
          |<---------------------------------------------------------|
          |                                                          |
          |   EAP-PSK/AT_PCHANNEL(AT_STATUS, AT_EXT)                 |
          |--------------------------------------------------------->|
          |                                                          |

   Figure 10: EAP-PSK extended authentication

2.4 Identity protection

   It has been chosen not include any identity protection scheme in EAP-
   PSK, see section 6.1 for more discussion.

2.5 Fast reconnect

   It has been chosen not to include any fast reconnect capability in
   EAP-PSK.

   Indeed, as noted for instance in [AKSD], mutual authentication
   (without counters or timestamps) requires three exchanges, thus four
   exchanges in EAP since any EAP-Request MUST be answered to by an EAP-
   Response. Since this minimum bound is already reached in EAP-PSK
   standard authentication, there is no way we can reduce within EAP-PSK
   the number of round-trips used in case of fast reconnect.

   However, there could be an obvious way to reduce the number of EAP-
   PSK round trips by using the EAP-Request/Identity and EAP-
   Response/Identity (which is not part of EAP-PSK) but the consequences
   of this have to be carefully evaluated (for instance, [NETSEL] also


Bersani                 Expires û December 2004              [Page 25]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   intends to reuse these messages). We therefore chose not to rely on
   unverified assumptions about external protocols.

   Since the processing and memory resources required by a standard EAP-
   PSK authentication are already very light, we chose not to try any
   hazardous optimization that would anyway have probably ended to be
   more complex, to make more efficient computations to provide fast
   reconnect. Such optimizations makes a lot more sense in cryptographic
   protocols that use both asymmetric and symmetric cryptography (e.g.
   TLS), when the asymmetric part can be avoided, as it is well known to
   be much more computation/memory intensive than the symmetric one.

   Furthermore, possible extensions of EAP (like the AMSK, see [EKMF])
   may well be used to provide fast reconnect in more efficient ways
   than EAP methods could do (by, for instance, in case of a roamer, not
   requiring a communication between the peer and the home server but
   allowing instead a conversation between the peer and the visited
   server).

2.6 Fragmentation

   EAP-PSK does not support fragmentation and reassembly.

   Indeed, for a standard authentication, the largest EAP-PSK frame is
   1004 bytes because we bounded the length of the identity used in EAP-
   PSK to 960 bytes, see 4.4.2 for more details. Since EAP has a header
   of 5 bytes and per [EAP] section 3.1, the lower layers over which EAP
   MAY be run are assumed to have an EAP MTU of 1020 bytes or greater,
   not supporting fragmentation for EAP-PSK standard authentication
   should not lead to any problem.

   In case extended authentication, it is the responsibility of the
   extension mechanism to handle their fragmentation (which can be done
   in an obvious way, see e.g. [EAP-TLS]). The security implications of
   fragmentation are discussed in section 6.13.

3. EAP-PSK state machines

   This section gives a formal description of the EAP-PSK peer and
   server state machines.

   First, it defines the conventions used for this description in
   subsection 3.1 and then proceeds to the actual description of the
   EAP-PSK peer state machine (in subsection 3.2) and EAP-PSK server
   state machine (in subsection 3.3).

   These EAP-PSK state machines take into account the EAP peer and
   server state machines that are defined in [EAP-SM] and interface to



Bersani                 Expires û December 2004              [Page 26]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   them. Thus, many conventions and notations in the sequel are directly
   derived from this document.

3.1 Conventions for the state machines

3.1.1  Rules of operation for the state machines

   Exactly one state of each state machine is active at any given time.

   In each state, there is one and only one transition which condition
   evaluates to true. Hence, there cannot be multiple possible
   transitions at the same given time.

   The state machines use variables and procedures.

   The variables are used to maintain state or to interface with other
   layers.

   The variables used by the state machines may be:
     o Long term, i.e. their value is maintained across different EAP-
        PSK dialogs
     o Short term, i.e. their value is particular to a specific EAP-PSK
        dialog

   The procedures are used to take some actions during an EAP-PSK
   dialog, e.g. check that a received EAP-PSK packet is well-formed
   (syntactically and/or cryptographically) or build a response to an
   received EAP-PSK packet.

   On entry to a state, the procedures defined for the state (if any)
   are executed exactly once, in the order that they appear on the page
   (in the table notation, see section 3.1.3). Each action is deemed to
   be atomic; i.e., execution of a procedure completes before the next
   sequential procedure starts to execute. No procedures execute outside
   of a state block. The procedures in only one state block execute at a
   time, even if the conditions for execution of state blocks in
   different state machines are satisfied, and all procedures in an
   executing state block complete execution before the transition to and
   execution of any other state block occurs, i.e., the execution of any
   state block appears to be atomic with respect to the execution of any
   other state block and the transition condition to that state from
   the previous state is TRUE when execution commences.

3.1.2  Graphical representation

   Figure 11 depicts the notation used in the EAP-PSK peer and server
   state machines graphical representations.




Bersani                 Expires û December 2004              [Page 27]


INTERNET-DRAFT                 EAP-PSK                      June 2004


       +-----------+          +-----------+
       |           |          |           |
       |  STATE_X  |----+---->|  STATE_Y  |
       |           |    |     |           |
       +-----------+    |     +-----------+
                        |
       +-----------+    |
       |           |    |
       |  STATE_Z  |<---+
       |           |
       +-----------+

   Figure 11: Example state machine graphical representation

   The graphical representation of a state machine only shows the
   different states and the possible transitions between these states.
   It does not show the procedures to execute on entry to a state and
   the transition conditions (they are shown in the table
   representation, see section 3.1.3). The goal of the graphical
   representation of a state machine is to give a compact overview of
   the protocol.

   In the graphical representation of a state machine, each state is
   represented as a rectangular box that contains the name of the state.

   All permissible transitions between different states are represented
   by arrows, the arrowhead denoting the direction of the possible
   transition. Thus, in Figure 11, there are permissible transitions
   from X to Y and X to Z (but not from Z to X, for instance).

3.1.3  Table representation

   Figure 12 below depicts the table representation of the EAP-PSK peer
   state machine.

   -----------------------------+------------------------+--------------
   X                            |   XCounter==0          |             Y
                                |------------------------+--------------
   XCounter++                   |   XCounter==1          |             Z
   -----------------------------+------------------------+--------------

   Figure 12: Example state machine table representation

   The notation is as follows: state name and procedure executed when
   entering it are shown on the left; outgoing transitions with their
   conditions are shown on the right.





Bersani                 Expires û December 2004              [Page 28]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The procedures and transition conditions are expressed in pseudo-
   code, derived of the notation of the C++ programming language,
   ISO/IEC 14882. We briefly recall the symbols we use:

   ( )

      Used to force the precedence of operators in Boolean expressions
      and to delimit the argument(s) of actions within state boxes.

   ;

      Used as a terminating delimiter for actions within state boxes.
      Where a state box contains multiple actions, the order of
      execution follows the normal English language conventions for
      reading text.

   =

      Assignment action. The value of the expression to the right of the
      operator is assigned to the variable to the left of the operator.

   !

      Logical NOT operator.

   &&

      Logical AND operator.

   !=

      Inequality. Evaluates to TRUE if the expression to the left of the
      operator is not equal in value to the expression to the right.

   ==

      Equality. Evaluates to TRUE if the expression to the left of the
      operator is equal in value to the expression to the right.

   ++
      Incrementation by one of an integer.

3.2 EAP-PSK peer state machine

3.2.1  Variables and procedures

   The EAP-PSK peer state machine uses the interface variables with the
   EAP state machine defined in [EAP-SM] that we briefly recall here
   after:


Bersani                 Expires û December 2004              [Page 29]


INTERNET-DRAFT                 EAP-PSK                      June 2004



      eapReqData (EAP packet)

   The contents of the available EAP request

      ignore (boolean)

   A flag indicating whether the method has decided to drop the current
   packet

      methodState (enumeration)

   The method state (INIT, CONT, MAY_CONT, DONE)

      decision (enumeration)

   The peer's decision regarding the success or not of the
   authentication (FAIL, COND_SUCC, UNCOND_SUCC)

      allowNotifications (boolean)

   A flag indicating whether the peer allows EAP to process EAP
   Notifications during the method's conversation. This flag is
   systematically set to FALSE by EAP-PSK (see 6.9).

      eapRespData (EAP Packet)

   The EAP packet which is the response to send. Please note that
   normally this variable is not considered as an interface with the
   method in [EAP-SM] but it is in our setting since we slightly
   modified the procedure m.process() defined in [EAP-SM] (see below).

   In addition to these interface variables, the EAP-PSK peer state
   machine uses the following long-term variables which are initialized
   by the peer before the first EAP-PSK dialog:

      PSK.AK (128 bit string)

   The AK portion of the PSK (see section 2.1.1)

      PSK.KDK (128 bit string)

   The KDK portion of the PSK (see section 2.1.1)

      PeerNAI (NAI)

   The NAI used by the peer as its identity (see section 2.2.1). This
   NAI is limited to 960 bytes (see section 4.4.2).



Bersani                 Expires û December 2004              [Page 30]


INTERNET-DRAFT                 EAP-PSK                      June 2004


      ServerNAI (NAI)

   The NAI that the server to which the peer wants to authenticate uses
   as its identity (see section 2.2.1). This NAI is limited to 960 bytes
   (see section 4.4.2).

   In addition to these interface variables and its long term variables,
   the EAP-PSK peer state machine uses the following short-term
   variables which are specific to a particular EAP-PSK dialog:

      RandServer (128 bits string)

   The random number sent by the server (see section 2.2.1)

      RandPeer (128 bit string)

   The random number chosen by the peer (see section 2.2.1)

      IsKeyAvailable (Boolean)

   A flag that indicates whether keying material is made available by
   EAP-PSK for EAP (see section 6.3)

      TEK (128 bit string)

   The Transient EAP Key (see section 2.1.2)

      MSK (256 byte string)

   The Master Session Key (see section 2.1.3)

      EMSK (256 byte string)

   The Extended Master Session Key (see section 2.1.4)

      PChannelNonce (32 bit string)

   The next value the nonce in the protected channel must take (see
   section 2.2.2)

      PchannelSuccess (boolean)

   A flag indicating that the server has sent an AT_STATUS which Status
   field was set to DONE_SUCCESS.

      ExtChosen (8 bit string or NONE)

   The type of the extension that has been chosen (if any) for the
   conversation over the protected channel


Bersani                 Expires û December 2004              [Page 31]


INTERNET-DRAFT                 EAP-PSK                      June 2004



      ExtUnkown(boolean)

   A flag indicating that an AT_EXT of a type that the peer was unable
   to process has been received (in which case it is set to TRUE)

   In addition to these variables, the EAP-PSK uses procedures.

   First, it uses the interface procedures with the EAP state machine
   defined in [EAP-SM] that we briefly recall here after.

      m.Check()

   Method procedure to test for the validity of a message.

   Please note that the actual procedure executed depends on the state
   of EAP-PSK. Namely, EAP-PSK uses four subprocedures within m.Check():
     o m.Check_INIT()
     o m.Check_ID&MACSENT()
     o m.Check_PCHANNEL()
     o m.Check_SUCCFAIL.

   m.Check_INIT() is the instantiation of m.Check() while in the INIT
   state (see section 3.2.2).
   It returns FALSE iff the received EAP-PSK message is exactly
   comprised of an AT_RAND that complies with the format defined in
   section 4.4.5.
   Thus, m.Check_INIT() only performs a syntactic check.

   m.Check_ID&MACSENT()is the instantiation of m.Check() while in the
   ID&MACSENT state (see section 3.2.2).
   It returns FALSE iff
     o The received EAP-PSK message is exactly comprised of an AT_MAC
        and an AT_PCHANNEL that comply with the formats defined in
        sections 4.4.3 and 4.4.4
     o And the value of the MAC field of AT_MAC is equal to the value
        the peer expects given the random number sent by the server and
        the one he has chosen (see section 2.2.1)
     o And the Nonce field of AT_PCHANNEL is equal to PChannelNonce and
        the Tag field of AT_PCHANNEL is equal to the value expected (see
        section 2.2.2)
     o And the decrypted payload of AT_PCHANNEL is syntactically and
        semantically correct.
   The decrypted payload of AT_PCHANNEL is said to be syntactically
   correct iff it is comprised
     o Either exactly of an AT_STATUS that complies with the format
        defined in section 4.4.6
     o Or exactly of an AT_STATUS and an AT_EXT that comply with the
        formats defined in sections 4.4.6 and 4.4.1.


Bersani                 Expires û December 2004              [Page 32]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The decrypted payload of AT_PCHANNEL is said to be semantically
   correct iff
     o The AT_EXT attribute (if any) is semantically correct, i.e.:
        o When ExtChosen==NONE, it only consists of an AT_STATUS
        o When ExtChosen!=NONE, it consists of an AT_STATUS and an
          AT_EXT which EXT_Type field is equal to ExtChosen
     o The AT_STATUS is semantically correct, i.e.:
        o The Status field can be set to CONT only if there is an
          AT_EXT included within the AT_PCHANNEL
        o When PchannelSuccess==TRUE, the Status field of AT_STATUS is
          equal to DONE_SUCCESS
        o When ExtUnknown is set to TRUE, the Status field of AT_STATUS
          is equal to DONE_SUCCESS or DONE_FAILURE
   Thus, m.Check_ID&MACSENT() performs:
     o A syntactic check on the whole message
     o A cryptographic check on AT_MAC
     o A cryptographic check on AT_PCHANNEL
     o And a syntactic and semantic check on the decrypted payload.
   It is RECOMMENDED that these checks be performed in the order in
   which they are specified here above and that no further checks be
   performed as soon as one has failed (see 6.3 for more discussion).
   Please note, that to perform the cryptographic checks on AT_PCHANNEL,
   m.Check_ID&MACSENT() needs to derive the TEK. Thus we mandate that
   m.Check_ID&MACSENT() also derive the MSK and the EMSK and assign
   these values to the appropriate variables (TEK, MSK and EMSK).

   m.Check_PCHANNEL()is the instantiation of m.Check() while in the
   PCHANNEL state (see section 3.2.2).
   It returns FALSE iff:
     o The received EAP-PSK message is exactly comprised of an
        AT_PCHANNEL that comply with the format defined in sections
        4.4.4
     o And which Nonce field is equal to PChannelNonce and which Tag
        field is equal to the value expected (see section 2.2.2)
     o And which decrypted payload is syntactically and semantically
        correct.
   Thus m.Check_PCHANNEL()performs:
     o A syntactic check on the whole message
     o A cryptographic check on AT_PCHANNEL
     o And a syntactic and semantic check on the decrypted payload.

   m.Check_SUCCFAIL()is the instantiation of m.Check() while in the
   FAILURE or SUCCESS states (see section 3.2.2).
   It always returns TRUE.
   Thus, it does not perform any checks, it is merely defined to ensure
   that no EAP-PSK packets be processed once the (EAP-PSK) FAILURE or
   SUCCESS states have been reached.




Bersani                 Expires û December 2004              [Page 33]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   Please, see sections 6.9 and 6.10 for some more discussion on the
   security of m.check().

      m.process()

   Method procedure to parse and process a request for EAP-PSK.
   The input to m.process is eapReqData and its output is (methodState,
   decision, allowNotifications, eapRespData): please note here that we
   slightly modified the notations of [EAP-SM] and added eapRespData to
   the output of m.process (that is to say we collapsed m.process() and
   m.build() into a single procedure seeing no point in keeping them
   separate).
   Please also note that the actual procedure executed depends on the
   state of EAP-PSK. Namely, EAP-PSK uses two subprocedures within
   m.process():
     o m.process_INIT()
     o And m.process_PCHANNEL()
   There are only tswo subprocedures for m.process() compared to the
   four subprocedures of m.Check because no EAP packet is sent in the
   ID&MACSENT, SUCCESS and FAILURE states.

   m.process_INIT() is the instantiation of m.process() while in the
   INIT state (see section 3.2.2).
   It takes eapReqData as input and outputs (CONT, FAIL, FALSE,
   eapRespData) where eapRespData is an EAP response packet of type EAP-
   PSK that consists in an AT_RAND which RAND field is equal to
   RandPeer, an AT_ID which Identity field is equal to PeerNAI and an
   AT_MAC which MAC value corresponds to the value specified in section
   2.2.1.
   m.process_INIT() makes the following computations before outputting
   its result:
     o It stores the RAND field of the received AT_RAND in RandServer
     o It chooses at random a 128 bit number and stores it in RandPeer
     o It computes the MAC field of the AT_MAC it is going to send
        according to section 2.2.1 using PSK.AK, RandPeer, RandServer,
        PeerNAI and ServerNAI.

   m.process_PCHANNEL()is the instantiation of m.process() while in the
   PCHANNEL state (see section 3.2.2).
   It takes eapReqData as input and outputs (methodState, decision,
   FALSE, eapRespData) where eapRespData is an EAP response packet
   comprised of an AT_PCHANNEL that complies with the cryptographic and
   synctactic rules defined in sections 2.2.2 and 4.4.4
   and which (decrypted) payload complies with the syntactic rules
   defined in sections 4.4.1 and 4.4.6
   and which payload complies with the following semantic rules:
     o The extension is semantically correct, i.e. an AT_EXT is
        included iff ExtChosen!=NONE and in case, ExtChosen!=NONE, the
        EXT_Type field of this AT_EXT is equal to ExtChosen


Bersani                 Expires û December 2004              [Page 34]


INTERNET-DRAFT                 EAP-PSK                      June 2004


     o The status is semantically correct, i.e. its Status field is in
        adequation with the decision output by m.process_PCHANNEL() (see
        below)
   To compute its decision, thee peer uses the Status field of the
   decrypted payload of the received AT_PCHANNEL as follows, depending
   on its policy:
     o If this Status field is equal to DONE_SUCCESS
        o It may take the decision UNCOND_SUCC and, in this case,
          chooses methodState to be DONE and sets its Status field to
          DONE_SUCCESS
        o It may take the decision to stay to its current FAIL decision
          because it needs more information to make a decision and, in
          this case, it chooses methodState to be CONT and sets its
          Status field to CONT
        o It may take the decision to irremediably fail and stay with
          its FAIL decision because it is sure it will not make it to
          SUCCESS, and, in this case, it chooses methodState to be DONE
          and sets its Status field to DONE_FAILURE
     o If this Status field is equal to DONE_FAILURE, it MUST take the
        decision FAIL, choose methodState to be DONE and set its Status
        field to DONE_FAILURE
     o If this Status field is equal to CONT
        o It may stay to the decision FAIL, choose methodState to be
          CONT and set its Status field to CONT
        o or it may stay to the decision FAIL, choose methodState to be
          DONE and set its Status field to DONE_FAILURE
   See section 6.9 for some discussion on these rules.
   m.process_PCHANNEL() makes the following computations before
   outputting its result:
     o If ExtChosen==NONE and there is no AT_EXT in the decrypted
        payload of the received AT_PCHANNEL
        o If the Status field of the received AT_STATUS is set to
          DONE_SUCCESS, the peer sets PChannelSuccess to TRUE and
          consults its policy to take either the decision UNCOND_SUCC
          or (irremediably) FAIL. In case, it takes the decision FAIL,
          it chooses methodState to be DONE and sets its Status field
          to DONE_FAILURE (i.e. it is not allowed to choose methodState
          to be CONT and set its Status field to CONT). In either
          cases, the peer increments PChannelNonce, encapsulates the
          corresponding AT_STATUS within an AT_PCHANNEL and sends an
          EAP-PSK packet containing this AT_PCHANNEL.
        o If the Status field of the received AT_STATUS is set to
          DONE_FAILURE, the peer must take the decision FAIL as
          explained above. The peer increments PChannelNonce,
          encapsulates the corresponding AT_STATUS within an
          AT_PCHANNEL and sends an EAP-PSK packet containing this
          AT_PCHANNEL.
     o If ExtChosen==NONE and there is an AT_EXT in the decrypted
        payload of the received AT_PCHANNEL


Bersani                 Expires û December 2004              [Page 35]


INTERNET-DRAFT                 EAP-PSK                      June 2004


        o If the peer is not able to process an AT_EXT of this type, it
          sets ExtUnknown to TRUE and ExtChosen to the type of this
          received AT_EXT. If the Status field of the received
          AT_STATUS is set to DONE_SUCCESS, the peer sets
          PChannelSuccess to TRUE. It consults its policy to take its
          decision. It outputs the corresponding methodState and
          decision, increments PChannelNonce and sends an EAP-PSK
          packet containing an AT_PCHANNEL with the adequate AT_STATUS
          and the AT_EXT it has received with the flag U(nrecognized)
          armed (see section 4.4.1)
        o If the peer is able to process an AT_EXT of this type, it
          sets ExtChosen to the type of this received AT_EXT. If the
          Status field of the received AT_STATUS is set to
          DONE_SUCCESS, the peer sets PChannelSuccess to TRUE. It
          processes the AT_EXT and the received AT_STATUS. It consults
          its policy to take its decision. It outputs the corresponding
          methodState and decision, increments PChannelNonce and sends
          an EAP-PSK packet containing an AT_PCHANNEL with the adequate
          AT_STATUS and a response AT_EXT of type ExtChosen
     o If ExtChosen!=NONE
        o If ExtUnknown==TRUE, then the peer consults its policy to
          take its decision. If the Status field of the received
          AT_STATUS is set to DONE_SUCCESS, the peer sets
          PChannelSuccess to TRUE. It outputs the corresponding
          methodState and decision, increments PChannelNonce and sends
          an EAP-PSK packet containing an AT_PCHANNEL with the adequate
          AT_STATUS and the AT_EXT it has received with the flag
          U(nrecognized) armed (see section 4.4.1)
        o If ExtUnkown==FALSE, the peer processes the AT_EXT and the
          received AT_STATUS. If the Status field of the received
          AT_STATUS is set to DONE_SUCCESS, the peer sets
          PChannelSuccess to TRUE. It consults its policy to take its
          decision. It outputs the corresponding methodState and
          decision, increments PChannelNonce and sends an EAP-PSK
          packet containing an AT_PCHANNEL with the adequate AT_STATUS
          and a response AT_EXT of type ExtChosen

      m.isKeyAvailable()

   Method procedure to signal that keying material is available.
   Within EAP-PSK, we simply have m.isKeyAvailable()=isKeyAvailable.

      m.getKey()

   Method procedure to obtain key material for use by EAP or lower
   layers.
   Within EAP-PSK, we simply have m.isKeyAvailable()=MSK||EMSK




Bersani                 Expires û December 2004              [Page 36]


INTERNET-DRAFT                 EAP-PSK                      June 2004


3.2.2  Graphical representation

   Figure 13 below is the EAP-PSK peer state machine graphical
   representation.

                                                          +------------+
                                                          |            |
                                                 +------->|  SUCCESS   |
                                                 |        |            |
                                                 |        +------------+
                                                 |
                                                 |
       +------------+    +------------+    +-----+------+
       |            |    |            |    |            |<-----+
   --->|    INIT    |--->| ID&MACSENT |--->|  PCHANNEL  |      |
       |            |    |            |    |            |------+
       +------------+    +------------+    +-----+------+
                                                 |
                                                 |
                                                 |        +------------+
                                                 |        |            |
                                                 +------->|  FAILURE   |
                                                          |            |
                                                          +------------+

   Figure 13: EAP-PSK Peer state machine graphical representation

   Please note that the SUCCESS and FAILURE states depicted in Figure 13
   are specific to the EAP-PSK peer state machine: they must not be
   confused with the EAP state machine states that bear the same name in
   [EAP-SM].

3.2.3  Table representation

   Figure 14 below is the EAP-PSK peer state machine graphical
   representation.















Bersani                 Expires û December 2004              [Page 37]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   -------------------------------+------------------------+------------
   INIT                           |                        |
                                  |                        |
   IsKeyAvailable=FALSE;          |                        |
   PChannelNonce=0;               |                        |
   (methodState,decision,         |                        | ID&MACSENT
    allowNotifications,           |                        |
    eapRespData)=                 |                        |
   m.process_INIT(eapReqData)     |                        |
   -------------------------------+------------------------+------------
   ID&MACSENT                     |                        |
                                  |                        |
                                  |                        | PCHANNEL
   Hand over  the decrypted       |                        |
   payload                        |                        |
   and the EAP identifier         |                        |
   -------------------------------+------------------------+------------
   PCHANNEL                       |                        |
                                  |  methodState==DONE &&  | SUCCESS
   (methodState,decision,         |  decision==UNCOND_SUCC |
    allowNotifications,           |                        |
    eapRespData)=                 +------------------------+------------
   m.process_PCHANNEL(eapReqData);|                        |
   PChannelNonce++                |  methodState==DONE &&  | FAILURE
                                  |  decision==FAIL        |
                                  |                        |
                                  +------------------------+------------
                                  |                        |
                                  |  methodState==CONT &&  | PCHANNEL
                                  |  decision==FAIL        |
   -------------------------------+------------------------+------------
   SUCCESS                        |                        |
   -------------------------------+------------------------+------------
   FAILURE                        |                        |
   -------------------------------+------------------------+------------

   Figure 14: EAP-PSK Peer state machine table representation

   For the sake of simplicity, we did not define formally the procedure
   "Hand over the decrypted payload and the EAP identifier" used in the
   ID&MACSENT state. Through this procedure, the decrypted payload is
   handed over to be acted upon by the PCHANNEL state (AT_STATUS and
   AT_EXT processing in case it is present) and the EAP Identifier is
   handed over so that the appropriate EAP response may be built in the
   PCHANNEL state (including the cryptographic protection of the EAP
   Identifier thanks to the Tag field of AT_PCHANNEL).

3.3 EAP-PSK server state machine



Bersani                 Expires û December 2004              [Page 38]


INTERNET-DRAFT                 EAP-PSK                      June 2004


3.3.1  Variables and Procedures

   The EAP-PSK server state machine uses the interface variables with
   the EAP state machine defined in [EAP-SM] that we briefly recall here
   after:

      eapReqData (EAP packet)

   The EAP packet to send (i.e. a request).

      eapRespData (EAP Packet)

   The EAP packet to be processed (i.e. a response).

      ignore (boolean)

   A flag indicating whether the method has decided to drop the current
   packet

      methodState (enumeration)

   The method state (CONTINUE, END)

      decision (enumeration)

   The server's decision regarding the success or not of the
   authentication (FAILURE or SUCCESS). Since EAP explicitly forbids
   using a sequence of authentication methods, we shall indeed not
   consider the decision CONTINUE that is proposed in [EAP-SM].

   In addition to these interface variables, the EAP-PSK server state
   machine uses the following long-term variables which are initialized
   by the server before the first EAP-PSK dialog:

      PSK.AK (128 bit string)

   The AK portion of the PSK (see section 2.1.1)

      PSK.KDK (128 bit string)

   The KDK portion of the PSK (see section 2.1.1)

      ServerNAI (NAI)

   The NAI used by the server as its identity (see section 2.2.1). This
   NAI is limited to 960 bytes (see section 4.4.2).

      PeerNAI (NAI)



Bersani                 Expires û December 2004              [Page 39]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The NAI of the peer used by the peer as its identity (see section
   2.2.1). This NAI is limited to 960 bytes (see section 4.4.2).

   Please note that a server will typically have to authenticate
   multiple peers. Hence, it is up to the server to store appropriately
   the different long-term EAP-PSK variables corresponding to these
   different peers and to retrieve the relevant information when needed
   (thanks to the communicating peer's identity included in the first
   EAP-PSK message received from the peer, see section 2.3.1).

   In addition to these interface variables and its long term variables,
   the EAP-PSK peer state machine uses the following short-term
   variables which are specific to a particular EAP-PSK dialog:

      RandServer (128 bits string)

   The random number chosen by the server (see section 2.2.1)

      RandPeer (128 bit string)

   The random number sent by the peer (see section 2.2.1)

      TEK (128 bit string)

   The Transient EAP Key (see section 2.1.2)

      MSK (256 byte string)

   The Master Session Key (see section 2.1.3)

      EMSK (256 byte string)

   The Extended Master Session Key (see section 2.1.4)

      PChannelNonce (32 bit string)

   The next value the nonce in the protected channel must take (see
   section 2.2.2)

      PchannelStatus (enumeration)

   The last value sent by the server in the Status field of AT_STATUS
   (DONE_SUCCESS, DONE_FAILURE, CONT).

      ExtChosen (8 bit string or NONE)

   The type of the extension that the server will choose (if any) for
   the conversation over the protected channel



Bersani                 Expires û December 2004              [Page 40]


INTERNET-DRAFT                 EAP-PSK                      June 2004


      ExtUnkown(boolean)

   A flag indicating that an AT_EXT of a type that the peer was unable
   to process has been received (in which case it is set to TRUE)

   isDone(boolean)

   A flag indicating that the method is done.

   In addition to these variables, the EAP-PSK uses procedures.

   First, it uses the interface procedures with the EAP state machine
   defined in [EAP-SM] that we briefly recall here after.

      m.Check()

   Method procedure to test for the validity of a message.

   Please note that the actual procedure executed depends on the state
   of EAP-PSK. Namely, EAP-PSK uses two subprocedures within m.Check():
     o m.Check_RANDSENT()
     o m.Check_PCHANNEL()

   m.Check__RANDSENT() is the instantiation of m.Check() while in the
   RANDSENT state (see section 3.3.2).
   It returns FALSE iff
     o The received EAP-PSK message is exactly comprised of an AT_RAND,
        an AT_ID and an AT_MAC that comply with the format defined in
        section 4.4.5, 4.4.2 and 4.4.3.
     o And the value of the MAC field of the received AT_MAC is equal
        to the value the server expects given the random number it sent
        and the one the peer sent in the RAND field of AT_RAND (see
        section 2.2.1)
   Thus, m.Check__RANDSENT()performs
     o A syntactic check on the whole message
     o And a cryptographic check on AT_MAC

   m.Check_PCHANNEL() is the instantiation of m.Check() while in the
   PCHANNEL state (see section 3.3.2).
   It returns FALSE iff
     o The received EAP-PSK message is exactly comprised of an
        AT_PCHANNEL that complies with the formats defined in section
        4.4.4
     o And the Nonce field of AT_PCHANNEL is equal to PChannelNonce and
        the Tag field of AT_PCHANNEL is equal to the value expected (see
        section 2.2.2)
     o And the decrypted payload of AT_PCHANNEL is syntactically and
        semantically correct.



Bersani                 Expires û December 2004              [Page 41]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The decrypted payload of AT_PCHANNEL is said to be syntactically
   correct iff it is comprised
     o Either exactly of an AT_STATUS that complies with the format
        defined in section 4.4.6
     o Or exactly of an AT_STATUS and an AT_EXT that comply with the
        formats defined in sections 4.4.6 and 4.4.1.
   The decrypted payload of AT_PCHANNEL is said to be semantically
   correct iff
     o The AT_EXT attribute (if any) is semantically correct, i.e.:
        o When ExtChosen==NONE, it only consists of an AT_STATUS
        o When ExtChosen!=NONE, it consists of an AT_STATUS and an
          AT_EXT which EXT_Type field is equal to ExtChosen
        o When ExtUnknown==TRUE, the flage U(nrecongnized) of the
          received AT_EXT is armed
     o The AT_STATUS is semantically correct, i.e.:
        o The Status field may be set to CONT only if there is an
          AT_EXT included within the AT_PCHANNEL
        o The Status field of the received AT_STATUS may only be equal
          to DONE_SUCCESS when PchannelStatus==DONE_SUCCESS
        o The Status field of the received AT_STATUS MUST be equal to
          DONE_FAILURE when PchannelStatus==DONE_SUCCESS
   Thus, m.Check_PCHANNEL() performs:
     o A syntactic check on the whole message
     o A cryptographic check on AT_PCHANNEL
     o And a syntactic and semantic check on the decrypted payload.
   It is RECOMMENDED that these checks be performed in the order in
   which they are specified here above and that no further checks be
   performed as soon as one has failed (see 6.3 for more discussion).

   Please, see sections 6.9 and 6.10 for some more discussion on the
   security of m.check().

      m.init()

   When the method is first started, it must initialize its own method-
   specific state. EAP-PSK initializes its state by choosing a 128 bit
   number at random and storing it in RandServer.

      m.process()

   Method procedure to parse and process a response for RAP-PSK.
   The input to m.process is eapResData and it has no output.
   Please note that the actual procedure executed depends on the state
   of EAP-PSK. Namely, EAP-PSK uses two subprocedures within
   m.process():
     o m.process_RANDSENT()
     o And m.process_PCHANNEL()




Bersani                 Expires û December 2004              [Page 42]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   m.process_RANDSENT() is the instantiation of m.process() while in the
   RANDSENT state (see section 3.3.2).
   It takes eapResData as input and has no output.
   m.process_RANDSENT () makes the following computations before
   outputting its result:
     o It stores the RAND field of the received AT_RAND in RandPeer
     o It stores the identity field of AT_ID in PeerNAI and uses it to
        retrieve and properly instantiate the relevant PSK.AK, PSK.KDK
        and ServerNAI
     o It instantiates PChannelNonce to 0
     o It consults its policy to instantiate ExtChosen (to NONE or a
        particular value)
     o It instantiates ExtUnknown to FALSE
     o It consults its policy to instantiate PChannelStatus
     o It instantiates the flag isDone to FALSE
     o It derives the TEK, MSK and EMSK and stores them in the
        appropriate variables

   m.process_PCHANNEL()is the instantiation of m.process() while in the
   PCHANNEL state (see section 3.2.2).
   It takes eapRespData as input and has no output.
     o If isKeyAvailable is set to FALSE, it sets it to TRUE.
     o If there is an AT_EXT encapsulated in the received AT_PCHANNEL
        that does not have the U flag armed, it hands it over for
        processing to the appropriate plugin together with the Status
        field of the received AT_STATUS.
     o If there is an AT_EXT encapsulated in the received AT_PCHANNEL
        that has the U flag armed, it sets ExtUnknown to TRUE
     o It sets isDone to TRUE iff the Status field of the received
        AT_STATUS is equal to DONE_SUCCESS or DONE_FAILURE.

      m.isKeyAvailable()

   Method procedure to signal that keying material is available.
   Within EAP-PSK, we simply have m.isKeyAvailable()=isKeyAvailable.

      m.getKey()

   Method procedure to obtain key material for use by EAP or lower
   layers.
   Within EAP-PSK, we simply have m.isKeyAvailable()=MSK||EMSK

      m.getTimeout()

   EAP-PSK can provide a hint for retransmission timeout. No specific
   hint is specified for EAP-PSK standard authentication. There is
   indeed no need to do so because EAP-PSK standard authentication does
   not require user interaction. However, in case extended



Bersani                 Expires û December 2004              [Page 43]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   authentication is used, it may become useful to specify such a hint
   depending on the EXT_Type (see sections 2.3.2 and 4.4.1).

      m.buildReq()

   Method procedure to build a request packet.
   Please note that the actual procedure executed depends on the state
   of EAP-PSK. Namely, EAP-PSK uses two subprocedures within
   m.buildReq():
     o m.buildReq_INIT()
     o m.buildReq.RANDSENT()
     o And m.buildReq_PCHANNEL()

   m.buildReq_INIT() is the instantiation of m.buildReq() while in the
   INIT state (see section 3.3.2).
   Basically, it send an EAP-PSK request that merely consists in an
   AT_RAND (which RAND field contains the random number stored in
   RandServer).

   m.buildReq_RANDSENT() is the instantiation of m.buildReq() while in
   the RANDSENT state (see section 3.3.2).
   It sends an EAP-PSK request that consists in an AT_MAC calculated as
   specified in section 2.2.1 and an AT_PCHANNEL calculated as specified
   in section 2.2.2.
   The payload of AT_PCHANNEL depends on the server's policy:
   If ExtChosen==NONE, the payload only consists in an AT_STATUS which
   Status field may take the value DONE_SUCCESS or DONE_FAILURE
   depending on the server's policy.
   If ExtChosen!=NONE, the payload contains an AT_STATUS and an AT_EXT
   of EXT_Type ExtChosen. The Status field of AT_STATUS may take the
   value CONT, DONE_SUCCESS or DONE_FAILURE depending on the server's
   policy.
   After sending the AT_PCHANNEL, m.buildReq_RANDSENT() increments
   PChannelNonce and possibly updates PChannelStatus.

   m.buildReq_PCHANNEL() is the instantiation of m.buildReq() while in
   the PCHANNEL state (see section 3.3.2).
   It sends an EAP-PSK request that consists in an AT_PCHANNEL
   calculated as specified in section 2.2.2.
   If the server sends a packet in this state, this means that
   ExtChosen!=NONE. Hence, the payload of AT_PCHANNEL consists in an
   AT_STATUS and an AT_EXT.
   If ExtUnkown==TRUE, then the server sends an AT_EXT of type ExtChosen
   with no payload (this was specified for it is believed to simplify
   implementations) and an AT_STATUS which Status field may take the
   value DONE_SUCCESS or DONE_FAILURE depending on the server's policy.
   If ExtUnknown==FALSE, then the server sends an AT_EXT of type
   ExtChosen (which payload is given by the extension plugin) and an



Bersani                 Expires û December 2004              [Page 44]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   AT_STATUS which Status field may take the value CONT, DONE_SUCCESS or
   DONE_FAILURE depending on the server's policy.
   After sending the AT_PCHANNEL, m.buildReq_RANDSENT() increments
   PChannelNonce and possibly updates PChannelStatus.

3.3.2  Graphical representation

   Figure 15 below is the EAP-PSK server state machine graphical
   representation.

       +------------+    +------------+    +------------+
       |            |    |            |    |            |<-----+
   --->|    INIT    |--->|  RANDSENT  |--->|  PCHANNEL  |      |
       |            |    |            |    |            |------+
       +------------+    +------------+    +------------+

   Figure 15: EAP-PSK Server state machine graphical representation

3.3.3  Table representation

   Figure 16 below is the EAP-PSK peer state machine graphical
   representation.
   -------------------------------+------------------------+------------
   INIT                           |                        |
                                  |                        |
   m.init()                       |                        |   RANDSENT
   -------------------------------+------------------------+------------
   RANDSENT                       |                        |
                                  |                        |
   m.process_RANDSENT             |                        |   PCHANNEL
   -------------------------------+------------------------+------------
   PCHANNEL                       |                        |
                                  |                        |
   m.process_PCHANNEL             |                        |   PCHANNEL
   -------------------------------+------------------------+------------


   Figure 16: EAP-PSK Server state machine table representation

   This table representation is pretty straightforward as all the
   procedures are concentrated in m.Check(), m.process and m.buildReq().

4. EAP-PSK message format

4.1 General format of an EAP-PSK message

   An EAP-PSK message is merely a concatenation of EAP-PSK attributes.




Bersani                 Expires û December 2004              [Page 45]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The order in which these attributes are concatenated has no
   importance whatsoever.

   When encapsulated in EAP, an EAP-PSK message has the following
   format, depicted in Figure 17 below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |                     AT_1 ...                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      |                             AT_n                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 17: Generic format of an EAP packet of Type EAP-PSK

   In Figure 17,:
     o Code is an EAP field that can be 1 (Request) or 2 (Response)
     o Identifier is a one byte EAP field that helps match the requests
        and the responses
     o Length is the total length of the EAP packet in bytes
     o Type is the type number to be defined allocated to EAP-PSK (see
        section 5.1).
     o AT_1, ...., AT_n is a concatenation of EAP-PSK attributes

4.2 Generic format of an EAP-PSK attribute

   Figure 18 below depicts the generic format of an EAP-PSK attribute.

       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_EXAMPLE   |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 18: Generic format of an EAP-PSK attribute

   An EAP-PSK attribute always start with a one byte field called the
   EAP-PSK Type field of the attribute. When it is clear from context
   (i.e. there can be no confusion with the EAP Type field, see section
   4.1), this field is simply called the Type field.

   The EAP-PSK Type field of the attribute is generally followed by a
   length field that indicates the total length of the attribute
   (including its header) in multiple of 32 bit words (thus payloads
   that are not necessarily aligned on 32 bit boundaries provide a



Bersani                 Expires û December 2004              [Page 46]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   padding scheme - see for instance section 4.4.2)and a Reserved field,
   which is set to zero when sending and ignored on reception.

4.3 Table of the Type field of the different attributes

   The table below presents the value of the EAP-PSK Type field of the
   different EAP-PSK attributes

   Attribute Name              Type Field Value
   AT_EXT                             1
   AT_ID                              2
   AT_RAND                            3
   AT_MAC                             4
   AT_PCHANNEL                        5
   AT_STATUS                          6

4.4 Format of the different EAP-PSK attributes

   This section presents the respective formats of the different
   attributes listed in alphabetical order.

4.4.1  AT_EXT

   The AT_EXT attribute is used to allow implementation of extensions to
   EAP-PSK.

   The format of the AT_EXT 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_EXT     |    Length    _|    EXT_Type   |U|  Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                         EXT_Payload                           :
      :   .                                                           :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_EXT is defined in section 2.2.2 and 3.

   The EXT_Type is a one byte field that indicates the type of the
   AT_EXT payload. This type number is allocated by IANA (see section
   5.2)

   The flag U (like Unrecognized) is used to indicate that the EXT_Type
   was not recognized. It is set to 1 when this is the case. This flag
   may only be set by the peer.



Bersani                 Expires û December 2004              [Page 47]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The EXT_Payload depends on the EXT_Type.

4.4.2  AT_ID

   The AT_ID attribute is used by the peer to state its identity.

   The format of the AT_ID 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_ID      |    Length     |    Actual Identity Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                          Identity                             :
      :   .                                                           :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_ID is defined in Section 2.3.1 and 3.

   The value field of this attribute begins with the 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.

   To avoid fragmentation issues, the length of the Identity field has
   been bounded to 960 bytes (i.e. two hundred and forty 32 bit words),
   which should be enough for most identities.

4.4.3  AT_MAC

   The AT_MAC attribute is used for authentication within EAP-PSK.

   The format of the AT_MAC attribute is shown below.












Bersani                 Expires û December 2004              [Page 48]


INTERNET-DRAFT                 EAP-PSK                      June 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                                 |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The MAC field is a 16 byte field used to transport a 128 bit keyed
   message authentication code.

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

4.4.4  AT_PCHANNEL

   The AT_PCHANNEL attribute 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 intention is quite similar to [PEAP-TLV].

   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 Nonce field is a four byte field used to convey the nonce for the
   protected channel that is specified in section 2.2.2.



Bersani                 Expires û December 2004              [Page 49]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The Tag field is 128 bit long and is used to transport a 128 bit
   keyed message authentication code. It is calculated as specified in
   2.2.2.

   The payload consists in the variable length cipher text 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 derived TEK (see Section 2.2.2).

   The information that the peer and the server may exchange over the
   protected channel consists either of an AT_STATUS or an AT_STATUS
   concatenated with an AT_EXT.

   The use of AT_PCHANNEL is defined in section 2.2.2.

4.4.5  AT_RAND

   The AT_RAND attribute is used to transport 128 bit random numbers
   that are used as challenges for authentication (see section 2.2.1).

   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 16 byte RAND field is used to transport a random number freshly
   generated either by the peer or the server for the EAP-PSK
   authentication exchange.

   The random number sent by the server is also used as a seed value for
   the derivation of keying material.

   The use of AT_RAND is defined in sections 2.2.1 and 2.3.1.

4.4.6  AT_STATUS

   The AT_STATUS attribute is used by the peer and the server to
   exchange protected result indications of success or failure for the
   EAP-PSK dialog.

   The format of the AT_STATUS attribute is shown below.


Bersani                 Expires û December 2004              [Page 50]


INTERNET-DRAFT                 EAP-PSK                      June 2004



       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    | S |         Reserved          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   There MUST be exactly one AT_STATUS encapsulated in each AT_PCHANNEL.

   The two bit S field is called the Status field.
   It is set to:
     o 01 if the current status is CONT
     o 10 if the current status is DONE_SUCCESS
     o 11 if the current status is DONE_FAILURE

   The use of AT_STATUS is defined in sections 3.2.3 and 3.3.3.

5. IANA considerations

   This document introduces two new Internet Assigned Numbers Authority
   (IANA) considerations.

   This section provides guidance to the IANA regarding registration of
   values related to the EAP-PSK protocol, in accordance with BCP 26,
   [RFC 2434].

   The following terms are used here with the meanings defined in BCP
   26: "name space", "assigned value", "registration".

   The following policies are used here with the meanings defined in BCP
   26: "Private Use", "First Come First Served", "Expert Review",
   "Specification Required", "IETF Consensus", "Standards Action".

   There are one name space in EAP-PSK that require registration: the
   EXT_Type field values of AT_EXT (see section 4.4.1).

   EAP-PSK is not intended as a general-purpose protocol, and
   allocations SHOULD NOT be made for purposes unrelated to
   authentication, authorization and accounting.

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert. The intention is that any allocation will be
   accompanied by a published RFC. But in order to allow for the
   allocation of values prior to the RFC being approved for publication,
   the Designated Expert can approve allocations once it seems clear
   that an RFC will be published. The Designated expert will post a
   request to the EAP WG mailing list (or a successor designated by the
   Area Director) for comment and review, including an Internet-Draft.
   Before a period of 30 days has passed, the Designated Expert will


Bersani                 Expires û December 2004              [Page 51]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   either approve or deny the registration request and publish a notice
   of the decision to the EAP WG mailing list or its successor, as well
   as informing IANA. A denial notice must be justified by an
   explanation and, in the cases where it is possible, concrete
   suggestions on how the request can be modified so as to become
   acceptable.

5.1 Allocation of an EAP-Request/Response Type for EAP-PSK

   This document requires IANA to allocate a new EAP Type for EAP-PSK.
   It is not clear yet whether this request will follow the standards
   track allocation process for method types (type numbers 192-253 ) or
   the "informational" one (type numbers 46-191), see [EAP] for more
   details.

5.2 Allocation of EXT_Type numbers

   EXT_Type has a range from 0 to 255.

   EXT_Type 255 has been allocated for Experimental use.

   EXT_Type 0-254 may be allocated on the advice of a Designated Expert,
   with Specification Required

6. Security considerations

   [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-PSK as
   well as vulnerabilities and security recommendations.

6.1 Identity protection

   Since the choice was made to restrict to a single cryptographic
   primitive from symmetric cryptography, namely the block cipher AES-
   128, it appears that it is not possible to provide "reasonable"
   identity protection without failing to meet the simplicity goal.

   We provide hereafter an informal discussion of what is meant by
   identity protection and the rationale behind the requirement of
   identity protection. For some complementary discussion, please refer
   to [SIGMA].

   Identity protection basically means preventing the disclosure of the
   identities of the communicating over the network... which is quite
   contradictory with authentication. There are two levels of identity
   protection: protection against passive attackers and protection
   against active eavesdropper.


Bersani                 Expires û December 2004              [Page 52]


INTERNET-DRAFT                 EAP-PSK                      June 2004



   As explained in [SIGMA], "a common example [for identity protection]
   is the case of mobile devices wishing to prevent an attacker from
   correlating their (changing) location with the logical identity of
   the device (or user)".

   In case only symmetric cryptography is used, only a weak form of
   identity protection may be offered, namely pseudonym management. In
   other words, the peer and the server agree on pseudonyms that they
   use to identify each other and usually change periodically (possibly
   in a protected way so that an attacker cannot learn the new pseudonym
   before it is used).

   The problem with pseudonym management is that there is a tradeoff
   between allowing for pseudonym resynchronization (thanks to a
   permanent identity) and being vulnerable to active attacks (in which
   the attacker forges messages simulating a pseudonym
   desynchronization). Indeed, a protocol using (changing) pseudonyms
   may want to anticipate "desyncrhonization" situations such as for
   instance when the peer believes that the current pseudonym it has to
   use is "pseudo1@bigco.com" whereas the server believes the peer has
   to use the pseudonym "pseudo2@bigco.com" which updated
   "pseudo1@bigco.com".

   Because pseudonym management adds complexity to the protocol and
   implies this unsatisfactory tradeoff, it was decided not to include
   this feature in EAP-PSK.

   However, EAP-PSK may provide protection against the two main attacks
   that account, in our opinion, for the identity protection requirement
   placed on EAP methods.

   The first attack is an active probing attack, i.e. the attacker
   probes a device in order to learn its logical identity. This attack
   does not apply to EAP-PSK since it is the initiator of the EAP-PSK
   conversation that has to disclose and prove its identity first - in
   fact, the server never discloses its identity (following an
   assumption discussed in section 1.1).

   The second attack is passive and aims at learning valuable
   information on the peer.
   For instance, let us take the example of user John Doe that roams and
   connects to a Hot-Spot owned and operated by Wireless Internet
   Service Provider (WISP) BAD. Suppose this user authenticates to his
   home WISP (WISP GOOD) with an EAP method under an identity (e.g.
   "john.doe@wispgood.com") that allows WISP BAD (or an attacker) to
   recover his "real-life" identity, i.e. John Doe. An example drawback
   of this, is that a competitor of John Doe's WISP may want to win John



Bersani                 Expires û December 2004              [Page 53]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   Doe as a new customer by sending him some special targeted
   advertisement.
   EAP-PSK can very simply thwart this attack, merely by avoiding to
   provide John Doe with a NAI that allows easy recovery of his real-
   life identity. We believe that when a NAI decorrelated to a real-life
   identity is used, no other valuable information leaks because of the
   EAP method. Indeed, the identity of the WISP used by a peer has to be
   disclosed anyway in the realm portion of its NAI to allow AAA routing
   and the Medium Access Control Address of the peer can generally be
   used to track the peer as efficiently as a fixed NAI.

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 also can calculate a valid MAC.

   The authentication protocol used in EAP-PSK, AKEP2, enjoys a security
   proof in the provable security paradigm, see [EAKD].

   The MAC algorithm used in the instantiation of AKEP2 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.1.

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



Bersani                 Expires û December 2004              [Page 54]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   The key derivation mechanism uses a dedicated key, the KDK.

   The input block to the key derivation is taken to be RB as specified
   in AKEP2.

   It should be emphasized that the server has control of the session
   keys derived by EAP-PSK. In particular, it can easily choose RB so
   that one of the 9 derived 128 bit key blocks (see section 2.2.1)
   takes a pre-specified value.
   It was chosen not to prevent this server control of the session keys
   because:
     o Preventing it would have added some complexity to the protocol
        (typically inclusion of a one-way mode of operation of AES in
        the key derivation part)
     o We believe that the server may reasonably be assumed to be
        honest (e.g. it won't try to force the peer to use some pre-
        specified value for the session keys) and more "secure" than the
        peer (e.g. it will use a good source of randomness for RB)
   This key control by the server is however not the behavior
   recommended by EAP in section 7.10 "A RECOMMENDED method is for each
   party to provide a nonce of at least 128 bits, used in the derivation
   of the MSK and EMSK"

   Since deriving the keys requires some cryptographic computations, it
   is RECOMMENDED that the keys be derived only if authentication has
   succeeded (i.e. the server verifies that the AT_MAC sent by the peer
   is valid and only then does he derive the keys and similarly, the
   peer verifies that the AT_MAC sent by the server is valid and only
   then derive the keys - see sections 3.2.1 and 3.3.1).

   It is RECOMMENDED to take great care in implementations so that
   derived keys are not made available if the EAP-PSK dialog fails (i.e.
   ends with DONE_FAILURE or a time out). The derived keys are made
   available to the other layers/applications only if a flag
   (isKeyAvailable is set to TRUE). In case, this flag is not set to
   TRUE, the derived keys MUST NOT be made available, although they may
   have been derived.

   The TEK MUST NOT be made available to anyone except to the current
   EAP-PSK dialog.

6.4 Dictionary attacks

   Because EAP-PSK is not a password protocol, it is not vulnerable to
   dictionary attacks. Let us indeed remind that the PSK used by EAP-PSK
   MUST NOT be derived from a password. Derivation of the PSK from a
   password may lead to dictionary attacks.

   However using a 256 bit pre-shared key has:


Bersani                 Expires û December 2004              [Page 55]


INTERNET-DRAFT                 EAP-PSK                      June 2004


     o Ergonomic impacts: it may be considered cumbersome to have to
        provision 256 bit credentials
     o Deployment impacts: it may be wanted to reuse existing
        credential databases that contain passwords and not PSKs

   Since despite the warning not to use passwords, people will probably
   do that anyway, we offer four alleys to mitigate the risk associated
   with such a behavior:
     o Annex A provides guidance on the minimal operations to do when
        one still wants to derive the PSK from a password. This should
        complicate dictionary attacks - but by no way make them
        impossible!
     o Annex B suggests a complementary key derivation scheme that
        allows EAP-PSK to be provisioned with a single 128 bit secret
        which is then expanded into a 256 bit PSK - this should improve
        the ergonomics by dividing the credential length by two
     o AT_EXT can be used to provision a stronger PSK after a
        successful authentication occurred with a password based PSK -
        this can be used to reduce the vulnerability window to one EAP-
        PSK exchange when a password is used

   We also remind that it is not a fatality that password be used
   instead of PSKs: people rarely use password derived certificates, so
   why should they do so for shared keys?

   Last, we note that AKEP2 makes dictionary attacks harder, since the
   first value that is MACed is not predictable neither by the peer nor
   the server or anybody else: precomputing a dictionary adapted to EAP-
   PSK even in case of an active attack seems thus at least very
   difficult.

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.

   As soon as AT_PCHANNEL is included in an EAP packet, the whole EAP
   packet is integrity protected.

6.6 Negotiation attacks

   EAP-PSK does not protect from negotiation attacks since it currently
   does not provide version or cipher suite negotiation.



Bersani                 Expires û December 2004              [Page 56]


INTERNET-DRAFT                 EAP-PSK                      June 2004


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

   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. The effectiveness of
   such attacks and the solutions that should be adopted is still
   controversial in our opinion (see [IETF 55] and [IETF 59] for some
   discussions on this issue).

6.8 Random numbers generation

   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.9 Denial of Service resistance

   Denial of Service resistance (DoS) resistance has not been a design
   goal for EAP-PSK.

   We however believe that EAP-PSK does not provide any obvious and
   avoidable venue for such attacks.

   EAP-PSK does not allow EAP notifications to prevent potential DoS
   attacks.. Indeed, since EAP Notifications are not integrity
   protected, they can easily be spoofed by an attacker. Such an
   attacker could force a peer that allows Notifications to engage in a
   discussion which would delay his authentication or result in the peer
   taking unexpected actions (e.g. in case the Notification is used to
   prompt the peer to do a "bad" action.

   According to this specification, it would be possible for an attacker
   to make a number of tentative forgeries limited only by time outs.
   Indeed, the m.check() procedures (see sections 3.2.1 and 3.3.1) does
   not currently specify whether an error is fatal or not. An error is
   fatal, if after it, no verifications are done any more: the party
   transitions to failure without further examining any new packet.
   Since this does not affect interoperability, it is up to the
   implementor or the user to specify for instance the maximum number of
   failed checks authorized in a particular state. There is a trade off
   between possibly allowing multiple tentative forgeries and allowing a
   direct DoS (in case the first error is fatal).



Bersani                 Expires û December 2004              [Page 57]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   It is also not clear from [EAP-SM] how to transition quickly to the
   EAP SUCCESS or FAILURE state. One could use the variables altAccept
   and altReject but in the current version of [EAP-SM], these variables
   are specified as interface between the lower layer and the EAP peer
   state machine and not between the EAP peer state machine and the EAP-
   PSK peer state machine. As a result, depending on EAP implementations
   there might not be a better way to transition to EAP SUCCESS or
   FAILURE state than to wait for a time out to occur. This behavior
   might result in annoying delays.

   Last, the Status field of the AT_STATUS has been specified so that
   the peer and the server may share information on their respective
   state in a protected way. The peer is not authorized to make a
   transition to DONE_SUCCESS before the server has made its own
   transition to DONE_SUCCESS. When one party transitions to
   DONE_FAILURE, both parties are expected to fail. The cryptographic
   protection of these result indications does not prevent message
   deletion. For instance, a server sends DONE_SUCCESS to a peer that
   upon reception also sends DONE_SUCCESS. In case this last message
   from the peer is intercepted, and an EAP Success is sent to the peer
   before any retransmission from the server reaches it or the
   retransmissions from the server are also deleted, the peer will
   believe that it has successfully authenticated to the server while
   the server will fail. This behavior is well known (see [CK]) and in a
   sense unavoidable. There is a trade off between efficiency and the
   "level" of information sharing that is attainable. EAP-PSK chose the
   more efficient solution (i.e. a round trip of DONE_SUCCESS suffice)
   because, it is believed that:
     o In case there is an adversary capable of disrupting the
        communication channel, it can do so whenever it wants (be it
        after one or 10 round trip or even during data communication)
     o Other layers/applications will generally start by doing a
        specific key exchange and confirmation procedure using the keys
        derived by EAP-PSK. This is typically done by IEEE 802.11i
        "four-way handshake". In case the error is not detected by EAP-
        PSK, it should be detected then (please note that it is however
        generally not a good idea to rely on external mechanism to
        ensure security properties).

6.10 Implementation of EAP-PSK

   This section is to remind that the security provided by EAP-PSK
   depends on its implementation and that implementation of
   cryptographic algorithms require special skills since cryptographic
   software is not only vulnerable to classical attacks (e.g. buffer
   overflow or missing checks) but also to some special cryptographic
   attacks (e.g. side channels attacks like timing ones, see for
   instance [TIM]). Hence, care must be taken in EAP-PSK implementation
   to avoid such attacks, please refer to [EAX] for some discussion.


Bersani                 Expires û December 2004              [Page 58]


INTERNET-DRAFT                 EAP-PSK                      June 2004



   Please also not that the quality of the checks performed by the
   m.check() procedures (see sections 3.2.1 and 3.3.1)is of vital
   importance. For instance, when checking the syntactic correctness of
   AT_ID (see section 4.4.2), not only should
     o The Type field be checked, namely that it is equal to 2
     o The Length field be checked, namely that it is not bigger than
        the EAP-PSK packet minus the length of the other attributes it
        contains and that is not bigger than 241
   but also
     o The Actual Identity Length field, namely that it is not bigger
        than the length specified in the length field minus 1 (for the
        32 bit header of AT_ID)
     o The Identity field, namely that it complies with [NAI]

6.11 Exposition of the PSK

   This is to remind some issues related to the use of a PSK and AES-128
   as the only cryptographic primitive.

   First, EAP-PSK does not provide perfect forward secrecy. Compromise
   of the PSK leads to compromise of recorded past sessions.

   Second, Compromise of the PSK enable the attacker to impersonate the
   peer of the server: compromise of the PSK leads to "full" compromise
   of future sessions.

   Last, usage of a PSK that is only 256 bit long and thus that a human
   user can "read" or remember - compared say the "long" 1024 or 2048
   bit RSA keys, often leads to selecting poor repositories for the PSK
   (such as a plaintext file). From this, it generally follows that a
   user has full access to the PSK: he can read it and share it with
   anybody. Again, this has nothing to do with the nature of the PSK and
   appropriate protection (such as storage on a tamper resistant device)
   can be provided as well for PSKs as for certificates (which is very
   often the case).

6.12 Channel binding

   This feature is not provided in EAP-PSK as it still very much work in
   progress (please refer to [CBIND]).

   However, it should be easy to add to EAP-PSK thanks to the EAP-PSK
   extensible design (namely AT_EXT, see section 2.3.2)

6.13 Fragmentation

   As explained in section 2.6, EAP-PSK does not provide fragmentation
   and leave it to the AT_EXT to implement the fragmentation mechanisms.


Bersani                 Expires û December 2004              [Page 59]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   Care must be taken while implementing fragmentation within AT_EXT
   since fragmentation has some serious security implications, that we
   briefly discuss here after.

   Fragmentation may lead to disruption of the protected result
   indication mechanism. To mitigate this risk, the extension plugin
   should check that all the Status field received in the AT_STATUS that
   accompany the AT_EXT that contain fragments of the same series are
   the same. Similarly, while acknowledging AT_EXT that contain
   fragments of the same series, the same Status field MUST be used in
   all AT_STATUS - except if a party wishes to fail before reassembly
   and sends a DONE_FAILURE.

   Fragmentation may lead to implementation issues (e.g. buffer
   overflow). It is RECOMMENDED that the fragmentation mechanism provide
   the total length of the fragmented message in the first fragment.

   Fragmentation could lead to well-known DoS attacks (see for instance
   [FRAG]) were it not implemented within the protected channel. Hence,
   the main threat against fragmentation arises when one of the
   communicating party behaves "badly", which should not occur and is
   not in the scope of the threat model.

7. Security claims

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

   [a] Mechanism. EAP-PSK is based on symmetric cryptography (AES-128)
   and uses a 256 bit Pre-shared Key

   [b] Security claims. The security properties of the method are
   discussed in Section 6.
   EAP-PSK provides:
     o Mutual authentication (see section 6.2)
     o Integrity protection (see section 6.5)
     o Replay protection (see sections 6.2 and 6.5)
     o Key derivation (see section 6.3)
     o Dictionary attack resistance (see section 6.4)
     o Session independence (see section 6.3)

   [c] Key strength. EAP-PSK mutually authenticates the parties with a
   128 bit effective key strength and supports key derivation with 128-
   bit effective key strength.

   [d] Description of key hierarchy. Please see Section 2.1.

   [e] Indication of vulnerabilities. Vulnerabilities are discussed in
   Section 6.
   EAP-PSK does not provide:


Bersani                 Expires û December 2004              [Page 60]


INTERNET-DRAFT                 EAP-PSK                      June 2004


     o Identity protection (see section 6.1)
     o Confidentiality. Although EAP-PSK provides confidentiality in
        its protected channel (see section 6.5), it cannot claim to do
        so as per [EAP] "A method making this claim MUST support
        identity protection"
     o Fast reconnect (see section 2.5)
     o Fragmentation (see section 2.6)
     o Cryptographic binding (see section 6.7)
     o Protected cipher suite negotiation (see section 6.6)
     o Perfect Forward Secrecy (see section 6.3)
     o Key agreement: the session key is chosen by the server (see
        section 6.3)
     o Channel binding (see section 6.12)

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.

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.

   It also benefited from exchanges with other EAP methods designers:
   many thanks to Hannes Tschofenig (EAP-IKEv2) and Nancy Cam-Winget
   (EAP-FAST).

   Many thanks to Aurelien Magniez for his help in the first
   implementation of EAP-PSK under Microsoft Windows and Freeradius and
   the very valuable feedback he provided, Henri Gilbert for some
   interesting discussions on the cryptographic parts of EAP-PSK, Thomas
   Otto for the inchoate working relationship and the implementation of
   the first version of EAP-PSK under Xsupplicant, Anne-Sophie Dusserre
   for pointers to EAP client and server implementations, and Laurent
   Butti.

   Finally, thanks to Jari Arkko and Bernard Aboba the beloved EAP WG
   chairs for the work they stimulate!

10. References

10.1 Normative

   [AES]         Federal Information Processing Standards (FIPS)
                 Publication 197, " Specification for the Advanced
                 Encryption Standard (AES)", National Institute of


Bersani                 Expires û December 2004              [Page 61]


INTERNET-DRAFT                 EAP-PSK                      June 2004


                 Standards and Technology, November 26, 2001

   [EAP]         Blunk, L. and Vollbrecht, J., "PPP Extensible
                 Authentication Protocol (EAP)", RFC 3748, May
                 2004

   [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",
                 FSE 2004, LNCS 3017, Springer-Verlag,
                 Berlin, 2004

   [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 Beadles M., "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 2887,
                 pp129-153, Springer-Verlag, Berlin, 2003

   [RFC 2219]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997

   [RFC 2434]    Narten, T. and Alvestrand, H. "Guidelines for Writing
                 an IANA Considerations Section in RFCs", RFC 2434,
                 October 1998

   [SOBMMO]      Gilbert, H., ôThe Security of One-Block-to-Many Modes
                 of Operationö, Fast Software Encryption, FSE 2003,
                 LNCS 2287, pp376-395, Springer-Verlag

10.2 Informative

   [AH]          Kent, S. and Atkinson, R., "IP Authentication Header",
                 RFC 2402, November 1998

   [AKESD]       Bellare, M. et al., "Authenticated Key Exchange Secure
                 Against Dictionary attacks", EUROCRYPT 2000, LNCS 1807,
                 pp139-155, Springer-Verlag, Berlin, 2000

   [CBIND]       Arkko, J. and Eronen, P., "Authenticated Service
                 Identities for the Extensible Authentication Protocol",
                 Internet-Draft (work in progress), April 2004,
                 draft-arkko-eap-service-identity-auth-00.txt


Bersani                 Expires û December 2004              [Page 62]


INTERNET-DRAFT                 EAP-PSK                      June 2004



   [CK]          Halpern, J. and Moses, Y., "Knowledge and common
                 knowledge in a distributed environment", Journal of the
                 ACM 37:3, 1990

   [EAP-AKA]     Arkko, J. and Haverinen, H., ôEAP AKA Authenticationö,
                 Internet-Draft (work in progress), April 2004,
                 draft-arkko-pppext-eap-aka-12.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. and Salowey, J.,
                 "EAP SIM Authentication",
                 Internet-Draft (work in progress),April 2004,
                 draft-haverinen-pppext-eap-sim-13.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.txt

   [EAP-SRP]     Carlson, J. et al., ôEAP SRP-SHA1 Authentication
                 Protocolô, Internet-Draft (work in progress),
                 July 2001, draft-ietf-pppext-eap-srp-03.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

   [FRAG]        Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS
                 protection for UDP-based protocols", ACM Conference on
                 Computer and Communications Security, October 2003.

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

   [IEEE802.1X]  Institute of Electrical and Electronics Engineers,
                 "Standards for Local and Metropolitan Area Networks:
                 Port Based Access Control", IEEE STD 802.1X, 2001

   [IEEE802.11]  Institute of Electrical and Electronics Engineers,
                 "Information Technology - Telecommunications and
                 Information Exchange between Systems - Local and


Bersani                 Expires û December 2004              [Page 63]


INTERNET-DRAFT                 EAP-PSK                      June 2004


                 Metropolitan Area Network - Specific Requirements û
                 Part 11: Wireless LAN Medium Access Control (MAC) and
                 Physical Layer (PHY) Specifications", IEEE STD 802.11,
                 1999

   [IEEE802.11i] 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 - Amendment 6:
                 Medium Access Control (MAC) Security Enhancements",
                 IEEE STD 802.11i, June 2004

   [IEEE802REQ]  Stanley, Dorothy et al., ôEAP Method Requirements for
                 Wireless LANsö, Internet-Draft (work in progress),
                 May 2004, draft-walker-ieee802-req-01.txt

   [IETF 55]     Proceeding of IETF 55, Internet Area, EAP WG,
                 http://www.ietf.org/proceedings/02nov/136.htm

   [IETF 59]     Proceeding of IETF 55, Internet Area, EAP WG,
                 http://www.ietf.org/proceedings/04mar/138.htm

   [KSIZE]       National Institute of Standards and Technology,
                 "Special Publication 800-57 Recommendation for Key
                 Management Part 1: General Guideline",
                 Draft, January 2003,
                 http://csrc.nist.gov/CryptoToolkit/kms/
                 guideline-1-Jan03.pdf

   [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

   [NETSEL]      Adrangi, F., "Mediating Network Discovery and
                 Selection", Internet-Draft (work in progress), February
                 2004, draft-adrangi-eap-network-Discovery-and-
                 Selection-01.txt


Bersani                 Expires û December 2004              [Page 64]


INTERNET-DRAFT                 EAP-PSK                      June 2004



   [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]       Kaliski, B., "PKCS #5: Password-Based Cryptography
                 Specification Version 2.0", RFC 2898, September 2000

   [PWD]         National Institute of Standards and Technology (NIST).
                 ôFIPS PUB 112: Password Usageö. May 30, 1985.

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

   [RFC 2989]    Aboba, B. et al., " Criteria for Evaluating AAA
                 Protocols for Network Access", RFC 2989, November 2000

   [SAM]         Rescorla, E., "Survey of Authentication Mechanisms",
                 Internet-Draft (work in progress), March 2004,
                 draft-iab-auth-mech-03.txt

   [SKM]         Bersani, F., ôEAP shared key methods: a tentative
                 synthesis of those proposed so farö,
                 Internet-Draft (work in progress), April 2004,
                 draft-bersani-eap-synthesis-sharedkeymethods-00.txt

   [SIGMA]       Krawczyk, H., "SIGMA: the SIGn-and-MAc Approach to
                 Authenticated Diffie-Hellman and its use in the IKE
                 protocol"

   [SPEKE]       Jablon, D., "Strong Password-Only Authenticated Key
                 Exchange", Computer Communication Review, ACM SIGCOMM,
                 vol. 26, no. 5, pp. 5-26, October 1996

   [TIM]         Kocher, P., "Timing Attacks on Implementations of
                 Diffie-Hellman, RSA, DSS, and Other Systems",
                 CRYPTO 96, LNCS 1109, pp. 104-113, Springer-Verlag,
                 Berlin, 1996

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

11. Authors' Addresses

   Florent Bersani                   florent.bersani@francetelecom.com


Bersani                 Expires û December 2004              [Page 65]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   France Telecom R&D
   38, rue du General Leclerc
   92794 Issy Les Moulineaux Cedex 9
   France















































Bersani                 Expires û December 2004              [Page 66]


INTERNET-DRAFT                 EAP-PSK                      June 2004


Annex A: Generation of the PSK from a password - Discouraged

   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.

   The PSK of EAP-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

   Although this gives better protection than nothing, the reader is
   reminded that this derivation does not stricto sensu protect against
   dictionary attacks. It only makes dictionary precomputation more
   difficult.








Bersani                 Expires û December 2004              [Page 67]


INTERNET-DRAFT                 EAP-PSK                      June 2004


Annex B: Generation of the PSK from a 128 bit shared key

   Since it may be found cumbersome to enter manually the 256 bits of
   the PSK that is split in two 128 bit subkeys and because 128 bit
   security provide an appropriate level of security for most
   applications (see [KSIZE] or [IEEE802REQ]), we provide hereafter
   guidance on how to reduce the credential used by EAP-PSK to 128 bits:
   we specify how to securely extend 128 bits to 256 bits that can then
   be used as the PSK.

   Contrary to the PSK generation from a password which is formally
   discouraged, generation of the PSK from a 128 bit shared key does not
   reduce in practice the security level of EAP-PSK (which only claims
   128 bit security, see section 7). EAP-PSK may indeed evolve and this
   informative annex become normative part of the protocol if no concern
   arises.

   We take advantage of the key derivation scheme that is already used
   by EAP-PSK, namely the modified counter mode (see section 2.2.1).

   We present hereafter the parameters with which we use this mode for
   derivation of a 256 bit PSK from a 128 bit secret.

   All rotation values (the ri per [SOBMMO] Figure 3 notation) are set
   to zero (no rotations) and the counter values (the ci per [SOBMMO]
   Figure 3 notation) are respectively set to the first t integers (that
   is ci="i", starting with i=1).

   The parameter t of [SOBMO] is set to 2.

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

   The input block is "0".

   For what regards the output blocks, using EAP-PSK terminology:
     1. The first output block is AK
     2. The second output block is KDK














Bersani                 Expires û December 2004              [Page 68]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   Annex C: Issue list for EAP-PSK

   An issue list for EAP-PSK is available at:
   http://perso.rd.francetelecom.fr/bersani/EAP_PSK/EAP-PSK_Issues.htm















































Bersani                 Expires û December 2004              [Page 69]


INTERNET-DRAFT                 EAP-PSK                      June 2004


   Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


   Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


   Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Bersani                 Expires û December 2004              [Page 70]