One document matched: draft-zhou-emu-fast-gtc-00.txt
Network Working Group N. Cam-Winget
Internet-Draft H. Zhou
Intended status: Informational Cisco Systems
Expires: February 14, 2008 August 13, 2007
Basic Password Exchange within the Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST)
draft-zhou-emu-fast-gtc-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 February 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Cam-Winget & Zhou Expires February 14, 2008 [Page 1]
Internet-Draft EAP-FAST with EAP-GTC August 2007
Abstract
The flexible authentication via secure tunneling EAP method (EAP-
FAST) enables secure communication between a client 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 February 14, 2008 [Page 2]
Internet-Draft EAP-FAST with EAP-GTC August 2007
1. Introduction
EAP-FAST [RFC4851] is an EAP method that can be used to mutually
authenticate peer and server. This document describes the inner EAP
method used by EAP-FAST to carry out a basic password exchange, based
on EAP-GTC, to authenticate the user. EAP-GTC, described in
[RFC3748], was chosen due to its versatility and simplicity. Message
exchanges, including user credentials, are in clear text strings, but
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.
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 February 14, 2008 [Page 3]
Internet-Draft EAP-FAST with EAP-GTC August 2007
2. EAP-FAST GTC authentication
All EAP-GTC packets used in EAP-FAST must follow the "LABEL=Value"
format. For instance, the server request MUST be in the form of
"REQUEST=please enter your password." and peer response MUST be in
the form of "RESPONSE=user@example.com\0secret", where
"user@example.com" is the user identity, "secret" is the user
password, and "\0" is the NULL character to separate user name and
password. If the peer or the server receive EAP-GTC request or
response not in the format specified, it should fail the
authentication by sending 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, often with a 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
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 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 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
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 EAP-GTC Response.
If the EAP-FAST server finishes authentication, it will proceed to
Protected Termination as described in [RFC4851].
Cam-Winget & Zhou Expires February 14, 2008 [Page 4]
Internet-Draft EAP-FAST with EAP-GTC August 2007
An EAP-GTC server implementation within EAP-FAST uses the following
format if an authentication fails:
"E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc M=<msg> "
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.
Below 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
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 EAP 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].
The "cccccccccccccccccccccccccccccccc" is the ASCII representation of
a hexadecimal challenge value. This field is reserved for future
use.
The error format described above is similar to what are defined in
MSCHAPv2 [RFC2759], except for the 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. In the case of connecting to an OTP or LDAP
[RFC4511] server, the EAP-FAST Server can format the error message
into this format and define some additional error codes. With the
addition of the retry count, peer can potentially prompt the user for
new credentials to try again without restarts the EAP-FAST
authentication from the beginning. Peer will respond to the error
code with another EAP-GTC Response with either the new Username and
Password or in case of other unrecoverable failures, an empty EAP-GTC
packet for acknowledgement.
Cam-Winget & Zhou Expires February 14, 2008 [Page 5]
Internet-Draft EAP-FAST with EAP-GTC August 2007
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 username and password, as well as server challenges MAY support
non-ASCII characters. In this case, International username,
password, and messages are based on the use of Unicode characters,
encoded as UTF-8 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 doesn't generate session keys, the ISK used for crypto-
binding for EAP-FAST will be filled with all zeros.
Cam-Winget & Zhou Expires February 14, 2008 [Page 6]
Internet-Draft EAP-FAST with EAP-GTC August 2007
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 SHOULD authenticate the server
before disclosing its credentials. Since EAP-FAST with anonymous
provisioning does not authenticate the server, EAP-GTC MUST NOT be
used for anonymous provisioning mode. EAP-GTC can only be used with
EAP-FAST provisioning mode if server authentication is performed.
Cam-Winget & Zhou Expires February 14, 2008 [Page 7]
Internet-Draft EAP-FAST with EAP-GTC August 2007
4. IANA Considerations
EAP-GTC has already been assigned the value of 6.
The document defines a registry for EAP-GTC error code, which may be
assigned by Specification Required as defined in [RFC2434]. A
summary of the error code types defined so far is given below:
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
755 ERROR_PAC_I-ID-NO_MATCH
Cam-Winget & Zhou Expires February 14, 2008 [Page 8]
Internet-Draft EAP-FAST with EAP-GTC August 2007
5. Acknowledgments
The authors would like thank Joe Salowey, Amir Naftali for their
contributions of the problem space.
Cam-Winget & Zhou Expires February 14, 2008 [Page 9]
Internet-Draft EAP-FAST with EAP-GTC August 2007
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.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[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 February 14, 2008 [Page 10]
Internet-Draft EAP-FAST with EAP-GTC August 2007
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 February 14, 2008 [Page 11]
Internet-Draft EAP-FAST with EAP-GTC August 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).
Cam-Winget & Zhou Expires February 14, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 07:46:17 |