idnits 2.17.1 draft-ietf-emu-eap-gpsk-08.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 1571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1595. 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 (December 4, 2007) is 5988 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) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 2 errors (**), 0 flaws (~~), 2 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: June 6, 2008 Nokia Siemens Networks 6 December 4, 2007 8 EAP Generalized Pre-Shared Key (EAP-GPSK) 9 draft-ietf-emu-eap-gpsk-08 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 June 6, 2008. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 12 61 7. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12 62 7.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 12 63 7.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12 64 7.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13 65 7.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13 66 7.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14 67 7.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14 68 7.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 69 7.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14 71 8. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 73 8.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15 74 8.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16 75 8.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21 76 8.4.1. Protected Results Indication . . . . . . . . . . . . . 24 78 9. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24 80 10. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 83 11.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 28 84 11.2. Protected Result Indications . . . . . . . . . . . . . . 29 85 11.3. Integrity Protection . . . . . . . . . . . . . . . . . . 29 86 11.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 29 87 11.5. Reflection attacks . . . . . . . . . . . . . . . . . . . 29 88 11.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 29 89 11.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . 30 90 11.8. Denial of Service Resistance . . . . . . . . . . . . . . 30 91 11.9. Session Independence . . . . . . . . . . . . . . . . . . 30 92 11.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 31 93 11.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 31 94 11.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31 95 11.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 31 96 11.14. Identity Protection . . . . . . . . . . . . . . . . . . . 31 97 11.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 31 98 11.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 32 99 11.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 32 101 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 103 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 105 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 107 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 108 15.1. Normative References . . . . . . . . . . . . . . . . . . 35 109 15.2. Informative References . . . . . . . . . . . . . . . . . 35 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 112 Intellectual Property and Copyright Statements . . . . . . . . . . 37 114 1. Introduction 116 EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a 117 generalized pre-shared key authentication technique. Mutual 118 authentication is achieved through a nonce-based exchange that is 119 secured by a pre-shared key. 121 EAP-GPSK addresses a large number of design goals with the intention 122 of being applicable in a broad range of usage scenarios. 124 The main design goals of EAP-GPSK are 126 Simplicity: 128 EAP-GPSK should be easy to implement. 130 Security Model: 132 EAP-GPSK has been designed in a threat model where the attacker 133 has full control over the communication channel. This is the EAP 134 threat model that is presented in Section 7.1 of [RFC3748]. 136 Efficiency: 138 EAP-GPSK does not make use of public key cryptography and fully 139 relies of symmetric cryptography. The restriction on symmetric 140 cryptographic computations allows for low computational overhead. 141 Hence, EAP-GPSK is lightweight and well suited for any type of 142 device, especially those with processing power, memory and battery 143 constraints. Additionally it seeks to minimize the number of 144 round trips. 146 Flexibility: 148 EAP-GPSK offers cryptographic flexibility. At the beginning, the 149 EAP server proposes a list of ciphersuites. The client then 150 selects one. The current version of EAP-GPSK comprises two 151 ciphersuites, but additional ones can be easily added. 153 Extensibility: 155 The design of EAP-GPSK allows to securely exchange information 156 between the EAP peer and the EAP server using protected data 157 fields. These fields might, for example, be used to exchange 158 channel binding information or to provide support for identity 159 confidentiality. 161 2. Terminology 163 In this document, several words are used to signify the requirements 164 of the specification. These words are often capitalized. The key 165 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 166 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 167 are to be interpreted as described in [RFC2119]. 169 This section describes the various variables and functions used in 170 the EAP-GPSK method. 172 Variables: 174 CSuite_List: An octet array listing available ciphersuites (variable 175 length) 177 CSuite_Sel: Ciphersuite selected by the peer (6 octets) 179 ID_Peer: Peer NAI [RFC4282] 181 ID_Server: Server identity as an opaque blob. 183 KS: Integer representing the key size in octets of the selected 184 ciphersuite CSuite_Sel. The key size is one of the ciphersuite 185 parameters. 187 PD_Payload: Data carried within the protected data payload 189 PD_Payload_Block: Block of possibly multiple PD_Payloads carried by 190 a GPSK packet 192 PL: Integer representing the length of the PSK in octets (2 octets) 194 RAND_Peer: Random integer generated by the peer (32 octets) 196 RAND_Server: Random integer generated by the server (32 octets) 198 Operations: 200 A || B: Concatenation of octet strings A and B 202 A**B: Integer exponentiation 203 truncate(A,B): Returns the first B octets of A 205 ENC_X(Y): Encryption of message Y with a symmetric key X, using a 206 defined block cipher 208 KDF_X(Y): Key Derivation Function that generates an arbitrary number 209 of octets of output using secret X and seed Y 211 length(X): Function that returns the length of input X in octets, 212 encoded as a 2-octet integer in network byte order 214 MAC_X(Y): Keyed message authentication code computed over Y with 215 symmetric key X 217 SEC_X(Y): SEC is a function that provides integrity protection based 218 on the chosen ciphersuite. The function SEC uses the algorithm 219 defined by the selected ciphersuite and applies it to the message 220 content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y). 222 X[A..B]: Notation representing octets A through B of octet array X 224 The following abbreviations are used for the keying material: 226 EMSK: Extended Master Session Key is exported by the EAP method (64 227 octets) 229 MK: Master Key between the peer and EAP server from which all other 230 EAP method session keys are derived (KS octets) 232 MSK: Master Session Key exported by the EAP method (64 octets) 234 PK: Session key generated from the MK and used during protocol 235 exchange to encrypt protected data (KS octets) 237 PSK: Long-term key shared between the peer and the server (PL 238 octets) 240 SK: Session key generated from the MK and used during protocol 241 exchange to demonstrate knowledge of the PSK (KS octets) 243 3. Overview 245 The EAP framework (see Section 1.3 of [RFC3748]) defines three basic 246 steps that occur during the execution of an EAP conversation between 247 the EAP peer, the Authenticator and the EAP server. 249 1. The first phase, discovery, is handled by the underlying 250 protocol. 251 2. The EAP authentication phase with EAP-GPSK is defined in this 252 document. 253 3. The secure association distribution and secure association phases 254 are handled differently depending on the underlying protocol. 256 EAP-GPSK performs mutual authentication between EAP peer ("Peer") and 257 EAP server ("Server") based on a pre-shared key (PSK). The protocol 258 consists of four message exchanges (GPSK-1, ..., GPSK-4), in which 259 both sides exchange nonces and their identities, compute and exchange 260 a Message Authentication Code (MAC) over the previously exchanged 261 values, keyed with the pre-shared key. This MAC is considered as 262 proof of possession of the pre-shared key. 264 A successful protocol exchange is shown in Figure 1. 266 +--------+ +--------+ 267 | | EAP-Request/Identity | | 268 | EAP |<------------------------------------| EAP | 269 | peer | | server | 270 | | EAP-Response/Identity | | 271 | |------------------------------------>| | 272 | | | | 273 | | EAP-Request/GPSK-1 | | 274 | |<------------------------------------| | 275 | | | | 276 | | EAP-Response/GPSK-2 | | 277 | |------------------------------------>| | 278 | | | | 279 | | EAP-Request/GPSK-3 | | 280 | |<------------------------------------| | 281 | | | | 282 | | EAP-Response/GPSK-4 | | 283 | |------------------------------------>| | 284 | | | | 285 | | EAP-Success | | 286 | |<------------------------------------| | 287 +--------+ +--------+ 289 Figure 1: EAP-GPSK: Successful Exchange 291 The full EAP-GPSK protocol is as follows: 293 GPSK-1: 295 ID_Server, RAND_Server, CSuite_List 297 GPSK-2: 299 SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List, 300 CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] ) 302 GPSK-3: 304 SEC_SK(RAND_Peer, RAND_Server, ID_Server, CSuite_Sel, [ 305 ENC_PK(PD_Payload_Block) ] ) 307 GPSK-4: 309 SEC_SK( [ ENC_PK(PD_Payload_Block) ] ) 311 The EAP server begins EAP-GPSK by selecting a random number 312 RAND_Server and by encoding the supported ciphersuites into 313 CSuite_List. A ciphersuite consists of an encryption algorithm, a 314 key derivation function and a message authentication code. 316 In GPSK-1, the EAP server sends its identity ID_Server, a random 317 number RAND_Server and a list of supported ciphersuites CSuite_List. 318 The decision which ciphersuite to offer and which ciphersuite to pick 319 is policy- and implementation-dependent and therefore outside the 320 scope of this document. 322 In GPSK-2, the peer sends its identity ID_Peer and a random number 323 RAND_Peer. Furthermore, it repeats the received parameters of the 324 GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected 325 ciphersuite. It computes a Message Authentication Code over all the 326 transmitted parameters. 328 The EAP server verifies the received Message Authentication Code. In 329 case of successful verification, the EAP server computes a Message 330 Authentication Code over the session parameter and returns it to the 331 peer (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP server 332 have the possibility to exchange encrypted protected data parameters. 334 The peer verifies the received Message Authentication Code. If the 335 verification is successful, GPSK-4 is prepared. This message can 336 optionally contain the peer's protected data parameters. 338 Upon receipt of GPSK-4, the server processes any included 339 PD_Payload_Block. Then, the EAP server sends an EAP Success message 340 to indicate the successful outcome of the authentication. 342 4. Key Derivation 344 EAP-GPSK provides key derivation in compliance to the requirements of 345 [RFC3748] and [I-D.ietf-eap-keying]. Note that this section provides 346 an abstract description for the key derivation procedure that needs 347 to be instantiated with a specific ciphersuite. 349 The long-term credential shared between EAP peer and EAP server 350 SHOULD be a strong pre-shared key PSK of at least 16 octets, though 351 its length and entropy is variable. While it is possible to use a 352 password or passphrase, doing so is NOT RECOMMENDED as it would make 353 EAP-GPSK vulnerable to dictionary attacks. 355 During an EAP-GPSK authentication, a Master Key MK, a Session Key SK 356 and a Protected Data Encryption Key PK (if using an encrypting 357 ciphersuite) are derived using the ciphersuite-specified KDF and data 358 exchanged during the execution of the protocol, namely 'RAND_Peer || 359 ID_Peer || RAND_Server || ID_Server' referred as inputString as its 360 short-hand form. 362 In case of successful completion, EAP-GPSK derives and exports an MSK 363 and EMSK both in length of 64 octets. 365 The following notation is used: KDF-X(Y, Z)[A..B], whereby 366 X is the length, in octets, of the desired output, 367 Y is a secret key, 368 Z is the inputString, 369 [A..B] extracts the string of octets starting with octet A finishing 370 with octet B from the output of the KDF function. 372 This keying material is derived using the ciphersuite-specified KDF 373 as follows: 375 o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 376 o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || 377 inputString)[0..KS-1] 378 o MSK = KDF-{128+2*KS}(MK, inputString)[0..63] 379 o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127] 380 o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS] 381 o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using 382 an encrypting ciphersuite) 384 Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires 385 the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. 386 These values are defined as: 388 o zero = 0x00 || 0x00 || ... || 0x00 (KS times) 389 o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type || 390 CSuite_Sel || inputString)[0..15] 391 o Session-ID = Type_Code || Method_ID 392 o Peer-ID = ID_Peer 393 o Server-ID = ID_Server 395 EAP_Method_Type refers to the integer value of the IANA allocated EAP 396 Type code. 398 Figure 2 depicts the key derivation procedure of EAP-GPSK. 400 +-------------+ +-------------------------------+ 401 | PL-octet | | RAND_Peer || ID_Peer || | 402 | PSK | | RAND_Server || ID_Server | 403 +-------------+ +-------------------------------+ 404 | | | 405 | +------------+ | | 406 | | CSuite_Sel | | | 407 | +------------+ | | 408 | | | | 409 v v v | 410 +--------------------------------------------+ | 411 | KDF | | 412 +--------------------------------------------+ | 413 | | 414 v | 415 +-------------+ | 416 | KS-octet | | 417 | MK | | 418 +-------------+ | 419 | | 420 v v 421 +---------------------------------------------------+ 422 | KDF | 423 +---------------------------------------------------+ 424 | | | | 425 v v v v 426 +---------+ +---------+ +----------+ +----------+ 427 | 64-octet| | 64-octet| | KS-octet | | KS-octet | 428 | MSK | | EMSK | | SK | | PK | 429 +---------+ +---------+ +----------+ +----------+ 431 Figure 2: EAP-GPSK Key Derivation 433 5. Ciphersuites 435 The design of EAP-GPSK allows cryptographic algorithms and key sizes, 436 called ciphersuites, to be negotiated during the protocol run. The 437 ability to specify block-based and hash-based ciphersuites is 438 offered. Extensibility is provided with the introduction of new 439 ciphersuites; this document specifies an initial set. The CSuite/ 440 Specifier column in Figure 3 uniquely identifies a ciphersuite. 442 For a vendor-specific ciphersuite the first three octets are the 443 vendor-specific Object Identifier (OID) contains the IANA assigned 444 "SMI Network Management Private Enterprise Codes" value (see 445 [RFC3232]), encoded in network byte order. The last three octets are 446 vendor assigned for the specific ciphersuite. 448 The following ciphersuites are specified in this document: 450 +-----------+----+-------------+--------------+----------------+ 451 | CSuite/ | KS | Encryption | Integrity / | Key Derivation | 452 | Specifier | | | KDF MAC | Function | 453 +-----------+----+-------------+--------------+----------------+ 454 | 0x000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF | 455 +-----------+----+-------------+--------------+----------------+ 456 | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF | 457 +-----------+----+-------------+--------------+----------------+ 459 Figure 3: Ciphersuites 461 Ciphersuite 1, which is based on AES as a cryptographic primitive, is 462 mandatory to implement. This document specifies also a second 463 ciphersuite, but its support is optional. Both ciphersuites defined 464 in this document make use of the GKDF, as defined in Section 6. The 465 following aspects need to be considered to ensure that the PSK that 466 is used as input to the GKDF is sufficiently long (in case it is 467 longer it needs to be truncated): 469 1. The PSK used with ciphersuite 1 MUST be 128 bits in length or 470 longer. 471 2. The PSK used with ciphersuite 2 MUST be 256 bits in length or 472 longer. 473 3. It is RECOMMENDED that 256 bit keys be provisioned in all cases 474 to provide enough entropy for all current and many possible 475 future ciphersuites. 477 Ciphersuites defined in the future that make use of the GKDF need to 478 specify a minimum PSK size (as it is done with the ciphersuites 479 listed in this document). 481 6. Generalized Key Derivation Function (GKDF) 483 Each ciphersuite needs to specify a key derivation function. The 484 ciphersuites defined in this document make use of the Generalized Key 485 Derivation Function (GKDF) that utilizes the MAC function defined in 486 the ciphersuite. Future ciphersuites can use any other formally 487 specified KDF that takes as arguments a key and a seed value, and 488 produces at least 128+2*KS octets of output. 490 GKDF has the following structure: 492 GKDF-X(Y, Z) 494 X length, in octets, of the desired output 495 Y secret key 496 Z inputString 498 GKDF-X (Y, Z) 499 { 500 n = ceiling integer of ( X / KS ); 501 /* determine number of output blocks */ 503 M_0 = ""; 504 result = ""; 506 for i = 1 to n { 507 M_i = MAC_Y (i || Z); 508 result = result || M_i; 509 } 511 return truncate(result, X) 512 } 514 Note that the variable 'i' in M_i is represented as a 2-octet value 515 in network byte order. 517 7. Ciphersuites Processing Rules 519 7.1. Ciphersuite #1 521 7.1.1. Encryption 523 With this ciphersuite all cryptography is built around a single 524 cryptographic primitive, AES-128 ([AES]). Within the protected data 525 frames, AES-128 is used in Cipher Block Chaining (CBC) mode of 526 operation (see [CBC]). This EAP method uses encryption in a single 527 payload, in the protected data payload (see Section 8.4). 529 In a nutshell, the CBC mode proceeds as follows. The IV is XORed 530 with the first plaintext block before it is encrypted. Then for 531 successive blocks, the previous ciphertext block is XORed with the 532 current plaintext, before it is encrypted. 534 7.1.2. Integrity 536 Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is 537 recommended by NIST. Among its advantages, CMAC is capable to work 538 with messages of arbitrary length. A detailed description of CMAC 539 can be found in [CMAC]. 541 The following instantiation is used: AES-CMAC-128(SK, Input) denotes 542 the MAC of Input under the key SK. 544 where Input refers to the following content: 546 o Value of SEC_SK(Value) in message GPSK-2 547 o Value of SEC_SK(Value) in message GPSK-3 548 o Value of SEC_SK(Value) in message GPSK-4 550 7.1.3. Key Derivation 552 This ciphersuite instantiates the KDF in the following way: 554 inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 556 MK = GKDF-16 (PSK[0..15], PL || PSK || CSuite_Sel || inputString) 558 MSK = GKDF-160 (MK, inputString)[0..63] 560 EMSK = GKDF-160 (MK, inputString)[64..127] 562 SK = GKDF-160 (MK, inputString)[128..143] 564 PK = GKDF-160 (MK, inputString)[144..159] 566 zero = 0x00 || 0x00 || ... || 0x00 (16 times) 568 Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type || 569 CSuite_Sel || inputString) 571 7.2. Ciphersuite #2 573 7.2.1. Encryption 575 Ciphersuite 2 does not include an algorithm for encryption. With a 576 NULL encryption algorithm, encryption is defined as: 578 E_X(Y) = Y 580 When using this ciphersuite, the data exchanged inside the protected 581 data block is not encrypted. Therefore this mode MUST NOT be used if 582 confidential information appears inside the protected data block. 584 7.2.2. Integrity 586 Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash 587 algorithm (see [RFC4634]). 589 For integrity protection the following instantiation is used: 591 HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK 592 where Input refers to the following content: 594 o Value of SEC_SK(Value) in message GPSK-2 595 o Value of SEC_SK(Value) in message GPSK-3 596 o Value of SEC_SK(Value) in message GPSK-4 598 7.2.3. Key Derivation 600 This ciphersuite instantiates the KDF in the following way: 602 inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 604 MK = GKDF-32 (PSK[0..31], PL || PSK || CSuite_Sel || inputString) 606 MSK = GKDF-160 (MK, inputString)[0..63] 608 EMSK = GKDF-160 (MK, inputString)[64..127] 610 SK = GKDF-160 (MK, inputString)[128..159] 612 zero = 0x00 || 0x00 || ... || 0x00 (32 times) 614 Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type || 615 CSuite_Sel || inputString) 617 8. Packet Formats 619 This section defines the packet format of the EAP-GPSK messages. 621 8.1. Header Format 623 The EAP-GPSK header has the following structure: 625 --- bit offset ---> 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Code | Identifier | Length | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Type | OP-Code | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 633 | | 634 ... Payload ... 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Figure 5 640 The Code, Identifier, Length, and Type fields are all part of the EAP 641 header, and defined in [RFC3748]. IANA has allocated EAP Method Type 642 XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX. 644 The OP-Code field is one of four values: 646 o 0x01 : GPSK-1 647 o 0x02 : GPSK-2 648 o 0x03 : GPSK-3 649 o 0x04 : GPSK-4 650 o 0x05 : GPSK-Fail 651 o 0x06 : GPSK-Protected-Fail 652 All other values of this OP-Code field are available via IANA 653 registration. 655 8.2. Ciphersuite Formatting 657 Ciphersuites are encoded as 6-octet arrays. The first four octets 658 indicate the CSuite/Vendor field. For vendor-specific ciphersuites, 659 this represents the vendor Object Identifier (OID) contains the IANA 660 assigned "SMI Network Management Private Enterprise Codes" value (see 661 [RFC3232]), encoded in network byte order. The last two octets 662 indicate the CSuite/Specifier field, which identifies the particular 663 ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates 664 ciphersuites allocated by the IETF. 666 Graphically, they are represented as 668 --- bit offset ---> 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | CSuite/Vendor = 0x00000000 or OID | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | CSuite/Specifier | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 6 679 CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and 680 CSuite/Specifier pair. 682 CSuite_List is a variable-length octet array of ciphersuites. It is 683 encoded by concatenating encoded ciphersuite values. Its length in 684 octets MUST be a multiple of 6. 686 8.3. Payload Formatting 688 Payload formatting is based on the protocol exchange description in 689 Section 3. 691 The GPSK-1 payload format is defined as follows: 693 --- bit offset ---> 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | length(ID_Server) | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 699 | | 700 ... ID_Server ... 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | | 704 ... 32-octet RAND_Server ... 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | length(CSuite_List) | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 709 | | 710 ... CSuite_List ... 711 | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Figure 7: GPSK-1 Payload 716 The GPSK-2 payload format is defined as follows: 718 --- bit offset ---> 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | length(ID_Peer) | | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 724 | | 725 ... ID_Peer ... 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | length(ID_Server) | | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 730 | | 731 ... ID_Server ... 732 | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | | 735 ... 32-octet RAND_Peer ... 736 | | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | | 739 ... 32-octet RAND_Server ... 740 | | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | length(CSuite_List) | | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 744 | | 745 ... CSuite_List ... 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | CSuite_Sel | 749 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | length(PD_Payload_Block) | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | | 753 ... optional PD_Payload_Block ... 754 | | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | | 757 ... KS-octet payload MAC ... 758 | | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 Figure 8: GPSK-2 Payload 763 If the optional protected data payload is not included, then 764 length(PD_Payload_Block)=0 and the PD payload is excluded. 766 The GPSK-3 payload is defined as follows: 768 --- bit offset ---> 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | | 773 ... 32-octet RAND_Peer ... 774 | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | | 777 ... 32-octet RAND_Server ... 778 | | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | length(ID_Server) | | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 782 | | 783 ... ID_Server ... 784 | | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | CSuite_Sel | 787 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | | length(PD_Payload_Block) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | | 791 ... optional PD_Payload_Block ... 792 | | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | 795 ... KS-octet payload MAC ... 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Figure 9: GPSK-3 Payload 801 If the optional protected data payload is not included, then 802 length(PD_Payload_Block)=0 and the PD payload is excluded. 804 The GPSK-4 payload format is defined as follows: 806 --- bit offset ---> 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | length(PD_Payload_Block) | | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 812 | | 813 ... optional PD_Payload_Block ... 814 | | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | | 817 ... KS-octet payload MAC ... 818 | | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Figure 10: GPSK-4 Payload 823 If the optional protected data payload is not included, then 824 length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC 825 MUST always be included, regardless of the presence of 826 PD_Payload_Block. 828 The GPSK-Fail payload format is defined as follows: 830 --- bit offset ---> 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Failure-Code | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Figure 11: GPSK-Fail Payload 839 The GPSK-Protected-Fail payload format is defined as follows: 841 --- bit offset ---> 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Failure-Code | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | | 848 ... KS-octet payload MAC ... 849 | | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Figure 12: GPSK-Protected-Fail Payload 853 The Failure-Code field is one of three values, but can be extended: 855 o 0x00000001: PSK Not Found 856 o 0x00000002: Authentication Failure 857 o 0x00000003: Authorization Failure 858 All other values of this field are available via IANA registration. 860 "PSK Not Found" indicates a key for a particular user could not be 861 located, making authentication impossible. "Authentication Failure" 862 indicates a MAC failure due to a PSK mismatch. "Authorization 863 Failure" indicates that while the PSK being used is correct, the user 864 is not authorized to connect. 866 8.4. Protected Data 868 The protected data blocks are a generic mechanism for the peer and 869 server to securely exchange data. If the specified ciphersuite has a 870 NULL encryption primitive, then this channel only offers 871 authenticity, and not confidentiality. 873 These payloads are encoded as the concatenation of type-length-value 874 (TLV) triples called PD_Payloads. 876 Type values are encoded as a 6-octet string and represented by a 877 4-octet vendor and 2-octet specifier field. The vendor field 878 indicates the type as either standards-specified or vendor-specific. 879 If these four octets are 0x00000000, then the value is standards- 880 specified, and any other value represents a vendor-specific Object 881 Identifier (OID). 883 The specifier field indicates the actual type. For vendor field 884 0x00000000, the specifier field is maintained by IANA. For any other 885 vendor field, the specifier field is maintained by the vendor. 887 Length fields are specified as 2-octet integers in network byte 888 order, and reflect only the length of the value, and do not include 889 the length of the type and length fields. 891 Graphically, this can be depicted as follows: 893 --- bit offset ---> 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | PData/Vendor | ... 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 PData/Specifier | PData/Length | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | | 902 ... PData/Value ... 903 | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 Protected Data Payload (PD_Payload) Formatting 908 These PD_Payloads are concatenated together to form a 909 PD_Payload_Block. The If the CSuite_Sel includes support for 910 encryption, then the PD_Payload_Block includes fields specifying an 911 initialization vector (IV), and the necessary padding. This can be 912 depicted as follows: 914 --- bit offset ---> 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Initialization Vector | 919 ... (length is block size for encryption algorithm) ... 920 | | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | | 923 ... PD_Payload ... 924 | | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | | 927 ... optional PD_Payload, etc ... 928 | | 929 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | | Padding (0-255 octets) | 931 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 932 | | Pad Length | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 Protected Data Block (PD_Payload_Block) Formatting if Encryption 936 Supported 938 The Initialization Vector is a randomly chosen value whose length is 939 equal to the block length of the underlying encryption algorithm. 941 Recipients MUST accept any value. Senders SHOULD either pick this 942 value pseudo-randomly and independently for each message or use the 943 final ciphertext block of the previous message sent. Senders MUST 944 NOT use the same value for each message, use a sequence of values 945 with low hamming distance (e.g., a sequence number), or use 946 ciphertext from a received message. 948 The concatenation of PD_Payloads along with the padding and padding 949 length are all encrypted using the negotiated block cipher. If no 950 block cipher is specified, then these fields are not encrypted. 952 The Padding field MAY contain any value chosen by the sender, and 953 MUST have a length that makes the combination of the concatenation of 954 PD_Payloads, the Padding, and the Pad Length to be a multiple of the 955 encryption block size. 957 The Pad Length field is the length of the Padding field. The sender 958 SHOULD set the Pad Length to the minimum value that makes the 959 combination of the PD_Payloads, the Padding, and the Pad Length a 960 multiple of the block size, but the recipient MUST accept any length 961 that results in proper alignment. This field is encrypted with the 962 negotiated cipher. 964 If the negotiated ciphersuite does not support encryption, then the 965 padding field MUST be of length zero. The padding length field MUST 966 still be present, and contain the value zero. This is depicted in 967 the following figure. 969 --- bit offset ---> 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | | 974 ... PD_Payload ... 975 | | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | | 978 ... optional PD_Payload, etc +-+-+-+-+-+-+-+-+ 979 | | 0x00 | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 Protected Data Block (PD_Payload_Block) Formatting Without Encryption 984 For PData/Vendor field 0x000000, the following PData/Specifier fields 985 are defined: 987 o 0x000000 : Reserved 988 o 0x000001 : Protected Results Indication 989 All other values of this field are available via IANA registration. 991 8.4.1. Protected Results Indication 993 Based on the PData/Specifier allocation the following 8-bit payload 994 is specified to be placed in the PD_Payload Value to provide the 995 functionality of protected results indication. 997 0 998 0 1 2 3 4 5 6 7 999 +-+-+-+-+-+-+-+-+ 1000 |I|R|R|R|R|R|R|R| 1001 +-+-+-+-+-+-+-+-+ 1003 I: Result Indicator 1005 The bits have the following meaning: 1007 (0): Success 1008 (1): Failure 1010 R: Reserved 1011 These bits are used for padding. 1013 The 8 bits of protected results indication functionality, which does 1014 not require confidentiality protection, MUST only be sent in GPSK-3 1015 from the EAP server to the EAP peer. 1017 9. Packet Processing Rules 1019 This section defines how the EAP peer and EAP server MUST behave when 1020 received packet is deemed invalid. 1022 Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP 1023 server MUST be silently discarded. An EAP peer or EAP server 1024 receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 1025 before receiving GPSK-1 or before transmitting GPSK-2) MUST silently 1026 discard the packet. 1028 GPSK-1 contains no MAC protection, so provided it properly parses, it 1029 MUST be accepted by the peer. Note that the ciphersuite list 1030 provided by the EAP server in CSuite_List MUST always include the 1031 mandatory-to-implement ciphersuite defined in this document. Hence, 1032 there is always at least one ciphersuite in common between the EAP 1033 peer and the EAP server. If the EAP peer decides the ID_Server is 1034 that of a AAA server to which it does not wish to authenticate, the 1035 EAP peer should respond with an EAP-NAK. 1037 For GPSK-2, if ID_Peer is for an unknown user, the EAP server MUST 1038 send either a "PSK Not Found" GPSK-Fail message, or an 1039 "Authentication Failure" GPSK-Fail, depending on its policy, and 1040 discard the received packet. If the MAC validation fails, the server 1041 MUST transmit a GPSK-Fail message specifying "Authentication Failure" 1042 and discard the received packet. If the RAND_Server or CSuite_List 1043 field in GPSK-2 does not match the values in GPSK-1, the server MUST 1044 silently discard the packet. If server policy determines the peer is 1045 not authorized and the MAC is correct, the server MUST transmit a 1046 GPSK-Protected-Fail message indicating "Authorization Failure" and 1047 discard the received packet. 1049 A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in 1050 response to a GPSK-2 message MUST replay the received GPSK-Fail / 1051 GPSK-Protected-Fail message. Then, the EAP server returns an EAP- 1052 Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message 1053 to correctly finish the EAP conversation. If MAC validation on a 1054 GPSK-Protected-Fail packet fails, then the received packet MUST be 1055 silently discarded. 1057 For GPSK-3, a peer MUST silently discard messages where the 1058 RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those 1059 transmitted in GPSK-2. An EAP peer MUST silently discard any packet 1060 whose MAC fails. 1062 For GPSK-4, a server MUST silently discard any packet whose MAC fails 1063 validation. 1065 If a decryption failure of a protected payload is detected, the 1066 recipient MUST silently discard the GPSK packet. 1068 10. Example Message Exchanges 1070 This section shows a couple of example message flows. 1072 A successful EAP-GPSK message exchange is shown in Figure 1. 1074 +--------+ +--------+ 1075 | | EAP-Request/Identity | | 1076 | EAP |<------------------------------------| EAP | 1077 | peer | | server | 1078 | | EAP-Response/Identity | | 1079 | |------------------------------------>| | 1080 | | | | 1081 | | EAP-Request/GPSK-1 | | 1082 | |<------------------------------------| | 1083 | | | | 1084 | | EAP-Response/EAP-NAK | | 1085 | |------------------------------------>| | 1086 | | | | 1087 | | EAP-Failure | | 1088 | |<------------------------------------| | 1089 +--------+ +--------+ 1091 EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity; 1092 ID_Server) 1094 +--------+ +--------+ 1095 | | EAP-Request/Identity | | 1096 | EAP |<------------------------------------| EAP | 1097 | peer | | server | 1098 | | EAP-Response/Identity | | 1099 | |------------------------------------>| | 1100 | | | | 1101 | | EAP-Request/GPSK-1 | | 1102 | |<------------------------------------| | 1103 | | | | 1104 | | EAP-Response/GPSK-2 | | 1105 | |------------------------------------>| | 1106 | | | | 1107 | | EAP-Request/GPSK-3 (GPSK-Fail | | 1108 | | (PSK Not Found or Authentication | | 1109 | | Failure)) | | 1110 | |<------------------------------------| | 1111 | | | | 1112 | | EAP-Response/GPSK-4 (GPSK-Fail | | 1113 | | (PSK Not Found or Authentication | | 1114 | | Failure)) | | 1115 | |------------------------------------>| | 1116 | | | | 1117 | | EAP-Failure | | 1118 | |<------------------------------------| | 1119 +--------+ +--------+ 1120 EAP-GPSK: Unsuccessful Exchange (Unknown user) 1122 +--------+ +--------+ 1123 | | EAP-Request/Identity | | 1124 | EAP |<------------------------------------| EAP | 1125 | peer | | server | 1126 | | EAP-Response/Identity | | 1127 | |------------------------------------>| | 1128 | | | | 1129 | | EAP-Request/GPSK-1 | | 1130 | |<------------------------------------| | 1131 | | | | 1132 | | EAP-Response/GPSK-2 | | 1133 | |------------------------------------>| | 1134 | | | | 1135 | | EAP-Request/GPSK-3 (GPSK-Fail | | 1136 | | (Authentication Failure)) | | 1137 | |<------------------------------------| | 1138 | | | | 1139 | | EAP-Response/GPSK-4 (GPSK-Fail | | 1140 | | (Authentication Failure)) | | 1141 | |------------------------------------>| | 1142 | | | | 1143 | | EAP-Failure | | 1144 | |<------------------------------------| | 1145 +--------+ +--------+ 1147 EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2) 1149 +--------+ +--------+ 1150 | | EAP-Request/Identity | | 1151 | EAP |<------------------------------------| EAP | 1152 | peer | | server | 1153 | | EAP-Response/Identity | | 1154 | |------------------------------------>| | 1155 | | | | 1156 | | EAP-Request/GPSK-1 | | 1157 | |<------------------------------------| | 1158 | | | | 1159 | | EAP-Response/GPSK-2 | | 1160 | |------------------------------------>| | 1161 | | | | 1162 | | EAP-Request/GPSK-3 | | 1163 | | GPSK-Protected-Fail | | 1164 | | (Authorization Failure) | | 1165 | |<------------------------------------| | 1166 | | | | 1167 | | EAP-Request/GPSK-4 | | 1168 | | GPSK-Protected-Fail | | 1169 | | (Authorization Failure) | | 1170 | |------------------------------------>| | 1171 | | | | 1172 | | EAP-Failure | | 1173 | |<------------------------------------| | 1174 +--------+ +--------+ 1176 EAP-GPSK: Unsuccessful Exchange (Authorization failure) 1178 11. Security Considerations 1180 [RFC3748] highlights several attacks that are possible against EAP 1181 since EAP itself does not provide any security. 1183 This section discusses the claimed security properties of EAP-GPSK as 1184 well as vulnerabilities and security recommendations in the threat 1185 model of [RFC3748]. 1187 11.1. Mutual Authentication 1189 EAP-GPSK provides mutual authentication. 1191 The server believes that the peer is authentic when it successfully 1192 verifies the MAC in the GPSK-2 message and the peer believes that the 1193 server is authentic when it successfully verifies the MAC it receives 1194 with the GPSK-3 message. 1196 The key used for mutual authentication is derived based on the long- 1197 term secret PSK, nonces contributed by both parties and other 1198 parameters. The long-term secret PSK has to provide sufficient 1199 entropy and therefore sufficient strength. The nonces (RAND_Peer and 1200 RAND_Server) need to be fresh and unique for every session. In this 1201 way EAP-GPSK is not different than other authentication protocols 1202 based on pre-shared keys. 1204 11.2. Protected Result Indications 1206 EAP-GPSK offers the capability to exchange protected result 1207 indications using the protected data payloads. 1209 11.3. Integrity Protection 1211 EAP-GPSK provides integrity protection based on the ciphersuites 1212 suggested in this document. Integrity protection is a minimum 1213 feature every ciphersuite must provide. 1215 11.4. Replay Protection 1217 EAP-GPSK provides replay protection of its mutual authentication part 1218 thanks to the use of random numbers RAND_Server and RAND_Peer. Since 1219 RAND_Server is 32 octets long, one expects to have to record 2**64 1220 (i.e., approximately 1.84*10**19) EAP-GPSK successful authentication 1221 before an protocol run can be replayed. Hence, EAP-GPSK provides 1222 replay protection of its mutual authentication part as long as 1223 RAND_Server and RAND_Peer are chosen at random, randomness is 1224 critical for replay protection. RFC 4086 [RFC4086] describes 1225 techniques for producing random quantities. 1227 11.5. Reflection attacks 1229 EAP-GPSK provides protection against reflection attacks in case of an 1230 extended authentication because the messages are constructed in a 1231 different fashion. 1233 11.6. Dictionary Attacks 1235 EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based 1236 on at least 16 octets of entropy to guarantee security against 1237 dictionary attacks. Users who use passwords are not guaranteed 1238 protection against dictionary attacks. Derivation of the long-term 1239 shared secret from a password is strongly discouraged. 1241 11.7. Key Derivation 1243 EAP-GPSK supports key derivation as shown in Section 4. 1245 11.8. Denial of Service Resistance 1247 There are two forms of denial of service attacks relevant for this 1248 document, namely attacks that lead to vast amount of state being 1249 allocated and attacks against the computational resources. The 1250 latter onces are less problematic for EAP-GPSK since all computations 1251 are lightweight. We will consider the former one in more detail 1252 below. 1254 In an EAP-GPSK conversation the server has to maintain state, namely 1255 the 32-octet RAND_Server, when transmitting the GPSK-1 message to the 1256 peer. An adversary could therefore flood a server with a large 1257 number of EAP-GPSK communication attempts. An EAP server may 1258 therefore ensure that established state times out after a relatively 1259 short period of time when no further messages are received. This 1260 enables a sort of garbage collection. 1262 The client would have to potentially keep state information after 1263 receiving the GPSK-1 message. Section 4.2 of [HM2004] describes a 1264 short of client-side denial of service attack and illustrates three 1265 possible solutions to avoid having the client to keep state when 1266 receiving the first message. When the client receives the GPSK-3 1267 message then it needs to derive keying material based on the 1268 following information: RAND_Peer, ID_Peer, RAND_Server, ID_Server, 1269 RAND_Peer, RAND_Server. Hence, GPSK-3 includes all necessary 1270 parameters to allow the client to (a) avoid allocating state 1271 information with the arrival of GPSK-1 and (b) to enable deriving the 1272 keying material. 1274 The security considerations of EAP itself, see Section 5.2 and 1275 Section 7 of RFC 3748 [RFC3748], are also applicable to this 1276 specification (e.g., for example concerning EAP-based notifications). 1278 11.9. Session Independence 1280 Thanks to its key derivation mechanisms, EAP-GPSK provides session 1281 independence: passive attacks (such as capture of the EAP 1282 conversation) or active attacks (including compromise of the MSK or 1283 EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. 1284 The assumption that RAND_Peer and RAND_Server are random is central 1285 for the security of EAP-GPSK in general and session independence in 1286 particular. 1288 11.10. Exposition of the PSK 1290 EAP-GPSK does not provide perfect forward secrecy. Compromise of the 1291 PSK leads to compromise of recorded past sessions. 1293 Compromise of the PSK enables the attacker to impersonate the peer 1294 and the server and it allows the adversary to compromise future 1295 sessions. 1297 EAP-GPSK provides no protection against a legitimate peer sharing its 1298 PSK with a third party. Such protection may be provided by 1299 appropriate repositories for the PSK, which choice is outside the 1300 scope of this document. The PSK used by EAP-GPSK must only be shared 1301 between two parties: the peer and the server. In particular, this 1302 PSK must not be shared by a group of peers communicating with the 1303 same server. 1305 The PSK used by EAP-GPSK must be cryptographically separated from 1306 keys used by other protocols, otherwise the security of EAP-GPSK may 1307 be compromised. 1309 11.11. Fragmentation 1311 EAP-GPSK does not support fragmentation and reassembly since the 1312 message size is relatively small. 1314 11.12. Channel Binding 1316 This document enables the ability to exchange channel binding 1317 information. It does not, however, define the encoding of channel 1318 binding information in the document. 1320 11.13. Fast Reconnect 1322 EAP-GPSK does not provide the fast reconnect capability since this 1323 method is already at (or close to) the lower limit of the number of 1324 roundtrips and the cryptographic operations. 1326 11.14. Identity Protection 1328 Identity protection is not specified in this document. Extensions 1329 can be defined that enhance this protocol to provide this feature. 1331 11.15. Protected Ciphersuite Negotiation 1333 EAP-GPSK provides protected ciphersuite negotiation via the 1334 indication of available ciphersuites by the server in the first 1335 message and a confirmation by the peer in the subsequent message. 1337 Note, however, that the GPSK-2 message may optionally contain a 1338 payload, ENC_PK(PD_Payload_Block), protected with an algorithm based 1339 on a selected ciphersuite before the ciphersuite list has actually 1340 been authenticated. In the classical downgrading attack an adversary 1341 would chose a ciphersuite that it weak enough to that it could break 1342 it in real-time or to turn security off. The latter is not possible 1343 since any ciphersuite defined for EAP-GPSK must at least provide 1344 authentication and integrity protection. Confidentity protection is 1345 optional. When, some time in the future, a ciphersuite contains 1346 algorithms that can be broken in real-time then a policy on peers and 1347 the server needs to indicate that such a ciphersuite must not be 1348 selected by any of parties. 1350 Furthermore, an adversay may modify the selection of the ciphersuite 1351 to for the client to select a ciphersuite that does not provide 1352 confidentity protection. As a result this would cause the content of 1353 PD_Payload_Block to be transmitted in cleartext. When protocol 1354 designers extend EAP-GPSK to carry information in the 1355 PD_Payload_Block of the GPSK-2 message then it must be indicated 1356 whether confidentiality protection is mandatory. In case such an 1357 extension requires a ciphersuite with confidentiality protection then 1358 the policy at the peer must not transmit information of that 1359 extension in the PD_Payload_Block of the GPSK-2 message. The peer 1360 may, if possible, delay the transmission of this information element 1361 to the GPSK-4 message where the ciphersuite negotiation has been 1362 confirmed already. In general, when a ciphersuite is selected that 1363 does not provide confidentiality protection then information that 1364 demands confidentility protection must not be included in any of the 1365 PD_Payload_Block objects. 1367 11.16. Confidentiality 1369 Although EAP-GPSK provides confidentiality in its protected data 1370 payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748]. 1372 11.17. Cryptographic Binding 1374 Since EAP-GPSK does not tunnel another EAP method, it does not 1375 implement cryptographic binding. 1377 12. IANA Considerations 1379 This document requires IANA to allocate a new EAP Type for EAP-GPSK. 1381 This document requires IANA to create a new registry for 1382 ciphersuites, protected data types, failure codes and op-codes. IANA 1383 is furthermore instructed to add the specified ciphersuites, 1384 protected data types, failure codes and op-codes to these registries 1385 as defined in this document. Values can be added or modified with 1386 informational RFCs defining either block-based or hash-based 1387 ciphersuites, protected data payloads, failure codes and op-codes. 1388 Each ciphersuite needs to provide processing rules and needs to 1389 specify how the following algorithms are instantiated: encryption, 1390 integrity, key derivation and key length. 1392 Figure 3 represents the initial ciphersuite CSuite/Specifier registry 1393 setup. The CSuite/Specifier field is 16 bits long. All other values 1394 are available via IANA registration. 1396 The following is the initial protected data PData/Specifier registry 1397 setup: 1399 o 0x000000 : Reserved 1400 o 0x000001 : Protected Results Indication 1402 The PData/Specifier field is 24 bits long and all other values are 1403 available via IANA registration. Each extension needs to indicate 1404 whether confidentiality protection for transmission between the EAP 1405 peer and the EAP server is mandatory. The following layout 1406 represents the initial Failure-Code registry setup: 1408 o 0x00000001: PSK Not Found 1409 o 0x00000002: Authentication Failure 1410 o 0x00000003: Authorization Failure 1412 The Failure-Code field is 32 bits long and all other values are 1413 available via IANA registration. The following layout represents the 1414 initial OP-Code registry setup: 1416 o 0x01 : GPSK-1 1417 o 0x02 : GPSK-2 1418 o 0x03 : GPSK-3 1419 o 0x04 : GPSK-4 1420 o 0x05 : GPSK-Fail 1421 o 0x06 : GPSK-Protected-Fail 1423 The OP-Code field is 8 bits long and all other values are available 1424 via IANA registration. 1426 13. Contributors 1428 This work is a joint effort of the EAP Method Update (EMU) design 1429 team of the EMU Working Group that was created to develop a mechanism 1430 based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 1431 4017 [RFC4017] requirements. The design team members (in 1432 alphabetical order) were: 1434 o Jari Arkko 1435 o Mohamad Badra 1436 o Uri Blumenthal 1437 o Charles Clancy 1438 o Lakshminath Dondeti 1439 o David McGrew 1440 o Joe Salowey 1441 o Sharma Suman 1442 o Hannes Tschofenig 1443 o Jesse Walker 1445 Finally, we would like to thank Thomas Otto for his draft reviews, 1446 feedback and text contributions. 1448 14. Acknowledgments 1450 We would like to thank 1452 o Jouni Malinen and Bernard Aboba for their early draft comments in 1453 June 2006. Jouni Malinen developed the first prototype 1454 implementation. It can be found at: 1455 http://hostap.epitest.fi/releases/snapshots/ 1456 o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela 1457 Vanderveen and Ray Bell for their input to the ciphersuite 1458 discussions between July and August 2006. 1459 o Lakshminath Dondeti for his detailed draft review (sent to the EMU 1460 ML on the 12th July 2006). 1461 o Based on a review requested from NIST Quynh Dang suggested changes 1462 to the GKDF function (December 2006). 1463 o Jouni Malinen and Victor Fajardo for their review in January 2007. 1464 o Jouni Malinen for his suggestions regarding the examples and the 1465 key derivation function in February 2007. 1466 o Bernard Aboba and Jouni Malinen for their review in February 2007. 1467 o Vidya Narayanan for her review in March 2007. 1468 o 1469 o Joe Salowey, the EMU working group chair, provided a document 1470 review in April 2007. Jouni Malinen also reviewed the document 1471 during the same month. 1472 o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov 1473 and Prof. John C. Mitchell for their analysis of EAP-GPSK and for 1474 pointing us to a client-side DoS attack, a downgrading attack and 1475 their input to the key derivation function. Based on their input 1476 the key derivation function has been modified and the text in the 1477 security consideration section has been updated. 1479 o Finally, we would like to thank our working group chair, Joe 1480 Salowey, for his support and for the time he spend on discussing 1481 open issues with us. 1483 15. References 1485 15.1. Normative References 1487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1488 Requirement Levels", BCP 14, RFC 2119, March 1997. 1490 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1491 Levkowetz, "Extensible Authentication Protocol (EAP)", 1492 RFC 3748, June 2004. 1494 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1495 Network Access Identifier", RFC 4282, December 2005. 1497 15.2. Informative References 1499 [I-D.ietf-eap-keying] 1500 Aboba, B., Simon, D., and P. Eronen, "Extensible 1501 Authentication Protocol (EAP) Key Management Framework", 1502 draft-ietf-eap-keying-22 (work in progress), 1503 November 2007. 1505 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1506 Authentication Protocol (EAP) Method Requirements for 1507 Wireless LANs", RFC 4017, March 2005. 1509 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1510 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1512 [AES] National Institute of Standards and Technology, 1513 "Specification for the Advanced Encryption Standard 1514 (AES)", Federal Information Processing Standards 1515 (FIPS) 197, November 2001. 1517 [CMAC] National Institute of Standards and Technology, 1518 "Recommendation for Block Cipher Modes of Operation: The 1519 CMAC Mode for Authentication", Special Publication 1520 (SP) 800-38B, May 2005. 1522 [CBC] National Institute of Standards and Technology, 1523 "Recommendation for Block Cipher Modes of Encryption. 1524 Methods and Techniques.", Special Publication (SP) 800- 1525 38A, December 2001. 1527 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1528 an On-line Database", RFC 3232, January 2002. 1530 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1531 Requirements for Security", BCP 106, RFC 4086, June 2005. 1533 [HM2004] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way 1534 Handshake)", Proceedings of the Third ACM International 1535 Workshop on Wireless Security (WiSe'04), Philadelphia, 1536 PA pages 43-50, October 2004. 1538 Authors' Addresses 1540 T. Charles Clancy 1541 DoD Laboratory for Telecommunications Sciences 1542 8080 Greenmead Drive 1543 College Park, MD 20740 1544 USA 1546 Email: clancy@ltsnet.net 1548 Hannes Tschofenig 1549 Nokia Siemens Networks 1550 Otto-Hahn-Ring 6 1551 Munich, Bavaria 81739 1552 Germany 1554 Email: Hannes.Tschofenig@nsn.com 1555 URI: http://www.tschofenig.com 1557 Full Copyright Statement 1559 Copyright (C) The IETF Trust (2007). 1561 This document is subject to the rights, licenses and restrictions 1562 contained in BCP 78, and except as set forth therein, the authors 1563 retain all their rights. 1565 This document and the information contained herein are provided on an 1566 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1567 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1568 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1569 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1570 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1571 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1573 Intellectual Property 1575 The IETF takes no position regarding the validity or scope of any 1576 Intellectual Property Rights or other rights that might be claimed to 1577 pertain to the implementation or use of the technology described in 1578 this document or the extent to which any license under such rights 1579 might or might not be available; nor does it represent that it has 1580 made any independent effort to identify any such rights. Information 1581 on the procedures with respect to rights in RFC documents can be 1582 found in BCP 78 and BCP 79. 1584 Copies of IPR disclosures made to the IETF Secretariat and any 1585 assurances of licenses to be made available, or the result of an 1586 attempt made to obtain a general license or permission for the use of 1587 such proprietary rights by implementers or users of this 1588 specification can be obtained from the IETF on-line IPR repository at 1589 http://www.ietf.org/ipr. 1591 The IETF invites any interested party to bring to its attention any 1592 copyrights, patents or patent applications, or other proprietary 1593 rights that may cover technology that may be required to implement 1594 this standard. Please address the information to the IETF at 1595 ietf-ipr@ietf.org. 1597 Acknowledgment 1599 Funding for the RFC Editor function is provided by the IETF 1600 Administrative Support Activity (IASA).