idnits 2.17.1 draft-ietf-emu-eap-gpsk-05.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, updated by RFC 4748 on line 1443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1467. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (April 5, 2007) is 6223 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-18 -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU Working Group T. Clancy 3 Internet-Draft LTS 4 Intended status: Standards Track H. Tschofenig 5 Expires: October 7, 2007 Nokia Siemens Networks 6 April 5, 2007 8 EAP Generalized Pre-Shared Key (EAP-GPSK) 9 draft-ietf-emu-eap-gpsk-05 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 October 7, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This Internet Draft defines an Extensible Authentication Protocol 43 method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method 44 is a lightweight shared-key authentication protocol supporting mutual 45 authentication and key derivation. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 57 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12 60 6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 12 61 6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12 62 6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 12 63 6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13 64 6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 13 65 6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13 66 6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13 67 6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14 69 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 14 71 7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15 72 7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 15 73 7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 20 74 7.4.1. Protected Results Indication . . . . . . . . . . . . . 23 76 8. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 23 78 9. Example Message Exchanges . . . . . . . . . . . . . . . . . . 24 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 81 10.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 27 82 10.2. Protected Result Indications . . . . . . . . . . . . . . 28 83 10.3. Integrity Protection . . . . . . . . . . . . . . . . . . 28 84 10.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 28 85 10.5. Reflection attacks . . . . . . . . . . . . . . . . . . . 28 86 10.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 28 87 10.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . 28 88 10.8. Denial of Service Resistance . . . . . . . . . . . . . . 28 89 10.9. Session Independence . . . . . . . . . . . . . . . . . . 29 90 10.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 29 91 10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 30 92 10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30 93 10.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 30 94 10.14. Identity Protection . . . . . . . . . . . . . . . . . . . 30 95 10.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 30 96 10.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30 97 10.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 30 99 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 101 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 105 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 107 14.2. Informative References . . . . . . . . . . . . . . . . . 33 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 110 Intellectual Property and Copyright Statements . . . . . . . . . . 34 112 1. Introduction 114 EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a 115 generalized pre-shared key authentication technique. Mutual 116 authentication is achieved through a nonce-based exchange that is 117 secured by a pre-shared key. 119 EAP-GPSK addresses a large number of design goals with the intention 120 of being applicable in a broad range of usage scenarios. 122 The main design goals of EAP-GPSK are 124 Simplicity: 126 EAP-GPSK should be easy to implement. 128 Security Model: 130 EAP-GPSK has been designed in a threat model where the attacker 131 has full control over the communication channel. This is the EAP 132 threat model that is presented in Section 7.1 of [RFC3748]. 134 Efficiency: 136 EAP-GPSK does not make use of public key cryptography and fully 137 relies of symmetric cryptography. The restriction on symmetric 138 cryptographic computations allows for low computational overhead. 139 Hence, EAP-GPSK is lightweight and well suited for any type of 140 device, especially those with processing power, memory and battery 141 constraints. Additionally it seeks to minimize the number of 142 round trips. 144 Flexibility: 146 EAP-GPSK offers cryptographic flexibility. At the beginning, the 147 EAP server selects a set of cryptographic algorithms and key 148 sizes, a so called ciphersuite. The current version of EAP-GPSK 149 comprises two ciphersuites, but additional ones can be easily 150 added. 152 Extensibility: 154 The design of EAP-GPSK allows to securely exchange information 155 between the EAP peer and the EAP server using protected data 156 fields. These fields might, for example, be used to exchange 157 channel binding information or to provide support for identity 158 confidentiality. 160 2. Terminology 162 In this document, several words are used to signify the requirements 163 of the specification. These words are often capitalized. The key 164 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 165 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 166 are to be interpreted as described in [RFC2119]. 168 This section describes the various variables and functions used in 169 the EAP-GPSK method. 171 Variables: 173 CSuite_List: An octet array listing available ciphersuites (variable 174 length) 176 CSuite_Sel: Ciphersuite selected by the peer (6 octets) 178 ID_Peer: Peer NAI [RFC4282] 180 ID_Server: Server identity as an opaque blob. 182 KS: Integer representing the key size in octets of the selected 183 ciphersuite CSuite_Sel. The key size is one of the ciphersuite 184 parameters. 186 PD_Payload: Data carried within the protected data payload 188 PD_Payload_Block: Block of possibly multiple PD_Payloads carried by 189 a GPSK packet 191 PL: Integer representing the length of the PSK in octets (2 octets) 193 RAND_Peer: Random integer generated by the peer (32 octets) 195 RAND_Server: Random integer generated by the server (32 octets) 197 Operations: 199 A || B: Concatenation of octet strings A and B 201 ENC_X(Y): Encryption of message Y with a symmetric key X, using a 202 defined block cipher 204 KDF_X(Y): Key Derivation Function that generates an arbitrary number 205 of octets of output using secret X and seed Y 207 length(X): Function that returns the length of input X in octets, 208 encoded as a 2-octet integer in network byte order 210 MAC_X(Y): Keyed message authentication code computed over Y with 211 symmetric key X 213 SEC_X(Y): SEC is a function that provides integrity protection based 214 on the chosen ciphersuite. The function SEC uses the algorithm 215 defined by the selected ciphersuite and applies it to the message 216 content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y). 218 X[A..B]: Notation representing octets A through B of octet array X 220 The following abbreviations are used for the keying material: 222 EMSK: Extended Master Session Key is exported by the EAP method (64 223 octets) 225 MK: Master Key between the peer and EAP server from which all other 226 EAP method session keys are derived (KS octets) 228 MSK: Master Session Key exported by the EAP method (64 octets) 230 PK: Session key generated from the MK and used during protocol 231 exchange to encrypt protected data (KS octets) 233 PSK: Long-term key shared between the peer and the server (PL 234 octets) 236 SK: Session key generated from the MK and used during protocol 237 exchange to demonstrate knowledge of the PSK (KS octets) 239 3. Overview 241 The EAP framework (see Section 1.3 of [RFC3748]) defines three basic 242 steps that occur during the execution of an EAP conversation between 243 the EAP peer, the Authenticator and the EAP server. 245 1. The first phase, discovery, is handled by the underlying 246 protocol. 248 2. The EAP authentication phase with EAP-GPSK is defined in this 249 document. 250 3. The secure association distribution and secure association phases 251 are handled differently depending on the underlying protocol. 253 EAP-GPSK performs mutual authentication between EAP peer ("Peer") and 254 EAP server ("Server") based on a pre-shared key (PSK). The protocol 255 consists of four message exchanges (GPSK-1, ..., GPSK-4), in which 256 both sides exchange nonces and their identities, compute and exchange 257 a Message Authentication Code (MAC) over the previously exchanged 258 values, keyed with the pre-shared key. This MAC is considered as 259 proof of possession of the pre-shared key. 261 A successful protocol exchange is shown in Figure 1. 263 +--------+ +--------+ 264 | | EAP-Request/Identity | | 265 | EAP |<------------------------------------| EAP | 266 | peer | | server | 267 | | EAP-Response/Identity | | 268 | |------------------------------------>| | 269 | | | | 270 | | EAP-Request/GPSK-1 | | 271 | |<------------------------------------| | 272 | | | | 273 | | EAP-Response/GPSK-2 | | 274 | |------------------------------------>| | 275 | | | | 276 | | EAP-Request/GPSK-3 | | 277 | |<------------------------------------| | 278 | | | | 279 | | EAP-Response/GPSK-4 | | 280 | |------------------------------------>| | 281 | | | | 282 | | EAP-Success | | 283 | |<------------------------------------| | 284 +--------+ +--------+ 286 Figure 1: EAP-GPSK: Successful Exchange 288 The full EAP-GPSK protocol is as follows: 289 GPSK-1: 291 ID_Server, RAND_Server, CSuite_List 293 GPSK-2: 295 SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List, 296 CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] ) 298 GPSK-3 300 SEC_SK(RAND_Peer, RAND_Server, CSuite_Sel, [ 301 ENC_PK(PD_Payload_Block) ] ) 303 GPSK-4: 305 SEC_SK( [ ENC_PK(PD_Payload_Block) ] ) 307 The EAP server begins EAP-GPSK by selecting a random number 308 RAND_Server and by encoding the supported ciphersuites into 309 CSuite_List. A ciphersuite consists of an encryption algorithm, a 310 key derivation function and a message authentication code. 312 In GPSK-1, the EAP server sends its identity ID_Server, a random 313 number RAND_Server and a list of supported ciphersuites CSuite_List. 314 The decision which ciphersuite to offer and which ciphersuite to pick 315 is policy- and implementation-dependent and therefore outside the 316 scope of this document. 318 In GPSK-2, the peer sends its identity ID_Peer and a random number 319 RAND_Peer. Furthermore, it repeats the received parameters of the 320 GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected 321 ciphersuite. It computes a Message Authentication Code over all the 322 transmitted parameters. 324 The EAP server verifies the received Message Authentication Code. In 325 case of successful verification, the EAP server computes a Message 326 Authentication Code over the session parameter and returns it to the 327 peer (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP server 328 have the possibility to exchange encrypted protected data parameters. 330 The peer verifies the received Message Authentication Code. If the 331 verification is successful, GPSK-4 is prepared. This message can 332 optionally contain the peer's protected data parameters. 334 Upon receipt of GPSK-4, the server processes any included 335 PD_Payload_Block. Then, the EAP server sends an EAP Success message 336 to indicate the successful outcome of the authentication. 338 4. Key Derivation 340 EAP-GPSK provides key derivation in compliance to the requirements of 341 [RFC3748] and [I-D.ietf-eap-keying]. Note that this section provides 342 an abstract description for the key derivation procedure that needs 343 to be instantiated with a specific ciphersuite. 345 The long-term credential shared between EAP peer and EAP server 346 SHOULD be a strong pre-shared key PSK of at least 16 octets, though 347 its length and entropy is variable. While it is possible to use a 348 password or passphrase, doing so is NOT RECOMMENDED as it would make 349 EAP-GPSK vulnerable to dictionary attacks. 351 During an EAP-GPSK authentication, a Master Key MK, a Session Key SK 352 and a Protected Data Encryption Key PK (if using an encrypting 353 ciphersuite) are derived using the ciphersuite-specified KDF and data 354 exchanged during the execution of the protocol, namely 'RAND_Peer || 355 ID_Peer || RAND_Server || ID_Server' referred as inputString as its 356 short-hand form. 358 In case of successful completion, EAP-GPSK derives and exports an MSK 359 and EMSK both in length of 64 octets. 361 The following notation is used: KDF-X(Y, Z)[A..B], whereby 362 X is the length, in octets, of the desired output, 363 Y is a secret key, 364 Z is the inputString, 365 [A..B] extracts the string of octets starting with octet A finishing 366 with octet B from the output of the KDF function. 368 This keying material is derived using the ciphersuite-specified KDF 369 as follows: 371 o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 372 o MK = KDF-KS(0x00, PL || PSK || CSuite_Sel || inputString)[0..KS-1] 373 o MSK = KDF-{128+2*KS}(MK, inputString)[0..63] 374 o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127] 375 o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS] 376 o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using 377 an encrypting ciphersuite) 379 Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires 380 the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. 381 These values are defined as: 383 o Method-ID = KDF-16(0x00, "Method ID" || EAP_Method_Type || 384 CSuite_Sel || inputString)[0..15] 386 o Session-ID = Type_Code || Method_ID 387 o Peer-ID = ID_Peer 388 o Server-ID = ID_Server 390 EAP_Method_Type refers to the integer value of the IANA allocated EAP 391 Type code. 393 Figure 2 depicts the key derivation procedure of EAP-GPSK. 395 +-------------+ +-------------------------------+ 396 | PL-octet | | RAND_Peer || ID_Peer || | 397 | PSK | | RAND_Server || ID_Server | 398 +-------------+ +-------------------------------+ 399 | | | 400 | +------------+ | | 401 | | CSuite_Sel | | | 402 | +------------+ | | 403 | | | | 404 v v v | 405 +--------------------------------------------+ | 406 | KDF | | 407 +--------------------------------------------+ | 408 | | 409 v | 410 +-------------+ | 411 | KS-octet | | 412 | MK | | 413 +-------------+ | 414 | | 415 v v 416 +---------------------------------------------------+ 417 | KDF | 418 +---------------------------------------------------+ 419 | | | | 420 v v v v 421 +---------+ +---------+ +----------+ +----------+ 422 | 64-octet| | 64-octet| | KS-octet | | KS-octet | 423 | MSK | | EMSK | | SK | | PK | 424 +---------+ +---------+ +----------+ +----------+ 426 Figure 2: EAP-GPSK Key Derivation 428 5. Ciphersuites 430 The design of EAP-GPSK allows cryptographic algorithms and key sizes, 431 called ciphersuites, to be negotiated during the protocol run. The 432 ability to specify block-based and hash-based ciphersuites is 433 offered. Extensibility is provided with the introduction of new 434 ciphersuites; this document specifies an initial set. The CSuite/ 435 Specifier column in Figure 3 uniquely identifies a ciphersuite. 437 For a vendor-specific ciphersuite the first three octets are the 438 vendor-specific OID, and the last three octets are vendor assigned 439 for the specific ciphersuite. 441 The following ciphersuites are specified in this document: 443 +-----------+----+-------------+--------------+----------------+ 444 | CSuite/ | KS | Encryption | Integrity / | Key Derivation | 445 | Specifier | | | KDF MAC | Function | 446 +-----------+----+-------------+--------------+----------------+ 447 | 0x000001 | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF | 448 +-----------+----+-------------+--------------+----------------+ 449 | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF | 450 +-----------+----+-------------+--------------+----------------+ 452 Figure 3: Ciphersuites 454 Ciphersuite 1, which is based on AES as a cryptographic primitive, is 455 mandatory to implement. This document specifies also a second 456 ciphersuite, but its support is optional. 458 Each ciphersuite needs to specify a key derivation function. The 459 ciphersuites defined in this document make use of the Generalized Key 460 Distribution Function (GKDF) which utilizes the MAC function defined 461 in the ciphersuite. Future ciphersuites can use any other formally 462 specified KDF that takes as arguments a key and a seed value, and 463 produces at least 128+2*KS octets of output. 465 GKDF has the following structure: 467 GKDF-X(Y, Z) 469 X length, in octets, of the desired output 470 Y secret key 471 Z inputString 472 GKDF-X (Y, Z) { 473 n = ceiling integer of ( X / KS ); 474 /* determine number of output blocks */ 476 M_0 = ""; 477 result = ""; 479 for i = 1 to n { 480 M_i = MAC_Y (i || Z); 481 result = result || M_i; 482 } 484 return truncate (result) 485 } 487 Note that the variable 'i' in M_i is represented as a 2-octet value 488 in network byte order. 490 6. Ciphersuites Processing Rules 492 6.1. Ciphersuite #1 494 6.1.1. Encryption 496 With this ciphersuite all cryptography is built around a single 497 cryptographic primitive, AES-128. Within the protected data frames, 498 AES-128 is used in Cipher Block Chaining (CBC) mode of operation (see 499 [CBC]). This EAP method uses encryption in a single payload, in the 500 protected data payload (see Section 7.4). 502 In a nutshell, the CBC mode proceeds as follows. The IV is XORed 503 with the first plaintext block before it is encrypted. Then for 504 successive blocks, the previous ciphertext block is XORed with the 505 current plaintext, before it is encrypted. 507 6.1.2. Integrity 509 Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is 510 recommended by NIST. Among its advantages, CMAC is capable to work 511 with messages of arbitrary length. A detailed description of CMAC 512 can be found in [CMAC]. 514 The following instantiation is used: AES-128-CMAC(SK, Input) denotes 515 the MAC of Input under the key SK. 517 where Input refers to the following content: 519 o Value of SEC_SK(Value) in message GPSK-2 520 o Value of SEC_SK(Value) in message GPSK-3 521 o Value of SEC_SK(Value) in message GPSK-4 523 6.1.3. Key Derivation 525 This ciphersuite instantiates the KDF in the following way: 527 inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 529 MK = GKDF-32 (0x00, PL || PSK || CSuite_Sel || inputString) 531 MSK = GKDF-160 (MK, inputString)[0..63] 533 EMSK = GKDF-160 (MK, inputString)[64..127] 535 SK = GKDF-160 (MK, inputString)[128..143] 537 PK = GKDF-160 (MK, inputString)[144..159] 539 Method-ID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || 540 CSuite_Sel || inputString) 542 6.2. Ciphersuite #2 544 6.2.1. Encryption 546 Ciphersuite 2 does not include an algorithm for encryption. With a 547 NULL encryption algorithm, encryption is defined as: 549 E_X(Y) = Y 551 When using this ciphersuite, the data exchanged inside the protected 552 data block is not encrypted. Therefore this mode MUST NOT be used if 553 confidential information appears inside the protected data block. 555 6.2.2. Integrity 557 Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash 558 algorithm (see [RFC4634]). 560 For integrity protection the following instantiation is used: 562 HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK 563 where Input refers to the following content: 565 o Value of SEC_SK(Value) in message GPSK-2 566 o Value of SEC_SK(Value) in message GPSK-3 567 o Value of SEC_SK(Value) in message GPSK-4 569 6.2.3. Key Derivation 571 This ciphersuite instantiates the KDF in the following way: 573 inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 575 MK = GKDF-32 (0x00, PL || PSK || CSuite_Sel || inputString) 577 MSK = GKDF-160 (MK, inputString)[0..63] 579 EMSK = GKDF-160 (MK, inputString)[64..127] 581 SK = GKDF-160 (MK, inputString)[128..159] 583 Method-ID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || 584 CSuite_Sel || inputString) 586 7. Packet Formats 588 This section defines the packet format of the EAP-GPSK messages. 590 7.1. Header Format 592 The EAP-GPSK header has the following structure: 594 --- bit offset ---> 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Code | Identifier | Length | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Type | OP-Code | | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 602 | | 603 ... Payload ... 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 5 609 The Code, Identifier, Length, and Type fields are all part of the EAP 610 header, and defined in [RFC3748]. IANA has allocated EAP Method Type 611 XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX. 613 The OP-Code field is one of four values: 615 o 0x01 : GPSK-1 616 o 0x02 : GPSK-2 617 o 0x03 : GPSK-3 618 o 0x04 : GPSK-4 619 o 0x05 : GPSK-Fail 620 o 0x06 : GPSK-Protected-Fail 622 7.2. Ciphersuite Formatting 624 Ciphersuites are encoded as 6-octet arrays. The first three octets 625 indicate the CSuite/Vendor field. For vendor-specific ciphersuites, 626 this represents the vendor OID. The last three octets indicate the 627 CSuite/Specifier field, which identifies the particular ciphersuite. 628 The 3-octet CSuite/Vendor value 0x000000 indicates ciphersuites 629 allocated by the IETF. 631 Graphically, they are represented as 633 --- bit offset ---> 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | CSuite/Vendor = 0x000000 or OID | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 CSuite / Specifier | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 6 644 CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and 645 CSuite/Specifier pair. 647 CSuite_List is a variable-length octet array of ciphersuites. It is 648 encoded by concatenating encoded ciphersuite values. Its length in 649 octets MUST be a multiple of 6. 651 7.3. Payload Formatting 653 Payload formatting is based on the protocol exchange description in 654 Section 3. 656 The GPSK-1 payload format is defined as follows: 658 --- bit offset ---> 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | length(ID_Server) | | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 664 | | 665 ... ID_Server ... 666 | | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | 669 ... 32-octet RAND_Server ... 670 | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | length(CSuite_List) | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 674 | | 675 ... CSuite_List ... 676 | | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Figure 7: GPSK-1 Payload 681 The GPSK-2 payload format is defined as follows: 683 --- bit offset ---> 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | length(ID_Peer) | | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 689 | | 690 ... ID_Peer ... 691 | | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | length(ID_Server) | | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 695 | | 696 ... ID_Server ... 697 | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | | 700 ... 32-octet RAND_Peer ... 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | | 704 ... 32-octet RAND_Server ... 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | length(CSuite_List) | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 709 | | 710 ... CSuite_List ... 711 | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | CSuite_Sel | 714 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | | length(PD_Payload_Block) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | | 718 ... optional PD_Payload_Block ... 719 | | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | | 722 ... KS-octet payload MAC ... 723 | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Figure 8: GPSK-2 Payload 728 If the optional protected data payload is not included, then 729 length(PD_Payload_Block)=0 and the PD payload is excluded. 731 The GPSK-3 payload is defined as follows: 733 --- bit offset ---> 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | | 738 ... 32-octet RAND_Peer ... 739 | | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | | 742 ... 32-octet RAND_Server ... 743 | | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | CSuite_Sel | 746 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | | length(PD_Payload_Block) | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | | 750 ... optional PD_Payload_Block ... 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 ... KS-octet payload MAC ... 755 | | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Figure 9: GPSK-3 Payload 760 If the optional protected data payload is not included, then 761 length(PD_Payload_Block)=0 and the PD payload is excluded. 763 The GPSK-4 payload format is defined as follows: 765 --- bit offset ---> 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | length(PD_Payload_Block) | | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 771 | | 772 ... optional PD_Payload_Block ... 773 | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | | 776 ... KS-octet payload MAC ... 777 | | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Figure 10: GPSK-4 Payload 782 If the optional protected data payload is not included, then 783 length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC 784 MUST always be included, regardless of the presence of 785 PD_Payload_Block. 787 The GPSK-Fail payload format is defined as follows: 789 --- bit offset ---> 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Failure-Code | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Figure 11: GPSK-Fail Payload 798 The GPSK-Protected-Fail payload format is defined as follows: 800 --- bit offset ---> 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Failure-Code | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | | 807 ... KS-octet payload MAC ... 808 | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Figure 12: GPSK-Protected-Fail Payload 812 The Failure-Code field is one of three values, but can be extended: 814 o 0x00000001: PSK Not Found 815 o 0x00000002: Authentication Failure 816 o 0x00000003: Authorization Failure 817 o 0x00000004 through 0xFFFFFFFF : Unallocated 819 "PSK Not Found" indicates a key for a particular user could not be 820 located, making authentication impossible. "Authentication Failure" 821 indicates a MAC failure due to a PSK mismatch. "Authorization 822 Failure" indicates that while the PSK being used is correct, the user 823 is not authorized to connect. 825 7.4. Protected Data 827 The protected data blocks are a generic mechanism for the peer and 828 server to securely exchange data. If the specified ciphersuite has a 829 NULL encryption primitive, then this channel only offers 830 authenticity, and not confidentiality. 832 These payloads are encoded as the concatenation of type-length-value 833 (TLV) triples called PD_Payloads. 835 Type values are encoded as a 6-octet string and represented by a 836 3-octet vendor and 3-octet specifier field. The vendor field 837 indicates the type as either standards-specified or vendor-specific. 838 If these three octets are 0x000000, then the value is standards- 839 specified, and any other value represents a vendor-specific OID. 841 The specifier field indicates the actual type. For vendor field 842 0x000000, the specifier field is maintained by IANA. For any other 843 vendor field, the specifier field is maintained by the vendor. 845 Length fields are specified as 2-octet integers in network byte 846 order, and reflect only the length of the value, and do not include 847 the length of the type and length fields. 849 Graphically, this can be depicted as follows: 851 --- bit offset ---> 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | PData/Vendor | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 PData/Specifier | PData/Length | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | | 860 ... PData/Value ... 861 | | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Protected Data Payload (PD_Payload) Formatting 866 These PD_Payloads are concatenated together to form a 867 PD_Payload_Block. The If the CSuite_Sel includes support for 868 encryption, then the PD_Payload_Block includes fields specifying an 869 initialization vector (IV), and the necessary padding. This can be 870 depicted as follows: 872 --- bit offset ---> 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Initialization Vector | 877 ... (length is block size for encryption algorithm) ... 878 | | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | | 881 ... PD_Payload ... 882 | | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | | 885 ... optional PD_Payload, etc ... 886 | | 887 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | | Padding (0-255 octets) | 889 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 890 | | Pad Length | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Protected Data Block (PD_Payload_Block) Formatting if Encryption 894 Supported 896 The Initialization Vector is a randomly chosen value whose length is 897 equal to the block length of the underlying encryption algorithm. 899 Recipients MUST accept any value. Senders SHOULD either pick this 900 value pseudo-randomly and independently for each message or use the 901 final ciphertext block of the previous message sent. Senders MUST 902 NOT use the same value for each message, use a sequence of values 903 with low hamming distance (e.g., a sequence number), or use 904 ciphertext from a received message. 906 The concatenation of PD_Payloads along with the padding and padding 907 length are all encrypted using the negotiated block cipher. If no 908 block cipher is specified, then these fields are not encrypted. 910 The Padding field MAY contain any value chosen by the sender, and 911 MUST have a length that makes the combination of the concatenation of 912 PD_Payloads, the Padding, and the Pad Length to be a multiple of the 913 encryption block size. 915 The Pad Length field is the length of the Padding field. The sender 916 SHOULD set the Pad Length to the minimum value that makes the 917 combination of the PD_Payloads, the Padding, and the Pad Length a 918 multiple of the block size, but the recipient MUST accept any length 919 that results in proper alignment. This field is encrypted with the 920 negotiated cipher. 922 If the negotiated ciphersuite does not support encryption, then the 923 padding field MUST be of length zero. The padding length field MUST 924 still be present, and contain the value zero. This is depicted in 925 the following figure. 927 --- bit offset ---> 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | | 932 ... PD_Payload ... 933 | | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | | 936 ... optional PD_Payload, etc +-+-+-+-+-+-+-+-+ 937 | | 0x00 | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 Protected Data Block (PD_Payload_Block) Formatting Without Encryption 942 For PData/Vendor field 0x000000, the following PData/Specifier fields 943 are defined: 945 o 0x000000 : Reserved 946 o 0x000001 : Protected Results Indication 947 o 0x000002 through 0xFFFFFF : Unallocated 949 7.4.1. Protected Results Indication 951 Based on the PData/Specifier allocation the following 8-bit payload 952 is specified to be placed in the PD_Payload Value to provide the 953 functionality of protected results indication. 955 0 956 0 1 2 3 4 5 6 7 957 +-+-+-+-+-+-+-+-+ 958 |I|R|R|R|R|R|R|R| 959 +-+-+-+-+-+-+-+-+ 961 I: Result Indicator 963 The bits have the following meaning: 965 (0): Success 966 (1): Failure 968 R: Reserved 969 These bits are used for padding. 971 The 8 bits of protected results indication functionality MUST only be 972 sent in GPSK-3 from the EAP server to the EAP peer. 974 8. Packet Processing Rules 976 This section defines how the EAP peer and EAP server MUST behave when 977 received packet is deemed invalid. 979 Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP 980 server MUST be silently discarded. An EAP peer or EAP server 981 receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 982 before receiving GPSK-1 or before transmitting GPSK-2) MUST silently 983 discard the packet. 985 GPSK-1 contains no MAC protection, so provided it properly parses, it 986 MUST be accepted by the peer. Note that the ciphersuite list 987 provided by the EAP server in CSuite_List MUST always include the 988 mandatory-to-implement ciphersuite defined in this document. Hence, 989 there is always at least one ciphersuite in common between the EAP 990 peer and the EAP server. If the EAP peer decides the ID_Server is 991 that of a AAA server to which it does not wish to authenticate, the 992 EAP peer should respond with an EAP-NAK. 994 For GPSK-2, if ID_Peer is for an unknown user, the EAP server MUST 995 send either a "PSK Not Found" GPSK-Fail message, or an 996 "Authentication Failure" GPSK-Fail, depending on its policy, and 997 discard the received packet. If the MAC validation fails, the server 998 MUST transmit a GPSK-Fail message specifying "Authentication Failure" 999 and discard the received packet. If the RAND_Server or CSuite_List 1000 field in GPSK-2 does not match the values in GPSK-1, the server MUST 1001 silently discard the packet. If server policy determines the peer is 1002 not authorized and the MAC is correct, the server MUST transmit a 1003 GPSK-Protected-Fail message indicating "Authorization Failure" and 1004 discard the received packet. 1006 A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in 1007 response to a GPSK-2 message MUST replay the received GPSK-Fail / 1008 GPSK-Protected-Fail message. Then, the EAP server returns an EAP- 1009 Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message 1010 to correctly finish the EAP conversation. If MAC validation on a 1011 GPSK-Protected-Fail packet fails, then the received packet MUST be 1012 silently discarded. 1014 For GPSK-3, a peer MUST silently discard messages where the 1015 RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those 1016 transmitted in GPSK-2. An EAP peer MUST silently discard any packet 1017 whose MAC fails. 1019 For GPSK-4, a server MUST silently discard any packet whose MAC fails 1020 validation. 1022 If a decryption failure of a protected payload is detected, the 1023 recipient MUST silently discard the GPSK packet. 1025 9. Example Message Exchanges 1027 This section shows a couple of example message flows. 1029 A successful EAP-GPSK message exchange is shown in Figure 1. 1031 +--------+ +--------+ 1032 | | EAP-Request/Identity | | 1033 | EAP |<------------------------------------| EAP | 1034 | peer | | server | 1035 | | EAP-Response/Identity | | 1036 | |------------------------------------>| | 1037 | | | | 1038 | | EAP-Request/GPSK-1 | | 1039 | |<------------------------------------| | 1040 | | | | 1041 | | EAP-Response/EAP-NAK | | 1042 | |------------------------------------>| | 1043 | | | | 1044 | | EAP-Failure | | 1045 | |<------------------------------------| | 1046 +--------+ +--------+ 1048 EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity; 1049 ID_Server) 1051 +--------+ +--------+ 1052 | | EAP-Request/Identity | | 1053 | EAP |<------------------------------------| EAP | 1054 | peer | | server | 1055 | | EAP-Response/Identity | | 1056 | |------------------------------------>| | 1057 | | | | 1058 | | EAP-Request/GPSK-1 | | 1059 | |<------------------------------------| | 1060 | | | | 1061 | | EAP-Response/GPSK-2 | | 1062 | |------------------------------------>| | 1063 | | | | 1064 | | EAP-Request/GPSK-3 (GPSK-Fail | | 1065 | | (PSK Not Found or AuthenFail) | | 1066 | |<------------------------------------| | 1067 | | | | 1068 | | EAP-Response/GPSK-4 (GPSK-Fail) | | 1069 | | (PSK Not Found or AuthenFail) | | 1070 | |------------------------------------>| | 1071 | | | | 1072 | | EAP-Failure | | 1073 | |<------------------------------------| | 1074 +--------+ +--------+ 1076 EAP-GPSK: Unsuccessful Exchange (Unknown user) 1078 +--------+ +--------+ 1079 | | EAP-Request/Identity | | 1080 | EAP |<------------------------------------| EAP | 1081 | peer | | server | 1082 | | EAP-Response/Identity | | 1083 | |------------------------------------>| | 1084 | | | | 1085 | | EAP-Request/GPSK-1 | | 1086 | |<------------------------------------| | 1087 | | | | 1088 | | EAP-Response/GPSK-2 | | 1089 | |------------------------------------>| | 1090 | | | | 1091 | | EAP-Request/GPSK-3 (GPSK-Fail | | 1092 | | (AuthenFail) | | 1093 | |<------------------------------------| | 1094 | | | | 1095 | | EAP-Response/GPSK-4 (GPSK-Fail) | | 1096 | | (AuthenFail) | | 1097 | |------------------------------------>| | 1098 | | | | 1099 | | EAP-Failure | | 1100 | |<------------------------------------| | 1101 +--------+ +--------+ 1103 EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2) 1105 +--------+ +--------+ 1106 | | EAP-Request/Identity | | 1107 | EAP |<------------------------------------| EAP | 1108 | peer | | server | 1109 | | EAP-Response/Identity | | 1110 | |------------------------------------>| | 1111 | | | | 1112 | | EAP-Request/GPSK-1 | | 1113 | |<------------------------------------| | 1114 | | | | 1115 | | EAP-Response/GPSK-2 | | 1116 | |------------------------------------>| | 1117 | | | | 1118 | | EAP-Request/GPSK-3 | | 1119 | | GPSK-Protected-Fail | | 1120 | | (Authorization Failure) | | 1121 | |<------------------------------------| | 1122 | | | | 1123 | | EAP-Request/GPSK-4 | | 1124 | | GPSK-Protected-Fail | | 1125 | | (Authorization Failure) | | 1126 | |------------------------------------>| | 1127 | | | | 1128 | | EAP-Failure | | 1129 | |<------------------------------------| | 1130 +--------+ +--------+ 1132 EAP-GPSK: Unsuccessful Exchange (Authorization failure) 1134 10. Security Considerations 1136 [RFC3748] highlights several attacks that are possible against EAP 1137 since EAP itself does not provide any security. 1139 This section discusses the claimed security properties of EAP-GPSK as 1140 well as vulnerabilities and security recommendations in the threat 1141 model of [RFC3748]. 1143 10.1. Mutual Authentication 1145 EAP-GPSK provides mutual authentication. 1147 The server believes that the peer is authentic because it can 1148 calculate a valid MAC and the peer believes that the server is 1149 authentic because it can calculate another valid MAC. 1151 The key used for mutual authentication is computed again based on the 1152 long-term secret PSK that has to provide sufficient entropy and 1153 therefore sufficient strength. In this way EAP-GPSK is no different 1154 than other authentication protocols based on pre-shared keys. 1156 10.2. Protected Result Indications 1158 EAP-GPSK offers the capability to exchange protected result 1159 indications using the protected data payloads. 1161 10.3. Integrity Protection 1163 EAP-GPSK provides integrity protection based on the ciphersuites 1164 suggested in this document. 1166 10.4. Replay Protection 1168 EAP-GPSK provides replay protection of its mutual authentication part 1169 thanks to the use of random numbers RAND_Server and RAND_Peer. Since 1170 RAND_Server is 32 octets long, one expects to have to record 2**64 1171 (i.e., approximately 1.84*10**19) EAP-GPSK successful authentication 1172 before an protocol run can be replayed. Hence, EAP-GPSK provides 1173 replay protection of its mutual authentication part as long as 1174 RAND_Server and RAND_Peer are chosen at random, randomness is 1175 critical for replay protection. 1177 10.5. Reflection attacks 1179 EAP-GPSK provides protection against reflection attacks in case of an 1180 extended authentication because the messages are constructed in a 1181 different fashion. 1183 10.6. Dictionary Attacks 1185 EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based 1186 on at least 16 octets of entropy to guarantee security against 1187 dictionary attacks. Users who use passwords are not guaranteed 1188 security against dictionary attacks. Derivation of the long-term 1189 shared secret from a password is strongly discouraged. 1191 10.7. Key Derivation 1193 EAP-GPSK supports key derivation as shown in Section 4. 1195 10.8. Denial of Service Resistance 1197 Denial of Service (DoS) resistance has not been a design goal for 1198 EAP-GPSK. 1200 It is however believed that EAP-GPSK does not provide any obvious and 1201 avoidable venue for such attacks. 1203 It is worth noting that the server has to maintain some state when it 1204 engages in an EAP-GPSK conversation, namely to generate and to 1205 remember the 32-octet RAND_Server. This should however not lead to 1206 resource exhaustion as this state and the associated computation are 1207 fairly lightweight. 1209 It is recommended that EAP-GPSK does not allow EAP notifications to 1210 be interleaved in its dialog to prevent potential DoS attacks. 1211 Indeed, since EAP Notifications are not integrity protected, they can 1212 easily be spoofed by an attacker. Such an attacker could force a 1213 peer that allows EAP Notifications to engage in a discussion which 1214 would delay his authentication or result in the peer taking 1215 unexpected actions (e.g., in case a notification is used to prompt 1216 the peer to do some "bad" action). 1218 It is up to the implementation of EAP-GPSK or to the peer and the 1219 server to specify the maximum number of failed cryptographic checks 1220 that are allowed. 1222 10.9. Session Independence 1224 Thanks to its key derivation mechanisms, EAP-GPSK provides session 1225 independence: passive attacks (such as capture of the EAP 1226 conversation) or active attacks (including compromise of the MSK or 1227 EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. 1228 The assumption that RAND_Peer and RAND_Server are random is central 1229 for the security of EAP-GPSK in general and session independence in 1230 particular. 1232 10.10. Exposition of the PSK 1234 EAP-GPSK does not provide perfect forward secrecy. Compromise of the 1235 PSK leads to compromise of recorded past sessions. 1237 Compromise of the PSK enables the attacker to impersonate the peer 1238 and the server and it allows the adversary to compromise future 1239 sessions. 1241 EAP-GPSK provides no protection against a legitimate peer sharing its 1242 PSK with a third party. Such protection may be provided by 1243 appropriate repositories for the PSK, which choice is outside the 1244 scope of this document. The PSK used by EAP-GPSK must only be shared 1245 between two parties: the peer and the server. In particular, this 1246 PSK must not be shared by a group of peers communicating with the 1247 same server. 1249 The PSK used by EAP-GPSK must be cryptographically separated from 1250 keys used by other protocols, otherwise the security of EAP-GPSK may 1251 be compromised. 1253 10.11. Fragmentation 1255 EAP-GPSK does not support fragmentation and reassembly since the 1256 message size is small. 1258 10.12. Channel Binding 1260 This document enables the ability to exchange channel binding 1261 information. It does not, however, define the encoding of channel 1262 binding information in the document. 1264 10.13. Fast Reconnect 1266 EAP-GPSK does not provide the fast reconnect capability since this 1267 method is already at (or close to) the lower limit of the number of 1268 roundtrips and the cryptographic operations. 1270 10.14. Identity Protection 1272 Identity protection is not specified in this document. Extensions 1273 can be defined that enhance this protocol to provide this feature. 1275 10.15. Protected Ciphersuite Negotiation 1277 EAP-GPSK provides protected ciphersuite negotiation via the 1278 indication of available ciphersuites by the server in the first 1279 message and a confirmation by the peer in the subsequent message. 1281 10.16. Confidentiality 1283 Although EAP-GPSK provides confidentiality in its protected data 1284 payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748]. 1286 10.17. Cryptographic Binding 1288 Since EAP-GPSK does not tunnel another EAP method, it does not 1289 implement cryptographic binding. 1291 11. IANA Considerations 1293 This document requires IANA to allocate a new EAP Type for EAP-GPSK. 1295 This document requires IANA to create a new registry for 1296 ciphersuites, protected data types, and failure codes. IANA is 1297 furthermore instructed to add the specified ciphersuites, protected 1298 data types, and failure codes to this registry as defined in this 1299 document. Values can be added or modified with informational RFCs 1300 defining either block-based or hash-based ciphersuites, protected 1301 data payloads, or failure codes. Each ciphersuite needs to provide 1302 processing rules and needs to specify how the following algorithms 1303 are instantiated: Encryption, Integrity and Key Derivation. 1304 Additionally, the preferred key size needs to be specified. 1306 The following layout represents the initial ciphersuite CSuite/ 1307 Specifier registry setup: 1309 o 0x000000 : Reserved 1310 o 0x000001 : AES-CBC-128, AES-CMAC-128, GKDF-128 1311 o 0x000002 : NULL, HMAC-SHA256, GKDF-256 1312 o 0x000003 through 0xFFFFFF : Unallocated 1314 The following is the initial protected data PData/Specifier registry 1315 setup: 1317 o 0x000000 : Reserved 1318 o 0x000001 : Protected Results Indication 1319 o 0x000002 through 0xFFFFFF : Unallocated 1321 The following layout represents the initial Failure-Code registry 1322 setup: 1324 o 0x00000001: PSK Not Found 1325 o 0x00000002: Authentication Failure 1326 o 0x00000003: Authorization Failure 1327 o 0x00000004 through 0xFFFFFFFF : Unallocated 1329 12. Contributors 1331 This work is a joint effort of the EAP Method Update (EMU) design 1332 team of the EMU Working Group that was created to develop a mechanism 1333 based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 1334 4017 [RFC4017] requirements. The design team members (in 1335 alphabetical order) were: 1337 o Jari Arkko 1338 o Mohamad Badra 1339 o Uri Blumenthal 1340 o Charles Clancy 1341 o Lakshminath Dondeti 1342 o David McGrew 1343 o Joe Salowey 1344 o Sharma Suman 1345 o Hannes Tschofenig 1346 o Jesse Walker 1348 Finally, we would like to thank Thomas Otto for his draft reviews, 1349 feedback and text contributions. 1351 13. Acknowledgments 1353 We would like to thank 1355 o Jouni Malinen and Bernard Aboba for their early draft comments in 1356 June 2006. Jouni Malinen developed the first prototype 1357 implementation. It can be found at: 1358 http://hostap.epitest.fi/releases/snapshots/ 1359 o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela 1360 Vanderveen and Ray Bell for their input to the ciphersuite 1361 discussions between July and August 2006. 1362 o Lakshminath Dondeti for his detailed draft review (sent to the EMU 1363 ML on the 12th July 2006). 1364 o Based on a review requested from NIST Quynh Dang suggested changes 1365 to the GKDF function (December 2006). 1366 o Jouni Malinen and Victor Fajardo for their review in January 2007. 1367 o Jouni Malinen for his suggestions regarding the examples and the 1368 key derivation function in February 2007. 1369 o Bernard Aboba and Jouni Malinen for their review in February 2007. 1370 o Vidya Narayanan for her review in March 2007. 1372 14. References 1374 14.1. Normative References 1376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1377 Requirement Levels", BCP 14, RFC 2119, March 1997. 1379 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1380 Levkowetz, "Extensible Authentication Protocol (EAP)", 1381 RFC 3748, June 2004. 1383 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1384 Network Access Identifier", RFC 4282, December 2005. 1386 14.2. Informative References 1388 [I-D.ietf-eap-keying] 1389 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1390 Management Framework", draft-ietf-eap-keying-18 (work in 1391 progress), February 2007. 1393 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1394 Authentication Protocol (EAP) Method Requirements for 1395 Wireless LANs", RFC 4017, March 2005. 1397 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1398 (SHA and HMAC-SHA)", RFC 4634, August 2006. 1400 [CMAC] National Institute of Standards and Technology, 1401 "Recommendation for Block Cipher Modes of Operation: The 1402 CMAC Mode for Authentication", Special Publication 1403 (SP) 800-38B, May 2005. 1405 [CBC] National Institute of Standards and Technology, 1406 "Recommendation for Block Cipher Modes of Encryption. 1407 Methods and Techniques.", Special Publication (SP) 800- 1408 38A, December 2001. 1410 Authors' Addresses 1412 T. Charles Clancy 1413 DoD Laboratory for Telecommunications Sciences 1414 8080 Greenmead Drive 1415 College Park, MD 20740 1416 USA 1418 Email: clancy@ltsnet.net 1420 Hannes Tschofenig 1421 Nokia Siemens Networks 1422 Otto-Hahn-Ring 6 1423 Munich, Bavaria 81739 1424 Germany 1426 Email: Hannes.Tschofenig@siemens.com 1427 URI: http://www.tschofenig.com 1429 Full Copyright Statement 1431 Copyright (C) The IETF Trust (2007). 1433 This document is subject to the rights, licenses and restrictions 1434 contained in BCP 78, and except as set forth therein, the authors 1435 retain all their rights. 1437 This document and the information contained herein are provided on an 1438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1440 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1441 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1442 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1445 Intellectual Property 1447 The IETF takes no position regarding the validity or scope of any 1448 Intellectual Property Rights or other rights that might be claimed to 1449 pertain to the implementation or use of the technology described in 1450 this document or the extent to which any license under such rights 1451 might or might not be available; nor does it represent that it has 1452 made any independent effort to identify any such rights. Information 1453 on the procedures with respect to rights in RFC documents can be 1454 found in BCP 78 and BCP 79. 1456 Copies of IPR disclosures made to the IETF Secretariat and any 1457 assurances of licenses to be made available, or the result of an 1458 attempt made to obtain a general license or permission for the use of 1459 such proprietary rights by implementers or users of this 1460 specification can be obtained from the IETF on-line IPR repository at 1461 http://www.ietf.org/ipr. 1463 The IETF invites any interested party to bring to its attention any 1464 copyrights, patents or patent applications, or other proprietary 1465 rights that may cover technology that may be required to implement 1466 this standard. Please address the information to the IETF at 1467 ietf-ipr@ietf.org. 1469 Acknowledgment 1471 Funding for the RFC Editor function is provided by the IETF 1472 Administrative Support Activity (IASA).