idnits 2.17.1 draft-bersani-eap-psk-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2763. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 528: '...means that there MUST only be at most ...' RFC 2119 keyword, line 562: '...tive NAIs. This means that there MUST...' RFC 2119 keyword, line 583: '...tive NAIs. This means that there MUST...' RFC 2119 keyword, line 1181: '...d authentication MUST be supported i.e...' RFC 2119 keyword, line 1182: '... implementation MUST support sending ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2509 has weird spacing: '...ication and K...' == Line 2557 has weird spacing: '... common know...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 19, 2006) is 6521 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'String' on line 342 == Unused Reference: '20' is defined on line 2541, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 2554, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 2607, but no explicit reference was found in the text == Unused Reference: '45' is defined on line 2633, but no explicit reference was found in the text == Unused Reference: '50' is defined on line 2650, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-13 -- Obsolete informational reference (is this intentional?): RFC 2716 (ref. '11') (Obsoleted by RFC 5216) == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-15 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '20') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '21') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '24') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2898 (ref. '35') (Obsoleted by RFC 8018) == Outdated reference: A later version (-02) exists of draft-kamath-pppext-eap-mschapv2-01 -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '38') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: A later version (-07) exists of draft-iab-auth-mech-05 == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-03 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-10 Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP F. Bersani 3 Internet-Draft France Telecom R&D 4 Expires: December 21, 2006 H. Tschofenig 5 Siemens AG 6 June 19, 2006 8 The EAP-PSK Protocol: a Pre-Shared Key EAP Method 9 draft-bersani-eap-psk-11 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 21, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies EAP-PSK, an Extensible Authentication 43 Protocol (EAP) method for mutual authentication and session key 44 derivation using a Pre-Shared Key (PSK). 45 EAP-PSK provides a protected communication channel when mutual 46 authentication is successful for both parties to communicate over. 47 This document describes the use of this channel only for protected 48 exchange of result indications, but future EAP-PSK extensions may use 49 the channel for other purposes. 50 EAP-PSK is designed for authentication over insecure networks such as 51 IEEE 802.11. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Design goals for EAP-PSK . . . . . . . . . . . . . . . . . 4 57 1.1.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1.2. Wide Applicability . . . . . . . . . . . . . . . . . . 5 59 1.1.3. Security . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1.4. Extensibility . . . . . . . . . . . . . . . . . . . . 5 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 63 1.4. Related Work . . . . . . . . . . . . . . . . . . . . . . . 9 64 2. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 12 65 2.1. EAP-PSK key hierarchy . . . . . . . . . . . . . . . . . . 13 66 2.1.1. The PSK . . . . . . . . . . . . . . . . . . . . . . . 13 67 2.1.2. AK . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 2.1.3. KDK . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 2.2. The TEK . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 2.3. The MSK . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 2.4. The EMSK . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 2.5. The IV . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 3. Cryptographic design of EAP-PSK . . . . . . . . . . . . . . . 16 74 3.1. The Key Setup . . . . . . . . . . . . . . . . . . . . . . 16 75 3.2. The Authenticated Key Exchange . . . . . . . . . . . . . . 18 76 3.3. The Protected Channel . . . . . . . . . . . . . . . . . . 22 77 4. EAP-PSK Message Flows . . . . . . . . . . . . . . . . . . . . 26 78 4.1. EAP-PSK Standard Authentication . . . . . . . . . . . . . 26 79 4.2. EAP-PSK Extended Authentication . . . . . . . . . . . . . 29 80 5. EAP-PSK Message format . . . . . . . . . . . . . . . . . . . . 32 81 5.1. EAP-PSK First Message . . . . . . . . . . . . . . . . . . 32 82 5.2. EAP-PSK Second Message . . . . . . . . . . . . . . . . . . 34 83 5.3. EAP-PSK Third Message . . . . . . . . . . . . . . . . . . 36 84 5.4. EAP-PSK Fourth Message . . . . . . . . . . . . . . . . . . 40 85 6. Rules of Operation for the EAP-PSK Protected Channel . . . . . 43 86 6.1. Protected Result Indications . . . . . . . . . . . . . . . 43 87 6.1.1. CONT . . . . . . . . . . . . . . . . . . . . . . . . . 44 88 6.1.2. DONE_SUCCESS . . . . . . . . . . . . . . . . . . . . . 44 89 6.1.3. DONE_FAILURE . . . . . . . . . . . . . . . . . . . . . 45 90 6.2. Extended Authentication . . . . . . . . . . . . . . . . . 45 91 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 47 92 7.1. Allocation of an EAP-Request/Response Type for EAP-PSK . . 47 93 7.2. Allocation of EXT Type numbers . . . . . . . . . . . . . . 47 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 95 8.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 49 96 8.2. Protected Result Indications . . . . . . . . . . . . . . . 49 97 8.3. Integrity Protection . . . . . . . . . . . . . . . . . . . 50 98 8.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 51 99 8.5. Reflection attacks . . . . . . . . . . . . . . . . . . . . 51 100 8.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 51 101 8.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 52 102 8.8. Denial of Service Resistance . . . . . . . . . . . . . . . 53 103 8.9. Session Independence . . . . . . . . . . . . . . . . . . . 54 104 8.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 54 105 8.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 55 106 8.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 55 107 8.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 55 108 8.14. Identity Protection . . . . . . . . . . . . . . . . . . . 56 109 8.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 57 110 8.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 57 111 8.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 57 112 8.18. Implementation of EAP-PSK . . . . . . . . . . . . . . . . 58 113 9. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 59 114 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 116 11.1. Normative References . . . . . . . . . . . . . . . . . . . 61 117 11.2. Informative References . . . . . . . . . . . . . . . . . . 61 118 Appendix A. Generation of the PSK from a password - 119 Discouraged . . . . . . . . . . . . . . . . . . . . . 66 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 121 Intellectual Property and Copyright Statements . . . . . . . . . . 69 123 1. Introduction 125 1.1. Design goals for EAP-PSK 127 The Extensible Authentication Protocol (EAP) [2] provides an 128 authentication framework which supports multiple authentication 129 methods. 131 This document specifies an EAP method, called EAP-PSK, that uses a 132 Pre-Shared Key (PSK). 134 EAP-PSK was developed at France Telecom R&D in 2003-2004. It is 135 published as an RFC for the general information of the Internet 136 community and to allow independent implementations. 138 Because PSKs are of frequent use in security protocols, other 139 protocols may also refer to a PSK or contain this word in their name. 140 For instance, Wi-Fi Protected Access (WPA) [53] specifies an 141 authentication mode called "WPA-PSK". EAP-PSK is distinct from these 142 protocols and should not be confused with them. 144 Design goals for EAP-PSK were: 146 o Simplicity: EAP-PSK should be easy to implement and deploy without 147 any pre-existing infrastructure. It should be available quickly 148 because recently-released protocols, such as IEEE 802.11i [29], 149 employ EAP in a different threat model than PPP [48] and thus 150 require "modern" EAP methods. 152 o Wide applicability: EAP-PSK should be suitable to authenticate 153 over any network, and in particular over IEEE 802.11 [30] wireless 154 LANs. 156 o Security: EAP-PSK should be conservative in its cryptographic 157 design. 159 o Extensibility: EAP-PSK should be easily extensible. 161 1.1.1. Simplicity 163 For the sake of simplicity, EAP-PSK relies on a single cryptographic 164 primitive, AES-128 [6]. 166 Restriction to such a primitive, and in particular, not using 167 asymmetric cryptography like Diffie-Hellman key exchange, makes EAP- 168 PSK: 170 o Easy to understand and implement while avoiding cryptographic 171 negotiations. 173 o Light-weight and well suited for any type of device, especially 174 those with little processing power and memory. 176 However, as further discussed in Section 8, this prevents EAP-PSK 177 from offering advanced features such as identity protection, password 178 support, or Perfect Forward Secrecy (PFS). This choice has been 179 deliberately made as a trade-off between simplicity and security. 181 For the sake of simplicity, EAP-PSK has also chosen a fixed message 182 format and not a Type-Length-Value (TLV) design. 184 1.1.2. Wide Applicability 186 EAP-PSK has been designed in a threat model where the attacker has 187 full control over the communication channel. This is the EAP threat 188 model that is presented in Section 7.1 of [2]. 190 1.1.3. Security 192 Since the design of authenticated key exchange is notoriously known 193 to be hard and error prone, EAP-PSK tries to avoid inventing any new 194 cryptographic mechanism. It attempts to build instead on existing 195 primitives and protocols that have been reviewed by the cryptographic 196 community. 198 1.1.4. Extensibility 200 EAP-PSK explicitly provides a mechanism to allow future extensions 201 within its protected channel (see Section 3.3). Thanks to this 202 mechanism, EAP-PSK will be able to provide more sophisticated 203 services as the need to do so appears. 205 1.2. Terminology 207 Authentication, Authorization and Accounting (AAA) Please refer to 208 [10] for more details. 210 AES-128 A block cipher specified in the Advanced Encryption 211 Standard [6]. 213 Authentication Key (AK) A 16-byte key derived from the PSK that the 214 EAP peer and server use to mutually authenticate. 216 AKEP2 An authenticated key exchange protocol, please refer to 217 [14] for more details. 219 Backend Authentication Server An entity that provides an 220 authentication service to an Authenticator. When used, 221 this server typically executes EAP Methods for the 222 Authenticator (This terminology is also used in [28], and 223 has the same meaning in this document). 225 CMAC CMAC stands for cipher-based message authentication code 226 (MAC). It is the authentication mode of operation of AES 227 recommended by NIST in [7]. 229 Extensible Authentication Protocol (EAP) Defined in [2]. 231 EAP Authenticator (or simply Authenticator) The end of the EAP link 232 initiating the EAP authentication methods. (This 233 terminology is also used in [28], and has the same meaning 234 in this document). 236 EAP peer (or simply peer) The end of the EAP link that responds to 237 the Authenticator. (In [28], this end is known as the 238 Supplicant). 240 EAP server (or simply server) The entity that terminates the EAP 241 authentication with the peer. When there is no Backend 242 Authentication Server, this term refers to the EAP 243 Authenticator. Where the EAP Authenticator operates in 244 pass-through mode, it refers to the Backend Authentication 245 Server. 247 EAX An authenticated-encryption with associated data mode of 248 operation for block ciphers, [3]. 250 Extended Master Session Key (EMSK) Additional keying material derived 251 between the EAP peer and server that is exported by the EAP 252 method. The EMSK is reserved for future uses that are not 253 defined yet and is not provided to a third party. Please 254 refer to [8] for more details. 255 EAP-PSK generates a 64-byte EMSK. 257 Initialization Vector (IV) A quantity of at least 64 bytes, suitable 258 for use in an initialization vector field, that is derived 259 between the peer and EAP server. Since the IV is a known 260 value in methods such as EAP-TLS [11], it cannot be used by 261 itself for computation of any quantity that needs to remain 262 secret. As a result, its use has been deprecated and EAP 263 methods are not required to generate it. Please refer to 265 [8] for more details. 266 EAP-PSK does not generate an IV. 268 Key-Derivation Key (KDK) A 16-byte key derived from the PSK that the 269 EAP peer and server use to derive session keys (namely, the 270 TEK, MSK and EMSK). 272 Message Authentication Code (MAC) Informally, the purpose of a MAC is 273 to provide assurances regarding both the source of a 274 message and its integrity [43]. IEEE 802.11i uses the 275 acronym MIC (Message Integrity Check) to avoid confusion 276 with the other meaning of the acronym MAC (Medium Access 277 Control). 279 Master Session Key (MSK) Keying material that is derived between the 280 EAP peer and server and exported by the EAP method. In 281 existing implementations a AAA server acting as an EAP 282 server transports the MSK to the Authenticator [8]. 283 EAP-PSK generates a 64-byte MSK. 285 Network Access Identifier (NAI) Identifier used to identify the 286 communicating parties [1]. 288 One Key CBC-MAC 1 (OMAC1) A method to generate a Message 289 Authentication Code [31]. CMAC is the name under which 290 NIST has standardized OMAC1. 292 Perfect Forward Secrecy (PFS) The confidence that the compromise of a 293 long-term private key does not compromise any earlier 294 session keys. In other words, once an EAP dialog is 295 finished and its corresponding keys are forgotten, even 296 someone who has recorded all of the data from the 297 connection and gets access to all of the long-term keys of 298 the peer and the server cannot reconstruct the keys used to 299 protect the conversation without doing a brute force search 300 of the session key space. 301 EAP-PSK does not have this property. 303 Pre-Shared Key (PSK) A Pre-Shared Key simply means a key in symmetric 304 cryptography. This key is derived by some prior mechanism 305 and shared between the parties before the protocol using it 306 takes place. It is merely a bit sequence of given length, 307 each bit of which has been chosen at random uniformly and 308 independently. For EAP-PSK, the PSK is the long term 16- 309 byte credential shared by the EAP peer and server. 311 Protected Result Indication Please refer to Section 7.16 of [2] for a 312 definition of this term. This feature has been introduced 313 because EAP-Success/Failure packets are unidirectional and 314 are not protected. 316 Transient EAP Key (TEK) A session key which is used to establish a 317 protected channel between the EAP peer and server during 318 the EAP authentication exchange. The TEK is appropriate 319 for use with the ciphersuite negotiated between the EAP 320 peer and server to protect the EAP conversation. Note that 321 the ciphersuite used to set up the protected channel 322 between the EAP peer and server during EAP authentication 323 is unrelated to the ciphersuite used to subsequently 324 protect data sent between the EAP peer and Authenticator 325 [8]. 326 EAP-PSK uses a 16-byte TEK for its protected channel, which 327 is the only ciphersuite available between the EAP peer and 328 server to protect the EAP conversation. This ciphersuite 329 uses AES-128 in the EAX mode of operation. 331 1.3. Conventions 333 All numbers presented in this document are considered in network-byte 334 order. 336 || denotes concatenation of strings (and not the logical OR). 338 MAC(K, String) denotes the MAC of String under the key K (the 339 algorithm used in this document to compute the MACs is CMAC with AES- 340 128, see Section 3.2). 342 [String] denotes the concatenation of String with the MAC of String 343 calculated as specified by the context. Hence, we have, with K 344 specified by the context: 345 [String]=String||MAC(K,String) . 347 ** denotes integer exponentiation. 349 "i" denotes the unsigned binary representation on 16 bytes of the 350 integer i in network byte order. Therefore this notation only makes 351 sense when i is between 0 and 2**128-1. 353 denotes the unsigned binary representation on 4 bytes of the 354 integer i in network byte order. Therefore this notation only makes 355 sense when i is between 0 and 2**32-1. 357 1.4. Related Work 359 At the time this document is written, only three EAP methods are 360 standards track EAP methods per IETF terminology (see [17]), namely: 362 o MD5-Challenge (EAP-Request/Response type 4), defined in [2], which 363 uses a MD5 challenge similar to [49]. 365 o OTP (EAP-Request/Response type 5), defined in [2], which aims at 366 providing One-Time Password support similar to [23] and [42]. 368 o GTC (EAP-Request/Response type 6), defined in [2], which aims at 369 providing Generic Token Card Support. 371 Unfortunately, all three methods are deprecated for security reasons 372 that are explained in part in [2]. 374 Myriads of EAP methods have however been otherwise proposed: 376 o One as an experimental RFC (EAP-TLS [11]) - which therefore is not 377 a standard (see [27]) 379 o Some as individual Internet-Drafts submissions (e.g., [46] or this 380 document). 382 o And some even undocumented (e.g., Rob EAP which has EAP-Request/ 383 Response type 31). 385 However, no secure and mature Pre-Shared Key EAP method is yet easily 386 and widely available, which is all the more regrettable that Pre- 387 Shared Key methods are the most basic ones! 389 The existing proposals for a future Pre-Shared Key EAP method are 390 briefly reviewed hereafter (please refer to [16] for a more thorough 391 synthesis on EAP methods). 393 Among these proposals, there are some which: 395 o Are broken from a security point of view, e.g.: 397 * LEAP which is specified in [41] and which vulnerabilities are 398 discussed in [54]. 400 * EAP-MSCHAPv2 which is specified in [36] and which 401 vulnerabilities are indirectly discussed in [47]. 403 o Essentially require additional infrastructure, e.g., EAP-SIM [26], 404 EAP-AKA [12] or OTP/token card methods like [33]. 406 o Are not shared key methods but often confused with them, namely 407 the password methods, e.g., EAP-SRP [18] or SPEKE [32] - which 408 wide adoption very unfortunately seem to be hindered by 409 Intellectual Property Rights issues. 411 o Are generic tunneling methods which do not essentially rely on 412 Pre-Shared Keys as they require a public-key certificate for the 413 server and allow the peer to authenticate with whatever EAP method 414 or even other non-EAP authentication mechanisms, namely [34] and 415 [22]. 417 o Are abandoned but have provided the basis for EAP-PSK, namely, 418 EAP-Archie [52]. 420 o Are possible alternatives to EAP-PSK (i.e., claimed to be secure 421 and subject of active work): 423 * EAP-FAST [46]. 425 * EAP-IKEv2 [51]. 427 * EAP-TLS (when shared key/password support is added to TLS, see 428 [55]). 430 EAP-PSK differs from the aforementioned methods on the following 431 points: 433 o No attacks on EAP-PSK within its threat model have yet been found. 435 o EAP-PSK was not designed to leverage a pre-existing 436 infrastructure. Thus, it does not inherit potential limitations 437 of such an infrastructure and it should be easier to deploy "from 438 scratch". 440 o EAP-PSK wished to avoid IPR blockages. 442 o EAP-PSK does not have any dependencies on protocols other than 443 EAP. 445 o EAP-PSK restricted to simply proposing a Pre-Shared Key method 446 with symmetric cryptography 448 * To remain simple to understand and implement 449 * To avoid potentially complex configurations and negotiations 451 o EAP-PSK was designed with efficiency in mind. 453 2. Protocol overview 455 Figure 1 presents an overview of the EAP-PSK protocol. 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+ 458 | | ^ 459 | EAP-PSK Protocol: a Pre-Shared Key EAP Method | | 460 | | | 461 | +----------+ | | 462 | | PSK | | | 463 | |(16 bytes)| | | 464 | +----------+ | | 465 | | | | 466 | v | | 467 | *********************** | | 468 | *Modified Counter Mode* | | 469 | *********************** | | 470 | | | | | 471 | v v | | 472 | +----------+ +----------+ +----------------+ | | 473 | | AK | | KDK | | RAND_P | | | 474 | |(16 bytes)| |(16 bytes)| |(16 bytes) | | | 475 | +----------+ +----------+ +----------------+ | | 476 | | | | | 477 | | | | | 478 | +-----------+ | | | | 479 | +--------+|Plain Text | | | | | 480 |+-------+|Header H||Var.Length | | | | | 481 ||Nonce N||22 bytes|+-----------+ v v Local | 482 ||4 bytes|+--------+ | *********************** to EAP | 483 |+-------+ | +--------+ +------*Modified Counter Mode* Method | 484 | | v v v *********************** | | 485 | | ******* +--------+ |64 |64 | | 486 | | * EAX *-------|TEK | |bytes |bytes | | 487 | +-->******* |16 bytes| | | | | 488 | | +--------+ | | | | 489 | +-----+----+ | | | | 490 | v v | | | | 491 |+--------+ +-------------------+ | | | | 492 ||Tag | |Cipher Text Payload| | | | | 493 ||16 bytes| | Variable length L | | | | | 494 |+--------+ +-------------------+ | | | V 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+ 496 | | ^ 497 +-+-+-+-+-++ +-+-+-+-+-++ | 498 |MSK | |EMSK | | 499 | | | | Exported | 500 +-+-+-+-+-++ +-+-+-+-+-++ by EAP | 501 | | Method | 502 | | | 503 V V | 504 ************************* V 505 * AAA Key Derivation * ---+ 506 * Naming & Binding * 507 ************************* 509 Figure 1: EAP-PSK overview 511 2.1. EAP-PSK key hierarchy 513 This section presents the key hierarchy used by EAP-PSK. This 514 hierarchy is inspired by the EAP Key hierarchy described in [8]. 516 2.1.1. The PSK 518 The PSK is shared between the EAP peer and the EAP server. 520 EAP-PSK assumes that the PSK is known only to the EAP peer and EAP 521 server. The security properties of the protocol is compromised if it 522 has wider distribution. Please note that EAP-PSK shares this 523 property with all other symmetric key methods (including all password 524 based methods). 526 EAP-PSK also assumes the EAP server and EAP peer identify the correct 527 PSK to use with each other thanks to their respective NAIs. This 528 means that there MUST only be at most one PSK shared between an EAP 529 server using a given server NAI and an EAP peer using a given peer 530 NAI. 532 This PSK is used, as shown in Figure 2, to derive two 16-byte static 533 long-lived subkeys, respectively called the Authentication Key (AK) 534 and the Key-Derivation Key (KDK). This derivation should only be 535 done once: it is called the key setup. For an explanation of why PSK 536 is not used a static long-lived key but only as the initial keying 537 material from which the static long-lived keys, AK and KDK, that are 538 actually used by the protocol EAP-PSK, see Section 3.1. 540 +---------------------------+ 541 | PSK | 542 | (16 bytes) | 543 +---------------------------+ 544 | | 545 v v 546 +---------------------------+ +---------------------------+ 547 | AK | | KDK | 548 | (16 bytes) | | (16 bytes) | 549 +---------------------------+ +---------------------------+ 551 Figure 2: Derivation of AK and KDK from the PSK 553 2.1.2. AK 555 EAP-PSK uses AK to mutually authenticate the EAP peer and the EAP 556 server. 558 AK is a static long-lived key derived from the PSK, see Section 3.1. 559 AK is not a session key. 561 The EAP server and EAP peer identify the correct AK to use with each 562 other thanks to their respective NAIs. This means that there MUST 563 only be at most one AK shared between an EAP server using a given 564 server NAI and an EAP peer using a given peer NAI. This is the case 565 when there is at most one PSK shared between an EAP server using a 566 given server NAI and an EAP peer using a given peer NAI, see 567 Section 2.1.1. 569 The EAP peer chooses the AK to use based on the EAP server NAI that 570 has been sent by the EAP server in the first EAP-PSK message (namely 571 ID_S, see Section 4.1) and the EAP peer NAI it chooses to include in 572 the second EAP-PSK message (namely ID_P, see Section 4.1). 574 2.1.3. KDK 576 EAP-PSK uses KDK to derive session keys shared by the EAP peer and 577 the EAP server (namely, the TEK, MSK and EMSK). 579 KDK is a static long-lived key derived from the PSK, see Section 3.1. 580 KDK is not a session key. 582 The EAP server and EAP peer identify the correct AK to use with each 583 other thanks to their respective NAIs. This means that there MUST 584 only be at most one AK shared between an EAP server using a given 585 server NAI and an EAP peer using a given peer NAI. This is the case 586 when there is at most one PSK shared between an EAP server using a 587 given server NAI and an EAP peer using a given peer NAI, see 588 Section 2.1.1. 590 The EAP peer chooses the AK to use based on the EAP server NAI that 591 has been sent by the EAP server in the first EAP-PSK message (namely 592 ID_S, see Section 4.1) and the EAP peer NAI it chooses to include in 593 the second EAP-PSK message (namely ID_P, see Section 4.1). 595 2.2. The TEK 597 EAP-PSK derives a 16-byte TEK thanks to a random number exchanged 598 during authentication (RAND_P, see Section 5.1) and KDK. 600 This TEK is used to implement a protected channel for both mutually 601 authenticated parties to communicate over securely. 603 2.3. The MSK 605 EAP-PSK derives a MSK thanks to a random number exchanged during 606 authentication (RAND_P, see Section 5.1) and the KDK. 608 The MSK is 64 bytes long, which complies with [2]. 610 2.4. The EMSK 612 EAP-PSK derives an EMSK thanks to a random number exchanged during 613 authentication (RAND_P, see Section 5.1) and the KDK. 615 The EMSK is 64 bytes long, which complies with [2]. 617 2.5. The IV 619 EAP-PSK does not derive any IV, which complies with [8]. 621 3. Cryptographic design of EAP-PSK 623 EAP-PSK relies on a single cryptographic primitive, a block cipher, 624 which is instantiated with AES-128. AES-128 takes a 16-byte Pre- 625 Shared Key and a 16-byte Plain Text block as inputs. It outputs a 626 16-byte Cipher Text block. For a detailed description of AES-128, 627 please refer to [6]. 629 AES-128 has been chosen because: 631 o It is standardized and implementations are widely available. 633 o It has been carefully reviewed by the cryptographic community and 634 is believed to be secure. 636 Other block ciphers could easily be proposed for EAP-PSK, as EAP-PSK 637 does not intrinsically depend on AES-128. The only parameters of 638 AES-128 that EAP-PSK depends on, are the AES-128 block and key size 639 (16 bytes). For the sake of simplicity, EAP-PSK has however been 640 chosen to restrict to a single mandatory block cipher and not allow 641 the negotiation of other block ciphers. In case AES-128 is 642 deprecated for security reasons, EAP-PSK should also be deprecated 643 and a cut-and-paste EAP-PSK' should be defined with another block 644 cipher. This EAP-PSK' should not be backward compatible with EAP-PSK 645 because of the security issues with AES-128. EAP-PSK' should 646 therefore use a different EAP-Request/Response Type number. With the 647 EAP-Request/Response Type number space structure defined in [2], this 648 should not be a problem. The use of a different EAP-Request/Response 649 Type number for EAP-PSK' will prevent this new method from being 650 vulnerable to chosen protocol attacks. 652 EAP-PSK uses three cryptographic parts: 654 o A key setup to derive AK and KDK from the PSK. 656 o An authenticated key exchange protocol to mutually authenticate 657 the communicating parties and derive session keys. 659 o A protected channel protocol for both mutually authenticated 660 parties to communicate over. 662 Each part is discussed in more detail in the subsequent paragraphs. 664 3.1. The Key Setup 666 EAP-PSK needs two cryptographically separated 16-byte subkeys for 667 mutual authentication and session key derivation. Indeed, it is a 668 rule of the thumb in cryptography to use different keys for different 669 applications. 671 It could have implemented these two subkeys either by specifying a 672 32-byte PSK that would then be split in two 16-byte subkeys, or by 673 specifying a 16-byte PSK that would then be cryptographically 674 expanded to two 16-byte subkeys. 676 Because provisioning a 32-byte long term credential is more 677 cumbersome than a 16-byte one, and the strength of the derived 678 session keys is 16 bytes either ways, the latter option was chosen. 680 Hence, the PSK is only used by EAP-PSK to derive AK and KDK. This 681 derivation should be done only once, immediately after the PSK has 682 been provisioned. As soon as AK and KDK have been derived, the PSK 683 should be deleted. If the PSK is deleted, it should be done so 684 securely (see, for instance, [19] for guidance on secure deletion of 685 the PSK). 687 Derivation of AK and KDK from the PSK is called the key setup: 689 o The input to the key setup is the PSK. 691 o The outputs of the key setup are AK and KDK. 693 AK and KDK are derived from the PSK using the modified counter mode 694 of operation of AES-128. The modified counter mode is a length 695 increasing function, i.e., it expands one AES-128 input block into a 696 longer t-block output, where t>=2. This mode was chosen for the key 697 setup because it had already been chosen for the derivation of the 698 session keys (see Section 3.2). 700 The details of the derivation of AK and KDK from the PSK are shown in 701 Figure 3. 703 +--------------------------+ 704 | "0" | 705 | Input Block (16 bytes) | 706 +--------------------------+ 707 | 708 v 709 +----------------+ 710 | | 711 | AES-128(PSK,.) | 712 | | 713 +----------------+ 714 | 715 | 716 +----------------------------+ 717 | | 718 v v 719 +--------+ +---+ +--------+ +---+ 720 | c1="1" |->|XOR| | c2="2" |->|XOR| 721 |16 bytes| +---+ |16 bytes| +---+ 722 +--------+ | +--------+ | 723 | | 724 +----------------+ +----------------+ 725 | | | | 726 | AES-128(PSK,.) | | AES-128(PSK,.) | 727 | | | | 728 +----------------+ +----------------+ 729 | | 730 | | 731 v v 732 +------------------------+ +------------------------+ 733 | AK | | KDK | 734 | (16 bytes) | | (16 bytes) | 735 +------------------------+ +------------------------+ 737 Figure 3: Derivation of AK and KDK from the PSK in Details 739 The input block is "0". For the sake of simplicity, this input block 740 has been chosen constant: it could have been set to a value depending 741 on the peer and the server (for instance, the XOR of their respective 742 NAIs appropriately truncated or zero-padded), but this did not seem 743 to add much security to the scheme, whereas it added complexity. Any 744 16-byte constant could have been chosen, as the security is not 745 supposed to depend on the particular value taken by the constant. "0" 746 was arbitrarily chosen. 748 3.2. The Authenticated Key Exchange 750 The authentication protocol used by EAP-PSK is inspired of AKEP2 751 which is described in [14]. 753 AKEP2 consists of a one and half round trip exchange, as shown in 754 Figure 4 which is inspired of Figure 5 of [14]. 756 Bob Alice 757 | RA | 758 |<---------------------------------------------------------| 759 | | 760 | [B||A||RA||RB] | 761 |--------------------------------------------------------->| 762 | | 763 | [A||RB] | 764 |<---------------------------------------------------------| 766 Figure 4: Overview of AKEP2 768 It is also worth noting that [14] focuses on cryptography and not on 769 designing a real-life protocol. Thus, as noted in subsection "Out- 770 Of-Band-Data" of [14], Alice has to send A, its identity, to Bob so 771 that Bob may select the appropriate credential for the sequel of the 772 conversation. This leads to a slightly complemented version of AKEP2 773 for EAP-PSK as depicted in Figure 5. 775 Bob Alice 776 | A||RA | 777 |<---------------------------------------------------------| 778 | | 779 | [B||A||RA||RB] | 780 |--------------------------------------------------------->| 781 | | 782 | [A||RB] | 783 |<---------------------------------------------------------| 785 Figure 5: Overview of AKEP2 787 In AKEP2, 789 o RA and RB are random numbers chosen respectively by Alice and Bob. 791 o A and B are Alice's and Bob's respective identities. They allow 792 Alice and Bob to retrieve the key that they have to use to run an 793 authenticated key exchange between each other. They are also 794 included in the protocol for cryptographic reasons. 796 o The MACs (see Section 1.3 for the notation "[]") are calculated 797 using a dedicated key. 799 EAP-PSK instantiates this protocol with: 801 o The server as Alice and the peer as Bob. 803 o RA and RB as 16-byte random numbers, using Section 4.1 notations, 804 this means RA=RAND_S and RB=RAND_P. 806 o A and B as Alice's and Bob's respective NAIs, using Section 4.1 807 notations, this means A=ID_S and B=ID_P.. 809 o The MAC algorithm as CMAC with AES-128 using AK and producing a 810 tag length of 16 bytes. 812 o The modified counter mode of operation of AES-128 using KDK, to 813 derive session keys as a result of this exchange. 815 CMAC was chosen as the MAC algorithm because it is capable of 816 handling of arbitrary length messages, and its design is simple. It 817 also enjoys up to date review by the cryptographic community, 818 especially using provable security concepts. It has been recommended 819 by the NIST. For a detailed description of CMAC, please refer to 820 [7]. 822 In AKEP2 the key exchange is "implicit": the session keys are derived 823 from RB. In EAP-PSK, the session keys are thus derived from RAND_P 824 by using KDK and the modified counter mode of operation of AES-128 825 described in [4]. This mode was chosen because it is a simple key 826 derivation schemes that relies on a block cipher and has a proof of 827 its security. It is a length increasing function, i.e., it expands 828 one AES-128 input block into a longer t-block output, where t>=2. 829 The derivation of the session keys is shown in Figure 6. 831 +--------------------------+ +-------------------------------+ 832 | RAND_P | | KDK | 833 | Input Block (16 bytes) | | Key Derivation Key (16 bytes) | 834 +--------------------------+ +-------------------------------+ 835 | | 836 v v 837 +-----------------------------------------------------------------+ 838 | | 839 | Modified Counter Mode | 840 | | 841 +-----------------------------------------------------------------+ 842 | | | 843 v v v 844 +------------+ +----------------------+ +----------------------+ 845 | TEK | | MSK | | EMSK | 846 | (16 bytes) | | (64 bytes) | | (64 bytes) | 847 +------------+ +----------------------+ +----------------------+ 849 Figure 6: Derivation of the Session Keys 851 The input to the derivation of the session keys is RAND_P. 853 The outputs of the derivation of the session keys are: 855 * The 16-byte TEK (the first output block). 857 * The 64-byte MSK (the concatenation of the second to fifth 858 output blocks). 860 * The 64-byte EMSK (the concatenation of the sixth to ninth 861 output blocks). 863 The details of the derivation of the session keys are shown in 864 Figure 7. 866 +--------------------------+ 867 | RAND_P | 868 | Input Block (16 bytes) | 869 +--------------------------+ 870 | 871 v 872 +----------------+ 873 | | 874 | AES-128(KDK,.) | 875 | | 876 +----------------+ 877 | 878 | 879 +---------------------+-- - - - - - - - - - --+ 880 | | | 881 v v v 882 +--------+ +---+ +--------+ +---+ +--------+ +---+ 883 | c1="1" |->|XOR| | c2="2" |->|XOR|.......| c9="9" |->|XOR| 884 |16 bytes| +---+ |16 bytes| +---+ |16 bytes| +---+ 885 +--------+ | +--------+ | +--------+ | 886 | | | 887 +----------------+ +----------------+ +----------------+ 888 | | | | | | 889 | AES-128(KDK,.) | | AES-128(KDK,.) |......| AES-128(KDK,.) | 890 | | | | | | 891 +----------------+ +----------------+ +----------------+ 892 | | | 893 | | | 894 v v v 895 +-----------------+ +-----------------+ +------------------+ 896 | Output Block #1 | | Output Block #2 | | Output Block #9 | 897 | (16 bytes) | | (16 bytes) |.....| (16 bytes) | 898 | TEK | | MSK (block 1/4) | | EMSK (block 4/4) | 899 +-----------------+ +-----------------+ +------------------+ 901 Figure 7: Derivation of the Session Keys in Details 903 The counter values are set respectively to the first t integers (that 904 is ci="i", with i=1 to 9). 906 Keying material is sensitive information and should be handled 907 accordingly (see Section 8.10 for further discussion. 909 3.3. The Protected Channel 911 EAP-PSK provides a protected channel for both parties to communicate 912 over, in case of a successful authentication. This protected channel 913 is currently used to exchange protected result indications and may be 914 used in the future to implement extensions. 916 EAP-PSK uses the EAX mode of operation to provide this protected 917 channel. For a detailed description of EAX, please refer to [3]. 918 Figure 8 shows how EAX is used to implement EAP-PSK protected 919 channel. 921 +-----------+ +----------------+ +---------------------+ +----------+ 922 | Nonce N | | Header H | | Plain Text Payload | | TEK | 923 | 4 bytes | | 22 bytes | | Variable length L | | 16 bytes | 924 +-----------+ +----------------+ +---------------------+ +----------+ 925 | | | | 926 v v v v 927 +-------------------------------------------------------------------+ 928 | | 929 | EAX | 930 | | 931 +-------------------------------------------------------------------+ 932 | | 933 v v 934 +---------------------+ +----------+ 935 | Cipher Text Payload | | Tag | 936 | Variable length L | | 16 bytes | 937 +---------------------+ +----------+ 939 Figure 8: The Protected Channel 941 This protected channel: 943 o Provides replay protection. 945 o Encrypts and authenticates a Plain Text Payload that becomes an 946 Encrypted Payload. The Plain Text Payload must not exceed 960 947 bytes, see Section 5.3, Section 5.4 and Section 8.11. 949 o Only authenticates a Header that is thus sent in clear. 951 EAX is instantiated with AES-128 as the underlying block cipher. 953 AES-128 is keyed with the TEK. 955 The nonce N is used to provide cryptographic security to the 956 encryption and data origin authentication as well as protection 957 replay. Indeed, N is a 4-byte sequence number starting from <0> that 958 is monotonically incremented at each EAP-PSK message within one EAP- 959 PSK dialog, except retransmissions of course. 960 N was taken to be 4 bytes to avoid 16-byte arithmetic. Since EAX 961 uses a 16-byte nonce, N is padded with 96 zero bits for its high 962 order bits. 963 For cryptographic reasons, N is not allowed to wrap around. In the 964 unlikely, yet possible, event of the server sending an EAP-PSK 965 message with N set to <2**32-2>, it must not send any further message 966 on this protected channel, which would cause to reuse the value 0. 967 Either the conversation is finished after the server receives the 968 EAP-PSK answer from the peer with N set to <2**32-1> and the server 969 proceeds (typically by sending an EAP-Success or Failure), or the 970 conversation is not finished and must then be aborted (a new EAP-PSK 971 dialog may subsequently be started to try again to authenticate). 972 Thus, the maximum number of messages that can be exchanged over the 973 same protected channel is 2**32 (which should not be a limitation in 974 practice as this is approximately equal to 4 billions). 976 The Header H consists in the first 22 bytes of the EAP Request or 977 Response packet (i.e. the EAP Code, Identifier, Length and Type 978 fields followed by the EAP-PSK Flags and RAND_S fields). Although it 979 may appear unorthodox that an upper layer (EAP-PSK) protects some 980 information of the lower layer (EAP), this was chosen to comply with 981 EAP recommendation (see Section 7.5. of [2]) and seems to be existing 982 practice at IETF (see, for instance, [38]). 984 The Plain Text Payload is the payload that is to be encrypted and 985 integrity protected. The Cipher Text payload is the result of the 986 encryption of the Plain Text. 988 The Tag is a MAC that protects both the Header and the Plain Text 989 Payload. 990 The verification of the Tag must only be done after a successful 991 verification of the Nonce for replay protection. 992 If the verification of the Tag succeeds, then the Encrypted Payload 993 is decrypted to recover the Plain Text Payload. If the verification 994 of the Tag fails, then no decryption is performed and this MAC 995 failure should be logged. 996 The tag length is chosen to be 16 bytes for EAX within EAP-PSK. This 997 length is considered appropriate by the cryptographic community. 999 EAX was mainly chosen because: 1001 o It strongly relies on OMAC in its design and OMAC1, a variant of 1002 OMAC, had already been chosen in EAP-PSK for the authentication 1003 part (please rememeber that OMAC1 and CMAC are analogous. 1005 o Its design is simple. 1007 o It enjoys a security proof. 1009 o It is free of any Intellectual Property Rights claims. 1011 4. EAP-PSK Message Flows 1013 EAP-PSK may consist of two different types of message flows: 1015 o The "standard authentication", which is: 1017 * Mandatory to implement. 1019 * Fully specified in this document. 1021 * The simpler type of message flow, which is expected to be used 1022 most frequently. 1024 o The "extended authentication", which is: 1026 * Optional to implement (i.e., there are no mandatory 1027 extensions). 1029 * Partly specified in this document since it depends on 1030 extensions and none are currently specified, let alone in this 1031 document. 1033 * The type of message flow that should be used when extensions of 1034 EAP-PSK are needed by more sophisticated usage scenarios and 1035 are available. 1037 EAP-PSK introduces the concept of session to facilitate its analysis 1038 and provide a cleaner interface to other layers. A session is a 1039 particular instance of an EAP-PSK dialog between two parties. This 1040 session is identified by a session identifier. 1042 In the first EAP-PSK message, the EAP server asserts its identity. 1043 Given that the EAP-Request/Identity and EAP-Response/Identity may not 1044 be assumed to have occured prior to this sending and that the 1045 response included in EAP-Response/Identity (if this EAP Identity 1046 exchange takes) place may not contain the actual NAI the peer shall 1047 use with EAP-PSK, this means that an EAP server implementing EAP-PSK 1048 must use the same EAP server NAI for all EAP-PSK dialogs with any EAP 1049 peer implementing EAP-PSK. 1051 4.1. EAP-PSK Standard Authentication 1053 EAP-PSK standard authentication is comprised of four messages, i.e., 1054 two round trips; see Figure 9. 1056 peer server 1057 | Flags||RAND_S||ID_S | 1058 |<---------------------------------------------------------| 1059 | | 1060 | Flags||RAND_S||RAND_P||MAC_P||ID_P | 1061 |--------------------------------------------------------->| 1062 | | 1063 | Flags||RAND_S||MAC_S||PCHANNEL_S_0 | 1064 |<---------------------------------------------------------| 1065 | | 1066 | Flags||RAND_S||PCHANNEL_P_1 | 1067 |--------------------------------------------------------->| 1068 | | 1070 Figure 9: EAP-PSK Standard Authentication 1072 o The first message is sent by the server to the peer to: 1074 * Send a 16-byte random challenge (RAND_S). RAND_S was called RA 1075 in Section 3.2 1077 * State its identity (ID_S). ID_S was denoted by A in 1078 Section 3.2. 1080 o The second message is sent by the peer to the server to: 1082 * Send another 16-byte random challenge (RAND_P). RAND_P was 1083 called RB in Section 3.2 1085 * State its identity (ID_P). ID_P was denoted by B in 1086 Section 3.2. 1088 * Authenticate to the server by proving that it is able to 1089 compute a particular MAC (MAC_P), which is a function of the 1090 two challenges and AK: 1091 MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P) 1093 o The third message is sent by the server to the peer to: 1095 * Authenticate to the peer by proving that it is able to compute 1096 another MAC (MAC_S), which is a function of the peer's 1097 challenge and AK: 1098 MAC_S = CMAC-AES-128(AK, ID_S||RAND_P) 1100 * Set up the protected channel (P_CHANNEL_S_0) to: 1102 + Confirm that it has derived session keys (at least the TEK). 1104 + Give a protected result indication of the authentication. 1106 o The fourth message is sent by the peer to the server to finish the 1107 setup of the protected channel (P_CHANNEL_P_1) to: 1109 * Confirm that it has derived session keys (at least the TEK). 1111 * Give a protected result indication of the authentication. 1113 The PCHANNEL_S_0 and PCHANNEL_P_1 fields of the third and fourth EAP- 1114 PSK messages contain a MAC computed thanks to TEK that protects the 1115 integrity of the messages. For a detailed list of the fields of the 1116 messages that are integrity protected please refer to Section 3.3. 1118 All EAP-PSK messages include a sort of header which is comprised of 1119 two fields: 1121 o Flags, a 1-byte field that is currently only used to number EAP- 1122 PSK messages. 1124 o RAND_S, a 16-byte challenge sent by the server that is used as a 1125 session identifier. 1127 This standard message flow could be comprised of only three messages, 1128 like AKEP2, were it not the request/response nature of EAP that 1129 prevents the third message to be the last one. Since the fourth 1130 message is mandatory, EAP-PSK chose to take advantage of this and set 1131 up a protected channel. 1133 The standard message flow also includes a statement by the peer of 1134 its identity, in addition to the EAP-Response/Identity it may have 1135 sent. This behavior follows Section 5.1 of [2] which recommends that 1136 the EAP-Response/Identity be used primarily for routing purposes and 1137 selecting which EAP method to use, and therefore that EAP methods 1138 include a method-specific mechanism for obtaining the identity, so 1139 that they do not have to rely on the Identity Response. 1141 When a party receives an EAP-PSK message, it checks that the message 1142 is syntaxically valid in accordance with the message formats defined 1143 in Section 5. If the message is syntaxically incorrect, then it is 1144 silently discarded.Then it checks the cryptographic validity of this 1145 message, i.e. it checks the MAC(s), namely 1147 o If the received message is the first EAP-PSK message, there is no 1148 MAC to check as none is included in message 1. 1150 o If the received message is the second EAP-PSK message, the 1151 validity of MAC_P is checked. 1153 o If the received message is the third EAP-PSK message, the validity 1154 of MAC_S is checked and then the validity of the Tag included in 1155 P_CHANNEL_S_0 is checked. The validity checks must be done in 1156 this order to avoid unnecessarily deriving TEK, MSK and EMSK in 1157 case MAC_S is invalid, meaning that mutual authentication has 1158 failed. Indeed, TEK is used to verify the validity of the Tag 1159 included in P_CHANNEL_S_0. 1161 o If the received message is the fourth EAP-PSK message, the 1162 validity of the Tag included in P_CHANNEL_P_1 is checked. 1164 In case a validity check fails, the message is silently discarded. 1165 There can be a counter to track the number of silently discarded 1166 messages Section 8.8. In case, there is an encrypted payload in the 1167 message (namely in the PCHANNEL attribute), then the encrypted 1168 payload is decrypted. Then, if the decrypted payload is syntaxically 1169 incorrect then the message is silently discarded. 1171 4.2. EAP-PSK Extended Authentication 1173 To remain simple and yet be extensible to meet future requirements, 1174 EAP-PSK provides an extension mechanism within its protected channel: 1175 the payload of the protected channel may contain an optional 1176 extension field (EXT). 1178 Figure 10 presents the message sequence for EAP-PSK extended 1179 authentication. 1181 Extended authentication MUST be supported i.e. any EAP-PSK 1182 implementation MUST support sending and reception of an EXT attribute 1183 according to rules of operation described in Section 6. Yet, 1184 although support of the EXT field is mandatory, there is no mandatory 1185 extension type to support. This means that if a server engages in 1186 EAP-PSK extended authentication, as only the server can start 1187 extended authentication per Section 6, a peer will recognize the 1188 attempt to start extended authentication through its EXT support. If 1189 the peer does not support the particular extension type used by the 1190 server, the peer will still be able to conclude the EAP-PSK dialog 1192 The mandatory support of the EXT field is dictated: 1194 o To guarantee a robust behavior in the future where some peers 1195 might support some extensions and others not. All peers will thus 1196 be able to understand that an extended authentication is being 1197 attempted and indicate whether or not they support the extension 1198 that is tried. 1200 o To ensure that all implementations will indeed be extensible. 1202 No extension is currently defined. 1204 At most One extension may be run within a single EAP-PSK dialog: 1205 there can neither be sequences of extensions nor interleaved 1206 extensions. However, extensions may take a variable number of round 1207 trips to complete. 1209 Only the server can start an extension and, if it does so, it must 1210 start it in the first payload it sends over the protected channel. 1212 peer server 1213 | Flags||RAND_S||ID_S | 1214 |<---------------------------------------------------------| 1215 | | 1216 | Flags||RAND_S||RAND_P||MAC_P||ID_P | 1217 |--------------------------------------------------------->| 1218 | | 1219 | Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT) | 1220 |<---------------------------------------------------------| 1221 | | 1222 | Flags||RAND_S||PCHANNEL_P_1(EXT) | 1223 |--------------------------------------------------------->| 1224 | | 1225 . . 1226 . . 1227 . . 1228 | Flags||RAND_S||PCHANNEL_S_2i(EXT) | 1229 |<---------------------------------------------------------| 1230 | | 1231 | Flags||RAND_S||PCHANNEL_P_2i+1(EXT) | 1232 |--------------------------------------------------------->| 1233 | | 1235 Figure 10: EAP-PSK Extended Authentication 1237 Please refer to Section 6 for more details on how extended 1238 authentication works. 1240 The PCHANNEL_S_2j and PCHANNEL_P_2j+1 fields of the EAP-PSK messages 1241 (where j varies from 0 to i) contain a MAC computed thanks to TEK 1242 that protects the integrity of the messages. For a detailed list of 1243 the fields of the messages that are integrity protected please refer 1244 to Section 3.3. 1246 When a party receives an EAP-PSK message, it checks that the message 1247 is syntaxically valid in accordance with the message formats defined 1248 in Section 5. If the message is syntaxically incorrect, then it is 1249 silently discarded.Then it checks the cryptographic validity of this 1250 message, i.e. it checks the MAC(s), namely 1252 o If the received message is the first EAP-PSK message, there is no 1253 MAC to check as none is included in message 1. 1255 o If the received message is the second EAP-PSK message, the 1256 validity of MAC_P is checked. 1258 o If the received message is the third EAP-PSK message, the validity 1259 of MAC_S is checked and then the validity of the Tag included in 1260 P_CHANNEL_S_0 is checked. The validity checks must be done in 1261 this order to avoid unnecessarily deriving TEK, MSK and EMSK in 1262 case MAC_S is invalid, meaning that mutual authentication has 1263 failed. Indeed, TEK is used to verify the validity of the Tag 1264 included in P_CHANNEL_S_0. 1266 o If the received message is the fourth EAP-PSK message, the 1267 validity of the Tag included in P_CHANNEL_P_1 is checked. 1269 o If the received message is an EAP-PSK message different from the 1270 first four ones, then validity of the Tag included in P_CHANNEL is 1271 checked 1273 In case a validity check fails, the message is silently discarded. 1274 There can be a counter to track the number of silently discarded 1275 messages Section 8.8. In case, there is an encrypted payload in the 1276 message (namely in the PCHANNEL attribute), then the encrypted 1277 payload is decrypted. Then, if the decrypted payload is syntaxically 1278 incorrect then the message is silently discarded. 1280 5. EAP-PSK Message format 1282 For the sake of simplicity, EAP-PSK uses a fixed message format. 1283 There are four different types of EAP-PSK messages: 1285 o The first EAP-PSK message, which is sent by the server to the 1286 peer. 1288 o The second EAP-PSK message, which is sent by the peer to the 1289 server. 1291 o The third EAP-PSK message, which is sent by the server to the 1292 peer. 1294 o The fourth EAP-PSK message, which is sent by the peer to the 1295 server. This is also the type of the message that the peer 1296 further sends to the server in case of an extended authentication. 1297 This is also essentially the type of message that the server 1298 further sends to the peer in case of an extended authentication: 1299 the only slight modification that occurs in this last case is the 1300 setting of the EAP Code to 1 instead of 2 in the other cases. 1302 For the sake of clarity, the whole EAP packet that encapsulates the 1303 EAP-PSK message, i.e., the EAP-PSK message plus its EAP headers, are 1304 depicted in Figure 11, Figure 13, Figure 14 and Figure 18. 1306 5.1. EAP-PSK First Message 1308 The first EAP-PSK message is sent by the server to the peer. It has 1309 the format presented in Figure 11. 1311 0 1 2 3 1312 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 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Code=1 | Identifier | Length | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Type EAP-PSK | Flags | | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1318 | | 1319 + + 1320 | RAND_S | 1321 + + 1322 | | 1323 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | | | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1326 : : 1327 : ID_S : 1328 : : 1329 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 Figure 11: EAP-PSK First Message 1335 Since IANA has allocated EAP method type 47 for EAP-PSK, Type EAP-PSK 1336 for the first EAP-PSK message as well as any other EAP-PSK message 1337 MUST be 47 1339 The first EAP-PSK message consists of: 1341 o A 1-byte Flags field 1343 o A 16-byte random number: RAND_S 1345 o A variable length field that conveys the server's NAI: ID_S. The 1346 length of this field is deduced from the EAP length field. The 1347 length of this NAI must not exceed 966 bytes. This restriction 1348 aims at avoiding fragmentation issues (see Section 8.11). 1350 The Flags field has the format presented in Figure 12. 1352 0 1353 0 1 2 3 4 5 6 7 8 1354 +-+-+-+-+-+-+-+-+ 1355 | T | Reserved | 1356 +-+-+-+-+-+-+-+-+ 1357 Figure 12: EAP-PSK Flags Field 1359 The Flags field is comprised of two subfields: 1361 o A 2-bit T subfield which indicates the type of the EAP-PSK 1362 message: 1364 * T=0 for the first EAP-PSK message presented in Section 5.1. 1366 * T=1 for the second EAP-PSK message presented in Section 5.2. 1368 * T=2 for the third EAP-PSK message presented in Section 5.3. 1370 * T=3 for the fourth EAP-PSK message presented in Section 5.4 and 1371 the subsequent EAP-PSK messages that may be exchanged during 1372 extended authentication. 1374 o A 6-bit Reserved subfield that is set to zero on transmission and 1375 ignored on reception. 1377 The PCHANNEL Nonce field N (see Section 5.3) is used to distinguish 1378 between the different EAP-PSK messages that may be exchanged during 1379 extended authentication which all have T set to 3, i.e., the fourth 1380 EAP-PSK message and possibly the next ones. 1382 5.2. EAP-PSK Second Message 1384 The second EAP-PSK message is sent by the peer to the server. It has 1385 the format presented in Figure 13. 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Code=2 | Identifier | Length | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Type EAP-PSK | Flags | | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1394 | | 1395 + + 1396 | RAND_S | 1397 + + 1398 | | 1399 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | | | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1402 | | 1403 + + 1404 | RAND_P | 1405 + + 1406 | | 1407 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | | | 1409 +-+-+-+-+-+-+-+-+ + 1410 | | 1411 + + 1412 | MAC_P | 1413 + + 1414 | | 1415 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | | | 1417 +-+-+-+-+-+-+-+-+ + 1418 : ID_P : 1419 : : 1420 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 Figure 13: EAP-PSK Second Message 1426 It consists of: 1428 o A 1-byte Flags field 1430 o The 16-byte random number sent by the server in the first EAP-PSK 1431 message (RAND_S) that serves as a session identifier 1433 o A 16-byte random number: RAND_P 1434 o A 16-byte MAC: MAC_P 1436 o A variable length field that conveys the peer's NAI: ID_P. The 1437 length of this field is deduced from the EAP length field. The 1438 length of this NAI must not exceed 966 bytes. This restriction 1439 aims at avoiding fragmentation issues (see Section 8.11). 1441 The Flags field format is presented in Figure 12. 1443 5.3. EAP-PSK Third Message 1445 The third EAP-PSK message is sent by the server to the peer. It has 1446 the format presented in Figure 14. 1448 0 1 2 3 1449 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 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Code=1 | Identifier | Length | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Type EAP-PSK | Flags | | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1455 | | 1456 + + 1457 | RAND_S | 1458 + + 1459 | | 1460 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | | | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1463 | | 1464 + + 1465 | MAC_S | 1466 + + 1467 | | 1468 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | | | 1470 +-+-+-+-+-+-+-+-+ + 1471 : PCHANNEL : 1472 : : 1473 : : 1474 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 Figure 14: EAP-PSK Third Message 1480 It consists of: 1482 o A 1-byte Flags field 1484 o The 16-byte random number sent by the server in the first EAP-PSK 1485 message (RAND_S) that is used as a session identifier 1487 o A 16-byte MAC: MAC_S 1489 o A variable length field that constitutes the protected channel: 1490 PCHANNEL 1492 The Flags field format is presented in Figure 12. 1494 If there is no extension, i.e., if the authentication is standard, 1495 the PCHANNEL field consists of: 1497 o A 4-byte Nonce N (see Section 3.3). 1499 o A 16-byte Tag (see Section 3.3). 1501 o A 2-bit result indication flag R. 1503 o A 1-bit extension flag E, which is set to 0. 1505 o A 5-bit Reserved field, which is set to zero on emission and 1506 ignored on reception. 1508 R, E and Reserved are sent encrypted by the protected channel (see 1509 Section 3.3). 1511 If there is no extension, PCHANNEL has the format presented in 1512 Figure 15 (where R, E and Reserved are presented in the clear for the 1513 sake of clarity, although in reality they are sent encrypted). 1515 0 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Nonce | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | | 1521 + + 1522 | Tag | 1523 + + 1524 | | 1525 + + 1526 | | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | R |0| Reserved| 1529 +-+-+-+-+-+-+-+-+ 1531 Figure 15: The PCHANNEL Field with E=0 1533 If there is an extension, i.e., if the authentication is extended, 1534 the PCHANNEL field consists of: 1536 o A 4-byte Nonce N (see Section 3.3). 1538 o A 16-byte Tag (see Section 3.3). 1540 o A 2-bit result indication flag R. 1542 o A 1-bit extension flag E, which is set to 1. 1544 o A 5-bit Reserved field, which is set to zero on emission and 1545 ignored on reception. 1547 o A variable length EXT field. 1549 R, E, Reserved and EXT are sent encrypted by the protected channel 1550 (see Section 3.3). 1552 If there is an extension, PCHANNEL has the format presented in 1553 Figure 16 where R, E, Reserved and EXT are presented in the clear for 1554 the sake of clarity, although in reality they are sent encrypted).. 1556 0 1 2 3 1557 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 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Nonce | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | | 1562 + + 1563 | Tag | 1564 + + 1565 | | 1566 + + 1567 | | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | R |1| Reserved| | 1570 +-+-+-+-+-+-+-+-+ + 1571 : EXT : 1572 : : 1573 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 Figure 16: The PCHANNEL Field with E=1 1579 This EXT field is split in two subfields: 1581 o The EXT_Type subfield which indicates the type of the extension 1583 o The EXT_Payload subfield which consists in the payload of the 1584 extension. The EXT_Payload length is derived from the EAP Length 1585 field. EXT_Payload must have a bit-length that is a multiple of 8 1586 bits and must not exceed 960 bytes. The latter restriction aims 1587 at avoiding fragmentation issues (see Section 8.11) whereas the 1588 former comes from the EAP length being specified in bytes. 1590 The format of the EXT field is presented in Figure 17. 1592 0 1 2 3 1593 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 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | EXT_Type | | 1596 +-+-+-+-+-+-+-+-+ + 1597 : EXT_Payload : 1598 : : 1599 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 Figure 17: The EXT Field 1605 5.4. EAP-PSK Fourth Message 1607 The fourth EAP-PSK message is sent by the peer to the server. It has 1608 the format presented in Figure 18. 1610 0 1 2 3 1611 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 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Code=2 | Identifier | Length | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | Type EAP-PSK | Flags | | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1617 | | 1618 + + 1619 | RAND_S | 1620 + + 1621 | | 1622 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | | | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1625 : : 1626 : PCHANNEL : 1627 : : 1628 : : 1629 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 Figure 18: EAP-PSK Fourth Message 1635 It consists of: 1637 o A 1-byte Flags field 1639 o The 16-byte random number sent by the server in the first EAP-PSK 1640 message (RAND_S) that is used as a session identifier 1642 o A variable length field that constitutes the protected channel: 1643 PCHANNEL 1645 The Flags field format is presented in Figure 12. 1647 The PCHANNEL field has the following structure, which was already 1648 described in Section 5.3. 1650 If there is no extension, i.e., if the authentication is standard, 1651 the PCHANNEL field consists of: 1653 o A 4-byte Nonce N (see Section 3.3). 1655 o A 16-byte Tag (see Section 3.3). 1657 o A 2-bit result indication flag R. 1659 o A 1-bit extension flag E, which is set to 0. 1661 o A 5-bit Reserved field, which is set to zero on emission and 1662 ignored on reception. 1664 R, E and Reserved are sent encrypted by the protected channel (see 1665 Section 3.3). 1667 If there is no extension, PCHANNEL has the format presented in 1668 Figure 15. 1670 If there is an extension, i.e., if the authentication is extended, 1671 the PCHANNEL field consists of: 1673 o A 4-byte Nonce N (see Section 3.3). 1675 o A 16-byte Tag (see Section 3.3). 1677 o A 2-bit result indication flag R. 1679 o A 1-bit extension flag E, which is set to 1. 1681 o A 5-bit Reserved field, which is set to zero on emission and 1682 ignored on reception. 1684 o A variable length EXT field. 1686 R, E, Reserved and EXT are sent encrypted by the protected channel 1687 (see Section 3.3). 1689 If there is an extension, PCHANNEL has the format presented in 1690 Figure 16. 1692 This EXT field is split in two subfields: 1694 o The EXT_Type subfield which indicates the type of the extension 1696 o The EXT_Payload subfield which consists in the payload of the 1697 extension. The EXT_Payload length is derived from the EAP Length 1698 field. EXT_Payload must have a bit-length that is a multiple of 8 1699 bits and must not exceed 960 bytes. The latter restriction aims 1700 at avoiding fragmentation issues (see Section 8.11). 1702 The format of the EXT field is presented in Figure 17. 1704 6. Rules of Operation for the EAP-PSK Protected Channel 1706 In this section, the rules of operation of the EAP-PSK protected 1707 channel are presented: 1709 o How protected result indications are implemented. 1711 o How an extended authentication works in details. 1713 6.1. Protected Result Indications 1715 The R flag of the PCHANNEL field in the third and fourth type of EAP- 1716 PSK messages is used to provide result indications. 1718 Since this 2-bit flag is communicated over the protected channel, it 1719 is: 1721 o Encrypted so that only the peer and the server can know its value. 1723 o Integrity-protected so that it cannot be modified by an attacker 1724 without the peer or the server detecting this modification. 1726 o Protected against replays. 1728 This 2-bit R flag can take the following values: 1730 o 01 to mean CONT 1732 o 10 to mean DONE_SUCCESS 1734 o 11 to mean DONE_FAILURE 1736 The peer and the server each remember some information about both the 1737 values of R that they have sent and the values of R they have 1738 received. It is the conjunction of both sent and received R values 1739 that indicate the success or the failure of the EAP-PSK dialog. 1741 In case of a standard authentication, the following values of R 1742 should be exchanged: 1744 o Either the server sends a DONE_SUCCESS in the PCHANNEL of the 1745 third EAP-PSK message, to which the peer replies with a 1746 DONE_SUCCESS in the PCHANNEL of the fourth EAP-PSK message, which 1747 successfully ends the EAP-PSK dialog. 1749 o Or the server sends a DONE_FAILURE in the PCHANNEL of the third 1750 EAP-PSK message, to which the peer replies with a DONE_FAILURE in 1751 the PCHANNEL of the fourth EAP-PSK message, which unsuccessfully 1752 ends the EAP-PSK dialog. 1754 In case of an extended authentication, more complex exchanges may 1755 occur, which is why the CONT value was introduced. 1757 The rules of operation for each value R may take are presented in 1758 details hereafter. 1760 6.1.1. CONT 1762 The server and the peer each initialize the values of R they intend 1763 to send and receive as CONT. 1765 Here CONT stands for "Continue". It indicates that the EAP-PSK 1766 dialog is not yet successful and that the party sending it wants to 1767 continue the dialog to try and reach success. 1769 Indeed, although the peer and the server must have successfully 1770 authenticated each other, thanks to MAC_P and MAC_S, before they 1771 start communicating over the protected channel, the EAP-PSK dialog 1772 may not yet be deemed successful after this mutual authentication 1773 because of authorization issues. For instance, a prepaid customer of 1774 a wireless Hot-Spot might have successfully authenticated but has to 1775 refill its account, e.g., with a credit card transaction over the 1776 protected channel, before it is authorized. 1778 6.1.2. DONE_SUCCESS 1780 DONE_SUCCESS indicates that the party that sent it deems the EAP-PSK 1781 dialog successful and therefore proposes to end this dialog. 1783 Once the server has sent a DONE_SUCCESS, it must keep sending this 1784 value for R. 1786 The peer must first receive a DONE_SUCCESS from the server before it 1787 is allowed to send a DONE_SUCCESS. 1789 After the peer has received a DONE_SUCCESS from the server, it may: 1791 o Send a CONT to the server if it has not reached success on its 1792 side. The server that receives a CONT should continue the EAP-PSK 1793 dialog (see Section 8.2 for some discussion on the security 1794 implications of this should). 1796 o Send a DONE_SUCCESS to the server, which will end the EAP-PSK 1797 dialog with success. 1799 o Send a DONE_FAILURE to the server, which will end the EAP-PSK 1800 dialog with failure. 1802 6.1.3. DONE_FAILURE 1804 DONE_FAILURE indicates that the party that sent it deems the EAP-PSK 1805 dialog unsuccessful and proposes to end this dialog because nothing 1806 will make it change its mind. 1808 If the server is the first to send a DONE_FAILURE, then, the peer 1809 that receives this DONE_FAILURE must reply with a DONE_FAILURE and 1810 fail, which ends the EAP-PSK dialog. 1812 If the peer is the first to send a DONE_FAILURE, then, the server 1813 that receives this DONE_FAILURE must immediately end this EAP-PSK 1814 dialog without sending any further EAP-PSK message, and fail. 1816 6.2. Extended Authentication 1818 An extended authentication can only be started by the server. 1820 Exactly one extension (identified by the EXT_Type subfield of the EXT 1821 field) must be run during an EAP-PSK extended authentication dialog. 1823 The extension is run over the protected channel: it can assume 1824 confidentiality, integrity and replay protection. 1826 To start an extended authentication, the server sets the PCHANNEL E 1827 flag to 1 and includes the EXT_Payload of the extension it has 1828 chosen. 1830 Since EAP-PSK does not provide fragmentation, the extension must not 1831 send an EXT_Payload larger than 960 bytes, which corresponds to the 1832 1020-byte EAP MTU that may minimally be assumed (see [2]). 1834 Moreover, an extension must not send an empty EXT_Payload (because 1835 this has a particular meaning for EAP-PSK, see below). 1837 When the peer receives the third EAP-PSK message with the E flag set 1838 to 1, it checks whether it is able to process the proposed extension. 1840 If the peer is not able to process the proposed extension, i.e., it 1841 does not recognize the EXT_Type of the proposed extension, it sets 1842 E=1 in its reply (the fourth EAP-PSK message) and include an EXT 1843 field of the same EXT_Type but with an empty EXT_Payload. 1844 Depending on the values taken by the R flags, the EAP-PSK dialog may: 1846 o End 1848 * In case the peer's policy mandates that it fails in case of an 1849 unrecognized extension, it sends a DONE_FAILURE in the fourth 1850 EAP-PSK message. 1852 * In case the server has sent a DONE_SUCCESS in the third EAP-PSK 1853 message and the peer's policy authorizes it to succeed even if 1854 the extension is not recognized, the peer sends a DONE_SUCCESS. 1856 o Continue for exactly one round-trip, namely, in case the server 1857 has sent a CONT in the third EAP-PSK message and the peer's policy 1858 authorizes it to succeed even if the extension is not recognized, 1859 the peer replies with a CONT in the fourth EAP-PSK message. The 1860 server must then, depending on its policy, either send a 1861 DONE_SUCCESS or a DONE_FAILURE to the peer in the fifth EAP-PSK 1862 message. If the server sent a DONE_SUCCESS in the fifth EAP-PSK 1863 message, the peer must send a DONE_SUCCESS in the sixth EAP-PSK 1864 message. All these messages must have the E flag sent to 1 with 1865 an EXT field of with the EXT_Type of the extension that was 1866 proposed and an empty EXT_Payload (this behavior was chosen to 1867 simplify implementations). 1869 If the peer is able to process the proposed extension, then it does 1870 so. In this case, the extension must be aware of the R values sent 1871 and received and able to propose to update them. All the subsequent 1872 messages exchanged between the peer and the server must have the E 1873 flag sent to 1 with an EXT field of the EXT_Type of the extension 1874 that was proposed and a non-empty EXT_Payload. 1876 7. IANA considerations 1878 This section provides guidance to the IANA regarding registration of 1879 values related to the EAP-PSK protocol, in accordance with [5]. 1881 The following terms are used here with the meanings defined in [5]: 1882 "name space" and "registration". 1884 The following policies are used here with the meanings defined in 1885 [5]: "Expert Review" and "Specification Required". 1887 This document introduces one new Internet Assigned Numbers Authority 1888 (IANA) considerations: there is one name space in EAP-PSK that 1889 requires registration: the EXT_Type values (see Section 5.3 and 1890 Section 5.4). 1892 For registration requests where a Designated Expert should be 1893 consulted, the responsible IESG area director should appoint the 1894 Designated Expert. The intention is that any allocation will be 1895 accompanied by a published RFC. But in order to allow for the 1896 allocation of values prior to the RFC being approved for publication, 1897 the Designated Expert can approve allocations once it seems clear 1898 that an RFC will be published. The Designated expert will post a 1899 request to the EAP WG mailing list (or a successor designated by the 1900 Area Director) for comment and review, including an Internet-Draft. 1901 Before a period of 30 days has passed, the Designated Expert will 1902 either approve or deny the registration request and publish a notice 1903 of the decision to the EAP WG mailing list or its successor, as well 1904 as informing IANA. A denial notice must be justified by an 1905 explanation and, in the cases where it is possible, concrete 1906 suggestions on how the request can be modified so as to become 1907 acceptable. 1909 7.1. Allocation of an EAP-Request/Response Type for EAP-PSK 1911 This document requires IANA to allocate a new EAP Type for EAP-PSK. 1913 7.2. Allocation of EXT Type numbers 1915 EAP-PSK is not intended as a general-purpose protocol, and 1916 allocations of EXT_Type should not be made for purposes unrelated to 1917 authentication, authorization and accounting. 1919 EXT_Type numbers have a range from 1 to 255. 1921 EXT_Type 255 has been allocated for Experimental use. 1923 EXT_Type 1-254 may be allocated on the advice of a Designated Expert, 1924 with Specification Required. 1926 8. Security Considerations 1928 [2] highlights several attacks that are possible against EAP as EAP 1929 does not provide any robust security mechanism. 1931 This section discusses the claimed security properties of EAP-PSK as 1932 well as vulnerabilities and security recommendations in the threat 1933 model of [2]. 1935 8.1. Mutual Authentication 1937 EAP-PSK provides mutual authentication. 1939 The server believes that the peer is authentic because it can 1940 calculate a valid MAC and the peer believes that the server is 1941 authentic because it can calculate another valid MAC. 1943 The authentication protocol which inspired EAP-PSK, AKEP2, enjoys a 1944 security proof in the provable security paradigm, see [14]. 1946 The MAC algorithm used in the instantiation of AKEP2 within EAP-PSK, 1947 CMAC, also enjoys a security proof in the provable security paradigm, 1948 see [31]. A tag length of 16 bytes for CMAC is currently deemed 1949 appropriate by the cryptographic community for entity authentication. 1951 The underlying block cipher used, AES-128, is widely believed to be a 1952 secure block cipher. 1954 Finally, the key used for mutual authentication, AK, is only used for 1955 that purpose, which makes this part cryptographically independent of 1956 the other parts of the protocol. 1958 EAP-PSK provides mutual authentication if it is based on a pairwise 1959 PSK of sufficient strength. If the PSK is not pairwise or not 1960 sufficiently strong, then it does not provide authentication. In 1961 this way EAP-PSK is no different than other authentication protocols 1962 based on pre-shared keys. 1964 8.2. Protected Result Indications 1966 EAP-PSK provides protected result indications thanks to its 2-bit R 1967 flag (see Section 6.1). This 2-bit R flag is protected because it is 1968 encrypted and integrity protected by the EAX mode of operation, see 1969 Section 3.3. 1971 Care may be taken against Byzantine failures, that is to say, for 1972 instance, when a peer tries to force a server to engage in a never 1973 ending conversation. This could for example, be done by a peer that 1974 keeps sending a CONT after it has received a DONE_SUCCESS from the 1975 server. A policy may limit the number of rounds in an EAP-PSK 1976 extended authentication to mitigate this threat, which is outside our 1977 threat model. 1979 It should also be noted that the cryptographic protection of the 1980 result indications does not prevent message deletion. 1982 For instance, let us consider a scenario in which: 1984 o A server sends a DONE_SUCCESS to a peer. 1986 o The peer replies with a DONE_SUCCESS. 1988 In case the last message from the peer is intercepted, and an EAP 1989 Success is sent to the peer before any retransmission from the server 1990 reaches it or the retransmissions from the server are also deleted, 1991 the peer will believe that it has successfully authenticated to the 1992 server while the server will fail. 1994 This behavior is well known (see e.g., [25]) and in a sense 1995 unavoidable. There is a trade-off between efficiency and the "level" 1996 of information sharing that is attainable. EAP-PSK specified a 1997 single round trip of DONE_SUCCESS because, it is believed that: 1999 o In case there is an adversary capable of disrupting the 2000 communication channel, it can do so whenever it wants (be it after 2001 one or 10 round trip or even during data communication). 2003 o Other layers/applications will generally start by doing a specific 2004 key exchange and confirmation procedure using the keys derived by 2005 EAP-PSK. This is typically done by IEEE 802.11i "four-way 2006 handshake". In case the error is not detected by EAP- PSK, it 2007 should be detected then (please note however, that it is bad 2008 practice to rely on external mechanism to ensure synchronization, 2009 unless this is an explicit property of the external mechanism). 2011 8.3. Integrity Protection 2013 EAP-PSK provides integrity protection thanks to the Tag of its 2014 protected channel (see Section 3.3). 2016 EAP-PSK provides integrity protection if it is based on a pairwise 2017 PSK of sufficient strength. If the PSK is not pairwise or not 2018 sufficiently strong, then it does not provide authentication. In 2019 this way it is no different than other authentication protocols based 2020 on pre-shared keys. 2022 8.4. Replay Protection 2024 EAP-PSK provides replay protection of its mutual authentication part 2025 thanks to the use of random numbers RAND_S and RAND_P. Since RAND_S 2026 is 128 bit long, one expects to have to record 2**64 (i.e. 2027 approximately 1.84*10**19) EAP-PSK successful authentication before 2028 an authentication can be replayed. Hence, EAP-PSK provides replay 2029 protection of its mutual authentication part as long as RAND_S and 2030 RAND_P are chosen at random, randomness is critical for security. 2032 EAP-PSK provides replay protection during the conversation of the 2033 protected channel thanks to the Nonce N of its protected channel (see 2034 Section 3.3). This nonce is initialized to 0 by the server and 2035 monotonically incremented by one by the party that receives a valide 2036 EAP-PSK message. For instance, after receiving from the server a 2037 valid EAP-PSK message with Nonce set to x, the peer will answer with 2038 an EAP-PSK message with Nonce set to x+1 and wait for an EAP-PSK 2039 message with Nonce set to x+2. A retransmission of the server's 2040 message with Nonce set to x, would cause the peer EAP layer to resend 2041 the message in which Nonce was set to x+1, which would be transparent 2042 to the EAP-PSK layer. 2044 The EAP peer must check that the Nonce is indeed initialized to 0 by 2045 the server. 2047 8.5. Reflection attacks 2049 EAP-PSK provides protection against reflection attacks in case of an 2050 extended authentication because: 2052 o It integrity protects the EAP header (which contains the 2053 indication Request/Response. 2055 o It includes two separate spaces for the Nonces: the EAP server 2056 only receives messages with odd nonces, whereas the EAP peer only 2057 received messages with even nonces. 2059 8.6. Dictionary Attacks 2061 Because EAP-PSK is not a password protocol, it is not vulnerable to 2062 dictionary attacks. 2064 Indeed, the PSK used by EAP-PSK must not be derived from a password. 2065 Derivation of the PSK from a password may lead to dictionary attacks. 2067 However using a 16-byte PSK key has: 2069 o Ergonomic impacts: some people may find it cumbersome to manually 2070 provision a 16-byte PSK. 2072 o Deployment impacts: some people may want to reuse existing 2073 credential databases that contain passwords and not PSKs. 2075 Since, despite the warning not to use passwords, people will probably 2076 do that anyway, guidance to derive a PSK from a password is provided 2077 in Appendix A. The method proposed in Appendix A only tries to make 2078 dictionary attacks harder. It does not eliminate them. 2080 It is however not a fatality that passwords be used instead of PSKs: 2081 people rarely use password derived certificates, so why should they 2082 do so for shared keys? 2084 8.7. Key Derivation 2086 EAP-PSK supports key derivation. 2088 The key hierarchy is specified in Section 2.1. 2090 The mechanism used for key derivation is the modified counter mode. 2092 The instantiation of the modified counter in EAP-PSK complies with 2093 the conditions stated in [4] so that the security proof for this mode 2094 holds. 2096 The underlying block cipher used, AES-128, is widely believed to be a 2097 secure block cipher. 2099 A first key derivation occurs to calculate AK and KDK from the PSK: 2100 it is called the key setup (see Section 3.1). 2101 It uses the PSK as the key to the modified counter mode. Thus, AK 2102 and KDK are believed to be cryptographically separated and computable 2103 only to those who have knowledge of the PSK. 2105 A second key derivation occurs to derive session keys, namely, the 2106 TEK, MSK and EMSK (see Section 3.2). 2107 It uses KDK as the key to the modified counter mode. 2109 The protocol design explicitly assumes that neither AK nor KDK are 2110 shared beyond the two parties utilizing them. AK loses its efficacy 2111 to mutually authenticate the peer and server with each other when it 2112 is shared. Similarly, the derived TEK, MSK, and EMSK lose their 2113 value when KDK is shared with a third party. 2115 It should be emphasized that the peer has control of the session keys 2116 derived by EAP-PSK. In particular, it can easily choose the random 2117 number it sends in EAP-PSK so that one of the nine derived 16-byte 2118 key blocks (see Section 2.1) takes a pre-specified value. 2120 It was chosen not to prevent this control of the session keys by the 2121 peer because: 2123 o Preventing it would have added some complexity to the protocol 2124 (typically, the inclusion of a one-way mode of operation of AES in 2125 the key derivation part). 2127 o It is believed that the peer won't try to force the server to use 2128 some pre- specified value for the session keys. Such an attack is 2129 outside the threat model and seems to have little value compared 2130 to a peer sharing its PSK. 2132 This is however not the behavior recommended by EAP in section 7.10 2133 of [2]. 2135 Since deriving the session keys requires some cryptographic 2136 computations, it is recommended that the session keys be derived only 2137 once authentication has succeeded (i.e., once the server has 2138 successfully verified MAC_P for the server side, and once the peer 2139 has successfully verified MAC_S for the peer side). 2141 It is recommended to take great care in implementations, so that 2142 derived keys are not made available if the EAP-PSK dialog fails, 2143 e.g., ends with DONE_FAILURE. 2145 The TEK must not be made available to anyone except to the current 2146 EAP-PSK dialog. 2148 8.8. Denial of Service Resistance 2150 Denial of Service resistance (DoS) has not been a design goal for 2151 EAP-PSK. 2153 It is however believed that EAP-PSK does not provide any obvious and 2154 avoidable venue for such attacks. 2156 It is worth noting that the server has to do a cryptographic 2157 calculation and maintain some state when it engages in an EAP-PSK 2158 conversation, namely generate and remember the 16-byte RAND_S. This 2159 should however not lead to resource exhaustion as this state and the 2160 associated computation are fairly lightweight. 2162 Please note that both the peer and the server must commit to their 2163 RAND_S and RAND_P to protect their partners from flooding attacks. 2165 It is recommended that EAP-PSK does not allow EAP notifications to be 2166 interleaved in its dialog to prevent potential DoS attacks. Indeed, 2167 since EAP Notifications are not integrity protected, they can easily 2168 be spoofed by an attacker. Such an attacker could force a peer that 2169 allows EAP Notifications to engage in a discussion which would delay 2170 his authentication or result in the peer taking unexpected actions 2171 (e.g., in case a notification is used to prompt the peer to do some 2172 "bad" action). 2174 It is up to the implementation of EAP-PSK or to the peer and the 2175 server to specify the maximum number of failed cryptographic checks 2176 that are allowed. For instance, does the reception of a bogus MAC_P 2177 in the second EAP-PSK message cause a fatal error or is it discarded 2178 to continue waiting for the valid response of the valid peer? There 2179 is a trade-off between possibly allowing multiple tentative forgeries 2180 and allowing a direct DoS (in case the first error is fatal). 2182 For the sake of simplicity and denial of service resilience, EAP-PSK 2183 has chosen not to include any error messages. Hence, an "invalid" 2184 EAP-PSK message is silently discarded. Although this makes 2185 interoperability testing and debugging harder, this leads to simpler 2186 implementations and does not open any venue for denial of service 2187 attacks. 2189 8.9. Session Independence 2191 Thanks to its key derivation mechanisms, EAP-PSK provides session 2192 independence: passive attacks (such as capture of the EAP 2193 conversation) or active attacks (including compromise of the MSK or 2194 EMSK) does not enable compromise of subsequent or prior MSKs or 2195 EMSKs. The assumption that RAND_P and RAND_S are random is central 2196 for the security of EAP-PSK in general and session independance in 2197 particular. 2199 8.10. Exposition of the PSK 2201 EAP-PSK does not provide perfect forward secrecy. Compromise of the 2202 PSK leads to compromise of recorded past sessions. 2204 Compromise of the PSK enables the attacker to impersonate the peer 2205 and the server: compromise of the PSK leads to "full" compromise of 2206 future sessions. 2208 EAP-PSK provides no protection against a legitimate peer sharing its 2209 PSK with a third party. Such protection may be provided by 2210 appropriate repositories for the PSK, which choice is outside the 2211 scope of this document. The PSK used by EAP-PSK must only be shared 2212 between two parties: the peer and the server. In particular, this 2213 PSK must not be shared by a group of peers communicating with the 2214 same server. 2216 The PSK used by EAP-PSK must be cryptographically separated from keys 2217 used by other protocols, otherwise the security of EAP-PSK may be 2218 compromised. It is a rule of the thumb in cryptography to use 2219 different keys for different applications. 2221 8.11. Fragmentation 2223 EAP-PSK does not support fragmentation and reassembly. 2225 Indeed, the largest EAP-PSK frame is at most 1015 bytes long, 2226 because: 2228 o The maximum length for the peer NAI identity used in EAP- PSK is 2229 966 bytes (see Section 5.2). This should not be a limitation in 2230 practice (see Section 2.2 of [9] for more considerations on NAI 2231 length). 2233 o The maximum length for the EXT_Payload field used in EAP-PSK is 2234 960 bytes (see Section 5.3 and Section 5.4). 2236 Per Section 3.1 of [2], the lower layers over which EAP may be run 2237 are assumed to have an EAP MTU of 1020 bytes or greater. Since the 2238 EAP header is 5 bytes long, supporting fragmentation for EAP-PSK is 2239 unnecessary. 2241 Extensions that require sending a payload larger than 960 bytes 2242 should provide their own fragmentation and reassembly mechanism. 2244 8.12. Channel Binding 2246 EAP-PSK does not provide channel binding as this feature is still 2247 very much work in progress (see [13]). 2249 However, it should be easy to add it to EAP-PSK as an extension (see 2250 Section 4.2). 2252 8.13. Fast Reconnect 2254 EAP-PSK does not provide any fast reconnect capability. 2256 Indeed, as noted for instance in [15], mutual authentication (without 2257 counters or timestamps) requires three exchanges, thus four exchanges 2258 in EAP since any EAP-Request must be answered to by an EAP-Response. 2260 Since this minimum bound is already reached in EAP-PSK standard 2261 authentication, there is no way the number of round-trips used within 2262 EAP-PSK can be reduced without using timestamps or counters. 2263 Timestamps and counters were deliberately avoided for the sake of 2264 simplicity and security (e.g., synchronization issues). 2266 8.14. Identity Protection 2268 Since it was chosen to restrict to a single cryptographic primitive 2269 from symmetric cryptography, namely the block cipher AES-128, it 2270 appears that it is not possible to provide "reasonable" identity 2271 protection without failing to meet the simplicity goal. 2273 Hereafter is an informal discussion of what is meant by identity 2274 protection and the rationale behind the requirement of identity 2275 protection. For some complementary discussion, refer to [40]. 2277 Identity protection basically means preventing the disclosure of the 2278 identities of the communicating parties over the network, which is 2279 quite contradictory with authentication. There are two levels of 2280 identity protection: protection against passive attackers and 2281 protection against active eavesdroppers. 2283 As explained in [40], "a common example [for identity protection] is 2284 the case of mobile devices wishing to prevent an attacker from 2285 correlating their (changing) location with the logical identity of 2286 the device (or user)". 2288 In case only symmetric cryptography is used, only a weak form of 2289 identity protection may be offered, namely pseudonym management. In 2290 other words, the peer and the server agree on pseudonyms that they 2291 use to identify each other and usually change them periodically, 2292 possibly in a protected way so that an attacker cannot learn new 2293 pseudonyms before they are used. 2295 With pseudonym management, there is a trade-off between allowing for 2296 pseudonym resynchronization (thanks to a permanent identity) and 2297 being vulnerable to active attacks (in which the attacker forges 2298 messages simulating a pseudonym desynchronization). 2299 Indeed, a protocol using time-varying pseudonyms may want to 2300 anticipate "desynchronization" situations such as, for instance, when 2301 the peer believes that its current pseudonym is "pseudo1@bigco.com" 2302 whereas the server believes this peer will use the pseudonym 2303 "pseudo2@bigco.com" (which is the pseudonym the server has sent to 2304 update "pseudo1@bigco.com"). 2306 Because pseudonym management adds complexity to the protocol and 2307 implies this unsatisfactory trade-off, it was decided not to include 2308 this feature in EAP-PSK. 2310 However, EAP-PSK may trivially provide some protection when the 2311 concern is to avoid the "real-life" identity of the user being 2312 "discovered". For instance, let us take the example of user John Doe 2313 that roams and connects to a Hot-Spot owned and operated by Wireless 2314 Internet Service Provider (WISP) BAD. Suppose this user 2315 authenticates to his home WISP (WISP GOOD) with an EAP method under 2316 an identity (e.g., "john.doe@wispgood.com") that allows WISP BAD (or 2317 an attacker) to recover his "real-life" identity, i.e. John Doe. An 2318 example drawback of this, is that a competitor of John Doe's WISP may 2319 want to win John Doe as a new customer by sending him some special 2320 targeted advertisement. 2321 EAP-PSK can very simply thwart this attack, merely by avoiding to 2322 provide John Doe with a NAI that allows easy recovery of his real- 2323 life identity. It is believed that, when a NAI that is not 2324 correlated to a real-life identity, is used, no valuable information 2325 leaks because of the EAP method. 2326 Indeed, the identity of the WISP used by a peer has to be disclosed 2327 anyway in the realm portion of its NAI to allow AAA routing. 2328 Moreover, the Medium Access Control Address of the peer's Network 2329 Interface Card can generally be used to track the peer as efficiently 2330 as a fixed NAI. 2332 It is worth noting that the server systematically discloses its 2333 identity, which may allow probing attacks. This may not be a problem 2334 as the identity of the server is not supposed to remain secret. 2335 Quite on the contrary, users tend to want to know to whom they will 2336 be talking to choose the right network to attach to. 2338 8.15. Protected Ciphersuite Negotiation 2340 EAP-PSK does not allow to negotiate cipher suites. Hence, it is not 2341 vulnerable to negotiation attacks and does not implement protected 2342 cipher suite negotiation. 2344 8.16. Confidentiality 2346 Although EAP-PSK provides confidentiality in its protected channel, 2347 it cannot claim to do so as per Section 7.2.1 of [2]: "A method 2348 making this claim must support identity protection". 2350 8.17. Cryptographic Binding 2352 Since EAP-PSK is not intended to be tunneled within another protocol 2353 that omits peer authentication, it does not implement cryptographic 2354 binding. 2356 8.18. Implementation of EAP-PSK 2358 To really provide security, not only must a protocol be well-thought 2359 and correctly specified, but its implementation must take special 2360 care. 2362 For instance, implementing cryptographic algorithms requires special 2363 skills since cryptographic software is not only vulnerable to 2364 classical attacks (e.g., buffer overflow or missing checks) but also 2365 to some special cryptographic attacks (e.g., side channels attacks 2366 like timing ones, see [39]). In particular, care must be taken to 2367 avoid such attacks in EAX implementation, please refer to [3] for a 2368 note on this point. 2370 An EAP-PSK implementation should use a good source of randomness to 2371 generate the random numbers required in the protocol. Please refer 2372 to [21] for more information on generating random numbers for 2373 security applications. 2375 Handling sensitive material (namely, keying material such as the PSK, 2376 AK, KDK, etc.) should be done so in a secure way (see, for instance, 2377 [19] for guidance on secure deletion). 2379 The specification of a repository for the PSK that EAP-PSK uses is 2380 outside of the scope of this document. In particular, nothing 2381 prevents from storing this PSK on a tamper-resistant device such as a 2382 smart card rather than having it memorized or written down on a sheet 2383 of paper. The choice of the PSK repository may have important 2384 security impacts. 2386 9. Security Claims 2388 This section provides the security claims required by [2]. 2390 [a] Mechanism. EAP-PSK is based on symmetric cryptography (AES-128) 2391 and uses a 16-byte Pre-Shared Key (PSK). 2393 [b] Security claims. EAP-PSK provides: 2395 * Mutual authentication (see Section 8.1) 2397 * Integrity protection (see Section 8.3) 2399 * Replay protection (see Section 8.4) 2401 * Key derivation (see Section 8.7) 2403 * Dictionary attack resistance (see Section 8.6) 2405 * Session independence (see section Section 8.6) 2407 [c] Key strength. EAP-PSK provides a 16-byte effective key strength. 2409 [d] Description of key hierarchy. Please see Section 2.1. 2411 [e] Indication of vulnerabilities. EAP-PSK does not provide: 2413 * Identity protection (see Section 8.14) 2415 * Confidentiality (see Section 8.16) 2417 * Fast reconnect (see Section 8.13) 2419 * Fragmentation (see Section 8.11) 2421 * Cryptographic binding (see Section 8.17) 2423 * Protected cipher suite negotiation (see Section 8.15) 2425 * Perfect Forward Secrecy (see Section 8.7) 2427 * Key agreement: the session key is chosen by the peer (see 2428 Section 8.7) 2430 * Channel binding (see Section 8.12) 2432 10. Acknowledgments 2434 This EAP method has been inspired by EAP-Archie and EAP-SIM. Many 2435 thanks to their respective authors: Jesse Walker (Extra thanks to 2436 Jesse Walker for his thorough and challenging expert review of EAP- 2437 PSK), Russ Housley, Henry Haverinen and Joseph Salowey. 2439 Thanks to 2441 o Henri Gilbert for some interesting discussions on the 2442 cryptographic parts of EAP-PSK. 2444 o Aurelien Magniez for his valuable feedback on network aspects of 2445 EAP-PSK, his curiosity and rigor that led to numerous 2446 improvements, and his help in the first implementation of EAP-PSK 2447 under Microsoft Windows and Freeradius. 2449 o Thomas Otto for his valuable feedback on EAP-PSK and the 2450 implementation of the first version of EAP-PSK under Xsupplicant. 2452 o Nancy Cam-Winget for some exchanges on EAP-PSK 2454 o Jari Arkko and Bernard Aboba, the beloved EAP WG chairs, for the 2455 work they stimulate. 2457 Finally, thanks to Vir Z. who has brought a permanent and outstanding 2458 though discrete contribution to this protocol. 2460 11. References 2462 11.1. Normative References 2464 [1] Aboba, B. and M. Beadles, "The Network Access Identifier", 2465 RFC 2486, January 1999. 2467 [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2468 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 2469 June 2004. 2471 [3] Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of 2472 operation", FSE 04, Springer-Verlag LNCS 3017, 2004. 2474 [4] Gilbert, H., "The Security of One-Block-to-Many Modes of 2475 Operation", FSE 03, Springer-Verlag LNCS 2287, 2003. 2477 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2478 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2480 [6] National Institute of Standards and Technology, "Specification 2481 for the Advanced Encryption Standard (AES)", Federal Information 2482 Processing Standards (FIPS) 197, November 2001. 2484 [7] National Institute of Standards and Technology, "Recommendation 2485 for Block Cipher Modes of Operation: The CMAC Mode for 2486 Authentication", Special Publication (SP) 800-38B, May 2005. 2488 11.2. Informative References 2490 [8] Aboba, B., "Extensible Authentication Protocol (EAP) Key 2491 Management Framework", draft-ietf-eap-keying-13 (work in 2492 progress), May 2006. 2494 [9] Aboba, B., "The Network Access Identifier", 2495 draft-arkko-roamops-rfc2486bis-02 (work in progress), 2496 July 2004. 2498 [10] B.Aboba, P.Calhoun, S.Glass, T.Hiller, P.McCann, H.Shiino, 2499 G.Zorn, G.Dommety, C.Perkins, B.Patil, D.Mitton, S.Manning, 2500 M.Beadles, P.Walsh, X.Chen, S.Sivalingham, A.Hameed, M.Munson, 2501 S.Jacobs, B.Lim, B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, 2502 and E.Jaques, "Criteria for Evaluating AAA Protocols for 2503 Network Access", RFC 2989, November 2000. 2505 [11] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 2506 RFC 2716, October 1999. 2508 [12] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol 2509 Method for 3rd Generation Authentication and Key Agreement 2510 (EAP-AKA)", draft-arkko-pppext-eap-aka-15 (work in progress), 2511 December 2004. 2513 [13] Arkko, J. and P. Eronen, "Authenticated Service Information for 2514 the Extensible Authentication Protocol (EAP)", 2515 draft-arkko-eap-service-identity-auth-04 (work in progress), 2516 October 2005. 2518 [14] Bellare, M. and P. Rogaway, "Entity Authentication and Key 2519 Distribution", CRYPTO 93, Springer-Verlag LNCS 773, 1994. 2521 [15] Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated 2522 Key Exchange Secure Against Dictionary attacks", 2523 EUROCRYPT 00, Springer-Verlag LNCS 1807, 2000. 2525 [16] Bersani, F., "EAP shared key methods: a tentative synthesis of 2526 those proposed so far", 2527 draft-bersani-eap-synthesis-sharedkeymethods-00 (work in 2528 progress), April 2004. 2530 [17] Bradner, S., "The Internet Standards Process -- Revision 3", 2531 BCP 9, RFC 2026, October 1996. 2533 [18] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 2534 Authentication Protocol", draft-ietf-pppext-eap-srp-03.txt 2535 (work in progress), July 2001. 2537 [19] Department of Defense of the United States, "National 2538 Industrial Security Program Operating Manual", DoD 5220-22M, 2539 January 1995. 2541 [20] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2542 RFC 2246, January 1999. 2544 [21] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 2545 Recommendations for Security", RFC 1750, December 1994. 2547 [22] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication 2548 Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-05 (work in 2549 progress), July 2004. 2551 [23] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time 2552 Password System", RFC 2289, February 1998. 2554 [24] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2555 RFC 2409, November 1998. 2557 [25] Halpern, J. and Y. Moses, "Knowledge and common knowledge in 2558 a distributed environment", Journal of the ACM 37:3, 1990. 2560 [26] Haverinen, H. and J. Salowey, "Extensible Authentication 2561 Protocol Method for GSM Subscriber Identity Modules (EAP- 2562 SIM)", draft-haverinen-pppext-eap-sim-16 (work in progress), 2563 December 2004. 2565 [27] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are 2566 Standards", RFC 1796, April 1995. 2568 [28] Institute of Electrical and Electronics Engineers, "Local and 2569 Metropolitan Area Networks: Port-Based Network Access Control", 2570 IEEE Standard 802.1X, September 2001. 2572 [29] Institute of Electrical and Electronics Engineers, "Approved 2573 Draft Supplement to Standard for Telecommunications and 2574 Information Exchange Between Systems-LAN/MAN Specific 2575 Requirements - Part 11: Wireless LAN Medium Access Control 2576 (MAC) and Physical Layer (PHY) Specifications: Specification 2577 for Enhanced Security", IEEE 802.11i-2004, 2004. 2579 [30] Institute of Electrical and Electronics Engineers, "Standard 2580 for Telecommunications and Information Exchange Between Systems 2581 - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium 2582 Access Control (MAC) and Physical Layer (PHY) Specifications", 2583 IEEE Standard 802.11, 1999. 2585 [31] Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC", FSE 03, 2586 Springer-Verlag LNCS 2887, 2003. 2588 [32] Jablon, D., "The SPEKE Password-Based Key Agreement Methods", 2589 draft-jablon-speke-02 (work in progress), November 2002. 2591 [33] Josefsson, S., "The EAP SecurID(r) Mechanism", 2592 draft-josefsson-eap-securid-01 (work in progress), 2593 February 2002. 2595 [34] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected 2596 EAP Protocol (PEAP) Version 2", 2597 draft-josefsson-pppext-eap-tls-eap-10 (work in progress), 2598 October 2004. 2600 [35] Kaliski, B., "PKCS #5: Password-Based Cryptography 2601 Specification Version 2.0", RFC 2898, September 2000. 2603 [36] Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions", 2604 draft-kamath-pppext-eap-mschapv2-01 (work in progress), 2605 April 2004. 2607 [37] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2608 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 2610 [38] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 2611 November 1998. 2613 [39] Kocher, P., "Timing Attacks on Implementations of Diffie- 2614 Hellman, RSA, DSS, and Other Systems", CRYPTO 96, Springer- 2615 Verlag LNCS 1109, 1996. 2617 [40] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to 2618 Authenticated Diffie-Hellman and its Use in the IKE Protocols", 2619 CRYPTO 03, Springer-Verlag LNCS 2729, June 2003. 2621 [41] MacNally, C., "Cisco LEAP protocol description", 2622 September 2001. 2624 [42] Metz, C., "OTP Extended Responses", RFC 2243, November 1997. 2626 [43] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of 2627 Applied Cryptography", CRC Press , 1996. 2629 [44] National Institute of Standards and Technology, "Password 2630 Usage", Federal Information Processing Standards (FIPS) 112, 2631 May 1985. 2633 [45] Rescorla, E., "A Survey of Authentication Mechanisms", 2634 draft-iab-auth-mech-05 (work in progress), February 2006. 2636 [46] Salowey, J., "The Flexible Authentication via Secure Tunneling 2637 Extensible Authentication Protocol Method (EAP-FAST)", 2638 draft-cam-winget-eap-fast-03 (work in progress), October 2005. 2640 [47] Schneier, B., Mudge, and D. Wagner, "Cryptanalysis of 2641 Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", 2642 CQRE 99, Springer-Verlag LNCS 1740, October 1999. 2644 [48] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2645 RFC 1661, July 1994. 2647 [49] Simpson, W., "PPP Challenge Handshake Authentication Protocol 2648 (CHAP)", RFC 1994, August 1996. 2650 [50] Stanley, D., Walker, J., and B. Aboba, "EAP Method Requirements 2651 for Wireless LANs", draft-walker-ieee802-req-04 (work in 2652 progress), August 2004. 2654 [51] Tschofenig, H., "EAP IKEv2 Method", 2655 draft-tschofenig-eap-ikev2-10 (work in progress), 2656 February 2006. 2658 [52] Walker, J. and R. Housley, "The EAP Archie Protocol", 2659 draft-jwalker-eap-archie-01 (work in progress), June 2003. 2661 [53] Wi-Fi Alliance, "Wi-Fi Protected Access, version 2.0", 2662 April 2003. 2664 [54] Wright, J., "Weaknesses in LEAP Challenge/Response", Defcon 03, 2665 August 2003. 2667 [55] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 2668 Transport Layer Security (TLS)", draft-ietf-tls-psk-09 (work in 2669 progress), June 2005. 2671 Appendix A. Generation of the PSK from a password - Discouraged 2673 It is formally discouraged to use a password to generate the PSK, 2674 since this opens the door to exhaustive search or dictionary, two 2675 attacks that would not otherwise be possible. 2677 EAP-PSK only provides a 16-byte key strength when a 16-byte PSK is 2678 drawn at random from the set of all possible 16-byte strings. 2680 However, as people will probably do this anyway, guidance is provided 2681 hereafter to generate the PSK from a password. 2683 For some hints on how passwords should be selected, please refer to 2684 [44]. 2686 The technique presented herein is drawn from [35]. It is intended to 2687 try to mitigate the risks associated with password usage in 2688 cryptography, typically dictionary attacks. 2690 If the binary representation of the password is strictly fewer than 2691 16 bytes long (which by the way means that the chosen password is 2692 probably weak because it is too short), then it is padded to 16 bytes 2693 with zeroes as its high order bits. 2695 If the binary representation of the password is strictly more than 16 2696 bytes long, then it is hashed down to exactly 16 bytes using the 2697 Matyas-Meyer-Oseas hash (please refer to [43] for a description of 2698 this hash. Using the notation of Figure 9.3 of [43], g is the 2699 identity function and E is AES-128 in our construction.) with 2700 IV=0x0123456789ABCDEFFEDCBA9876543210 (this value has been 2701 arbitrarily selected). 2703 We now assume that we have a 16-byte number derived from the initial 2704 password (that can be the password itself if its binary 2705 representation is exactly 16 bytes long). We shall call this number 2706 P16. 2708 Following the notations used in [35], the PSK is derived thanks to 2709 PBKDF2 instantiated with: 2711 o P16 as P 2713 o The first 96 bits of the XOR of the peer and server NAIs as Salt 2714 (zero-padded in the high-order bits if necessary). 2716 o 5000 as c 2717 o 16 as dkLen 2719 Although this gives better protection than nothing, this derivation 2720 does not stricto sensu protect against dictionary attacks. It only 2721 makes dictionary precomputation harder. 2723 Authors' Addresses 2725 Florent Bersani 2726 France Telecom R&D 2727 38, rue du General Leclerc 2728 Issy-Les-Moulineaux 92794 Cedex 9 2729 FR 2731 Email: bersani_florent@yahoo.fr 2733 Hannes Tschofenig 2734 Siemens AG 2735 Otto-Hahn-Ring 6 2736 Munich 81739 2737 GE 2739 Email: Hannes.Tschofenig@siemens.com 2741 Intellectual Property Statement 2743 The IETF takes no position regarding the validity or scope of any 2744 Intellectual Property Rights or other rights that might be claimed to 2745 pertain to the implementation or use of the technology described in 2746 this document or the extent to which any license under such rights 2747 might or might not be available; nor does it represent that it has 2748 made any independent effort to identify any such rights. Information 2749 on the procedures with respect to rights in RFC documents can be 2750 found in BCP 78 and BCP 79. 2752 Copies of IPR disclosures made to the IETF Secretariat and any 2753 assurances of licenses to be made available, or the result of an 2754 attempt made to obtain a general license or permission for the use of 2755 such proprietary rights by implementers or users of this 2756 specification can be obtained from the IETF on-line IPR repository at 2757 http://www.ietf.org/ipr. 2759 The IETF invites any interested party to bring to its attention any 2760 copyrights, patents or patent applications, or other proprietary 2761 rights that may cover technology that may be required to implement 2762 this standard. Please address the information to the IETF at 2763 ietf-ipr@ietf.org. 2765 Disclaimer of Validity 2767 This document and the information contained herein are provided on an 2768 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2769 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2770 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2771 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2772 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2773 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2775 Copyright Statement 2777 Copyright (C) The Internet Society (2006). This document is subject 2778 to the rights, licenses and restrictions contained in BCP 78, and 2779 except as set forth therein, the authors retain all their rights. 2781 Acknowledgment 2783 Funding for the RFC Editor function is currently provided by the 2784 Internet Society.