idnits 2.17.1 draft-ietf-emu-eap-gpsk-09.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 1588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1612. 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 (June 27, 2008) is 5780 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 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBC' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 11 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: December 29, 2008 Nokia Siemens Networks 6 June 27, 2008 8 EAP Generalized Pre-Shared Key (EAP-GPSK) Method 9 draft-ietf-emu-eap-gpsk-09 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 29, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 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. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 7. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 13 63 8. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13 64 8.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13 65 8.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14 66 8.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 67 8.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14 68 8.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14 69 8.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 71 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 72 9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 73 9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 16 74 9.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16 75 9.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21 77 10. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24 79 11. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25 81 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 82 12.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 29 83 12.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 29 84 12.3. Protected Result Indications . . . . . . . . . . . . . . 29 85 12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30 86 12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30 87 12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30 88 12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30 89 12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 30 90 12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31 91 12.10. Session Independence . . . . . . . . . . . . . . . . . . 31 92 12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32 93 12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32 94 12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 95 12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 32 96 12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33 97 12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33 98 12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 33 99 12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34 101 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 103 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 107 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 108 16.1. Normative References . . . . . . . . . . . . . . . . . . 36 109 16.2. Informative References . . . . . . . . . . . . . . . . . 37 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 112 Intellectual Property and Copyright Statements . . . . . . . . . . 38 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 input key size in octets of the 184 selected ciphersuite CSuite_Sel. The key size is one of the 185 ciphersuite 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 From this it should be noted that EAP-GSPK assumes the cipher key 385 input length is equal to the MAC output length. This is generally 386 true of many ciphersuites, but would prevent the definition of a 387 ciphersuite that used a one input key length and a different output 388 MAC length. 390 Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires 391 the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. 392 These values are defined as: 394 o zero = 0x00 || 0x00 || ... || 0x00 (KS times) 395 o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type || 396 CSuite_Sel || inputString)[0..15] 397 o Session-ID = Type_Code || Method_ID 398 o Peer-ID = ID_Peer 399 o Server-ID = ID_Server 401 EAP_Method_Type refers to the integer value of the IANA allocated EAP 402 Type code. 404 Figure 2 depicts the key derivation procedure of EAP-GPSK. 406 +-------------+ +-------------------------------+ 407 | PL-octet | | RAND_Peer || ID_Peer || | 408 | PSK | | RAND_Server || ID_Server | 409 +-------------+ +-------------------------------+ 410 | | | 411 | +------------+ | | 412 | | CSuite_Sel | | | 413 | +------------+ | | 414 | | | | 415 v v v | 416 +--------------------------------------------+ | 417 | KDF | | 418 +--------------------------------------------+ | 419 | | 420 v | 421 +-------------+ | 422 | KS-octet | | 423 | MK | | 424 +-------------+ | 425 | | 426 v v 427 +---------------------------------------------------+ 428 | KDF | 429 +---------------------------------------------------+ 430 | | | | 431 v v v v 432 +---------+ +---------+ +----------+ +----------+ 433 | 64-octet| | 64-octet| | KS-octet | | KS-octet | 434 | MSK | | EMSK | | SK | | PK | 435 +---------+ +---------+ +----------+ +----------+ 437 Figure 2: EAP-GPSK Key Derivation 439 5. Key Management 441 In order to be interoperable, PSKs must be entered in the same way on 442 both the peer and server. The management interface for entering PSKs 443 MUST support entering PSKs up to 64 octets in length as ASCII strings 444 and in hexadecimal encoding. 446 Additionally, the ID_Peer and ID_Server MUST be provisioned with the 447 PSK. Validation of these values is by a octet-wise comparison. Thus 448 the management interface MUST allow entering values for the ID_Peer 449 and ID_Server as ASCII strings up to 254 octets in length. 451 6. Ciphersuites 453 The design of EAP-GPSK allows cryptographic algorithms and key sizes, 454 called ciphersuites, to be negotiated during the protocol run. The 455 ability to specify block-based and hash-based ciphersuites is 456 offered. Extensibility is provided with the introduction of new 457 ciphersuites; this document specifies an initial set. The CSuite/ 458 Specifier column in Figure 3 uniquely identifies a ciphersuite. 460 For a vendor-specific ciphersuite the first four octets are the 461 vendor-specific enterprise number contains the IANA assigned "SMI 462 Network Management Private Enterprise Codes" value (see [ENTNUM]), 463 encoded in network byte order. The last two octets are vendor 464 assigned for the specific ciphersuite. A vendor code of 0x00000000 465 indicates ciphersuites standardized by IETF in an IANA-maintained 466 registry. 468 The following ciphersuites are specified in this document: 470 +-----------+----+-------------+--------------+----------------+ 471 | CSuite/ | KS | Encryption | Integrity / | Key Derivation | 472 | Specifier | | | KDF MAC | Function | 473 +-----------+----+-------------+--------------+----------------+ 474 | 0x000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF | 475 +-----------+----+-------------+--------------+----------------+ 476 | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF | 477 +-----------+----+-------------+--------------+----------------+ 479 Figure 3: Ciphersuites 481 Ciphersuite 1, which is based on AES as a cryptographic primitive, 482 MUST be implemented. This document specifies also a second 483 ciphersuite, which MAY be implemented. Both ciphersuites defined in 484 this document make use of the GKDF, as defined in Section 7. The 485 following aspects need to be considered to ensure that the PSK that 486 is used as input to the GKDF is sufficiently long (in case it is 487 longer it needs to be truncated): 489 1. The PSK used with ciphersuite 1 MUST be 128 bits in length or 490 longer. 491 2. The PSK used with ciphersuite 2 MUST be 256 bits in length or 492 longer. 493 3. It is RECOMMENDED that 256 bit keys be provisioned in all cases 494 to provide enough entropy for all current and many possible 495 future ciphersuites. 497 Ciphersuites defined in the future that make use of the GKDF need to 498 specify a minimum PSK size (as it is done with the ciphersuites 499 listed in this document). 501 7. Generalized Key Derivation Function (GKDF) 503 Each ciphersuite needs to specify a key derivation function. The 504 ciphersuites defined in this document make use of the Generalized Key 505 Derivation Function (GKDF) that utilizes the MAC function defined in 506 the ciphersuite. Future ciphersuites can use any other formally 507 specified KDF that takes as arguments a key and a seed value, and 508 produces at least 128+2*KS octets of output. 510 GKDF has the following structure: 512 GKDF-X(Y, Z) 514 X length, in octets, of the desired output 515 Y secret key 516 Z inputString 518 GKDF-X (Y, Z) 519 { 520 n = ceiling integer of ( X / KS ); 521 /* determine number of output blocks */ 523 M_0 = ""; 524 result = ""; 526 for i = 1 to n { 527 M_i = MAC_Y (i || Z); 528 result = result || M_i; 529 } 531 return truncate(result, X) 532 } 534 Note that the variable 'i' in M_i is represented as a 2-octet value 535 in network byte order. 537 8. Ciphersuites Processing Rules 539 8.1. Ciphersuite #1 540 8.1.1. Encryption 542 With this ciphersuite all cryptography is built around a single 543 cryptographic primitive, AES-128 ([AES]). Within the protected data 544 frames, AES-128 is used in Cipher Block Chaining (CBC) mode of 545 operation (see [CBC]). This EAP method uses encryption in a single 546 payload, in the protected data payload (see Section 9.4). 548 In a nutshell, the CBC mode proceeds as follows. The IV is XORed 549 with the first plaintext block before it is encrypted. Then for 550 successive blocks, the previous ciphertext block is XORed with the 551 current plaintext, before it is encrypted. 553 8.1.2. Integrity 555 Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is 556 recommended by NIST. Among its advantages, CMAC is capable to work 557 with messages of arbitrary length. A detailed description of CMAC 558 can be found in [CMAC]. 560 The following instantiation is used: AES-CMAC-128(SK, Input) denotes 561 the MAC of Input under the key SK where Input refers to the following 562 content: 564 o Parameter within SEC_SK(Parameter) in message GPSK-2 565 o Parameter within SEC_SK(Parameter) in message GPSK-3 566 o Parameter within SEC_SK(Parameter) in message GPSK-4 568 8.2. Ciphersuite #2 570 8.2.1. Encryption 572 Ciphersuite 2 does not include an algorithm for encryption. With a 573 NULL encryption algorithm, encryption is defined as: 575 E_X(Y) = Y 577 When using this ciphersuite, the data exchanged inside the protected 578 data block is not encrypted. Therefore this mode MUST NOT be used if 579 confidential information appears inside the protected data block. 581 8.2.2. Integrity 583 Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash 584 algorithm (see [RFC4634]). 586 For integrity protection the following instantiation is used: 588 HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK 589 where Input refers to the following content: 591 o Parameter within SEC_SK(Parameter) in message GPSK-2 592 o Parameter within SEC_SK(Parameter) in message GPSK-3 593 o Parameter within SEC_SK(Parameter) in message GPSK-4 595 9. Packet Formats 597 This section defines the packet format of the EAP-GPSK messages. 599 9.1. Header Format 601 The EAP-GPSK header has the following structure: 603 --- bit offset ---> 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Code | Identifier | Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type | OP-Code | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 611 | | 612 ... Payload ... 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Figure 5 618 The Code, Identifier, Length, and Type fields are all part of the EAP 619 header, and defined in [RFC3748]. The Type field in the EAP header 620 MUST be the value allocated by IANA for EAP-GPSK. 622 The OP-Code field is one of four values: 624 o 0x01 : GPSK-1 625 o 0x02 : GPSK-2 626 o 0x03 : GPSK-3 627 o 0x04 : GPSK-4 628 o 0x05 : GPSK-Fail 629 o 0x06 : GPSK-Protected-Fail 631 All other values of this OP-Code field are available via IANA 632 registration. 634 9.2. Ciphersuite Formatting 636 Ciphersuites are encoded as 6-octet arrays. The first four octets 637 indicate the CSuite/Vendor field. For vendor-specific ciphersuites, 638 this represents the vendor enterprise number and contains the IANA 639 assigned "SMI Network Management Private Enterprise Codes" value (see 640 [ENTNUM]), encoded in network byte order. The last two octets 641 indicate the CSuite/Specifier field, which identifies the particular 642 ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates 643 ciphersuites allocated by the IETF. 645 Graphically, they are represented as 647 --- bit offset ---> 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | CSuite/Vendor = 0x00000000 or enterprise number | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | CSuite/Specifier | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Figure 6 658 CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and 659 CSuite/Specifier pair. 661 CSuite_List is a variable-length octet array of ciphersuites. It is 662 encoded by concatenating encoded ciphersuite values. Its length in 663 octets MUST be a multiple of 6. 665 9.3. Payload Formatting 667 Payload formatting is based on the protocol exchange description in 668 Section 3. 670 The GPSK-1 payload format is defined as follows: 672 --- bit offset ---> 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | length(ID_Server) | | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 678 | | 679 ... ID_Server ... 680 | | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | | 683 ... 32-octet RAND_Server ... 684 | | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | length(CSuite_List) | | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 688 | | 689 ... CSuite_List ... 690 | | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Figure 7: GPSK-1 Payload 695 The GPSK-2 payload format is defined as follows: 697 --- bit offset ---> 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | length(ID_Peer) | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 703 | | 704 ... ID_Peer ... 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | length(ID_Server) | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 709 | | 710 ... ID_Server ... 711 | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | | 714 ... 32-octet RAND_Peer ... 715 | | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | | 718 ... 32-octet RAND_Server ... 719 | | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | length(CSuite_List) | | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 723 | | 724 ... CSuite_List ... 725 | | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | CSuite_Sel | 728 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | | length(PD_Payload_Block) | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | | 732 ... optional PD_Payload_Block ... 733 | | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | | 736 ... KS-octet payload MAC ... 737 | | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Figure 8: GPSK-2 Payload 742 If the optional protected data payload is not included, then 743 length(PD_Payload_Block)=0 and the PD payload is excluded. The 744 payload MAC covers the entire packet, from the ID_Client length, up 745 through the optional PD_Payload_Block. 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 | length(ID_Server) | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 763 | | 764 ... ID_Server ... 765 | | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | CSuite_Sel | 768 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | | length(PD_Payload_Block) | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | | 772 ... optional PD_Payload_Block ... 773 | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | | 776 ... KS-octet payload MAC ... 777 | | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Figure 9: GPSK-3 Payload 782 If the optional protected data payload is not included, then 783 length(PD_Payload_Block)=0 and the PD payload is excluded. The 784 payload MAC covers the entire packet, from the RAND_Peer, up through 785 the optional PD_Payload_Block. 787 The GPSK-4 payload format is defined as follows: 789 --- bit offset ---> 790 0 1 2 3 791 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | length(PD_Payload_Block) | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 795 | | 796 ... optional PD_Payload_Block ... 797 | | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | | 800 ... KS-octet payload MAC ... 801 | | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 10: GPSK-4 Payload 806 If the optional protected data payload is not included, then 807 length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC 808 MUST always be included, regardless of the presence of 809 PD_Payload_Block. The payload MAC covers the entire packet, from the 810 PD_Payload_Block length up through the optional PD_Payload_Block. 812 The GPSK-Fail payload format is defined as follows: 814 --- bit offset ---> 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Failure-Code | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Figure 11: GPSK-Fail Payload 823 The GPSK-Protected-Fail payload format is defined as follows: 825 --- bit offset ---> 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Failure-Code | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | 832 ... KS-octet payload MAC ... 833 | | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Figure 12: GPSK-Protected-Fail Payload 838 The Failure-Code field is one of three values, but can be extended: 840 o 0x00000001: PSK Not Found 841 o 0x00000002: Authentication Failure 842 o 0x00000003: Authorization Failure 843 All other values of this field are available via IANA registration. 845 "PSK Not Found" indicates a key for a particular user could not be 846 located, making authentication impossible. "Authentication Failure" 847 indicates a MAC failure due to a PSK mismatch. "Authorization 848 Failure" indicates that while the PSK being used is correct, the user 849 is not authorized to connect. 851 9.4. Protected Data 853 The protected data blocks are a generic mechanism for the peer and 854 server to securely exchange data. If the specified ciphersuite has a 855 NULL encryption primitive, then this channel only offers 856 authenticity, and not confidentiality. 858 These payloads are encoded as the concatenation of type-length-value 859 (TLV) triples called PD_Payloads. 861 Type values are encoded as a 6-octet string and represented by a 862 4-octet vendor and 2-octet specifier field. The vendor field 863 indicates the type as either standards-specified or vendor-specific. 864 If these four octets are 0x00000000, then the value is standards- 865 specified, and any other value represents a vendor-specific 866 enterprise number. 868 The specifier field indicates the actual type. For vendor field 869 0x00000000, the specifier field is maintained by IANA. For any other 870 vendor field, the specifier field is maintained by the vendor. 872 Length fields are specified as 2-octet integers in network byte 873 order, and reflect only the length of the value, and do not include 874 the length of the type and length fields. 876 Graphically, this can be depicted as follows: 878 --- bit offset ---> 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | PData/Vendor | ... 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 PData/Specifier | PData/Length | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | | 887 ... PData/Value ... 888 | | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Protected Data Payload (PD_Payload) Formatting 893 These PD_Payloads are concatenated together to form a 894 PD_Payload_Block. The If the CSuite_Sel includes support for 895 encryption, then the PD_Payload_Block includes fields specifying an 896 initialization vector (IV), and the necessary padding. This can be 897 depicted as follows: 899 --- bit offset ---> 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | IV Length | | 904 +-+-+-+-+-+-+-+-+ Initialization Vector + 905 | | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | | 908 ... PD_Payload ... 909 | | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | | 912 ... optional PD_Payload, etc ... 913 | | 914 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | | Padding (0-255 octets) | 916 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 917 | | Pad Length | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 Protected Data Block (PD_Payload_Block) Formatting if Encryption 920 Supported 922 The Initialization Vector is a randomly chosen value whose length is 923 equal to the specified IV Length. The required length is defined by 924 the ciphersuite. Recipients MUST accept any value. Senders SHOULD 925 either pick this value pseudo-randomly and independently for each 926 message or use the final ciphertext block of the previous message 927 sent. Senders MUST NOT use the same value for each message, use a 928 sequence of values with low hamming distance (e.g., a sequence 929 number), or use ciphertext from a received message. IVs should be 930 selected per the security requirements of the underlying cipher. If 931 the data is not being encrypted, then the IV Length MUST be 0. If 932 the ciphersuite does not require an IV, or has a self-contained way 933 of communicating the IV, then the IV Length field MUST be 0. In 934 these cases the ciphersuite definition defines how the IV is 935 encapsulated in the PD_Payload. 937 The concatenation of PD_Payloads along with the padding and padding 938 length are all encrypted using the negotiated block cipher. If no 939 block cipher is specified, then these fields are not encrypted. 941 The Padding field MAY contain any value chosen by the sender. For 942 block-based cipher modes, the padding MUST have a length that makes 943 the combination of the concatenation of PD_Payloads, the Padding, and 944 the Pad Length to be a multiple of the encryption block size. If the 945 underlying ciphersuite does not require padding (e.g. a stream-based 946 cipher mode) or no encryption is being used, then the padding length 947 MUST still be present and be zero. 949 The Pad Length field is the length of the Padding field. The sender 950 SHOULD set the Pad Length to the minimum value that makes the 951 combination of the PD_Payloads, the Padding, and the Pad Length a 952 multiple of the block size (in the case of block-based cipher modes), 953 but the recipient MUST accept any length that results in proper 954 alignment. This field is encrypted with the negotiated cipher. 956 If the negotiated ciphersuite does not support encryption, then the 957 IV field MUST be of length zero and padding field MUST be of length 958 zero. The IV length and padding length fields MUST still be present, 959 and contain the value zero. The rationale for still requiring the 960 length fields is to allow for modular implementations where the 961 crypto processing is independent of the payload processing. This is 962 depicted in the following figure. 964 --- bit offset ---> 965 0 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | 0x00 | | 969 +-+-+-+-+-+-+-+-+ PD_Payload ... 970 | | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | | 973 ... optional PD_Payload, etc +-+-+-+-+-+-+-+-+ 974 | | 0x00 | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Protected Data Block (PD_Payload_Block) Formatting Without Encryption 979 For PData/Vendor field 0x000000, the following PData/Specifier fields 980 are defined: 981 o 0x000000 : Reserved 982 All other values of this field are available via IANA registration. 984 10. Packet Processing Rules 986 This section defines how the EAP peer and EAP server MUST behave when 987 received packet is deemed invalid. 989 Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP 990 server MUST be silently discarded. An EAP peer or EAP server 991 receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 992 before receiving GPSK-1 or before transmitting GPSK-2) MUST silently 993 discard the packet. 995 GPSK-1 contains no MAC protection, so provided it properly parses, it 996 MUST be accepted by the peer. If the EAP peer has no ciphersuites in 997 common with the server or decides the ID_Server is that of a AAA 998 server to which it does not wish to authenticate, the EAP peer MUST 999 respond with an EAP-NAK. 1001 For GPSK-2, if ID_Peer is for an unknown user, the EAP server MUST 1002 send either a "PSK Not Found" GPSK-Fail message, or an 1003 "Authentication Failure" GPSK-Fail, depending on its policy. If the 1004 MAC validation fails, the server MUST transmit a GPSK-Fail message 1005 specifying "Authentication Failure" and discard the received packet. 1006 If the RAND_Server or CSuite_List field in GPSK-2 does not match the 1007 values in GPSK-1, the server MUST silently discard the packet. If 1008 server policy determines the peer is not authorized and the MAC is 1009 correct, the server MUST transmit a GPSK-Protected-Fail message 1010 indicating "Authorization Failure" and discard the received packet. 1012 A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in 1013 response to a GPSK-2 message MUST replay the received GPSK-Fail / 1014 GPSK-Protected-Fail message. Then, the EAP server returns an EAP- 1015 Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message 1016 to correctly finish the EAP conversation. If MAC validation on a 1017 GPSK-Protected-Fail packet fails, then the received packet MUST be 1018 silently discarded. 1020 For GPSK-3, a peer MUST silently discard messages where the 1021 RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those 1022 transmitted in GPSK-2. An EAP peer MUST silently discard any packet 1023 whose MAC fails. 1025 For GPSK-4, a server MUST silently discard any packet whose MAC fails 1026 validation. 1028 If a decryption failure of a protected payload is detected, the 1029 recipient MUST silently discard the GPSK packet. 1031 11. Example Message Exchanges 1033 This section shows a couple of example message flows. 1035 A successful EAP-GPSK message exchange is shown in Figure 1. 1037 +--------+ +--------+ 1038 | | EAP-Request/Identity | | 1039 | EAP |<------------------------------------| EAP | 1040 | peer | | server | 1041 | | EAP-Response/Identity | | 1042 | |------------------------------------>| | 1043 | | | | 1044 | | EAP-Request/GPSK-1 | | 1045 | |<------------------------------------| | 1046 | | | | 1047 | | EAP-Response/EAP-NAK | | 1048 | |------------------------------------>| | 1049 | | | | 1050 | | EAP-Failure | | 1051 | |<------------------------------------| | 1052 +--------+ +--------+ 1054 EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity; 1055 ID_Server) 1057 +--------+ +--------+ 1058 | | EAP-Request/Identity | | 1059 | EAP |<------------------------------------| EAP | 1060 | peer | | server | 1061 | | EAP-Response/Identity | | 1062 | |------------------------------------>| | 1063 | | | | 1064 | | EAP-Request/GPSK-1 | | 1065 | |<------------------------------------| | 1066 | | | | 1067 | | EAP-Response/GPSK-2 | | 1068 | |------------------------------------>| | 1069 | | | | 1070 | | EAP-Request/GPSK-3 (GPSK-Fail | | 1071 | | (PSK Not Found or Authentication | | 1072 | | Failure)) | | 1073 | |<------------------------------------| | 1074 | | | | 1075 | | EAP-Response/GPSK-4 (GPSK-Fail | | 1076 | | (PSK Not Found or Authentication | | 1077 | | Failure)) | | 1078 | |------------------------------------>| | 1079 | | | | 1080 | | EAP-Failure | | 1081 | |<------------------------------------| | 1082 +--------+ +--------+ 1084 EAP-GPSK: Unsuccessful Exchange (Unknown user) 1086 +--------+ +--------+ 1087 | | EAP-Request/Identity | | 1088 | EAP |<------------------------------------| EAP | 1089 | peer | | server | 1090 | | EAP-Response/Identity | | 1091 | |------------------------------------>| | 1092 | | | | 1093 | | EAP-Request/GPSK-1 | | 1094 | |<------------------------------------| | 1095 | | | | 1096 | | EAP-Response/GPSK-2 | | 1097 | |------------------------------------>| | 1098 | | | | 1099 | | EAP-Request/GPSK-3 (GPSK-Fail | | 1100 | | (Authentication Failure)) | | 1101 | |<------------------------------------| | 1102 | | | | 1103 | | EAP-Response/GPSK-4 (GPSK-Fail | | 1104 | | (Authentication Failure)) | | 1105 | |------------------------------------>| | 1106 | | | | 1107 | | EAP-Failure | | 1108 | |<------------------------------------| | 1109 +--------+ +--------+ 1111 EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2) 1113 +--------+ +--------+ 1114 | | EAP-Request/Identity | | 1115 | EAP |<------------------------------------| EAP | 1116 | peer | | server | 1117 | | EAP-Response/Identity | | 1118 | |------------------------------------>| | 1119 | | | | 1120 | | EAP-Request/GPSK-1 | | 1121 | |<------------------------------------| | 1122 | | | | 1123 | | EAP-Response/GPSK-2 | | 1124 | |------------------------------------>| | 1125 | | | | 1126 | | EAP-Request/GPSK-3 | | 1127 | | GPSK-Protected-Fail | | 1128 | | (Authorization Failure) | | 1129 | |<------------------------------------| | 1130 | | | | 1131 | | EAP-Request/GPSK-4 | | 1132 | | GPSK-Protected-Fail | | 1133 | | (Authorization Failure) | | 1134 | |------------------------------------>| | 1135 | | | | 1136 | | EAP-Failure | | 1137 | |<------------------------------------| | 1138 +--------+ +--------+ 1140 EAP-GPSK: Unsuccessful Exchange (Authorization failure) 1142 12. Security Considerations 1144 [RFC3748] highlights several attacks that are possible against EAP 1145 since EAP itself does not provide any security. 1147 This section discusses the claimed security properties of EAP-GPSK as 1148 well as vulnerabilities and security recommendations in the threat 1149 model of [RFC3748]. 1151 12.1. Security Claims 1153 Auth. mechanism: Shared Keys 1154 Ciphersuite negotiation: Yes (section 11.15) 1155 Mutual authentication: Yes (section 11.1) 1156 Integrity protection: Yes (section 11.3) 1157 Replay protection: Yes (section 11.4) 1158 Confidentiality: No (section 11.14 and 11.16) 1159 Key derivation: Yes (section 11.7) 1160 Key strength: Varies (section 11.7) 1161 Dictionary attack prot.: No (section 11.6) 1162 Fast reconnect: No (section 11.13) 1163 Crypt. binding: N/A (section 11.17) 1164 Session independence: Yes (section 11.9) 1165 Fragmentation: No (section 11.11) 1166 Channel binding: Extensible (section 11.12) 1168 12.2. Mutual Authentication 1170 EAP-GPSK provides mutual authentication. 1172 The server believes that the peer is authentic when it successfully 1173 verifies the MAC in the GPSK-2 message and the peer believes that the 1174 server is authentic when it successfully verifies the MAC it receives 1175 with the GPSK-3 message. 1177 The key used for mutual authentication is derived based on the long- 1178 term secret PSK, nonces contributed by both parties and other 1179 parameters. The long-term secret PSK has to provide sufficient 1180 entropy and therefore sufficient strength. The nonces (RAND_Peer and 1181 RAND_Server) need to be fresh and unique for every session. In this 1182 way EAP-GPSK is not different than other authentication protocols 1183 based on pre-shared keys. 1185 12.3. Protected Result Indications 1187 EAP-GPSK supports protected results indication via the GPSK- 1188 Protected-Fail message. This allows a server to provide additional 1189 information to the peer as to why the session failed, and do so in an 1190 authenticated way (if possible). In particular, the server can 1191 indicate the lack of PSK (account not present), failed authentication 1192 (PSK incorrect), or authorization failure (account disabled or 1193 unauthorized). Only the third message could be integrity protected. 1195 It should be noted that these options make debugging network and 1196 account errors easier, but also leak information about accounts to 1197 attackers. An attacker can determine if a particular ID_Peer is a 1198 valid user on the network, or not. Thus implementers should use care 1199 in enabling this particular option on their servers. If they are in 1200 an environment where such attacks are of concern, then protected 1201 result indication capabilities should be disabled. 1203 12.4. Integrity Protection 1205 EAP-GPSK provides integrity protection based on the ciphersuites 1206 suggested in this document. Integrity protection is a minimum 1207 feature every ciphersuite must provide. 1209 12.5. Replay Protection 1211 EAP-GPSK provides replay protection of its mutual authentication part 1212 thanks to the use of random numbers RAND_Server and RAND_Peer. Since 1213 RAND_Server is 32 octets long, one expects to have to record 2**64 1214 (i.e., approximately 1.84*10**19) EAP-GPSK successful authentication 1215 before an protocol run can be replayed. Hence, EAP-GPSK provides 1216 replay protection of its mutual authentication part as long as 1217 RAND_Server and RAND_Peer are chosen at random, randomness is 1218 critical for replay protection. RFC 4086 [RFC4086] describes 1219 techniques for producing random quantities. 1221 12.6. Reflection attacks 1223 EAP-GPSK provides protection against reflection attacks in case of an 1224 extended authentication because the messages are constructed in a 1225 different fashion. 1227 Also note that EAP-GPSK does not provide MAC protection of the OP- 1228 Code field, but again since each message is constructed differently, 1229 it would not be possible to change the OP-Code of a valid message and 1230 still have it be parseable and accepted by the recipient. 1232 12.7. Dictionary Attacks 1234 EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be 1235 based on at least 16 octets of entropy to be fully secure. The EAP- 1236 GPSK protocol makes no special provisions to ensure keys based on 1237 passwords are used securely. Users who use passwords as the basis of 1238 their PSK are not protected against dictionary attacks. Derivation 1239 of the long-term shared secret from a password is strongly 1240 discouraged. 1242 12.8. Key Derivation and Key Strength 1244 EAP-GPSK supports key derivation as shown in Section 4. 1246 Keys used within EAP-GPSK are all based on the security of the 1247 originating PSK. PSKs SHOULD have at least 16 octets of entropy. 1248 Independent of the protocol exchange (i.e. without knowing RAND_Peer 1249 and RAND_Server), the keys have been derived with sufficient input 1250 entropy to make them as secure as the underlying KDF output key 1251 length. 1253 12.9. Denial of Service Resistance 1255 There are three forms of denial of service attacks relevant for this 1256 document, namely (1) attacks that lead to vast amount of state being 1257 allocated, (2) attacks that attempt to prevent communication between 1258 the peer and server, and (3) attacks against computational resources. 1260 In an EAP-GPSK conversation the server has to maintain state, namely 1261 the 32-octet RAND_Server, when transmitting the GPSK-1 message to the 1262 peer. An adversary could therefore flood a server with a large 1263 number of EAP-GPSK communication attempts. An EAP server may 1264 therefore ensure that established state times out after a relatively 1265 short period of time when no further messages are received. This 1266 enables a sort of garbage collection. 1268 The client has to keep state information after receiving the GPSK-1 1269 message. To prevent a replay attack, all the client need do is 1270 ensure that the value of RAND_Peer is consistent between GPSK-2 and 1271 GPSK-3. Message GPSK-3 contains all the material required to re- 1272 compute the keying material. Thus a client need only maintain 1273 minimal state (RAND_Peer) between GPSK-2 and GPSK-3. 1275 Attacks that disrupt communication between the peer and server are 1276 mitigated by silently discarding messages with invalid MACs. Attacks 1277 against computational resources are mitigated by having very light- 1278 weight cryptographic operations required during each protocol round. 1280 The security considerations of EAP itself, see Section 5.2 and 1281 Section 7 of RFC 3748 [RFC3748], are also applicable to this 1282 specification (e.g., for example concerning EAP-based notifications). 1284 12.10. Session Independence 1286 Thanks to its key derivation mechanisms, EAP-GPSK provides session 1287 independence: passive attacks (such as capture of the EAP 1288 conversation) or active attacks (including compromise of the MSK or 1289 EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. 1290 The assumption that RAND_Peer and RAND_Server are random is central 1291 for the security of EAP-GPSK in general and session independence in 1292 particular. 1294 12.11. Compromise of the PSK 1296 EAP-GPSK does not provide perfect forward secrecy. Compromise of the 1297 PSK leads to compromise of recorded past sessions. 1299 Compromise of the PSK enables the attacker to impersonate the peer 1300 and the server and it allows the adversary to compromise future 1301 sessions. 1303 EAP-GPSK provides no protection against a legitimate peer sharing its 1304 PSK with a third party. Such protection may be provided by 1305 appropriate repositories for the PSK, which choice is outside the 1306 scope of this document. The PSK used by EAP-GPSK must only be shared 1307 between two parties: the peer and the server. In particular, this 1308 PSK must not be shared by a group of peers (e.g. those with different 1309 ID_Peer values) communicating with the same server. 1311 The PSK used by EAP-GPSK must be cryptographically separated from 1312 keys used by other protocols, otherwise the security of EAP-GPSK may 1313 be compromised. 1315 12.12. Fragmentation 1317 EAP-GPSK does not support fragmentation and reassembly since the 1318 message size is relatively small. However it should be noted that 1319 this impacts the length of protected data payloads that can be 1320 attached to messages. Also if the EAP frame is larger than the MTU 1321 of the underlying transport, and that transport does not support 1322 fragmentation, the frame will most likely not be transported. 1323 Consequently implementors and deployers should take care to ensure 1324 EAP-GPSK frames are short enough to work properly on the target 1325 underlying transport mechanism. 1327 12.13. Channel Binding 1329 This document enables the ability to exchange channel binding 1330 information. It does not, however, define the encoding of channel 1331 binding information in the document. 1333 12.14. Fast Reconnect 1335 EAP-GPSK does not provide the fast reconnect capability since this 1336 method is already at (or close to) the lower limit of the number of 1337 roundtrips and the cryptographic operations. 1339 12.15. Identity Protection 1341 Identity protection is not specified in this document. Extensions 1342 can be defined that enhance this protocol to provide this feature. 1344 12.16. Protected Ciphersuite Negotiation 1346 EAP-GPSK provides protected ciphersuite negotiation via the 1347 indication of available ciphersuites by the server in the first 1348 message and a confirmation by the peer in the subsequent message. 1350 Note, however, that the GPSK-2 message may optionally contain a 1351 payload, ENC_PK(PD_Payload_Block), protected with an algorithm based 1352 on a selected ciphersuite before the ciphersuite list has actually 1353 been authenticated. In the classical downgrading attack an adversary 1354 would chose a ciphersuite that it weak enough to that it could break 1355 it in real-time or to turn security off. The latter is not possible 1356 since any ciphersuite defined for EAP-GPSK must at least provide 1357 authentication and integrity protection. Confidentiality protection 1358 is optional. When, some time in the future, a ciphersuite contains 1359 algorithms that can be broken in real-time then a policy on peers and 1360 the server needs to indicate that such a ciphersuite must not be 1361 selected by any of parties. 1363 Furthermore, an adversary may modify the selection of the ciphersuite 1364 to for the client to select a ciphersuite that does not provide 1365 confidentiality protection. As a result this would cause the content 1366 of PD_Payload_Block to be transmitted in cleartext. When protocol 1367 designers extend EAP-GPSK to carry information in the 1368 PD_Payload_Block of the GPSK-2 message then it must be indicated 1369 whether confidentiality protection is mandatory. In case such an 1370 extension requires a ciphersuite with confidentiality protection then 1371 the policy at the peer must not transmit information of that 1372 extension in the PD_Payload_Block of the GPSK-2 message. The peer 1373 may, if possible, delay the transmission of this information element 1374 to the GPSK-4 message where the ciphersuite negotiation has been 1375 confirmed already. In general, when a ciphersuite is selected that 1376 does not provide confidentiality protection then information that 1377 demands confidentiality protection must not be included in any of the 1378 PD_Payload_Block objects. 1380 12.17. Confidentiality 1382 Although EAP-GPSK provides confidentiality in its protected data 1383 payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748] 1384 since it does not support identity protection. 1386 12.18. Cryptographic Binding 1388 Since EAP-GPSK does not tunnel another EAP method, it does not 1389 implement cryptographic binding. 1391 13. IANA Considerations 1393 This document requires IANA to allocate a new EAP Type for EAP-GPSK. 1395 This document requires IANA to create a new registry for 1396 ciphersuites, protected data types, failure codes and op-codes. IANA 1397 is furthermore instructed to add the specified ciphersuites, 1398 protected data types, failure codes and op-codes to these registries 1399 as defined below. Values can be added or modified per IETF CONSENSUS 1400 [RFC2434] defining either block-based or hash-based ciphersuites, 1401 protected data payloads, failure codes and op-codes. Each 1402 ciphersuite needs to provide processing rules and needs to specify 1403 how the following algorithms are instantiated: encryption, integrity, 1404 key derivation and key length. 1406 Figure 3 represents the initial ciphersuite CSuite/Specifier registry 1407 setup. The CSuite/Specifier field is 16 bits long. All other values 1408 are available via IANA registration. This registry should be named 1409 "EAP-GPSK Ciphersuites". 1411 The following is the initial protected data PData/Specifier registry 1412 setup, which should be named "EAP-GPSK Protected Data Payloads": 1414 o 0x000000 : Reserved 1416 The PData/Specifier field is 24 bits long and all other values are 1417 available via IANA registration. Each extension needs to indicate 1418 whether confidentiality protection for transmission between the EAP 1419 peer and the EAP server is mandatory. 1421 The following layout represents the initial Failure-Code registry 1422 setup, which should be named "EAP-GPSK Failure Codes": 1424 o 0x00000001: PSK Not Found 1425 o 0x00000002: Authentication Failure 1426 o 0x00000003: Authorization Failure 1428 The Failure-Code field is 32 bits long and all other values are 1429 available via IANA registration. 1431 The following layout represents the initial OP-Code registry setup, 1432 which should be named "EAP-GPSK OP Codes": 1434 o 0x01 : GPSK-1 1435 o 0x02 : GPSK-2 1436 o 0x03 : GPSK-3 1437 o 0x04 : GPSK-4 1438 o 0x05 : GPSK-Fail 1439 o 0x06 : GPSK-Protected-Fail 1441 The OP-Code field is 8 bits long and all other values are available 1442 via IANA registration. 1444 14. Contributors 1446 This work is a joint effort of the EAP Method Update (EMU) design 1447 team of the EMU Working Group that was created to develop a mechanism 1448 based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 1449 4017 [RFC4017] requirements. The design team members (in 1450 alphabetical order) were: 1452 o Jari Arkko 1453 o Mohamad Badra 1454 o Uri Blumenthal 1455 o Charles Clancy 1456 o Lakshminath Dondeti 1457 o David McGrew 1458 o Joe Salowey 1459 o Sharma Suman 1460 o Hannes Tschofenig 1461 o Jesse Walker 1463 Finally, we would like to thank Thomas Otto for his draft reviews, 1464 feedback and text contributions. 1466 15. Acknowledgments 1468 We would like to thank 1470 o Jouni Malinen and Bernard Aboba for their early draft comments in 1471 June 2006. Jouni Malinen developed the first prototype 1472 implementation. It can be found at: 1473 http://hostap.epitest.fi/releases/snapshots/ 1474 o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela 1475 Vanderveen and Ray Bell for their input to the ciphersuite 1476 discussions between July and August 2006. 1477 o Lakshminath Dondeti for his detailed draft review (sent to the EMU 1478 ML on the 12th July 2006). 1480 o Based on a review requested from NIST Quynh Dang suggested changes 1481 to the GKDF function (December 2006). 1482 o Jouni Malinen and Victor Fajardo for their review in January 2007. 1483 o Jouni Malinen for his suggestions regarding the examples and the 1484 key derivation function in February 2007. 1485 o Bernard Aboba and Jouni Malinen for their review in February 2007. 1486 o Vidya Narayanan for her review in March 2007. 1487 o 1488 o Joe Salowey, the EMU working group chair, provided a document 1489 review in April 2007. Jouni Malinen also reviewed the document 1490 during the same month. 1491 o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov 1492 and Prof. John C. Mitchell for their analysis of EAP-GPSK and for 1493 pointing us to a client-side DoS attack, a downgrading attack and 1494 their input to the key derivation function. Based on their input 1495 the key derivation function has been modified and the text in the 1496 security consideration section has been updated. 1497 o Finally, we would like to thank our working group chair, Joe 1498 Salowey, for his support and for the time he spend on discussing 1499 open issues with us. 1501 16. References 1503 16.1. Normative References 1505 [I-D.ietf-eap-keying] 1506 Aboba, B., Simon, D., and P. Eronen, "Extensible 1507 Authentication Protocol (EAP) Key Management Framework", 1508 draft-ietf-eap-keying-22 (work in progress), 1509 November 2007. 1511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1512 Requirement Levels", BCP 14, RFC 2119, March 1997. 1514 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1515 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1516 October 1998. 1518 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1519 Levkowetz, "Extensible Authentication Protocol (EAP)", 1520 RFC 3748, June 2004. 1522 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1523 Network Access Identifier", RFC 4282, December 2005. 1525 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1526 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1528 [AES] National Institute of Standards and Technology, 1529 "Specification for the Advanced Encryption Standard 1530 (AES)", Federal Information Processing Standards 1531 (FIPS) 197, November 2001. 1533 [CMAC] National Institute of Standards and Technology, 1534 "Recommendation for Block Cipher Modes of Operation: The 1535 CMAC Mode for Authentication", Special Publication 1536 (SP) 800-38B, May 2005. 1538 [CBC] National Institute of Standards and Technology, 1539 "Recommendation for Block Cipher Modes of Encryption. 1540 Methods and Techniques.", Special Publication (SP) 800- 1541 38A, December 2001. 1543 16.2. Informative References 1545 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1546 Authentication Protocol (EAP) Method Requirements for 1547 Wireless LANs", RFC 4017, March 2005. 1549 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1550 Requirements for Security", BCP 106, RFC 4086, June 2005. 1552 [ENTNUM] IANA, "SMI Network Management Private Enterprise Codes", 1553 IANA Assignments enterprise-numbers. 1555 Authors' Addresses 1557 T. Charles Clancy 1558 DoD Laboratory for Telecommunications Sciences 1559 8080 Greenmead Drive 1560 College Park, MD 20740 1561 USA 1563 Email: clancy@ltsnet.net 1565 Hannes Tschofenig 1566 Nokia Siemens Networks 1567 Otto-Hahn-Ring 6 1568 Munich, Bavaria 81739 1569 Germany 1571 Email: Hannes.Tschofenig@nsn.com 1572 URI: http://www.tschofenig.com 1574 Full Copyright Statement 1576 Copyright (C) The IETF Trust (2008). 1578 This document is subject to the rights, licenses and restrictions 1579 contained in BCP 78, and except as set forth therein, the authors 1580 retain all their rights. 1582 This document and the information contained herein are provided on an 1583 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1584 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1585 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1586 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1587 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1588 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1590 Intellectual Property 1592 The IETF takes no position regarding the validity or scope of any 1593 Intellectual Property Rights or other rights that might be claimed to 1594 pertain to the implementation or use of the technology described in 1595 this document or the extent to which any license under such rights 1596 might or might not be available; nor does it represent that it has 1597 made any independent effort to identify any such rights. Information 1598 on the procedures with respect to rights in RFC documents can be 1599 found in BCP 78 and BCP 79. 1601 Copies of IPR disclosures made to the IETF Secretariat and any 1602 assurances of licenses to be made available, or the result of an 1603 attempt made to obtain a general license or permission for the use of 1604 such proprietary rights by implementers or users of this 1605 specification can be obtained from the IETF on-line IPR repository at 1606 http://www.ietf.org/ipr. 1608 The IETF invites any interested party to bring to its attention any 1609 copyrights, patents or patent applications, or other proprietary 1610 rights that may cover technology that may be required to implement 1611 this standard. Please address the information to the IETF at 1612 ietf-ipr@ietf.org. 1614 Acknowledgment 1616 Funding for the RFC Editor function is provided by the IETF 1617 Administrative Support Activity (IASA).