idnits 2.17.1 draft-aboba-pppext-key-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 598 has weird spacing: '...imed to perta...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (4 November 2001) is 8210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 421, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 423, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 426, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 429, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 432, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 435, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 444, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 447, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 450, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 454, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 457, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 470, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 473, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 479, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 482, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 491, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 495, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 498, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 501, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 504, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 507, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 511, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 517, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 520, but no explicit reference was found in the text == Unused Reference: '43' is defined on line 554, but no explicit reference was found in the text == Unused Reference: '44' is defined on line 558, but no explicit reference was found in the text == Unused Reference: '45' is defined on line 561, but no explicit reference was found in the text == Unused Reference: '46' is defined on line 564, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1334 (ref. '4') (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 2284 (ref. '9') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2434 (ref. '22') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2716 (ref. '32') (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2246 (ref. '33') (Obsoleted by RFC 4346) == Outdated reference: A later version (-07) exists of draft-ietf-ipsra-pic-03 == Outdated reference: A later version (-12) exists of draft-aboba-pppext-eapgss-08 == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-00 Summary: 10 errors (**), 0 flaws (~~), 37 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group Bernard Aboba 3 INTERNET-DRAFT Dan Simon 4 Category: Informational Microsoft 5 6 4 November 2001 8 The EAP Session Key Problem 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet- Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 This document makes the case for standardizing the algorithms used to 37 derive authentication and encryption transient session keys from the 38 master keying material derived by EAP methods. As EAP methods 39 proliferate, allowing each EAP method to define its own ciphersuite- 40 specific key derivation algorithms will compromise the security and 41 generality that EAP was intended to provide. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Requirements language ........................... 3 47 1.2 Terminology ..................................... 3 48 1.3 EAP overview .................................... 3 49 1.4 Problem overview ................................ 4 50 2. Proposed architecture ................................ 6 51 2.1 Solution requirements ........................... 8 52 3. Security considerations ............................... 10 53 4. References ............................................ 10 54 Acknowledgments .............................................. 13 55 Author's Addresses ........................................... 14 56 Intellectual Property Statement .............................. 14 57 Full Copyright Statement ..................................... 14 58 1. Introduction 60 1.1. Requirements language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in BCP 14 [18]. 66 1.2. Terminology 68 This document frequently uses the following terms: 70 Authentication Server 71 An Authentication Server is an entity that provides an 72 Authentication Service to an NAS. This service verifies from 73 the credentials provided by the peer, the claim of identity 74 made by the peer. 76 Master key 77 The session key derived between the EAP client and EAP server 78 during the EAP authentication process. 80 Master session key 81 The keys derived from the master key that are subsequently 82 used in generation of the transient session keys for 83 authentication, encryption, and IV-generation. So that the 84 master session keys are to be usable with any ciphersuite, 85 they are longer than is necessary, and are truncated to fit. 87 Transient session keys 88 The chosen ciphersuites uses transient session keys for 89 authentication and encryption as well as IVs (if required). 90 The transient session keys are derived from the master session 91 keys, and are of the appropriate size for use with the chosen 92 ciphersuite. 94 1.3. EAP overview 96 The Extensible Authentication Protocol (EAP), defined in RFC 2284 [9], 97 was developed to provide extensible authentication for use with PPP [1]. 98 Since then, new applications of EAP have emerged, including IEEE 802.1X 99 network port authentication, defined in [21], and provisioning of 100 certificates based of legacy authentication methods via PIC, defined in 101 [38]. 103 EAP was developed in part to enable deployment of new authentication 104 methods without requiring deployment of new code on the NAS. As a 105 result, the NAS acts as a "passthrough", and does not need to understand 106 specific EAP methods. Among other things, this implies that a NAS cannot 107 be assumed to contain code specific to any EAP method. 109 Instead of requiring new code to be installed on the NAS in order to 110 support a new EAP method, EAP method support is added to the client and 111 backend authentication server. EAP method support is typically provided 112 via an EAP API, such as that described in [42]. In order to allow the 113 client and backend server to install new EAP methods without requiring 114 an operating system upgrade, operating systems isolate EAP method- 115 specific code within the installed EAP methods, and thus also operate as 116 "passthrough" entities with respect to EAP. 118 Since the client and NAS will need to contain code to implement any 119 particular ciphersuite, it is reasonable to assume that ciphersuite- 120 specific code exists on these entities. However, just as the NAS should 121 not need to be updated to support a new EAP method, the backend 122 authentication server should not need to be updated to support a new 123 ciphersuite on the NAS. Since the backend authentication server is not 124 involved in the protection of data traffic, there is no intrinsic reason 125 that it should need to implement ciphersuite-specific code. 127 These restrictions, when put together, imply that including ciphersuite- 128 specific code within an EAP method is inappropriate, as is including 129 code specific to an EAP-method within the NAS. Moreover, since operating 130 systems provide EAP APIs in order to remain "EAP-Method Agnostic", EAP 131 method-specific code is best kept out of the EAP APIs as well. 133 1.4. Problem overview 135 RFC 2284 defined the EAP-MD5, as well as One-Time Password (OTP) and 136 Generic Token Card methods. Since then, the development of additional 137 EAP methods has accelerated. These include EAP-TLS [32], EAP-SRP [37], 138 EAP-GSS [39] and EAP-AKA [40]. Each of these methods is capable of 139 deriving keys, as well as providing for mutual authentication. 141 The ciphersuites for which EAP may provide keying material have also 142 grown in number. Within PPP, ciphersuites include DESEbis [16], 3DES 143 [17], and MPPE [36]. For PPP DESEbis, a 56-bit encryption key is 144 required in each direction; for PPP 3DES, a 168-bit encryption key is 145 needed in each direction; for MPPE, 40-bit, 56-bit or 128-bit encryption 146 keys can be required in each direction, as described in [35],[36]. 147 While these PPP ciphersuites provide encryption, they do not provide a 148 per-packet keyed message integrity check (MIC). 150 Within 802.11, ciphersuites include WEP-40, described in [24], which 151 requires a 40-bit encryption key, which is the same in either direction; 152 and WEP-128, which requires a 104-bit encryption key, the same in either 153 direction. These ciphersuites also do not include a keyed MIC. 155 Recently, new ciphersuites have been proposed for use with 802.11 that 156 do provide per-packet authentication as well as encryption. These 157 methods, described in [41], require 128-bit authentication and 158 encryption keys in each direction, and are based on AES [43]-[46]. 160 With the increase in the number of EAP methods and applicable 161 ciphersuites, there is a growing need for supplying algorithms to derive 162 transient session keys from master keys produced by EAP methods. To 163 date, this need has been filled on a piece-meal basis, with EAP methods 164 such as EAP SRP [37], defining transient session key derivation 165 mechanisms for each ciphersuite. 167 There are significant drawbacks to allowing each EAP method to specify 168 session key derivation mechanisms for individual ciphersuites. These 169 include: 171 Document Revision 172 If an EAP method specifies how to derive transient 173 session keys on a per-ciphersuite basis, then this 174 document will need to be revised each time a new 175 ciphersuite comes out. This would also imply that an 176 authentication server supporting an EAP method might not 177 be usable with a NAS supporting EAP, due to lack of 178 support for a ciphersuite implemented on the NAS. This is 179 antithetical to the EAP architecture, which conceives of 180 the NAS as a "pass through" device that does not need to 181 understand EAP, and which therefore can work with any EAP 182 method supported by the authentication server. 184 EAP method complexity 185 Forcing the EAP method to include ciphersuite-specific 186 code for transient session key derivation increases the 187 complexity of EAP method development, as well as client 188 and authentication server implementations. 190 Knowledge assymmetry 191 In practice, an EAP method may not have knowledge of the 192 ciphersuite that has been negotiated. In PPP, negotiation 193 of the ciphersuite is accomplished via the Encryption 194 Control Protocol (ECP), described in [10]. Since ECP 195 negotiation occurs after authentication, unless an EAP 196 method is utilized that supports ciphersuite negotiation 197 (such as EAP-TLS [32]), the client, NAS and backend 198 authentication server may not be able to anticipate the 199 ciphersuite that will be used and therefore this 200 information cannot be provided to the EAP method. 202 Similarly, it is also desirable to avoid proliferation of EAP method- 203 specific master session key derivation algorithms. Aside from the 204 duplication of effort this would imply, the deployment of many 205 algorithms, as opposed to a single well-analyzed one, is more likely to 206 create security vulnerabilities. 208 2. Proposed architecture 210 This document proposes an architecture that avoids the proliferation of 211 EAP method-specific master session key algorithms, as well as 212 ciphersuite-specific transient session key algorithms. 214 In the most general case, authentication and encryption keys as well as 215 initialization vectors must be derived for each direction from the 216 master key K derived by the EAP method. This is accomplished by the 217 adoption of two standard algorithms: 219 [1] An algorithm for the derivation of "master session keys" from the 220 negotiated master key. The "master session keys" are derived from 221 the master key derived by the EAP method, but are never directly 222 used by ciphersuites; they are only used in the derivation of 223 transient session keys. These "master session keys" are derived on 224 the client and the backend authentication server. The backend 225 authentication server then transmits the "master session keys" to 226 the NAS. 228 [2] An algorithm for the derivation of "transient session keys" from 229 the "master session keys". The "transient session keys" are used 230 for encryption, authentication and IV-generation in each direction, 231 and are derived by the NAS and client, based on the negotiated 232 ciphersuite. 234 Depending on the negotiated ciphersuite, not all of the "transient 235 session keys" will be required; for example 802.11 WEP does not provide 236 a keyed message integrity check, and typically uses only a single 237 encryption key in both directions. 239 The algorithm for deriving the "master session keys" from the "master 240 key" is designed to be ciphersuite-independent, and to apply across a 241 wide range of EAP methods. This enables the security community to 242 carefully analyze the proposed algorithm. Such an analysis would be 243 difficult were multiple algorithms to proliferate. 245 The specification of a universal algorithm for master session key 246 derivation also enables development of libraries that can be called by 247 EAP method developers, who otherwise would have to code algorithms 248 independently within each EAP method. This also avoids having to upgrade 249 AAA servers and EAP methods every time a new ciphersuite is developed, 250 By standardizing the master session key derivation within EAP methods 251 and on the AAA server, the NAS can be assured of obtaining master 252 session keys in a well-defined format. Since it is assumed that the 253 backend authentication server will perform the required calculations and 254 will supply the NAS with the master session keys, the algorithm need not 255 be implemented on the NAS. 257 Rather, the NAS will only need code for the second algorithm, namely for 258 the derivation of ciphersuite-specific "transient session keys" from 259 "master session keys". Although the NAS needs to be upgraded to support 260 additional ciphersuites, it is best if the code for generation of 261 "transient session keys" from "master session keys" is as ciphersuite- 262 independent as possible, so as to avoid requiring constant maintenance 263 of the algorithm. 265 The derivation of ciphersuite-specific "transient session keys" from 266 "master session keys" occurs after the ciphersuite has been determined, 267 and provides for authentication and encryption keys as well as IV- 268 generation. Within the proposed architecture, this conversion is also 269 carried out according to a standardized algorithm. 271 The algorithm for deriving "transient session keys" from the "master 272 session keys" is designed to be EAP-method independent, and to apply 273 across a wide range of ciphersuites. This enables its security also to 274 be thoroughly analyzed and for the code to be reused within the NAS 275 where it is expected to reside. 277 Note that the master key may not be directly available within all EAP 278 methods. For security reasons, the TLS master key is typically not 279 directly available via TLS APIs. As a result, RFC 2716 [32] derives 280 master session keys from the TLS master key, and uses those master 281 session keys to derive the required session keys. Since RFC 2716 does 282 not assume knowledge of the negotiated ciphersuite, it provides keys 283 large enough for use with any ciphersuite, assuming that these will be 284 truncated for use within the client and NAS. Since the raw master key 285 is typically not available in to EAP-TLS implementations, when this EAP 286 method is used, the TLS PRF function is needed to derive keying material 287 from it. 289 Other EAP methods may also encounter similar issues. For example, EAP 290 GSS implementations will typically not be able to access the master keys 291 directly, but can call GSS_Wrap() to encrypted tokens and GSS_GetMIC() 292 to generate authentication tokens based on the master key. EAP GSS 293 implementations will therefore need to use GSS-API calls to derive 294 master session keys from the master key, rather than operating on the 295 master key directly. 297 While method-specific algorithms may be required in some methods, for 298 other methods, the master key is directly available, and so the 299 algorithm used to derive master sesion keys from it can be designed in 300 complete freedom. However, even where such freedom is available, the 301 proliferation of EAP method-specific key derivation algorithms is 302 undesirable. 304 Figure 1 on the next page describes the overall logic of how master 305 session keys and transient session keys are derived from the master key 306 negotiated with an EAP method. 308 The master key K may be of varying length, and as described earlier, may 309 not be directly available to the EAP method. Where the master key K is 310 not exportable, an intermediate step is required to generate a "Pseudo- 311 Master Key" from the master key. For example, in EAP GSS, as described 312 in [39], a "Pseudo-Master Key", K' is derived via GSS-API calls, and is 313 used instead. 315 2.1. Solution requirements 317 The algorithms for derivation of "master session keys" from the master 318 key, and for derivation of "transient session keys" from the "master 319 session keys" are not specified in this document. Rather, the purpose of 320 this document is to lay out a framework within which algorithms can be 321 discussed and evaluated. 323 For a proposed "master session key" derivation algorithm to be 324 satisfactory, it needs to fulfill several requirements: 326 Ciphersuite-independence 327 A satisfactory "master session key" derivation algorithm MUST 328 NOT require ciphersuite-specific code to be implemented within 329 an EAP method. In practice, this implies that the master 330 session keys need to enable derivation of authentication and 331 encryption keys and IVs in both directions. 333 Generality 334 A satisfactory "master session key" derivation algorithm MUST 335 provide master session keys appropriate for use with a wide 336 range of ciphersuites. Among other things, this implies that 337 the master session keys must contain sufficient entropy to be 338 usable with existing and future ciphersuites. 340 Direct and Indirect Access 341 A satisfactory "master session key" derivation algorithm MUST 342 be applicable to EAP methods where the master key is not 343 directly accessible. These include TLS and GSS-API methods. 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | | | 347 | Is raw master key | | Can a pseudo-master key | 348 | available or can | | be derived from | 349 | the PRF operate on it? | | the master key? | 350 | | | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 | K | K' 354 | | 355 V V 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 | Master Session Key | 359 | Derivation | 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 | Master Session Key Outputs | 364 | | 365 V V 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 | Key and IV Derivation | 369 | Derivation | 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | P->A | A->P | P->A | A->P | P->A | A->P 373 | Enc. | Enc. | Auth. | Auth. | IV | IV 374 | Key | Key | Key | Key | | 375 | | | | | | 376 | | | | | | 377 V V V V V V 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 | Ciphersuite-Specific Truncation & | 381 | Key utilization | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 1 - Architecture for derivation of session keys from the 386 EAP method master key K. 388 The algorithm for "transient session key" derivation also needs to 389 fulfill several requirements: 391 EAP method independence 392 The algorithm for deriving "transient session keys" from 393 "master session keys" MUST NOT depend on the EAP method. 394 Derivation of "transient session keys" is expected to occur on 395 the NAS, which acts as a "passthrough" for EAP. Therefore the 396 NAS cannot be expected to have knowledge of the EAP method 397 that has been negotiated. 399 Generality 400 The algorithm for derivation of "transient session keys" from 401 "master session keys" MUST be suitable for use with a wide 402 range of ciphersuites. In practice, this means that the 403 algorithm must be usable with existing and future 404 ciphersuites. 406 3. Security considerations 408 The strength of the session keys is dependent upon the security of the 409 EAP method providing the master keying material. If the chosen EAP 410 method has security vulnerabilities, then it is possible that weak 411 session keys may be produced. 413 4. References 415 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 416 RFC 1661, July 1994. 418 [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, 419 "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. 421 [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994. 423 [4] Lloyd, B., Simpson, W., "PPP Authentication Protocols," RFC 1334, 424 October 1992. 426 [5] Simpson, W., "PPP Challenge Handshake Authentication Protocol 427 (CHAP)," RFC 1994, August 1996. 429 [6] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions," RFC 2433, 430 October 1998. 432 [7] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2," RFC 2759, 433 January 2000. 435 [8] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 436 1321, April 1992. 438 [9] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 439 (EAP)", RFC 2284, March 1998. 441 [10] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 442 1996. 444 [11] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 445 46 (January 1977). 447 [12] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 448 (December 1980). 450 [13] National Institute of Standards and Technology (NIST), "Announcing 451 the Secure Hash Standard," FIPS 180-1, U.S. Department of 452 Commerce, 04/1995 454 [14] Daemen, Joan and Vincent Rijmen, "AES Proposal: Rijndael", 455 September 1999, . 457 [15] National Institute of Standards and Technology, "Rijndael: NIST's 458 Selection for the AES", December 2000, 459 . 461 [16] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2 462 (DESE-bis)", RFC 2419, September 1998. 464 [17] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 465 2420, September 1998. 467 [18] Bradner, S., "Key words for use in RFCs to Indicate Requirement 468 Levels", BCP 14, RFC 2119, March 1997. 470 [19] D. Rand. "The PPP Compression Control Protocol", RFC 1962, Novell, 471 June 1996. 473 [20] IEEE Standards for Local and Metropolitan Area Networks: Overview 474 and Architecture, ANSI/IEEE Std 802, 1990. 476 [21] IEEE Standards for Local and Metropolitan Area Networks: Port based 477 Network Access Control, IEEE Std 802.1X-2001, June 2001. 479 [22] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 480 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 482 [23] Dobbertin, H., "The Status of MD5 After a Recent Attack." 483 CryptoBytes Vol.2 No.2, Summer 1996. 485 [24] Information technology - Telecommunications and information 486 exchange between systems - Local and metropolitan area networks - 487 Specific Requirements Part 11: Wireless LAN Medium Access Control 488 (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 489 802.11-1997, 1997. 491 [25] Wu, T., "The Secure Remote Password Protocol", in Proceedings of 492 the 1998 Internet Society Symposium on Network and Distributed 493 Systems Security, San Diego, CA, pp. 97-111 495 [26] Wu, T., "The Secure Remote Password Protocol", March 1998, 496 . 498 [27] Wu, T., "The SRP Authentication and Key Exchange System," RFC 2945, 499 September 2000. 501 [28] Wu, T., "SRP: The Open Source Password Authentication Standard", 502 March 1998, . 504 [29] Hopwood, D., "Standard Cryptographic Algorithm Naming", June 2000, 505 . 507 [30] Menezes, A.J., van Oorschot, P.C. and S.A. Vanstone, "Handbook of 508 Applied Cryptography", CRC Press, Inc., ISBN 0-8493-8523-7, 1997, 509 . 511 [31] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 512 Authentication", RFC 2104, February 1997. 514 [32] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 515 2716, October 1999. 517 [33] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 2246, 518 November 1998. 520 [34] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, 521 November 1998. 523 [35] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point 524 Encryption (MPPE)," RFC 3079, March 2001. 526 [36] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption (MPPE) 527 RFC 3078, March 2001. 529 [37] Carlson, J., Aboba, B., Haverinen, H., "PPP EAP SRP-SHA1 530 Authentication Protocol", Internet-draft (work in progress), draft- 531 ietf-pppext-eap-srp-03.txt, July 2001. 533 [38] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE Credential 534 Provisioning Protocol", Internet draft (work in progress), draft- 535 ietf-ipsra-pic-03.txt, July 2001. 537 [39] Aboba, B., "EAP GSS Authentication Protocol", Internet draft (work 538 in progress), draft-aboba-pppext-eapgss-08.txt, October 2001. 540 [40] Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet draft 541 (work in progress), draft-arkko-pppext-eap-aka-00.txt, December 542 2001. 544 [41] IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR 545 Telecommunications and Information Exchange between Systems - 546 LAN/MAN Specific Requirements - Part 11: Wireless Medium Access 547 Control (MAC) and physical layer (PHY) specifications: 548 Specification for Enhanced Security", July 2001. 550 [42] Microsoft Developer Network, "Windows 2000 EAP API", August 2000, 551 http://msdn.microsoft.com/library/default.asp?url=/library/en- 552 us/eap/eapport_0fj9.asp 554 [43] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES 555 Proposal, June 1998. http://csrc.nist.gov/encryption/aes/round2/ 556 AESAlgs/Rijndael/Rijndael.pdf 558 [44] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)", 559 U.S. DoC/NIST, summer 2001. 561 [45] "Symmetric Key Block Cipher Modes of Operation," 562 http://www.nist.gov/modes. 564 [46] "Recommendation for Block Cipher Modes of Operation", National 565 Institute of Standards and Technology (NIST) Special Publication 566 800-XX, CODEN: NSPUE2, U.S. Government Printing Office, Washington, 567 DC, July 2001. 569 Acknowledgments 571 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft for 572 useful feedback. 574 Author Addresses 576 Bernard Aboba 577 Microsoft Corporation 578 One Microsoft Way 579 Redmond, WA 98052 581 EMail: bernarda@microsoft.com 582 Phone: +1 425 706 6605 583 Fax: +1 425 706 7329 585 Dan Simon 586 Microsoft Research 587 Microsoft Corporation 588 One Microsoft Way 589 Redmond, WA 98052 591 EMail: dansimon@microsoft.com 592 Phone: +1 425 706 6711 593 Fax: +1 425 706 7329 595 Intellectual Property Statement 597 The IETF takes no position regarding the validity or scope of any 598 intellectual property or other rights that might be claimed to pertain 599 to the implementation or use of the technology described in this 600 document or the extent to which any license under such rights might or 601 might not be available; neither does it represent that it has made any 602 effort to identify any such rights. Information on the IETF's 603 procedures with respect to rights in standards-track and standards- 604 related documentation can be found in BCP-11. Copies of claims of 605 rights made available for publication and any assurances of licenses to 606 be made available, or the result of an attempt made to obtain a general 607 license or permission for the use of such proprietary rights by 608 implementors or users of this specification can be obtained from the 609 IETF Secretariat. 611 The IETF invites any interested party to bring to its attention any 612 copyrights, patents or patent applications, or other proprietary rights 613 which may cover technology that may be required to practice this 614 standard. Please address the information to the IETF Executive 615 Director. 617 Full Copyright Statement 619 Copyright (C) The Internet Society (2001). All Rights Reserved. 620 This document and translations of it may be copied and furnished to 621 others, and derivative works that comment on or otherwise explain it or 622 assist in its implmentation may be prepared, copied, published and 623 distributed, in whole or in part, without restriction of any kind, 624 provided that the above copyright notice and this paragraph are included 625 on all such copies and derivative works. However, this document itself 626 may not be modified in any way, such as by removing the copyright notice 627 or references to the Internet Society or other Internet organizations, 628 except as needed for the purpose of developing Internet standards in 629 which case the procedures for copyrights defined inthe Internet 630 Standards process must be followed, or as required to translate it into 631 languages other than English. The limited permissions granted above are 632 perpetual and will not be revoked by the Internet Society or its 633 successors or assigns. This document and the information contained 634 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 635 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 636 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 637 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 638 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 640 Expiration Date 642 This memo is filed as , and 643 expires May 22, 2002.