idnits 2.17.1 draft-ietf-emu-eap-gpsk-17.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 1621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1645. 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 (November 19, 2008) is 5634 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- 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: May 23, 2009 Nokia Siemens Networks 6 November 19, 2008 8 EAP Generalized Pre-Shared Key (EAP-GPSK) Method 9 draft-ietf-emu-eap-gpsk-17 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 May 23, 2009. 36 Abstract 38 This Internet Draft defines an Extensible Authentication Protocol 39 (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This 40 method is a lightweight shared-key authentication protocol supporting 41 mutual authentication and key derivation. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 51 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 53 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11 55 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 12 57 7. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 13 59 8. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13 60 8.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13 61 8.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14 62 8.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 63 8.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14 64 8.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14 65 8.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 67 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 68 9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 69 9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 16 70 9.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16 71 9.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21 73 10. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24 75 11. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 78 12.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 28 79 12.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 29 80 12.3. Protected Result Indications . . . . . . . . . . . . . . 29 81 12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30 82 12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30 83 12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30 84 12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30 85 12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 31 86 12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31 87 12.10. Session Independence . . . . . . . . . . . . . . . . . . 32 88 12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32 89 12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32 90 12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 91 12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 33 92 12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33 93 12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33 94 12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 34 95 12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34 97 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 99 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 101 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 103 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 16.1. Normative References . . . . . . . . . . . . . . . . . . 36 105 16.2. Informative References . . . . . . . . . . . . . . . . . 37 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 108 Intellectual Property and Copyright Statements . . . . . . . . . . 39 110 1. Introduction 112 EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a 113 generalized pre-shared key authentication technique. Mutual 114 authentication is achieved through a nonce-based exchange that is 115 secured by a pre-shared key. 117 EAP-GPSK addresses a large number of design goals with the intention 118 of being applicable in a broad range of usage scenarios. 120 The main design goals of EAP-GPSK are 122 Simplicity: 124 EAP-GPSK should be easy to implement. 126 Security Model: 128 EAP-GPSK has been designed in a threat model where the attacker 129 has full control over the communication channel. This is the EAP 130 threat model that is presented in Section 7.1 of [RFC3748]. 132 Efficiency: 134 EAP-GPSK does not make use of public key cryptography and fully 135 relies of symmetric cryptography. The restriction of symmetric 136 cryptographic computations allows for low computational overhead. 137 Hence, EAP-GPSK is lightweight and well suited for any type of 138 device, especially those with processing power, memory and battery 139 constraints. Additionally it seeks to minimize the number of 140 round trips. 142 Flexibility: 144 EAP-GPSK offers cryptographic flexibility. At the beginning, the 145 EAP server proposes a list of ciphersuites. The client then 146 selects one. The current version of EAP-GPSK includes two 147 ciphersuites, but additional ones can be easily added. 149 Extensibility: 151 The design of EAP-GPSK allows to securely exchange information 152 between the EAP peer and the EAP server using protected data 153 fields. These fields might, for example, be used to exchange 154 channel binding information or to provide support for identity 155 confidentiality. 157 2. Terminology 159 In this document, several words are used to signify the requirements 160 of the specification. These words are often capitalized. The key 161 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 162 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 163 are to be interpreted as described in [RFC2119]. 165 This section describes the various variables and functions used in 166 the EAP-GPSK method. 168 Variables: 170 CSuite_List: An octet array listing available ciphersuites (variable 171 length) 173 CSuite_Sel: Ciphersuite selected by the peer (6 octets) 175 ID_Peer: Peer NAI [RFC4282] 177 ID_Server: Server identity as an opaque blob. 179 KS: Integer representing the input key size in octets of the 180 selected ciphersuite CSuite_Sel. The key size is one of the 181 ciphersuite parameters. 183 ML: Integer representing the length of the MAC output, in octets, of 184 the selected ciphersuite CSuite_Sel. 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). 192 PL MUST be larger than or equal to KS. 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 204 truncate(A,B): Returns the first B octets of A 206 ENC_X(Y): Encryption of message Y with a symmetric key X, using a 207 defined block cipher 209 KDF-X(Y): Key Derivation Function that generates an arbitrary number 210 of octets of output using secret X and seed Y 212 length(X): Function that returns the length of input X in octets, 213 encoded as a 2-octet integer in network byte order 215 MAC_X(Y): Keyed message authentication code computed over Y with 216 symmetric key X 218 SEC_X(Y): SEC is a function that provides integrity protection based 219 on the chosen ciphersuite. The function SEC uses the algorithm 220 defined by the selected ciphersuite and applies it to the message 221 content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y). 223 X[A..B]: Notation representing octets A through B of octet array X 224 where the first octet of the array has index zero 226 The following abbreviations are used for the keying material: 228 EMSK: Extended Master Session Key is exported by the EAP method (64 229 octets) 231 MK: A session-specific Master Key between the peer and EAP server 232 from which all other EAP method session keys are derived (KS 233 octets) 235 MSK: Master Session Key exported by the EAP method (64 octets) 237 PK: Session key generated from the MK and used during protocol 238 exchange to encrypt protected data (KS octets) 240 PSK: Long-term key shared between the peer and the server (PL 241 octets) 243 SK: Session key generated from the MK and used during protocol 244 exchange to demonstrate knowledge of the PSK (KS octets) 246 3. Overview 248 The EAP framework (see Section 1.3 of [RFC3748]) defines three basic 249 steps that occur during the execution of an EAP conversation between 250 the EAP peer, the Authenticator and the EAP server. 252 1. The first phase, discovery, is handled by the underlying 253 protocol, e.g. IEEE 802.1X as utilized by IEEE 802.11 [80211]. 254 2. The EAP authentication phase with EAP-GPSK is defined in this 255 document. 256 3. The secure association distribution and secure association phases 257 are handled differently depending on the underlying protocol. 259 EAP-GPSK performs mutual authentication between EAP peer ("Peer") and 260 EAP server ("Server") based on a pre-shared key (PSK). The protocol 261 consists of the message exchanges (GPSK-1, ..., GPSK-4), in which 262 both sides exchange nonces and their identities, compute and exchange 263 a Message Authentication Code (MAC) over the previously exchanged 264 values, keyed with the pre-shared key. This MAC is considered as 265 proof of possession of the pre-shared key. Two further messages, 266 namely GPSK-Fail and GPSK-Protected-Fail are used to deal with error 267 situations. 269 A successful protocol exchange is shown in Figure 1. 271 +--------+ +--------+ 272 | | EAP-Request/Identity | | 273 | EAP |<------------------------------------| EAP | 274 | peer | | server | 275 | | EAP-Response/Identity | | 276 | |------------------------------------>| | 277 | | | | 278 | | EAP-Request/GPSK-1 | | 279 | |<------------------------------------| | 280 | | | | 281 | | EAP-Response/GPSK-2 | | 282 | |------------------------------------>| | 283 | | | | 284 | | EAP-Request/GPSK-3 | | 285 | |<------------------------------------| | 286 | | | | 287 | | EAP-Response/GPSK-4 | | 288 | |------------------------------------>| | 289 | | | | 290 | | EAP-Success | | 291 | |<------------------------------------| | 292 +--------+ +--------+ 294 Figure 1: EAP-GPSK: Successful Exchange 296 The full EAP-GPSK protocol is as follows: 298 GPSK-1: 300 ID_Server, RAND_Server, CSuite_List 302 GPSK-2: 304 SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List, 305 CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] ) 307 GPSK-3: 309 SEC_SK(RAND_Peer, RAND_Server, ID_Server, CSuite_Sel, [ 310 ENC_PK(PD_Payload_Block) ] ) 312 GPSK-4: 314 SEC_SK( [ ENC_PK(PD_Payload_Block) ] ) 316 The EAP server begins EAP-GPSK by selecting a random number 317 RAND_Server and by encoding the supported ciphersuites into 318 CSuite_List. A ciphersuite consists of an encryption algorithm, a 319 key derivation function and a message authentication code. 321 In GPSK-1, the EAP server sends its identity ID_Server, a random 322 number RAND_Server and a list of supported ciphersuites CSuite_List. 323 The decision which ciphersuite to offer and which ciphersuite to pick 324 is policy- and implementation-dependent and therefore outside the 325 scope of this document. 327 In GPSK-2, the peer sends its identity ID_Peer and a random number 328 RAND_Peer. Furthermore, it repeats the received parameters of the 329 GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected 330 ciphersuite. It computes a Message Authentication Code over all the 331 transmitted parameters. 333 The EAP server verifies the received Message Authentication Code, and 334 consistency of the identities, nonces, and ciphersuite parameters 335 transmitted in GPSK-1. In case of successful verification, the EAP 336 server computes a Message Authentication Code over the session 337 parameter and returns it to the peer (within GPSK-3). Within GPSK-2 338 and GPSK-3, peer and EAP server have the possibility to exchange 339 encrypted protected data parameters. 341 The peer verifies the received Message Authentication Code, and 342 consistency of the identities, nonces, and ciphersuite parameters 343 transmitted in GPSK-2. If the verification is successful, GPSK-4 is 344 prepared. This message can optionally contain the peer's protected 345 data parameters. 347 Upon receipt of GPSK-4, the server processes any included 348 PD_Payload_Block. Then, the EAP server sends an EAP Success message 349 to indicate the successful outcome of the authentication. 351 4. Key Derivation 353 EAP-GPSK provides key derivation in compliance to the requirements of 354 [RFC3748] and [RFC5247]. Note that this section provides an abstract 355 description for the key derivation procedure that needs to be 356 instantiated with a specific ciphersuite. 358 The long-term credential shared between EAP peer and EAP server 359 SHOULD be a strong pre-shared key PSK of at least 16 octets, though 360 its length and entropy is variable. While it is possible to use a 361 password or passphrase, doing so is NOT RECOMMENDED as EAP-GPSK is 362 vulnerable to dictionary attacks. 364 During an EAP-GPSK authentication, a Master Key MK, a Session Key SK 365 and a Protected Data Encryption Key PK (if using an encrypting 366 ciphersuite) are derived using the ciphersuite-specified KDF and data 367 exchanged during the execution of the protocol, namely 'RAND_Peer || 368 ID_Peer || RAND_Server || ID_Server' referred as inputString as its 369 short-hand form. 371 In case of successful completion, EAP-GPSK derives and exports an MSK 372 and EMSK both in length of 64 octets. 374 The following notation is used: KDF-X(Y, Z)[A..B], whereby 375 X is the length, in octets, of the desired output, 376 Y is a secret key, 377 Z is the inputString, 378 [A..B] extracts the string of octets starting with octet A finishing 379 with octet B from the output of the KDF function. 381 This keying material is derived using the ciphersuite-specified KDF 382 as follows: 384 o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server 385 o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || 386 inputString)[0..KS-1] 387 o MSK = KDF-{128+2*KS}(MK, inputString)[0..63] 388 o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127] 389 o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS] 390 o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using 391 an encrypting ciphersuite) 393 The value for PL (the length of the PSK in octets) is encoded as a 394 2-octet integer in network byte order. Recall that KS is the length 395 of the ciphersuite input key size in octets. 397 Additionally, the EAP keying framework [RFC5247] requires the 398 definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. These 399 values are defined as: 401 o Method-ID = KDF-16(PSK[0..KS-1], "Method ID" || EAP_Method_Type || 402 CSuite_Sel || inputString)[0..15] 403 o Session-ID = EAP_Method_Type || Method_ID 404 o Peer-ID = ID_Peer 405 o Server-ID = ID_Server 407 EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code 408 value. 410 Figure 2 depicts the key derivation procedure of EAP-GPSK. 412 +-------------+ +-------------------------------+ 413 | PL-octet | | RAND_Peer || ID_Peer || | 414 | PSK | | RAND_Server || ID_Server | 415 +-------------+ +-------------------------------+ 416 | | | 417 | +------------+ | | 418 | | CSuite_Sel | | | 419 | +------------+ | | 420 | | | | 421 v v v | 422 +--------------------------------------------+ | 423 | KDF | | 424 +--------------------------------------------+ | 425 | | 426 v | 427 +-------------+ | 428 | KS-octet | | 429 | MK | | 430 +-------------+ | 431 | | 432 v v 433 +---------------------------------------------------+ 434 | KDF | 435 +---------------------------------------------------+ 436 | | | | 437 v v v v 438 +---------+ +---------+ +----------+ +----------+ 439 | 64-octet| | 64-octet| | KS-octet | | KS-octet | 440 | MSK | | EMSK | | SK | | PK | 441 +---------+ +---------+ +----------+ +----------+ 443 Figure 2: EAP-GPSK Key Derivation 445 5. Key Management 447 In order to be interoperable, PSKs must be entered in the same way on 448 both the peer and server. The management interface for entering PSKs 449 MUST support entering PSKs up to 64 octets in length as ASCII strings 450 and in hexadecimal encoding. 452 Additionally, the ID_Peer and ID_Server MUST be provisioned with the 453 PSK. Validation of these values is by an octet-wise comparison. The 454 management interface SHOULD support entering non-ASCII octets for the 455 ID_Peer and ID_Server up to 254 octets in length. For more 456 information the reader is advised to read Section 2.4 of RFC 4282 457 [RFC4282]. 459 6. Ciphersuites 461 The design of EAP-GPSK allows cryptographic algorithms and key sizes, 462 called ciphersuites, to be negotiated during the protocol run. The 463 ability to specify block-based and hash-based ciphersuites is 464 offered. Extensibility is provided with the introduction of new 465 ciphersuites; this document specifies an initial set. The CSuite/ 466 Specifier column in Figure 3 uniquely identifies a ciphersuite. 468 For a vendor-specific ciphersuite the first four octets are the 469 vendor-specific enterprise number contains the IANA assigned "SMI 470 Network Management Private Enterprise Codes" value (see [ENTNUM]), 471 encoded in network byte order. The last two octets are vendor 472 assigned for the specific ciphersuite. A vendor code of 0x00000000 473 indicates ciphersuites standardized by IETF in an IANA-maintained 474 registry. 476 The following ciphersuites are specified in this document (recall 477 that KS is the length of the ciphersuite input key length in octets, 478 and ML is the length of the MAC output in octets): 480 +-----------+----+-------------+----+--------------+----------------+ 481 | CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation | 482 | Specifier | | | | KDF MAC | Function | 483 +-----------+----+-------------+----+--------------+----------------+ 484 | 0x0001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF | 485 +-----------+----+-------------+----+--------------+----------------+ 486 | 0x0002 | 32 | NULL | 32 | HMAC-SHA256 | GKDF | 487 +-----------+----+-------------+----+--------------+----------------+ 489 Figure 3: Ciphersuites 491 Ciphersuite 1, which is based on AES as a cryptographic primitive, 492 MUST be implemented. This document specifies also a second 493 ciphersuite, which MAY be implemented. Both ciphersuites defined in 494 this document make use of the GKDF, as defined in Section 7. The 495 following aspects need to be considered to ensure that the PSK that 496 is used as input to the GKDF is sufficiently long (in case it is 497 longer it needs to be truncated): 499 1. The PSK used with ciphersuite 1 MUST be 128 bits in length or 500 longer. 501 2. The PSK used with ciphersuite 2 MUST be 256 bits in length or 502 longer. 503 3. It is RECOMMENDED that 256 bit keys be provisioned in all cases 504 to provide enough entropy for all current and many possible 505 future ciphersuites. 507 Ciphersuites defined in the future that make use of the GKDF need to 508 specify a minimum PSK size (as it is done with the ciphersuites 509 listed in this document). 511 7. Generalized Key Derivation Function (GKDF) 513 Each ciphersuite needs to specify a key derivation function. The 514 ciphersuites defined in this document make use of the Generalized Key 515 Derivation Function (GKDF) that utilizes the MAC function defined in 516 the ciphersuite. Future ciphersuites can use any other formally 517 specified KDF that takes as arguments a key and a seed value, and 518 produces at least 128+2*KS octets of output. 520 GKDF has the following structure: 522 GKDF-X(Y, Z) 524 X length, in octets, of the desired output 525 Y secret key 526 Z inputString 528 GKDF-X (Y, Z) 529 { 530 n = ceiling integer of ( X / ML ); 531 /* determine number of output blocks */ 533 result = ""; 535 for i = 1 to n { 536 result = result || MAC_Y (i || Z); 537 } 539 return truncate(result, X) 540 } 542 Note that the variable 'i' in M_i is represented as a 2-octet value 543 in network byte order. 545 8. Ciphersuites Processing Rules 547 8.1. Ciphersuite #1 548 8.1.1. Encryption 550 With this ciphersuite all cryptography is built around a single 551 cryptographic primitive, AES-128 ([AES]). Within the protected data 552 frames, AES-128 is used in Cipher Block Chaining (CBC) mode of 553 operation (see [CBC]). This EAP method uses encryption in a single 554 payload, in the protected data payload (see Section 9.4). 556 In a nutshell, the CBC mode proceeds as follows. The IV is XORed 557 with the first plaintext block before it is encrypted. Then for 558 successive blocks, the previous ciphertext block is XORed with the 559 current plaintext, before it is encrypted. 561 8.1.2. Integrity 563 Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is 564 recommended by NIST. Among its advantages, CMAC is capable to work 565 with messages of arbitrary length. A detailed description of CMAC 566 can be found in [CMAC]. 568 The following instantiation is used: AES-CMAC-128(SK, Input) denotes 569 the MAC of Input under the key SK where Input refers to the following 570 content: 572 o Parameter within SEC_SK(Parameter) in message GPSK-2 573 o Parameter within SEC_SK(Parameter) in message GPSK-3 574 o Parameter within SEC_SK(Parameter) in message GPSK-4 576 8.2. Ciphersuite #2 578 8.2.1. Encryption 580 Ciphersuite 2 does not include an algorithm for encryption. With a 581 NULL encryption algorithm, encryption is defined as: 583 E_X(Y) = Y 585 When using this ciphersuite, the data exchanged inside the protected 586 data block is not encrypted. Therefore this mode MUST NOT be used if 587 confidential information appears inside the protected data block. 589 8.2.2. Integrity 591 Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash 592 algorithm (see [RFC4634]). 594 For integrity protection the following instantiation is used: 596 HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK 597 where Input refers to the following content: 599 o Parameter within SEC_SK(Parameter) in message GPSK-2 600 o Parameter within SEC_SK(Parameter) in message GPSK-3 601 o Parameter within SEC_SK(Parameter) in message GPSK-4 603 9. Packet Formats 605 This section defines the packet format of the EAP-GPSK messages. 607 9.1. Header Format 609 The EAP-GPSK header has the following structure: 611 --- bit offset ---> 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Code | Identifier | Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Type | OP-Code | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 619 | | 620 ... Payload ... 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Figure 4 626 The Code, Identifier, Length, and Type fields are all part of the EAP 627 header, and defined in [RFC3748]. The Type field in the EAP header 628 MUST be the value allocated by IANA for EAP-GPSK. 630 The OP-Code field is one of four values: 632 o 0x00 : Reserved 633 o 0x01 : GPSK-1 634 o 0x02 : GPSK-2 635 o 0x03 : GPSK-3 636 o 0x04 : GPSK-4 637 o 0x05 : GPSK-Fail 638 o 0x06 : GPSK-Protected-Fail 640 All other values of this OP-Code field are available via IANA 641 registration. 643 9.2. Ciphersuite Formatting 645 Ciphersuites are encoded as 6-octet arrays. The first four octets 646 indicate the CSuite/Vendor field. For vendor-specific ciphersuites, 647 this represents the vendor enterprise number and contains the IANA 648 assigned "SMI Network Management Private Enterprise Codes" value (see 649 [ENTNUM]), encoded in network byte order. The last two octets 650 indicate the CSuite/Specifier field, which identifies the particular 651 ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates 652 ciphersuites allocated by the IETF. 654 Graphically, they are represented as 656 --- bit offset ---> 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | CSuite/Vendor = 0x00000000 or enterprise number | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | CSuite/Specifier | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 Figure 5 667 CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and 668 CSuite/Specifier pair. 670 CSuite_List is a variable-length octet array of ciphersuites. It is 671 encoded by concatenating encoded ciphersuite values. Its length in 672 octets MUST be a multiple of 6. 674 9.3. Payload Formatting 676 Payload formatting is based on the protocol exchange description in 677 Section 3. 679 The GPSK-1 payload format is defined as follows: 681 --- bit offset ---> 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | length(ID_Server) | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 687 | | 688 ... ID_Server ... 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | | 692 ... 32-octet RAND_Server ... 693 | | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | length(CSuite_List) | | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 697 | | 698 ... CSuite_List ... 699 | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Figure 6: GPSK-1 Payload 704 The GPSK-2 payload format is defined as follows: 706 --- bit offset ---> 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | length(ID_Peer) | | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 712 | | 713 ... ID_Peer ... 714 | | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | length(ID_Server) | | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 718 | | 719 ... ID_Server ... 720 | | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | | 723 ... 32-octet RAND_Peer ... 724 | | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | | 727 ... 32-octet RAND_Server ... 728 | | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | length(CSuite_List) | | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 732 | | 733 ... CSuite_List ... 734 | | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | CSuite_Sel | 737 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | | length(PD_Payload_Block) | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | | 741 ... optional PD_Payload_Block ... 742 | | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | 745 ... ML-octet payload MAC ... 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Figure 7: GPSK-2 Payload 751 If the optional protected data payload is not included, then 752 length(PD_Payload_Block)=0 and the PD payload is excluded. The 753 payload MAC covers the entire packet, from the ID_Peer length, up 754 through the optional PD_Payload_Block. 756 The GPSK-3 payload is defined as follows: 758 --- bit offset ---> 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 ... 32-octet RAND_Peer ... 764 | | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | | 767 ... 32-octet RAND_Server ... 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | length(ID_Server) | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 772 | | 773 ... ID_Server ... 774 | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | CSuite_Sel | 777 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | | length(PD_Payload_Block) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | | 781 ... optional PD_Payload_Block ... 782 | | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 ... ML-octet payload MAC ... 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Figure 8: GPSK-3 Payload 791 If the optional protected data payload is not included, then 792 length(PD_Payload_Block)=0 and the PD payload is excluded. The 793 payload MAC covers the entire packet, from the RAND_Peer, up through 794 the optional PD_Payload_Block. 796 The GPSK-4 payload format is defined as follows: 798 --- bit offset ---> 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | length(PD_Payload_Block) | | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 804 | | 805 ... optional PD_Payload_Block ... 806 | | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 ... ML-octet payload MAC ... 810 | | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 9: GPSK-4 Payload 815 If the optional protected data payload is not included, then 816 length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC 817 MUST always be included, regardless of the presence of 818 PD_Payload_Block. The payload MAC covers the entire packet, from the 819 PD_Payload_Block length up through the optional PD_Payload_Block. 821 The GPSK-Fail payload format is defined as follows: 823 --- bit offset ---> 824 0 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Failure-Code | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Figure 10: GPSK-Fail Payload 832 The GPSK-Protected-Fail payload format is defined as follows: 834 --- bit offset ---> 835 0 1 2 3 836 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 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Failure-Code | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | | 841 ... ML-octet payload MAC ... 842 | | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 Figure 11: GPSK-Protected-Fail Payload 847 The Failure-Code field is one of three values, but can be extended: 849 o 0x00000000 : Reserved 850 o 0x00000001 : PSK Not Found 851 o 0x00000002 : Authentication Failure 852 o 0x00000003 : Authorization Failure 854 All other values of this field are available via IANA registration. 856 "PSK Not Found" indicates a key for a particular user could not be 857 located, making authentication impossible. "Authentication Failure" 858 indicates a MAC failure due to a PSK mismatch. "Authorization 859 Failure" indicates that while the PSK being used is correct, the user 860 is not authorized to connect. 862 9.4. Protected Data 864 The protected data blocks are a generic mechanism for the peer and 865 server to securely exchange data. If the specified ciphersuite has a 866 NULL encryption primitive, then this channel only offers 867 authenticity, and not confidentiality. 869 These payloads are encoded as the concatenation of type-length-value 870 (TLV) triples called PD_Payloads. 872 Type values are encoded as a 6-octet string and represented by a 873 4-octet vendor and 2-octet specifier field. The vendor field 874 indicates the type as either standards-specified or vendor-specific. 875 If these four octets are 0x00000000, then the value is standards- 876 specified, and any other value represents a vendor-specific 877 enterprise number. 879 The specifier field indicates the actual type. For vendor field 880 0x00000000, the specifier field is maintained by IANA. For any other 881 vendor field, the specifier field is maintained by the vendor. 883 Length fields are specified as 2-octet integers in network byte 884 order, and reflect only the length of the value, and do not include 885 the length of the type and length fields. 887 Graphically, this can be 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 | PData/Vendor | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 PData/Specifier | PData/Length | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | | 898 ... PData/Value ... 899 | | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 Protected Data Payload (PD_Payload) Formatting 904 These PD_Payloads are concatenated together to form a 905 PD_Payload_Block. The If the CSuite_Sel includes support for 906 encryption, then the PD_Payload_Block includes fields specifying an 907 initialization vector (IV), and the necessary padding. This can be 908 depicted as follows: 910 --- bit offset ---> 911 0 1 2 3 912 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 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | IV Length | | 915 +-+-+-+-+-+-+-+-+ Initialization Vector + 916 | | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | | 919 ... PD_Payload ... 920 | | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | | 923 ... optional PD_Payload, etc ... 924 | | 925 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | | Padding (0-255 octets) | 927 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 928 | | Pad Length | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Protected Data Block (PD_Payload_Block) Formatting if Encryption 932 Supported 934 The Initialization Vector is a randomly chosen value whose length is 935 equal to the specified IV Length. The required length is defined by 936 the ciphersuite. Recipients MUST accept any value. Senders SHOULD 937 either pick this value pseudo-randomly and independently for each 938 message or use the final ciphertext block of the previous message 939 sent. Senders MUST NOT use the same value for each message, use a 940 sequence of values with low hamming distance (e.g., a sequence 941 number), or use ciphertext from a received message. IVs should be 942 selected per the security requirements of the underlying cipher. If 943 the data is not being encrypted, then the IV Length MUST be 0. If 944 the ciphersuite does not require an IV, or has a self-contained way 945 of communicating the IV, then the IV Length field MUST be 0. In 946 these cases the ciphersuite definition defines how the IV is 947 encapsulated in the PD_Payload. 949 The concatenation of PD_Payloads along with the padding and padding 950 length are all encrypted using the negotiated block cipher. If no 951 block cipher is specified, then these fields are not encrypted. 953 The Padding field MAY contain any value chosen by the sender. For 954 block-based cipher modes, the padding MUST have a length that makes 955 the combination of the concatenation of PD_Payloads, the Padding, and 956 the Pad Length to be a multiple of the encryption block size. If the 957 underlying ciphersuite does not require padding (e.g. a stream-based 958 cipher mode) or no encryption is being used, then the padding length 959 MUST still be present and be zero. 961 The Pad Length field is the length of the Padding field. The sender 962 SHOULD set the Pad Length to the minimum value that makes the 963 combination of the PD_Payloads, the Padding, and the Pad Length a 964 multiple of the block size (in the case of block-based cipher modes), 965 but the recipient MUST accept any length that results in proper 966 alignment. This field is encrypted with the negotiated cipher. 968 If the negotiated ciphersuite does not support encryption, then the 969 IV field MUST be of length zero and padding field MUST be of length 970 zero. The IV length and padding length fields MUST still be present, 971 and contain the value zero. The rationale for still requiring the 972 length fields is to allow for modular implementations where the 973 crypto processing is independent of the payload processing. This is 974 depicted in the following figure. 976 --- bit offset ---> 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | 0x00 | | 981 +-+-+-+-+-+-+-+-+ PD_Payload ... 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 ... optional PD_Payload, etc +-+-+-+-+-+-+-+-+ 986 | | 0x00 | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Protected Data Block (PD_Payload_Block) Formatting Without Encryption 991 For PData/Vendor field 0x00000000, the following PData/Specifier 992 fields are defined: 993 o 0x0000 : Reserved 994 All other values of this field are available via IANA registration. 996 10. Packet Processing Rules 998 This section defines how the EAP peer and EAP server MUST behave when 999 received packet is deemed invalid. 1001 Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP 1002 server MUST be silently discarded. An EAP peer or EAP server 1003 receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 1004 before receiving GPSK-1 or before transmitting GPSK-2) MUST silently 1005 discard the packet. 1007 GPSK-1 contains no MAC protection, so provided it properly parses, it 1008 MUST be accepted by the peer. If the EAP peer has no ciphersuites in 1009 common with the server or decides the ID_Server is that of a AAA 1010 server to which it does not wish to authenticate, the EAP peer MUST 1011 respond with an EAP-NAK. 1013 For GPSK-2, if ID_Peer is for an unknown user, the EAP server MUST 1014 send either a "PSK Not Found" GPSK-Fail message, or an 1015 "Authentication Failure" GPSK-Fail, depending on its policy. If the 1016 MAC validation fails, the server MUST transmit a GPSK-Fail message 1017 specifying "Authentication Failure". If the RAND_Server or 1018 CSuite_List field in GPSK-2 does not match the values in GPSK-1, the 1019 server MUST silently discard the packet. If server policy determines 1020 the peer is not authorized and the MAC is correct, the server MUST 1021 transmit a GPSK-Protected-Fail message indicating "Authorization 1022 Failure" and discard the received packet. 1024 A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in 1025 response to a GPSK-2 message MUST replay the received GPSK-Fail / 1026 GPSK-Protected-Fail message. Then, the EAP server returns an EAP- 1027 Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message 1028 to correctly finish the EAP conversation. If MAC validation on a 1029 GPSK-Protected-Fail packet fails, then the received packet MUST be 1030 silently discarded. 1032 For GPSK-3, a peer MUST silently discard messages where the 1033 RAND_Peer, ID_Server, or the CSuite_Sel fields do not match those 1034 transmitted in GPSK-2. An EAP peer MUST silently discard any packet 1035 whose MAC fails. 1037 For GPSK-4, a server MUST silently discard any packet whose MAC fails 1038 validation. 1040 If a decryption failure of a protected payload is detected, the 1041 recipient MUST silently discard the GPSK packet. 1043 11. Example Message Exchanges 1045 This section shows a couple of example message flows. 1047 A successful EAP-GPSK message exchange is shown in Figure 1. 1049 +--------+ +--------+ 1050 | | EAP-Request/Identity | | 1051 | EAP |<------------------------------------| EAP | 1052 | peer | | server | 1053 | | EAP-Response/Identity | | 1054 | |------------------------------------>| | 1055 | | | | 1056 | | EAP-Request/GPSK-1 | | 1057 | |<------------------------------------| | 1058 | | | | 1059 | | EAP-Response/EAP-NAK | | 1060 | |------------------------------------>| | 1061 | | | | 1062 | | EAP-Failure | | 1063 | |<------------------------------------| | 1064 +--------+ +--------+ 1066 EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity; 1067 ID_Server) 1069 +--------+ +--------+ 1070 | | EAP-Request/Identity | | 1071 | EAP |<------------------------------------| EAP | 1072 | peer | | server | 1073 | | EAP-Response/Identity | | 1074 | |------------------------------------>| | 1075 | | | | 1076 | | EAP-Request/GPSK-1 | | 1077 | |<------------------------------------| | 1078 | | | | 1079 | | EAP-Response/GPSK-2 | | 1080 | |------------------------------------>| | 1081 | | | | 1082 | | EAP-Request/GPSK-Fail | | 1083 | | (PSK Not Found or Authentication | | 1084 | | Failure) | | 1085 | |<------------------------------------| | 1086 | | | | 1087 | | EAP-Response/GPSK-Fail | | 1088 | | (PSK Not Found or Authentication | | 1089 | | Failure) | | 1090 | |------------------------------------>| | 1091 | | | | 1092 | | EAP-Failure | | 1093 | |<------------------------------------| | 1094 +--------+ +--------+ 1096 EAP-GPSK: Unsuccessful Exchange (Unknown user) 1098 +--------+ +--------+ 1099 | | EAP-Request/Identity | | 1100 | EAP |<------------------------------------| EAP | 1101 | peer | | server | 1102 | | EAP-Response/Identity | | 1103 | |------------------------------------>| | 1104 | | | | 1105 | | EAP-Request/GPSK-1 | | 1106 | |<------------------------------------| | 1107 | | | | 1108 | | EAP-Response/GPSK-2 | | 1109 | |------------------------------------>| | 1110 | | | | 1111 | | EAP-Request/GPSK-Fail | | 1112 | | (Authentication Failure) | | 1113 | |<------------------------------------| | 1114 | | | | 1115 | | EAP-Response/GPSK-Fail | | 1116 | | (Authentication Failure) | | 1117 | |------------------------------------>| | 1118 | | | | 1119 | | EAP-Failure | | 1120 | |<------------------------------------| | 1121 +--------+ +--------+ 1123 EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2) 1125 +--------+ +--------+ 1126 | | EAP-Request/Identity | | 1127 | EAP |<------------------------------------| EAP | 1128 | peer | | server | 1129 | | EAP-Response/Identity | | 1130 | |------------------------------------>| | 1131 | | | | 1132 | | EAP-Request/GPSK-1 | | 1133 | |<------------------------------------| | 1134 | | | | 1135 | | EAP-Response/GPSK-2 | | 1136 | |------------------------------------>| | 1137 | | | | 1138 | | EAP-Request/ | | 1139 | | GPSK-Protected-Fail | | 1140 | | (Authorization Failure) | | 1141 | |<------------------------------------| | 1142 | | | | 1143 | | EAP-Request/ | | 1144 | | GPSK-Protected-Fail | | 1145 | | (Authorization Failure) | | 1146 | |------------------------------------>| | 1147 | | | | 1148 | | EAP-Failure | | 1149 | |<------------------------------------| | 1150 +--------+ +--------+ 1152 EAP-GPSK: Unsuccessful Exchange (Authorization failure) 1154 12. Security Considerations 1156 [RFC3748] highlights several attacks that are possible against EAP 1157 since EAP itself does not provide any security. 1159 This section discusses the claimed security properties of EAP-GPSK as 1160 well as vulnerabilities and security recommendations in the threat 1161 model of [RFC3748]. 1163 12.1. Security Claims 1165 Auth. mechanism: Shared Keys 1166 Ciphersuite negotiation: Yes (Section 12.16) 1167 Mutual authentication: Yes (Section 12.2) 1168 Integrity protection: Yes (Section 12.4) 1169 Replay protection: Yes (Section 12.5) 1170 Confidentiality: No (Section 12.17, Section 12.15) 1171 Key derivation: Yes (Section 12.8) 1172 Key strength: Varies (Section 12.8) 1173 Dictionary attack prot.: No (Section 12.7) 1174 Fast reconnect: No (Section 12.14) 1175 Crypt. binding: N/A (Section 12.18) 1176 Session independence: Yes (Section 12.10) 1177 Fragmentation: No (Section 12.12) 1178 Channel binding: Extensible (Section 12.13) 1180 12.2. Mutual Authentication 1182 EAP-GPSK provides mutual authentication. 1184 The server believes that the peer is authentic when it successfully 1185 verifies the MAC in the GPSK-2 message and the peer believes that the 1186 server is authentic when it successfully verifies the MAC it receives 1187 with the GPSK-3 message. 1189 The key used for mutual authentication is derived based on the long- 1190 term secret PSK, nonces contributed by both parties and other 1191 parameters. The long-term secret PSK has to provide sufficient 1192 entropy and therefore sufficient strength. The nonces (RAND_Peer and 1193 RAND_Server) need to be fresh and unique for every session. In this 1194 way EAP-GPSK is not different than other authentication protocols 1195 based on pre-shared keys. 1197 12.3. Protected Result Indications 1199 EAP-GPSK supports protected results indication via the GPSK- 1200 Protected-Fail message. This allows a server to provide additional 1201 information to the peer as to why the session failed, and do so in an 1202 authenticated way (if possible). In particular, the server can 1203 indicate the lack of PSK (account not present), failed authentication 1204 (PSK incorrect), or authorization failure (account disabled or 1205 unauthorized). Only the third message could be integrity protected. 1207 It should be noted that these options make debugging network and 1208 account errors easier, but also leak information about accounts to 1209 attackers. An attacker can determine if a particular ID_Peer is a 1210 valid user on the network, or not. Thus implementers should use care 1211 in enabling this particular option on their servers. If they are in 1212 an environment where such attacks are of concern, then protected 1213 result indication capabilities should be disabled. 1215 12.4. Integrity Protection 1217 EAP-GPSK provides integrity protection based on the ciphersuites 1218 suggested in this document. Integrity protection is a minimum 1219 feature every ciphersuite must provide. 1221 12.5. Replay Protection 1223 EAP-GPSK provides replay protection of its mutual authentication part 1224 thanks to the use of random numbers RAND_Server and RAND_Peer. Since 1225 RAND_Server is 32 octets long, one expects to have to record 2**64 1226 (i.e., approximately 1.84*10**19) EAP-GPSK successful authentication 1227 before an protocol run can be replayed. Hence, EAP-GPSK provides 1228 replay protection of its mutual authentication part as long as 1229 RAND_Server and RAND_Peer are chosen at random, randomness is 1230 critical for replay protection. RFC 4086 [RFC4086] describes 1231 techniques for producing random quantities. 1233 12.6. Reflection attacks 1235 Reflection attacks occur in bi-directional, challenge-response, 1236 mutual authentication protocols where an attacker, upon being issued 1237 a challenge by an authenticator responds by issuing the same 1238 challenge back to the authenticator, obtaining the response, and then 1239 "reflecting" that same response to the original challenge. 1241 EAP-GPSK provides protection against reflection attacks because the 1242 message formats for the challenges differ. The protocol does not 1243 consist of two independent authentications, but rather the 1244 authentications are tightly coupled. 1246 Also note that EAP-GPSK does not provide MAC protection of the OP- 1247 Code field, but again since each message is constructed differently, 1248 it would not be possible to change the OP-Code of a valid message and 1249 still have it be parseable and accepted by the recipient. 1251 12.7. Dictionary Attacks 1253 EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be 1254 based on at least 16 octets of entropy to be fully secure. The EAP- 1255 GPSK protocol makes no special provisions to ensure keys based on 1256 passwords are used securely. Users who use passwords as the basis of 1257 their PSK are not protected against dictionary attacks. Derivation 1258 of the long-term shared secret from a password is strongly 1259 discouraged. 1261 The success of a dictionary attack against EAP-GPSK depends on the 1262 strength of the long-term shared secret (PSK) it uses. The PSK used 1263 by EAP-GPSK SHOULD be drawn from a pool of secrets that is at least 1264 2^128 bits large and whose distribution is uniformly random. Note 1265 that this does not imply resistance to dictionary attack, only that 1266 the probability of success in such an attack is acceptably remote. 1268 12.8. Key Derivation and Key Strength 1270 EAP-GPSK supports key derivation as shown in Section 4. 1272 Keys used within EAP-GPSK are all based on the security of the 1273 originating PSK. PSKs SHOULD have at least 16 octets of entropy. 1274 Independent of the protocol exchange (i.e. without knowing RAND_Peer 1275 and RAND_Server), the keys have been derived with sufficient input 1276 entropy to make them as secure as the underlying KDF output key 1277 length. 1279 12.9. Denial of Service Resistance 1281 There are three forms of denial of service attacks relevant for this 1282 document, namely (1) attacks that lead to vast amount of state being 1283 allocated, (2) attacks that attempt to prevent communication between 1284 the peer and server, and (3) attacks against computational resources. 1286 In an EAP-GPSK conversation the server has to maintain state, namely 1287 the 32-octet RAND_Server, when transmitting the GPSK-1 message to the 1288 peer. An adversary could therefore flood a server with a large 1289 number of EAP-GPSK communication attempts. An EAP server may 1290 therefore ensure that established state times out after a relatively 1291 short period of time when no further messages are received. This 1292 enables a sort of garbage collection. 1294 The client has to keep state information after receiving the GPSK-1 1295 message. To prevent a replay attack, all the client needs to do is 1296 to ensure that the value of RAND_Peer is consistent between GPSK-2 1297 and GPSK-3. Message GPSK-3 contains all the material required to re- 1298 compute the keying material. Thus, if a client chooses to implement 1299 this client-side DoS protection mechanism it may manage RAND_Peer and 1300 CSuite_Sel on a per-server basis for servers it knows instead of on a 1301 per-message basis. 1303 Attacks that disrupt communication between the peer and server are 1304 mitigated by silently discarding messages with invalid MACs. Attacks 1305 against computational resources are mitigated by having very light- 1306 weight cryptographic operations required during each protocol round. 1308 The security considerations of EAP itself, see Section 5.2 and 1309 Section 7 of RFC 3748 [RFC3748], are also applicable to this 1310 specification (e.g., for example concerning EAP-based notifications). 1312 12.10. Session Independence 1314 Thanks to its key derivation mechanisms, EAP-GPSK provides session 1315 independence: passive attacks (such as capture of the EAP 1316 conversation) or active attacks (including compromise of the MSK or 1317 EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. 1318 The assumption that RAND_Peer and RAND_Server are random is central 1319 for the security of EAP-GPSK in general and session independence in 1320 particular. 1322 12.11. Compromise of the PSK 1324 EAP-GPSK does not provide perfect forward secrecy. Compromise of the 1325 PSK leads to compromise of recorded past sessions. 1327 Compromise of the PSK enables the attacker to impersonate the peer 1328 and the server and it allows the adversary to compromise future 1329 sessions. 1331 EAP-GPSK provides no protection against a legitimate peer sharing its 1332 PSK with a third party. Such protection may be provided by 1333 appropriate repositories for the PSK, which choice is outside the 1334 scope of this document. The PSK used by EAP-GPSK must only be shared 1335 between two parties: the peer and the server. In particular, this 1336 PSK must not be shared by a group of peers (e.g. those with different 1337 ID_Peer values) communicating with the same server. 1339 The PSK used by EAP-GPSK must be cryptographically separated from 1340 keys used by other protocols, otherwise the security of EAP-GPSK may 1341 be compromised. 1343 12.12. Fragmentation 1345 EAP-GPSK does not support fragmentation and reassembly since the 1346 message size is relatively small. However it should be noted that 1347 this impacts the length of protected data payloads that can be 1348 attached to messages. Also if the EAP frame is larger than the MTU 1349 of the underlying transport, and that transport does not support 1350 fragmentation, the frame will most likely not be transported. 1351 Consequently implementors and deployers should take care to ensure 1352 EAP-GPSK frames are short enough to work properly on the target 1353 underlying transport mechanism. 1355 12.13. Channel Binding 1357 This document enables the ability to exchange channel binding 1358 information. It does not, however, define the encoding of channel 1359 binding information in the document. 1361 12.14. Fast Reconnect 1363 EAP-GPSK does not provide the fast reconnect capability since this 1364 method is already at (or close to) the lower limit of the number of 1365 roundtrips and the cryptographic operations. 1367 12.15. Identity Protection 1369 Identity protection is not specified in this document. Extensions 1370 can be defined that enhance this protocol to provide this feature. 1372 12.16. Protected Ciphersuite Negotiation 1374 EAP-GPSK provides protected ciphersuite negotiation via the 1375 indication of available ciphersuites by the server in the first 1376 message and a confirmation by the peer in the subsequent message. 1378 Note, however, that the GPSK-2 message may optionally contain a 1379 payload, ENC_PK(PD_Payload_Block), protected with an algorithm based 1380 on a selected ciphersuite before the ciphersuite list has actually 1381 been authenticated. In the classical downgrading attack an adversary 1382 would chose a ciphersuite that it weak enough to that it could break 1383 it in real-time or to turn security off. The latter is not possible 1384 since any ciphersuite defined for EAP-GPSK must at least provide 1385 authentication and integrity protection. Confidentiality protection 1386 is optional. When, some time in the future, a ciphersuite contains 1387 algorithms that can be broken in real-time then a policy on peers and 1388 the server needs to indicate that such a ciphersuite must not be 1389 selected by any of parties. 1391 Furthermore, an adversary may modify the selection of the ciphersuite 1392 to for the client to select a ciphersuite that does not provide 1393 confidentiality protection. As a result this would cause the content 1394 of PD_Payload_Block to be transmitted in cleartext. When protocol 1395 designers extend EAP-GPSK to carry information in the 1396 PD_Payload_Block of the GPSK-2 message then it must be indicated 1397 whether confidentiality protection is mandatory. In case such an 1398 extension requires a ciphersuite with confidentiality protection then 1399 the policy at the peer must not transmit information of that 1400 extension in the PD_Payload_Block of the GPSK-2 message. The peer 1401 may, if possible, delay the transmission of this information element 1402 to the GPSK-4 message where the ciphersuite negotiation has been 1403 confirmed already. In general, when a ciphersuite is selected that 1404 does not provide confidentiality protection then information that 1405 demands confidentiality protection must not be included in any of the 1406 PD_Payload_Block objects. 1408 12.17. Confidentiality 1410 Although EAP-GPSK provides confidentiality in its protected data 1411 payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748] 1412 since it does not support identity protection. 1414 12.18. Cryptographic Binding 1416 Since EAP-GPSK does not tunnel another EAP method, it does not 1417 implement cryptographic binding. 1419 13. IANA Considerations 1421 This document requires IANA to allocate a new EAP Type for EAP-GPSK. 1423 This document requires IANA to create a new registry for 1424 ciphersuites, protected data types, failure codes and op-codes. IANA 1425 is furthermore instructed to add the specified ciphersuites, 1426 protected data types, failure codes and op-codes to these registries 1427 as defined below. Values can be added or modified per IETF REVIEW 1428 [RFC5226] defining either block-based or hash-based ciphersuites, 1429 protected data payloads, failure codes and op-codes. Each 1430 ciphersuite needs to provide processing rules and needs to specify 1431 how the following algorithms are instantiated: encryption, integrity, 1432 key derivation and key length. 1434 Figure 3 represents the initial ciphersuite CSuite/Specifier registry 1435 setup. The CSuite/Specifier field is 16 bits long. All other values 1436 are available via IANA registration. This registry should be named 1437 "EAP-GPSK Ciphersuites". 1439 The following is the initial protected data PData/Specifier registry 1440 setup, which should be named "EAP-GPSK Protected Data Payloads": 1442 o 0x0000 : Reserved 1444 The PData/Specifier field is 16 bits long and all other values are 1445 available via IANA registration. Each extension needs to indicate 1446 whether confidentiality protection for transmission between the EAP 1447 peer and the EAP server is mandatory. 1449 The following layout represents the initial Failure-Code registry 1450 setup, which should be named "EAP-GPSK Failure Codes": 1452 o 0x00000000 : Reserved 1453 o 0x00000001 : PSK Not Found 1454 o 0x00000002 : Authentication Failure 1455 o 0x00000003 : Authorization Failure 1457 The Failure-Code field is 32 bits long and all other values are 1458 available via IANA registration. 1460 The following layout represents the initial OP-Code registry setup, 1461 which should be named "EAP-GPSK OP Codes": 1463 o 0x00 : Reserved 1464 o 0x01 : GPSK-1 1465 o 0x02 : GPSK-2 1466 o 0x03 : GPSK-3 1467 o 0x04 : GPSK-4 1468 o 0x05 : GPSK-Fail 1469 o 0x06 : GPSK-Protected-Fail 1471 The OP-Code field is 8 bits long and all other values are available 1472 via IANA registration. 1474 14. Contributors 1476 This work is a joint effort of the EAP Method Update (EMU) design 1477 team of the EMU Working Group that was created to develop a mechanism 1478 based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 1479 4017 [RFC4017] requirements. The design team members (in 1480 alphabetical order) were: 1482 o Jari Arkko 1483 o Mohamad Badra 1484 o Uri Blumenthal 1485 o Charles Clancy 1486 o Lakshminath Dondeti 1487 o David McGrew 1488 o Joe Salowey 1489 o Sharma Suman 1490 o Hannes Tschofenig 1491 o Jesse Walker 1493 Finally, we would like to thank Thomas Otto for his draft reviews, 1494 feedback and text contributions. 1496 15. Acknowledgments 1498 We would like to thank 1499 o Jouni Malinen and Bernard Aboba for their early draft comments in 1500 June 2006. Jouni Malinen developed the first prototype 1501 implementation. It can be found at: 1502 http://hostap.epitest.fi/releases/snapshots/ 1503 o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela 1504 Vanderveen and Ray Bell for their input to the ciphersuite 1505 discussions between July and August 2006. 1506 o Lakshminath Dondeti for his detailed draft review (sent to the EMU 1507 ML on the 12th July 2006). 1508 o Based on a review requested from NIST Quynh Dang suggested changes 1509 to the GKDF function (December 2006). 1510 o Jouni Malinen and Victor Fajardo for their review in January 2007. 1511 o Jouni Malinen for his suggestions regarding the examples and the 1512 key derivation function in February 2007. 1513 o Bernard Aboba and Jouni Malinen for their review in February 2007. 1514 o Vidya Narayanan for her review in March 2007. 1515 o Pasi Eronen for his IESG review in March and July 2008. 1516 o Dan Harkins for his review in June 2008. 1517 o Joe Salowey, the EMU working group chair, provided a document 1518 review in April 2007. Jouni Malinen also reviewed the document 1519 during the same month. 1520 o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov 1521 and Prof. John C. Mitchell for their analysis of EAP-GPSK and for 1522 pointing us to a client-side DoS attack, a downgrading attack and 1523 their input to the key derivation function. Based on their input 1524 the key derivation function has been modified and the text in the 1525 security consideration section has been updated. 1526 o Finally, we would like to thank our working group chair, Joe 1527 Salowey, for his support and for the time he spend on discussing 1528 open issues with us. 1530 16. References 1532 16.1. Normative References 1534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1535 Requirement Levels", BCP 14, RFC 2119, March 1997. 1537 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1538 Levkowetz, "Extensible Authentication Protocol (EAP)", 1539 RFC 3748, June 2004. 1541 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1542 Network Access Identifier", RFC 4282, December 2005. 1544 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1545 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1547 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1548 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1549 May 2008. 1551 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1552 Authentication Protocol (EAP) Key Management Framework", 1553 RFC 5247, August 2008. 1555 [AES] National Institute of Standards and Technology, 1556 "Specification for the Advanced Encryption Standard 1557 (AES)", Federal Information Processing Standards 1558 (FIPS) 197, November 2001. 1560 [CMAC] National Institute of Standards and Technology, 1561 "Recommendation for Block Cipher Modes of Operation: The 1562 CMAC Mode for Authentication", Special Publication 1563 (SP) 800-38B, May 2005. 1565 [CBC] National Institute of Standards and Technology, 1566 "Recommendation for Block Cipher Modes of Encryption. 1567 Methods and Techniques.", Special Publication (SP) 800- 1568 38A, December 2001. 1570 16.2. Informative References 1572 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1573 Authentication Protocol (EAP) Method Requirements for 1574 Wireless LANs", RFC 4017, March 2005. 1576 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1577 Requirements for Security", BCP 106, RFC 4086, June 2005. 1579 [ENTNUM] IANA, "SMI Network Management Private Enterprise Codes", 1580 IANA Assignments enterprise-numbers. 1582 [80211] "Information technology - Telecommunications and 1583 Information Exchange Between Systems - Local and 1584 Metropolitan Area Networks - Specific Requirements - Part 1585 11: Wireless LAN Medium Access Control (MAC) and Physical 1586 Layer (PHY) Specifications", IEEE Standard 802.11-2007, 1587 March 2007. 1589 Authors' Addresses 1591 T. Charles Clancy 1592 DoD Laboratory for Telecommunications Sciences 1593 8080 Greenmead Drive 1594 College Park, MD 20740 1595 USA 1597 Email: clancy@ltsnet.net 1599 Hannes Tschofenig 1600 Nokia Siemens Networks 1601 Linnoitustie 6 1602 Espoo 02600 1603 Finland 1605 Email: Hannes.Tschofenig@gmx.net 1607 Full Copyright Statement 1609 Copyright (C) The IETF Trust (2008). 1611 This document is subject to the rights, licenses and restrictions 1612 contained in BCP 78, and except as set forth therein, the authors 1613 retain all their rights. 1615 This document and the information contained herein are provided on an 1616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1618 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1619 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1620 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1623 Intellectual Property 1625 The IETF takes no position regarding the validity or scope of any 1626 Intellectual Property Rights or other rights that might be claimed to 1627 pertain to the implementation or use of the technology described in 1628 this document or the extent to which any license under such rights 1629 might or might not be available; nor does it represent that it has 1630 made any independent effort to identify any such rights. Information 1631 on the procedures with respect to rights in RFC documents can be 1632 found in BCP 78 and BCP 79. 1634 Copies of IPR disclosures made to the IETF Secretariat and any 1635 assurances of licenses to be made available, or the result of an 1636 attempt made to obtain a general license or permission for the use of 1637 such proprietary rights by implementers or users of this 1638 specification can be obtained from the IETF on-line IPR repository at 1639 http://www.ietf.org/ipr. 1641 The IETF invites any interested party to bring to its attention any 1642 copyrights, patents or patent applications, or other proprietary 1643 rights that may cover technology that may be required to implement 1644 this standard. Please address the information to the IETF at 1645 ietf-ipr@ietf.org.