Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4764


The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method

Part 3 of 3, p. 41 to 64
Prev RFC Part


prevText      Top      Up      ToC       Page 41 
6.  Rules of Operation for the EAP-PSK Protected Channel

   In this section, the rules of operation of the EAP-PSK protected
   channel are presented:

   o  How protected result indications are implemented.

   o  How an extended authentication works in details.

6.1.  Protected Result Indications

   The R flag of the PCHANNEL field in the third and fourth types of
   EAP-PSK messages is used to provide result indications.

   Since this 2-bit flag is communicated over the protected channel, it

   o  Encrypted so that only the peer and the server can know its value.

   o  Integrity-protected so that it cannot be modified by an attacker
      without the peer or the server detecting this modification.

   o  Protected against replays.

   This 2-bit R flag can take the following values:

   o  01 to mean CONT

Top      Up      ToC       Page 42 
   o  10 to mean DONE_SUCCESS

   o  11 to mean DONE_FAILURE

   The peer and the server each remember some information about both the
   values of R that they have sent and the values of R they have
   received.  It is the conjunction of both sent and received R values
   that indicate the success or the failure of the EAP-PSK dialog.

   In the case of a standard authentication, the following values of R
   should be exchanged:

   o  Either the server sends a DONE_SUCCESS in the PCHANNEL of the
      third EAP-PSK message, to which the peer replies with a
      DONE_SUCCESS in the PCHANNEL of the fourth EAP-PSK message, which
      successfully ends the EAP-PSK dialog.

   o  Or the server sends a DONE_FAILURE in the PCHANNEL of the third
      EAP-PSK message, to which the peer replies with a DONE_FAILURE in
      the PCHANNEL of the fourth EAP-PSK message, which unsuccessfully
      ends the EAP-PSK dialog.

   In the case of an extended authentication, more complex exchanges may
   occur, which is why the CONT value was introduced.

   The rules of operation for each value that R may take are detailed

6.1.1.  CONT

   The server and the peer each initialize the values of R they intend
   to send and receive as CONT.

   Here CONT stands for "Continue".  It indicates that the EAP-PSK
   dialog is not yet successful and that the party sending it wants to
   continue the dialog to try and reach success.

   Indeed, although the peer and the server must have successfully
   authenticated each other, thanks to MAC_P and MAC_S, before they
   start communicating over the protected channel, the EAP-PSK dialog
   may not yet be deemed successful after this mutual authentication
   because of authorization issues.  For instance, a prepaid customer of
   a wireless Hot-Spot might have successfully authenticated but has to
   refill its account, e.g., with a credit card transaction over the
   protected channel, before it is authorized.

Top      Up      ToC       Page 43 

   DONE_SUCCESS indicates that the party that sent it deems the EAP-PSK
   dialog successful and therefore proposes to end this dialog.

   Once the server has sent a DONE_SUCCESS, it must keep sending this
   value for R.

   The peer must first receive a DONE_SUCCESS from the server before it
   is allowed to send a DONE_SUCCESS.

   After the peer has received a DONE_SUCCESS from the server, it may:

   o  Send a CONT to the server if it has not reached success on its
      side.  The server that receives a CONT should continue the EAP-PSK
      dialog (see Section 8.2 for some discussion on the security
      implications of this).

   o  Send a DONE_SUCCESS to the server, which will end the EAP-PSK
      dialog with success.

   o  Send a DONE_FAILURE to the server, which will end the EAP-PSK
      dialog with failure.


   DONE_FAILURE indicates that the party that sent it deems the EAP-PSK
   dialog unsuccessful and proposes to end this dialog because nothing
   will make it change its mind.

   If the server is the first to send a DONE_FAILURE, then the peer that
   receives this DONE_FAILURE must reply with a DONE_FAILURE and fail,
   which ends the EAP-PSK dialog.

   If the peer is the first to send a DONE_FAILURE, then the server that
   receives this DONE_FAILURE must immediately end this EAP-PSK dialog
   without sending any further EAP-PSK message, and fail.

6.2.  Extended Authentication

   An extended authentication can only be started by the server.

   Exactly one extension (identified by the EXT_Type subfield of the EXT
   field) must be run during an EAP-PSK extended authentication dialog.

   The extension is run over the protected channel: it can assume
   confidentiality, integrity, and replay protection.

