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
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
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.
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.
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 ).
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:
* If the peer's policy mandates that it fails in the case of an
unrecognized extension, it sends a DONE_FAILURE in the fourth
* 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
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 .
The following terms are used here with the meanings defined in :
"name space" and "registration".
The following policies are used here with the meanings defined in
: "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
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.
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
 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 .
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 .
The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK,
CMAC, also enjoys a security proof in the provable security paradigm;
see . 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.
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
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
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., ) 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
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
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
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.
8.6. Dictionary Attacks
Because EAP-PSK is not a password protocol, it is not vulnerable to
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  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.
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
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
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
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.
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
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
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.
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  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 , 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.
8.12. Channel Binding
EAP-PSK does not provide channel binding as this feature is still
very much a work in progress (see ).
However, it should be easy to add it to EAP-PSK as an extension (see
8.13. Fast Reconnect
EAP-PSK does not provide any fast reconnect capability.
Indeed, as noted, for instance, in , 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 .
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 , "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
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 "email@example.com"
whereas the server believes this peer will use the pseudonym
"firstname.lastname@example.org" (which is the pseudonym the server has sent to
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., "email@example.com") 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
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.
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
Although EAP-PSK provides confidentiality in its protected channel,
it cannot claim to do so as per Section 7.2.1 of : "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 ). In particular, care must be taken to
avoid such attacks in EAX implementation; please refer to  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  for more information on generating random numbers for
Handling sensitive material (namely, keying material such as the PSK,
AK, KDK, etc.) should be done in a secure way (see, for instance,
 for guidance on secure deletion).
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
9. Security Claims
This section provides the security claims required by .
[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)
* Key agreement: the session key is chosen by the peer (see
* Channel binding (see Section 8.12)
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.
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.1. Normative References
 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
 Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
 Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of
operation", FSE 04, Springer-Verlag LNCS 3017, 2004.
 Gilbert, H., "The Security of One-Block-to-Many Modes of
Operation", FSE 03, Springer-Verlag LNCS 2287, 2003.
 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
 National Institute of Standards and Technology, "Specification
for the Advanced Encryption Standard (AES)", Federal
Information Processing Standards (FIPS) 197, November 2001.
 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
 Aboba, B., Simon, D., Eronen, P., and H. Levkowetz,"Extensible
Authentication Protocol (EAP) Key Management Framework", Work
in Progress, October 2006.
 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.
 Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
 Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement
(EAP-AKA)", RFC 4187, January 2006.
 Arkko, J. and P. Eronen, "Authenticated Service Information for
the Extensible Authentication Protocol (EAP)", Work in
Progress, October 2005.
 Bellare, M. and P. Rogaway, "Entity Authentication and Key
Distribution", CRYPTO 93, Springer-Verlag LNCS 773, 1994.
 Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated
Key Exchange Secure Against Dictionary attacks", EUROCRYPT 00,
Springer-Verlag LNCS 1807, 2000.
 Bersani, F., "EAP shared key methods: a tentative synthesis of
those proposed so far", Work in Progress, April 2004.
 Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1
Authentication Protocol", Work in Progress, July 2001.
 Department of Defense of the United States, "National
Industrial Security Program Operating Manual", DoD 5220-22M,
 Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)", Work in Progress, July 2004.
 Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time
Password System", RFC 2289, February 1998.
 Halpern, J. and Y. Moses, "Knowledge and common knowledge in a
distributed environment", Journal of the ACM 37:3, 1990.
 Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile Communications
(GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186,
 Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
Standards", RFC 1796, April 1995.
 Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
 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.
 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.
 Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 03,
Springer-Verlag LNCS 2887, 2003.
 Jablon, D., "The SPEKE Password-Based Key Agreement Methods",
Work in Progress, November 2002.
 Josefsson, S., "The EAP SecurID(r) Mechanism", Work in
Progress, February 2002.
 Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected
EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
 Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
 Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions",
Work in Progress, April 2004.
 Kent, S., "IP Authentication Header", RFC 4302, December 2005
 Kocher, P., "Timing Attacks on Implementations of Diffie-
Hellman, RSA, DSS, and Other Systems", CRYPTO 96, Springer-
Verlag LNCS 1109, 1996.
 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.
 MacNally, C., "Cisco LEAP protocol description",
September 2001, available from
 Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
 Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of
Applied Cryptography", CRC Press , 1996.
 National Institute of Standards and Technology, "Password
Usage", Federal Information Processing Standards (FIPS) 112,
 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,
 Schneier, B., Mudge, and D. Wagner, "Cryptanalysis of
Microsoft's PPTP Authentication Extensions (MS-CHAPv2)",
CQRE 99, Springer-Verlag LNCS 1740, October 1999.
 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
 Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
 Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and
F. Bersani, "EAP IKEv2 Method", Work in Progress, October 2006.
 Walker, J. and R. Housley, "The EAP Archie Protocol", Work in
Progress, June 2003.
 Wi-Fi Alliance, "Wi-Fi Protected Access, version 2.0",
 Wright, J., "Weaknesses in LEAP Challenge/Response", Defcon 03,
 Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
Transport Layer Security (TLS)", RFC 4279, December 2005.
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 . 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  for a description of
this hash. Using the notation of Figure 9.3 of , g is the
identity function and E is AES-128 in our construction.) with
IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has been
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 , 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
Although this gives better protection than nothing, this derivation
does not stricto sensu protect against dictionary attacks. It only
makes dictionary precomputation harder.
France Telecom R&D
38, rue du General Leclerc
Issy-Les-Moulineaux 92794 Cedex 9
Siemens Networks GmbH & Co KG
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 www.rfc-editor.org/copyright.html, and
except as set forth therein, the authors retain all their rights.
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, THE IETF TRUST 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.
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