RFC 4764
The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method
Pages: 64
Experimental
Experimental
Part 3 of 3 – Pages 41 to 64
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 is: 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
below.
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.
6.1.2. DONE_SUCCESS
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.6.1.3. DONE_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 chosen. 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 implementations). 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 [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 acceptable.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
[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.
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).
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.
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 holds. 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 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.
8.8. Denial-of-Service Resistance
Denial of Service (DoS) resistance has not been a design goal for EAP-PSK. 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 attacks.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 particular.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, because: 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 length). 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 unnecessary. 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 [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- Response. 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
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 "pseudo1@bigco.com" whereas the server believes this peer will use the pseudonym "pseudo2@bigco.com" (which is the pseudonym the server has sent to update "pseudo1@bigco.com"). 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., "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 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.
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 binding.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 care. 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).
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 strength. [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
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.
[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.
[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.
[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 <http://www.missl.cs.umd.edu/wireless/ethereal/leap.txt>. [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.
[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.
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 [41]. 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 P16. 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
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 FR EMail: bersani_florent@yahoo.fr Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich 81739 GE EMail: Hannes.Tschofenig@siemens.com
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. 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 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.