Network Working Group N. Cam-Winget Internet-Draft H. Zhou Intended status: Informational Cisco Systems Expires: October 6, 2008 April 4, 2008 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) draft-zhou-emu-fast-gtc-03 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 October 6, 2008. Cam-Winget & Zhou Expires October 6, 2008 [Page 1]
Internet-Draft EAP-FAST with GTC April 2008 Abstract The flexible authentication via secure tunneling EAP method (EAP- FAST) enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within this tunnel a basic password exchange, based on the generic token card method (EAP-GTC), may be executed to authenticate the peer. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification Requirements . . . . . . . . . . . . . . . . 3 2. EAP-FAST GTC Authentication . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Cam-Winget & Zhou Expires October 6, 2008 [Page 2]
Internet-Draft EAP-FAST with GTC April 2008 1. Introduction EAP-FAST [RFC4851] is an EAP method that can be used to mutually authenticate peer and server. This document describes the EAP-FAST inner EAP method, EAP-GTC, which is used to authenticate the peer through a basic password exchange. EAP-GTC, described in [RFC3748], was chosen due to its versatility and simplicity. Message exchanges, including user credentials, are clear text strings transferred within the encrypted TLS tunnel and thus are considered secure. All EAP-GTC packets sent within the TLS tunnel must be encapsulated in EAP Payload TLVs, described in [RFC4851]. Note that EAP-GTC payloads used in EAP-FAST require specific formatting and therefore will not necessarily be compatible with EAP-GTC mechanisms used outside of EAP-FAST. It is assumed that reader of this document is familiar with EAP-FAST [RFC4851]. 1.1. Specification Requirements 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]. Cam-Winget & Zhou Expires October 6, 2008 [Page 3]
Internet-Draft EAP-FAST with GTC April 2008 2. EAP-FAST GTC Authentication All EAP-GTC packets inside EAP-FAST other than the empty acknowledgment packet MUST follow the "LABEL=Value" format. Currently, three Labels are defined: o "CHALLENGE", the server request packet MUST be in the form of "CHALLENGE=Value", where Value is the server challenge, such as "please enter your password." o "RESPONSE", the peer response packet MUST be in the form of "RESPONSE=Value", where Value is the peer response. o "E", the server failure packet MUST be in the form of "E=Value", where Value is the error message generated by the server. If the peer or the server receives an EAP-GTC request or response that is not in the format specified above, it SHOULD fail the authentication by sending a Result TLV with a failure. After the TLS encryption tunnel is established and EAP-FAST Authentication Phase 2 starts, the EAP Server sends an EAP-GTC Request, which contains a server challenge. This EAP-GTC Request will often be accompanied with a displayable message for use as 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 EAP-GTC Response using the following format: "RESPONSE=user@example.com\0secret" where "user@example.com" 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 username and password are included in a single message in the first response packet as an optimization by eliminating the inner method EAP-Identity exchange to save an extra round trip. Once the EAP-FAST server receives the user credentials, it SHOULD first validate the user identity with the I-ID in the PAC-Opaque and if it matches, it will continue to authenticate the user with internal or external user databases. Additional exchanges MAY occur between the EAP-FAST server and peer to facilitate various user authentications. The EAP-FAST server Cam-Winget & Zhou Expires October 6, 2008 [Page 4]
Internet-Draft EAP-FAST with GTC April 2008 might send additional challenges to the peer for additional information, such as password change or new pin mode in the OTP [RFC2289] case. The peer MAY prompt the user again and send back the needed information in an EAP-GTC Response. An EAP-GTC server implementation within EAP-FAST uses the following format to indicate error if an authentication fails: "E=eeeeeeeeee R=r M=<msg>" where The "eeeeeeeeee" is the ASCII representation of a decimal error code corresponding to one of those listed below, though peer implementations SHOULD deal with codes not on this list gracefully. The error code need not be 10 digits long. Below are some pre-defined error codes: o 646 ERROR_RESTRICTED_LOGON_HOURS o 647 ERROR_ACCT_DISABLED o 648 ERROR_PASSWD_EXPIRED o 649 ERROR_NO_DIALIN_PERMISSION o 691 ERROR_AUTHENTICATION_FAILURE o 709 ERROR_CHANGING_PASSWORD o 755 ERROR_PAC_I-ID-NO_MATCH The "r" is a single character ASCII flag set to '1' if a retry is allowed, and '0' if not. When the server sets this flag to '1' it disables short timeouts, expecting the peer to prompt the user for new credentials and resubmit the response. The <msg> is human-readable text in the appropriate character set and language [RFC2484]. Peer SHOULD ignore any unknown label in the failure packet. The error format described above is similar to what are defined in MSCHAPv2 [RFC2759], except for the omission of server challenge. So if the EAP-FAST Server is distributing MSCHAPV2 exchanges to the backend inner method server, it can simply just return what the backend inner method server returns less the server challenge. In Cam-Winget & Zhou Expires October 6, 2008 [Page 5]
Internet-Draft EAP-FAST with GTC April 2008 the case of connecting to an OTP or LDAP [RFC4511] server, the EAP- FAST Server can format the error message into this format. With the addition of the retry count, peer can potentially prompt the user for new credentials to try again without restarting the EAP-FAST authentication from the beginning. Peer will respond to the error code with another EAP-GTC Response packet with both the new user name and password or in case of other unrecoverable failures, an empty EAP-GTC packet for acknowledgement. Peer uses empty EAP-GTC payload as an acknowledgment to the unrecoverable failure. If the EAP-FAST server finishes authentication for EAP-GTC inner method, it will proceed to Protected Termination as described in [RFC4851]. In the case of an unrecoverable EAP-GTC authentication failure, the EAP server can send a GTC error code as described above, along with the Result TLV for protected termination. This way, no extra round trips will occur. The peer can acknowledge the GTC failure as well as the Result TLV within the same EAP-FAST packet. Once server receives the acknowledgement, the TLS tunnel will be torn down and a clear text EAP-Failure will be sent. The user name and password, as well as server challenges MAY support non-ASCII characters. In this case, international user name, password, and messages are based on the use of Unicode characters, encoded as UTF-8 [RFC3629] and processed with a certain algorithm to ensure a canonical representation. The input should be processed according to [RFC4282] Section 2.4. Since EAP-GTC does not generate session keys, the ISK used for crypto-binding for EAP-FAST will be filled with all zeros. Cam-Winget & Zhou Expires October 6, 2008 [Page 6]
Internet-Draft EAP-FAST with GTC April 2008 3. Security Considerations The EAP-GTC method sends password information in the clear and MUST NOT be used outside of a protected tunnel such as the one provided by EAP-FAST. In addition, the peer MUST authenticate the server before disclosing its credentials. Since EAP-FAST Server-Unauthenticated Provisioning Mode does not authenticate the server, EAP-GTC MUST NOT be used as the inner method in this mode. EAP-GTC MAY be used in EAP-FAST authentication and Server-Authenticated Provisioning Mode, where the server is authenticated. Cam-Winget & Zhou Expires October 6, 2008 [Page 7]
Internet-Draft EAP-FAST with GTC April 2008 4. IANA Considerations EAP-GTC has already been assigned the value of 6 for the EAP Type in [RFC3748]. The document defines a registry for EAP-GTC error codes when running inside EAP-FAST, which may be assigned by Specification Required as defined in [RFC2434]. A summary of the error codes defined so far is given below: o 646 ERROR_RESTRICTED_LOGON_HOURS o 647 ERROR_ACCT_DISABLED o 648 ERROR_PASSWD_EXPIRED o 649 ERROR_NO_DIALIN_PERMISSION o 691 ERROR_AUTHENTICATION_FAILURE o 709 ERROR_CHANGING_PASSWORD o 755 ERROR_PAC_I-ID-NO_MATCH Cam-Winget & Zhou Expires October 6, 2008 [Page 8]
Internet-Draft EAP-FAST with GTC April 2008 5. Acknowledgments The authors would like thank Joe Salowey, Amir Naftali for their contributions of the problem space, and Jouni Malinen for reviewing this document. Cam-Winget & Zhou Expires October 6, 2008 [Page 9]
Internet-Draft EAP-FAST with GTC April 2008 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007. 6.2. Informative References [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- Time Password System", RFC 2289, February 1998. [RFC2484] Zorn, G., "PPP LCP Internationalization Configuration Option", RFC 2484, January 1999. [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000. [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. Cam-Winget & Zhou Expires October 6, 2008 [Page 10]
Internet-Draft EAP-FAST with GTC April 2008 Authors' Addresses Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US Email: ncamwing@cisco.com Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US Email: hzhou@cisco.com Cam-Winget & Zhou Expires October 6, 2008 [Page 11]
Internet-Draft EAP-FAST with GTC April 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Cam-Winget & Zhou Expires October 6, 2008 [Page 12]
