idnits 2.17.1 draft-clancy-emu-eap-shared-secret-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 1222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1212. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 1153 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 (June 26, 2006) is 6512 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 1126, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3174 == Outdated reference: A later version (-11) exists of draft-clancy-eap-pax-07 == Outdated reference: A later version (-02) exists of draft-otto-emu-eap-tls-psk-00 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-13 Summary: 4 errors (**), 0 flaws (~~), 8 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 Expires: December 28, 2006 H. Tschofenig 5 Siemens 6 June 26, 2006 8 EAP Generalized Pre-Shared Key (EAP-GPSK) 9 draft-clancy-emu-eap-shared-secret-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 December 28, 2006. 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . 23 82 8.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 23 83 8.8. Denial of Service Resistance . . . . . . . . . . . . . . . 23 84 8.9. Session Independence . . . . . . . . . . . . . . . . . . . 23 85 8.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . 25 92 8.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 25 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 11. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26 99 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 103 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 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 117 o EAP-PAX [I-D.clancy-eap-pax] 118 o EAP-PSK [I-D.bersani-eap-psk] 119 o EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and 120 o EAP-SAKE [I-D.vanderveen-eap-sake]. 121 Each proposal has its particular benefits but also its particular 122 deficiencies. EAP-GPSK is a new EAP method that tries to combine the 123 most valuable characteristics of each of these methods and therefore 124 attempts to address a broad range of usage scenarios. 126 The main design goals of EAP-GPSK are 127 Simplicity: 129 EAP-GPSK should be easy to implement and therefore quickly 130 available. 132 Wide applicability: 134 EAP-GPSK has been designed in a threat model where the attacker 135 has full control over the communication channel. This is the EAP 136 threat model that is presented in Section 7.1 of [RFC3748]. Thus, 137 it is particularly suited for wireless or battery powered devices. 139 Efficiency: 141 EAP-GPSK does not make use of public key cryptography and fully 142 relies of symmetric cryptography. The restriction on symmetric 143 cryptographic computations allows for low computational overhead. 144 Hence, EAP-GPSK is lightweight and well suited for any type of 145 device, especially those with little processing power and memory. 147 Flexibility: 149 EAP-GPSK offers cryptographic flexibility. At the beginning, the 150 EAP server selects a set of cryptographic algorithms and key 151 sizes, a so called ciphersuite. The current version of EAP-GPSK 152 comprises two ciphersuites, but additional ones can be easily 153 added. 155 Extensibility: 157 The design of EAP-GPSK allows to securely exchange information 158 between the EAP peer and the EAP server using protected data 159 fields. These fields might, for example, be used to exchange 160 channel binding information or to provide support for identity 161 confidentiality. 163 2. Terminology 165 In this document, several words are used to signify the requirements 166 of the specification. These words are often capitalized. The key 167 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 168 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 169 are to be interpreted as described in [RFC2119]. 171 This section describes the various variables and functions used in 172 the EAP-GPSK method. 174 Variables: 176 PD_Payload_X: 178 Data carried within the X-th protected data payload 179 CSuite_List: 181 An octet array listing available ciphersuites (variable length) 183 CSuite_Sel: 185 Ciphersuite selected by the client (1 octet or 7 octets) 187 ID_Client: 189 Client NAI [RFC2486bis] 191 ID_Server: 193 Server identity as an opaque blob. 195 KS: 197 Integer representing the key size in octets of the selected 198 ciphersuite CSuite_Sel 200 RAND_Client: 202 Random integer generated by the client (256 bits) 204 RAND_Server: 206 Random integer generated by the server (256 bits) 208 KDFData_Client: 210 Arbitrary data provided by the client to be included in the KDF 212 KDFData_Server: 214 Arbitrary data provided by the server to be included in the KDF 216 Operations: 218 A || B: 220 Concatenation of octet strings A and B 222 ENC_X(Y): 224 Encryption of message Y with a symmetric key X, using a defined 225 block cipher 227 KDF_X(Y): 229 Key Derivation Function that generates an arbitrary number of 230 octets of output using secret X and seed Y 231 length(X): 233 Function that returns the length of input X in octets, encoded as 234 a 16-bit integer in network byte order 236 MAC_X(Y): 238 Keyed message authentication code computed over Y with symmetric 239 key X 241 SEC_X(Y): 243 SEC is a function that provides integrity protection based on the 244 chosen ciphersuite. The function SEC uses the algorithm defined 245 by the selected ciphersuite and applies it to the message content 246 Y with key X. As an output the message returns Y concatenated with 247 MAC_X(Y). 249 X[A..B]: 251 Notation representing octets A through B of octet array X 253 The following abbreviations are used for the keying material: 255 PK: 257 Session key generated from the MK and used during protocol 258 exchange to encrypt protected data (size defined by ciphersuite) 260 SK: 262 Session key generated from the MK and used during protocol 263 exchange to prove knowledge of PSK (size defined by ciphersuite) 265 EMSK: 267 Extended Master Session Key is exported by the EAP method (512 268 bits) 270 MK: 272 Master Key between the client and EAP server from which all other 273 EAP method session keys are derived (KS octets) 275 MSK: 277 Master Session Key exported by to the EAP method (512 bits) 279 MID: 281 Method ID exported by the EAP method according to the EAP keying 282 framework [I-D.ietf-eap-keying] (128 bits) 284 PSK: 286 Long-term key shared between the client and the server (PL octets) 288 3. Overview 290 The EAP framework [RFC3748] defines four basic steps that occur 291 during the execution of an EAP conversation between client and 292 server. The first phase, discovery, is handled by the underlying 293 protocol. The authentication phase is defined here. The key 294 distribution and secure association phases are handled differently 295 depending on the underlying protocol, and are not discussed in this 296 document. 298 +--------+ +--------+ 299 | | EAP-Request/Identity | | 300 | EAP |<------------------------------------| EAP | 301 | peer | | server | 302 | | EAP-Response/Identity | | 303 | |------------------------------------>| | 304 | | | | 305 | | EAP-Request/GPSK-1 | | 306 | |<------------------------------------| | 307 | | | | 308 | | EAP-Response/GPSK-2 | | 309 | |------------------------------------>| | 310 | | | | 311 | | EAP-Request/GPSK-3 | | 312 | |<------------------------------------| | 313 | | | | 314 | | EAP-Response/GPSK-4 | | 315 | |------------------------------------>| | 316 | | | | 317 | | EAP-Success or EAP-Failure | | 318 | |<------------------------------------| | 319 +--------+ +--------+ 321 EAP-GPSK performs mutual authentication between EAP peer ("Client") 322 and EAP server ("Server") based on a pre-shared key (PSK). The 323 protocol consists of two EAP message exchanges, in which both sides 325 o exchange nonces and their identities and 327 o compute and exchange a Message Authentication Code (MAC) over the 328 previously exchanged values, keyed with the pre-shared key. This 329 MAC is considered as proof of possession of the pre-shared key. 331 The full EAP-GPSK protocol is as follows: 332 GPSK-1: 334 ID_Server, RAND_Server, CSuite_List 336 GPSK-2: 338 SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server, 339 CSuite_List, CSuite_Sel [, ENC_PK(PD_Payload_1), ... ] ) 341 GPSK-3 343 SEC_SK(RAND_Client, RAND_Server, CSuite_Sel [, 344 ENC_PK(PD_Payload_2) ] ) 346 GPSK-4: 348 [ SEC_SK(ENC_PK(PD_Payload_3)) ] 350 The EAP server begins EAP-GPSK creating a random number RAND_Server 351 and by encoding the supported ciphersuites into CSuite_List. A 352 ciphersuite consists of an encryption algorithm, a key derivation 353 function and a message authentication code. 355 In GPSK-1, the EAP server sends its identity ID_Server, a random 356 number RAND_Server and the identifier of the chosen ciphersuite. The 357 decision which ciphersuite to use is policy-dependent and therefore 358 outside the scope of this document. 360 In GPSK-2, the peer sends its identity ID_Client, a random number 361 RAND_Client. Furthermore, it repeats the received parameters of the 362 GPSK-1 message and computes a Message Authentication Code over all 363 these parameters. 365 The EAP server verifies the received Message Authentication Code. In 366 case of successful verification, the EAP server computes a Message 367 Authentication Code over the session parameter and returns it to the 368 client (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP 369 server have the possibility to exchange encrypted protected data 370 parameters. 372 The peer verifies the received Message Authentication Code. If the 373 verification is successful, GPSK-4 is prepared. This message can 374 optionally contain the client's protected data parameters. 376 Upon receipt of GPSK-4, the server assures that the peer has derived 377 session keys SK and PK properly. Then, the EAP server sends an EAP 378 Success message to indicate the successful outcome of the 379 authentication. 381 4. Key Derivation 383 EAP-GPSK provides key derivation in compliance to the requirements of 384 [RFC3748] and [I-D.ietf-eap-keying]. 386 The long-term credential shared between EAP peer and EAP server 387 SHOULD be a strong pre-shared key PSK of at least 16 bytes, though 388 its length and entropy is variable. while it is possible to use a 389 password or passphrase, doing so is NOT RECOMMENDED as it would make 390 EAP-GPSK vulnerable to dictionary attack. 392 During an EAP-GPSK authentication, a Master Key MK, a Session Key SK 393 and a Protected Data Encryption Key PK are derived using the 394 ciphersuite-specified KDF and the entropy exchanged during the 395 execution of the protocol. 397 In case of successful completion, EAP-GPSK derives and exports an MSK 398 and EMSK both in length of 64 byte. This keying material is derived 399 using the ciphersuite-specified KDF as follows: 400 o Entropy = RAND_Client || RAND_Server || ID_Client || ID_Server 401 o MK = KDF_Zero-String (PL || PSK || CSuite_Sel || Entropy)[0..KS-1] 402 o SK = KDF_MK (Entropy)[128..127+KS] 403 o PK = KDF_MK (Entropy)[128+KS..127+2*KS] 404 o MSK = KDF_MK (Entropy || KDFData_Client || KDFData_Server)[0..63] 405 o EMSK = KDF_MK (Entropy || KDFData_Client || 406 KDFData_Server)[64..127] 407 o MID = KDF_Zero-String ("Method ID" || EAP_Method_Type || 408 CSuite_Sel || Entropy)[0..15] 410 Note that the term 'Zero-String' refers to a sequence of 0x00 values, 411 KS octets in length. EAP_Method_Type refers to the integer value of 412 the IANA allocated EAP Type code. 414 Figure 2 depicts the key derivation procedure of EAP-GPSK. 416 +-------------+ +-------------------------------+ 417 | PL-octet | | RAND_Client || RAND_Server || | 418 | PSK | | ID_Client || ID_Server | 419 +-------------+ +-------------------------------+ 420 | | | 421 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 | 512-bit | | 512-bit | | KS-octet | | KS-octet | 440 | MSK | | EMSK | | SK | | PK | 441 +---------+ +---------+ +----------+ +----------+ 443 Figure 2: EAP-GPSK Key Derivation 445 5. Ciphersuites 447 The design of EAP-GPSK allows cryptographic algorithms and key sizes, 448 called ciphersuite, to be negotiated during the protocol run. The 449 ability to specify block-based and hash-based ciphersuites is 450 offered. Extensibility is provided with the introduction of new 451 ciphersuites; this document specifies an initial set. The CSuite/ 452 Specifier column in Figure 3 uniquely identifies a ciphersuite. 454 For a vendor-specific ciphersuite the first three octets are the 455 vendor-specific OID, and the last three octets are vendor assigned 456 for the specific ciphersuite. 458 The following ciphersuites are specified in this document: 460 +-----------+----+-------------+---------------+--------------------+ 461 | CSuite/ | KS | Encryption | Integrity | Key Derivation | 462 | Specifier | | | | Function | 463 +-----------+----+-------------+---------------+--------------------+ 464 | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 | 465 +-----------+----+-------------+---------------+--------------------+ 466 | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF-256 | 467 +-----------+----+-------------+---------------+--------------------+ 469 Figure 3: Ciphersuites 471 Ciphersuite 1, which is based on AES as a cryptographic primitive, is 472 mandatory to implement. 474 Each ciphersuite needs to specify a key derivation function. The 475 ciphersuites defined in this document make use of the Generalized Key 476 Distribution Function (GKDF). Future ciphersuites can use any other 477 formally specified KDF that takes as arguments a key and a seed or 478 entropy value, and produces at least 1024+2*KS bits of output. 480 If GKDF is invoked by a MAC-based ciphersuite, then the variable 481 "size" contains the MAC output size in octets. In case of a block 482 cipher-based ciphersuite, "size" contains the block size in octets. 484 GKDF has the following structure: 486 GKDF-X(Y, Z) 488 X length, in octets, of the desired output 489 Y secret key used to protect the computation 490 Z data specific for the protocol run 492 GKDF-X (Y, Z) 493 { 494 n = int( X / size - 1 ) + 1; /* determine number of 495 output blocks */ 496 M_0 = ""; 497 result = ""; 499 for i=1 to n { 500 M_i = MAC_Y (M_{i-1} || Z || i || X); 501 result = result || M_i; 502 } 504 return truncate (result; X) 505 } 506 Note that the variables 'i' and 'X' in M_i are represented as 16-bit 507 values in network byte order. 509 6. Ciphersuites Processing Rules 511 6.1. Ciphersuite #1 513 6.1.1. Encryption 515 With this ciphersuite all cryptography is built around a single 516 cryptographic primitive, AES-128. Within the protected data frames, 517 AES-128 is used in EAX mode of operation. Ciphersuite 1 makes use of 518 the EAX mode of encryption. EAX is an Authenticated-Encryption-With- 519 Associated-Data (AEAD) scheme. It has as input a plaintext M, a 520 header H and a nonce N and is keyed with a key K. The idea is that 521 both M and H are integrity protected, but only M is encrypted. 522 Therefore, EAX encryption returns the ciphertext, which consists of H 523 and encrypted M, and a cryptographic checksum Tag T. 525 H || C || T = EAX.Encrypt (K; N, H, M) 527 H || M = EAX.Decrypt (K; N, H, C, T) 529 EAX strongly relies on CMAC and is therefore suited to be used in 530 combination with this. 532 The following instantiation is used: 534 E = C || T = EAX.Encrypt (SK; Input), where Input refers to the 535 following content: 536 o Value of PD_Payload_1 in message GPSK-2 537 o Value of PD_Payload_2 in message GPSK-3 538 o Value of PD_Payload_3 in message GPSK-4 540 6.1.2. Integrity 542 Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is 543 recommended by NIST. Among its advantages, CMAC is capable to work 544 with messages of arbitrary length. A detailed description of CMAC 545 can be found in [CMAC]. 547 The following instantiation is used: AES-128-CMAC(SK, Input) denotes 548 the MAC of Input under the key SK. 550 where Input refers to the following content: 552 o Value of SEC_SK in message GPSK-2 553 o Value of SEC_SK in message GPSK-3 554 o Value of SEC_SK in message GPSK-4 556 6.1.3. Key Derivation 558 This ciphersuite instantiates the KDF in the following way: 560 MK = GKDF-16 (PSK[0..15], RAND_Client || RAND_Server || ID_Server || 561 ID_Client) 563 KDF_out = GKDF-160 (MK, RAND_Client || RAND_Server || ID_Server || 564 ID_Client) 566 MSK = KDF_out[0..63] 568 EMSK = KDF_out[64..127] 570 SK = KDF_out[128..143] 572 PK = KDF_out[144..159] 574 MID = GKDF-16 (Zero-String, "Method ID" || EAP_Method_Type || 575 RAND_Client || RAND_Server || ID_Server || ID_Client) 577 6.2. Ciphersuite #2 579 6.2.1. Encryption 581 Ciphersuite 2 does not include an algorithm for encryption. With a 582 NULL encryption algorithm, encryption is defined as: 584 E_X(Y) = Y 586 When using this ciphersuite, the data exchanged inside the protected 587 data blocks is not encrypted. Therefore this mode MUST NOT be used 588 if confidential information appears inside the protected data blocks. 590 6.2.2. Integrity 592 Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash 593 algorithm. 595 For integrity protection the following instantiation is used: 597 HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK 598 where Input refers to the following content: 600 o Value of SEC_SK in message GPSK-2 601 o Value of SEC_SK in message GPSK-3 602 o Value of SEC_SK in message GPSK-4 604 6.2.3. Key Derivation 606 This ciphersuite instantiates the KDF in the following way: 608 MK = GKDF-32 (PSK, RAND_Client || RAND_Server || ID_Server || 609 ID_Client || CSuite_Sel) 611 KDF_out = GKDF-192 (MK, RAND_Client || RAND_Server || ID_Server || 612 ID_Client) 614 MSK = KDF_out[0..63] 616 EMSK = KDF_out[64..127] 618 SK = KDF_out[128..159] 620 PK = KDF_out[160..191] 622 MID = GKDF-16 (Zero-String, "Method ID" || EAP_Method_Type || 623 RAND_Client || RAND_Server || ID_Server || ID_Client) 625 7. Packet Formats 627 This section defines the packet format of the EAP-GPSK messages. 629 7.1. Header Format 631 The EAP-GPSK header has the following structure: 633 --- bit offset ---> 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Code | Identifier | Length | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | OP-Code | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 641 | | 642 ... Payload ... 643 | | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Figure 5 647 The Code, Identifier, Length, and Type fields are all part of the EAP 648 header, and defined in [RFC3748]. IANA has allocated EAP Method Type 649 XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX. 651 The OP-Code field is one of four values: 653 o 0x01 : GPSK-1 654 o 0x02 : GPSK-2 655 o 0x03 : GPSK-3 656 o 0x04 : GPSK-4 658 7.2. Ciphersuite Formatting 660 Ciphersuites are encoded as 6-octet arrays. The first three octets 661 indicate the CSuite/Vendor field. For vendor-specific ciphersuites, 662 this represents the vendor OID. The last three octets indicate the 663 CSuite/Specifier field, which identifies the particular ciphersuite. 664 The 3-byte CSuite/Vendor value 0x000000 indicates ciphersuites 665 allocated by the IETF. 667 Graphically, they are represented as 669 --- bit offset ---> 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | CSuite/Vendor = 0x000000 or OID | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 CSuite / Specifier | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Figure 6 680 CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and 681 CSuite/Specifier pair. 683 CSuite_List is a variable-length octet array of ciphersuites. It is 684 encoded by concatenating encoded ciphersuite values. Its length in 685 octets MUST be a multiple of 6. 687 7.3. Payload Formatting 689 Payload formatting is based on the protocol exchange description in 690 Section 3. 692 The GPSK-1 payload format is defined as follows: 694 --- bit offset ---> 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | length(ID_Server) | | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 700 | | 701 ... ID_Server ... 702 | | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | | 705 ... 32-octet RAND_Server ... 706 | | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | length(CSuite_List) | | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 710 | | 711 ... CSuite_List ... 712 | | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Figure 7: GPSK-1 Payload 717 The GPSK-2 payload format is defined as follows: 719 --- bit offset ---> 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | length(ID_Client) | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 725 | | 726 ... ID_Client ... 727 | | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | length(ID_Server) | | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 731 | | 732 ... ID_Server ... 733 | | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | | 736 ... 32-octet RAND_Client ... 737 | | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | | 740 ... 32-octet RAND_Server ... 741 | | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | length(CSuite_List) | | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 745 | | 746 ... CSuite_List ... 747 | | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | CSuite_Sel | 750 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | | length(PD_Payload_1) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 ... optional PD_Payload_1 ... 755 | | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | | 758 ... KS-octet payload MAC ... 759 | | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 Figure 8: GPSK-2 Payload 764 If the optional protected data payload is not included, then 765 length(PD_Payload)=0 and the PD payload is excluded. 767 The GPSK-3 payload is defined as follows: 769 --- bit offset ---> 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | | 774 ... 32-octet RAND_Client ... 775 | | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | | 778 ... 32-octet RAND_Server ... 779 | | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | CSuite_Sel | 782 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | | length(PD_Payload_2) | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | | 786 ... optional PD_Payload_2 ... 787 | | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | | 790 ... KS-octet payload MAC ... 791 | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Figure 9: GPSK-3 Payload 796 If the optional protected data payload is not included, then 797 length(PD_Payload)=0 and the PD payload is excluded. 799 The GPSK-4 payload format is defined as follows: 801 --- bit offset ---> 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | length(PD_Payload_3) | | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 807 | | 808 ... optional PD_Payload_3 ... 809 | | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | | 812 ... KS-octet payload MAC ... 813 | | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Figure 10: GPSK-4 Payload 818 If the optional protected data payload is not included, then 819 length(PD_Payload)=0 and the PD payload is excluded. The MAC MUST 820 always be included, regardless of the presence of PD_Payload_3. 822 7.4. Protected Data 824 The protected data blocks are a generic mechanism for the client and 825 server to securely exchange data. If the specified ciphersuite has a 826 NULL encryption primitive, then this channel only offers 827 authenticity, and not confidentiality. 829 These payloads are encoded as the concatenation of type-length-value 830 (TLV) tripples. 832 Type values are encoded as a 6-octet string and represented by a 833 3-octet vendor and 3-octet specifier field. The vendor field 834 indicates the type as either standards-specified or vendor-specific. 835 If these three octets are 0x000000, then the value is standards- 836 specified, and any other value represents a vendor-specific OID. 838 The specifier field indicates the actual type. For vendor field 839 0x000000, the specifier field is maintained by IANA. For any other 840 vendor field, the specifier field is maintained by the vendor. 842 Length fields are specified as 2-octet integers in network byte 843 order, and reflect only the length of the value, and do not include 844 the length of the type and length fields. 846 Graphically, this can be depicted as follows: 848 --- bit offset ---> 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | PData/Vendor | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 PData/Specifier | Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | | 857 ... PD_Payload Value ... 858 | | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 For PData/Vendor field 0x000000, the following PData/Specifier fields 862 are defined: 863 o 0x000000 : Reserved 864 o 0x000001 : Channel Binding Data 865 o 0x000002 : Protected Results Indication 866 o 0x000003 : Extra KDF Data 867 o 0x000004 through 0xFFFFFF : Unallocated 869 Definition of channel binding data is outside the scope of this 870 document. These protected payloads can be used to carry such data 871 once it has been formally specified. 873 Definition of the protected results indication field is outside the 874 scope of this document. It could be used to indicate the success or 875 failure of both authentication and authorization in a secure way. 877 The Extra KDF Data field specifies an arbitrary amount of additional 878 data, represented as KDFData_Client and KDFData_Server, and is used 879 in the derivation of the MSK and EMSK exported by GPSK to EAP. It 880 can be used to extensibly bind data into the key derivation process. 882 KDFData_Server can ONLY be specified in PD_Payload_2. KDFData_Client 883 can only be bound to data specified in PD_Payload_3. If multiple 884 entries are specified in a single PD_Payload with PData/Specifier 3, 885 then the first field must be used. These fields MUST NOT contain 886 plaintext, sensitive data if a ciphersuite is used that specifies a 887 NULL encryption primitive. 889 If the Extra KDF Data field is not used, then KDFData_Server and 890 KDFData_Client MUST both be zero-length octet arrays, and therefore 891 not included in the KDF. 893 8. Security Considerations 895 [RFC3748] highlights several attacks that are possible against EAP 896 since EAP itself does not provide any security. 898 This section discusses the claimed security properties of EAP-GPSK as 899 well as vulnerabilities and security recommendations in the threat 900 model of [RFC3748]. 902 8.1. Mutual Authentication 904 EAP-GPSK provides mutual authentication. 906 The server believes that the peer is authentic because it can 907 calculate a valid MAC and the peer believes that the server is 908 authentic because it can calculate another valid MAC. 910 The key used for mutual authentication is computed again based on the 911 long-term secret PSK that has to provide sufficient entropy and 912 therefore sufficient strength. In this way EAP-GPSK is no different 913 than other authentication protocols based on pre-shared keys. 915 8.2. Protected Result Indications 917 EAP-GPSK provides protected result indications based on information 918 exchanged inside the protected data payloads. 920 8.3. Integrity Protection 922 EAP-GPSK provides integrity protection based on the ciphersuites 923 suggested in this document. 925 8.4. Replay Protection 927 EAP-GPSK provides replay protection of its mutual authentication part 928 thanks to the use of random numbers RAND_S and RAND_P. Since RAND_S 929 is 128 bit long, one expects to have to record 2**64 (i.e., 930 approximately 1.84*10**19) EAP-GPSK successful authentication before 931 an protocol run can be replayed. Hence, EAP-GPSK provides replay 932 protection of its mutual authentication part as long as RAND_S and 933 RAND_P are chosen at random, randomness is critical for security. 935 8.5. Reflection attacks 937 EAP-GPSK provides protection against reflection attacks in case of an 938 extended authentication because of the messages are constructed in a 939 different fashion. 941 8.6. Dictionary Attacks 943 EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based 944 on at least 128 bits of entropy to guarantee security against 945 dictionary attacks. Users who use passwords or weak keys are not 946 guaranteed security against dictionary attacks. Derivation of the 947 long-term shared secret from a password is highly discouraged. 949 8.7. Key Derivation 951 EAP-GPSK supports key derivation as shown in Section 4. 953 8.8. Denial of Service Resistance 955 Denial of Service resistance (DoS) has not been a design goal for 956 EAP-GPSK. 958 It is however believed that EAP-GPSK does not provide any obvious and 959 avoidable venue for such attacks. 961 It is worth noting that the server has to maintain some state when it 962 engages in an EAP-GPSK conversation, namely to generate and to 963 remember the 16-byte RAND_S. This should however not lead to resource 964 exhaustion as this state and the associated computation are fairly 965 lightweight. 967 It is recommended that EAP-GPSK does not allow EAP notifications to 968 be interleaved in its dialog to prevent potential DoS attacks. 969 Indeed, since EAP Notifications are not integrity protected, they can 970 easily be spoofed by an attacker. Such an attacker could force a 971 peer that allows EAP Notifications to engage in a discussion which 972 would delay his authentication or result in the peer taking 973 unexpected actions (e.g., in case a notification is used to prompt 974 the peer to do some "bad" action). 976 It is up to the implementation of EAP-GPSK or to the peer and the 977 server to specify the maximum number of failed cryptographic checks 978 that are allowed. 980 8.9. Session Independence 982 Thanks to its key derivation mechanisms, EAP-GPSK provides session 983 independence: passive attacks (such as capture of the EAP 984 conversation) or active attacks (including compromise of the MSK or 985 EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. 986 The assumption that RAND_P and RAND_S are random is central for the 987 security of EAP-GPSK in general and session independance in 988 particular. 990 8.10. Exposition of the PSK 992 EAP-GPSK does not provide perfect forward secrecy. Compromise of the 993 PSK leads to compromise of recorded past sessions. 995 Compromise of the PSK enables the attacker to impersonate the peer 996 and the server and it allows the adversary to compromise future 997 sessions. 999 EAP-GPSK provides no protection against a legitimate peer sharing its 1000 PSK with a third party. Such protection may be provided by 1001 appropriate repositories for the PSK, which choice is outside the 1002 scope of this document. The PSK used by EAP-GPSK must only be shared 1003 between two parties: the peer and the server. In particular, this 1004 PSK must not be shared by a group of peers communicating with the 1005 same server. 1007 The PSK used by EAP-GPSK must be cryptographically separated from 1008 keys used by other protocols, otherwise the security of EAP-GPSK may 1009 be compromised. 1011 8.11. Fragmentation 1013 EAP-GPSK does not support fragmentation and reassembly since the 1014 message size is kept small. 1016 8.12. Channel Binding 1018 This document enables the ability to exchange channel binding 1019 information. It does not, however, define the encoding of channel 1020 binding information in the document. 1022 8.13. Fast Reconnect 1024 EAP-GPSK does not provide the fast reconnect capability since this 1025 method is already at the lower limit of the number of roundtrips and 1026 the cryptographic operations. 1028 8.14. Identity Protection 1030 Identity protection is not specified in this document. Extensions 1031 can be defined that enhanced this protocol to provide this feature. 1033 8.15. Protected Ciphersuite Negotiation 1035 EAP-GPSK provides protected ciphersuite negotiation via the 1036 indication of available ciphersuites by the server in the first 1037 message and a confirmation by the client in the subsequent message. 1039 8.16. Confidentiality 1041 Although EAP-GPSK provides confidentiality in its protected data 1042 payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748]. 1044 8.17. Cryptographic Binding 1046 Since EAP-GPSK does not tunnel another EAP method, it does not 1047 implement cryptographic binding. 1049 9. IANA Considerations 1051 This document requires IANA to allocate a new EAP Type for EAP-GPSK. 1053 This document requires IANA to create a new registry for ciphersuites 1054 and protected data types. IANA is furthermore instructed to add the 1055 specified ciphersuites and protected data types to this registry as 1056 defined in this document. Values can be added or modified with 1057 informational RFCs defining either block-based or hash-based 1058 ciphersuites. Each ciphersuite needs to provide processing rules and 1059 needs to specify how the following algorithms are instantiated: 1060 Encryption, Integrity and Key Derivation. Additionally, the 1061 preferred key size needs to be specified. 1063 The following layout represents the initial ciphersuite CSuite/ 1064 Specifier registry setup: 1066 o 0x000000 : Reserved 1067 o 0x000001 : AES-EAX-128, AES-CMAC-128, GKDF-128 1068 o 0x000002 : NULL, HMAC-SHA256, GKDF-256 1069 o 0x000003 through 0xFFFFFF : Unallocated 1071 The following is the initial protected data PData/Specifier registry 1072 setup: 1074 o 0x000000 : Reserved 1075 o 0x000001 : Channel Binding Data 1076 o 0x000002 : Protected Results Indication 1077 o 0x000003 : Extra KDF Data 1078 o 0x000004 through 0xFFFFFF : Unallocated 1080 10. Contributors 1082 This work is a joint effort of the EAP Method Update (EMU) design 1083 team of the EMU Working Group that was created to develop a mechanism 1084 based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 1085 4017 [RFC4017] requirements. The contributors (in alphabetical 1086 order) include: 1087 o Jari Arkko 1088 o Mohamad Badra 1089 o Uri Blumenthal 1090 o T. Charles Clancy 1091 o Lakshminath Dondeti 1092 o David McGrew 1093 o Joe Salowey 1094 o Sharma Suman 1095 o Hannes Tschofenig 1096 o Jesse Walker 1097 Finally, we would like to thank Thomas Otto for this review, feedback 1098 and text input. 1100 11. Acknowledgment 1102 We would like to thank Jouni Malinen and Bernard Aboba for their 1103 comments in June 2006. 1105 12. Open Issues 1107 The list of open issues can be found at: 1108 http://www.tschofenig.com:8080/eap-gpsk/ 1110 A first prototype implementation by Jouni Malinen can be found at: 1111 http://hostap.epitest.fi/releases/snapshots/ 1113 13. References 1115 13.1. Normative References 1117 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1118 Requirement Levels", March 1997. 1120 [RFC2486bis] 1121 Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1122 Network Access Identifier", 1123 draft-ietf-radext-rfc2486bis-06 (work in progress), 1124 July 2005. 1126 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1127 (SHA1)", RFC 3174, September 2001. 1129 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1131 Levkowetz, "Extensible Authentication Protocol (EAP)", 1132 RFC 3748, June 2004. 1134 13.2. Informative References 1136 [I-D.clancy-eap-pax] 1137 Clancy, C. and W. Arbaugh, "EAP Password Authenticated 1138 Exchange", draft-clancy-eap-pax-07 (work in progress), 1139 June 2006. 1141 [I-D.bersani-eap-psk] 1142 Tschofenig, H. and F. Bersani, "The EAP-PSK Protocol: a 1143 Pre-Shared Key EAP Method", draft-bersani-eap-psk-11 (work 1144 in progress), June 2006. 1146 [I-D.otto-emu-eap-tls-psk] 1147 Otto, T. and H. Tschofenig, "The EAP-TLS-PSK 1148 Authentication Protocol", draft-otto-emu-eap-tls-psk-00 1149 (work in progress), April 2006. 1151 [I-D.vanderveen-eap-sake] 1152 Vanderveen, M. and H. Soliman, "Extensible Authentication 1153 Protocol Method for Shared-secret Authentication and Key 1154 Establishment (EAP-SAKE)", draft-vanderveen-eap-sake-02 1155 (work in progress), May 2006. 1157 [I-D.ietf-eap-keying] 1158 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1159 Management Framework", draft-ietf-eap-keying-13 (work in 1160 progress), May 2006. 1162 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1163 Authentication Protocol (EAP) Method Requirements for 1164 Wireless LANs", RFC 4017, March 2005. 1166 [CMAC] National Institute of Standards and Technology, 1167 "Recommendation for Block Cipher Modes of Operation: The 1168 CMAC Mode for Authentication", Special Publication 1169 (SP) 800-38B, May 2005. 1171 Authors' Addresses 1173 T. Charles Clancy 1174 DoD Laboratory for Telecommunication Sciences 1175 8080 Greenmeade Drive 1176 College Park, MD 20740 1177 USA 1179 Email: clancy@ltsnet.net 1181 Hannes Tschofenig 1182 Siemens 1183 Otto-Hahn-Ring 6 1184 Munich, Bavaria 81739 1185 Germany 1187 Email: Hannes.Tschofenig@siemens.com 1188 URI: http://www.tschofenig.com 1190 Intellectual Property Statement 1192 The IETF takes no position regarding the validity or scope of any 1193 Intellectual Property Rights or other rights that might be claimed to 1194 pertain to the implementation or use of the technology described in 1195 this document or the extent to which any license under such rights 1196 might or might not be available; nor does it represent that it has 1197 made any independent effort to identify any such rights. Information 1198 on the procedures with respect to rights in RFC documents can be 1199 found in BCP 78 and BCP 79. 1201 Copies of IPR disclosures made to the IETF Secretariat and any 1202 assurances of licenses to be made available, or the result of an 1203 attempt made to obtain a general license or permission for the use of 1204 such proprietary rights by implementers or users of this 1205 specification can be obtained from the IETF on-line IPR repository at 1206 http://www.ietf.org/ipr. 1208 The IETF invites any interested party to bring to its attention any 1209 copyrights, patents or patent applications, or other proprietary 1210 rights that may cover technology that may be required to implement 1211 this standard. Please address the information to the IETF at 1212 ietf-ipr@ietf.org. 1214 Disclaimer of Validity 1216 This document and the information contained herein are provided on an 1217 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1218 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1219 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1220 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1221 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1222 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1224 Copyright Statement 1226 Copyright (C) The Internet Society (2006). This document is subject 1227 to the rights, licenses and restrictions contained in BCP 78, and 1228 except as set forth therein, the authors retain all their rights. 1230 Acknowledgment 1232 Funding for the RFC Editor function is currently provided by the 1233 Internet Society.