INTERNET-DRAFT EAP-PSK June 2004 Internet Draft Florent Bersani File: draft-bersani-eap-psk-02.txt France Telecom R&D Expires: December 2004 June 2004 The EAP-PSK Protocol: a Pre-Shared Key (PSK) EAP Method Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. This Internet-Draft will expire in December 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a pre-shared key (PSK). This PSK is used by a unique underlying cryptographic primitive, a block cipher, which is instantiated with AES-128. EAP-PSK provides a secure communication channel within EAP in case the authentication is successful. This channel is used to implement protected result indications and may be used by future extensions. EAP-PSK is designed to be easy to deploy and well-suited for authentication over insecure networks such as IEEE 802.11. It is proposed as a replacement for MD5-Challenge. Bersani Expires û December 2004 [Page 1] INTERNET-DRAFT EAP-PSK June 2004 Table of Contents 1. Introduction..................................................4 1.1 Design goals for EAP-PSK...................................4 1.2 Caveats....................................................5 1.3 Specification of requirements..............................6 1.4 Terminology................................................6 1.5 Conventions................................................9 1.6 Related work..............................................10 2. Protocol overview............................................12 2.1 EAP-PSK key hierarchy.....................................12 2.1.1 The PSK............................................12 2.1.2 The TEK............................................13 2.1.3 The MSK............................................13 2.1.4 The EMSK...........................................13 2.1.5 The IV.............................................13 2.2 Cryptographic design of EAP-PSK...........................13 2.2.1 The authenticated key exchange.....................14 2.2.2 The protected channel..............................17 2.3 EAP-PSK message flow......................................23 2.3.1 EAP-PSK standard authentication....................23 2.3.2 EAP-PSK extended authentication....................24 2.4 Identity protection.......................................25 2.5 Fast reconnect............................................25 2.6 Fragmentation.............................................26 3. EAP-PSK state machines.......................................26 3.1 Conventions for the state machines........................27 3.1.1 Rules of operation for the state machines..........27 3.1.2 Graphical representation...........................27 3.1.3 Table representation...............................28 3.2 EAP-PSK peer state machine................................29 3.2.1 Variables and procedures...........................29 3.2.2 Graphical representation...........................37 3.2.3 Table representation...............................37 3.3 EAP-PSK server state machine..............................38 3.3.1 Variables and Procedures...........................39 3.3.2 Graphical representation...........................45 3.3.3 Table representation...............................45 4. EAP-PSK message format.......................................45 4.1 General format of an EAP-PSK message......................45 4.2 Generic format of an EAP-PSK attribute....................46 4.3 Table of the Type field of the different attributes.......47 4.4 Format of the different EAP-PSK attributes................47 4.4.1 AT_EXT.............................................47 4.4.2 AT_ID..............................................48 4.4.3 AT_MAC.............................................48 4.4.4 AT_PCHANNEL........................................49 4.4.5 AT_RAND............................................50 4.4.6 AT_STATUS..........................................50 Bersani Expires û December 2004 [Page 2] INTERNET-DRAFT EAP-PSK June 2004 5. IANA considerations..........................................51 5.1 Allocation of an EAP-Request/Response Type for EAP-PSK....52 5.2 Allocation of EXT_Type numbers............................52 6. Security considerations......................................52 6.1 Identity protection.......................................52 6.2 Mutual authentication.....................................54 6.3 Key derivation............................................54 6.4 Dictionary attacks........................................55 6.5 Protected channel.........................................56 6.6 Negotiation attacks.......................................56 6.7 Man-in-the-middle attacks.................................57 6.8 Random numbers generation.................................57 6.9 Denial of Service resistance..............................57 6.10 Implementation of EAP-PSK................................58 6.11 Exposition of the PSK....................................59 6.12 Channel binding..........................................59 6.13 Fragmentation............................................59 7. Security claims..............................................60 8. Intellectual Property Right Notice...........................61 9. Acknowledgements.............................................61 10. References..................................................61 10.1 Normative................................................61 10.2 Informative..............................................62 11. Authors' Addresses..........................................65 Annex A: Generation of the PSK from a password - Discouraged....67 Annex B: Generation of the PSK from a 128 bit shared key........68 Bersani Expires û December 2004 [Page 3] INTERNET-DRAFT EAP-PSK June 2004 1. Introduction 1.1 Design goals for EAP-PSK The Extensible Authentication Protocol (EAP) [EAP] provides an authentication framework which supports multiple authentication methods. This document specifies an EAP method called EAP-PSK that uses a pre- shared key (PSK). Design goals for this method were: o Simplicity: it should be easy to implement and to deploy without any pre-existing infrastructure o Wide applicability: it should be possible to use this method to authenticate over any network. In particular, it should be suitable for IEEE 802.11 [IEEE802.11] wireless LANs o Security: it should be conservative in its cryptographic design and enjoy security proofs o Extensibility: it should be possible to easily extend this method as the need to do so appears o Patent-avoidance: it should be free of any Intellectual Property Right claims o Reduced time to market: since some of the protocols that rely on EAP are nearly completed (e.g. IEEE 802.11i [IEEE802.11i]), it is crucial that a simple shared key method be provided as quickly as possible For the sake of simplicity, EAP-PSK has thus chosen to rely on a single cryptographic primitive, AES-128 [AES]. The restriction to such a primitive (and in particular, the choice not to use asymmetric cryptography like Diffie-Hellman key exchange) should make EAP-PSK light-weight and well suited for any type of device, especially those with low processing power and memory. However, as further discussed in section 6, this prevents EAP-PSK from offering possibly nice features such as identity protection or Perfect Forward Secrecy (PFS). This choice has been deliberately made as a trade off between simplicity and security. For the sake of simplicity, EAP-PSK also made the assumption that the peer knows the identity of the server it is authenticating to (see section 2.2.1). This assumption probably prevents EAP-PSK to efficiently deal with sophisticated usage scenarios like peer-to-peer ad-hoc mode, that were deemed inessential and infrequent. The level of security offered by EAP-PSK is however compatible with its use over any type of network, and in particular wireless networks. Indeed, it performs mutual authentication and session key derivation and has been designed in the EAP threat model where the attacker has full control over the communication channel. Bersani Expires û December 2004 [Page 4] INTERNET-DRAFT EAP-PSK June 2004 Since the design of authenticated key exchange is notoriously known to be hard and error prone, EAP-PSK does not invent any new mechanism but builds on existing protocols that have been proposed and reviewed by the cryptographic community and enjoy proofs of security in the cryptographic provable security paradigm. To allow for simple extensions, EAP-PSK uses a Type-Length-Value design: new attributes may thus be easily added to EAP-PSK. This design is quite analogous to the attribute format used in EAP-SIM [EAP-SIM], EAP-TTLS [EAP-TTLS] or PEAP [PEAP] and EAP-FAST [EAP-FAST] (please refer to EAP-TLV [EAP-TLV]). EAP-PSK provides a hook to implement these extensions (see section 2.3.2). There has been a trend to play Russian dolls with protocols (IEEE 802.11i which uses IEEE 802.1X [IEEE802.1X] which in turn uses EAP which itself uses EAP methods). The problem is, that now that the outer dolls are quite complete, mature and standard inner dolls tend to lack. To fill this gap as quickly as possible, EAP-PSK chose not to implement any functionality that was deemed superfluous (e.g. identity protection or password support) and that might have thus unnecessarily delayed its release. 1.2 Caveats The reader is strongly advised to keep the following points in mind: o The level of security provided by EAP-PSK is still to be assessed o EAP-PSK should not be confused with other protocols that also have the word "PSK" in their name o The PSK used by EAP-PSK MUST be chosen at random among the set of possible keys o The PSK used by EAP-PSK MUST be cryptographically separated from keys used by any other protocol o EAP-PSK does not mandate in any way how the PSK is to be stored o The "network quality" of EAP-PSK is still to be assessed As has already been said in section 1.1, the design of authenticated key exchange protocols is error prone. Great care should thus be taken regarding EAP-PSK. It is still work in progress and has to be reviewed by cryptographic experts before it can be trusted, although it reuses existing protocols that are deemed secure. Since PSK are of frequent use in security protocols, because a PSK simply means a cryptographic key in the symmetric cryptography setting (see e.g. [HAC] for an introduction to symmetric vs. asymmetric cryptography), attention should be paid not to confuse EAP-PSK with any other protocols that may also refer to a PSK, for Bersani Expires û December 2004 [Page 5] INTERNET-DRAFT EAP-PSK June 2004 instance Wi-Fi Protected Access (WPA) [WPA] when used in its PSK mode. Although, the generation of the PSK used by EAP-PSK is outside of the scope of this document, it is reminded that the PSK MUST be generated by a good source of randomness (see [RFC 1750]) for security properties to hold. In particular, a PSK MUST NOT be confused with a password (see section 6.4 for further discussion). The PSK used by EAP-PSK MUST be cryptographically separated from keys used by any other protocol otherwise the security of EAP-PSK might be voided. It is a rule of the thumb in cryptography to use different keys for different applications. The definition of the repository of the PSK used by EAP-PSK is outside of the scope of this document. In particular, nothing prevents from storing the PSK used by EAP-PSK on a tamper-resistant device such as a smart card rather than having it memorized or written down on a sheet of paper. It is reminded that the choice of the repository used for the PSK may have serious security impacts (see section 6.11 for a brief discussion). Finally, the "network quality" of EAP-PSK e.g. its correctness from a non-cryptographic point of view, its efficiency or the soundness of its non-cryptographic design (e.g. its attribute format) is still to be evaluated by expert network engineers. 1.3 Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2219]. 1.4 Terminology This document frequently uses the following terms: AAA Authentication, Authorization and Accounting, please refer to [RFC 2989] for more details AES Advanced Encryption Standard, a block cipher, please refer to [AES] for more details AKEP Authenticated Key Exchange Protocols. The name of a family of protocols that allow authenticated key exchange and that are specified in [EAKD] Bersani Expires û December 2004 [Page 6] INTERNET-DRAFT EAP-PSK June 2004 Backend Authentication Server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP Methods for the Authenticator (This terminology is also used in [IEEE802.1X]) EAP Extensible Authentication Protocol, please refer to [EAP] for more details EAP Authenticator (or simply Authenticator) The end of the EAP link initiating the EAP authentication methods. (This terminology is also used in [IEEE802.1X], and has the same meaning in this document). EAP Peer (or simply Peer) The end of the EAP Link that responds to the authenticator. ( In [IEEE802.1X], this end is known as the Supplicant) EAP Server (or simply Server) The entity that terminates the EAP authentication with the peer. In the case where there is no Backend Authentication Server, this term refers to the EAP Authenticator. Where the EAP Authenticator operates in pass-through, it refers to the Backend Authentication Server. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 bytes in length. The EMSK is reserved for future uses that are not defined yet and is not provided to a third party. IV Initialization Vector. A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the peer and EAP server. Since the IV is a known value in methods such as EAP-TLS [EAP-TLS], it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and EAP methods are not required to generate it. However, when it is generated it MUST be unpredictable MAC Message Authentication Code. Informally, the purpose of a MAC is to facilitate, without the use of any additional Bersani Expires û December 2004 [Page 7] INTERNET-DRAFT EAP-PSK June 2004 mechanisms, assurances regarding both the source of a message and its integrity, please refer to [HAC] for more details. IEEE 802 specifications use the acronym MIC (Message Integrity Check) to avoid confusion with their acronym MAC (Medium Access Control) Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 bytes in length. In existing implementations a AAA server acting as an EAP server transports the MSK to the authenticator. NAI Network Access Identifier, the NAI is used to identify the parties communicating, see [NAI] OMAC One Key CBC-MAC, a method to generate a Message Authentication Code (MAC, see this word here above), please refer to [OMAC] for more details Perfect Forward Secrecy The confidence that the compromise of a long-term private key does not compromise any earlier session keys. In other words, once an EAP dialog is finished and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the peer and the server cannot reconstruct the keys used to protect the conversation without doing a brute force search of the session key space. PSK Pre-shared key. A pre-shared key is a cryptographic key in the symmetric setting that is derived by some prior mechanism and shared between the parties before the protocol using it takes place. It is merely a sequence of binary digits of given length that have been chosen at random. PRF Pseudo-random function. Please refer for instance to [EAX] for a precise cryptographic definition of this term. Informally a family of functions is pseudo-random if there is no efficient procedure to distinguish between a member of this family chosen at random and a function with the same domain and range chosen at random. By improper though common extension, a member of a family of pseudo-random Bersani Expires û December 2004 [Page 8] INTERNET-DRAFT EAP-PSK June 2004 functions is itself called a pseudo-random function Protected result indication Informally, protected result indication means that the peer and the server share the same view on the success or not of the authentication. This feature has been introduced because EAP-Success/Failure packets are not protected. See [EAP], section 7.16, for more details. PRP Pseudo-random permutation. Please refer for instance to [EAX] for a precise cryptographic definition of this term. Informally a family of permutations is pseudo-random if there is no efficient procedure to distinguish between a member of this family chosen at random and a permutation with the same domain chosen at random. By improper though common extension, a member of a family of pseudo-random permutations is itself called a pseudo-random permutation Transient EAP Keys (TEKs) Session keys which are used to establish a protected channel between the EAP peer and server during the EAP authentication exchange. The TEKs are appropriate for use with the ciphersuite negotiated between EAP peer and server for use in protecting the EAP conversation. Note that the ciphersuite used to set up the protected channel between the EAP peer and server during EAP authentication is unrelated to the ciphersuite used to subsequently protect data sent between the EAP peer and authenticator. 1.5 Conventions All numbers involved in cryptographic calculations are considered in network-byte order. || denotes concatenation of strings (and not the logical OR). MAC(K,String) denotes the MAC of String under the key K (the algorithm used in this document to compute the MAC is OMAC1 with AES- 128, see section 2.2.1) [String] denotes the concatenation of String with the MAC of String calculated as specified by the context. Hence, [String]=String||MAC(K,String) where K is specified by the context. ** denotes integer exponentiation. Bersani Expires û December 2004 [Page 9] INTERNET-DRAFT EAP-PSK June 2004 ôiö denotes the unsigned binary representation on 128 bits of the integer i in network byte order. Therefore this notation only makes sense when i is between 0 and 2**128-1. denotes the unsigned binary representation on 32 bits of the integer i in network byte order. Therefore this notation only makes sense when i is between 0 and 2**32-1. 1.6 Related work So far, at the time this document is written, only three EAP methods are standards track EAP methods per IETF terminology (please, refer to [RFC2026]), namely: o MD5-Challenge (EAP-Request/Response type 4), defined in [EAP], which uses a MD5 challenge similar to [CHAP] o OTP (EAP-Request/Response type 5), defined in [EAP], which aims at providing One-Time Password support o GTC (EAP-Request/Response type 6), defined in [EAP], which aims at providing Generic Token Card Support Unfortunately, all three are deprecated for security reasons that are partly explained in [EAP]. Myriads of EAP methods have however been otherwise proposed, some as informational RFCs (e.g. [EAP-TLS]) - which thus aren't standards (see [RFC 1796] and [RFC 2026]), some as individual Internet-Drafts submissions (e.g. [PEAP] or this document) and some even undocumented (e.g. Rob EAP which has EAP-Request/Response type 31). Although it may be considered good news for mankind creativity, this situation is quite a pity because it is not easy at all for the profane (and sometimes for the expert as well): o To choose the/an EAP method that suits a specific usage scenario o To know whether the EAP method it has selected is mature, still evolving or, worse, abandoned o To be sure that the EAP method it has selected is not broken from a functional or a secure point of view o To be sure that he will find implementations of the EAP method it has chosen on a wide range of platforms and that these implementations will be interoperable A recommended reading on do's and don'ts for authentication methods is [SAM]. Anyway, sad as it may be, no secure and mature shared key EAP method exists, which is all the more regrettable that shared key methods are supposed to be the simplest ones! Bersani Expires û December 2004 [Page 10] INTERNET-DRAFT EAP-PSK June 2004 Yet, a good many proposals for such shared key methods exist, that we briefly review here after (please refer to [SKM] for a more thorough synthesis on EAP methods). Among the existing proposed shared key methods, we distinguish between those which: o Are broken from a security point of view e.g. LEAP [LEAP] - see [LEAPVUL] - or EAP-MSCHAPv2 [EAP-MSCHAPv2] o Would normally require additional infrastructure to work e.g. EAP-SIM, EAP-AKA [EAP-AKA] or OTP/token card methods like [EAP-SecurID] o Are abandoned but have provided the basis for EAP-PSK e.g. EAP-Archie [EAP-Archie] o Are not shared key methods but often confused with them, namely the password methods e.g. EAP-SRP [EAP-SRP] or SPEKE [SPEKE] - which very unfortunately seem to have serious IPR concerns o Are possible alternatives to EAP-PSK (i.e. claimed to be secure and subject of active work), namely EAP-FAST [EAP- FAST], EAP-IKEv2 [EAP-IKEv2] or EAP-TLS (when shared key/password support will be added to TLS) What makes then EAP-PSK different from the related work mentioned here above? Essentially, the fact that EAP-PSK does not wish to be the shared key solution but rather wishes to stimulate the community to standardize such a solution by fully opening its development process (see Annex C). Indeed, EAP-PSK tries to borrow all the best parts of the existing proposals and merge them into a single method. In its attempt to retain the strengths of the other proposed shared key EAP methods, EAP-PSK is currently faced with some issues, such as: o Should a "new" shared key authentication and key exchange mechanism be used in EAP-PSK or is there any standard and well-reviewed such mechanism at IETF that could be cut-and- paste? o Should there be a single EAP method that allows a variety of authentication mechanisms or as many EAP methods as authentication mechanisms? o What should be the security requirements for a shared key EAP method? The first question above is not about inventing a new cryptographic authenticated key exchange protocol - we have strictly forbidden us to do so - but rather about finding a cryptographic mechanism among the existing ones that has been integrated in a "real-world" standard at IETF. In fact and very surprisingly, apart from the deprecated shared key mechanisms such as [CHAP], the possible IETF candidates, namely IKEv2 and TLS with shared key/password, do not seem to be Bersani Expires û December 2004 [Page 11] INTERNET-DRAFT EAP-PSK June 2004 appropriate. Firstly, these mechanisms raise the "unifying" question in EAP (see next paragraph) as they are themselves designed to allow for a variety of authentication methods (public-key certificates, shared keys, passwords). Secondly, they have some specific concerns: IKEv2 mandates use of public key cryptography (namely Diffie-Hellman key exchange) and shared key/password support in TLS is still work in progress. As EAP is already a framework, it seems natural to have different methods for different situations, as a single method for all situations would simply be a another framework redundant with EAP. However the latter seems to be the trend (e.g. PEAP/EAP-TTLS/EAP-FAST allow virtually any authentication method for the peer and TLS or IKEv2 could handle public key or shared key and even password authentication). Is this trend regrettable? We call this the "unifying question". Last, although some work has been done to clarify the requirements on EAP methods ([IEEE802REQ]), it is still unclear in our opinion what the real-world constraints are, e.g. should an EAP method try to adjust to legacy devices or credentials (like EAP-FAST)? More on these issues can be found at http://perso.rd.francetelecom.fr/bersani/EAP_PSK/EAP-PSK.htm Any feedback to the author will be most appreciated. 2. Protocol overview 2.1 EAP-PSK key hierarchy This section instantiates the EAP Key hierarchy described in [EKMF] for EAP-PSK. 2.1.1 The PSK EAP-PSK uses a long-lived 32 byte secret key called the PSK that is shared between the EAP Peer and the EAP Server. This PSK has an internal structure. It consists of two 16 byte subkeys, respectively called the authentication key (AK) and the key- derivation key (KDK). Hence, PSK=AK||KDK The protocol uses the AK to mutually authenticate the EAP Peer and the EAP Server and the KDK to derive keying material between the EAP Peer and the EAP Server. It should be emphasized again that EAP-PSK assumes that AK and KDK are cryptographically separated and that its security proof relies on this assumption. In case the PSK is drawn at Bersani Expires û December 2004 [Page 12] INTERNET-DRAFT EAP-PSK June 2004 random from the set of possible keys (i.e. 32 byte strings), this assumption is verified. EAP-PSK assumes that the PSK is known only to the EAP Peer and EAP Server. The security properties of the protocol may be compromised if it has wider distribution. The protocol also assumes the EAP Server and EAP Peer identify the correct PSK to use with each other by their respective Network Access Identifiers (NAIs - see [RFC 2486]). 2.1.2 The TEK EAP-PSK allows for TEK derivation thanks to a random number exchanged during authentication and the KDK. There is only one TEK used within an EAP-PSK dialog. The TEK used within an EAP-PSK dialog is a 16 byte key that is used to set up a protected channel for both mutually authenticated parties to communicate securely. 2.1.3 The MSK EAP-PSK allows for MSK derivation thanks to a random number exchanged during authentication and the KDK. As specified in [EKMF], the MSK is 64 bytes long. 2.1.4 The EMSK EAP-PSK allows for EMSK derivation thanks to a random number exchanged during authentication and the KDK. As specified in [EKMF], the EMSK is 64 bytes long. 2.1.5 The IV EAP-PSK does not derive any IV. 2.2 Cryptographic design of EAP-PSK EAP-PSK relies on a single cryptographic primitive, a block cipher, which is instantiated with AES-128. AES-128 has been chosen because: o It is standardized and implementations are widely available o It has been carefully reviewed by the community and is believed to be secure Bersani Expires û December 2004 [Page 13] INTERNET-DRAFT EAP-PSK June 2004 However, in case it should be needed, new instantiations of EAP-PSK with other block ciphers could easily be proposed as EAP-PSK does not intricately depend on the chosen block cipher. The only parameters of the block cipher that EAP-PSK depends on, are its block size (128 bits) and its key size (128 bits). For the sake of simplicity, it has been chosen not to allow the negotiation of other block ciphers for EAP-PSK. For a detailed description of AES-128, please refer to [AES]. EAP-PSK uses two cryptographic parts: o An authenticated key exchange protocol to mutually authenticate the communicating parties, that follows the design presented in [EAKD] under the name AKEP2 instantiated with OMAC1 [OMAC], the modified counter mode [SOBMMO] and AES-128 o A secure channel protocol for both mutually authenticated parties to communicate, that uses the EAX [EAX] mode of operation with AES-128 2.2.1 The authenticated key exchange The authentication protocol used by EAP-PSK is the Authenticated Key Exchange Protocol 2 (AKEP2) described in [EAKD]. It consists of a one and half round trip exchange depicted in Figure 1. Bob Alice | | | A, RA | |<---------------------------------------------------------| | | | [B||A||RA||RB] | |--------------------------------------------------------->| | | | [A||RB] | |<---------------------------------------------------------| Figure 1: Overview of AKEP2 In Figure 1: o RA and RB are random numbers chosen respectively by Alice and Bob o A and B are Alice's and Bob's respective identities o The MACs (see section 1.5 for the notation []) are calculated using a dedicated key EAP-PSK instantiates this protocol with: Bersani Expires û December 2004 [Page 14] INTERNET-DRAFT EAP-PSK June 2004 o RA and RB taken to be 128 bit random numbers chosen respectively by Alice and Bob o A and B taken to be Alice's and BobÆs respective NAIs o The MAC algorithm we use is OMAC1 with AES-128 using a 128-bit portion of the PSK called AK (see section2.1.1) and producing a tag length of 128 bits. o The modified counter mode of operation of AES-128 to derive the keying material resulting from this exchange. OMAC was chosen because of its handling of arbitrary length messages and its design simplicity. It also enjoys a security proof, which has not been found to be flawed so far and is believed to have been extensively reviewed by the cryptographic community. For a detailed description of OMAC, please refer to [OMAC]. Since in AKEP2 the key exchange is "implicit", we have to specify the cryptographic derivation of the session keys from RB. This cryptographic derivation is realized using the modified counter mode described in [SOBMMO]. This mode was chosen because it seems to be one of the rare simple key derivation schemes that relies on a block cipher and has a proof of its security. The modified counter mode is a length increasing function, i.e. it expands a 1-block input value into a longer t-block output, where t>=2. Figure 2 below depicts the modified counter mode as a black box used by EAP-PSK. RB KDK Input Block (128 bits) Key Derivation Key (128 bits) | | v v +-------------------------------------------------------------+ | | | Modified Counter Mode | | | +------------------------------------------------------------+ | | | v v v +---------+ +---------------------+ +---------------------+ | TEK | | MSK | | EMSK | +---------+ +---------------------+ +---------------------+ Figure 2: The modified counter mode as a black box for EAP-PSK The underlying block cipher used by this counter mode is AES-128. Bersani Expires û December 2004 [Page 15] INTERNET-DRAFT EAP-PSK June 2004 The input block to the key derivation is taken to be RB as specified in AKEP2 (see section 6.3 for a discussion of the implications of this choice). The key used for key derivation is a portion of the PSK called the KDK, see section 2.1.1. For what regards the output blocks, using [EKMF] terminology: o The first output block is the TEK that will be used by the current instance of EAP-PSK o The second to fifth output blocks of the key derivation are the Master Session Key (MSK) o The sixth to ninth output blocks of the key derivation are the Extended Master Session Key (EMSK) We hereafter describe precisely the parameters with which we use the modified counter mode in EAP-PSK using the same notations as in [SOBMO]. All rotation values (the ri per [SOBMMO] Figure 3 notation) are set to zero (no rotations) and the counter values (the ci per [SOBMMO] Figure 3 notation) are respectively set to the first t integers (that is ci="i", starting with i=1). The ri were taken equal to zero for the sake of simplicity. While we take the ri to be all zeroes, taking ci="i" ensures that the security proof holds (because it implies that that the ci are all distinct). The parameter t of [SOBMO] is set to 9 so that the amount of keying material needed is exactly generated (i.e. with a 128 bit block length, a 1 block TEK, a 4 block MSK and a 4 block EMSK). Figure 3 below depicts the modified counter mode used for key derivation within EAP-PSK showing its internals. Bersani Expires û December 2004 [Page 16] INTERNET-DRAFT EAP-PSK June 2004 RB Input Block (128 bits) | | +----------------+ | | | AES-128(KDK,.) | | | +----------------+ | | +---------------------+--..................--+ | | | | | | +-------+ +-------+ +-------+ c1="1" ->| XOR | c2="2" ->| XOR | ... c9="9" ->| XOR | (128 bits) +-------+ (128 bits) +-------+ (128 bits) +-------+ | | | | | | +----------------+ +----------------+ +----------------+ | | | | | | | AES-128(KDK,.) | | AES-128(KDK,.) |......| AES-128(KDK,.) | | | | | | | +----------------+ +----------------+ +----------------+ | | | | | | Output Block #1 Output Block #2 Output Block #9 (128 bits) (128 bits) ...... (128 bits) TEK MSK Block #1 EMSK Block #4 Figure 3: EAP-PSK Key derivation with the modified counter mode 2.2.2 The protected channel EAP-PSK provides a secure channel called "the protected channel" in case of a successful authentication for both parties to communicate over. This protected channel is provided to allow protected result indications and future extensions of EAP-PSK (such as account reporting and provisioning). Figure 4 below describes the protected channel as a black box for EAP-PSK when used in the encryption way. Bersani Expires û December 2004 [Page 17] INTERNET-DRAFT EAP-PSK June 2004 +-----------+ +----------------+ +---------------------+ +----------+ | Nonce N | | Header H | | Plain Text Payload | | TEK | | 32 bits | | 9 bytes | | Variable length v | | 128 bits | +-----------+ +----------------+ +---------------------+ +----------+ | | | | v v v v +-------------------------------------------------------------------+ | | | Protected Channel | | | +-------------------------------------------------------------------+ | | | v v v +-----------+ +----------------------------------------+ +----------+ | Nonce N | | Encrypted Payload | | Tag | | 32 bits | | Variable length v | | 128 bits | +-----------+ +----------------------------------------+ +----------+ Figure 4: The protected channel in the encryption way used as a black-box by EAP-PSK The nonce N is used to provide cryptographic security to the encryption and to the MAC as well as to provide protection replay (indeed we take for nonce N a 32 bit sequence number that is monotonically incremented). The Header H consists in the first 5 bytes of the EAP request or response packet (i.e. the Code, Identifier, Length and Type fields) followed by the first 4 bytes of AT_PCHANNEL (i.e. the EAP-PSK Attribute Type for AT_PCHANNEL, its length and Reserved fields - see section 4.4.4). The Plain Text payload is the payload that is to be encaspulated (once it has been encrypted) as the AT_PCHANNEL payload (see section 4.4.4). The Tag is a MAC that protects both the Header and the payload. It is included in the AT_PCHANNEL Tag field (see section 4.4.4). Figure 5 below describes the protected channel as a black box for EAP-PSK when used in the decryption way Bersani Expires û December 2004 [Page 18] INTERNET-DRAFT EAP-PSK June 2004 +---------+ +----------+ +-----------------+ +----------+ +---------+ | Nonce N | | Header H | |Encrypted Payload| | Tag | | TEK | | 32 bits | | 9 bytes | |Variable length v| | 128 bits | | 128 bits| +---------+ +----------+ +-----------------+ +----------+ +---------+ | | | | | v v v v v +-------------------------------------------------------------------+ | | | Protected Channel | | | +-------------------------------------------------------------------+ | v +----------------------------------------+ | Plain Text Payload | | Variable length v | +----------------------------------------+ or +----------------------------------------+ | INVALID | | | +----------------------------------------+ Figure 5: The protected channel in the decryption way used as a black-box by EAP-PSK The decryption process returns either the plain text payload or invalid if the replay counter does not have the expected value or if the tag does not match its expected value. EAP-PSK uses the EAX mode of operation described in [EAX] to provide this protected channel. EAX was mainly chosen because it strongly relied on OMAC in its design and OMAC had already been chosen in EAP-PSK for the authentication part. EAX was also chosen because of the simplicity of its design and the security proof it enjoys. It should however be understood that there are currently many other proposed modes for authenticated encryption with associated data (including IPR free ones, like CCM, CWC or GCM, please refer to [MOSKBC] for more details) and that the complexity and novelty of EAX security proof may be a concern. We hereafter describe the parameters with which we use EAX in EAP-PSK using the same notations as in [EAX]. EAX is instantiated with AES-128 as the underlying block cipher keyed with the TEK (see section 2.1.2). Bersani Expires û December 2004 [Page 19] INTERNET-DRAFT EAP-PSK June 2004 The tag length is chosen to be 128 bits for EAX within EAP-PSK. The nonce N used by EAX (following [EAX] Figure 3 notation) is a counter starting with <0> and incremented at each subsequent EAP-PSK message (except retransmissions of course) within one EAP-PSK dialog. Thus, N can be considered a replay counter. The nonce N was taken on 32 bits to simplify implementations (i.e. to avoid 128 bit arithmetic). Since EAX uses a 128 bit nonce, N is padded with 96 zero bits for its high order bits. Thus, the maximum number of messages that can be exchanged over the same protected channel is 2**32 (which should not be a limitation in practice as 2**32 is approximately equal to 4 billions). Indeed, the 32 low order bits of N are not allowed to wrap up. In the unlikely yet possible event of the server having sent an EAP-PSK message with the 32 low order bits of N set to 2**32-2, it MUST NOT send any further message on this protected channel (which would cause the nonce to wrap up and reuse the value 0): either the conversation is finished after the server receives the EAP-PSK answer from the peer with the 32 low order bits of N set to 2**32-1 and the server proceeds (typically by sending an EAP message of type success or failure), or the conversation is not finished and MUST then be aborted (a new EAP-PSK dialog MAY subsequently be started to try again to successfully authenticate). The message M used by EAX (following [EAX] Figure 3 notation) consists of the message that one party wishes to send to the other over the protected channel (i.e. the AT_PCHANNEL payload, which can be an AT_STATUS or an AT_STATUS and an AT_EXT - see section 4.4.4). The header H used by EAX (following [EAX] Figure 3 notation) is taken to be the EAP header of the EAP packet in which the EAP-PSK packet is encapsulated followed by the first four bytes of the AT_PCHANNEL header. Although it may appear unorthodox that an upper layer (EAP- PSK) protects some information of the lower layer (EAP), this was chosen to comply with [EAP] recommendation (see section 7.5. of [EAP]) and seems to be existing practice at IETF (e.g. see [AH]) Before giving a detailed presentation of EAX, we first present in Figure 6 the notation we use for EAX encryption building block: the counter mode. Figure 6 depicts the counter mode of operation with AES-128 as the underlying primitive which is used for encryption in EAP-PSK protected channel. This counter mode is part of the EAX mode of operation that is depicted in Figure 8. This counter mode should not be confused with the modified counter mode used for key derivation. Bersani Expires û December 2004 [Page 20] INTERNET-DRAFT EAP-PSK June 2004 Message M (Variable length V) | +----------------+ | | St -->| CTR(TEK,.,.) | (128 bits) | | +----------------+ | Cipher Text C (Variable length V) Figure 6: The counter mode used in EAP-PSK protected channel The counter mode CTR takes three input values: o TEK, which is the key used to encrypt the counter thanks to AES- 128 o St, which is a 128 bit value taken to be the starting point of the counter o M, which is a variable length message to encrypt The counter mode CTR produces one output value: o C, which is the variable length cipher text resulting from the encryption of the message In Figure 7 below, we present, a notation used in to depict OMAC1 which is intensively used in EAX. Message M (Variable length V) | +----------------+ | | | OMAC1(TEK, P) | | | +----------------+ | Tag T (128 bits) Figure 7: OMAC1 used in EAP-PSK protected channel OMAC1 takes three input values: o TEK, which is the key used by the underlying AES-128 o M, which is a variable length message to process o P, which is an variable length prefix (possibly the empty string) to pre-pend to M OMAC1 produces one output value: Bersani Expires û December 2004 [Page 21] INTERNET-DRAFT EAP-PSK June 2004 o T, which is a 128 bit tag resulting from the processing of the message. In Figure 8 below, we finally present the internals of EAX as used by EAP-PSK. Nonce N Message M Header H (128 bits) (Variable Length V) (9 bytes) | | | +-------------------+ | +-------------------+ | | | | | | OMAC1(TEK,"0") | | | OMAC1(TEK,"1") | | | | | | +-------------------+ | +-------------------+ | | | | +----------------+ | | | | | +------------>| CTR(TEK,.,.) | | | | | | | +----------------+ | | | | | | | | Cipher Text C | | (Variable Length V) | | | | | | | | +-------------------+ | | | | | | | OMAC1(TEK,"2") | | | | | | | +-------------------+ | | | | | | | | | | | +-------+ | +----------------->| XOR |<---------------+ +-------+ | Tag T (128 bits) Figure 8: EAP-PSK Protected channel using EAX EAX takes three inputs: o The Nonce N that is used to provide security to encryption and authentication and to provide a replay counter o The Header H that will be authenticated but not encrypted o The Message M that will be authenticated and encrypted Bersani Expires û December 2004 [Page 22] INTERNET-DRAFT EAP-PSK June 2004 EAX takes a key, the TEK EAX produces two outputs: o The Cipher Text C, that is the result of the encryption of message M o The Tag, that is the MAC of H and M 2.3 EAP-PSK message flow EAP-PSK allows basically two different types of message flows: o The simple "standard authentication", which should be used most of the time o The "extended authentication", which consists in using a hook EAP-PSK provides (namely AT_EXT, see section 4.4.1) to extend it 2.3.1 EAP-PSK standard authentication Basically, EAP-PSK standard authentication is comprised of four messages (i.e. two round trips): o The first message is sent by the server to the peer an consists in a random challenge (AT_RAND) o The second message is sent by the peer to the server to state its identity (AT_ID), to send another random challenge (AT_RAND), and to authenticate itself by proving it is able to compute AT_MAC, which is a function of the two aforementioned challenges and the PSK o The third message is sent by the server to the peer to authenticate itself by proving it is able to compute another AT_MAC, which is computed as a function of the peer's challenge and the PSK (AT_MAC), to confirm the liveness of the derived session keys and to give a protected result indication of the authentication (AT_PCHANNEL) o The fourth message is sent by the peer to the server to confirm the liveness of the derived session keys and to give a protected result indication of the authentication (AT_PCHANNEL) Figure 9 below depicts the EAP-PSK standard authentication Bersani Expires û December 2004 [Page 23] INTERNET-DRAFT EAP-PSK June 2004 Peer Server | EAP-PSK/AT_RAND | |<---------------------------------------------------------| | | | EAP-PSK/AT_ID, AT_RAND, AT_MAC | |--------------------------------------------------------->| | | | EAP-PSK/AT_MAC, AT_PCHANNEL | |<---------------------------------------------------------| | | | EAP-PSK/AT_PCHANNEL | |--------------------------------------------------------->| | | Figure 9: EAP-PSK standard authentication In Figure 9, AT_ID, AT_RAND, AT_MAC and AT_PCHANNEL stand for the different attributes that are exchanged. In particular, although two attributes may be of the same type (i.e. AT_RAND in message #1 and #2, AT_MAC in messages #2 and #3 or AT_PCHANNEL in messages #3 and #4), it should be understood that this does not mean that their payload is the same. For instance, AT_RAND in message #1 contains a random number chosen by the server whereas AT_RAND in message #2 contains a random number chosen by the peer, which is with very high probability different from the one chosen by the server. This basic message flow could be comprised of only three messages, like AKEP2 were it not the request/response nature of EAP that prevents the third message to be the last one. We take advantage of this situation by mandating the setup of a protected channel. The basic message flow also includes a statement by the peer of its identity, in addition to the EAP-Request/Response Identity that has already occurred, as recommended in section 5.1 of [EAP]. The exact behavior of the standard authentication is specified and discussed in section 3. 2.3.2 EAP-PSK extended authentication In order to remain simple and yet to be extensible to meet future requirements, EAP-PSK provides a hook: AT_EXT which is a generic attribute that can be used by extensions. This attribute is encapsulated in AT_PCHANNEL. It may be included in the AT_PCHANNEL of the third message of the EAP-PSK standard authentication and, if it is, it will be included in all subsequent AT_PCHANNEL attributes. See section 3, 5 and 6 for more discussion. Bersani Expires û December 2004 [Page 24] INTERNET-DRAFT EAP-PSK June 2004 Although AT_EXT support is mandatory, no particular extension is currently defined. Hence, the support of any particular extension type (EXT_Type, see section 4.4.1) is optionnal. Figure 10 below depicts an extended authentication Peer Server | EAP-PSK/AT_RAND | |<---------------------------------------------------------| | | | EAP-PSK/AT_ID, AT_RAND, AT_MAC | |--------------------------------------------------------->| | | | EAP-PSK/AT_MAC, AT_PCHANNEL(AT_STATUS, AT_ExT) | |<---------------------------------------------------------| | | | EAP-PSK/AT_PCHANNEL(AT_STATUS, AT_EXT) | |--------------------------------------------------------->| | | | EAP-PSK/AT_PCHANNEL(AT_STATUS, AT_ExT) | |<---------------------------------------------------------| | | | EAP-PSK/AT_PCHANNEL(AT_STATUS, AT_EXT) | |--------------------------------------------------------->| | | Figure 10: EAP-PSK extended authentication 2.4 Identity protection It has been chosen not include any identity protection scheme in EAP- PSK, see section 6.1 for more discussion. 2.5 Fast reconnect It has been chosen not to include any fast reconnect capability in EAP-PSK. Indeed, as noted for instance in [AKSD], mutual authentication (without counters or timestamps) requires three exchanges, thus four exchanges in EAP since any EAP-Request MUST be answered to by an EAP- Response. Since this minimum bound is already reached in EAP-PSK standard authentication, there is no way we can reduce within EAP-PSK the number of round-trips used in case of fast reconnect. However, there could be an obvious way to reduce the number of EAP- PSK round trips by using the EAP-Request/Identity and EAP- Response/Identity (which is not part of EAP-PSK) but the consequences of this have to be carefully evaluated (for instance, [NETSEL] also Bersani Expires û December 2004 [Page 25] INTERNET-DRAFT EAP-PSK June 2004 intends to reuse these messages). We therefore chose not to rely on unverified assumptions about external protocols. Since the processing and memory resources required by a standard EAP- PSK authentication are already very light, we chose not to try any hazardous optimization that would anyway have probably ended to be more complex, to make more efficient computations to provide fast reconnect. Such optimizations makes a lot more sense in cryptographic protocols that use both asymmetric and symmetric cryptography (e.g. TLS), when the asymmetric part can be avoided, as it is well known to be much more computation/memory intensive than the symmetric one. Furthermore, possible extensions of EAP (like the AMSK, see [EKMF]) may well be used to provide fast reconnect in more efficient ways than EAP methods could do (by, for instance, in case of a roamer, not requiring a communication between the peer and the home server but allowing instead a conversation between the peer and the visited server). 2.6 Fragmentation EAP-PSK does not support fragmentation and reassembly. Indeed, for a standard authentication, the largest EAP-PSK frame is 1004 bytes because we bounded the length of the identity used in EAP- PSK to 960 bytes, see 4.4.2 for more details. Since EAP has a header of 5 bytes and per [EAP] section 3.1, the lower layers over which EAP MAY be run are assumed to have an EAP MTU of 1020 bytes or greater, not supporting fragmentation for EAP-PSK standard authentication should not lead to any problem. In case extended authentication, it is the responsibility of the extension mechanism to handle their fragmentation (which can be done in an obvious way, see e.g. [EAP-TLS]). The security implications of fragmentation are discussed in section 6.13. 3. EAP-PSK state machines This section gives a formal description of the EAP-PSK peer and server state machines. First, it defines the conventions used for this description in subsection 3.1 and then proceeds to the actual description of the EAP-PSK peer state machine (in subsection 3.2) and EAP-PSK server state machine (in subsection 3.3). These EAP-PSK state machines take into account the EAP peer and server state machines that are defined in [EAP-SM] and interface to Bersani Expires û December 2004 [Page 26] INTERNET-DRAFT EAP-PSK June 2004 them. Thus, many conventions and notations in the sequel are directly derived from this document. 3.1 Conventions for the state machines 3.1.1 Rules of operation for the state machines Exactly one state of each state machine is active at any given time. In each state, there is one and only one transition which condition evaluates to true. Hence, there cannot be multiple possible transitions at the same given time. The state machines use variables and procedures. The variables are used to maintain state or to interface with other layers. The variables used by the state machines may be: o Long term, i.e. their value is maintained across different EAP- PSK dialogs o Short term, i.e. their value is particular to a specific EAP-PSK dialog The procedures are used to take some actions during an EAP-PSK dialog, e.g. check that a received EAP-PSK packet is well-formed (syntactically and/or cryptographically) or build a response to an received EAP-PSK packet. On entry to a state, the procedures defined for the state (if any) are executed exactly once, in the order that they appear on the page (in the table notation, see section 3.1.3). Each action is deemed to be atomic; i.e., execution of a procedure completes before the next sequential procedure starts to execute. No procedures execute outside of a state block. The procedures in only one state block execute at a time, even if the conditions for execution of state blocks in different state machines are satisfied, and all procedures in an executing state block complete execution before the transition to and execution of any other state block occurs, i.e., the execution of any state block appears to be atomic with respect to the execution of any other state block and the transition condition to that state from the previous state is TRUE when execution commences. 3.1.2 Graphical representation Figure 11 depicts the notation used in the EAP-PSK peer and server state machines graphical representations. Bersani Expires û December 2004 [Page 27] INTERNET-DRAFT EAP-PSK June 2004 +-----------+ +-----------+ | | | | | STATE_X |----+---->| STATE_Y | | | | | | +-----------+ | +-----------+ | +-----------+ | | | | | STATE_Z |<---+ | | +-----------+ Figure 11: Example state machine graphical representation The graphical representation of a state machine only shows the different states and the possible transitions between these states. It does not show the procedures to execute on entry to a state and the transition conditions (they are shown in the table representation, see section 3.1.3). The goal of the graphical representation of a state machine is to give a compact overview of the protocol. In the graphical representation of a state machine, each state is represented as a rectangular box that contains the name of the state. All permissible transitions between different states are represented by arrows, the arrowhead denoting the direction of the possible transition. Thus, in Figure 11, there are permissible transitions from X to Y and X to Z (but not from Z to X, for instance). 3.1.3 Table representation Figure 12 below depicts the table representation of the EAP-PSK peer state machine. -----------------------------+------------------------+-------------- X | XCounter==0 | Y |------------------------+-------------- XCounter++ | XCounter==1 | Z -----------------------------+------------------------+-------------- Figure 12: Example state machine table representation The notation is as follows: state name and procedure executed when entering it are shown on the left; outgoing transitions with their conditions are shown on the right. Bersani Expires û December 2004 [Page 28] INTERNET-DRAFT EAP-PSK June 2004 The procedures and transition conditions are expressed in pseudo- code, derived of the notation of the C++ programming language, ISO/IEC 14882. We briefly recall the symbols we use: ( ) Used to force the precedence of operators in Boolean expressions and to delimit the argument(s) of actions within state boxes. ; Used as a terminating delimiter for actions within state boxes. Where a state box contains multiple actions, the order of execution follows the normal English language conventions for reading text. = Assignment action. The value of the expression to the right of the operator is assigned to the variable to the left of the operator. ! Logical NOT operator. && Logical AND operator. != Inequality. Evaluates to TRUE if the expression to the left of the operator is not equal in value to the expression to the right. == Equality. Evaluates to TRUE if the expression to the left of the operator is equal in value to the expression to the right. ++ Incrementation by one of an integer. 3.2 EAP-PSK peer state machine 3.2.1 Variables and procedures The EAP-PSK peer state machine uses the interface variables with the EAP state machine defined in [EAP-SM] that we briefly recall here after: Bersani Expires û December 2004 [Page 29] INTERNET-DRAFT EAP-PSK June 2004 eapReqData (EAP packet) The contents of the available EAP request ignore (boolean) A flag indicating whether the method has decided to drop the current packet methodState (enumeration) The method state (INIT, CONT, MAY_CONT, DONE) decision (enumeration) The peer's decision regarding the success or not of the authentication (FAIL, COND_SUCC, UNCOND_SUCC) allowNotifications (boolean) A flag indicating whether the peer allows EAP to process EAP Notifications during the method's conversation. This flag is systematically set to FALSE by EAP-PSK (see 6.9). eapRespData (EAP Packet) The EAP packet which is the response to send. Please note that normally this variable is not considered as an interface with the method in [EAP-SM] but it is in our setting since we slightly modified the procedure m.process() defined in [EAP-SM] (see below). In addition to these interface variables, the EAP-PSK peer state machine uses the following long-term variables which are initialized by the peer before the first EAP-PSK dialog: PSK.AK (128 bit string) The AK portion of the PSK (see section 2.1.1) PSK.KDK (128 bit string) The KDK portion of the PSK (see section 2.1.1) PeerNAI (NAI) The NAI used by the peer as its identity (see section 2.2.1). This NAI is limited to 960 bytes (see section 4.4.2). Bersani Expires û December 2004 [Page 30] INTERNET-DRAFT EAP-PSK June 2004 ServerNAI (NAI) The NAI that the server to which the peer wants to authenticate uses as its identity (see section 2.2.1). This NAI is limited to 960 bytes (see section 4.4.2). In addition to these interface variables and its long term variables, the EAP-PSK peer state machine uses the following short-term variables which are specific to a particular EAP-PSK dialog: RandServer (128 bits string) The random number sent by the server (see section 2.2.1) RandPeer (128 bit string) The random number chosen by the peer (see section 2.2.1) IsKeyAvailable (Boolean) A flag that indicates whether keying material is made available by EAP-PSK for EAP (see section 6.3) TEK (128 bit string) The Transient EAP Key (see section 2.1.2) MSK (256 byte string) The Master Session Key (see section 2.1.3) EMSK (256 byte string) The Extended Master Session Key (see section 2.1.4) PChannelNonce (32 bit string) The next value the nonce in the protected channel must take (see section 2.2.2) PchannelSuccess (boolean) A flag indicating that the server has sent an AT_STATUS which Status field was set to DONE_SUCCESS. ExtChosen (8 bit string or NONE) The type of the extension that has been chosen (if any) for the conversation over the protected channel Bersani Expires û December 2004 [Page 31] INTERNET-DRAFT EAP-PSK June 2004 ExtUnkown(boolean) A flag indicating that an AT_EXT of a type that the peer was unable to process has been received (in which case it is set to TRUE) In addition to these variables, the EAP-PSK uses procedures. First, it uses the interface procedures with the EAP state machine defined in [EAP-SM] that we briefly recall here after. m.Check() Method procedure to test for the validity of a message. Please note that the actual procedure executed depends on the state of EAP-PSK. Namely, EAP-PSK uses four subprocedures within m.Check(): o m.Check_INIT() o m.Check_ID&MACSENT() o m.Check_PCHANNEL() o m.Check_SUCCFAIL. m.Check_INIT() is the instantiation of m.Check() while in the INIT state (see section 3.2.2). It returns FALSE iff the received EAP-PSK message is exactly comprised of an AT_RAND that complies with the format defined in section 4.4.5. Thus, m.Check_INIT() only performs a syntactic check. m.Check_ID&MACSENT()is the instantiation of m.Check() while in the ID&MACSENT state (see section 3.2.2). It returns FALSE iff o The received EAP-PSK message is exactly comprised of an AT_MAC and an AT_PCHANNEL that comply with the formats defined in sections 4.4.3 and 4.4.4 o And the value of the MAC field of AT_MAC is equal to the value the peer expects given the random number sent by the server and the one he has chosen (see section 2.2.1) o And the Nonce field of AT_PCHANNEL is equal to PChannelNonce and the Tag field of AT_PCHANNEL is equal to the value expected (see section 2.2.2) o And the decrypted payload of AT_PCHANNEL is syntactically and semantically correct. The decrypted payload of AT_PCHANNEL is said to be syntactically correct iff it is comprised o Either exactly of an AT_STATUS that complies with the format defined in section 4.4.6 o Or exactly of an AT_STATUS and an AT_EXT that comply with the formats defined in sections 4.4.6 and 4.4.1. Bersani Expires û December 2004 [Page 32] INTERNET-DRAFT EAP-PSK June 2004 The decrypted payload of AT_PCHANNEL is said to be semantically correct iff o The AT_EXT attribute (if any) is semantically correct, i.e.: o When ExtChosen==NONE, it only consists of an AT_STATUS o When ExtChosen!=NONE, it consists of an AT_STATUS and an AT_EXT which EXT_Type field is equal to ExtChosen o The AT_STATUS is semantically correct, i.e.: o The Status field can be set to CONT only if there is an AT_EXT included within the AT_PCHANNEL o When PchannelSuccess==TRUE, the Status field of AT_STATUS is equal to DONE_SUCCESS o When ExtUnknown is set to TRUE, the Status field of AT_STATUS is equal to DONE_SUCCESS or DONE_FAILURE Thus, m.Check_ID&MACSENT() performs: o A syntactic check on the whole message o A cryptographic check on AT_MAC o A cryptographic check on AT_PCHANNEL o And a syntactic and semantic check on the decrypted payload. It is RECOMMENDED that these checks be performed in the order in which they are specified here above and that no further checks be performed as soon as one has failed (see 6.3 for more discussion). Please note, that to perform the cryptographic checks on AT_PCHANNEL, m.Check_ID&MACSENT() needs to derive the TEK. Thus we mandate that m.Check_ID&MACSENT() also derive the MSK and the EMSK and assign these values to the appropriate variables (TEK, MSK and EMSK). m.Check_PCHANNEL()is the instantiation of m.Check() while in the PCHANNEL state (see section 3.2.2). It returns FALSE iff: o The received EAP-PSK message is exactly comprised of an AT_PCHANNEL that comply with the format defined in sections 4.4.4 o And which Nonce field is equal to PChannelNonce and which Tag field is equal to the value expected (see section 2.2.2) o And which decrypted payload is syntactically and semantically correct. Thus m.Check_PCHANNEL()performs: o A syntactic check on the whole message o A cryptographic check on AT_PCHANNEL o And a syntactic and semantic check on the decrypted payload. m.Check_SUCCFAIL()is the instantiation of m.Check() while in the FAILURE or SUCCESS states (see section 3.2.2). It always returns TRUE. Thus, it does not perform any checks, it is merely defined to ensure that no EAP-PSK packets be processed once the (EAP-PSK) FAILURE or SUCCESS states have been reached. Bersani Expires û December 2004 [Page 33] INTERNET-DRAFT EAP-PSK June 2004 Please, see sections 6.9 and 6.10 for some more discussion on the security of m.check(). m.process() Method procedure to parse and process a request for EAP-PSK. The input to m.process is eapReqData and its output is (methodState, decision, allowNotifications, eapRespData): please note here that we slightly modified the notations of [EAP-SM] and added eapRespData to the output of m.process (that is to say we collapsed m.process() and m.build() into a single procedure seeing no point in keeping them separate). Please also note that the actual procedure executed depends on the state of EAP-PSK. Namely, EAP-PSK uses two subprocedures within m.process(): o m.process_INIT() o And m.process_PCHANNEL() There are only tswo subprocedures for m.process() compared to the four subprocedures of m.Check because no EAP packet is sent in the ID&MACSENT, SUCCESS and FAILURE states. m.process_INIT() is the instantiation of m.process() while in the INIT state (see section 3.2.2). It takes eapReqData as input and outputs (CONT, FAIL, FALSE, eapRespData) where eapRespData is an EAP response packet of type EAP- PSK that consists in an AT_RAND which RAND field is equal to RandPeer, an AT_ID which Identity field is equal to PeerNAI and an AT_MAC which MAC value corresponds to the value specified in section 2.2.1. m.process_INIT() makes the following computations before outputting its result: o It stores the RAND field of the received AT_RAND in RandServer o It chooses at random a 128 bit number and stores it in RandPeer o It computes the MAC field of the AT_MAC it is going to send according to section 2.2.1 using PSK.AK, RandPeer, RandServer, PeerNAI and ServerNAI. m.process_PCHANNEL()is the instantiation of m.process() while in the PCHANNEL state (see section 3.2.2). It takes eapReqData as input and outputs (methodState, decision, FALSE, eapRespData) where eapRespData is an EAP response packet comprised of an AT_PCHANNEL that complies with the cryptographic and synctactic rules defined in sections 2.2.2 and 4.4.4 and which (decrypted) payload complies with the syntactic rules defined in sections 4.4.1 and 4.4.6 and which payload complies with the following semantic rules: o The extension is semantically correct, i.e. an AT_EXT is included iff ExtChosen!=NONE and in case, ExtChosen!=NONE, the EXT_Type field of this AT_EXT is equal to ExtChosen Bersani Expires û December 2004 [Page 34] INTERNET-DRAFT EAP-PSK June 2004 o The status is semantically correct, i.e. its Status field is in adequation with the decision output by m.process_PCHANNEL() (see below) To compute its decision, thee peer uses the Status field of the decrypted payload of the received AT_PCHANNEL as follows, depending on its policy: o If this Status field is equal to DONE_SUCCESS o It may take the decision UNCOND_SUCC and, in this case, chooses methodState to be DONE and sets its Status field to DONE_SUCCESS o It may take the decision to stay to its current FAIL decision because it needs more information to make a decision and, in this case, it chooses methodState to be CONT and sets its Status field to CONT o It may take the decision to irremediably fail and stay with its FAIL decision because it is sure it will not make it to SUCCESS, and, in this case, it chooses methodState to be DONE and sets its Status field to DONE_FAILURE o If this Status field is equal to DONE_FAILURE, it MUST take the decision FAIL, choose methodState to be DONE and set its Status field to DONE_FAILURE o If this Status field is equal to CONT o It may stay to the decision FAIL, choose methodState to be CONT and set its Status field to CONT o or it may stay to the decision FAIL, choose methodState to be DONE and set its Status field to DONE_FAILURE See section 6.9 for some discussion on these rules. m.process_PCHANNEL() makes the following computations before outputting its result: o If ExtChosen==NONE and there is no AT_EXT in the decrypted payload of the received AT_PCHANNEL o If the Status field of the received AT_STATUS is set to DONE_SUCCESS, the peer sets PChannelSuccess to TRUE and consults its policy to take either the decision UNCOND_SUCC or (irremediably) FAIL. In case, it takes the decision FAIL, it chooses methodState to be DONE and sets its Status field to DONE_FAILURE (i.e. it is not allowed to choose methodState to be CONT and set its Status field to CONT). In either cases, the peer increments PChannelNonce, encapsulates the corresponding AT_STATUS within an AT_PCHANNEL and sends an EAP-PSK packet containing this AT_PCHANNEL. o If the Status field of the received AT_STATUS is set to DONE_FAILURE, the peer must take the decision FAIL as explained above. The peer increments PChannelNonce, encapsulates the corresponding AT_STATUS within an AT_PCHANNEL and sends an EAP-PSK packet containing this AT_PCHANNEL. o If ExtChosen==NONE and there is an AT_EXT in the decrypted payload of the received AT_PCHANNEL Bersani Expires û December 2004 [Page 35] INTERNET-DRAFT EAP-PSK June 2004 o If the peer is not able to process an AT_EXT of this type, it sets ExtUnknown to TRUE and ExtChosen to the type of this received AT_EXT. If the Status field of the received AT_STATUS is set to DONE_SUCCESS, the peer sets PChannelSuccess to TRUE. It consults its policy to take its decision. It outputs the corresponding methodState and decision, increments PChannelNonce and sends an EAP-PSK packet containing an AT_PCHANNEL with the adequate AT_STATUS and the AT_EXT it has received with the flag U(nrecognized) armed (see section 4.4.1) o If the peer is able to process an AT_EXT of this type, it sets ExtChosen to the type of this received AT_EXT. If the Status field of the received AT_STATUS is set to DONE_SUCCESS, the peer sets PChannelSuccess to TRUE. It processes the AT_EXT and the received AT_STATUS. It consults its policy to take its decision. It outputs the corresponding methodState and decision, increments PChannelNonce and sends an EAP-PSK packet containing an AT_PCHANNEL with the adequate AT_STATUS and a response AT_EXT of type ExtChosen o If ExtChosen!=NONE o If ExtUnknown==TRUE, then the peer consults its policy to take its decision. If the Status field of the received AT_STATUS is set to DONE_SUCCESS, the peer sets PChannelSuccess to TRUE. It outputs the corresponding methodState and decision, increments PChannelNonce and sends an EAP-PSK packet containing an AT_PCHANNEL with the adequate AT_STATUS and the AT_EXT it has received with the flag U(nrecognized) armed (see section 4.4.1) o If ExtUnkown==FALSE, the peer processes the AT_EXT and the received AT_STATUS. If the Status field of the received AT_STATUS is set to DONE_SUCCESS, the peer sets PChannelSuccess to TRUE. It consults its policy to take its decision. It outputs the corresponding methodState and decision, increments PChannelNonce and sends an EAP-PSK packet containing an AT_PCHANNEL with the adequate AT_STATUS and a response AT_EXT of type ExtChosen m.isKeyAvailable() Method procedure to signal that keying material is available. Within EAP-PSK, we simply have m.isKeyAvailable()=isKeyAvailable. m.getKey() Method procedure to obtain key material for use by EAP or lower layers. Within EAP-PSK, we simply have m.isKeyAvailable()=MSK||EMSK Bersani Expires û December 2004 [Page 36] INTERNET-DRAFT EAP-PSK June 2004 3.2.2 Graphical representation Figure 13 below is the EAP-PSK peer state machine graphical representation. +------------+ | | +------->| SUCCESS | | | | | +------------+ | | +------------+ +------------+ +-----+------+ | | | | | |<-----+ --->| INIT |--->| ID&MACSENT |--->| PCHANNEL | | | | | | | |------+ +------------+ +------------+ +-----+------+ | | | +------------+ | | | +------->| FAILURE | | | +------------+ Figure 13: EAP-PSK Peer state machine graphical representation Please note that the SUCCESS and FAILURE states depicted in Figure 13 are specific to the EAP-PSK peer state machine: they must not be confused with the EAP state machine states that bear the same name in [EAP-SM]. 3.2.3 Table representation Figure 14 below is the EAP-PSK peer state machine graphical representation. Bersani Expires û December 2004 [Page 37] INTERNET-DRAFT EAP-PSK June 2004 -------------------------------+------------------------+------------ INIT | | | | IsKeyAvailable=FALSE; | | PChannelNonce=0; | | (methodState,decision, | | ID&MACSENT allowNotifications, | | eapRespData)= | | m.process_INIT(eapReqData) | | -------------------------------+------------------------+------------ ID&MACSENT | | | | | | PCHANNEL Hand over the decrypted | | payload | | and the EAP identifier | | -------------------------------+------------------------+------------ PCHANNEL | | | methodState==DONE && | SUCCESS (methodState,decision, | decision==UNCOND_SUCC | allowNotifications, | | eapRespData)= +------------------------+------------ m.process_PCHANNEL(eapReqData);| | PChannelNonce++ | methodState==DONE && | FAILURE | decision==FAIL | | | +------------------------+------------ | | | methodState==CONT && | PCHANNEL | decision==FAIL | -------------------------------+------------------------+------------ SUCCESS | | -------------------------------+------------------------+------------ FAILURE | | -------------------------------+------------------------+------------ Figure 14: EAP-PSK Peer state machine table representation For the sake of simplicity, we did not define formally the procedure "Hand over the decrypted payload and the EAP identifier" used in the ID&MACSENT state. Through this procedure, the decrypted payload is handed over to be acted upon by the PCHANNEL state (AT_STATUS and AT_EXT processing in case it is present) and the EAP Identifier is handed over so that the appropriate EAP response may be built in the PCHANNEL state (including the cryptographic protection of the EAP Identifier thanks to the Tag field of AT_PCHANNEL). 3.3 EAP-PSK server state machine Bersani Expires û December 2004 [Page 38] INTERNET-DRAFT EAP-PSK June 2004 3.3.1 Variables and Procedures The EAP-PSK server state machine uses the interface variables with the EAP state machine defined in [EAP-SM] that we briefly recall here after: eapReqData (EAP packet) The EAP packet to send (i.e. a request). eapRespData (EAP Packet) The EAP packet to be processed (i.e. a response). ignore (boolean) A flag indicating whether the method has decided to drop the current packet methodState (enumeration) The method state (CONTINUE, END) decision (enumeration) The server's decision regarding the success or not of the authentication (FAILURE or SUCCESS). Since EAP explicitly forbids using a sequence of authentication methods, we shall indeed not consider the decision CONTINUE that is proposed in [EAP-SM]. In addition to these interface variables, the EAP-PSK server state machine uses the following long-term variables which are initialized by the server before the first EAP-PSK dialog: PSK.AK (128 bit string) The AK portion of the PSK (see section 2.1.1) PSK.KDK (128 bit string) The KDK portion of the PSK (see section 2.1.1) ServerNAI (NAI) The NAI used by the server as its identity (see section 2.2.1). This NAI is limited to 960 bytes (see section 4.4.2). PeerNAI (NAI) Bersani Expires û December 2004 [Page 39] INTERNET-DRAFT EAP-PSK June 2004 The NAI of the peer used by the peer as its identity (see section 2.2.1). This NAI is limited to 960 bytes (see section 4.4.2). Please note that a server will typically have to authenticate multiple peers. Hence, it is up to the server to store appropriately the different long-term EAP-PSK variables corresponding to these different peers and to retrieve the relevant information when needed (thanks to the communicating peer's identity included in the first EAP-PSK message received from the peer, see section 2.3.1). In addition to these interface variables and its long term variables, the EAP-PSK peer state machine uses the following short-term variables which are specific to a particular EAP-PSK dialog: RandServer (128 bits string) The random number chosen by the server (see section 2.2.1) RandPeer (128 bit string) The random number sent by the peer (see section 2.2.1) TEK (128 bit string) The Transient EAP Key (see section 2.1.2) MSK (256 byte string) The Master Session Key (see section 2.1.3) EMSK (256 byte string) The Extended Master Session Key (see section 2.1.4) PChannelNonce (32 bit string) The next value the nonce in the protected channel must take (see section 2.2.2) PchannelStatus (enumeration) The last value sent by the server in the Status field of AT_STATUS (DONE_SUCCESS, DONE_FAILURE, CONT). ExtChosen (8 bit string or NONE) The type of the extension that the server will choose (if any) for the conversation over the protected channel Bersani Expires û December 2004 [Page 40] INTERNET-DRAFT EAP-PSK June 2004 ExtUnkown(boolean) A flag indicating that an AT_EXT of a type that the peer was unable to process has been received (in which case it is set to TRUE) isDone(boolean) A flag indicating that the method is done. In addition to these variables, the EAP-PSK uses procedures. First, it uses the interface procedures with the EAP state machine defined in [EAP-SM] that we briefly recall here after. m.Check() Method procedure to test for the validity of a message. Please note that the actual procedure executed depends on the state of EAP-PSK. Namely, EAP-PSK uses two subprocedures within m.Check(): o m.Check_RANDSENT() o m.Check_PCHANNEL() m.Check__RANDSENT() is the instantiation of m.Check() while in the RANDSENT state (see section 3.3.2). It returns FALSE iff o The received EAP-PSK message is exactly comprised of an AT_RAND, an AT_ID and an AT_MAC that comply with the format defined in section 4.4.5, 4.4.2 and 4.4.3. o And the value of the MAC field of the received AT_MAC is equal to the value the server expects given the random number it sent and the one the peer sent in the RAND field of AT_RAND (see section 2.2.1) Thus, m.Check__RANDSENT()performs o A syntactic check on the whole message o And a cryptographic check on AT_MAC m.Check_PCHANNEL() is the instantiation of m.Check() while in the PCHANNEL state (see section 3.3.2). It returns FALSE iff o The received EAP-PSK message is exactly comprised of an AT_PCHANNEL that complies with the formats defined in section 4.4.4 o And the Nonce field of AT_PCHANNEL is equal to PChannelNonce and the Tag field of AT_PCHANNEL is equal to the value expected (see section 2.2.2) o And the decrypted payload of AT_PCHANNEL is syntactically and semantically correct. Bersani Expires û December 2004 [Page 41] INTERNET-DRAFT EAP-PSK June 2004 The decrypted payload of AT_PCHANNEL is said to be syntactically correct iff it is comprised o Either exactly of an AT_STATUS that complies with the format defined in section 4.4.6 o Or exactly of an AT_STATUS and an AT_EXT that comply with the formats defined in sections 4.4.6 and 4.4.1. The decrypted payload of AT_PCHANNEL is said to be semantically correct iff o The AT_EXT attribute (if any) is semantically correct, i.e.: o When ExtChosen==NONE, it only consists of an AT_STATUS o When ExtChosen!=NONE, it consists of an AT_STATUS and an AT_EXT which EXT_Type field is equal to ExtChosen o When ExtUnknown==TRUE, the flage U(nrecongnized) of the received AT_EXT is armed o The AT_STATUS is semantically correct, i.e.: o The Status field may be set to CONT only if there is an AT_EXT included within the AT_PCHANNEL o The Status field of the received AT_STATUS may only be equal to DONE_SUCCESS when PchannelStatus==DONE_SUCCESS o The Status field of the received AT_STATUS MUST be equal to DONE_FAILURE when PchannelStatus==DONE_SUCCESS Thus, m.Check_PCHANNEL() performs: o A syntactic check on the whole message o A cryptographic check on AT_PCHANNEL o And a syntactic and semantic check on the decrypted payload. It is RECOMMENDED that these checks be performed in the order in which they are specified here above and that no further checks be performed as soon as one has failed (see 6.3 for more discussion). Please, see sections 6.9 and 6.10 for some more discussion on the security of m.check(). m.init() When the method is first started, it must initialize its own method- specific state. EAP-PSK initializes its state by choosing a 128 bit number at random and storing it in RandServer. m.process() Method procedure to parse and process a response for RAP-PSK. The input to m.process is eapResData and it has no output. Please note that the actual procedure executed depends on the state of EAP-PSK. Namely, EAP-PSK uses two subprocedures within m.process(): o m.process_RANDSENT() o And m.process_PCHANNEL() Bersani Expires û December 2004 [Page 42] INTERNET-DRAFT EAP-PSK June 2004 m.process_RANDSENT() is the instantiation of m.process() while in the RANDSENT state (see section 3.3.2). It takes eapResData as input and has no output. m.process_RANDSENT () makes the following computations before outputting its result: o It stores the RAND field of the received AT_RAND in RandPeer o It stores the identity field of AT_ID in PeerNAI and uses it to retrieve and properly instantiate the relevant PSK.AK, PSK.KDK and ServerNAI o It instantiates PChannelNonce to 0 o It consults its policy to instantiate ExtChosen (to NONE or a particular value) o It instantiates ExtUnknown to FALSE o It consults its policy to instantiate PChannelStatus o It instantiates the flag isDone to FALSE o It derives the TEK, MSK and EMSK and stores them in the appropriate variables m.process_PCHANNEL()is the instantiation of m.process() while in the PCHANNEL state (see section 3.2.2). It takes eapRespData as input and has no output. o If isKeyAvailable is set to FALSE, it sets it to TRUE. o If there is an AT_EXT encapsulated in the received AT_PCHANNEL that does not have the U flag armed, it hands it over for processing to the appropriate plugin together with the Status field of the received AT_STATUS. o If there is an AT_EXT encapsulated in the received AT_PCHANNEL that has the U flag armed, it sets ExtUnknown to TRUE o It sets isDone to TRUE iff the Status field of the received AT_STATUS is equal to DONE_SUCCESS or DONE_FAILURE. m.isKeyAvailable() Method procedure to signal that keying material is available. Within EAP-PSK, we simply have m.isKeyAvailable()=isKeyAvailable. m.getKey() Method procedure to obtain key material for use by EAP or lower layers. Within EAP-PSK, we simply have m.isKeyAvailable()=MSK||EMSK m.getTimeout() EAP-PSK can provide a hint for retransmission timeout. No specific hint is specified for EAP-PSK standard authentication. There is indeed no need to do so because EAP-PSK standard authentication does not require user interaction. However, in case extended Bersani Expires û December 2004 [Page 43] INTERNET-DRAFT EAP-PSK June 2004 authentication is used, it may become useful to specify such a hint depending on the EXT_Type (see sections 2.3.2 and 4.4.1). m.buildReq() Method procedure to build a request packet. Please note that the actual procedure executed depends on the state of EAP-PSK. Namely, EAP-PSK uses two subprocedures within m.buildReq(): o m.buildReq_INIT() o m.buildReq.RANDSENT() o And m.buildReq_PCHANNEL() m.buildReq_INIT() is the instantiation of m.buildReq() while in the INIT state (see section 3.3.2). Basically, it send an EAP-PSK request that merely consists in an AT_RAND (which RAND field contains the random number stored in RandServer). m.buildReq_RANDSENT() is the instantiation of m.buildReq() while in the RANDSENT state (see section 3.3.2). It sends an EAP-PSK request that consists in an AT_MAC calculated as specified in section 2.2.1 and an AT_PCHANNEL calculated as specified in section 2.2.2. The payload of AT_PCHANNEL depends on the server's policy: If ExtChosen==NONE, the payload only consists in an AT_STATUS which Status field may take the value DONE_SUCCESS or DONE_FAILURE depending on the server's policy. If ExtChosen!=NONE, the payload contains an AT_STATUS and an AT_EXT of EXT_Type ExtChosen. The Status field of AT_STATUS may take the value CONT, DONE_SUCCESS or DONE_FAILURE depending on the server's policy. After sending the AT_PCHANNEL, m.buildReq_RANDSENT() increments PChannelNonce and possibly updates PChannelStatus. m.buildReq_PCHANNEL() is the instantiation of m.buildReq() while in the PCHANNEL state (see section 3.3.2). It sends an EAP-PSK request that consists in an AT_PCHANNEL calculated as specified in section 2.2.2. If the server sends a packet in this state, this means that ExtChosen!=NONE. Hence, the payload of AT_PCHANNEL consists in an AT_STATUS and an AT_EXT. If ExtUnkown==TRUE, then the server sends an AT_EXT of type ExtChosen with no payload (this was specified for it is believed to simplify implementations) and an AT_STATUS which Status field may take the value DONE_SUCCESS or DONE_FAILURE depending on the server's policy. If ExtUnknown==FALSE, then the server sends an AT_EXT of type ExtChosen (which payload is given by the extension plugin) and an Bersani Expires û December 2004 [Page 44] INTERNET-DRAFT EAP-PSK June 2004 AT_STATUS which Status field may take the value CONT, DONE_SUCCESS or DONE_FAILURE depending on the server's policy. After sending the AT_PCHANNEL, m.buildReq_RANDSENT() increments PChannelNonce and possibly updates PChannelStatus. 3.3.2 Graphical representation Figure 15 below is the EAP-PSK server state machine graphical representation. +------------+ +------------+ +------------+ | | | | | |<-----+ --->| INIT |--->| RANDSENT |--->| PCHANNEL | | | | | | | |------+ +------------+ +------------+ +------------+ Figure 15: EAP-PSK Server state machine graphical representation 3.3.3 Table representation Figure 16 below is the EAP-PSK peer state machine graphical representation. -------------------------------+------------------------+------------ INIT | | | | m.init() | | RANDSENT -------------------------------+------------------------+------------ RANDSENT | | | | m.process_RANDSENT | | PCHANNEL -------------------------------+------------------------+------------ PCHANNEL | | | | m.process_PCHANNEL | | PCHANNEL -------------------------------+------------------------+------------ Figure 16: EAP-PSK Server state machine table representation This table representation is pretty straightforward as all the procedures are concentrated in m.Check(), m.process and m.buildReq(). 4. EAP-PSK message format 4.1 General format of an EAP-PSK message An EAP-PSK message is merely a concatenation of EAP-PSK attributes. Bersani Expires û December 2004 [Page 45] INTERNET-DRAFT EAP-PSK June 2004 The order in which these attributes are concatenated has no importance whatsoever. When encapsulated in EAP, an EAP-PSK message has the following format, depicted in Figure 17 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | AT_1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : | AT_n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: Generic format of an EAP packet of Type EAP-PSK In Figure 17,: o Code is an EAP field that can be 1 (Request) or 2 (Response) o Identifier is a one byte EAP field that helps match the requests and the responses o Length is the total length of the EAP packet in bytes o Type is the type number to be defined allocated to EAP-PSK (see section 5.1). o AT_1, ...., AT_n is a concatenation of EAP-PSK attributes 4.2 Generic format of an EAP-PSK attribute Figure 18 below depicts the generic format of an EAP-PSK attribute. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_EXAMPLE | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: Generic format of an EAP-PSK attribute An EAP-PSK attribute always start with a one byte field called the EAP-PSK Type field of the attribute. When it is clear from context (i.e. there can be no confusion with the EAP Type field, see section 4.1), this field is simply called the Type field. The EAP-PSK Type field of the attribute is generally followed by a length field that indicates the total length of the attribute (including its header) in multiple of 32 bit words (thus payloads that are not necessarily aligned on 32 bit boundaries provide a Bersani Expires û December 2004 [Page 46] INTERNET-DRAFT EAP-PSK June 2004 padding scheme - see for instance section 4.4.2)and a Reserved field, which is set to zero when sending and ignored on reception. 4.3 Table of the Type field of the different attributes The table below presents the value of the EAP-PSK Type field of the different EAP-PSK attributes Attribute Name Type Field Value AT_EXT 1 AT_ID 2 AT_RAND 3 AT_MAC 4 AT_PCHANNEL 5 AT_STATUS 6 4.4 Format of the different EAP-PSK attributes This section presents the respective formats of the different attributes listed in alphabetical order. 4.4.1 AT_EXT The AT_EXT attribute is used to allow implementation of extensions to EAP-PSK. The format of the AT_EXT attribute is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_EXT | Length _| EXT_Type |U| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : EXT_Payload : : . : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The use of the AT_EXT is defined in section 2.2.2 and 3. The EXT_Type is a one byte field that indicates the type of the AT_EXT payload. This type number is allocated by IANA (see section 5.2) The flag U (like Unrecognized) is used to indicate that the EXT_Type was not recognized. It is set to 1 when this is the case. This flag may only be set by the peer. Bersani Expires û December 2004 [Page 47] INTERNET-DRAFT EAP-PSK June 2004 The EXT_Payload depends on the EXT_Type. 4.4.2 AT_ID The AT_ID attribute is used by the peer to state its identity. The format of the AT_ID attribute is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_ID | Length | Actual Identity Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Identity : : . : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The use of the AT_ID is defined in Section 2.3.1 and 3. The value field of this attribute begins with the 2-byte actual identity length, which specifies the length of the identity in bytes. This field is followed by the subscriber identity of the indicated actual length. The identity does not include any terminating null characters. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the identity with zero bytes when necessary. To avoid fragmentation issues, the length of the Identity field has been bounded to 960 bytes (i.e. two hundred and forty 32 bit words), which should be enough for most identities. 4.4.3 AT_MAC The AT_MAC attribute is used for authentication within EAP-PSK. The format of the AT_MAC attribute is shown below. Bersani Expires û December 2004 [Page 48] INTERNET-DRAFT EAP-PSK June 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MAC | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MAC field is a 16 byte field used to transport a 128 bit keyed message authentication code. This MAC is calculated over message-specific data. The contents of the message-specific data that are MACed are specified separately for each EAP/PSK message in Section 2.2.1. 4.4.4 AT_PCHANNEL The AT_PCHANNEL attribute is used to transmit information between the peer and server over a protected channel, that is to say a channel that provides confidentiality, data origin authentication and replay protection. The intention is quite similar to [PEAP-TLV]. The format of the AT_PCHANNEL attribute is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_PCHANNEL | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | |---------------------------------------------------------------| | | | Tag | | | | | |---------------------------------------------------------------| | | | Payload | : : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Nonce field is a four byte field used to convey the nonce for the protected channel that is specified in section 2.2.2. Bersani Expires û December 2004 [Page 49] INTERNET-DRAFT EAP-PSK June 2004 The Tag field is 128 bit long and is used to transport a 128 bit keyed message authentication code. It is calculated as specified in 2.2.2. The payload consists in the variable length cipher text resulting from the encryption in the EAX mode of operation of the information that the peer and the server wish to exchange over the protected channel under Nonce and the derived TEK (see Section 2.2.2). The information that the peer and the server may exchange over the protected channel consists either of an AT_STATUS or an AT_STATUS concatenated with an AT_EXT. The use of AT_PCHANNEL is defined in section 2.2.2. 4.4.5 AT_RAND The AT_RAND attribute is used to transport 128 bit random numbers that are used as challenges for authentication (see section 2.2.1). The format of the AT_RAND attribute is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_RAND | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | RAND | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 16 byte RAND field is used to transport a random number freshly generated either by the peer or the server for the EAP-PSK authentication exchange. The random number sent by the server is also used as a seed value for the derivation of keying material. The use of AT_RAND is defined in sections 2.2.1 and 2.3.1. 4.4.6 AT_STATUS The AT_STATUS attribute is used by the peer and the server to exchange protected result indications of success or failure for the EAP-PSK dialog. The format of the AT_STATUS attribute is shown below. Bersani Expires û December 2004 [Page 50] INTERNET-DRAFT EAP-PSK June 2004 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_STATUS | Length | S | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There MUST be exactly one AT_STATUS encapsulated in each AT_PCHANNEL. The two bit S field is called the Status field. It is set to: o 01 if the current status is CONT o 10 if the current status is DONE_SUCCESS o 11 if the current status is DONE_FAILURE The use of AT_STATUS is defined in sections 3.2.3 and 3.3.3. 5. IANA considerations This document introduces two new Internet Assigned Numbers Authority (IANA) considerations. This section provides guidance to the IANA regarding registration of values related to the EAP-PSK protocol, in accordance with BCP 26, [RFC 2434]. The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration". The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action". There are one name space in EAP-PSK that require registration: the EXT_Type field values of AT_EXT (see section 4.4.1). EAP-PSK is not intended as a general-purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization and accounting. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published. The Designated expert will post a request to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will Bersani Expires û December 2004 [Page 51] INTERNET-DRAFT EAP-PSK June 2004 either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable. 5.1 Allocation of an EAP-Request/Response Type for EAP-PSK This document requires IANA to allocate a new EAP Type for EAP-PSK. It is not clear yet whether this request will follow the standards track allocation process for method types (type numbers 192-253 ) or the "informational" one (type numbers 46-191), see [EAP] for more details. 5.2 Allocation of EXT_Type numbers EXT_Type has a range from 0 to 255. EXT_Type 255 has been allocated for Experimental use. EXT_Type 0-254 may be allocated on the advice of a Designated Expert, with Specification Required 6. Security considerations [EAP] highlights several attacks that are possible against the EAP protocol as there is no inherent security mechanisms provided. This section discusses the claimed security properties of EAP-PSK as well as vulnerabilities and security recommendations. 6.1 Identity protection Since the choice was made to restrict to a single cryptographic primitive from symmetric cryptography, namely the block cipher AES- 128, it appears that it is not possible to provide "reasonable" identity protection without failing to meet the simplicity goal. We provide hereafter an informal discussion of what is meant by identity protection and the rationale behind the requirement of identity protection. For some complementary discussion, please refer to [SIGMA]. Identity protection basically means preventing the disclosure of the identities of the communicating over the network... which is quite contradictory with authentication. There are two levels of identity protection: protection against passive attackers and protection against active eavesdropper. Bersani Expires û December 2004 [Page 52] INTERNET-DRAFT EAP-PSK June 2004 As explained in [SIGMA], "a common example [for identity protection] is the case of mobile devices wishing to prevent an attacker from correlating their (changing) location with the logical identity of the device (or user)". In case only symmetric cryptography is used, only a weak form of identity protection may be offered, namely pseudonym management. In other words, the peer and the server agree on pseudonyms that they use to identify each other and usually change periodically (possibly in a protected way so that an attacker cannot learn the new pseudonym before it is used). The problem with pseudonym management is that there is a tradeoff between allowing for pseudonym resynchronization (thanks to a permanent identity) and being vulnerable to active attacks (in which the attacker forges messages simulating a pseudonym desynchronization). Indeed, a protocol using (changing) pseudonyms may want to anticipate "desyncrhonization" situations such as for instance when the peer believes that the current pseudonym it has to use is "pseudo1@bigco.com" whereas the server believes the peer has to use the pseudonym "pseudo2@bigco.com" which updated "pseudo1@bigco.com". Because pseudonym management adds complexity to the protocol and implies this unsatisfactory tradeoff, it was decided not to include this feature in EAP-PSK. However, EAP-PSK may provide protection against the two main attacks that account, in our opinion, for the identity protection requirement placed on EAP methods. The first attack is an active probing attack, i.e. the attacker probes a device in order to learn its logical identity. This attack does not apply to EAP-PSK since it is the initiator of the EAP-PSK conversation that has to disclose and prove its identity first - in fact, the server never discloses its identity (following an assumption discussed in section 1.1). The second attack is passive and aims at learning valuable information on the peer. For instance, let us take the example of user John Doe that roams and connects to a Hot-Spot owned and operated by Wireless Internet Service Provider (WISP) BAD. Suppose this user authenticates to his home WISP (WISP GOOD) with an EAP method under an identity (e.g. "john.doe@wispgood.com") that allows WISP BAD (or an attacker) to recover his "real-life" identity, i.e. John Doe. An example drawback of this, is that a competitor of John Doe's WISP may want to win John Bersani Expires û December 2004 [Page 53] INTERNET-DRAFT EAP-PSK June 2004 Doe as a new customer by sending him some special targeted advertisement. EAP-PSK can very simply thwart this attack, merely by avoiding to provide John Doe with a NAI that allows easy recovery of his real- life identity. We believe that when a NAI decorrelated to a real-life identity is used, no other valuable information leaks because of the EAP method. Indeed, the identity of the WISP used by a peer has to be disclosed anyway in the realm portion of its NAI to allow AAA routing and the Medium Access Control Address of the peer can generally be used to track the peer as efficiently as a fixed NAI. 6.2 Mutual authentication EAP-PSK provides mutual authentication. The server believes the peer is authentic because it can calculate a valid MAC and the peer believes that the server is authentic because it also can calculate a valid MAC. The authentication protocol used in EAP-PSK, AKEP2, enjoys a security proof in the provable security paradigm, see [EAKD]. The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK, OMAC1, also enjoys a security proof in the provable security paradigm, see [OMAC]. The underlying block cipher used, AES-128, is widely believed to be a secure block cipher. Finally, the key used for mutual authentication, AK, is only used for that purpose, making thus this part cryptographically independent of the other parts. 6.3 Key derivation EAP-PSK supports key derivation. The key hierarchy is specified in Section 2.1. The mechanism used for key derivation is the modified counter mode. The instantiation of the modified counter in EAP-PSK (i.e. the selected ri and ci) complies with the conditions stated in [SOBMMO] so that the security proof in the provable security paradigm of [SOBMMO] holds. The underlying block cipher used, AES-128, is widely believed to be a secure block cipher. Bersani Expires û December 2004 [Page 54] INTERNET-DRAFT EAP-PSK June 2004 The key derivation mechanism uses a dedicated key, the KDK. The input block to the key derivation is taken to be RB as specified in AKEP2. It should be emphasized that the server has control of the session keys derived by EAP-PSK. In particular, it can easily choose RB so that one of the 9 derived 128 bit key blocks (see section 2.2.1) takes a pre-specified value. It was chosen not to prevent this server control of the session keys because: o Preventing it would have added some complexity to the protocol (typically inclusion of a one-way mode of operation of AES in the key derivation part) o We believe that the server may reasonably be assumed to be honest (e.g. it won't try to force the peer to use some pre- specified value for the session keys) and more "secure" than the peer (e.g. it will use a good source of randomness for RB) This key control by the server is however not the behavior recommended by EAP in section 7.10 "A RECOMMENDED method is for each party to provide a nonce of at least 128 bits, used in the derivation of the MSK and EMSK" Since deriving the keys requires some cryptographic computations, it is RECOMMENDED that the keys be derived only if authentication has succeeded (i.e. the server verifies that the AT_MAC sent by the peer is valid and only then does he derive the keys and similarly, the peer verifies that the AT_MAC sent by the server is valid and only then derive the keys - see sections 3.2.1 and 3.3.1). It is RECOMMENDED to take great care in implementations so that derived keys are not made available if the EAP-PSK dialog fails (i.e. ends with DONE_FAILURE or a time out). The derived keys are made available to the other layers/applications only if a flag (isKeyAvailable is set to TRUE). In case, this flag is not set to TRUE, the derived keys MUST NOT be made available, although they may have been derived. The TEK MUST NOT be made available to anyone except to the current EAP-PSK dialog. 6.4 Dictionary attacks Because EAP-PSK is not a password protocol, it is not vulnerable to dictionary attacks. Let us indeed remind that the PSK used by EAP-PSK MUST NOT be derived from a password. Derivation of the PSK from a password may lead to dictionary attacks. However using a 256 bit pre-shared key has: Bersani Expires û December 2004 [Page 55] INTERNET-DRAFT EAP-PSK June 2004 o Ergonomic impacts: it may be considered cumbersome to have to provision 256 bit credentials o Deployment impacts: it may be wanted to reuse existing credential databases that contain passwords and not PSKs Since despite the warning not to use passwords, people will probably do that anyway, we offer four alleys to mitigate the risk associated with such a behavior: o Annex A provides guidance on the minimal operations to do when one still wants to derive the PSK from a password. This should complicate dictionary attacks - but by no way make them impossible! o Annex B suggests a complementary key derivation scheme that allows EAP-PSK to be provisioned with a single 128 bit secret which is then expanded into a 256 bit PSK - this should improve the ergonomics by dividing the credential length by two o AT_EXT can be used to provision a stronger PSK after a successful authentication occurred with a password based PSK - this can be used to reduce the vulnerability window to one EAP- PSK exchange when a password is used We also remind that it is not a fatality that password be used instead of PSKs: people rarely use password derived certificates, so why should they do so for shared keys? Last, we note that AKEP2 makes dictionary attacks harder, since the first value that is MACed is not predictable neither by the peer nor the server or anybody else: precomputing a dictionary adapted to EAP- PSK even in case of an active attack seems thus at least very difficult. 6.5 Protected channel EAP-PSK provides a protected channel over which the peer and the server can securely exchange information, in case of a successful authentication. This protected channel provides confidentiality, data origin authentication, replay protection and confirmation of the end of the conversation. As soon as AT_PCHANNEL is included in an EAP packet, the whole EAP packet is integrity protected. 6.6 Negotiation attacks EAP-PSK does not protect from negotiation attacks since it currently does not provide version or cipher suite negotiation. Bersani Expires û December 2004 [Page 56] INTERNET-DRAFT EAP-PSK June 2004 6.7 Man-in-the-middle attacks Due to the use of symmetric cryptography and the security proofs of its cryptographic components, EAP-PSK is believed not to be vulnerable to man-in-the-middle attacks. There are "man-in-the-middle" attacks associated with the use of any EAP method within a tunneled protocol such as PEAP, or within a sequence of EAP methods followed by each other (see [MTAP]). This specification does not address these attacks. The effectiveness of such attacks and the solutions that should be adopted is still controversial in our opinion (see [IETF 55] and [IETF 59] for some discussions on this issue). 6.8 Random numbers generation An EAP-PSK implementation SHOULD use a good source of randomness to generate the random numbers required in the protocol. Please see [RFC 1750] for more information on generating random numbers for security applications. 6.9 Denial of Service resistance Denial of Service resistance (DoS) resistance has not been a design goal for EAP-PSK. We however believe that EAP-PSK does not provide any obvious and avoidable venue for such attacks. EAP-PSK does not allow EAP notifications to prevent potential DoS attacks.. Indeed, since EAP Notifications are not integrity protected, they can easily be spoofed by an attacker. Such an attacker could force a peer that allows Notifications to engage in a discussion which would delay his authentication or result in the peer taking unexpected actions (e.g. in case the Notification is used to prompt the peer to do a "bad" action. According to this specification, it would be possible for an attacker to make a number of tentative forgeries limited only by time outs. Indeed, the m.check() procedures (see sections 3.2.1 and 3.3.1) does not currently specify whether an error is fatal or not. An error is fatal, if after it, no verifications are done any more: the party transitions to failure without further examining any new packet. Since this does not affect interoperability, it is up to the implementor or the user to specify for instance the maximum number of failed checks authorized in a particular state. There is a trade off between possibly allowing multiple tentative forgeries and allowing a direct DoS (in case the first error is fatal). Bersani Expires û December 2004 [Page 57] INTERNET-DRAFT EAP-PSK June 2004 It is also not clear from [EAP-SM] how to transition quickly to the EAP SUCCESS or FAILURE state. One could use the variables altAccept and altReject but in the current version of [EAP-SM], these variables are specified as interface between the lower layer and the EAP peer state machine and not between the EAP peer state machine and the EAP- PSK peer state machine. As a result, depending on EAP implementations there might not be a better way to transition to EAP SUCCESS or FAILURE state than to wait for a time out to occur. This behavior might result in annoying delays. Last, the Status field of the AT_STATUS has been specified so that the peer and the server may share information on their respective state in a protected way. The peer is not authorized to make a transition to DONE_SUCCESS before the server has made its own transition to DONE_SUCCESS. When one party transitions to DONE_FAILURE, both parties are expected to fail. The cryptographic protection of these result indications does not prevent message deletion. For instance, a server sends DONE_SUCCESS to a peer that upon reception also sends DONE_SUCCESS. In case this last message from the peer is intercepted, and an EAP Success is sent to the peer before any retransmission from the server reaches it or the retransmissions from the server are also deleted, the peer will believe that it has successfully authenticated to the server while the server will fail. This behavior is well known (see [CK]) and in a sense unavoidable. There is a trade off between efficiency and the "level" of information sharing that is attainable. EAP-PSK chose the more efficient solution (i.e. a round trip of DONE_SUCCESS suffice) because, it is believed that: o In case there is an adversary capable of disrupting the communication channel, it can do so whenever it wants (be it after one or 10 round trip or even during data communication) o Other layers/applications will generally start by doing a specific key exchange and confirmation procedure using the keys derived by EAP-PSK. This is typically done by IEEE 802.11i "four-way handshake". In case the error is not detected by EAP- PSK, it should be detected then (please note that it is however generally not a good idea to rely on external mechanism to ensure security properties). 6.10 Implementation of EAP-PSK This section is to remind that the security provided by EAP-PSK depends on its implementation and that implementation of cryptographic algorithms require special skills since cryptographic software is not only vulnerable to classical attacks (e.g. buffer overflow or missing checks) but also to some special cryptographic attacks (e.g. side channels attacks like timing ones, see for instance [TIM]). Hence, care must be taken in EAP-PSK implementation to avoid such attacks, please refer to [EAX] for some discussion. Bersani Expires û December 2004 [Page 58] INTERNET-DRAFT EAP-PSK June 2004 Please also not that the quality of the checks performed by the m.check() procedures (see sections 3.2.1 and 3.3.1)is of vital importance. For instance, when checking the syntactic correctness of AT_ID (see section 4.4.2), not only should o The Type field be checked, namely that it is equal to 2 o The Length field be checked, namely that it is not bigger than the EAP-PSK packet minus the length of the other attributes it contains and that is not bigger than 241 but also o The Actual Identity Length field, namely that it is not bigger than the length specified in the length field minus 1 (for the 32 bit header of AT_ID) o The Identity field, namely that it complies with [NAI] 6.11 Exposition of the PSK This is to remind some issues related to the use of a PSK and AES-128 as the only cryptographic primitive. First, EAP-PSK does not provide perfect forward secrecy. Compromise of the PSK leads to compromise of recorded past sessions. Second, Compromise of the PSK enable the attacker to impersonate the peer of the server: compromise of the PSK leads to "full" compromise of future sessions. Last, usage of a PSK that is only 256 bit long and thus that a human user can "read" or remember - compared say the "long" 1024 or 2048 bit RSA keys, often leads to selecting poor repositories for the PSK (such as a plaintext file). From this, it generally follows that a user has full access to the PSK: he can read it and share it with anybody. Again, this has nothing to do with the nature of the PSK and appropriate protection (such as storage on a tamper resistant device) can be provided as well for PSKs as for certificates (which is very often the case). 6.12 Channel binding This feature is not provided in EAP-PSK as it still very much work in progress (please refer to [CBIND]). However, it should be easy to add to EAP-PSK thanks to the EAP-PSK extensible design (namely AT_EXT, see section 2.3.2) 6.13 Fragmentation As explained in section 2.6, EAP-PSK does not provide fragmentation and leave it to the AT_EXT to implement the fragmentation mechanisms. Bersani Expires û December 2004 [Page 59] INTERNET-DRAFT EAP-PSK June 2004 Care must be taken while implementing fragmentation within AT_EXT since fragmentation has some serious security implications, that we briefly discuss here after. Fragmentation may lead to disruption of the protected result indication mechanism. To mitigate this risk, the extension plugin should check that all the Status field received in the AT_STATUS that accompany the AT_EXT that contain fragments of the same series are the same. Similarly, while acknowledging AT_EXT that contain fragments of the same series, the same Status field MUST be used in all AT_STATUS - except if a party wishes to fail before reassembly and sends a DONE_FAILURE. Fragmentation may lead to implementation issues (e.g. buffer overflow). It is RECOMMENDED that the fragmentation mechanism provide the total length of the fragmented message in the first fragment. Fragmentation could lead to well-known DoS attacks (see for instance [FRAG]) were it not implemented within the protected channel. Hence, the main threat against fragmentation arises when one of the communicating party behaves "badly", which should not occur and is not in the scope of the threat model. 7. Security claims This section provides the security claims required by [EAP]. [a] Mechanism. EAP-PSK is based on symmetric cryptography (AES-128) and uses a 256 bit Pre-shared Key [b] Security claims. The security properties of the method are discussed in Section 6. EAP-PSK provides: o Mutual authentication (see section 6.2) o Integrity protection (see section 6.5) o Replay protection (see sections 6.2 and 6.5) o Key derivation (see section 6.3) o Dictionary attack resistance (see section 6.4) o Session independence (see section 6.3) [c] Key strength. EAP-PSK mutually authenticates the parties with a 128 bit effective key strength and supports key derivation with 128- bit effective key strength. [d] Description of key hierarchy. Please see Section 2.1. [e] Indication of vulnerabilities. Vulnerabilities are discussed in Section 6. EAP-PSK does not provide: Bersani Expires û December 2004 [Page 60] INTERNET-DRAFT EAP-PSK June 2004 o Identity protection (see section 6.1) o Confidentiality. Although EAP-PSK provides confidentiality in its protected channel (see section 6.5), it cannot claim to do so as per [EAP] "A method making this claim MUST support identity protection" o Fast reconnect (see section 2.5) o Fragmentation (see section 2.6) o Cryptographic binding (see section 6.7) o Protected cipher suite negotiation (see section 6.6) o Perfect Forward Secrecy (see section 6.3) o Key agreement: the session key is chosen by the server (see section 6.3) o Channel binding (see section 6.12) 8. Intellectual Property Right Notice The author neither has, nor is of aware of, any patents or pending patents relevant to material included in this draft. 9. Acknowledgements This EAP method has been inspired by [EAP-SIM] and [EAP-Archie]. It also considerably reused extracts of these documents. Many thanks to their respective authors and especially: Jesse Walker, Russ Housley Henry Haverinen and Joseph Salowey. It also benefited from exchanges with other EAP methods designers: many thanks to Hannes Tschofenig (EAP-IKEv2) and Nancy Cam-Winget (EAP-FAST). Many thanks to Aurelien Magniez for his help in the first implementation of EAP-PSK under Microsoft Windows and Freeradius and the very valuable feedback he provided, Henri Gilbert for some interesting discussions on the cryptographic parts of EAP-PSK, Thomas Otto for the inchoate working relationship and the implementation of the first version of EAP-PSK under Xsupplicant, Anne-Sophie Dusserre for pointers to EAP client and server implementations, and Laurent Butti. Finally, thanks to Jari Arkko and Bernard Aboba the beloved EAP WG chairs for the work they stimulate! 10. References 10.1 Normative [AES] Federal Information Processing Standards (FIPS) Publication 197, " Specification for the Advanced Encryption Standard (AES)", National Institute of Bersani Expires û December 2004 [Page 61] INTERNET-DRAFT EAP-PSK June 2004 Standards and Technology, November 26, 2001 [EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 3748, May 2004 [EAKD] Bellare, M and P. Rogaway, "Entity Authentication and Key Distribution", CRYPTO 93, LNCS 773, pp232-249, Springer-Verlag, Berlin, 1994 [EAX] Bellare, M. et al., "The EAX mode of operation", FSE 2004, LNCS 3017, Springer-Verlag, Berlin, 2004 [EKMF] Aboba, B. et al., "EAP Key Management Framework", Internet-Draft (work in progress), October 2003, draft-ietf-eap-keying-01.txt [NAI] Aboba, B. and Beadles M., "The Network Access Identifier", RFC 2486, January 1999 [OMAC] Iwata, T. and Kurosawa., K., ôOMAC: One-Key CBC MACö Fast Software Encryption, FSE 2003, LNCS 2887, pp129-153, Springer-Verlag, Berlin, 2003 [RFC 2219] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC 2434] Narten, T. and Alvestrand, H. "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998 [SOBMMO] Gilbert, H., ôThe Security of One-Block-to-Many Modes of Operationö, Fast Software Encryption, FSE 2003, LNCS 2287, pp376-395, Springer-Verlag 10.2 Informative [AH] Kent, S. and Atkinson, R., "IP Authentication Header", RFC 2402, November 1998 [AKESD] Bellare, M. et al., "Authenticated Key Exchange Secure Against Dictionary attacks", EUROCRYPT 2000, LNCS 1807, pp139-155, Springer-Verlag, Berlin, 2000 [CBIND] Arkko, J. and Eronen, P., "Authenticated Service Identities for the Extensible Authentication Protocol", Internet-Draft (work in progress), April 2004, draft-arkko-eap-service-identity-auth-00.txt Bersani Expires û December 2004 [Page 62] INTERNET-DRAFT EAP-PSK June 2004 [CK] Halpern, J. and Moses, Y., "Knowledge and common knowledge in a distributed environment", Journal of the ACM 37:3, 1990 [EAP-AKA] Arkko, J. and Haverinen, H., ôEAP AKA Authenticationö, Internet-Draft (work in progress), April 2004, draft-arkko-pppext-eap-aka-12.txt [EAP-Archie] Walker, J. and Housley, R., ôThe EAP Archie Protocolö, Internet-Draft (work in progress), June 2003, draft-jwalker-eap-archie-01.txt [EAP-SecurID] Josefsson, S., ôThe EAP SecurID(r) Mechanismö, Internet-Draft (work in progress), February 2002, draft-josefsson-eap-securid-01.txt [EAP-SIM] Haverinen, H. and Salowey, J., "EAP SIM Authentication", Internet-Draft (work in progress),April 2004, draft-haverinen-pppext-eap-sim-13.txt [EAP-SM] Vollbrecht, J. et al., "State Machines for EAP Peer and Authenticator", Internet-Draft (work in progress), October 2003, draft-ietf-eap-statemachine-01.txt [EAP-SRP] Carlson, J. et al., ôEAP SRP-SHA1 Authentication Protocolô, Internet-Draft (work in progress), July 2001, draft-ietf-pppext-eap-srp-03.txt [EAP-TLV] Hiller, T. et al., "A Container Type for the Extensible Authentication Protocol (EAP)", Internet-Draft (work in progress), May 2003, draft-hiller-eap-tlv-01.txt [FRAG] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. [HAC] Menezes, A. et al., ôHandbook of Applied Cryptographyö, CRC Press, 1996. [IEEE802.1X] Institute of Electrical and Electronics Engineers, "Standards for Local and Metropolitan Area Networks: Port Based Access Control", IEEE STD 802.1X, 2001 [IEEE802.11] Institute of Electrical and Electronics Engineers, "Information Technology - Telecommunications and Information Exchange between Systems - Local and Bersani Expires û December 2004 [Page 63] INTERNET-DRAFT EAP-PSK June 2004 Metropolitan Area Network - Specific Requirements û Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE STD 802.11, 1999 [IEEE802.11i] Institute of Electrical and Electronics Engineers, "Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Network - Specific Requirements û Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE STD 802.11i, June 2004 [IEEE802REQ] Stanley, Dorothy et al., ôEAP Method Requirements for Wireless LANsö, Internet-Draft (work in progress), May 2004, draft-walker-ieee802-req-01.txt [IETF 55] Proceeding of IETF 55, Internet Area, EAP WG, http://www.ietf.org/proceedings/02nov/136.htm [IETF 59] Proceeding of IETF 55, Internet Area, EAP WG, http://www.ietf.org/proceedings/04mar/138.htm [KSIZE] National Institute of Standards and Technology, "Special Publication 800-57 Recommendation for Key Management Part 1: General Guideline", Draft, January 2003, http://csrc.nist.gov/CryptoToolkit/kms/ guideline-1-Jan03.pdf [LEAP] Macnally, C., ôCisco LEAP protocol descriptionö, September 2001 [LEAPVUL] Wright, J., ôWeaknesses in LEAP Challenge/Responseö, Defcon 2003 [MOSKBC] National Institute of Standards and Technology, "Modes of operation for symmetric key block ciphers", http://www.csrc.nist.gov/CryptoToolkit/modes/ [MTAP] Asokan, N. et al., ôMan-in-the-middle in Tunnelled Authentication Protocolsö, http://eprint.iacr.org/2002/163 [NETSEL] Adrangi, F., "Mediating Network Discovery and Selection", Internet-Draft (work in progress), February 2004, draft-adrangi-eap-network-Discovery-and- Selection-01.txt Bersani Expires û December 2004 [Page 64] INTERNET-DRAFT EAP-PSK June 2004 [PEAP] Palekar, A. et al., ôProtected EAP Protocol (PEAP)ö, Internet-Draft (work in progress), October 2003, draft- josefsson-pppext-eap-tls-eap-07.txt [PEAP-TLV] Salowey, J., "Protected EAP TLV", Internet-Draft (work in progress), June 2003, draft-salowey-eap- protectedtlv-02.txt [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000 [PWD] National Institute of Standards and Technology (NIST). ôFIPS PUB 112: Password Usageö. May 30, 1985. [RFC 1750] Eastlake, D. et al., "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC 2989] Aboba, B. et al., " Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000 [SAM] Rescorla, E., "Survey of Authentication Mechanisms", Internet-Draft (work in progress), March 2004, draft-iab-auth-mech-03.txt [SKM] Bersani, F., ôEAP shared key methods: a tentative synthesis of those proposed so farö, Internet-Draft (work in progress), April 2004, draft-bersani-eap-synthesis-sharedkeymethods-00.txt [SIGMA] Krawczyk, H., "SIGMA: the SIGn-and-MAc Approach to Authenticated Diffie-Hellman and its use in the IKE protocol" [SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5, pp. 5-26, October 1996 [TIM] Kocher, P., "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems", CRYPTO 96, LNCS 1109, pp. 104-113, Springer-Verlag, Berlin, 1996 [WPA] Wi-Fi Alliance, ôWi-Fi Protected Accessö, version 2.0, April 2003 11. Authors' Addresses Florent Bersani florent.bersani@francetelecom.com Bersani Expires û December 2004 [Page 65] INTERNET-DRAFT EAP-PSK June 2004 France Telecom R&D 38, rue du General Leclerc 92794 Issy Les Moulineaux Cedex 9 France Bersani Expires û December 2004 [Page 66] INTERNET-DRAFT EAP-PSK June 2004 Annex A: Generation of the PSK from a password - Discouraged It is formally discouraged to use a password to generate a PSK, since this commonly lead to exhaustive search or dictionary attacks that would not otherwise be possible. However, we provide guidance on how to generate the PSK from a password. Guidance on how passwords should be selected is provided in [PWD]. The technique presented herein is drawn from [PKCS5]. It is intended to mitigate the risks associated with password usage in cryptography, typically dictionary attacks. If the binary representation in ASCII of the password is strictly fewer than 128 bit long (which by the way means that the chosen password is probably weak because it is too short) then its is padded to 128 bits with zeroes. If the binary representation in ASCII of the password is strictly more than 128 bit long, then it is hashed down to exactly 128 bit using the Matyas-Meyer-Oseas hash (please refer to [HAC] for a description of this hash) with IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has been arbitrarily selected). We now assume that we have a 128 bit number derived from the initial password (that can be the password itself if its binary representation in ASCII is exactly 128 bit long). We shall call this number P128. The PSK of EAP-PSK is derived thanks to PBKDF2 instantiated with (following the notations in [PKCS5]): 1. P128 as P 2. The first 96 bits of the binary ASCII representation of the xor of the peerÆs and the server's NAI as Salt. 3. 5000 as c 4. 48 as dkLen Although this gives better protection than nothing, the reader is reminded that this derivation does not stricto sensu protect against dictionary attacks. It only makes dictionary precomputation more difficult. Bersani Expires û December 2004 [Page 67] INTERNET-DRAFT EAP-PSK June 2004 Annex B: Generation of the PSK from a 128 bit shared key Since it may be found cumbersome to enter manually the 256 bits of the PSK that is split in two 128 bit subkeys and because 128 bit security provide an appropriate level of security for most applications (see [KSIZE] or [IEEE802REQ]), we provide hereafter guidance on how to reduce the credential used by EAP-PSK to 128 bits: we specify how to securely extend 128 bits to 256 bits that can then be used as the PSK. Contrary to the PSK generation from a password which is formally discouraged, generation of the PSK from a 128 bit shared key does not reduce in practice the security level of EAP-PSK (which only claims 128 bit security, see section 7). EAP-PSK may indeed evolve and this informative annex become normative part of the protocol if no concern arises. We take advantage of the key derivation scheme that is already used by EAP-PSK, namely the modified counter mode (see section 2.2.1). We present hereafter the parameters with which we use this mode for derivation of a 256 bit PSK from a 128 bit secret. All rotation values (the ri per [SOBMMO] Figure 3 notation) are set to zero (no rotations) and the counter values (the ci per [SOBMMO] Figure 3 notation) are respectively set to the first t integers (that is ci="i", starting with i=1). The parameter t of [SOBMO] is set to 2. The underlying block cipher used by this counter mode is AES-128. The input block is "0". For what regards the output blocks, using EAP-PSK terminology: 1. The first output block is AK 2. The second output block is KDK Bersani Expires û December 2004 [Page 68] INTERNET-DRAFT EAP-PSK June 2004 Annex C: Issue list for EAP-PSK An issue list for EAP-PSK is available at: http://perso.rd.francetelecom.fr/bersani/EAP_PSK/EAP-PSK_Issues.htm Bersani Expires û December 2004 [Page 69] INTERNET-DRAFT EAP-PSK June 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bersani Expires û December 2004 [Page 70]