idnits 2.17.1 draft-ietf-emu-eap-gpsk-06.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 1485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1509. 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 (July 6, 2007) is 6111 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: January 7, 2008 Nokia Siemens Networks 6 July 6, 2007 8 EAP Generalized Pre-Shared Key (EAP-GPSK) 9 draft-ietf-emu-eap-gpsk-06 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 January 7, 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. 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 . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 105 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 14.1. Normative References . . . . . . . . . . . . . . . . . . 33 107 14.2. Informative References . . . . . . . . . . . . . . . . . 33 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 110 Intellectual Property and Copyright Statements . . . . . . . . . . 35 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 A**B: Integer exponentiation 202 truncate(A,B): Returns the first B octets of A 204 ENC_X(Y): Encryption of message Y with a symmetric key X, using a 205 defined block cipher 207 KDF_X(Y): Key Derivation Function that generates an arbitrary number 208 of octets of output using secret X and seed Y 210 length(X): Function that returns the length of input X in octets, 211 encoded as a 2-octet integer in network byte order 213 MAC_X(Y): Keyed message authentication code computed over Y with 214 symmetric key X 216 SEC_X(Y): SEC is a function that provides integrity protection based 217 on the chosen ciphersuite. The function SEC uses the algorithm 218 defined by the selected ciphersuite and applies it to the message 219 content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y). 221 X[A..B]: Notation representing octets A through B of octet array X 223 The following abbreviations are used for the keying material: 225 EMSK: Extended Master Session Key is exported by the EAP method (64 226 octets) 228 MK: Master Key between the peer and EAP server from which all other 229 EAP method session keys are derived (KS octets) 231 MSK: Master Session Key exported by the EAP method (64 octets) 233 PK: Session key generated from the MK and used during protocol 234 exchange to encrypt protected data (KS octets) 236 PSK: Long-term key shared between the peer and the server (PL 237 octets) 239 SK: Session key generated from the MK and used during protocol 240 exchange to demonstrate knowledge of the PSK (KS octets) 242 3. Overview 244 The EAP framework (see Section 1.3 of [RFC3748]) defines three basic 245 steps that occur during the execution of an EAP conversation between 246 the EAP peer, the Authenticator and the EAP server. 248 1. The first phase, discovery, is handled by the underlying 249 protocol. 250 2. The EAP authentication phase with EAP-GPSK is defined in this 251 document. 252 3. The secure association distribution and secure association phases 253 are handled differently depending on the underlying protocol. 255 EAP-GPSK performs mutual authentication between EAP peer ("Peer") and 256 EAP server ("Server") based on a pre-shared key (PSK). The protocol 257 consists of four message exchanges (GPSK-1, ..., GPSK-4), in which 258 both sides exchange nonces and their identities, compute and exchange 259 a Message Authentication Code (MAC) over the previously exchanged 260 values, keyed with the pre-shared key. This MAC is considered as 261 proof of possession of the pre-shared key. 263 A successful protocol exchange is shown in Figure 1. 265 +--------+ +--------+ 266 | | EAP-Request/Identity | | 267 | EAP |<------------------------------------| EAP | 268 | peer | | server | 269 | | EAP-Response/Identity | | 270 | |------------------------------------>| | 271 | | | | 272 | | EAP-Request/GPSK-1 | | 273 | |<------------------------------------| | 274 | | | | 275 | | EAP-Response/GPSK-2 | | 276 | |------------------------------------>| | 277 | | | | 278 | | EAP-Request/GPSK-3 | | 279 | |<------------------------------------| | 280 | | | | 281 | | EAP-Response/GPSK-4 | | 282 | |------------------------------------>| | 283 | | | | 284 | | EAP-Success | | 285 | |<------------------------------------| | 286 +--------+ +--------+ 288 Figure 1: EAP-GPSK: Successful Exchange 290 The full EAP-GPSK protocol is as follows: 292 GPSK-1: 294 ID_Server, RAND_Server, CSuite_List 296 GPSK-2: 298 SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List, 299 CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] ) 301 GPSK-3: 303 SEC_SK(RAND_Peer, RAND_Server, CSuite_Sel, [ 304 ENC_PK(PD_Payload_Block) ] ) 306 GPSK-4: 308 SEC_SK( [ ENC_PK(PD_Payload_Block) ] ) 310 The EAP server begins EAP-GPSK by selecting a random number 311 RAND_Server and by encoding the supported ciphersuites into 312 CSuite_List. A ciphersuite consists of an encryption algorithm, a 313 key derivation function and a message authentication code. 315 In GPSK-1, the EAP server sends its identity ID_Server, a random 316 number RAND_Server and a list of supported ciphersuites CSuite_List. 317 The decision which ciphersuite to offer and which ciphersuite to pick 318 is policy- and implementation-dependent and therefore outside the 319 scope of this document. 321 In GPSK-2, the peer sends its identity ID_Peer and a random number 322 RAND_Peer. Furthermore, it repeats the received parameters of the 323 GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected 324 ciphersuite. It computes a Message Authentication Code over all the 325 transmitted parameters. 327 The EAP server verifies the received Message Authentication Code. In 328 case of successful verification, the EAP server computes a Message 329 Authentication Code over the session parameter and returns it to the 330 peer (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP server 331 have the possibility to exchange encrypted protected data parameters. 333 The peer verifies the received Message Authentication Code. If the 334 verification is successful, GPSK-4 is prepared. This message can 335 optionally contain the peer's protected data parameters. 337 Upon receipt of GPSK-4, the server processes any included 338 PD_Payload_Block. Then, the EAP server sends an EAP Success message 339 to indicate the successful outcome of the authentication. 341 4. Key Derivation 343 EAP-GPSK provides key derivation in compliance to the requirements of 344 [RFC3748] and [I-D.ietf-eap-keying]. Note that this section provides 345 an abstract description for the key derivation procedure that needs 346 to be instantiated with a specific ciphersuite. 348 The long-term credential shared between EAP peer and EAP server 349 SHOULD be a strong pre-shared key PSK of at least 16 octets, though 350 its length and entropy is variable. While it is possible to use a 351 password or passphrase, doing so is NOT RECOMMENDED as it would make 352 EAP-GPSK vulnerable to dictionary attacks. 354 During an EAP-GPSK authentication, a Master Key MK, a Session Key SK 355 and a Protected Data Encryption Key PK (if using an encrypting 356 ciphersuite) are derived using the ciphersuite-specified KDF and data 357 exchanged during the execution of the protocol, namely 'RAND_Peer || 358 ID_Peer || RAND_Server || ID_Server' referred as inputString as its 359 short-hand form. 361 In case of successful completion, EAP-GPSK derives and exports an MSK 362 and EMSK both in length of 64 octets. 364 The following notation is used: KDF-X(Y, Z)[A..B], whereby 365 X is the length, in octets, of the desired output, 366 Y is a secret key, 367 Z is the inputString, 368 [A..B] extracts the string of octets starting with octet A finishing 369 with octet B from the output of the KDF function. 371 This keying material is derived using the ciphersuite-specified KDF 372 as follows: 374 o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 375 o zero = 0x00 || 0x00 || ... || 0x00 (KS times) 377 o MK = KDF-KS(zero, PL || PSK || CSuite_Sel || 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. 387 These values are defined as: 389 o zero = 0x00 || 0x00 || ... || 0x00 (KS times) 390 o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type || 391 CSuite_Sel || inputString)[0..15] 392 o Session-ID = Type_Code || Method_ID 393 o Peer-ID = ID_Peer 394 o Server-ID = ID_Server 396 EAP_Method_Type refers to the integer value of the IANA allocated EAP 397 Type code. 399 Figure 2 depicts the key derivation procedure of EAP-GPSK. 401 +-------------+ +-------------------------------+ 402 | PL-octet | | RAND_Peer || ID_Peer || | 403 | PSK | | RAND_Server || ID_Server | 404 +-------------+ +-------------------------------+ 405 | | | 406 | +------------+ | | 407 | | CSuite_Sel | | | 408 | +------------+ | | 409 | | | | 410 v v v | 411 +--------------------------------------------+ | 412 | KDF | | 413 +--------------------------------------------+ | 414 | | 415 v | 416 +-------------+ | 417 | KS-octet | | 418 | MK | | 419 +-------------+ | 420 | | 421 v v 422 +---------------------------------------------------+ 423 | KDF | 424 +---------------------------------------------------+ 425 | | | | 426 v v v v 427 +---------+ +---------+ +----------+ +----------+ 428 | 64-octet| | 64-octet| | KS-octet | | KS-octet | 429 | MSK | | EMSK | | SK | | PK | 430 +---------+ +---------+ +----------+ +----------+ 432 Figure 2: EAP-GPSK Key Derivation 434 5. Ciphersuites 436 The design of EAP-GPSK allows cryptographic algorithms and key sizes, 437 called ciphersuites, to be negotiated during the protocol run. The 438 ability to specify block-based and hash-based ciphersuites is 439 offered. Extensibility is provided with the introduction of new 440 ciphersuites; this document specifies an initial set. The CSuite/ 441 Specifier column in Figure 3 uniquely identifies a ciphersuite. 443 For a vendor-specific ciphersuite the first three octets are the 444 vendor-specific Object Identifier (OID) contains the IANA assigned 445 "SMI Network Management Private Enterprise Codes" value (see 446 [RFC3232]), encoded in network byte order. The last three octets are 447 vendor assigned for the specific ciphersuite. 449 The following ciphersuites are specified in this document: 451 +-----------+----+-------------+--------------+----------------+ 452 | CSuite/ | KS | Encryption | Integrity / | Key Derivation | 453 | Specifier | | | KDF MAC | Function | 454 +-----------+----+-------------+--------------+----------------+ 455 | 0x000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF | 456 +-----------+----+-------------+--------------+----------------+ 457 | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF | 458 +-----------+----+-------------+--------------+----------------+ 460 Figure 3: Ciphersuites 462 Ciphersuite 1, which is based on AES as a cryptographic primitive, is 463 mandatory to implement. This document specifies also a second 464 ciphersuite, but its support is optional. 466 Each ciphersuite needs to specify a key derivation function. The 467 ciphersuites defined in this document make use of the Generalized Key 468 Distribution Function (GKDF) which utilizes the MAC function defined 469 in the ciphersuite. Future ciphersuites can use any other formally 470 specified KDF that takes as arguments a key and a seed value, and 471 produces at least 128+2*KS octets of output. 473 GKDF has the following structure: 475 GKDF-X(Y, Z) 476 X length, in octets, of the desired output 477 Y secret key 478 Z inputString 480 GKDF-X (Y, Z) 481 { 482 n = ceiling integer of ( X / KS ); 483 /* determine number of output blocks */ 485 M_0 = ""; 486 result = ""; 488 for i = 1 to n { 489 M_i = MAC_Y (i || Z); 490 result = result || M_i; 491 } 493 return truncate(result, X) 494 } 496 Note that the variable 'i' in M_i is represented as a 2-octet value 497 in network byte order. 499 6. Ciphersuites Processing Rules 501 6.1. Ciphersuite #1 503 6.1.1. Encryption 505 With this ciphersuite all cryptography is built around a single 506 cryptographic primitive, AES-128 ([AES]). Within the protected data 507 frames, AES-128 is used in Cipher Block Chaining (CBC) mode of 508 operation (see [CBC]). This EAP method uses encryption in a single 509 payload, in the protected data payload (see Section 7.4). 511 In a nutshell, the CBC mode proceeds as follows. The IV is XORed 512 with the first plaintext block before it is encrypted. Then for 513 successive blocks, the previous ciphertext block is XORed with the 514 current plaintext, before it is encrypted. 516 6.1.2. Integrity 518 Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is 519 recommended by NIST. Among its advantages, CMAC is capable to work 520 with messages of arbitrary length. A detailed description of CMAC 521 can be found in [CMAC]. 523 The following instantiation is used: AES-CMAC-128(SK, Input) denotes 524 the MAC of Input under the key SK. 526 where Input refers to the following content: 528 o Value of SEC_SK(Value) in message GPSK-2 529 o Value of SEC_SK(Value) in message GPSK-3 530 o Value of SEC_SK(Value) in message GPSK-4 532 6.1.3. Key Derivation 534 This ciphersuite instantiates the KDF in the following way: 536 inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 538 zero = 0x00 || 0x00 || ... || 0x00 (16 times) 540 MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString) 542 MSK = GKDF-160 (MK, inputString)[0..63] 544 EMSK = GKDF-160 (MK, inputString)[64..127] 546 SK = GKDF-160 (MK, inputString)[128..143] 548 PK = GKDF-160 (MK, inputString)[144..159] 550 Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type || 551 CSuite_Sel || inputString) 553 6.2. Ciphersuite #2 555 6.2.1. Encryption 557 Ciphersuite 2 does not include an algorithm for encryption. With a 558 NULL encryption algorithm, encryption is defined as: 560 E_X(Y) = Y 562 When using this ciphersuite, the data exchanged inside the protected 563 data block is not encrypted. Therefore this mode MUST NOT be used if 564 confidential information appears inside the protected data block. 566 6.2.2. Integrity 568 Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash 569 algorithm (see [RFC4634]). 571 For integrity protection the following instantiation is used: 573 HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK 574 where Input refers to the following content: 576 o Value of SEC_SK(Value) in message GPSK-2 577 o Value of SEC_SK(Value) in message GPSK-3 578 o Value of SEC_SK(Value) in message GPSK-4 580 6.2.3. Key Derivation 582 This ciphersuite instantiates the KDF in the following way: 584 inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 586 zero = 0x00 || 0x00 || ... || 0x00 (32 times) 588 MK = GKDF-32 (zero, PL || PSK || CSuite_Sel || inputString) 590 MSK = GKDF-160 (MK, inputString)[0..63] 592 EMSK = GKDF-160 (MK, inputString)[64..127] 594 SK = GKDF-160 (MK, inputString)[128..159] 596 Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type || 597 CSuite_Sel || inputString) 599 7. Packet Formats 601 This section defines the packet format of the EAP-GPSK messages. 603 7.1. Header Format 605 The EAP-GPSK header has the following structure: 607 --- bit offset ---> 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Code | Identifier | Length | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Type | OP-Code | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 615 | | 616 ... Payload ... 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 5 622 The Code, Identifier, Length, and Type fields are all part of the EAP 623 header, and defined in [RFC3748]. IANA has allocated EAP Method Type 624 XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX. 626 The OP-Code field is one of four values: 628 o 0x01 : GPSK-1 629 o 0x02 : GPSK-2 630 o 0x03 : GPSK-3 631 o 0x04 : GPSK-4 632 o 0x05 : GPSK-Fail 633 o 0x06 : GPSK-Protected-Fail 634 All other values of this OP-Code field are available via IANA 635 registration. 637 7.2. Ciphersuite Formatting 639 Ciphersuites are encoded as 6-octet arrays. The first four octets 640 indicate the CSuite/Vendor field. For vendor-specific ciphersuites, 641 this represents the vendor Object Identifier (OID) contains the IANA 642 assigned "SMI Network Management Private Enterprise Codes" value (see 643 [RFC3232]), encoded in network byte order. The last two octets 644 indicate the CSuite/Specifier field, which identifies the particular 645 ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates 646 ciphersuites allocated by the IETF. 648 Graphically, they are represented as 649 --- bit offset ---> 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | CSuite/Vendor = 0x00000000 or OID | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | CSuite/Specifier | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Figure 6 660 CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and 661 CSuite/Specifier pair. 663 CSuite_List is a variable-length octet array of ciphersuites. It is 664 encoded by concatenating encoded ciphersuite values. Its length in 665 octets MUST be a multiple of 6. 667 7.3. Payload Formatting 669 Payload formatting is based on the protocol exchange description in 670 Section 3. 672 The GPSK-1 payload format is defined as follows: 674 --- bit offset ---> 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | length(ID_Server) | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 680 | | 681 ... ID_Server ... 682 | | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | | 685 ... 32-octet RAND_Server ... 686 | | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | length(CSuite_List) | | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 690 | | 691 ... CSuite_List ... 692 | | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Figure 7: GPSK-1 Payload 697 The GPSK-2 payload format is defined as follows: 699 --- bit offset ---> 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | length(ID_Peer) | | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 705 | | 706 ... ID_Peer ... 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | length(ID_Server) | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 711 | | 712 ... ID_Server ... 713 | | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | | 716 ... 32-octet RAND_Peer ... 717 | | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | | 720 ... 32-octet RAND_Server ... 721 | | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | length(CSuite_List) | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 725 | | 726 ... CSuite_List ... 727 | | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | CSuite_Sel | 730 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | | length(PD_Payload_Block) | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | | 734 ... optional PD_Payload_Block ... 735 | | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | | 738 ... KS-octet payload MAC ... 739 | | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Figure 8: GPSK-2 Payload 744 If the optional protected data payload is not included, then 745 length(PD_Payload_Block)=0 and the PD payload is excluded. 747 The GPSK-3 payload is defined as follows: 749 --- bit offset ---> 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 ... 32-octet RAND_Peer ... 755 | | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | | 758 ... 32-octet RAND_Server ... 759 | | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | CSuite_Sel | 762 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | | length(PD_Payload_Block) | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 ... optional PD_Payload_Block ... 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | | 770 ... KS-octet payload MAC ... 771 | | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Figure 9: GPSK-3 Payload 776 If the optional protected data payload is not included, then 777 length(PD_Payload_Block)=0 and the PD payload is excluded. 779 The GPSK-4 payload format is defined as follows: 781 --- bit offset ---> 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | length(PD_Payload_Block) | | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 787 | | 788 ... optional PD_Payload_Block ... 789 | | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | | 792 ... KS-octet payload MAC ... 793 | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Figure 10: GPSK-4 Payload 798 If the optional protected data payload is not included, then 799 length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC 800 MUST always be included, regardless of the presence of 801 PD_Payload_Block. 803 The GPSK-Fail payload format is defined as follows: 805 --- bit offset ---> 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Failure-Code | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Figure 11: GPSK-Fail Payload 814 The GPSK-Protected-Fail payload format is defined as follows: 816 --- bit offset ---> 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Failure-Code | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | | 823 ... KS-octet payload MAC ... 824 | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Figure 12: GPSK-Protected-Fail Payload 828 The Failure-Code field is one of three values, but can be extended: 830 o 0x00000001: PSK Not Found 831 o 0x00000002: Authentication Failure 832 o 0x00000003: Authorization Failure 833 All other values of this field are available via IANA registration. 835 "PSK Not Found" indicates a key for a particular user could not be 836 located, making authentication impossible. "Authentication Failure" 837 indicates a MAC failure due to a PSK mismatch. "Authorization 838 Failure" indicates that while the PSK being used is correct, the user 839 is not authorized to connect. 841 7.4. Protected Data 843 The protected data blocks are a generic mechanism for the peer and 844 server to securely exchange data. If the specified ciphersuite has a 845 NULL encryption primitive, then this channel only offers 846 authenticity, and not confidentiality. 848 These payloads are encoded as the concatenation of type-length-value 849 (TLV) triples called PD_Payloads. 851 Type values are encoded as a 6-octet string and represented by a 852 4-octet vendor and 2-octet specifier field. The vendor field 853 indicates the type as either standards-specified or vendor-specific. 854 If these three octets are 0x00000000, then the value is standards- 855 specified, and any other value represents a vendor-specific Object 856 Identifier (OID). 858 The specifier field indicates the actual type. For vendor field 859 0x00000000, the specifier field is maintained by IANA. For any other 860 vendor field, the specifier field is maintained by the vendor. 862 Length fields are specified as 2-octet integers in network byte 863 order, and reflect only the length of the value, and do not include 864 the length of the type and length fields. 866 Graphically, this can be depicted as follows: 868 --- bit offset ---> 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | PData/Vendor | ... 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 PData/Specifier | PData/Length | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | | 877 ... PData/Value ... 878 | | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Protected Data Payload (PD_Payload) Formatting 883 These PD_Payloads are concatenated together to form a 884 PD_Payload_Block. The If the CSuite_Sel includes support for 885 encryption, then the PD_Payload_Block includes fields specifying an 886 initialization vector (IV), and the necessary padding. This can be 887 depicted as follows: 889 --- bit offset ---> 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Initialization Vector | 894 ... (length is block size for encryption algorithm) ... 895 | | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | | 898 ... PD_Payload ... 899 | | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | | 902 ... optional PD_Payload, etc ... 903 | | 904 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | | Padding (0-255 octets) | 906 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 907 | | Pad Length | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Protected Data Block (PD_Payload_Block) Formatting if Encryption 911 Supported 913 The Initialization Vector is a randomly chosen value whose length is 914 equal to the block length of the underlying encryption algorithm. 916 Recipients MUST accept any value. Senders SHOULD either pick this 917 value pseudo-randomly and independently for each message or use the 918 final ciphertext block of the previous message sent. Senders MUST 919 NOT use the same value for each message, use a sequence of values 920 with low hamming distance (e.g., a sequence number), or use 921 ciphertext from a received message. 923 The concatenation of PD_Payloads along with the padding and padding 924 length are all encrypted using the negotiated block cipher. If no 925 block cipher is specified, then these fields are not encrypted. 927 The Padding field MAY contain any value chosen by the sender, and 928 MUST have a length that makes the combination of the concatenation of 929 PD_Payloads, the Padding, and the Pad Length to be a multiple of the 930 encryption block size. 932 The Pad Length field is the length of the Padding field. The sender 933 SHOULD set the Pad Length to the minimum value that makes the 934 combination of the PD_Payloads, the Padding, and the Pad Length a 935 multiple of the block size, but the recipient MUST accept any length 936 that results in proper alignment. This field is encrypted with the 937 negotiated cipher. 939 If the negotiated ciphersuite does not support encryption, then the 940 padding field MUST be of length zero. The padding length field MUST 941 still be present, and contain the value zero. This is depicted in 942 the following figure. 944 --- bit offset ---> 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | | 949 ... PD_Payload ... 950 | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | | 953 ... optional PD_Payload, etc +-+-+-+-+-+-+-+-+ 954 | | 0x00 | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Protected Data Block (PD_Payload_Block) Formatting Without Encryption 959 For PData/Vendor field 0x000000, the following PData/Specifier fields 960 are defined: 962 o 0x000000 : Reserved 963 o 0x000001 : Protected Results Indication 964 All other values of this field are available via IANA registration. 966 7.4.1. Protected Results Indication 968 Based on the PData/Specifier allocation the following 8-bit payload 969 is specified to be placed in the PD_Payload Value to provide the 970 functionality of protected results indication. 972 0 973 0 1 2 3 4 5 6 7 974 +-+-+-+-+-+-+-+-+ 975 |I|R|R|R|R|R|R|R| 976 +-+-+-+-+-+-+-+-+ 978 I: Result Indicator 980 The bits have the following meaning: 982 (0): Success 983 (1): Failure 985 R: Reserved 986 These bits are used for padding. 988 The 8 bits of protected results indication functionality MUST only be 989 sent in GPSK-3 from the EAP server to the EAP peer. 991 8. Packet Processing Rules 993 This section defines how the EAP peer and EAP server MUST behave when 994 received packet is deemed invalid. 996 Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP 997 server MUST be silently discarded. An EAP peer or EAP server 998 receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 999 before receiving GPSK-1 or before transmitting GPSK-2) MUST silently 1000 discard the packet. 1002 GPSK-1 contains no MAC protection, so provided it properly parses, it 1003 MUST be accepted by the peer. Note that the ciphersuite list 1004 provided by the EAP server in CSuite_List MUST always include the 1005 mandatory-to-implement ciphersuite defined in this document. Hence, 1006 there is always at least one ciphersuite in common between the EAP 1007 peer and the EAP server. If the EAP peer decides the ID_Server is 1008 that of a AAA server to which it does not wish to authenticate, the 1009 EAP peer should respond with an EAP-NAK. 1011 For GPSK-2, if ID_Peer is for an unknown user, the EAP server MUST 1012 send either a "PSK Not Found" GPSK-Fail message, or an 1013 "Authentication Failure" GPSK-Fail, depending on its policy, and 1014 discard the received packet. If the MAC validation fails, the server 1015 MUST transmit a GPSK-Fail message specifying "Authentication Failure" 1016 and discard the received packet. If the RAND_Server or CSuite_List 1017 field in GPSK-2 does not match the values in GPSK-1, the server MUST 1018 silently discard the packet. If server policy determines the peer is 1019 not authorized and the MAC is correct, the server MUST transmit a 1020 GPSK-Protected-Fail message indicating "Authorization Failure" and 1021 discard the received packet. 1023 A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in 1024 response to a GPSK-2 message MUST replay the received GPSK-Fail / 1025 GPSK-Protected-Fail message. Then, the EAP server returns an EAP- 1026 Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message 1027 to correctly finish the EAP conversation. If MAC validation on a 1028 GPSK-Protected-Fail packet fails, then the received packet MUST be 1029 silently discarded. 1031 For GPSK-3, a peer MUST silently discard messages where the 1032 RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those 1033 transmitted in GPSK-2. An EAP peer MUST silently discard any packet 1034 whose MAC fails. 1036 For GPSK-4, a server MUST silently discard any packet whose MAC fails 1037 validation. 1039 If a decryption failure of a protected payload is detected, the 1040 recipient MUST silently discard the GPSK packet. 1042 9. Example Message Exchanges 1044 This section shows a couple of example message flows. 1046 A successful EAP-GPSK message exchange is shown in Figure 1. 1048 +--------+ +--------+ 1049 | | EAP-Request/Identity | | 1050 | EAP |<------------------------------------| EAP | 1051 | peer | | server | 1052 | | EAP-Response/Identity | | 1053 | |------------------------------------>| | 1054 | | | | 1055 | | EAP-Request/GPSK-1 | | 1056 | |<------------------------------------| | 1057 | | | | 1058 | | EAP-Response/EAP-NAK | | 1059 | |------------------------------------>| | 1060 | | | | 1061 | | EAP-Failure | | 1062 | |<------------------------------------| | 1063 +--------+ +--------+ 1065 EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity; 1066 ID_Server) 1068 +--------+ +--------+ 1069 | | EAP-Request/Identity | | 1070 | EAP |<------------------------------------| EAP | 1071 | peer | | server | 1072 | | EAP-Response/Identity | | 1073 | |------------------------------------>| | 1074 | | | | 1075 | | EAP-Request/GPSK-1 | | 1076 | |<------------------------------------| | 1077 | | | | 1078 | | EAP-Response/GPSK-2 | | 1079 | |------------------------------------>| | 1080 | | | | 1081 | | EAP-Request/GPSK-3 (GPSK-Fail | | 1082 | | (PSK Not Found or Authentication | | 1083 | | Failure)) | | 1084 | |<------------------------------------| | 1085 | | | | 1086 | | EAP-Response/GPSK-4 (GPSK-Fail | | 1087 | | (PSK Not Found or Authentication | | 1088 | | Failure)) | | 1089 | |------------------------------------>| | 1090 | | | | 1091 | | EAP-Failure | | 1092 | |<------------------------------------| | 1093 +--------+ +--------+ 1094 EAP-GPSK: Unsuccessful Exchange (Unknown user) 1096 +--------+ +--------+ 1097 | | EAP-Request/Identity | | 1098 | EAP |<------------------------------------| EAP | 1099 | peer | | server | 1100 | | EAP-Response/Identity | | 1101 | |------------------------------------>| | 1102 | | | | 1103 | | EAP-Request/GPSK-1 | | 1104 | |<------------------------------------| | 1105 | | | | 1106 | | EAP-Response/GPSK-2 | | 1107 | |------------------------------------>| | 1108 | | | | 1109 | | EAP-Request/GPSK-3 (GPSK-Fail | | 1110 | | (Authentication Failure)) | | 1111 | |<------------------------------------| | 1112 | | | | 1113 | | EAP-Response/GPSK-4 (GPSK-Fail | | 1114 | | (Authentication Failure)) | | 1115 | |------------------------------------>| | 1116 | | | | 1117 | | EAP-Failure | | 1118 | |<------------------------------------| | 1119 +--------+ +--------+ 1121 EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2) 1123 +--------+ +--------+ 1124 | | EAP-Request/Identity | | 1125 | EAP |<------------------------------------| EAP | 1126 | peer | | server | 1127 | | EAP-Response/Identity | | 1128 | |------------------------------------>| | 1129 | | | | 1130 | | EAP-Request/GPSK-1 | | 1131 | |<------------------------------------| | 1132 | | | | 1133 | | EAP-Response/GPSK-2 | | 1134 | |------------------------------------>| | 1135 | | | | 1136 | | EAP-Request/GPSK-3 | | 1137 | | GPSK-Protected-Fail | | 1138 | | (Authorization Failure) | | 1139 | |<------------------------------------| | 1140 | | | | 1141 | | EAP-Request/GPSK-4 | | 1142 | | GPSK-Protected-Fail | | 1143 | | (Authorization Failure) | | 1144 | |------------------------------------>| | 1145 | | | | 1146 | | EAP-Failure | | 1147 | |<------------------------------------| | 1148 +--------+ +--------+ 1150 EAP-GPSK: Unsuccessful Exchange (Authorization failure) 1152 10. Security Considerations 1154 [RFC3748] highlights several attacks that are possible against EAP 1155 since EAP itself does not provide any security. 1157 This section discusses the claimed security properties of EAP-GPSK as 1158 well as vulnerabilities and security recommendations in the threat 1159 model of [RFC3748]. 1161 10.1. Mutual Authentication 1163 EAP-GPSK provides mutual authentication. 1165 The server believes that the peer is authentic because it can 1166 calculate a valid MAC and the peer believes that the server is 1167 authentic because it can calculate another valid MAC. 1169 The key used for mutual authentication is computed again based on the 1170 long-term secret PSK that has to provide sufficient entropy and 1171 therefore sufficient strength. In this way EAP-GPSK is not different 1172 than other authentication protocols based on pre-shared keys. 1174 10.2. Protected Result Indications 1176 EAP-GPSK offers the capability to exchange protected result 1177 indications using the protected data payloads. 1179 10.3. Integrity Protection 1181 EAP-GPSK provides integrity protection based on the ciphersuites 1182 suggested in this document. 1184 10.4. Replay Protection 1186 EAP-GPSK provides replay protection of its mutual authentication part 1187 thanks to the use of random numbers RAND_Server and RAND_Peer. Since 1188 RAND_Server is 32 octets long, one expects to have to record 2**64 1189 (i.e., approximately 1.84*10**19) EAP-GPSK successful authentication 1190 before an protocol run can be replayed. Hence, EAP-GPSK provides 1191 replay protection of its mutual authentication part as long as 1192 RAND_Server and RAND_Peer are chosen at random, randomness is 1193 critical for replay protection. 1195 10.5. Reflection attacks 1197 EAP-GPSK provides protection against reflection attacks in case of an 1198 extended authentication because the messages are constructed in a 1199 different fashion. 1201 10.6. Dictionary Attacks 1203 EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based 1204 on at least 16 octets of entropy to guarantee security against 1205 dictionary attacks. Users who use passwords are not guaranteed 1206 security against dictionary attacks. Derivation of the long-term 1207 shared secret from a password is strongly discouraged. 1209 10.7. Key Derivation 1211 EAP-GPSK supports key derivation as shown in Section 4. 1213 10.8. Denial of Service Resistance 1215 Denial of Service (DoS) resistance has not been a design goal for 1216 EAP-GPSK. 1218 It is however believed that EAP-GPSK does not provide any obvious and 1219 avoidable venue for such attacks. 1221 It is worth noting that the server has to maintain some state when it 1222 engages in an EAP-GPSK conversation, namely to generate and to 1223 remember the 32-octet RAND_Server. This should however not lead to 1224 resource exhaustion as this state and the associated computation are 1225 fairly lightweight. 1227 It is recommended that EAP-GPSK does not allow EAP notifications to 1228 be interleaved in its dialog to prevent potential DoS attacks. 1229 Indeed, since EAP Notifications are not integrity protected, they can 1230 easily be spoofed by an attacker. Such an attacker could force a 1231 peer that allows EAP Notifications to engage in a discussion which 1232 would delay his authentication or result in the peer taking 1233 unexpected actions (e.g., in case a notification is used to prompt 1234 the peer to do some "bad" action). 1236 It is up to the implementation of EAP-GPSK or to the peer and the 1237 server to specify the maximum number of failed cryptographic checks 1238 that are allowed. 1240 10.9. Session Independence 1242 Thanks to its key derivation mechanisms, EAP-GPSK provides session 1243 independence: passive attacks (such as capture of the EAP 1244 conversation) or active attacks (including compromise of the MSK or 1245 EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. 1246 The assumption that RAND_Peer and RAND_Server are random is central 1247 for the security of EAP-GPSK in general and session independence in 1248 particular. 1250 10.10. Exposition of the PSK 1252 EAP-GPSK does not provide perfect forward secrecy. Compromise of the 1253 PSK leads to compromise of recorded past sessions. 1255 Compromise of the PSK enables the attacker to impersonate the peer 1256 and the server and it allows the adversary to compromise future 1257 sessions. 1259 EAP-GPSK provides no protection against a legitimate peer sharing its 1260 PSK with a third party. Such protection may be provided by 1261 appropriate repositories for the PSK, which choice is outside the 1262 scope of this document. The PSK used by EAP-GPSK must only be shared 1263 between two parties: the peer and the server. In particular, this 1264 PSK must not be shared by a group of peers communicating with the 1265 same server. 1267 The PSK used by EAP-GPSK must be cryptographically separated from 1268 keys used by other protocols, otherwise the security of EAP-GPSK may 1269 be compromised. 1271 10.11. Fragmentation 1273 EAP-GPSK does not support fragmentation and reassembly since the 1274 message size is small. 1276 10.12. Channel Binding 1278 This document enables the ability to exchange channel binding 1279 information. It does not, however, define the encoding of channel 1280 binding information in the document. 1282 10.13. Fast Reconnect 1284 EAP-GPSK does not provide the fast reconnect capability since this 1285 method is already at (or close to) the lower limit of the number of 1286 roundtrips and the cryptographic operations. 1288 10.14. Identity Protection 1290 Identity protection is not specified in this document. Extensions 1291 can be defined that enhance this protocol to provide this feature. 1293 10.15. Protected Ciphersuite Negotiation 1295 EAP-GPSK provides protected ciphersuite negotiation via the 1296 indication of available ciphersuites by the server in the first 1297 message and a confirmation by the peer in the subsequent message. 1299 10.16. Confidentiality 1301 Although EAP-GPSK provides confidentiality in its protected data 1302 payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748]. 1304 10.17. Cryptographic Binding 1306 Since EAP-GPSK does not tunnel another EAP method, it does not 1307 implement cryptographic binding. 1309 11. IANA Considerations 1311 This document requires IANA to allocate a new EAP Type for EAP-GPSK. 1313 This document requires IANA to create a new registry for 1314 ciphersuites, protected data types, failure codes and op-codes. IANA 1315 is furthermore instructed to add the specified ciphersuites, 1316 protected data types, failure codes and op-codes to these registries 1317 as defined in this document. Values can be added or modified with 1318 informational RFCs defining either block-based or hash-based 1319 ciphersuites, protected data payloads, failure codes and op-codes. 1320 Each ciphersuite needs to provide processing rules and needs to 1321 specify how the following algorithms are instantiated: encryption, 1322 integrity, key derivation and key length. 1324 Figure 3 represents the initial ciphersuite CSuite/Specifier registry 1325 setup. The CSuite/Specifier field is 16 bits long. All other values 1326 are available via IANA registration. 1328 The following is the initial protected data PData/Specifier registry 1329 setup: 1331 o 0x000000 : Reserved 1332 o 0x000001 : Protected Results Indication 1334 The PData/Specifier field is 24 bits long and all other values are 1335 available via IANA registration. 1337 The following layout represents the initial Failure-Code registry 1338 setup: 1340 o 0x00000001: PSK Not Found 1341 o 0x00000002: Authentication Failure 1342 o 0x00000003: Authorization Failure 1344 The Failure-Code field is 32 bits long and all other values are 1345 available via IANA registration. 1347 The following layout represents the initial OP-Code registry setup: 1349 o 0x01 : GPSK-1 1350 o 0x02 : GPSK-2 1351 o 0x03 : GPSK-3 1352 o 0x04 : GPSK-4 1353 o 0x05 : GPSK-Fail 1354 o 0x06 : GPSK-Protected-Fail 1356 The OP-Code field is 8 bits long and all other values are available 1357 via IANA registration. 1359 12. Contributors 1361 This work is a joint effort of the EAP Method Update (EMU) design 1362 team of the EMU Working Group that was created to develop a mechanism 1363 based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 1364 4017 [RFC4017] requirements. The design team members (in 1365 alphabetical order) were: 1367 o Jari Arkko 1368 o Mohamad Badra 1369 o Uri Blumenthal 1370 o Charles Clancy 1371 o Lakshminath Dondeti 1372 o David McGrew 1373 o Joe Salowey 1374 o Sharma Suman 1375 o Hannes Tschofenig 1376 o Jesse Walker 1378 Finally, we would like to thank Thomas Otto for his draft reviews, 1379 feedback and text contributions. 1381 13. Acknowledgments 1383 We would like to thank 1385 o Jouni Malinen and Bernard Aboba for their early draft comments in 1386 June 2006. Jouni Malinen developed the first prototype 1387 implementation. It can be found at: 1388 http://hostap.epitest.fi/releases/snapshots/ 1389 o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela 1390 Vanderveen and Ray Bell for their input to the ciphersuite 1391 discussions between July and August 2006. 1392 o Lakshminath Dondeti for his detailed draft review (sent to the EMU 1393 ML on the 12th July 2006). 1394 o Based on a review requested from NIST Quynh Dang suggested changes 1395 to the GKDF function (December 2006). 1396 o Jouni Malinen and Victor Fajardo for their review in January 2007. 1397 o Jouni Malinen for his suggestions regarding the examples and the 1398 key derivation function in February 2007. 1399 o Bernard Aboba and Jouni Malinen for their review in February 2007. 1400 o Vidya Narayanan for her review in March 2007. 1401 o 1402 o Joe Salowey, the EMU working group chair, provided a document 1403 review in April 2007. Jouni Malinen also reviewed the document 1404 during the same month. 1406 14. References 1408 14.1. Normative References 1410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1411 Requirement Levels", BCP 14, RFC 2119, March 1997. 1413 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1414 Levkowetz, "Extensible Authentication Protocol (EAP)", 1415 RFC 3748, June 2004. 1417 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1418 Network Access Identifier", RFC 4282, December 2005. 1420 14.2. Informative References 1422 [I-D.ietf-eap-keying] 1423 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1424 Management Framework", draft-ietf-eap-keying-18 (work in 1425 progress), February 2007. 1427 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1428 Authentication Protocol (EAP) Method Requirements for 1429 Wireless LANs", RFC 4017, March 2005. 1431 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1432 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1434 [AES] National Institute of Standards and Technology, 1435 "Specification for the Advanced Encryption Standard 1436 (AES)", Federal Information Processing Standards 1437 (FIPS) 197, November 2001. 1439 [CMAC] National Institute of Standards and Technology, 1440 "Recommendation for Block Cipher Modes of Operation: The 1441 CMAC Mode for Authentication", Special Publication 1442 (SP) 800-38B, May 2005. 1444 [CBC] National Institute of Standards and Technology, 1445 "Recommendation for Block Cipher Modes of Encryption. 1446 Methods and Techniques.", Special Publication (SP) 800- 1447 38A, December 2001. 1449 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1450 an On-line Database", RFC 3232, January 2002. 1452 Authors' Addresses 1454 T. Charles Clancy 1455 DoD Laboratory for Telecommunications Sciences 1456 8080 Greenmead Drive 1457 College Park, MD 20740 1458 USA 1460 Email: clancy@ltsnet.net 1462 Hannes Tschofenig 1463 Nokia Siemens Networks 1464 Otto-Hahn-Ring 6 1465 Munich, Bavaria 81739 1466 Germany 1468 Email: Hannes.Tschofenig@nsn.com 1469 URI: http://www.tschofenig.com 1471 Full Copyright Statement 1473 Copyright (C) The IETF Trust (2007). 1475 This document is subject to the rights, licenses and restrictions 1476 contained in BCP 78, and except as set forth therein, the authors 1477 retain all their rights. 1479 This document and the information contained herein are provided on an 1480 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1481 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1482 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1483 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1484 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1485 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1487 Intellectual Property 1489 The IETF takes no position regarding the validity or scope of any 1490 Intellectual Property Rights or other rights that might be claimed to 1491 pertain to the implementation or use of the technology described in 1492 this document or the extent to which any license under such rights 1493 might or might not be available; nor does it represent that it has 1494 made any independent effort to identify any such rights. Information 1495 on the procedures with respect to rights in RFC documents can be 1496 found in BCP 78 and BCP 79. 1498 Copies of IPR disclosures made to the IETF Secretariat and any 1499 assurances of licenses to be made available, or the result of an 1500 attempt made to obtain a general license or permission for the use of 1501 such proprietary rights by implementers or users of this 1502 specification can be obtained from the IETF on-line IPR repository at 1503 http://www.ietf.org/ipr. 1505 The IETF invites any interested party to bring to its attention any 1506 copyrights, patents or patent applications, or other proprietary 1507 rights that may cover technology that may be required to implement 1508 this standard. Please address the information to the IETF at 1509 ietf-ipr@ietf.org. 1511 Acknowledgment 1513 Funding for the RFC Editor function is provided by the IETF 1514 Administrative Support Activity (IASA).