EMU H. Zhou, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track M. Nakhjiri, Ed. Expires: January 9, 2008 Huawei USA H. Tschofenig, Ed. Siemens Networks GmbH & Co KG July 8, 2007 PP-EAP - A Protected Password-Based EAP Method draft-zhou-emu-pp-eap-01.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 9, 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 exchange of password authentication mechanisms between a peer and an EAP server by using the Transport Layer Security (TLS) to establish a server-authenticated TLS tunnel. Within the tunnel, Zhou, et al. Expires January 9, 2008 [Page 1] Internet-Draft PP-EAP July 2007 Type-Length-Value (TLV) objects are used to convey password-based authentication between the peer and the EAP server. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 6 4.3. Phase 1: Tunnel Establishment . . . . . . . . . . . . . . 6 4.4. Phase 2: Password Authentication Exchange . . . . . . . . 7 4.4.1. Failure/ Error handling . . . . . . . . . . . . . . . 8 4.5. Protected Termination . . . . . . . . . . . . . . . . . . 9 4.6. Session Resumption . . . . . . . . . . . . . . . . . . . . 11 4.7. Determining Peer-Id and Server-Id . . . . . . . . . . . . 11 4.8. PP-EAP Session Identifier . . . . . . . . . . . . . . . . 12 4.9. Cryptographic Agility . . . . . . . . . . . . . . . . . . 12 4.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 4.11. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 12 4.11.1. PP-EAP Message Format . . . . . . . . . . . . . . . . 13 4.11.2. TLV Format . . . . . . . . . . . . . . . . . . . . . . 14 4.11.3. Password-Authentication TLV . . . . . . . . . . . . . 16 4.11.4. Result TLV . . . . . . . . . . . . . . . . . . . . . . 17 4.11.5. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 18 4.11.6. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 19 4.11.7. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 20 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 23 6.2. Server Certificate Validation . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Zhou, et al. Expires January 9, 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 Transport Layer Security (TLS) to establish a protected TLS tunnel and then exchange password-based authentication within the TLS tunnel. However, there are several reasons that prompt the work on a new password-based EAP method: 1. There is no standard track based password based EAP method. The EAP methods listed above are either expired Internet draft or Informational RFC. The Internet community and other standard bodies call for a standard track based password-based EAP method for better interoperability. 2. There is no standard mechanism and format defined for the inner data exchange, nor the mechanism to support cryptographic binding and extend the data exchanged inside the tunnel. 3. None of the existing EAP methods listed above supports cryptographic algorithm agility. The protocol defined in this document intends to address these limitations as a standard tracked based password-based EAP method. While in first version it only supports password-based authentication, it is designed with an extensibility framework so additional authentications and data exchanges can be added in the future without changing the basic protocol operation. 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 EAP [8] and EAP Keying Management Framework draft. Additional terms are defined below: Cryptographic Algorithm Agility Ability for a protocol to disable a cryptographic algorithm and negotiate a different algorithm when a new vulnerability specific to an algorithm is discovered, as well as ability to allow deployment of new cryptographic algorithms to be done incrementally. Zhou, et al. Expires January 9, 2008 [Page 3] Internet-Draft PP-EAP July 2007 Compound MAC Key (CMK) Key used to generate the compound Message Authentication Code (MAC) during cryptographic binding. Compound Session Key (CSK) Session key consists of the MSK and EMSK, derived from the combination of the Tunnel key and inner method key. Tunnel Key (TK) Key derived as part of the TLS Tunnel establishment and used to derive the CSK. 3. Design Requirements The following are mandatory requirements that guided the work on this EAP method: 1. Support secure transport of clear text password to support legacy user name and password databases, such as One-time Password (OTP) and LDAP. 2. Provide mutual authentication. 3. Provide resistance to offline dictionary attacks, man-in-the- middle attacks, and replay attacks. 4. Comply with RFC 3748, RFC 4017, EAP keying management framework draft (including MSK and EMSK generation). 5. Support user identity confidentiality for the peer. 6. Support cipher suite negotiation and cryptographic algorithm agility. 7. Support session resumption and avoid the need for use to re- enter the password every time). 8. Support protected result indication. 9. Support fragmentation and reassembly. 10. Support standard way of extending inner data exchanges to other than password-based authentications. The following requirements are optional and nice to have: o Support password/PIN changes. o Support cryptographic binding to make sure the inner authentication method and outer TLS tunnel exchange are terminated by 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 of carrying other data exchanges within the tunnel. An specific example for this type of data exchange is channel binding data. Zhou, et al. Expires January 9, 2008 [Page 4] Internet-Draft PP-EAP July 2007 o Support online server certificate validation such as OCSP. 4. Protocol Specification 4.1. Overview The network architectural model for PP-EAP usage is shown below: +----------+ +----------+ +----------+ +----------+ | | | | | | | User | | Peer |<---->| Authen- |<---->| PP-EAP |<---->| Database | | | | ticator | | Server | | Server | | | | | | | | | +----------+ +----------+ +----------+ +----------+ PP-EAP Architectural Model The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the PP-EAP server and user database server might be a single entity; the authenticator and PP-EAP server might be a single entity; or the functions of the authenticator, PP-EAP server, and user database server might be combined into a single physical device. For example, typical IEEE 802.11 deployments place the Authenticator in an access point (AP) while a Radius Server may provide the PP-EAP and user database server components. The above diagram illustrates the division of labor among entities in a general manner and shows how a distributed system might be constructed; however, actual systems might be realized more simply. The protocol consists of two phases, during the first phase, a TLS tunnel is established between the peer and the EAP server (PP-EAP server) 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 interactions. Phase 2 will occur only if establishment of a protected TLS tunnel in phase 1 was successful. Any data that is exchanged in Phase 2 is not vulnerable to active and passive man-in- the-middle attacks. In phase 2, Type-Length-Value (TLV) payloads for password-based authentication are exchanged. After a successful authentication protocol exchange the two peers MUST exchange Result TLVs and Crypto-Binding TLVs to ensure synchronized state and termination for both the TLS tunnel and inner authentication exchange. PP-EAP peer and server implementations MAY support user identity privacy. Disclosure of the username is avoided by utilizing a Zhou, et al. Expires January 9, 2008 [Page 5] Internet-Draft PP-EAP July 2007 privacy Network Access Identifier (NAI) [RFC4282] in the EAP- Response/Identity in the outer tunnel, and transmitting the real user identity within the TLS tunnel providing confidentiality. 4.2. Version Negotiation PP-EAP packets contain a 3-bit version field, following the Flags field, which enables PP-EAP implementations to be backward compatible with previous versions of the protocol. This specification documents the PP-EAP version 1 protocol; implementations of this specification MUST use a version field set to 1. Version negotiation proceeds as follows: In the first EAP-Request sent with EAP type=PP-EAP, the EAP server must set the version field to the highest supported version number. If the EAP peer supports this version of the protocol, it MUST respond with an EAP-Response of EAP type=PP-EAP, and the version number proposed by the PP-EAP server. If the EAP peer does not support this version, it responds with an EAP-Response of EAP type=PP-EAP and the highest supported version number. If the EAP server does not support the version number proposed by the EAP peer, it terminates the conversation. Otherwise the PP- EAP conversation continues. The version negotiation procedure guarantees that the EAP peer and server will agree to the latest version supported by both parties. If version negotiation fails, then use of PP-EAP will not be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed. The PP-EAP version is not protected by TLS; and hence can be modified in transit. In order to detect a modification of the PP-EAP version, the peers MUST exchange the PP-EAP version number received during version negotiation using the Crypto-Binding TLV. The receiver of the Crypto-Binding TLV MUST verify that the version received in the Crypto-Binding TLV matches the version sent by the receiver in the PP-EAP version negotiation. 4.3. Phase 1: Tunnel Establishment The exchanges for Phase 1 uses the EAP-TLS exchanges as described in EAP-TLS [7]. For interoperability reasons the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA is mandatory to implement. Phase 1 provides the functionality for fragmentation, session resumption, ciphersuite negotiation and resistance to offline dictionary attacks, Zhou, et al. Expires January 9, 2008 [Page 6] Internet-Draft PP-EAP July 2007 man-in-the-middle attacks, and replay attacks. However, the purpose of this specification is to provide a password-based method for client authentication. Thus, the EAP-TLS exchange MUST allow for the EAP peer and server to complete the TLS handshake using only server certificate, i.e. without requiring the peer to provide a certificate. Thus the exchange MUST be able to complete without the need for the peer to respond to a certificate-request from the server. There are scenarios where multi-factor authentication is required based on a client certificate authentication followed by a user password authentication. In such cases the EAP Peer MAY present the client certificate during phase 1 exchange. The EAP Peer MUST validate the server certificate during EAP-TLS exchanges, as it will send its password in the clear inside the TLS tunnel in Phase 2. Phase 2 will occur only if establishment of a protected TLS tunnel in phase 1 was successful. 4.4. Phase 2: Password Authentication Exchange 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 displayable message for the user prompt. All password authentication exchanges in phase 2 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 username and password" and client response will be in the form of "RESPONSE=test\0205." If the client or the server receive password request or response not in the format specified, it should fail the authentication. 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 "\0" is used to separate the user name and password. The inclusion of both user name and password in a single message is to achieve optimization by eliminating the optional Identity exchange 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 Zhou, et al. Expires January 9, 2008 [Page 7] Internet-Draft PP-EAP July 2007 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 EAP [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 [13]. This behavior is described in EAP [8]. 4.4.1. Failure/ Error handling As mentioned earlier, if the client or the server receive password request or response not in the format specified, it should fail the authentication. 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. Here are some pre-defined error codes: 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]. Zhou, et al. Expires January 9, 2008 [Page 8] Internet-Draft PP-EAP July 2007 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 user database server, it can simply just return what the backend user database 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, EAP peer can potentially prompt the user for new credentials to try again without restarts the password authentication from the beginning. EAP peer 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. EAP peer uses empty Password-Authentication TLV payload as an acknowledgment to the failure. 4.5. Protected Termination A successful PP-EAP Phase 2 conversation MUST always end in a successful Result TLV exchange. A PP-EAP server MAY initiate the Result TLV exchange without initiating any password authentication in PP-EAP Phase 2. After the final Result TLV exchange, the TLS tunnel is terminated and a clear text EAP-Success or EAP-Failure is sent by the server. The format of the Result TLV is described in Section 4.11.4. A server initiates a successful protected termination exchange by sending a Result TLV indicating success. The server MAY send the Result TLV along with a Crypto-Binding TLV. If the peer requires nothing more from the server it will respond with a Result TLV indicating success accompanied by a Crypto-Binding TLV if necessary. The server then tears down the tunnel and sends a clear text EAP- Success. To provide support for a cryptographic binding between the TLS tunnel establishment and the authentication running inside the TLS tunnel, fresh and unique keying material of both exchanges need to be combined. This means, the EAP peer and EAP server MUST compute compound session keys (CSK) that take the keying material from the initial TLS exchange and inner authentication into account. Furthermore, the peer and the server MUST exchange the Crypto-Binding TLVs including MAC signature that proves the knowledge of the keying material (compound MAC key, CMK) that are created as a result the successful completion of both TLS and the inner authentication exchanges. Details are described as follows: Zhou, et al. Expires January 9, 2008 [Page 9] Internet-Draft PP-EAP July 2007 As a result of the successful TLS tunnel establishment, a 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]: TK=PRF(master secret,"client EAP encryption", random) Where random is the concatenation of client_hello.random and server_hello.random The compound session key (CSK) is then calculated based on the knowledge of the tunnel key (TK), using the same PRF as that used in EAP-TLS specification [7]. Note that this provides better crypto- agility properties than the previous work in PEAPv2 or EAP-FAST where PRF+ from IKEv2 was used. We refer to MSK of the inner method as MSKi. When a legacy password exchange (e.g., OTP) is used, no MSK is generated. However, when an inner EAP method capable of MSK generation is used for password authentication, we refer to the MSK generated by the inner EAP method as MSKi. ISK0=First(32, MSK0) When no MSK is generated, the ISK0 is 32 zero octets. First (M, K) and Last (N, K) denote the first M octets, and the last N octets of a key K, respectively. IMCK0=PRF(TK, "Inner method compound keys", ISK0) S-IMCK0=First (40, IMCK0). CMK=Last(20, IMCK0) Where IMCK0 stands for Inner Method Compound key and S-IMCK is the shortened IMCK. The CMK is the compound MAC key used in generating the Crypto-Binding Compound MAC value sent in Crypto-Binding TLV Section 4.11.7. The Compound MAC computation is as follows: Compound-MAC = TLS-Hash( CMK, Crypto-Binding TLV ) where TLS-Hash is the TLS hash function negotiated in the TLS handshake. Zhou, et al. Expires January 9, 2008 [Page 10] Internet-Draft PP-EAP July 2007 The compound session key (CSK) is derived on both the peer and EAP server. CSK = PRF(S-IMCK0, "Session Key Generating Function") The output length of the CSK must be at least 128 octets. The first 64 octets are taken as the MSK and the second 64 octets are taken as the EMSK. The MSK and EMSK are described in [8]. MSK=First (64, CSK) EMSK=last (64, CSK) 4.6. Session Resumption PP-EAP session resumption is achieved in the same manner EAP-TLS achieves session resume. To support session resumption, the server and peer must minimally cache the SessionID, master secret, and ciphersuite. The peer attempts to resume a session by including a valid SessionID from a previous handshake in its ClientHello message. If the server finds a match for the SessionID and is willing to establish a new connection using the specified session state, the server will respond with the same SessionID and proceed with the phase 1 tunnel establishment based on a TLS abbreviated handshake. After a successful conclusion of the Phase 1 conversation, the conversation then continues directly to Phase 2 termination, bypassing the password user authentication. 4.7. Determining Peer-Id and Server-Id The Peer-Id and Server-Id may be determined based on the types of credentials used during either the PP-EAP tunnel creation or authentication within the tunnel. The Server-Id is determined by the subject or subjectAltName fields in the server certificate. As noted in [12]: The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension.... If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. Zhou, et al. Expires January 9, 2008 [Page 11] Internet-Draft PP-EAP July 2007 Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). The Peer-Id is obtained from the inner password authentication method. 4.8. PP-EAP Session Identifier The EAP session identifier is constructed using the random values provided by the peer and server during the TLS tunnel establishment. The Session-Id is defined as follows: Session-Id = PP_EAP_type || client_random || server_random PP-EAP_type = PP-EAP EAP type number (TBD) client_random = 32 octet nonce generated by the peer server_random = 32 octet nonce generated by the server 4.9. Cryptographic Agility Cryptographic agility is achieved using the PRF and hash functions defined in TLS. With TLS 1.2 or above, crypto-agility is supported so the hash, PRF and encryption algorithms used in TLS handshake and PP-EAP session key generation can all be negotiated. 4.10. Extensibility The protocol is designed with extensibility in mind. Although the first version only supports password-based authentication, the protocol can be extended in the following ways: o Additional TLVs can be defined to support exchanges of other type of authentications, such as CHAP, MSCHAP, even certificate-base or bio-based authentication. o Additional TLVs can also be defined to exchange arbitrary data exchange between the peer and the server. This can be used to support channel-binding etc. o Additional Vendor-Specific TLVs can be defined to support non- standard and experimental data exchange. All these can be achieved without changing the basic operation of the protocol including its session key generation and crypto-binding exchange. 4.11. Packet Formats Zhou, et al. Expires January 9, 2008 [Page 12] Internet-Draft PP-EAP July 2007 4.11.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 ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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| +-+-+-+-+-+ Zhou, et al. Expires January 9, 2008 [Page 13] Internet-Draft PP-EAP July 2007 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. 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.11.2. TLV Format The TLVs defined here are standard Type-Length-Value (TLV) objects. The TLV objects could be used to carry arbitrary parameters between EAP peer and EAP server within the protected TLS tunnel. TLVs are defined as described below. The fields are transmitted from left to right. Zhou, et al. Expires January 9, 2008 [Page 14] Internet-Draft PP-EAP July 2007 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. Allocated Types include: 0 Reserved 1 Reserved 2 Password-Authentication TLV 3 Result TLV 4 NAK TLV 7 Vendor-Specific TLV 12 Crypto-Binding TLV Length The length of the Value field in octets. Value The value of the TLV. The EAP peer may not necessarily implement all the TLVs supported by the EAP server. To allow for interoperability, TLVs are designed to allow an EAP server to discover if a TLV is supported by the EAP peer, using the NAK TLV. The mandatory bit in a TLV indicates whether support of the TLV is required. If the peer or server does not support a TLV marked mandatory, then it MUST send a NAK TLV in the response, and all the other TLVs in the message MUST be ignored. If an EAP peer or server finds an unsupported TLV that is marked as optional, it can ignore the unsupported TLV. It MUST NOT send an NAK TLV for a TLV that is not marked mandatory. Note that a peer or server may support a TLV with the mandatory bit Zhou, et al. Expires January 9, 2008 [Page 15] Internet-Draft PP-EAP July 2007 set, but may not understand the contents. The appropriate response to a supported TLV with content that is not understood is defined by the individual TLV specification. EAP implementations compliant with this specification MUST support TLV exchanges, as well as the processing of mandatory/optional settings on the TLV. Implementations conforming to this specification MUST support the following TLVs: Password-Authentication TLV Result TLV NAK TLV Vendor-Specific TLV Crypto-Binding TLV 4.11.3. Password-Authentication TLV The Password-Authentication TLV contains password exchanges described in Section 4.4 and its payload is placed into the Value field of Section 4.11.2. This TLV has the TLV Type (2). The password-Authentication 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhou, et al. Expires January 9, 2008 [Page 16] Internet-Draft PP-EAP July 2007 M 1 - Mandatory TLV R Reserved, set to zero (0) TLV Type 2 Length >=4 Value The password authentication request and response. 4.11.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, Password-Authentication 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 Zhou, et al. Expires January 9, 2008 [Page 17] Internet-Draft PP-EAP July 2007 Length 2 Status The Status field is two octets. Values include: 1 Success 2 Failure 4.11.5. NAK TLV The NAK TLV allows a peer to detect TLVs that are mandatory and not supported by the other peer. An PP-EAP packet can contain zero or more NAK TLVs. A NAK TLV should not be accompanied by other TLVs. A NAK TLV MUST NOT be sent in response to a message containing a Result TLV, instead a Result TLV of failure should be sent indicating failure. The NAK 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAK-Type | TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M Mandatory, set to one (1) R Reserved, set to zero (0) TLV Type 4 for NAK TLV Length >=6 Vendor-Id The Vendor-Id field is four octets, and contains the Vendor-Id of the TLV that was not supported. The high-order octet is 0 and the low-order three octets are the Structure of Management Information (SMI) Network Management Private Enterprise Code of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. Zhou, et al. Expires January 9, 2008 [Page 18] Internet-Draft PP-EAP July 2007 NAK-Type The NAK-Type field is two octets. The field contains the Type of the TLV that was not supported. A TLV of this Type MUST have been included in the previous packet. TLVs This field contains a list of zero or more TLVs, each of which MUST NOT have the mandatory bit set. These optional TLVs are for future extensibility to communicate why the offending TLV was determined to be unsupported. 4.11.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 9, 2008 [Page 19] 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. 4.11.7. Crypto-Binding TLV The Crypto-Binding TLV is used to prove that both the peer and server participated in the tunnel establishment and inner authentications. It also provides verification of the PP-EAP version negotiated before TLS tunnel establishment, see Section 4.2. The Crypto-Binding TLV MUST be included with the Result TLV to perform Cryptographic Binding after each successful inner authentication method. The Crypto-Binding TLV can be issued at other times as well. The Crypto-Binding TLV is valid only if the following checks pass: o The Crypto-Binding TLV version is supported o The Compound MAC verifies correctly o The received version in the Crypto-Binding TLV matches the version sent by the receiver during the EAP version negotiation Zhou, et al. Expires January 9, 2008 [Page 20] Internet-Draft PP-EAP July 2007 o The Sub-Type is set to the correct value If any of the above checks fails, then the TLV is invalid. An invalid Crypto-Binding TLV is a fatal error and is handled as described in Section 4.5. 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M Mandatory, set to (1) R Reserved, set to zero (0) TLV Type 12 for Crypto-Binding TLV Length 56 Reserved Reserved, set to zero (0) Version The Version field is a single octet, which is set to the version of Crypto-Binding TLV the EAP method is using. For an implementation compliant with this version of PP-EAP, the version number MUST be set to 1. Zhou, et al. Expires January 9, 2008 [Page 21] Internet-Draft PP-EAP July 2007 Received Version The Received Version field is a single octet and MUST be set to the EAP version number received during version negotiation. Note that this field only provides protection against downgrade attacks, where a version of EAP requiring support for this TLV is required on both sides. Sub-Type The Sub-Type field is one octet. Defined 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. The nonce in a request MUST have its least significant bit set to 0 and the nonce in a response MUST have the same value as the request nonce except the least significant bit MUST be set to 1. Compound MAC The Compound MAC field is 20 octets. The computation of the MAC is described in Section 4.5. 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/ EAP-Type=PP-EAP (TLS server_hello, TLS certificate, [TLS server_key_exchange,] Zhou, et al. Expires January 9, 2008 [Page 22] Internet-Draft PP-EAP July 2007 [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, Password-Authentication TLV (Challenge)) TLS channel established TLVs sent within TLS channel Password-Authentication TLV {Response}-> ... Additional Password-Authentication TLV exchanges // Protected termination <- Result TLV Crypto-Binding TLV Result TLV Crypto-Binding TLV-> TLS channel torn down (messages sent in cleartext) <- EAP-Success 6. Security Considerations 6.1. Security Claims EAP security claims are defined in EAP [8] Section 7.2.1. The security claims for PP-EAP are as follows: Zhou, et al. Expires January 9, 2008 [Page 23] Internet-Draft PP-EAP July 2007 Auth. mechanism: Certificate based, password based. Ciphersuite negotiation: Yes Mutual authentication: Yes Integrity protection: Yes, Any method executed within the PP-EAP tunnel is integrity protected. The cleartext EAP headers outside the tunnel are not integrity protected. Replay protection: Yes Confidentiality: Yes Key derivation: Yes Key strength: See Note 1 below. Dictionary attack prot.: Yes Fast reconnect: Yes Cryptographic binding: Yes Session independence: Yes Fragmentation: Yes Key Hierarchy: Yes Channel binding: No, but TLVs could be defined for this. Notes 1. BCP 86 [11] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [14]. 6.2. Server Certificate Validation Please refer to Section 5.3 and 5.4 described in EAP-TLS [7]. 7. 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.11.2 defines the TLV types that initially populate the registry. A summary of the PP- TLV types is given below: 0 Reserved 1 Reserved Zhou, et al. Expires January 9, 2008 [Page 24] Internet-Draft PP-EAP July 2007 2 Password-Authentication TLV 3 Result TLV 4 NAK TLV 7 Vendor-Specific TLV 12 Crypto-Binding TLV 8. 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: o Mohamad Badra o Ray Bell o Charles Clancy o Vijay Devarapalli o Jouni Malinen o Madjid Nakhjiri o Joe Salowey o Hannes Tschofenig o Pascal Urien o Hao Zhou 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 Zhou, et al. Expires January 9, 2008 [Page 25] Internet-Draft PP-EAP July 2007 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. [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., "The EAP TLS Authentication Protocol", draft-simon-emu-rfc2716bis-11 (work in progress), July 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] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [12] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [13] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. [14] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006. Zhou, et al. Expires January 9, 2008 [Page 26] Internet-Draft PP-EAP July 2007 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 Madjid Nakhjiri (editor) Huawei USA 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 9, 2008 [Page 27] 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 9, 2008 [Page 28]