Top      Up      ToC       Page 44 
   To start an extended authentication, the server sets the PCHANNEL E
   flag to 1 and includes the EXT_Payload of the extension it has

   Since EAP-PSK does not provide fragmentation, the extension must not
   send an EXT_Payload larger than 960 bytes, which corresponds to the
   1020-byte EAP MTU that may minimally be assumed (see [3]).

   Moreover, an extension must not send an empty EXT_Payload (because
   this has a particular meaning for EAP-PSK; see below).

   When the peer receives the third EAP-PSK message with the E flag set
   to 1, it checks whether it is able to process the proposed extension.

   If the peer is not able to process the proposed extension, i.e., it
   does not recognize the EXT_Type of the proposed extension, it sets
   E=1 in its reply (the fourth EAP-PSK message) and include an EXT
   field of the same EXT_Type but with an empty EXT_Payload.

   Depending on the values taken by the R flags, the EAP-PSK dialog may:

   o  End

      *  If the peer's policy mandates that it fails in the case of an
         unrecognized extension, it sends a DONE_FAILURE in the fourth
         EAP-PSK message.

      *  If the server has sent a DONE_SUCCESS in the third EAP-PSK
         message, and the peer's policy authorizes it to succeed even if
         the extension is not recognized, the peer sends a DONE_SUCCESS.

   o  Continue for exactly one round-trip; namely, in case the server
      has sent a CONT in the third EAP-PSK message and the peer's policy
      authorizes it to succeed even if the extension is not recognized,
      the peer replies with a CONT in the fourth EAP-PSK message.  The
      server must then, depending on its policy, send either a
      DONE_SUCCESS or a DONE_FAILURE to the peer in the fifth EAP-PSK
      message.  If the server sent a DONE_SUCCESS in the fifth EAP-PSK
      message, the peer must send a DONE_SUCCESS in the sixth EAP-PSK
      message.  All these messages must have the E flag set to 1 with an
      EXT field with the EXT_Type of the extension that was proposed and
      an empty EXT_Payload (this behavior was chosen to simplify

   If the peer is able to process the proposed extension, then it does
   so.  In this case, the extension must be aware of the R values sent
   and received and able to propose to update them.  All the subsequent
   messages exchanged between the peer and the server must have the E

Top      Up      ToC       Page 45 
   flag set to 1 with an EXT field of the EXT_Type of the extension that
   was proposed and a non-empty EXT_Payload.

7.  IANA Considerations

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

   The following terms are used here with the meanings defined in [6]:
   "name space" and "registration".

   The following policies are used here with the meanings defined in
   [6]: "Expert Review" and "Specification Required".

   This document introduces one new Internet Assigned Numbers Authority
   (IANA) consideration: there is one name space in EAP-PSK that
   requires registration: the EXT_Type values (see Section 5.3 and
   Section 5.4).

   For registration requests where a Designated Expert should be
   consulted, the responsible IETF 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
   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

7.1.  Allocation of an EAP-Request/Response Type for EAP-PSK

   IANA allocated a new EAP Type for EAP-PSK.

7.2.  Allocation of EXT Type Numbers

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

   EXT_Type numbers have a range from 1 to 255.

Top      Up      ToC       Page 46 
   EXT_Type 255 has been allocated for Experimental use.

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

8.  Security Considerations

   [3] highlights several attacks that are possible against EAP, as EAP
   does not provide any robust security mechanism.

   This section discusses the claimed security properties of EAP-PSK as
   well as vulnerabilities and security recommendations in the threat
   model of [3].

8.1.  Mutual Authentication

   EAP-PSK provides mutual authentication.

   The server believes that the peer is authentic because it can
   calculate a valid MAC and the peer believes that the server is
   authentic because it can calculate another valid MAC.

   The authentication protocol that inspired EAP-PSK, AKEP2, enjoys a
   security proof in the provable security paradigm; see [14].

   The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK,
   CMAC, also enjoys a security proof in the provable security paradigm;
   see [29].  A tag length of 16 bytes for CMAC is currently deemed
   appropriate by the cryptographic community for entity authentication.

   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, which makes this part cryptographically independent of
   the other parts of the protocol.

   EAP-PSK provides mutual authentication if it is based on a pairwise
   PSK of sufficient strength.  If the PSK is not pairwise or not
   sufficiently strong, then it does not provide authentication.  In
   this way, EAP-PSK is no different than other authentication protocols
   based on Pre-Shared Keys.

Top      Up      ToC       Page 47 
8.2.  Protected Result Indications

   EAP-PSK provides protected result indications thanks to its 2-bit R
   flag (see Section 6.1).  This 2-bit R flag is protected because it is
   encrypted and integrity protected by the EAX mode of operation; see
   Section 3.3.

   Care may be taken against Byzantine failures, that is to say, for
   instance, when a peer tries to force a server to engage in a never-
   ending conversation.  This could, for example, be done by a peer that
   keeps sending a CONT after it has received a DONE_SUCCESS from the
   server.  A policy may limit the number of rounds in an EAP-PSK
   extended authentication to mitigate this threat, which is outside our
   threat model.

   It should also be noted that the cryptographic protection of the
   result indications does not prevent message deletion.

   For instance, let us consider a scenario in which:

   o  A server sends a DONE_SUCCESS to a peer.

   o  The peer replies with a DONE_SUCCESS.

   In the case that the 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, e.g., [23]) and in a sense
   unavoidable.  There is a trade-off between efficiency and the "level"
   of information sharing that is attainable.  EAP-PSK specified a
   single round-trip of DONE_SUCCESS because it is believed that:

   o  If there is an adversary capable of disrupting the communication
      channel, it can do so whenever it wants (be it after 1 or 10
      round-trips 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, however, that it is bad
      practice to rely on an external mechanism to ensure
      synchronization, unless this is an explicit property of the
      external mechanism).

