Network Working Group Y. Ohba Internet-Draft Toshiba Intended status: Informational S. Das Expires: July 8, 2007 Telcordia January 4, 2007 An EAP Method for EAP Extension (EAP-EXT) draft-ohba-hokey-emu-eap-ext-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on July 8, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Ohba & Das Expires July 8, 2007 [Page 1] Internet-Draft EAP-EXT Method January 2007 Abstract This document describes an EAP method that is used for extending EAP functionality. The extended functionality includes re-authentication and channel binding. The proposed EAP method (EAP-EXT) also allows sequencing of multiple EAP methods within itself. EAP-EXT can generate MSK (Master Session Key) and EMSK (Extended Master Session Key) in cases where inner method(s) implementations generate MSK but do not generate EMSK. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 2. EAP-EXT Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. MSK and EMSK exported from EAP-EXT . . . . . . . . . . . . 8 4.2. EAP-EXT-KEY . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. EAP-REAUTH-KEY . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 9 6. EAP-EXT TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Method TLV . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. AUTH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Peer-ID TLV . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Server-ID TLV . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Reauth-Key-Lifetime TLV . . . . . . . . . . . . . . . . . 12 6.6. PRF TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.7. Channel-Binding-Mechanism TLV . . . . . . . . . . . . . . 13 6.8. Channel-Binding-Data TLV . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Ohba & Das Expires July 8, 2007 [Page 2] Internet-Draft EAP-EXT Method January 2007 1. Introduction EAP (Extensible Authentication Protocol) is an authentication protocol which supports multiple authentication algorithms known as "EAP methods" [RFC3748]. In EAP, an EAP peer and an EAP server generates EAP keying material, i.e., MSK (Master Session Key) and EMSK (Extended Master Session Key) upon successful authentication. A detailed framework for the generation, transport and usage of MSK is described in [I-D.ietf-eap-keying]. Additional functionalities such as re-authentication [I-D.vidya-eap-reauth-ps] and channel binding [I-D.ietf-eap-keying] can be supported by extending EAP functionality. There can be two approaches for extending EAP functionality. One approach is to define new EAP Codes to realize the extended EAP functionality in addition to the existing ones, i.e., Request, Response, Success and Failure. This approach, however, requires changes to [RFC3748] and may also require changes to authenticators and lower layer protocols. The other approach is to define a new EAP method to realize the extended functionality. For both approaches, it may be desirable that these extended functionalities are backward compatible. In such cases, a mechanism for negotiating the capabilities on the extended functionalities between an EAP peer and an EAP server may be needed. This document describes an EAP method that is used for extending EAP functionality. The extended functionality includes re-authentication and channel binding. The proposed EAP method (EAP-EXT) also allows sequencing of multiple EAP methods within itself. EAP-EXT can generate MSK and EMSK in cases where inner method(s) implementations generate MSK but do not generate EMSK. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119]. Ohba & Das Expires July 8, 2007 [Page 3] Internet-Draft EAP-EXT Method January 2007 2. EAP-EXT Overview EAP-EXT provides capabilities exchange. One bit (R-bit) is used for indicating Re-authentication capability. One bit (C-bit) is used for indicating channel binding capability. When EAP-EXT is used, the precedent EAP-Identity exchange MAY be omitted if the identity of the peer is known to the server before the server sends the first EAP-Request. Note that there are several outband mechanisms for providing the identity of the peer to the server, e.g., transferring the identity of the peer between authenticators and servers. In EAP-EXT, extended EAP capabilities such as re-authentication and channel binding are exchanged between the peer and the server. At the same time, at least one EAP method (e.g., EAP-TLS) is run inside EAP-EXT for authenticating the peer. Inner method(s) are carried in Method TLVs (Type-Length-Values). Until an inner method generates EAP keying material, no AUTH TLV is included and the capabilities are non-protected. Hence, if there is only one inner EAP method, additional EAP-EXT exchange(s) with an AUTH TLV need(s) to be performed after completion of the inner method and before sending an EAP-Success or an EAP-Failure message. After an inner EAP method generates EAP keying material, EAP-EXT messages MUST be protected with an AUTH TLV. AUTH TLVs in EAP-EXT messages MUST be computed using EAP-EXT-KEY generated from EAP keying material of the latest successful inner method. This means that if there are multiple inner EAP methods that are sequentially run inside EAP-EXT, a new EAP-EXT-KEY is generated each time an inner EAP method in the sequence generates EAP keying material. Any inner EAP method MUST be capable of generating EAP keying material. At the end of a successful EAP-EXT run, EAP keying material is derived from the MSK generated by the last successful inner EAP method and is exported to the EAP layer. The pseudo random function used for deriving the EAP keying material and USRKs (Usage Specific Root Keys) [I-D.salowey-eap-emsk-deriv] MAY be negotiated within EAP- EXT using PRF TLVs. F-bit is used for indicating the end of EXP-EXT exchange. Figure 1 shows an example of EAP-EXT message sequence with a single inner EAP method and with PRF negotiation. Figure 2 shows an example of EAP-EXT message sequence with multiple inner EAP methods and without PRF negotiation. Ohba & Das Expires July 8, 2007 [Page 4] Internet-Draft EAP-EXT Method January 2007 Peer Server | EAP-Request/Identity (optional) | |<---------------------------------------------------| | EAP-Response/Identity (optional) | |--------------------------------------------------->| | EAP-Request/EXT{Cap.(R,C),PRF(1,2),Method(Type X),| | CBM(1,2),CBD} | |<---------------------------------------------------| | EAP-Response/EXT{Cap.(R,C),PRF(1),Method(Type X), | | CBM(1)} | |--------------------------------------------------->| | ... | | EAP-Request/EXT{F,Cap.(R,C),PRF(1,2),Peer-ID, | | Server-ID,Reauth-Key-Lifetime, | | CBM(1,2),CBD,AUTH} | |<---------------------------------------------------| | EAP-Response/EXT{F,Cap.(C,R),PRF(2),CBM(1),AUTH} | |--------------------------------------------------->| | EAP-Success | |<---------------------------------------------------| F: F-bit is set Cap.(R,C): R-bit and C-bit of Capabilities field are set PRF(1,2): PRF TLV carrying PRF numbers 1 and 2 PRF(1): PRF TLV carrying PRF numbers 1 Method(Type X): Method TLV carrying method Type X Peer-ID: Peer-ID TLV Server-ID: Server-ID TLV Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV AUTH: AUTH TLV CBM(1,2): Channel-Binding-Mechanism TLV with channel binding mechanism numbers 1 and 2 CBM(1): Channel-Binding-Mechanism TLV with channel binding mechanism number 1 CBD: Channel-Binding-Data TLV Figure 1: EAP-EXT message sequence with a single inner method and PRF negotiation Ohba & Das Expires July 8, 2007 [Page 5] Internet-Draft EAP-EXT Method January 2007 Peer Server | EAP-Request/Identity (optional) | |<----------------------------------------------------| | EAP-Response/Identity (optional) | |---------------------------------------------------->| | EAP-Request/EXT{Cap.(R,C),Method(Type=X),CBM(1,2), | | CBD| | |<----------------------------------------------------| | EAP-Response/EXT{Cap.(R,C),Method(Type=X),CBM(2), | | CBD} | |---------------------------------------------------->| | .... | | EAP-Request/EXT{Cap.(R,C),Method(Type=Y), | | CBM(1,2),CBD,AUTH} | |<----------------------------------------------------| | EAP-Response/EXT{Cap.(R,C),Method(Type=Y), | | CBM(2),CBD,AUTH} | |---------------------------------------------------->| | .... | | EAP-Request/EXT{F,Cap.(R,C),Method(Type=Y), | | Peer-ID, Server-ID, | | Reauth-Key-Lifetime, CBM(1,2), | | CBD,AUTH} | |<----------------------------------------------------| | EAP-Response/EXT{F,Cap.(R,C),Method(Type=Y), | | CBM(2),CBD,AUTH} | |---------------------------------------------------->| | EAP-Success | |<----------------------------------------------------| F: F-bit is set Cap.(R,C): R-bit and C-bit of Capabilities field are set Method(Type-X): Method TLV carrying method Type X Method(Type-Y): Method TLV carrying method Type Y Peer-ID: Peer-ID TLV Server-ID: Server-ID TLV Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV AUTH: AUTH TLV CBM(1,2): Channel-Binding-Mechanism TLV with channel binding mechanism numbers 1 and 2 CBM(2): Channel-Binding-Mechanism TLV with channel binding mechanism number 2 CBD: Channel-Binding-Data TLV Figure 2: EAP-EXT message sequence with multiple inner methods and without PRF negotiation Ohba & Das Expires July 8, 2007 [Page 6] Internet-Draft EAP-EXT Method January 2007 3. Error Handling An error may happen for several reasons, e.g., due to failure of inner EAP method authentication or a malformed, unknown or missing EAP-EXT TLV. An error may be detected either by the peer or by the server. An EAP-EXT message that caused an error is referred to as an erroneous message. EAP-EXT messages with E-bit set are used for error indications. These messages are referred to as error indications. An error indication MUST contain an AUTH TLV, and SHOULD NOT contain other TLVs. Any erroneous message (including an erroneous error indication) without a valid AUTH TLV MUST be silently discarded. For an erroneous Request with a valid AUTH TLV, the peer sends an error indication Response. For an erroneous Response with a valid AUTH TLV, the server sends an error indication Request which is responded by the peer with an error indication Response. The server returns an EAP-Failure message in response to an error indication Response with a valid AUTH TLV. Ohba & Das Expires July 8, 2007 [Page 7] Internet-Draft EAP-EXT Method January 2007 4. Keys EAP-EXT defines the following types of keys. 4.1. MSK and EMSK exported from EAP-EXT A set of 64-octet MSK and 64-octet EMSK to be exported from EAP-EXT is derived from MSK_i, the MSK generated by the last successful inner EAP method, using the KDF defined in [I-D.salowey-eap-emsk-deriv] in the following way. (MSK, EMSK) = KDF(MSK_i, "EAP-EXT-EAP-Keying-Material", 128) 4.2. EAP-EXT-KEY EAP-EXT-KEY is used for computing AUTH TLVs for integrity protecting EAP-EXT messages. EAP-REAUTH-KEY is used within EAP-EXT only and is never exported. The EAP-EXT-KEY is the first N octets of MSK generated by an inner EAP method, where N denotes the length of EAP- EXT-KEY. When HMAC-SHA-256 [sha256] is used for the integrity algorithm, N=32. 4.3. EAP-REAUTH-KEY EAP-REAUTH-KEY is used as the pre-shared key required by an EAP method used for a re-authentication mechanism. The length of EAP- REAUTH-KEY. The length of EAP-REAUTH-KEY depends on the re- authentication mechanism. The EAP-REAUTH-KEY is derived from the EMSK exported from EAP-EXT using the USRK derivation algorithm defined in [I-D.salowey-eap-emsk-deriv] as follows. EAP-REAUTH-KEY = KDF(EMSK, "EAP-EXT-Reauthentication-Key", length) Ohba & Das Expires July 8, 2007 [Page 8] Internet-Draft EAP-EXT Method January 2007 5. Message Format EAP-EXT uses EAP Type XX (To be assigned by IANA). The message format including the common EAP fields (i.e., Code, Identifier, Length and Type) defined in [RFC3748] is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Version |F|E| Reserved | Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV(s) (optional) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- F This bit MUST be set to indicate that this is the last EAP-EXT message from the sender. Otherwise, this bit MUST NOT be set. E This bit is set when the message is an error indication. When this bit is set, F-bit MUST also be set. See Section 3 for detailed description on error indications. Version This 8-bit field indicates the version of the EAP-EXT method. This document defines Version 1. Reserved This 6-bit field is reserved for future extensions. This field MUST be set to zero by the sender and the recipient MUST ignore this field. Capabilities This field The Capabilities field contains extended EAP capabilities. The Capabilities field the following format. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R C r r r r r r| +-+-+-+-+-+-+-+-+ Ohba & Das Expires July 8, 2007 [Page 9] Internet-Draft EAP-EXT Method January 2007 Each bit corresponds to a particular capability. The semantics of each bit is as follows. R This bit is set to indicate that the sender supports a re- authentication EAP method. When this bit is set in the final Request/EXT message (i.e., the Request/EXT with F-bit is set), the message MUST include a Server-ID TLV and a Peer-ID TLV and MAY include a Reauth-Key-Lifetime AVP. If this bit is set in the final Request/EXT and Response/EXT exchange, the peer and the server MUST generate an EAP-REAUTH-KEY. The Server-ID and Peer-ID contained in the Server-ID and Peer-ID TLVs and the EAP-REAUTH-KEY is used for a re-authentication EAP method. The default re-authentication mechanism is TBD. C This bit is set to indicate that the sender supports a channel binding mechanism for MSK. When this bit is set in a Request/ EXT message, one Channel-Binding-Mechanism TLV MUST also be included to indicate the channel binding mechanism(s) supported by the server. If the peer supports and wants to enable one of the the channel binding mechanism(s) supported by the server, it sends a Response/EXT message with this bit set and one Channel-Binding-Mechanism TLV containing the selected channel binding mechanism. If this bit is set in the final Request/EXT and Response/EXT exchange with successful negotiation of one channel binding mechanism and the EAP-EXT method completes with success, the peer and the server MUST enable the negotiated channel binding mechanism. Other bits are reserved for future use, and MUST be set to zero by the sender and MUST be ignored by the recipient. TLV Zero, one or more TLVs (Type-Length-Value's). The TLV format of is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Ohba & Das Expires July 8, 2007 [Page 10] Internet-Draft EAP-EXT Method January 2007 Type This field indicates the type of this TLV. Length This field indicates the length of this TLV in octets, including the Type and Length fields of the TLV. Value This field contains data specific to the TLV Type. Ohba & Das Expires July 8, 2007 [Page 11] Internet-Draft EAP-EXT Method January 2007 6. EAP-EXT TLVs The following TLVs are defined. 6.1. Method TLV The Method TLV (Type 1) contains an EAP Method payload starting from Type field. 6.2. AUTH TLV The AUTH TLV (Type 2) contains integrity data used for protecting EAP-EXT messages. The EAP-EXT-KEY is used for computing AUTH TLVs. The TLV-Value field is computed over the entire EAP message including this field. Before computing the integrity data, this field MUST be initialized to all zeros. The length of this field depends on the integrity algorithm in use. When the integrity check fails, the message MUST be silently discarded. The default integrity algorithm is HMAC-SHA-256 [sha256]. 6.3. Peer-ID TLV The Peer-ID TLV (Type 3) contains the identity of the peer used for re-authentication. 6.4. Server-ID TLV The Server-ID TLV (Type 4) contains the identity of the server used for re-authentication. 6.5. Reauth-Key-Lifetime TLV The Reauth-Key-Lifetime TLV (Type 5) contains the lifetime of EAP- REAUTH-KEY in seconds. 6.6. PRF TLV The PRF TLV (Type 6) contains one or more one-octet PRF numbers defined in [I-D.salowey-eap-emsk-deriv]. When this TLV is carried in a Request, it indicates the PRF number(s) supported by the server. When this TLV is carried in a Request/EXT message, the corresponding Response/EXT message MAY contain this TLV. A PRF TLV in a Response/ EXT message MUST contain exactly one PRF number that is supported and selected by the peer among the PRF numbers in the Request/EXT message. If the PRF number is successfully negotiated using the PRF TLV exchange described above, the negotiated PRF number is used for KDF to derive EAP keying material to be exported by EAP-EXT and USRKs. Otherwise, the default PRF specified in Ohba & Das Expires July 8, 2007 [Page 12] Internet-Draft EAP-EXT Method January 2007 [I-D.salowey-eap-emsk-deriv] is used for KDF. 6.7. Channel-Binding-Mechanism TLV The Channel-Binding-Mechanism TLV (Type 7) contains one or more one- octet channel binding mechanism numbers. When this TLV is carried in a Request/EXT message, it indicates the channel binding mechanism number(s) supported by the server. When this TLV is carried in a Request/EXT message, the corresponding Response/EXT message MAY contain this TLV. A Channel-Binding-Mechanism TLV in a Response/EXT message MUST contain exactly one channel binding mechanism number that is supported and selected by the peer among the channel binding mechanism numbers in the Request/EXT message. If the channel binding mechanism is successfully negotiated using the Channel-Binding- Mechanism TLV exchange described above, the negotiated channel binding mechanism is enabled. The following channel binding mechanism numbers are defined in this document. 1 [I-D.ohba-eap-channel-binding] 2 [arkko-eap-service-identity-auth] For channel binding mechanism 1, the default hash algorithm for prf+ is AUTH_HMAC_SHA1_160. For channel binding mechanism 2, an additional Channel-Binding-Data TLV is carried in Requests and Responses. 6.8. Channel-Binding-Data TLV The Channel-Binding-Data TLV (Type 8) contains an octetstring data used for [arkko-eap-service-identity-auth]. Ohba & Das Expires July 8, 2007 [Page 13] Internet-Draft EAP-EXT Method January 2007 7. Security Considerations Capability exchange before an inner EAP method exports EAP keying material is unprotected. Hence, additional protected message exchange after creation of EAP keying material is mandated to avoid the capabilities information to be altered by an attacker without being detected by the peer and the server. EAP-EXT allows sequencing of multiple EAP methods inside it. It is known that a compound authentication method that consists of multiple nested or sequential authentication methods without cryptographically binding them has a vulnerability to man-in-the-middle attack. EAP- EXT is able to create the required cryptographically binding by protecting each inner EAP method together with the outer EAP method (i.e., EAP-EXT) with a key generated by its precedent successful inner method in the sequence and finally exporting EAP keying material derived from that is generated by the last successful inner EAP method. In order to achieve cryptographic binding, EAP-EXT requires inner EAP methods to be capable of generating EAP keying material. This method exports MSK and EMSK that are computed from MSK of an inner method. Therefore, the strength of exported MSK and EMSK altogether is the same as that of the MSK of the inner method. Ohba & Das Expires July 8, 2007 [Page 14] Internet-Draft EAP-EXT Method January 2007 8. IANA Considerations TBD. Ohba & Das Expires July 8, 2007 [Page 15] Internet-Draft EAP-EXT Method January 2007 9. Acknowledgments The authors would like to thank Bernard Aboba and Jari Arkko for their valuable inputs. Ohba & Das Expires July 8, 2007 [Page 16] Internet-Draft EAP-EXT Method January 2007 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-16 (work in progress), January 2007. [I-D.vidya-eap-reauth-ps] Narayanan, V. and L. Dondeti, "Problem Statement on EAP Efficient Re-authentication and Key Management", draft-vidya-eap-reauth-ps-00 (work in progress), October 2006. [I-D.ohba-eap-channel-binding] Ohba, Y., "Channel Binding Mechanism based on Parameter Binding in Key Derivation", draft-ohba-eap-channel-binding-02 (work in progress), December 2006. [I-D.salowey-eap-emsk-deriv] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in progress), June 2006. [sha256] National Institute of Standards and Technology, "Secure Hash Standard", August 2002. 10.2. Informative References [arkko-eap-service-identity-auth] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", http://tools.ietf.org/html/ draft-arkko-eap-service-identity-auth-04, October 2005. Ohba & Das Expires July 8, 2007 [Page 17] Internet-Draft EAP-EXT Method January 2007 Authors' Addresses Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Subir Das Telcordia 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 2483 Email: subir@research.telcordia.com Ohba & Das Expires July 8, 2007 [Page 18] Internet-Draft EAP-EXT Method January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ohba & Das Expires July 8, 2007 [Page 19]