EMU H. Zhou, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track M. Nakhjiri, Ed. Expires: January 2, 2008 Huawei H. Tschofenig, Ed. Siemens Networks GmbH & Co KG July 1, 2007 PP-EAP - A Protected Password-Based EAP Method draft-zhou-emu-pp-eap-00.txt 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 January 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines the Protected Password-based Extensible Authentication Protocol (EAP) method. PP-EAP is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a server-authentictaed tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used Zhou, et al. Expires January 2, 2008 [Page 1] Internet-Draft PP-EAP July 2007 to convey password-based authentication between the peer and the EAP server. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Password Authentication Exchange . . . . . . . . . . . . . 4 4.3. Crypto-Binding . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 7 4.4.1. PP-EAP Message Format . . . . . . . . . . . . . . . . 7 4.4.2. TLV Format . . . . . . . . . . . . . . . . . . . . . . 9 4.4.3. Password-Authentication TLV . . . . . . . . . . . . . 9 4.4.4. Result TLV . . . . . . . . . . . . . . . . . . . . . . 10 4.4.5. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 10 4.4.6. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 13 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 16 7.2. Server Certificate Validation . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Zhou, et al. Expires January 2, 2008 [Page 2] Internet-Draft PP-EAP July 2007 1. Introduction There were several existing EAP methods that support password-based authentications developed over the years, for example, PEAP, EAP- FAST, and EAP-TTLS. Most of them are based on TLS to establish a protected TLS tunnel and then exchange password-based authentication within the TLS tunnel. However, there is no standard mechanism and format defined for the inner data exchange, as well as the mechanism to support crypto-binding, extension of the data exchanged, and crypto-agility. The protocol defined in this document intends to address these limitations to ensure better interopabilities. The protected password-based EAP method described in this document consists of two steps: In step (1), the EAP-TLS protocol exchange is performed with the server authenticating to the client and optionally the client to the server. The TLS record layer is then used to offer authentication and integrity/confidentiality protection of the subsequent interaction. In step (2), Type-Length-Value (TLV) payloads for password-based authenication as well as protected result indication and crypo- binding are exchanged. This step will occur only if establishment of a protected TLS tunnel in step (1) was successful. Any data that is exchanged in this step is not vulnerable to active and passive man-in-the-middle attacks. 2. Terminology 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 RFC 2119 [1]. This document uses the terminology defined in [8]. 3. Requirements This section lists mandatory requirements that guided the work on this EAP method: 1. Support secure transport of clear text password to support legacy username and password databases, such as One-time Password (OTP) and LDAP. 2. Provide server authentication. 3. Provide resistance to offline dictionary attacks, man-in-the- middle attacks, and replay attacks. Zhou, et al. Expires January 2, 2008 [Page 3] Internet-Draft PP-EAP July 2007 4. Support exchange of channel binding data. 5. Compliant with RFC 3748, RFC 4017, EAP keying draft (includes MSK and EMSK generation). 6. Support user identity confidentiality for the peer. 7. Support Crypto-agility and cipher suite negotiation (need to define mandatory supported ciphers). 8. Support Session Resumption (avoid the need for use to re-enter the password every time). 9. Support protected result indication. 10. Support Fragmentation and reassembly. The following requirements are nice to have: o Support password/PIN changes. o Support Crypto-Binding to make sure the inner authenticaytion method and outer TLS tunnel exhcnage are terminated at the same peers. o Support other password based protocols (CHAP, MSCHAP, etc). o Support for carrying payloads of the Extensible Authentication Protocol (EAP). o Support fo carrying oither data exchanges within the tunnel. o Support standard extension of the inner data exchange. o Support online server certificate validation such as OCSP. 4. Protocol Specification 4.1. Overview The exchanges for step (1) are described in EAP-TLS [7]. For interoperability reasons the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA is mandatory to implement. Step (1) provides the functionality for fragmentation, session resumption, ciphersuite negotation and key derivation of the MSK and the EMSK. In step (2) Password-Authentication TLVs are exchanged. After an authentication protocol exchange the two peers MUST exchange Result TLVs and Crypto-Binding TLVs. If the Crypto-Binding TLV is invalid or missing, the other peer MUST assume an error. 4.2. Password Authentication Exchange All password authentication exchanges are encapsulated in Password- Authentication TLVs and must follow the "LABEL=Value" format. For instance, the server request will be in the form of "REQUEST=please enter your password." and client response will be in the form of "RESPONSE=\205." If the client or the server receive password request or response not in the format specified, it should fail the authentication. Zhou, et al. Expires January 2, 2008 [Page 4] Internet-Draft PP-EAP July 2007 An PP-EAP server implementation uses the following format if an authentication fails: "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc M= " where The "eeeeeeeeee" is the ASCII representation of a decimal error code corresponding to one of those listed below, though implementations should deal with codes not on this list gracefully. The error code need not be 10 digits long. 646 ERROR_RESTRICTED_LOGON_HOURS 647 ERROR_ACCT_DISABLED 648 ERROR_PASSWD_EXPIRED 649 ERROR_NO_DIALIN_PERMISSION 691 ERROR_AUTHENTICATION_FAILURE 709 ERROR_CHANGING_PASSWORD The "r" is a single character ASCII flag set to '1' if a retry is allowed, and '0' if not. When the authenticator sets this flag to '1' it disables short timeouts, expecting the peer to prompt the user for new credentials and resubmit the response. The is human-readable text in the appropriate character set and language [5]. The "cccccccccccccccccccccccccccccccc" is the ASCII representation of a hexadecimal challenge value. The error format described above is similar to what are defined in MSCHAPv2, except for the server challenge. So if the PP-EAP Server is distributing MSCHAPV2 exchanges to the backend inner method server, it can simply just return what the backend inner method server returns. In the case of connecting to an OTP or LDAP server, the PP-EAP Server can format the error message into this format and define some additional error codes. With the addition of the retry count, client can potentially prompt the user for new credentials to try again without restarts the password authentication from the beginning. Client will respond to the error code with another Password-Authentication TLV Response with either the new Username and Password or in case of other unrecoverable failures, an acknowledgement. Client use empty Password-Authentication TLV payload as an acknowledgment to the failure. After the TLS encryption channel is established and PP-EAP Authentication Phase 2 starts, the EAP Server sends Password- Authentication TLV, which contains a server challenge, often with a Zhou, et al. Expires January 2, 2008 [Page 5] Internet-Draft PP-EAP July 2007 displayable message for the user prompt. A peer may prompt the user for the user credentials, or decide to use the user credentials gained through some other means without prompting the user. The peer sends the user credentials back in the Password-Authentication TLV using the following format: "RESPONSE=johndoe\0secret" where "johndoe" is the actual user name and "secret" is the actual password. The NULL character is used to separate the user name and password. The inclusion of both username and secret in a single message is to achieve optimization by eliminating the inner method EAP-Identity and save an extra round trip by peer sending both use name and password in the first response packet. Once the PP-EAP Server receives the user credentials, it will continue to authenticate the user with internal or external user databases. Additional exchanges may occur between the PP-EAP server and peer to facilitate various user authentications. The PP-EAP Server might send additional challenges to user for additional information, such as password change or new pin mode. The peer may prompt the user again and send back the needed information in Password-Authentication TLV. The username and password, as well as server challenges may support non-ASCII characters. In this case, the input should be processed according to [8], using an appropriate stringprep [9] profile, and encoded in octets using UTF-8 encoding [10]. A preliminary version of a possible stringprep profile is described in [11]. This behavior is described in [8]. 4.3. Crypto-Binding To provide support for a cryptographic binding between the TLS tunnel establishment and the authentication running on top of the TLS record layer fresh and unique keying material of both exchanges need to be combined. Both the EAP peer and EAP server MUST compute the compound session keys using the procedure described below. The tunnel key (TK) is calculated using the first 40 octets of the (secret) key material generated as described in the EAP-TLS algorithm (see [7], Section 3.5). More explicitly, the TK is the first 40 octets of the PRF as defined in [7]: Zhou, et al. Expires January 2, 2008 [Page 6] Internet-Draft PP-EAP July 2007 PRF(master secret,"client EAP encryption", random) Where random is the concatenation of client_hello.random and server_hello.random The first 32 octets of the MSK provided by each successful inner EAP method The PRF algorithm is based on PRF+ from IKEv2 shown below ("|" denotes concatenation) K = Key, S = Seed, LEN = output length, represented as binary in a single octet. PRF (K,S,LEN) = T1 | T2 | T3 | T4 | ... where: T1 = HMAC-SHA1(K, S | LEN | 0x01) T2 = HMAC-SHA1 (K, T1 | S | LEN | 0x02) T3 = HMAC-SHA1 (K, T2 | S | LEN | 0x03) T4 = HMAC-SHA1 (K, T3 | S | LEN | 0x04) ... The compound session key (CSK) is derived on both the peer and EAP server. CSK = PRF+(TK, "Session Key Generating Function", OutputLength) The output length of the CSK must be at least 128 bytes. The first 64 octets are taken and the MSK and the second 64 octets are taken as the EMSK. The MSK and EMSK are described in [8]. 4.4. Packet Formats 4.4.1. PP-EAP Message Format A summary of the PP-EAP Request/Response packet format 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 | Flags | Ver | Message Length : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Message Length | Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhou, et al. Expires January 2, 2008 [Page 7] Internet-Draft PP-EAP July 2007 Code The code field is one octet in length defined as follows: 1 Request 2 Response Identifier The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet. The Identifier field in the Response packet MUST match the Identifier field from the corresponding request. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, Flags, Ver, Message Length, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Type TBD Flags 0 1 2 3 4 +-+-+-+-+-+ |L M S R R| +-+-+-+-+-+ L Length included; set to indicate the presence of the four- octet Message Length field M More fragments; set on all but the last fragment S PP-EAP start; set in an PP-EAP Start message R Reserved (must be zero) Ver This field contains the version of the protocol. This document describes version 1 (001 in binary) of PP-EAP. Message Length The Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the message that may be fragmented over the data fields of multiple packets. Zhou, et al. Expires January 2, 2008 [Page 8] Internet-Draft PP-EAP July 2007 Data When the Data field is present, it consists of an encapsulated TLS packet in TLS record format. A PP-EAP packet with Flags and Version fields, but with zero length data field, is used to indicate PP-EAP acknowledgement for either a fragmented message, a TLS Alert message or a TLS Finished message. 4.4.2. TLV Format TLVs are defined as described below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 0 - Optional TLV 1 - Mandatory TLV R Reserved, set to zero (0) TLV Type A 14-bit field, denoting the TLV type. Length The length of the Value field in octets. Value The value of the TLV. 4.4.3. Password-Authentication TLV The Password-Authentication TLV cantains password exchanges described in Section 4.2 and its payload is placed into the Value field of Section 4.4.2. Zhou, et al. Expires January 2, 2008 [Page 9] Internet-Draft PP-EAP July 2007 This TLV has the TLV Type (2). 4.4.4. Result TLV The Result TLV provides support for acknowledged success and failure messages for protected termination within PP-EAP. A Result TLV indicating failure MUST NOT be accompanied by the following TLVs: NAK, PAP TLV, or Crypto-Binding TLV. The Result TLV is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M Mandatory, set to one (1) R Reserved, set to zero (0) TLV Type 3 for Result TLV Length 2 Status The Status field is two octets. Values include: 1 Success 2 Failure 4.4.5. Crypto-Binding TLV The Crypto-Binding TLV is used prove that both peers participated in the sequence of authentications (specifically the TLS session and inner EAP methods that generate keys). Both the Binding Request (B1) and Binding Response (B2) use the same packet format. However the Sub-Type indicates whether it is B1 or B2. The Crypto-Binding TLV MUST be used to perform Cryptographic Binding after each successful authentication protocol exchange. Zhou, et al. Expires January 2, 2008 [Page 10] Internet-Draft PP-EAP July 2007 This message format is used for the Binding Request (B1) and also the Binding Response. This uses TLV type CRYPTO_BINDING_TLV. The Crypto-Binding TLV is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Version | Received Ver. | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Compound MAC ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhou, et al. Expires January 2, 2008 [Page 11] Internet-Draft PP-EAP July 2007 M 1 - Mandatory TLV R Reserved, set to zero (0) TLV Type 12 Length 56 Reserved Reserved, set to zero (0) Version Set to (0) Received Version Set to (0) Sub-Type The Sub-Type field is two octets. Possible values include: 0 - Binding Request 1 - Binding Response Nonce The Nonce field is 32 octets. It contains a 256 bit nonce that is temporally unique, used for compound MAC key derivation at each end. This is the S_NONCE for the B1 message and a C_NONCE for the B2 message. Compound MAC The Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). It is computed using the HMAC-SHA1-160 keyed MAC that provides 160 bits of output using the CMK key. The MAC is computed over the buffer created after concatenating these fields in the following order: Zhou, et al. Expires January 2, 2008 [Page 12] Internet-Draft PP-EAP July 2007 The entire Crypto-Binding TLV attribute with the MAC field zeroed out. 4.4.6. Vendor-Specific TLV The Vendor-Specific TLV is available to allow vendors to support their own extended attributes not suitable for general usage. A Vendor-Specific-TLV attribute can contain one or more TLVs, referred to as Vendor TLVs. The TLV-type of the Vendor-TLV will be defined by the vendor. All the Vendor TLVs inside a single Vendor- Specific TLV belong to the same vendor. Vendor TLVs may be optional or mandatory. Vendor TLVs sent in the protected success and failure packets MUST be marked as optional. The Vendor-Specific TLV is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor TLVs.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhou, et al. Expires January 2, 2008 [Page 13] Internet-Draft PP-EAP July 2007 M 1 - Mandatory TLV R Reserved, set to zero (0) TLV Type 7 Length >=4 Vendor-Id The Vendor-Id field is four octets. The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order. The Vendor- Id MUST be zero for TLVs that are not Vendor-Specific TLVs. For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code. Vendor TLVs This field is of indefinite length. It contains vendor-specific TLVs, in a format defined by the vendor. 5. Examples This section shows an example protocol exchanges. Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID1) -> <- EAP-Request/ EAP-Type=PP-EAP EAP-Response/ EAP-Type=PP-EAP (TLS client_hello)-> <- EAP-Request/ Zhou, et al. Expires January 2, 2008 [Page 14] Internet-Draft PP-EAP July 2007 EAP-Type=PP-EAP (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response/ EAP-Type=PP-EAP (TLS client_key_exchange, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=PP-EAP (TLS change_cipher_spec, TLS finished, PAP TLV TLS channel established TLVs sent within TLS channel PAP TLV {PAP-Request}-> // Protected termination <- Result TLV Crypto-Binding TLV (Nonce, B1_MAC) Result TLV Crypto-Binding TLV (Nonce, B2_MAC)-> TLS channel torn down (messages sent in cleartext) <- EAP-Success 6. Contributors This work is a joint effort of a design team established by the EMU Working Group in order to develop an password-based EAP method. The contributors include: Zhou, et al. Expires January 2, 2008 [Page 15] Internet-Draft PP-EAP July 2007 o Mohamad Badra o Pascal Urien o Charles Clancy o Madjid Nakhjiri o Joe Salowey o Jouni Malinen o Hannes Tschofenig o Hao Zhou o Ray Bell o Vijay Devarapalli 7. Security Considerations 7.1. Security Claims EAP security claims are defined in [RFC3748] Section 7.2.1. The security claims for PP-EAP are as follows: Auth. mechanism: Certificate-based server authentication and password-based peer authentication Ciphersuite negotiation: Yes Mutual authentication: Yes Integrity protection: Yes Replay protection: Yes Confidentiality: Yes Key derivation: Yes Key strength: See Note 1 below. Dictionary attack prot.: Yes Fast reconnect: Yes Crypt. binding: Yes Session independence: Yes Fragmentation: Yes Channel binding: No Zhou, et al. Expires January 2, 2008 [Page 16] Internet-Draft PP-EAP July 2007 [1] BCP 86 [RFC3766] Section 5 offers advice on the required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57]. 7.2. Server Certificate Validation Please refere to Section 5.3 and 5.4 described in EAP-TLS [7]. 8. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the PP- EAP protocol, in accordance with BCP 26, [RFC2434]. a new EAP method type will be assigned to the PP-EAP. The document defines a registry for PP-EAP TLV types, which may be assigned by Specification Required as defined in [RFC2434]. Section 4.2 defines the TLV types that initially populate the registry. A summary of the PP- TLV types is given below: 0 Reserved 1 Reserved 2 Password-Authentication TLV 3 Result TLV 7 Vendor-Specific TLV 12 Crypto-Binding TLV 9. Acknowledgments The protocol description in this document was inspired by PEAP, EAP- FAST and TTLS. The authors would therefore like to thank PEAP, EAP- FAST and TTLS authors for their work. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [2] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998. Zhou, et al. Expires January 2, 2008 [Page 17] Internet-Draft PP-EAP July 2007 [3] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000. [4] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992. [5] Zorn, G., "PPP LCP Internationalization Configuration Option", RFC 2484, January 1999. [6] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [7] Simon, D. and B. Aboba, "The EAP TLS Authentication Protocol", draft-simon-emu-rfc2716bis-10 (work in progress), June 2007. 10.2. Informative References [8] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [11] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. Authors' Addresses Hao Zhou (editor) Cisco Systems, Inc. 4125 Highlander parkway Richfield, Ohio 44286 USA Phone: Email: hzhou@cisco.com URI: http://www.cisco.com Zhou, et al. Expires January 2, 2008 [Page 18] Internet-Draft PP-EAP July 2007 Madjid Nakhjiri (editor) Huawei Phone: Email: mnakhjiri@huawei.com Hannes Tschofenig (editor) Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Zhou, et al. Expires January 2, 2008 [Page 19] Internet-Draft PP-EAP July 2007 Full Copyright Statement Copyright (C) The IETF Trust (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, THE IETF TRUST 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). Zhou, et al. Expires January 2, 2008 [Page 20]