Top      Up      ToC       Page 48 
8.3.  Integrity Protection

   EAP-PSK provides integrity protection thanks to the Tag of its
   protected channel (see Section 3.3).

   EAP-PSK provides integrity protection if it is based on a pairwise
   PSK of sufficient strength.  If the PSK is not pairwise or not
   sufficiently strong, then it does not provide authentication.  In
   this way, it is no different than other authentication protocols
   based on Pre-Shared Keys.

8.4.  Replay Protection

   EAP-PSK provides replay protection of its mutual authentication part
   thanks to the use of random numbers RAND_S and RAND_P.  Since RAND_S
   is 128 bits long, one expects to have to record 2**64 (i.e.,
   approximately 1.84*10**19) EAP-PSK successful authentications before
   an authentication can be replayed.  Hence, EAP-PSK provides replay
   protection of its mutual authentication part as long as RAND_S and
   RAND_P are chosen at random; randomness is critical for security.

   EAP-PSK provides replay protection during the conversation of the
   protected channel thanks to the Nonce N of its protected channel (see
   Section 3.3).  This nonce is initialized to 0 by the server and
   monotonically incremented by one by the party that receives a valid
   EAP-PSK message.  For instance, after receiving from the server a
   valid EAP-PSK message with Nonce set to x, the peer will answer with
   an EAP-PSK message with Nonce set to x+1 and wait for an EAP-PSK
   message with Nonce set to x+2.  A retransmission of the server's
   message with Nonce set to x would cause the peer EAP layer to resend
   the message in which Nonce was set to x+1, which would be transparent
   to the EAP-PSK layer.

   The EAP peer must check that the Nonce is indeed initialized to 0 by
   the server.

