idnits 2.17.1 draft-aboba-pppext-key-problem-01.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 15 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 16 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.) ** There are 39 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 619 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 (13 February 2002) is 8098 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 276 -- Looks like a reference, but probably isn't: '2' on line 285 == Missing Reference: 'RFC2548' is mentioned on line 307, but not defined == Unused Reference: 'RFC2434' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 567, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-12) exists of draft-aboba-pppext-eapgss-11 == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-01 == Outdated reference: A later version (-07) exists of draft-ietf-ipsra-pic-05 Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 6 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 13 February 2002 8 The EAP Keying 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 RFC 2026. 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 (2002). All Rights Reserved. 34 Abstract 36 This document describes the issues involved in key derivation by EAP 37 methods and provides guidelines for generation and usage of EAP keys. 39 Table of Contents 41 1. Introduction .......................................... 3 42 1.1 Requirements language ........................... 3 43 1.2 Terminology ..................................... 4 44 2. EAP architecture overview ............................. 4 45 2.1 Implications of the architecture ................ 7 46 3. EAP Keying Requirements ............................... 8 47 4. Security considerations ............................... 12 48 5. Normative references .................................. 13 49 6. Informative references ................................ 13 50 Acknowledgments .............................................. 14 51 Author's Addresses ........................................... 15 52 Intellectual Property Statement .............................. 15 53 Full Copyright Statement ..................................... 15 54 1. Introduction 56 The Extensible Authentication Protocol (EAP), defined in [RFC2284], was 57 developed to provide extensible authentication for use with PPP 58 [RFC1661]. Since then, new applications of EAP have emerged, including 59 IEEE 802.1X network port authentication [IEEE8021X], and PIC [PIC]. 61 Although the initial focus of EAP was authentication, it can also 62 provide keys for use with a ciphersuite. EAP methods defined in 63 [RFC2284] include EAP MD5, as well as One-Time Password (OTP) and 64 Generic Token Card methods. Each of these methods supports one-way 65 authentication only but not key derivation. However, subsequent EAP 66 method specifications such as EAP TLS [RFC2716], EAP SRP [EAPSRP], EAP 67 GSS [EAPGSS] and EAP AKA [EAPAKA] have provided for mutual 68 authentication, as well as key derivation. 70 The ciphersuites for which EAP may provide keying material have also 71 grown in number. PPP ciphersuites include DESEbis [RFC2419], 3DES 72 [RFC2420], and MPPE [RFC3078]. The DES algorithm is described in 73 [FIPSDES], and DES modes (such as CBC, used in RFC 2419 and DES- 74 EDE3-CBC, used in RFC 2420) are described in [DESMODES]. For PPP 75 DESEbis, a single 56-bit encryption key is required, used in both 76 directions; for PPP 3DES, a 168-bit encryption key is needed, used in 77 both directions. As described in [RFC2419] and [RFC2420] for both 78 protocols, the IV, which is different in each direction, is "deduced 79 from an explicit 64-bit nonce, which is exchanged in the clear during 80 the negotiation phase." 82 For MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in 83 each direction, as described in [RFC3078]. Since MPPE is based on the 84 RC4 algorithm, no initialization vector is required. While these PPP 85 ciphersuites provide encryption, they do not provide a per-packet keyed 86 message integrity check (MIC). Thus, an authentication key is not 87 required in either direction. 89 Within 802.11, ciphersuites include WEP-40, described in [IEEE80211], 90 which requires a 40-bit encryption key, the same in either direction; 91 and WEP-128, which requires a 104-bit encryption key, the same in either 92 direction. These ciphersuites also do not include a keyed MIC. 94 Recently, new ciphersuites have been proposed for use with 802.11 that 95 do provide per-packet authentication as well as encryption 96 [IEEE80211Tgi]. These ciphersuites use either 104-bit or 128-bit keys. 98 With the increase in the number of EAP methods and applicable 99 ciphersuites, there is a need for defining how transient session keys 100 are derived from the master secrets produced by EAP methods. Allowing 101 each EAP method to handle this in its own way is likely to produce 102 unacceptable results. 104 This document reviews the issues involved in EAP key derivation and 105 provides guidelines for the generation of keys by EAP methods. 107 1.1. Requirements language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in BCP 14 [RFC2119]. 113 1.2. Terminology 115 This document frequently uses the following terms: 117 Authentication Server 118 An Authentication Server is an entity that provides an 119 Authentication Service to an NAS. This service verifies from 120 the credentials provided by the peer, the claim of identity 121 made by the peer. 123 Master key 124 The key derived between the EAP client and EAP server during 125 the EAP authentication process. 127 Master session key 128 Master session keys are derived from the master key, and are 129 subsequently used in generation of transient session keys for 130 authentication, encryption and IV-generation. Since the 131 transient session keys may be different in each direction, 132 master session keys are also required in each direction, and 133 are therefore referred to as "asymmetrical". So that the 134 master session keys are to be usable with any ciphersuite, 135 they are longer than is necessary, and are truncated to fit. 137 Transient session keys 138 The chosen ciphersuite uses transient session keys for 139 authentication and encryption as well as IVs (if required). 140 The transient session keys are derived from the master session 141 keys, and are of the appropriate size for use with the chosen 142 ciphersuite. Depending on the ciphersuite, the transient 143 session keys may be different in each direction. 145 2. EAP architecture overview 147 One of the goals of EAP is to enable development of new authentication 148 methods without requiring deployment of new code on the NAS. As a 149 result, the NAS acts as a "passthrough", and need not understand 150 specific EAP methods. Among other things, this implies that a NAS need 151 not contain code specific to each EAP method. EAP 153 Instead of requiring new code on the NAS, EAP methods are installed on 154 the client and backend authentication server, typically interfacing with 155 the operating system via an EAP API, such as that described in [EAPAPI]. 156 In order to allow the client and backend server to install new EAP 157 methods without requiring an operating system upgrade, operating systems 158 isolate EAP method-specific code within the installed EAP methods, and 159 thus largely operate as "passthrough" entities with respect to EAP. 161 Figure 1 describes the relationship between the EAP peer, NAS and AAA 162 server. As described in the figure, the EAP conversation "passes 163 through" the NAS on its way between the client and the AAA server As a 164 result, the NAS does not have knowledge of the keys that are derived 165 between the AAA server and the client, and these keys need to be 166 transmitted from the AAA server to the NAS. 168 EAP methods are installed on the the client and the AAA server, 169 typically communicating via an EAP API, so that the main client and AAA 170 server code does not need to be modified to add new methods. Among the 171 results that are passed back by EAP methods via the APIs are the keys to 172 be communicated from the AAA server to the NAS. Ciphersuites are 173 installed on the NAS and the client. 175 While EAP methods which derive keys can be used to provide automated 176 keying for a ciphersuite, this does not imply that the EAP method need 177 contain ciphersuite-specific code. Since the client and NAS need to 178 implement a given ciphersuite, ciphersuite-specific code is expected to 179 exist on the client and NAS. However, since the backend authentication 180 server is not involved in the protection of data traffic, and may not 181 even be aware of the negotiated ciphersuite, it cannot be assumed to 182 implement ciphersuite-specific code, and the backend authentication 183 server will not necessarily have knowledge of the ciphersuites available 184 on the NAS and client. 186 +-+-+-+-+-+ +-+-+-+-+-+ 187 | | | | 188 | | | | 189 | Cipher- | | Cipher- | 190 | Suite | | Suite | 191 | | | | 192 +-+-+-+-+-+ +-+-+-+-+-+ 193 ^ ^ 194 | | 195 | | 196 | | 197 V V 198 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 199 | | EAP | | | | 200 | | Conversation | | | | 201 | |<================================>| AAA | 202 | Client | | NAS | | Server | 203 | | | |<=======| | 204 | | | | Keys | | 205 | | | | | | 206 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 207 ^ ^ 208 | | 209 | EAP API | EAP API 210 | | 211 V V 212 +-+-+-+-+-+ +-+-+-+-+-+ 213 | | | | 214 | | | | 215 | EAP | | EAP | 216 | Method | | Method | 217 | | | | 218 +-+-+-+-+-+ +-+-+-+-+-+ 220 Figure 1 - Relationship between EAP client, AAA server and NAS. 222 2.1. Implications of the architecture 224 Since the backend authentication server may not have knowledge of the 225 ciphersuite that has been negotiated, it may not be possible for this 226 information to be passed to the EAP method via the EAP APIs. As a 227 result, inclusion of ciphersuite-specific code within an EAP method is 228 inappropriate. Similarly, because the NAS is assumed to not have 229 knowledge of individual EAP methods, it cannot be assumed to include 230 code specific to an EAP method. Moreover, since operating systems 231 provide EAP APIs in order to remain "EAP-Method Agnostic", EAP method- 232 specific code is best kept out of the EAP APIs as well. 234 Drawbacks to allowing EAP methods to specify session key derivation 235 mechanisms for individual ciphersuites include: 237 Document Revision 238 If an EAP method specifies how to derive transient 239 session keys on a per-ciphersuite basis, then this 240 document will need to be revised each time a new 241 ciphersuite comes out. This would also imply that an 242 authentication server supporting an EAP method might not 243 be usable with a NAS supporting EAP, due to lack of 244 support for a ciphersuite implemented on the NAS. This is 245 antithetical to the EAP architecture, which conceives of 246 the NAS as a "pass through" device that does not need to 247 understand EAP, and which therefore can work with any EAP 248 method supported by the authentication server. 250 EAP method complexity 251 Forcing the EAP method to include ciphersuite-specific 252 code for transient session key derivation increases the 253 complexity of EAP method development, as well as client 254 and authentication server implementations. 256 Knowledge asymmetry 257 In practice, an EAP method may not have knowledge of the 258 ciphersuite that has been negotiated. In PPP, negotiation 259 of the ciphersuite is accomplished via the Encryption 260 Control Protocol (ECP), described in [RFC1968]. Since 261 ECP negotiation occurs after authentication, unless an 262 EAP method is utilized that supports ciphersuite 263 negotiation (such as EAP-TLS [RFC2716]), the client, NAS 264 and backend authentication server may not be able to 265 anticipate the ciphersuite that will be used and 266 therefore this information cannot be provided to the EAP 267 method. 269 3. EAP keying requirements 271 In the most general case, authentication and encryption keys as well as 272 initialization vectors must be derived for each direction from the 273 master secret K derived by the EAP method. This can accomplished via 274 the specification of two classes of algorithms: 276 [1] Algorithms for the derivation of "master session keys" from the 277 negotiated master key. The "master session keys" are derived from 278 the master key derived by the EAP method, but are never directly 279 used by ciphersuites; they are only used in the derivation of 280 transient session keys. These "master session keys" are derived on 281 the client and the backend authentication server. The backend 282 authentication server then transmits the "master session keys" to 283 the NAS. 285 [2] Algorithms for the derivation of "transient session keys" from the 286 "master session keys". The "transient session keys" are used for 287 encryption, authentication and IV-generation in each direction, and 288 are derived by the NAS and client, based on the negotiated 289 ciphersuite. 291 Depending on the negotiated ciphersuite, not all of the "transient 292 session keys" will be required; for example 802.11 WEP does not provide 293 a keyed message integrity check, and typically uses only a single 294 encryption key in both directions. 296 The algorithm for deriving the "master session keys" from the "master 297 key" is designed to be ciphersuite-independent, and is specific to the 298 EAP method. The goal of this algorithm is to provide master session keys 299 in a well defined format, suitable for passage between the AAA server 300 and the NAS. 302 Examples of master session key derivation algorithms are provided in 303 Section 3.5 of EAP TLS [RFC2716], based on the Pseudo-Random Function 304 (PRF) defined in TLS [RFC2246]. Equivalent algorithms are provided in 305 IKE [RFC2409] for the derivation of SKEYID_d, SKEYID_a and SKEYID_e from 306 the master key SKEYID. Examples of AAA master session key attributes 307 are provided in [RFC2548]. 309 Note that because the derivation and validation of these algorithms is 310 difficult, it is highly desirable to reuse existing algorithms if at all 311 possible. This enables the security community to carefully analyze the 312 proposed algorithm. Such an analysis would be difficult were multiple 313 algorithms to proliferate. However, since each EAP method is different, 314 it is also true that existing algorithms may not fit all situations. 316 For example, the master key may not be directly available within all EAP 317 methods. For security reasons, the TLS master secret is typically not 318 directly available via TLS APIs. As a result, [RFC2716] derives master 319 session keys from the TLS master secret, and uses those master session 320 keys to derive the required session keys. Since EAP TLS [RFC2716] does 321 not assume knowledge of the negotiated ciphersuite, it provides keys 322 large enough for use with any ciphersuite, assuming that these will be 323 truncated for use within the client and NAS. Since the raw master 324 secret is typically not available in to EAP-TLS implementations, when 325 this EAP method is used, the TLS PRF function is needed to derive keying 326 material from it. 328 Other EAP methods may also encounter similar issues. For example, EAP 329 GSS implementations will typically not be able to access the master keys 330 directly, but can call GSS_Wrap() to encrypted tokens and GSS_GetMIC() 331 to generate authentication tokens based on the master secret. EAP GSS 332 implementations will therefore need to use GSS-API calls to derive 333 master session keys from the master key, rather than operating on the 334 master key directly. 336 By specifying the algorithm by which master session keys are derived 337 within each EAP method, as well as the format by which the master 338 session keys are transmitted from the AAA server to the NAS, the NAS can 339 be assured of obtaining master session keys for each EAP method, in a 340 well-defined format. Since it is assumed that the backend 341 authentication server will perform the required calculations and will 342 supply the NAS with the master session keys, the master session key 343 algorithm need not be implemented on the NAS. 345 Rather, the NAS will only need code for the second algorithm, namely for 346 the derivation of ciphersuite-specific "transient session keys" from 347 "master session keys". 349 The derivation of ciphersuite-specific "transient session keys" from 350 "master session keys" occurs after the ciphersuite has been determined, 351 and provides for authentication and encryption keys as well as IV- 352 generation. The algorithm for deriving "transient session keys" from 353 the "master session keys" is designed to be EAP-method independent. 354 Since each ciphersuite will have different needs, the algorithms for 355 transient session key derivation will vary from ciphersuite to 356 ciphersuite. Nevertheless, as with master session key derivation 357 algorithms, it is desirable if commonalities can be found, so that the 358 correctness and security of the algorithms can be more easily analyzed. 360 Figure 2 on the next page describes the overall logic of how master 361 session keys and transient session keys are derived from the master key 362 negotiated within an EAP method. 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- 365 | | | | ^ 366 | Is a raw master key | | Can a pseudo-master key | | 367 | available or can | | be derived from | | 368 | the PRF operate on it? | | the master key? | | 369 | | | | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 371 | | | 372 | K | K' | 373 | | | 374 V V | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 376 | | EAP | 377 | Master Session Key | Method | 378 | Derivation | | 379 | | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 381 | | | 382 | Master Session Key Outputs | | 383 | | | 384 V V | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 386 | | | 387 | Key and IV Derivation | | 388 | Derivation | | 389 | | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 391 | P->A | A->P | P->A | A->P | P->A | A->P EAP V 392 | Enc. | Enc. | Auth. | Auth. | IV | IV API ---+--- 393 | Key | Key | Key | Key | | ^ 394 | | | | | | AAA | 395 | | | | | | Keys V 396 V V V V V V ---+--- 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 398 | | | 399 | Ciphersuite-Specific Truncation & | NAS | 400 | Key utilization | | 401 | | V 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- 404 Figure 2 - Architecture for derivation of session keys from the 405 EAP method master key K. 407 The master key K may be of varying length, and as described earlier, may 408 not be directly available to the EAP method. Where the master key K is 409 not exportable, an intermediate step is required to generate a "Pseudo- 410 Master Key" from the master key. For example, in EAP GSS, as described 411 in [EAPGSS], a "Pseudo-Master Key", K' is derived via GSS-API calls, and 412 is used instead. 414 In order to enable interoperability between backend authentication 415 servers, NASen and EAP clients implementing EAP methods that derive 416 keys, the following is required: 418 Key hierarchy 419 In order to enable the keys derived within EAP methods to be used 420 within any ciphersuite, EAP methods deriving keys need to specify 421 the algorithms for master session key derivation. If possible, it 422 is desirable to reuse existing key derivation techniques, rather 423 than inventing new ones. 425 Ciphersuite keys 426 In order to use the master session keys provided by EAP methods, 427 ciphersuites keyed via EAP need to define how ciphersuite-specific 428 keys are derived from the master session keys provided by EAP 429 methods. 431 Keying AVPs 432 In order to enable backend authentication servers to provide keying 433 material to the NAS in a well defined format, it is necessary to 434 standardize the attributes uses to transmit keys from the backend 435 authentication server to the NAS. 437 The algorithms for derivation of "master session keys" from the master 438 key, and for derivation of "transient session keys" from the "master 439 session keys" are not specified in this document. Rather, the purpose of 440 this document is to lay out a framework within which algorithms can be 441 discussed and evaluated. 443 For a proposed "master session key" derivation algorithm to be 444 satisfactory, it needs to fulfill several requirements: 446 Ciphersuite-independence 447 A satisfactory "master session key" derivation algorithm MUST 448 NOT require ciphersuite-specific code to be implemented within 449 an EAP method. In practice, this implies that the master 450 session keys MUST enable derivation of authentication and 451 encryption keys and IVs in both directions. 453 Generality 454 A satisfactory "master session key" derivation algorithm MUST 455 provide master session keys appropriate for use with a wide 456 range of ciphersuites. Among other things, this implies that 457 the master session keys MUST contain sufficient entropy to be 458 usable with existing and future ciphersuites. At a minimum, 459 master session keys SHOULD be at least 256 octets in length. 461 Direct and Indirect Access 462 Satisfactory "master session key" derivation algorithm MUST be 463 applicable to EAP methods where the master key is not directly 464 accessible. These include TLS and GSS-API methods. 466 Generality 467 It is likely that each EAP method will handle the derivation 468 of "master session keys" from "master keys" in a different 469 manner. However, wherever possible, well known algorithms 470 SHOULD be reused, and customized to fit, rather than 471 developing entirely new algorithms. 473 Algorithms for "transient session key" derivation also needs to fulfill 474 several requirements: 476 EAP method independence 477 Algorithms for deriving "transient session keys" from "master 478 session keys" MUST NOT depend on the EAP method. Derivation 479 of "transient session keys" is expected to occur on the NAS, 480 which acts as a "passthrough" for EAP. Therefore the NAS 481 cannot be expected to have knowledge of the EAP method that 482 has been negotiated. 484 Generality 485 More than one algorithm(s) for derivation of "transient 486 session keys" from "master session keys" MAY be required, in 487 order to cover the full range of ciphersuites, but algorithms 488 SHOULD be reused where possible, so that they do not 489 proliferate unnecessarily. 491 4. Security considerations 493 The strength of the session keys is dependent upon the security of the 494 EAP method providing the master keying material. If the chosen EAP 495 method has security vulnerabilities, or does not produce a key of 496 sufficient entropy then it is possible that weak session keys may be 497 produced. 499 5. Normative References 501 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 502 51, RFC 1661, July 1994. 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 508 2246, November 1998. 510 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 511 Protocol (EAP)", RFC 2284, March 1998. 513 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 514 RFC 2409, November 1998. 516 [IEEE8021X] 517 IEEE Standards for Local and Metropolitan Area Networks: Port 518 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 520 6. Informative References 522 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 523 1996. 525 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 526 Version 2 (DESE-bis)", RFC 2419, September 1998. 528 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 529 RFC 2420, September 1998. 531 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 532 Considerations Section in RFCs", BCP 26, RFC 2434, October 533 1998. 535 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", 536 RFC 2716, October 1999. 538 [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption 539 (MPPE) RFC 3078, March 2001. 541 [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point 542 Encryption (MPPE)," RFC 3079, March 2001. 544 [EAPGSS] Aboba, B., "EAP GSS Authentication Protocol", Internet draft 545 (work in progress), draft-aboba-pppext-eapgss-11.txt, February 546 2002. 548 [EAPAKA] Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet 549 draft (work in progress), draft-arkko-pppext-eap-aka-01.txt, 550 November 2001. 552 [EAPSRP] Carlson, J., Aboba, B., Haverinen, H., "PPP EAP SRP-SHA1 553 Authentication Protocol", Internet-draft (work in progress), 554 draft-ietf-pppext-eap-srp-03.txt, July 2001. 556 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS 557 PUB 46 (January 1977). 559 [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE 560 Credential Provisioning Protocol", Internet draft (work in 561 progress), draft-ietf-ipsra-pic-05.txt, February 2002. 563 [DESMODES] 564 National Bureau of Standards, "DES Modes of Operation", FIPS 565 PUB 81 (December 1980). 567 [SHA] National Institute of Standards and Technology (NIST), 568 "Announcing the Secure Hash Standard," FIPS 180-1, U.S. 569 Department of Commerce, 04/1995 571 [IEEE80211Tgi] 572 IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR 573 Telecommunications and Information Exchange between Systems - 574 LAN/MAN Specific Requirements - Part 11: Wireless Medium 575 Access Control (MAC) and physical layer (PHY) specifications: 576 Specification for Enhanced Security", July 2001. 578 [IEEE80211] 579 Information technology - Telecommunications and information 580 exchange between systems - Local and metropolitan area 581 networks - Specific Requirements Part 11: Wireless LAN Medium 582 Access Control (MAC) and Physical Layer (PHY) Specifications, 583 IEEE Std. 802.11-1997, 1997. 585 [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", August 586 2000, http://msdn.microsoft.com/library/ 587 default.asp?url=/library/en-us/eap/eapport_0fj9.asp 589 Acknowledgments 591 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 592 Dorothy Stanley of Agerem and Russ Housley of RSA Security for useful 593 feedback. 595 Author Addresses 597 Bernard Aboba 598 Microsoft Corporation 599 One Microsoft Way 600 Redmond, WA 98052 602 EMail: bernarda@microsoft.com 603 Phone: +1 425 706 6605 604 Fax: +1 425 706 7329 606 Dan Simon 607 Microsoft Research 608 Microsoft Corporation 609 One Microsoft Way 610 Redmond, WA 98052 612 EMail: dansimon@microsoft.com 613 Phone: +1 425 706 6711 614 Fax: +1 425 706 7329 616 Intellectual Property Statement 618 The IETF takes no position regarding the validity or scope of any 619 intellectual property or other rights that might be claimed to pertain 620 to the implementation or use of the technology described in this 621 document or the extent to which any license under such rights might or 622 might not be available; neither does it represent that it has made any 623 effort to identify any such rights. Information on the IETF's 624 procedures with respect to rights in standards-track and standards- 625 related documentation can be found in BCP-11. Copies of claims of 626 rights made available for publication and any assurances of licenses to 627 be made available, or the result of an attempt made to obtain a general 628 license or permission for the use of such proprietary rights by 629 implementors or users of this specification can be obtained from the 630 IETF Secretariat. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary rights 634 which may cover technology that may be required to practice this 635 standard. Please address the information to the IETF Executive 636 Director. 638 Full Copyright Statement 640 Copyright (C) The Internet Society (2002). All Rights Reserved. 641 This document and translations of it may be copied and furnished to 642 others, and derivative works that comment on or otherwise explain it or 643 assist in its implmentation may be prepared, copied, published and 644 distributed, in whole or in part, without restriction of any kind, 645 provided that the above copyright notice and this paragraph are included 646 on all such copies and derivative works. However, this document itself 647 may not be modified in any way, such as by removing the copyright notice 648 or references to the Internet Society or other Internet organizations, 649 except as needed for the purpose of developing Internet standards in 650 which case the procedures for copyrights defined inthe Internet 651 Standards process must be followed, or as required to translate it into 652 languages other than English. The limited permissions granted above are 653 perpetual and will not be revoked by the Internet Society or its 654 successors or assigns. This document and the information contained 655 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 656 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 657 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 658 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 659 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 661 Expiration Date 663 This memo is filed as , and 664 expires August 22, 2002.