EAP Working Group Bernard Aboba INTERNET-DRAFT Dan Simon Category: Informational Microsoft <draft-aboba-pppext-key-problem-04.txt> 6 December 2002 EAP Key Management Guidelines Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the issues involved in key derivation by EAP methods and provides guidelines for generation and usage of EAP keys. Algorithms for key derivation are not specified in this document. Rather, this document lays out a framework within which EAP key management algorithms can be discussed and evaluated. Aboba & Simon Informational [Page 1]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 Table of Contents 1. Introduction .......................................... 3 1.1 Requirements language ........................... 4 1.2 Terminology ..................................... 4 2. EAP architecture overview ............................. 5 2.1 Implications of the architecture ................ 8 2.2 EAP key hierarchy ............................... 9 3. EAP Keying Requirements ............................... 10 3.1 EAP method requirements ......................... 10 3.2 Ciphersuite requirements ........................ 13 4. Security considerations ............................... 14 5. Normative references .................................. 14 6. Informative references ................................ 14 Acknowledgments .............................................. 16 Author's Addresses ........................................... 16 Intellectual Property Statement .............................. 16 Full Copyright Statement ..................................... 17 Aboba & Simon Informational [Page 2]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 1. Introduction The Extensible Authentication Protocol (EAP), defined in [RFC2284], was developed to provide extensible authentication for use with PPP [RFC1661]. Since then, new applications of EAP have emerged, including IEEE 802.1X network port authentication [IEEE8021X], and PIC [PIC]. The primary purpose of EAP is to authenticate an EAP Client to a Network Access Server (NAS), as well as to provide keys for use with a ciphersuite. EAP presumes that prior to authentication, the EAP Client and NAS have located each other via some out-of-band mechanism. For example, for use with PPP, the Client might contain a phone book that would provide phone numbers of NASes used with the selected service. In IEEE 802.11, the Client (also known as a Station) may locate NAS devices (also known as Access Points) using the IEEE 802.11 Beacon and Probe Request/Response frames. EAP also assumes that ciphersuite negotiation and selection is done out-of-band, and therefore need not be handled within EAP itself. For example, a Client might be preconfigured with the ciphersuite to be used in communicating with a given NAS, or alternatively, the ciphersuite may be negotiated out-of-band. For example, within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP) after EAP authentication is completed. Within IEEE 802.11i, the AP capabilities (including ciphersuite) are advertised in the Beacon and Probe Responses, and are verified during a 4-way exchange after EAP authentication has completed. The desired ciphersuite is indicated within the Association/Reassociation Request/Response exchange. EAP methods defined in [RFC2284bis] include EAP MD5, as well as One-Time Password (OTP) and Generic Token Card methods. Each of these methods supports one-way authentication only but not key derivation. However, subsequent EAP method specifications such as EAP TLS [RFC2716], EAP SRP [EAPSRP], EAP GSS [EAPGSS] and EAP AKA [EAPAKA] have provided for mutual authentication, as well as key derivation. The ciphersuites for which EAP may provide keying material have also grown in number. With the increase in the number of EAP methods and applicable ciphersuites, there is a need for defining how transient session keys are derived from the master secrets produced by EAP methods, and how keys are used to provide cryptographic binding between methods used in a sequence or tunnel. Allowing each EAP method to handle this in its own way is likely to produce unacceptable results. This document reviews the issues involved in EAP key derivation and provides guidelines for the generation of keys by EAP methods. Aboba & Simon Informational [Page 3]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 1.1. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. 1.2. Terminology This document frequently uses the following terms: Authentication Server An Authentication Server is an entity that provides an Authentication Service to a Network Access Server (NAS). This service verifies from the credentials provided by the Client, the claim of identity made by the Client. Where an Authentication Server is provided, it acts as the EAP server, terminating EAP conversation with the EAP Client. Cryptographic binding The demonstration of the EAP Client to the EAP Server that a single entity has acted as the EAP Client for all methods executed within a sequence or tunnel. Binding MAY also imply that the EAP Server demonstrates to the Client that a single entity has acted as the EAP Server for all methods executed within a sequence or tunnel. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities. Master key (MK) The key derived between the EAP Client and Server during the EAP authentication process. Network Access Server (NAS) The device that provides access to the network. Where no Authentication Server is present, the NAS acts as the EAP Server, terminating the EAP conversation with the Client. Where an Authentication Server is present, the NAS may act as a passthrough for one or more authentication methods and for non-local users. Pairwise Master Key (PMK) Pairwise Master Keys (PMKs) are derived from the Master Key (MK) and are subsequently used in generation of Transient Session Keys (TSKs) for use in the selected ciphersuite. So that the PMKs are usable with any ciphersuite, they are longer than is necessary, and are truncated to fit. Transient Session Keys (TSKs) The EAP Client and NAS derive the TSKs from the PMKs. These Aboba & Simon Informational [Page 4]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 are of appropriate size for use with the chosen ciphersuite. 2. EAP architecture overview EAP authentication involves a Client, NAS and (optionally) an Authentication Server. One of the goals of EAP is to enable development of new authentication methods without requiring deployment of new code on the NAS. While the NAS may implement some methods locally and use those methods to authenticate local users, it may at the same time act as a "passthrough" for other users and methods. Supporting "passthrough" of authentication to the Authentication Server enables the NAS to support additional non-locally implemented methods. Among other things, this implies that a NAS need not implement code for each EAP method required by authenticating Clients. Figure 1 illustrates the EAP authentication process in the case where the Client is authenticated locally by the NAS using a locally installed authentication method. In this case, the Master Key (MK) and Pairwise Master Keys (PMKs) are derived on the Client and the NAS, which acts as the EAP server during the EAP authentication exchange. The Client and NAS then use the PMK to derive the transient session keys used with the selected ciphersuite. It is assumed that ciphersuite negotiation is handled out of band, rather than within EAP. If the authentication occurs with a method not implemented on the NAS, or involves a non-local user whose credentials the Server is unable to validate, then the NAS functions as a "passthrough". For passthrough authentication methods, instead of requiring code on the NAS, the NAS delegates the authentication to an Authentication Server. The Authentication Server installs the desired EAP methods, typically by interfacing with the operating system via an EAP API, such as that described in [EAPAPI]. In order to allow the Client and Authentication Server to install new EAP methods without requiring an operating system upgrade, operating systems isolate EAP method-specific code within the installed EAP methods, and thus largely operate as "passthrough" entities with respect to EAP. Figure 2 describes the relationship between the EAP Client, NAS and Authentication Server, for authentications which occur in "passthrough" mode. As described in the figure, the EAP conversation may "pass through" the NAS on its way between the Client and the Authentication Server (which acts as the EAP Server in this case). As a result, the NAS does not have knowledge of the keys that are derived between the Authentication Server and the Client, and these keys need to be transmitted from the Authentication Server to the NAS. Aboba & Simon Informational [Page 5]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ | | EAP | | | | Conversation | | | |<=============>| NAS | | Client | | (EAP | | | | Server) | | | | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | EAP API | EAP API | | V V +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | EAP | | EAP | | Method | | Method | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 1 - Relationship between EAP Client and NAS (acting as an EAP Server) where no Authentication Server is present Aboba & Simon Informational [Page 6]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | EAP | | | | | | Conversation | | | | | |<================================>| Authent.| | Client | | NAS | | Server | | | | |<=======| | | | | | PMK(s) | (EAP | | | | | | Server) | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | EAP API | EAP API | | V V +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | EAP | | EAP | | Method | | Method | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 2 - "Passthrough" relationship between EAP Client, NAS and Authentication Server. EAP methods are installed on the the Client and the Authentication Server, typically communicating via an EAP API, so that the main Client and Authentication Server code does not need to be modified to add new methods. Among the results that are passed back by EAP methods via the APIs are the PMK(s) to be communicated from the Authentication Server to the NAS. Ciphersuites are installed on the NAS and the Client. Aboba & Simon Informational [Page 7]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 2.1. Implications of the architecture While EAP methods which derive keys can be used to provide automated keying for a ciphersuite, this does not imply that the EAP method need contain ciphersuite-specific code. Since the Client and NAS need to implement a given ciphersuite, ciphersuite-specific code is expected to exist on the Client and NAS. However, since the Authentication Server is not involved in the protection of data traffic, and may not even be aware of the negotiated ciphersuite, it cannot be assumed to implement ciphersuite-specific code, and the backend Authentication Server will not necessarily have knowledge of the ciphersuites available on the NAS and Client. Since the Authentication Server may not have knowledge of the ciphersuite that has been negotiated, it may not be possible for this information to be passed to the EAP method via the EAP APIs. As a result, inclusion of ciphersuite-specific code within an EAP method may not be possible. Similarly, because the NAS is assumed to not have knowledge of individual EAP methods, it cannot be assumed to include code specific to an EAP method. Moreover, since operating systems provide EAP APIs in order to remain "EAP-Method Agnostic", EAP method-specific code is best kept out of the EAP APIs as well. Drawbacks to allowing EAP methods to specify session key derivation mechanisms for individual ciphersuites include: Document Revision If an EAP method specifies how to derive transient session keys on a per-ciphersuite basis, then this document will need to be revised each time a new ciphersuite comes out. This would also imply that an Authentication Server supporting an EAP method might not be usable with a NAS supporting EAP, due to lack of support for a ciphersuite implemented on the NAS. Since the EAP architecture enables the NAS "passthrough" EAP methods that it does not implement, a NAS implementing EAP can be used to implement any authentication method supported by the Authentication Server and Client, not just locally implemented methods. EAP method complexity Forcing the EAP method to include ciphersuite-specific code for transient session key derivation increases the complexity of EAP method development, as well as Client and Authentication Server implementations. Aboba & Simon Informational [Page 8]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 Knowledge asymmetry In practice, an EAP method may not have knowledge of the ciphersuite that has been negotiated. In PPP, negotiation of the ciphersuite is accomplished via the Encryption Control Protocol (ECP), described in [RFC1968]. Since ECP negotiation occurs after authentication, unless an EAP method is utilized that supports ciphersuite negotiation (such as EAP-TLS [RFC2716]), the Client, NAS and backend Authentication Server may not be able to anticipate the ciphersuite that will be used and therefore this information cannot be provided to the EAP method. 2.2. EAP Key hierarchy In the most general case, ciphersuite-specific keys must be derived from the master secret (K) derived by the EAP method. This is accomplished in two steps. [1] Derivation of the PMK from the Master Key. Using a one-way function, the EAP method derives the Pairwise Master Keys (PMKs) from the master key. Since any entity possessing the master key can impersonate the client and authentication server, the master key MUST be kept local to the client and authentication server and MUST NOT be provided to the NAS. However, the client and NAS need to share a key in order to subsequently derive ciphersuite-specific keys to protect subsequent data communications. Deriving the PMK from the master key via a one-way function enables the Authentication Server to provide the PMK(s) to the NAS without compromising the master key. Note that the PMK(s) are never directly used by the ciphersuitesw; they are only used in the derivation of transient session keys. The Client and Authentication Server compute the PMK(s) within the EAP method; the Authentication Server then transmits the PMK(s) to the NAS. Examples of Pairwise Master Key (PMK) derivation algorithms are provided in Section 3.5 of EAP TLS [RFC2716]. In that document, the PMK(s) are referred to as "Master Session Keys", and are derived based on the Pseudo-Random Function (PRF) defined in TLS [RFC2246]. Equivalent algorithms are provided in IKE [RFC2409] for the derivation of SKEYID_d, SKEYID_a and SKEYID_e from the master key SKEYID. RADIUS attributes for PMK transport are provided in [RFC2548]. [2] Derivation of the "transient session keys" from the PMK(s). The "transient session keys" are used by the ciphersuite negotiated between the EAP client and NAS. Depending on the negotiated ciphersuite and media, the algorithms for "transient session key" Aboba & Simon Informational [Page 9]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 derivation may differ. For example, 802.11 WEP does not provide a keyed message integrity check, and typically uses only a single encryption key in both directions. On the hand, PPP MPPE [RFC3079] requires encryption keys in both directions. Note that the master key may not be directly available within all EAP methods. For security reasons, the TLS master secret is typically not directly available via TLS APIs. As a result, [RFC2716] derives PMKs from the TLS master secret. Since EAP TLS [RFC2716] does not assume knowledge of the negotiated ciphersuite, it provides PMKs large enough for use with any ciphersuite, assuming that these will be truncated for use within the Client and NAS. Since the raw master secret is typically not available in to EAP-TLS implementations, when this EAP method is used, the TLS PRF function is needed to derive keying material from it. Other EAP methods may also encounter similar issues. For example, EAP GSS implementations will typically not be able to access the master keys directly, but can call GSS_Wrap() to encrypted tokens and GSS_GetMIC() to generate authentication tokens based on the master secret. EAP GSS implementations will therefore need to use GSS-API calls to derive PMK(s) from the master key, rather than operating on the master key directly. Where the master key K is not exportable, an intermediate step is required to generate a "Pseudo-Master Key" from the master key. For example, in [EAPGSS], a "Pseudo-Master Key", K' is derived via GSS-API calls, and is used instead. The steps by which the Transient Session Keys (TSKs) are derived from the Master Key (MK) are illustrated in Figure 3 on the next page. 3. EAP Keying requirements This section describes the keying requirements of EAP methods that MUST be met by method specifications requesting publication as an RFC. 3.1. EAP method requirements Key derivation Methods listing IEEE 802.11 WLANs as the intended medium MUST support key derivation. Algorithm specification Methods supporting key derivation MUST include a specification for the derivation of the PMK from the Master Key. Aboba & Simon Informational [Page 10]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- | | | | ^ | Is a raw master key | | Can a pseudo-master key | | | available or can | | be derived from | | | the PRF operate on it? | | the master key? | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | K | K' | | | | V V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Pairwise Master Key | EAP | | Derivation | Method | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP V | | API ---+--- | Pairwise Master Key(s) | | | | | | | AAA | | | Keys V V V ---+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | | | | Ciphersuite-Specific Key Hierarchy | NAS | | and Derivation | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- Figure 3 - Architecture for derivation of ciphersuite-specific session key from the EAP master key K. Aboba & Simon Informational [Page 11]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 Ciphersuite independence The algorithm for deriving the PMK(s) from the "master key" provided by the EAP method MUST be ciphersuite-independent. The algorithm MUST NOT require ciphersuite-specific code to be implemented within an EAP method. One-way function Given the PMK, it MUST NOT be possible to derive the Master Key. Key size An EAP method supporting key derivation SHOULD generate a PMK of at least 512 bits in length. Standard Keying AVPs In order to enable Authentication Servers to provide keying material to the NAS in a well defined format, AAA servers SHOULD use ciphersuite-independent AAA attributes to transmit the PMK(s) from the Authentication Server to the NAS. Since it is assumed that the Authentication Server will perform the required calculations to compute the PMK(s), the PMK derivation algorithm need not be implemented on the NAS. Key Entropy The strength of the session keys is dependent upon the security of the EAP method providing the keying material. If the chosen EAP method has security vulnerabilities, or does not produce a key of sufficient entropy then it is possible that weak session keys may be produced. An EAP method supporting key derivation SHOULD generate PMK(s) with at least 128 bits of entropy. Nonce exchange In order to assure non-repetition of the PMK, the PMK derivation SHOULD include a two-way nonce exchange, using nonces of at least 128-bits. Known-good algorithms The derivation and validation of key derivation algorithms is difficult, and as a result it is highly desirable to reuse existing algorithms. This enables the security community to carefully analyze the proposed algorithm; such an analysis would be difficult were multiple algorithms to proliferate. As a result, EAP methods SHOULD utilize well established and analyzed mechanisms for deriving the PMK from the Master Key. Aboba & Simon Informational [Page 12]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 3.2. Ciphersuite requirements The derivation of transient session keys from PMK(s) occurs after the ciphersuite has been determined. Ciphersuites looking to be keyed by EAP methods need to provide the following facilities: TSK specification In order to use the PMK(s) provided by EAP methods, ciphersuites keyed via EAP need to define how transient session keys are derived from the PMK(s) provided by EAP methods. EAP method independence Algorithms for deriving transient session keys from PMK(s) MUST NOT depend on the EAP method. Derivation of transient session keys occurs on the client as well as on the NAS, which acts as a "passthrough" for EAP. Therefore the NAS cannot be expected to have knowledge of the EAP method that has been negotiated. Cryptographic separation The transient session keys derived from the PMK(s) MUST be cryptographically independent. That is, given one of the transient session keys it MUST NOT be possible to derive other transient session key(s). PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE [RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes (such as CBC, used in RFC 2419 and DES-EDE3-CBC, used in RFC 2420) are described in [DESMODES]. For PPP DESEbis, a single 56-bit encryption key is required, used in both directions; for PPP 3DES, a 168-bit encryption key is needed, used in both directions. As described in [RFC2419] and [RFC2420] for both protocols, the IV, which is different in each direction, is "deduced from an explicit 64-bit nonce, which is exchanged in the clear during the negotiation phase." For MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in each direction, as described in [RFC3078]. Since MPPE is based on the RC4 algorithm, no initialization vector is required. While these PPP ciphersuites provide encryption, they do not provide a per-packet keyed message integrity check (MIC). Thus, an authentication key is not required in either direction. Within 802.11, ciphersuites include WEP-40, described in [IEEE80211], which requires a 40-bit encryption key, the same in either direction; and WEP-128, which requires a 104-bit encryption key, the same in either direction. These ciphersuites also do not include a keyed MIC. Aboba & Simon Informational [Page 13]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 Recently, new ciphersuites have been proposed for use with 802.11 that do provide per-packet authentication as well as encryption [IEEE80211Tgi]. These ciphersuites use either 104-bit or 128-bit keys, and include definition of their own ciphersuite-specific key hierarchy. 4. Security considerations The subject of this document is security. 5. Normative References [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 2246, November 1998. [RFC2284bis] Blunk, L., Vollbrecht, J., Aboba, B., "Extensible Authentication Protocol (EAP)", Internet draft (work in progress), draft-ietf-pppext-rfc2284bis-08.txt, December 2002. [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. 6. Informative References [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996. [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Aboba & Simon Informational [Page 14]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption (MPPE) RFC 3078, March 2001. [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)," RFC 3079, March 2001. [EAPGSS] Aboba, B., "EAP GSS Authentication Protocol", Internet draft (work in progress), draft-aboba-pppext-eapgss-12.txt, April 2002. [EAPAKA] Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet draft (work in progress), draft-arkko-pppext-eap-aka-05.txt, October 2002. [EAPSRP] Carlson, J., Aboba, B., Haverinen, H., "PPP EAP SRP-SHA1 Authentication Protocol", Internet-draft (work in progress), draft-ietf-pppext-eap-srp-03.txt, July 2001. [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977). [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE Credential Provisioning Protocol", Internet draft (work in progress), draft-ietf-ipsra-pic-06.txt, October 2002. [DESMODES] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980). [SHA] National Institute of Standards and Technology (NIST), "Announcing the Secure Hash Standard," FIPS 180-1, U.S. Department of Commerce, 04/1995 [IEEE80211Tgi] IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", July 2001. [IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Aboba & Simon Informational [Page 15]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 IEEE Std. 802.11-1997, 1997. [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", August 2000, http://msdn.microsoft.com/library/ default.asp?url=/library/en-us/eap/eapport_0fj9.asp Acknowledgments Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Dorothy Stanley of Agerem and Russ Housley of RSA Security for useful feedback. Author Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: dansimon@microsoft.com Phone: +1 425 706 6711 Fax: +1 425 936 7329 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Aboba & Simon Informational [Page 16]
INTERNET-DRAFT EAP Key Mgmt. 6 December 2002 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date This memo is filed as <draft-aboba-pppext-key-problem-04.txt>, and expires July 22, 2003. Aboba & Simon Informational [Page 17]