8.5.  Reflection Attacks

   EAP-PSK provides protection against reflection attacks in case of an
   extended authentication because:

   o  It integrity protects the EAP header (which contains the
      indication Request/Response.

   o  It includes two separate spaces for the Nonces: the EAP server
      only receives messages with odd nonces, whereas the EAP peer only
      receives messages with even nonces.

Top      Up      ToC       Page 49 
8.6.  Dictionary Attacks

   Because EAP-PSK is not a password protocol, it is not vulnerable to
   dictionary attacks.

   Indeed, 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 16-byte PSK has:

   o  Ergonomic impacts: some people may find it cumbersome to manually
      provision a 16-byte PSK.

   o  Deployment impacts: some people may want to reuse existing
      credential databases that contain passwords and not PSKs.

   Because people will probably not heed the warning not to use
   passwords, guidance to derive a PSK from a password is provided in
   Appendix A.  The method proposed in Appendix A only tries to make
   dictionary attacks harder.  It does not eliminate them.

   However, it does not cause a fatal error if passwords are used
   instead of PSKs: people rarely use password-derived certificates, so
   why should they do so for shared keys?

8.7.  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 complies with
   the conditions stated in [5] so that the security proof for this mode

   The underlying block cipher used, AES-128, is widely believed to be a
   secure block cipher.

   A first key derivation occurs to calculate AK and KDK from the PSK:
   it is called the key setup (see Section 3.1).  It uses the PSK as the
   key to the modified counter mode.  Thus, AK and KDK are believed to
   be cryptographically separated and computable only to those who have
   knowledge of the PSK.

Top      Up      ToC       Page 50 
   A second key derivation occurs to derive session keys, namely, the
   TEK, MSK, and EMSK (see Section 3.2).  It uses KDK as the key to the
   modified counter mode.

   The protocol design explicitly assumes that neither AK nor KDK are
   shared beyond the two parties utilizing them.  AK loses its efficacy
   to mutually authenticate the peer and server with each other when it
   is shared.  Similarly, the derived TEK, MSK, and EMSK lose their
   value when KDK is shared with a third party.

   It should be emphasized that the peer has control of the session keys
   derived by EAP-PSK.  In particular, it can easily choose the random
   number it sends in EAP-PSK so that one of the nine derived 16-byte
   key blocks (see Section 2.1) takes a pre-specified value.

   It was chosen not to prevent this control of the session keys by the
   peer because:

   o  Preventing it would have added some complexity to the protocol
      (typically, the inclusion of a one-way mode of operation of AES in
      the key derivation part).

   o  It is believed that the peer won't try to force the server to use
      some pre-specified value for the session keys.  Such an attack is
      outside the threat model and seems to have little value compared
      to a peer sharing its PSK.

   However, this is not the behavior recommended by EAP in Section 7.10
   of [3].

   Since deriving the session keys requires some cryptographic
   computations, it is recommended that the session keys be derived only
   once authentication has succeeded (i.e., once the server has
   successfully verified MAC_P for the server side, and once the peer
   has successfully verified MAC_S for the peer side).

   It is recommended to take great care in implementations, so that
   derived keys are not made available if the EAP-PSK dialog fails
   (e.g., ends with DONE_FAILURE).

   The TEK must not be made available to anyone except to the current
   EAP-PSK dialog.

Top      Up      ToC       Page 51 
8.8.  Denial-of-Service Resistance

   Denial of Service (DoS) resistance has not been a design goal for

   It is, however, believed that EAP-PSK does not provide any obvious
   and avoidable venue for such attacks.

   It is worth noting that the server has to do a cryptographic
   calculation and maintain some state when it engages in an EAP-PSK
   conversation, namely, generate and remember the 16-byte RAND_S.
   However, this should not lead to resource exhaustion as this state
   and the associated computation are fairly lightweight.

   Please note that both the peer and the server must commit to their
   RAND_S and RAND_P to protect their partners from flooding attacks.

   It is recommended that EAP-PSK not allow EAP notifications to be
   interleaved in its dialog 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 EAP notifications to engage in a discussion that would delay
   his or her authentication or result in the peer taking unexpected
   actions (e.g., in case a notification is used to prompt the peer to
   do some "bad" action).

   It is up to the implementation of EAP-PSK or to the peer and the
   server to specify the maximum number of failed cryptographic checks
   that are allowed.  For instance, does the reception of a bogus MAC_P
   in the second EAP-PSK message cause a fatal error or is it discarded
   to continue waiting for the valid response of the valid peer?  There
   is a trade-off between possibly allowing multiple tentative forgeries
   and allowing a direct DoS (in case the first error is fatal).

   For the sake of simplicity and denial-of-service resilience, EAP-PSK
   has chosen not to include any error messages.  Hence, an "invalid"
   EAP-PSK message is silently discarded.  Although this makes
   interoperability testing and debugging harder, this leads to simpler
   implementations and does not open any venue for denial-of-service

8.9.  Session Independence

   Thanks to its key derivation mechanisms, EAP-PSK provides session
   independence: passive attacks (such as capture of the EAP
   conversation) or active attacks (including compromise of the MSK or
   EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs.

Top      Up      ToC       Page 52 
   The assumption that RAND_P and RAND_S are random is central for the
   security of EAP-PSK in general and session independence in

8.10.  Exposition of the PSK

   EAP-PSK does not provide Perfect Forward Secrecy.  Compromise of the
   PSK leads to compromise of recorded past sessions.

   Compromise of the PSK enables the attacker to impersonate the peer
   and the server: compromise of the PSK leads to "full" compromise of
   future sessions.

   EAP-PSK provides no protection against a legitimate peer sharing its
   PSK with a third party.  Such protection may be provided by
   appropriate repositories for the PSK, whose choice is outside the
   scope of this document.  The PSK used by EAP-PSK must only be shared
   between two parties: the peer and the server.  In particular, this
   PSK must not be shared by a group of peers communicating with the
   same server.

   The PSK used by EAP-PSK must be cryptographically separated from keys
   used by other protocols, otherwise the security of EAP-PSK may be
   compromised.  It is a rule of thumb in cryptography to use different
   keys for different applications.

8.11.  Fragmentation

   EAP-PSK does not support fragmentation and reassembly.

   Indeed, the largest EAP-PSK frame is at most 1015 bytes long,

   o  The maximum length for the peer NAI identity used in EAP-PSK is
      966 bytes (see Section 5.2).  This should not be a limitation in
      practice (see Section 2.2 of [2] for more considerations on NAI

   o  The maximum length for the EXT_Payload field used in EAP-PSK is
      960 bytes (see Section 5.3 and Section 5.4).

   Per Section 3.1 of [3], the lower layers over which EAP may be run
   are assumed to have an EAP MTU of 1020 bytes or greater.  Since the
   EAP header is 5 bytes long, supporting fragmentation for EAP-PSK is

   Extensions that require sending a payload larger than 960 bytes
   should provide their own fragmentation and reassembly mechanism.

Top      Up      ToC       Page 53 
8.12.  Channel Binding

   EAP-PSK does not provide channel binding as this feature is still
   very much a work in progress (see [13]).

   However, it should be easy to add it to EAP-PSK as an extension (see
   Section 4.2).

8.13.  Fast Reconnect

   EAP-PSK does not provide any fast reconnect capability.

   Indeed, as noted, for instance, in [15], 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-

   Since this minimum bound is already reached in EAP-PSK standard
   authentication, there is no way the number of round-trips used within
   EAP-PSK can be reduced without using timestamps or counters.
   Timestamps and counters were deliberately avoided for the sake of
   simplicity and security (e.g., synchronization issues).

8.14.  Identity Protection

   Since it was chosen 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.

   Hereafter is an informal discussion of what is meant by identity
   protection and the rationale behind the requirement of identity
   protection.  For some complementary discussion, refer to [37].

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

   As explained in [37], "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)".

   If 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

Top      Up      ToC       Page 54 
   identify each other and usually change them periodically, possibly in
   a protected way so that an attacker cannot learn new pseudonyms
   before they are used.

   With pseudonym management, there is a trade-off 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 time-varying pseudonyms may want to
   anticipate "desynchronization" situations such as, for instance, when
   the peer believes that its current pseudonym is ""
   whereas the server believes this peer will use the pseudonym
   "" (which is the pseudonym the server has sent to
   update "").

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

   However, EAP-PSK may trivially provide some protection when the
   concern is to avoid the "real-life" identity of the user being
   "discovered".  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., "") that allows WISP BAD (or
   an attacker) to recover his "real-life" identity, i.e., John Doe.  An
   example drawback of this is when a competitor of John Doe's WISP
   wants to win John 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 an NAI that allows easy recovery of his real-
   life identity.  It is believed that when an NAI that is not
   correlated to a real-life identity is used, no 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.
   Moreover, the Medium Access Control Address of the peer's Network
   Interface Card can generally be used to track the peer as efficiently
   as a fixed NAI.

Top      Up      ToC       Page 55 
   It is worth noting that the server systematically discloses its
   identity, which may allow probing attacks.  This may not be a problem
   as the identity of the server is not supposed to remain secret.  On
   the contrary, users tend to want to know to whom they will be talking
   in order to choose the right network to attach to.

8.15.  Protected Ciphersuite Negotiation

   EAP-PSK does not allow negotiating ciphersuites.  Hence, it is not
   vulnerable to negotiation attacks and does not implement protected
   ciphersuite negotiation.

8.16.  Confidentiality

   Although EAP-PSK provides confidentiality in its protected channel,
   it cannot claim to do so as per Section 7.2.1 of [3]: "A method
   making this claim must support identity protection".

8.17.  Cryptographic Binding

   Since EAP-PSK is not intended to be tunneled within another protocol
   that omits peer authentication, it does not implement cryptographic

8.18.  Implementation of EAP-PSK

   To really provide security, not only must a protocol be well thought-
   out and correctly specified, but its implementation must take special

   For instance, implementing cryptographic algorithms requires special
   skills since cryptographic software is vulnerable not only 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 [36]).  In particular, care must be taken to
   avoid such attacks in EAX implementation; please refer to [4] for a
   note on this point.

   An EAP-PSK implementation should use a good source of randomness to
   generate the random numbers required in the protocol.  Please refer
   to [20] for more information on generating random numbers for
   security applications.

   Handling sensitive material (namely, keying material such as the PSK,
   AK, KDK, etc.) should be done in a secure way (see, for instance,
   [19] for guidance on secure deletion).

Top      Up      ToC       Page 56 
   The specification of a repository for the PSK that EAP-PSK uses is
   outside the scope of this document.  In particular, nothing prevents
   one from storing this PSK on a tamper-resistant device such as a
   smart card rather than having it memorized or written down on a sheet
   of paper.  The choice of the PSK repository may have important
   security impacts.

9.  Security Claims

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

   [a]  Mechanism.  EAP-PSK is based on symmetric cryptography (AES-128)
        and uses a 16-byte Pre-Shared Key (PSK).

   [b]  Security claims.  EAP-PSK provides:

        *  Mutual authentication (see Section 8.1)

        *  Integrity protection (see Section 8.3)

        *  Replay protection (see Section 8.4)

        *  Key derivation (see Section 8.7)

        *  Dictionary attack resistance (see Section 8.6)

        *  Session independence (see Section 8.9)

   [c]  Key strength.  EAP-PSK provides a 16-byte effective key

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

   [e]  Indication of vulnerabilities.  EAP-PSK does not provide:

        *  Identity protection (see Section 8.14)

        *  Confidentiality (see Section 8.16)

        *  Fast reconnect (see Section 8.13)

        *  Fragmentation (see Section 8.11)

        *  Cryptographic binding (see Section 8.17)

        *  Protected ciphersuite negotiation (see Section 8.15)

        *  Perfect Forward Secrecy (see Section 8.10)

Top      Up      ToC       Page 57 
        *  Key agreement: the session key is chosen by the peer (see
           Section 8.7)

        *  Channel binding (see Section 8.12)

10.  Acknowledgments

   This EAP method has been inspired by EAP-Archie and EAP-SIM.  Many
   thanks to their respective authors: Jesse Walker (extra thanks to
   Jesse Walker for his thorough and challenging expert review of EAP-
   PSK), Russ Housley, Henry Haverinen, and Joseph Salowey.

   Thanks to

   o  Henri Gilbert for some interesting discussions on the
      cryptographic parts of EAP-PSK.

   o  Aurelien Magniez for his valuable feedback on network aspects of
      EAP-PSK, his curiosity and rigor that led to numerous
      improvements, and his help in the first implementation of EAP-PSK
      under Microsoft Windows and Freeradius.

   o  Thomas Otto for his valuable feedback on EAP-PSK and the
      implementation of the first version of EAP-PSK under Xsupplicant.

   o  Nancy Cam-Winget for some exchanges on EAP-PSK.

   o  Jari Arkko and Bernard Aboba, the beloved EAP WG chairs, for the
      work they stimulate.

   Finally, thanks to Vir Z., who has brought a permanent and
   outstanding though discreet contribution to this protocol.

11.  References

11.1.  Normative References

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

   [2]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
         Access Identifier", RFC 4282, December 2005.

   [3]   Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
         Levkowetz, "Extensible Authentication Protocol (EAP)",
         RFC 3748, June 2004.

Top      Up      ToC       Page 58 
   [4]   Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of
         operation", FSE 04, Springer-Verlag LNCS 3017, 2004.

   [5]   Gilbert, H., "The Security of One-Block-to-Many Modes of
         Operation", FSE 03, Springer-Verlag LNCS 2287, 2003.

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

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

   [8]   National Institute of Standards and Technology, "Recommendation
         for Block Cipher Modes of Operation: The CMAC Mode for
         Authentication", Special Publication (SP) 800-38B, May 2005.

11.2.  Informative References

   [9]   Aboba, B., Simon, D., Eronen, P., and H. Levkowetz,"Extensible
         Authentication Protocol (EAP) Key Management Framework", Work
         in Progress, October 2006.

   [10]  Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
         Shiino, H., Zorn, G., Dommety, G., Perkins, C., Patil, B.,
         Mitton, D., Manning, S., Beadles, M., Walsh, P., Chen, X.,
         Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B.,
         Hirschman, B., Hsu, R., Xu, Y., Campell, E., Baba, S., and E.
         Jaques, "Criteria for Evaluating AAA Protocols for work
         Access", RFC 2989, November 2000.

   [11]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
         RFC 2716, October 1999.

   [12]  Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
         Method for 3rd Generation Authentication and Key Agreement
         (EAP-AKA)", RFC 4187, January 2006.

   [13]  Arkko, J. and P. Eronen, "Authenticated Service Information for
         the Extensible Authentication Protocol  (EAP)", Work in
         Progress, October 2005.

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

Top      Up      ToC       Page 59 
   [15]  Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated
         Key Exchange Secure Against Dictionary attacks", EUROCRYPT 00,
         Springer-Verlag LNCS 1807, 2000.

   [16]  Bersani, F., "EAP shared key methods: a tentative synthesis of
         those proposed so far", Work in Progress, April 2004.

   [17]  Bradner, S., "The Internet Standards Process -- Revision 3",
         BCP 9, RFC 2026, October 1996.

   [18]  Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1
         Authentication Protocol", Work in Progress, July 2001.

   [19]  Department of Defense of the United States, "National
         Industrial Security Program Operating Manual", DoD 5220-22M,
         January 1995.

   [20]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
         Requirements for Security", BCP 106, RFC 4086, June 2005.

   [21]  Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
         Protocol (EAP-TTLS)", Work in Progress, July 2004.

   [22]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time
         Password System", RFC 2289, February 1998.

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

   [24]  Haverinen, H. and J. Salowey, "Extensible Authentication
         Protocol Method for Global System for Mobile Communications
         (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186,
         January 2006.

   [25]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
         Standards", RFC 1796, April 1995.

   [26]  Institute of Electrical and Electronics Engineers, "Local and
         Metropolitan Area Networks: Port-Based Network Access Control",
         IEEE Standard 802.1X, September 2001.

   [27]  Institute of Electrical and Electronics Engineers, "Approved
         Draft Supplement to Standard for Telecommunications and
         Information Exchange Between Systems-LAN/MAN Specific
         Requirements - Part 11: Wireless LAN Medium Access Control
         (MAC) and Physical Layer (PHY) Specifications: Specification
         for Enhanced Security", IEEE 802.11i-2004, 2004.

Top      Up      ToC       Page 60 
   [28]  Institute of Electrical and Electronics Engineers, "Standard
         for Telecommunications and Information Exchange Between Systems
         - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium
         Access Control (MAC) and Physical Layer (PHY) Specifications",
         IEEE Standard 802.11, 1999.

   [29]  Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 03,
         Springer-Verlag LNCS 2887, 2003.

   [30]  Jablon, D., "The SPEKE Password-Based Key Agreement Methods",
         Work in Progress, November 2002.

   [31]  Josefsson, S., "The EAP SecurID(r) Mechanism", Work in
         Progress, February 2002.

   [32]  Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected
         EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.

   [33]  Kaliski, B., "PKCS #5: Password-Based Cryptography
         Specification Version 2.0", RFC 2898, September 2000.

   [34]  Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions",
         Work in Progress, April 2004.

   [35]  Kent, S., "IP Authentication Header", RFC 4302, December 2005

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

   [37]  Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
         Authenticated Diffie-Hellman and its Use in the IKE Protocols",
         CRYPTO 03, Springer-Verlag LNCS 2729, June 2003.

   [38]  MacNally, C., "Cisco LEAP protocol description",
         September 2001, available from

   [39]  Metz, C., "OTP Extended Responses", RFC 2243, November 1997.

   [40]  Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of
         Applied Cryptography", CRC Press , 1996.

   [41]  National Institute of Standards and Technology, "Password
         Usage", Federal Information Processing Standards (FIPS) 112,
         May 1985.

Top      Up      ToC       Page 61 
   [42]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
         Flexible Authentication via Secure Tunneling Extensible
         Authentication Protocol Method (EAP-FAST)", Work in Progress,
         October 2006.

   [43]  Schneier, B., Mudge, and D. Wagner, "Cryptanalysis of
         Microsoft's PPTP Authentication Extensions (MS-CHAPv2)",
         CQRE 99, Springer-Verlag LNCS 1740, October 1999.

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

   [45]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
         (CHAP)", RFC 1994, August 1996.

   [46]  Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and
         F. Bersani, "EAP IKEv2 Method", Work in Progress, October 2006.

   [47]  Walker, J. and R. Housley, "The EAP Archie Protocol", Work in
         Progress, June 2003.

   [48]  Wi-Fi Alliance, "Wi-Fi Protected Access, version 2.0",
         April 2003.

   [49]  Wright, J., "Weaknesses in LEAP Challenge/Response", Defcon 03,
         August 2003.

   [50]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
         Transport Layer Security (TLS)", RFC 4279, December 2005.

Top      Up      ToC       Page 62 
Appendix A.  Generation of the PSK from a Password - Discouraged

   It is formally discouraged to use a password to generate the PSK,
   since this opens the door to exhaustive search or dictionary attacks,
   two attacks that would not otherwise be possible.

   EAP-PSK only provides a 16-byte key strength when a 16-byte PSK is
   drawn at random from the set of all possible 16-byte strings.

   However, as people will probably do this anyway, guidance is provided
   hereafter to generate the PSK from a password.

   For some hints on how passwords should be selected, please refer to

   The technique presented herein is drawn from [33].  It is intended to
   try to mitigate the risks associated with password usage in
   cryptography, typically dictionary attacks.

   If the binary representation of the password is strictly fewer than
   16 bytes long (which by the way means that the chosen password is
   probably weak because it is too short), then it is padded to 16 bytes
   with zeroes as its high-order bits.

   If the binary representation of the password is strictly more than 16
   bytes long, then it is hashed down to exactly 16 bytes using the
   Matyas-Meyer-Oseas hash (please refer to [40] for a description of
   this hash.  Using the notation of Figure 9.3 of [40], g is the
   identity function and E is AES-128 in our construction.) with
   IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has been
   arbitrarily selected).

   We now assume that we have a 16-byte number derived from the initial
   password (that can be the password itself if its binary
   representation is exactly 16 bytes long).  We shall call this number

   Following the notations used in [33], the PSK is derived thanks to
   PBKDF2 instantiated with:

   o  P16 as P

   o  The first 96 bits of the XOR of the peer and server NAIs as Salt
      (zero-padded in the high-order bits if necessary).

   o  5000 as c

   o  16 as dkLen

Top      Up      ToC       Page 63 
   Although this gives better protection than nothing, this derivation
   does not stricto sensu protect against dictionary attacks.  It only
   makes dictionary precomputation harder.

Authors' Addresses

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


   Hannes Tschofenig
   Siemens Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich  81739


Top      Up      ToC       Page 64 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and at, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   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

   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


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