idnits 2.17.1 draft-ietf-emu-eap-gpsk-01.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 on line 1184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1202. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1208. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1129 has weird spacing: '...ication and K...' == 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 (October 31, 2006) is 6386 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) == Unused Reference: 'RFC3174' is defined on line 1103, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3174 == Outdated reference: A later version (-02) exists of draft-otto-emu-eap-tls-psk-01 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-15 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 4, 2007 Siemens 6 October 31, 2006 8 EAP Generalized Pre-Shared Key (EAP-GPSK) 9 draft-ietf-emu-eap-gpsk-01.txt 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 4, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 57 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13 60 6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . . 13 61 6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13 62 6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13 63 6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14 64 6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . . 14 65 6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14 66 6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 67 6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 15 69 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 70 7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 71 7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . . 16 72 7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . . 16 73 7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . . 20 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 76 8.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 21 77 8.2. Protected Result Indications . . . . . . . . . . . . . . . 22 78 8.3. Integrity Protection . . . . . . . . . . . . . . . . . . . 22 79 8.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 22 80 8.5. Reflection attacks . . . . . . . . . . . . . . . . . . . . 22 81 8.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 22 82 8.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 22 83 8.8. Denial of Service Resistance . . . . . . . . . . . . . . . 22 84 8.9. Session Independence . . . . . . . . . . . . . . . . . . . 23 85 8.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 23 86 8.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 24 87 8.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 24 88 8.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 24 89 8.14. Identity Protection . . . . . . . . . . . . . . . . . . . 24 90 8.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 24 91 8.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 24 92 8.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 24 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 11. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 25 99 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 103 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 106 Intellectual Property and Copyright Statements . . . . . . . . . . 29 108 1. Introduction 110 EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a 111 generalized pre-shared key authentication technique. Mutual 112 authentication is achieved through a nonce-based exchange that is 113 secured by a pre-shared key. 115 At present, several pre-shared key EAP methods are specified, most 116 notably 118 o EAP-PAX [I-D.clancy-eap-pax] 119 o EAP-PSK [I-D.bersani-eap-psk] 120 o EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and 121 o EAP-SAKE [I-D.vanderveen-eap-sake]. 123 Each proposal has its particular benefits but also its particular 124 deficiencies. EAP-GPSK is a new EAP method that tries to combine the 125 most valuable characteristics of each of these methods and therefore 126 attempts to address a broad range of usage scenarios. 128 The main design goals of EAP-GPSK are 130 Simplicity: 132 EAP-GPSK should be easy to implement and therefore quickly 133 available. 135 Wide applicability: 137 EAP-GPSK has been designed in a threat model where the attacker 138 has full control over the communication channel. This is the EAP 139 threat model that is presented in Section 7.1 of [RFC3748]. Thus, 140 it is particularly suited for wireless or battery powered devices. 142 Efficiency: 144 EAP-GPSK does not make use of public key cryptography and fully 145 relies of symmetric cryptography. The restriction on symmetric 146 cryptographic computations allows for low computational overhead. 147 Hence, EAP-GPSK is lightweight and well suited for any type of 148 device, especially those with little processing power and memory. 150 Flexibility: 152 EAP-GPSK offers cryptographic flexibility. At the beginning, the 153 EAP server selects a set of cryptographic algorithms and key 154 sizes, a so called ciphersuite. The current version of EAP-GPSK 155 comprises two ciphersuites, but additional ones can be easily 156 added. 158 Extensibility: 160 The design of EAP-GPSK allows to securely exchange information 161 between the EAP peer and the EAP server using protected data 162 fields. These fields might, for example, be used to exchange 163 channel binding information or to provide support for identity 164 confidentiality. 166 2. Terminology 168 In this document, several words are used to signify the requirements 169 of the specification. These words are often capitalized. The key 170 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 171 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 172 are to be interpreted as described in [RFC2119]. 174 This section describes the various variables and functions used in 175 the EAP-GPSK method. 177 Variables: 179 PD_Payload_X: 181 Data carried within the X-th protected data payload 182 CSuite_List: 184 An octet array listing available ciphersuites (variable length) 186 CSuite_Sel: 188 Ciphersuite selected by the client (1 octet or 7 octets) 190 ID_Client: 192 Client NAI [RFC2486bis] 194 ID_Server: 196 Server identity as an opaque blob. 198 KS: 200 Integer representing the key size in octets of the selected 201 ciphersuite CSuite_Sel 203 RAND_Client: 205 Random integer generated by the client (256 bits) 207 RAND_Server: 209 Random integer generated by the server (256 bits) 211 Operations: 213 A || B: 215 Concatenation of octet strings A and B 217 ENC_X(Y): 219 Encryption of message Y with a symmetric key X, using a defined 220 block cipher 222 KDF_X(Y): 224 Key Derivation Function that generates an arbitrary number of 225 octets of output using secret X and seed Y 227 length(X): 229 Function that returns the length of input X in octets, encoded as 230 a 16-bit integer in network byte order 232 MAC_X(Y): 234 Keyed message authentication code computed over Y with symmetric 235 key X 237 SEC_X(Y): 239 SEC is a function that provides integrity protection based on the 240 chosen ciphersuite. The function SEC uses the algorithm defined 241 by the selected ciphersuite and applies it to the message content 242 Y with key X. As an output the message returns Y concatenated with 243 MAC_X(Y). 245 X[A..B]: 247 Notation representing octets A through B of octet array X 249 The following abbreviations are used for the keying material: 251 PK: 253 Session key generated from the MK and used during protocol 254 exchange to encrypt protected data (size defined by ciphersuite) 256 SK: 258 Session key generated from the MK and used during protocol 259 exchange to prove knowledge of PSK (size defined by ciphersuite) 261 EMSK: 263 Extended Master Session Key is exported by the EAP method (512 264 bits) 266 MK: 268 Master Key between the client and EAP server from which all other 269 EAP method session keys are derived (KS octets) 271 MSK: 273 Master Session Key exported by to the EAP method (512 bits) 275 MID: 277 Method ID exported by the EAP method according to the EAP keying 278 framework [I-D.ietf-eap-keying] (128 bits) 280 PSK: 282 Long-term key shared between the client and the server (PL octets) 284 3. Overview 286 The EAP framework [RFC3748] defines four basic steps that occur 287 during the execution of an EAP conversation between client and 288 server. The first phase, discovery, is handled by the underlying 289 protocol. The authentication phase is defined here. The key 290 distribution and secure association phases are handled differently 291 depending on the underlying protocol, and are not discussed in this 292 document. 294 +--------+ +--------+ 295 | | EAP-Request/Identity | | 296 | EAP |<------------------------------------| EAP | 297 | peer | | server | 298 | | EAP-Response/Identity | | 299 | |------------------------------------>| | 300 | | | | 301 | | EAP-Request/GPSK-1 | | 302 | |<------------------------------------| | 303 | | | | 304 | | EAP-Response/GPSK-2 | | 305 | |------------------------------------>| | 306 | | | | 307 | | EAP-Request/GPSK-3 | | 308 | |<------------------------------------| | 309 | | | | 310 | | EAP-Response/GPSK-4 | | 311 | |------------------------------------>| | 312 | | | | 313 | | EAP-Success or EAP-Failure | | 314 | |<------------------------------------| | 315 +--------+ +--------+ 317 EAP-GPSK performs mutual authentication between EAP peer ("Client") 318 and EAP server ("Server") based on a pre-shared key (PSK). The 319 protocol consists of two EAP message exchanges, in which both sides 321 o exchange nonces and their identities and 323 o compute and exchange a Message Authentication Code (MAC) over the 324 previously exchanged values, keyed with the pre-shared key. This 325 MAC is considered as proof of possession of the pre-shared key. 327 The full EAP-GPSK protocol is as follows: 328 GPSK-1: 330 ID_Server, RAND_Server, CSuite_List 332 GPSK-2: 334 SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server, 335 CSuite_List, CSuite_Sel [, ENC_PK(PD_Payload_1), ... ] ) 337 GPSK-3 339 SEC_SK(RAND_Client, RAND_Server, CSuite_Sel [, 340 ENC_PK(PD_Payload_2) ] ) 342 GPSK-4: 344 [ SEC_SK(ENC_PK(PD_Payload_3)) ] 346 The EAP server begins EAP-GPSK creating a random number RAND_Server 347 and by encoding the supported ciphersuites into CSuite_List. A 348 ciphersuite consists of an encryption algorithm, a key derivation 349 function and a message authentication code. 351 In GPSK-1, the EAP server sends its identity ID_Server, a random 352 number RAND_Server and the identifier of the chosen ciphersuite. The 353 decision which ciphersuite to use is policy-dependent and therefore 354 outside the scope of this document. 356 In GPSK-2, the peer sends its identity ID_Client, a random number 357 RAND_Client. Furthermore, it repeats the received parameters of the 358 GPSK-1 message and computes a Message Authentication Code over all 359 these parameters. 361 The EAP server verifies the received Message Authentication Code. In 362 case of successful verification, the EAP server computes a Message 363 Authentication Code over the session parameter and returns it to the 364 client (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP 365 server have the possibility to exchange encrypted protected data 366 parameters. 368 The peer verifies the received Message Authentication Code. If the 369 verification is successful, GPSK-4 is prepared. This message can 370 optionally contain the client's protected data parameters. 372 Upon receipt of GPSK-4, the server assures that the peer has derived 373 session keys SK and PK properly. Then, the EAP server sends an EAP 374 Success message to indicate the successful outcome of the 375 authentication. 377 4. Key Derivation 379 EAP-GPSK provides key derivation in compliance to the requirements of 380 [RFC3748] and [I-D.ietf-eap-keying]. 382 The long-term credential shared between EAP peer and EAP server 383 SHOULD be a strong pre-shared key PSK of at least 16 bytes, though 384 its length and entropy is variable. While it is possible to use a 385 password or passphrase, doing so is NOT RECOMMENDED as it would make 386 EAP-GPSK vulnerable to dictionary attacks. 388 During an EAP-GPSK authentication, a Master Key MK, a Session Key SK 389 and a Protected Data Encryption Key PK are derived using the 390 ciphersuite-specified KDF and data exchanged during the execution of 391 the protocol, namely 'RAND_Client || ID_Client || RAND_Server || 392 ID_Server' referred as inputString as its short-hand form. 394 In case of successful completion, EAP-GPSK derives and exports an MSK 395 and EMSK both in length of 64 bytes. This keying material is derived 396 using the ciphersuite-specified KDF as follows: 398 o inputString = RAND_Client || ID_Client || RAND_Server || ID_Server 399 o MK = KDF_Zero-String (PL || PSK || CSuite_Sel || 400 inputString)[0..KS-1] 401 o SK = KDF_MK (inputString)[128..127+KS] 402 o PK = KDF_MK (inputString)[128+KS..127+2*KS] 403 o MSK = KDF_MK (inputString)[0..63] 404 o EMSK = KDF_MK (inputString)[64..127] 405 o MID = KDF_Zero-String ("Method ID" || EAP_Method_Type || 406 CSuite_Sel || inputString)[0..15] 408 Note that the term 'Zero-String' refers to a sequence of 0x00 values, 409 KS octets in length. EAP_Method_Type refers to the integer value of 410 the IANA allocated EAP Type code. 412 Figure 2 depicts the key derivation procedure of EAP-GPSK. 414 +-------------+ +-------------------------------+ 415 | PL-octet | | RAND_Client || ID_Client || | 416 | PSK | | RAND_Server || ID_Server | 417 +-------------+ +-------------------------------+ 418 | | | 419 v v | 420 +--------------------------------------------+ | 421 | KDF | | 422 +--------------------------------------------+ | 423 | | 424 v | 425 +-------------+ | 426 | KS-octet | | 427 | MK | | 428 +-------------+ | 429 | | 430 v v 431 +---------------------------------------------------+ 432 | KDF | 433 +---------------------------------------------------+ 434 | | | | 435 v v v v 436 +---------+ +---------+ +----------+ +----------+ 437 | 512-bit | | 512-bit | | KS-octet | | KS-octet | 438 | MSK | | EMSK | | SK | | PK | 439 +---------+ +---------+ +----------+ +----------+ 441 Figure 2: EAP-GPSK Key Derivation 443 5. Ciphersuites 445 The design of EAP-GPSK allows cryptographic algorithms and key sizes, 446 called ciphersuites, to be negotiated during the protocol run. The 447 ability to specify block-based and hash-based ciphersuites is 448 offered. Extensibility is provided with the introduction of new 449 ciphersuites; this document specifies an initial set. The CSuite/ 450 Specifier column in Figure 3 uniquely identifies a ciphersuite. 452 For a vendor-specific ciphersuite the first three octets are the 453 vendor-specific OID, and the last three octets are vendor assigned 454 for the specific ciphersuite. 456 The following ciphersuites are specified in this document: 458 +-----------+----+-------------+---------------+--------------------+ 459 | CSuite/ | KS | Encryption | Integrity | Key Derivation | 460 | Specifier | | | | Function | 461 +-----------+----+-------------+---------------+--------------------+ 462 | 0x000001 | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF-128 | 463 +-----------+----+-------------+---------------+--------------------+ 464 | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF-256 | 465 +-----------+----+-------------+---------------+--------------------+ 467 Figure 3: Ciphersuites 469 Ciphersuite 1, which is based on AES as a cryptographic primitive, is 470 mandatory to implement. This document specifies also a second 471 ciphersuite, but its support is only optional. 473 Each ciphersuite needs to specify a key derivation function. The 474 ciphersuites defined in this document make use of the Generalized Key 475 Distribution Function (GKDF). Future ciphersuites can use any other 476 formally specified KDF that takes as arguments a key and a seed 477 value, and produces at least 1024+2*KS bits of output. 479 If GKDF is invoked by a MAC-based ciphersuite, then the variable 480 "size" contains the MAC output size in octets. In case of a block 481 cipher-based ciphersuite, "size" contains the block size in octets. 483 GKDF has the following structure: 485 GKDF-X(Y, Z) 487 X length, in octets, of the desired output 488 Y secret key used to protect the computation 489 Z data specific for the protocol run 491 GKDF-X (Y, Z) 492 { 493 n = int( X / size - 1 ) + 1; /* determine number of 494 output blocks */ 495 M_0 = ""; 496 result = ""; 498 for i=1 to n { 499 M_i = MAC_Y (M_{i-1} || Z || i || X); 500 result = result || M_i; 501 } 503 return truncate (result; X) 504 } 505 Note that the variables 'i' and 'X' in M_i are represented as 16-bit 506 values in network byte order. 508 6. Ciphersuites Processing Rules 510 6.1. Ciphersuite #1 512 6.1.1. Encryption 514 With this ciphersuite all cryptography is built around a single 515 cryptographic primitive, AES-128. Within the protected data frames, 516 AES-128 is used in CBC mode of operation (see [CBC]). The CBC mode 517 is well-defined and well-understood. This mode requires an 518 Initialization Vector (IV) that has the same size as the block size. 519 For security reasons, the IV should be randomly generated. 521 In a nutshell, the CBC mode proceeds as follows. The IV is XORed 522 with the first plaintext block before it is encrypted. Then for 523 successive blocks, the previous ciphertext block is XORed with the 524 current plaintext, before it is encrypted. 526 Note that in order to provide integrity protection, the CBC-encrypted 527 ciphertext MUST be accompanied by a MAC. 529 [Editor's Note: Description about the computation of the IV is 530 missing] 532 6.1.2. Integrity 534 Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is 535 recommended by NIST. Among its advantages, CMAC is capable to work 536 with messages of arbitrary length. A detailed description of CMAC 537 can be found in [CMAC]. 539 The following instantiation is used: AES-128-CMAC(SK, Input) denotes 540 the MAC of Input under the key SK. 542 where Input refers to the following content: 544 o Value of SEC_SK in message GPSK-2 545 o Value of SEC_SK in message GPSK-3 546 o Value of SEC_SK in message GPSK-4 548 6.1.3. Key Derivation 550 This ciphersuite instantiates the KDF in the following way: 552 inputString = RAND_Client || ID_Client || RAND_Server || ID_Server 554 MK = GKDF-16 (Zero-String, PL || PSK || CSuite_SEL || inputString) 556 KDF_out = GKDF-160 (MK, inputString) 558 MSK = KDF_out[0..63] 560 EMSK = KDF_out[64..127] 562 SK = KDF_out[128..143] 564 PK = KDF_out[144..159] 566 MID = GKDF-16 (Zero-String, "Method ID" || EAP_Method_Type || 567 CSuite_Sel || inputString) 569 6.2. Ciphersuite #2 571 6.2.1. Encryption 573 Ciphersuite 2 does not include an algorithm for encryption. With a 574 NULL encryption algorithm, encryption is defined as: 576 E_X(Y) = Y 578 When using this ciphersuite, the data exchanged inside the protected 579 data blocks is not encrypted. Therefore this mode MUST NOT be used 580 if confidential information appears inside the protected data blocks. 582 6.2.2. Integrity 584 Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash 585 algorithm. 587 For integrity protection the following instantiation is used: 589 HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK 590 where Input refers to the following content: 592 o Value of SEC_SK in message GPSK-2 593 o Value of SEC_SK in message GPSK-3 594 o Value of SEC_SK in message GPSK-4 596 6.2.3. Key Derivation 598 This ciphersuite instantiates the KDF in the following way: 600 inputString = RAND_Client || ID_Client || RAND_Server || ID_Server 602 MK = GKDF-32 (Zero-String, PL || PSK || CSuite_SEL || inputString) 604 KDF_out = GKDF-192 (MK, inputString) 606 MSK = KDF_out[0..63] 608 EMSK = KDF_out[64..127] 610 SK = KDF_out[128..159] 612 PK = KDF_out[160..191] 614 MID = GKDF-16 (Zero-String, "Method ID" || EAP_Method_Type || 615 CSuite_Sel || inputString) 617 7. Packet Formats 619 This section defines the packet format of the EAP-GPSK messages. 621 7.1. Header Format 623 The EAP-GPSK header has the following structure: 625 --- bit offset ---> 626 0 1 2 3 627 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Code | Identifier | Length | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Type | OP-Code | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 633 | | 634 ... Payload ... 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Figure 5 640 The Code, Identifier, Length, and Type fields are all part of the EAP 641 header, and defined in [RFC3748]. IANA has allocated EAP Method Type 642 XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX. 644 The OP-Code field is one of four values: 646 o 0x01 : GPSK-1 647 o 0x02 : GPSK-2 648 o 0x03 : GPSK-3 649 o 0x04 : GPSK-4 651 7.2. Ciphersuite Formatting 653 Ciphersuites are encoded as 6-octet arrays. The first three octets 654 indicate the CSuite/Vendor field. For vendor-specific ciphersuites, 655 this represents the vendor OID. The last three octets indicate the 656 CSuite/Specifier field, which identifies the particular ciphersuite. 657 The 3-byte CSuite/Vendor value 0x000000 indicates ciphersuites 658 allocated by the IETF. 660 Graphically, they are represented as 662 --- bit offset ---> 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | CSuite/Vendor = 0x000000 or OID | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 CSuite / Specifier | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Figure 6 673 CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and 674 CSuite/Specifier pair. 676 CSuite_List is a variable-length octet array of ciphersuites. It is 677 encoded by concatenating encoded ciphersuite values. Its length in 678 octets MUST be a multiple of 6. 680 7.3. Payload Formatting 682 Payload formatting is based on the protocol exchange description in 683 Section 3. 685 The GPSK-1 payload format is defined as follows: 687 --- bit offset ---> 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | length(ID_Server) | | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 693 | | 694 ... ID_Server ... 695 | | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | | 698 ... 32-octet RAND_Server ... 699 | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | length(CSuite_List) | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 703 | | 704 ... CSuite_List ... 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 7: GPSK-1 Payload 710 The GPSK-2 payload format is defined as follows: 712 --- bit offset ---> 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | length(ID_Client) | | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 718 | | 719 ... ID_Client ... 720 | | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | length(ID_Server) | | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 724 | | 725 ... ID_Server ... 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | | 729 ... 32-octet RAND_Client ... 730 | | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | | 733 ... 32-octet RAND_Server ... 734 | | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | length(CSuite_List) | | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 738 | | 739 ... CSuite_List ... 740 | | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | CSuite_Sel | 743 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | length(PD_Payload_1) | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | | 747 ... optional PD_Payload_1 ... 748 | | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | 751 ... KS-octet payload MAC ... 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 8: GPSK-2 Payload 757 If the optional protected data payload is not included, then 758 length(PD_Payload)=0 and the PD payload is excluded. 760 The GPSK-3 payload is defined as follows: 762 --- bit offset ---> 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | | 767 ... 32-octet RAND_Client ... 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | | 771 ... 32-octet RAND_Server ... 772 | | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | CSuite_Sel | 775 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | | length(PD_Payload_2) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | | 779 ... optional PD_Payload_2 ... 780 | | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | | 783 ... KS-octet payload MAC ... 784 | | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Figure 9: GPSK-3 Payload 789 If the optional protected data payload is not included, then 790 length(PD_Payload)=0 and the PD payload is excluded. 792 The GPSK-4 payload format is defined as follows: 794 --- bit offset ---> 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | length(PD_Payload_3) | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 800 | | 801 ... optional PD_Payload_3 ... 802 | | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | | 805 ... KS-octet payload MAC ... 806 | | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Figure 10: GPSK-4 Payload 811 If the optional protected data payload is not included, then 812 length(PD_Payload)=0 and the PD payload is excluded. The MAC MUST 813 always be included, regardless of the presence of PD_Payload_3. 815 7.4. Protected Data 817 The protected data blocks are a generic mechanism for the client and 818 server to securely exchange data. If the specified ciphersuite has a 819 NULL encryption primitive, then this channel only offers 820 authenticity, and not confidentiality. 822 These payloads are encoded as the concatenation of type-length-value 823 (TLV) tripples. 825 Type values are encoded as a 6-octet string and represented by a 826 3-octet vendor and 3-octet specifier field. The vendor field 827 indicates the type as either standards-specified or vendor-specific. 828 If these three octets are 0x000000, then the value is standards- 829 specified, and any other value represents a vendor-specific OID. 831 The specifier field indicates the actual type. For vendor field 832 0x000000, the specifier field is maintained by IANA. For any other 833 vendor field, the specifier field is maintained by the vendor. 835 Length fields are specified as 2-octet integers in network byte 836 order, and reflect only the length of the value, and do not include 837 the length of the type and length fields. 839 Graphically, this can be depicted as follows: 841 --- bit offset ---> 842 0 1 2 3 843 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | PData/Vendor | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 PData/Specifier | Length | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | | 850 ... PD_Payload Value ... 851 | | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 For PData/Vendor field 0x000000, the following PData/Specifier fields 855 are defined: 856 o 0x000000 : Reserved 857 o 0x000001 : Protected Results Indication 858 o 0x000002 through 0xFFFFFF : Unallocated 860 [Editor's Note: Text for protected results indication needs to be 861 added here.] 863 8. Security Considerations 865 [RFC3748] highlights several attacks that are possible against EAP 866 since EAP itself does not provide any security. 868 This section discusses the claimed security properties of EAP-GPSK as 869 well as vulnerabilities and security recommendations in the threat 870 model of [RFC3748]. 872 8.1. Mutual Authentication 874 EAP-GPSK provides mutual authentication. 876 The server believes that the peer is authentic because it can 877 calculate a valid MAC and the peer believes that the server is 878 authentic because it can calculate another valid MAC. 880 The key used for mutual authentication is computed again based on the 881 long-term secret PSK that has to provide sufficient entropy and 882 therefore sufficient strength. In this way EAP-GPSK is no different 883 than other authentication protocols based on pre-shared keys. 885 8.2. Protected Result Indications 887 EAP-GPSK offers the capability to exchange protected result 888 indications using the protected data payloads. 890 8.3. Integrity Protection 892 EAP-GPSK provides integrity protection based on the ciphersuites 893 suggested in this document. 895 8.4. Replay Protection 897 EAP-GPSK provides replay protection of its mutual authentication part 898 thanks to the use of random numbers RAND_Server and RAND_P. Since 899 RAND_Server is 128 bit long, one expects to have to record 2**64 900 (i.e., approximately 1.84*10**19) EAP-GPSK successful authentication 901 before an protocol run can be replayed. Hence, EAP-GPSK provides 902 replay protection of its mutual authentication part as long as 903 RAND_Server and RAND_Client are chosen at random, randomness is 904 critical for security. 906 8.5. Reflection attacks 908 EAP-GPSK provides protection against reflection attacks in case of an 909 extended authentication because of the messages are constructed in a 910 different fashion. 912 8.6. Dictionary Attacks 914 EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based 915 on at least 128 bits of entropy to guarantee security against 916 dictionary attacks. Users who use passwords or weak keys are not 917 guaranteed security against dictionary attacks. Derivation of the 918 long-term shared secret from a password is highly discouraged. 920 8.7. Key Derivation 922 EAP-GPSK supports key derivation as shown in Section 4. 924 8.8. Denial of Service Resistance 926 Denial of Service resistance (DoS) has not been a design goal for 927 EAP-GPSK. 929 It is however believed that EAP-GPSK does not provide any obvious and 930 avoidable venue for such attacks. 932 It is worth noting that the server has to maintain some state when it 933 engages in an EAP-GPSK conversation, namely to generate and to 934 remember the 16-byte RAND_S. This should however not lead to resource 935 exhaustion as this state and the associated computation are fairly 936 lightweight. 938 It is recommended that EAP-GPSK does not allow EAP notifications to 939 be interleaved in its dialog to prevent potential DoS attacks. 940 Indeed, since EAP Notifications are not integrity protected, they can 941 easily be spoofed by an attacker. Such an attacker could force a 942 peer that allows EAP Notifications to engage in a discussion which 943 would delay his authentication or result in the peer taking 944 unexpected actions (e.g., in case a notification is used to prompt 945 the peer to do some "bad" action). 947 It is up to the implementation of EAP-GPSK or to the peer and the 948 server to specify the maximum number of failed cryptographic checks 949 that are allowed. 951 8.9. Session Independence 953 Thanks to its key derivation mechanisms, EAP-GPSK provides session 954 independence: passive attacks (such as capture of the EAP 955 conversation) or active attacks (including compromise of the MSK or 956 EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. 957 The assumption that RAND_Client and RAND_Server are random is central 958 for the security of EAP-GPSK in general and session independance in 959 particular. 961 8.10. Exposition of the PSK 963 EAP-GPSK does not provide perfect forward secrecy. Compromise of the 964 PSK leads to compromise of recorded past sessions. 966 Compromise of the PSK enables the attacker to impersonate the peer 967 and the server and it allows the adversary to compromise future 968 sessions. 970 EAP-GPSK provides no protection against a legitimate peer sharing its 971 PSK with a third party. Such protection may be provided by 972 appropriate repositories for the PSK, which choice is outside the 973 scope of this document. The PSK used by EAP-GPSK must only be shared 974 between two parties: the peer and the server. In particular, this 975 PSK must not be shared by a group of peers communicating with the 976 same server. 978 The PSK used by EAP-GPSK must be cryptographically separated from 979 keys used by other protocols, otherwise the security of EAP-GPSK may 980 be compromised. 982 8.11. Fragmentation 984 EAP-GPSK does not support fragmentation and reassembly since the 985 message size is kept small. 987 8.12. Channel Binding 989 This document enables the ability to exchange channel binding 990 information. It does not, however, define the encoding of channel 991 binding information in the document. 993 8.13. Fast Reconnect 995 EAP-GPSK does not provide the fast reconnect capability since this 996 method is already at the lower limit of the number of roundtrips and 997 the cryptographic operations. 999 8.14. Identity Protection 1001 Identity protection is not specified in this document. Extensions 1002 can be defined that enhanced this protocol to provide this feature. 1004 8.15. Protected Ciphersuite Negotiation 1006 EAP-GPSK provides protected ciphersuite negotiation via the 1007 indication of available ciphersuites by the server in the first 1008 message and a confirmation by the client in the subsequent message. 1010 8.16. Confidentiality 1012 Although EAP-GPSK provides confidentiality in its protected data 1013 payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748]. 1015 8.17. Cryptographic Binding 1017 Since EAP-GPSK does not tunnel another EAP method, it does not 1018 implement cryptographic binding. 1020 9. IANA Considerations 1022 This document requires IANA to allocate a new EAP Type for EAP-GPSK. 1024 This document requires IANA to create a new registry for ciphersuites 1025 and protected data types. IANA is furthermore instructed to add the 1026 specified ciphersuites and protected data types to this registry as 1027 defined in this document. Values can be added or modified with 1028 informational RFCs defining either block-based or hash-based 1029 ciphersuites. Each ciphersuite needs to provide processing rules and 1030 needs to specify how the following algorithms are instantiated: 1031 Encryption, Integrity and Key Derivation. Additionally, the 1032 preferred key size needs to be specified. 1034 The following layout represents the initial ciphersuite CSuite/ 1035 Specifier registry setup: 1037 o 0x000000 : Reserved 1038 o 0x000001 : AES-CBC-128, AES-CMAC-128, GKDF-128 1039 o 0x000002 : NULL, HMAC-SHA256, GKDF-256 1040 o 0x000003 through 0xFFFFFF : Unallocated 1042 The following is the initial protected data PData/Specifier registry 1043 setup: 1045 o 0x000000 : Reserved 1046 o 0x000001 : Protected Results Indication 1047 o 0x000002 through 0xFFFFFF : Unallocated 1049 10. Contributors 1051 This work is a joint effort of the EAP Method Update (EMU) design 1052 team of the EMU Working Group that was created to develop a mechanism 1053 based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 1054 4017 [RFC4017] requirements. The contributors (in alphabetical 1055 order) include: 1057 o Jari Arkko 1058 o Mohamad Badra 1059 o Uri Blumenthal 1060 o Charles Clancy 1061 o Lakshminath Dondeti 1062 o David McGrew 1063 o Joe Salowey 1064 o Sharma Suman 1065 o Hannes Tschofenig 1066 o Jesse Walker 1068 Finally, we would like to thank Thomas Otto for his draft reviews, 1069 feedback and text contributions. 1071 11. Acknowledgment 1073 We would like to thank 1074 o Jouni Malinen and Bernard Aboba for their early draft comments in 1075 June 2006. 1076 o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela 1077 Vanderveen and Ray Bell for their input to the ciphersuite 1078 discussions between July and August 2006. 1079 o Lakshminath for his detailed draft review (sent to the EMU ML on 1080 the 12th July 2006). 1082 12. Open Issues 1084 The list of open issues can be found at: 1085 http://www.tschofenig.com:8080/eap-gpsk/ 1087 A first prototype implementation by Jouni Malinen can be found at: 1088 http://hostap.epitest.fi/releases/snapshots/ 1090 13. References 1092 13.1. Normative References 1094 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1095 Requirement Levels", March 1997. 1097 [RFC2486bis] 1098 Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1099 Network Access Identifier", 1100 draft-ietf-radext-rfc2486bis-06 (work in progress), 1101 July 2005. 1103 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1104 (SHA1)", RFC 3174, September 2001. 1106 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1107 Levkowetz, "Extensible Authentication Protocol (EAP)", 1108 RFC 3748, June 2004. 1110 13.2. Informative References 1112 [I-D.clancy-eap-pax] 1113 Clancy, C. and W. Arbaugh, "EAP Password Authenticated 1114 Exchange", draft-clancy-eap-pax-11 (work in progress), 1115 September 2006. 1117 [I-D.bersani-eap-psk] 1118 Tschofenig, H. and F. Bersani, "The EAP-PSK Protocol: a 1119 Pre-Shared Key EAP Method", draft-bersani-eap-psk-11 (work 1120 in progress), June 2006. 1122 [I-D.otto-emu-eap-tls-psk] 1123 Otto, T. and H. Tschofenig, "The EAP-TLS-PSK 1124 Authentication Protocol", draft-otto-emu-eap-tls-psk-01 1125 (work in progress), October 2006. 1127 [I-D.vanderveen-eap-sake] 1128 Vanderveen, M. and H. Soliman, "Extensible Authentication 1129 Protocol Method for Shared-secret Authentication and Key 1130 Establishment (EAP-SAKE)", draft-vanderveen-eap-sake-02 1131 (work in progress), May 2006. 1133 [I-D.ietf-eap-keying] 1134 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1135 Management Framework", draft-ietf-eap-keying-15 (work in 1136 progress), October 2006. 1138 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1139 Authentication Protocol (EAP) Method Requirements for 1140 Wireless LANs", RFC 4017, March 2005. 1142 [CMAC] National Institute of Standards and Technology, 1143 "Recommendation for Block Cipher Modes of Operation: The 1144 CMAC Mode for Authentication", Special Publication 1145 (SP) 800-38B, May 2005. 1147 [CBC] National Institute of Standards and Technology, 1148 "Recommendation for Block Cipher Modes of Encryption. 1149 Methods and Techniques.", Special Publication (SP) 800- 1150 38A, December 2001. 1152 Authors' Addresses 1154 T. Charles Clancy 1155 DoD Laboratory for Telecommunication Sciences 1156 8080 Greenmeade Drive 1157 College Park, MD 20740 1158 USA 1160 Email: clancy@ltsnet.net 1161 Hannes Tschofenig 1162 Siemens 1163 Otto-Hahn-Ring 6 1164 Munich, Bavaria 81739 1165 Germany 1167 Email: Hannes.Tschofenig@siemens.com 1168 URI: http://www.tschofenig.com 1170 Full Copyright Statement 1172 Copyright (C) The Internet Society (2006). 1174 This document is subject to the rights, licenses and restrictions 1175 contained in BCP 78, and except as set forth therein, the authors 1176 retain all their rights. 1178 This document and the information contained herein are provided on an 1179 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1180 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1181 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1182 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1183 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1184 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1186 Intellectual Property 1188 The IETF takes no position regarding the validity or scope of any 1189 Intellectual Property Rights or other rights that might be claimed to 1190 pertain to the implementation or use of the technology described in 1191 this document or the extent to which any license under such rights 1192 might or might not be available; nor does it represent that it has 1193 made any independent effort to identify any such rights. Information 1194 on the procedures with respect to rights in RFC documents can be 1195 found in BCP 78 and BCP 79. 1197 Copies of IPR disclosures made to the IETF Secretariat and any 1198 assurances of licenses to be made available, or the result of an 1199 attempt made to obtain a general license or permission for the use of 1200 such proprietary rights by implementers or users of this 1201 specification can be obtained from the IETF on-line IPR repository at 1202 http://www.ietf.org/ipr. 1204 The IETF invites any interested party to bring to its attention any 1205 copyrights, patents or patent applications, or other proprietary 1206 rights that may cover technology that may be required to implement 1207 this standard. Please address the information to the IETF at 1208 ietf-ipr@ietf.org. 1210 Acknowledgment 1212 Funding for the RFC Editor function is provided by the IETF 1213 Administrative Support Activity (IASA).