[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 5421

Network Working Group                                      N. Cam-Winget
Internet-Draft                                                   H. Zhou
Intended status: Informational                             Cisco Systems
Expires: May 5, 2009                                    November 1, 2008


 Basic Password Exchange within the Flexible Authentication via Secure
        Tunneling Extensible Authentication Protocol (EAP-FAST)
                       draft-zhou-emu-fast-gtc-05

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 May 5, 2009.

















Cam-Winget & Zhou          Expires May 5, 2009                  [Page 1]

Internet-Draft              EAP-FAST with GTC              November 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  . . . . . . . . . . . . . . . . . . .  8
     3.1.  Security Claims  . . . . . . . . . . . . . . . . . . . . .  8

   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9

   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10

   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13





















Cam-Winget & Zhou          Expires May 5, 2009                  [Page 2]

Internet-Draft              EAP-FAST with GTC              November 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-FAST-GTC, which is used to authenticate the
   peer through a basic password exchange.  EAP-FAST-GTC was developed
   to support using clear text passwords to authenticate to legacy user
   databases, to facilitate password change and to support one time
   password features such as new pin mode.  Message exchanges, including
   user credentials, are clear text strings transferred within the
   encrypted TLS tunnel and thus are considered secure.  For historical
   reasons, EAP-FAST-GTC uses EAP Type 6, originally allocated to EAP-
   GTC [RFC3748].  Note that EAP-FAST-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.  To
   avoid interference between these two methods, EAP-FAST-GTC MUST NOT
   be used outside an EAP-FAST tunnel, and EAP-GTC MUST NOT be used
   inside an EAP-FAST tunnel.  All EAP-FAST-GTC packets sent within the
   TLS tunnel must be encapsulated in EAP Payload TLVs, described in
   [RFC4851].

   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 May 5, 2009                  [Page 3]

Internet-Draft              EAP-FAST with GTC              November 2008


2.  EAP-FAST GTC Authentication

   All EAP-FAST-GTC packets inside EAP-FAST other than the empty
   acknowledgment packet MUST follow the "LABEL=Value" format.  All
   Labels are in ASCII text and SHALL NOT contain the space character.
   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-FAST-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-FAST-GTC
   Request, which contains a server challenge.  The server challenge is
   a displayable message for use by the peer to prompt the user.

   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-FAST-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
   [I-D.cam-winget-eap-fast-provisioning] 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



Cam-Winget & Zhou          Expires May 5, 2009                  [Page 4]

Internet-Draft              EAP-FAST with GTC              November 2008


   to facilitate various user authentications.  The EAP-FAST server
   might send additional challenges to prompt the peer for additional
   information, such as request for next token or new pin in the one
   time password case, or server failure packet to indicate error.  The
   peer displays the prompt to the user again and sends back the needed
   information in an EAP-FAST-GTC Response.  The exchange ends when a
   Result TLV is received.

   An EAP-FAST-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 is a complete list of predefined error codes:

   o  646 ERROR_RESTRICTED_LOGON_HOURS

      Indicates that access is attempted outside the allowed hours.
      Peer implementation SHOULD display the error message to the user
      and ask the user to try in a later time.

   o  647 ERROR_ACCT_DISABLED

      Indicates the requested account is disabled.  Peer implementation
      SHOULD display the error message to the user, which helps the user
      to resolve the issue with the administrator.

   o  648 ERROR_PASSWD_EXPIRED

      Indicates the password has expired and password change is
      required.  Peer implementation SHOULD prompt user for a new
      password and send back the new password in the peer response
      packet.

   o  649 ERROR_NO_DIALIN_PERMISSION

      Indicates that access has been denied due to lack of dial in
      permission.  Peer implementation SHOULD display the error message
      to the user, which helps the user to resolve the issue with the
      administrator.




Cam-Winget & Zhou          Expires May 5, 2009                  [Page 5]

Internet-Draft              EAP-FAST with GTC              November 2008


   o  691 ERROR_AUTHENTICATION_FAILURE

      Indicates authentication failure due to incorrect user name or
      password.  Base on the retry flag described below, peer
      implementation MAY prompt the user again for a new set of user
      name and password or simply send back an empty acknowledgment
      packet to acknowledge the failure and go into termination phase of
      the authentication session.

   o  709 ERROR_CHANGING_PASSWORD

      Indicates password change failed, most likely because the new
      password fails to meet the password complexity policy.  Peer
      implementation SHOULD display the error message and prompt the
      user again for the new password.

   o  755 ERROR_PAC_I-ID_NO_MATCH

      Indicates that the PAC used to establish the EAP-FAST session
      cannot be used to authenticate to this user account.  Base on the
      retry flag described below, peer implementation MAY prompt the
      user again for a new set of user name and password or simply send
      back an empty acknowledgment packet to acknowledge the failure and
      go into termination phase of the authentication session.

   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.  When the server sets this
   flag to '0' the peer SHOULD NOT prompt the user for new credentials
   to try again without restarting the EAP-FAST authentication from the
   beginning.

   The <msg> is human-readable ASCII text.  Current implementations only
   support ASCII text.

   The server failure packet can be broken into label/value pair using
   the space character as the separator.  The only value may contain the
   space character is the <msg> value, which is always the last value
   pair in the failure packet.  Peer SHOULD ignore any unknown label/
   value pair 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
   the case of connecting to an one time password or LDAP [RFC4511]



Cam-Winget & Zhou          Expires May 5, 2009                  [Page 6]

Internet-Draft              EAP-FAST with GTC              November 2008


   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-FAST-GTC Response packet with both
   the new user name and password or in case of other unrecoverable
   failures, an empty EAP-FAST-GTC packet for acknowledgement.  Peer
   uses empty EAP-FAST-GTC payload as an acknowledgment to the
   unrecoverable failure.

   If the EAP-FAST server finishes authentication for EAP-FAST-GTC inner
   method, it will proceed to Protected Termination as described in
   [RFC4851].  In the case of an unrecoverable EAP-FAST-GTC
   authentication failure, the EAP server can send an EAP-FAST-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 EAP-FAST-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 [RFC5198].

   Since EAP-FAST-GTC does not generate session keys, the MSKi used for
   crypto-binding for EAP-FAST will be filled with all zeros.





















Cam-Winget & Zhou          Expires May 5, 2009                  [Page 7]

Internet-Draft              EAP-FAST with GTC              November 2008


3.  Security Considerations

   The EAP-FAST-GTC method sends password information in the clear and
   MUST NOT be used outside of a protected tunnel providing strong
   protection such as the one provided by EAP-FAST.  Weak encryption
   such as, 40-bit encryption or NULL cipher, MUST NOT be used.  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-FAST-GTC MUST NOT be used as
   the inner method in this mode.  EAP-FAST-GTC MAY be used in EAP-FAST
   authentication and Server-Authenticated Provisioning Mode
   [I-D.cam-winget-eap-fast-provisioning], where the server is
   authenticated.  Since EAP-FAST-GTC requires the server to have access
   to the actual authentication secret, it is RECOMMENDED to vary the
   stored authentication validation data by domain so that a compromise
   of a server at one location does not compromise others.

3.1.  Security Claims

   This section provides the needed security claim requirement for EAP
   [RFC3748].

   Auth. mechanism:         Password based.
   Ciphersuite negotiation: Yes. Provided by the EAP-FAST Tunnel.
   Mutual authentication:   Yes. Peer is authenticated by the password
                            and server is authenticated by certificate
                            or shared secret.
   Integrity protection:    Yes, Any method executed within the EAP-FAST
                            tunnel is integrity protected.  The
                            cleartext EAP headers outside the tunnel are
                            not integrity protected.
   Replay protection:       Yes. Provided by the EAP-FAST Tunnel.
   Confidentiality:         Yes. Provided by the EAP-FAST Tunnel.
   Key derivation:          Yes. Provided by the EAP-FAST Tunnel.
   Key strength:            See Section 7.8 of [RFC4851].
   Dictionary attack prot.: Yes. Provided by the EAP-FAST Tunnel.
   Fast reconnect:          Yes.
   Cryptographic binding:   Yes. Provided by the EAP-FAST Tunnel.
   Session independence:    Yes. Provided by the EAP-FAST Tunnel.
   Fragmentation:           Yes. Provided by the EAP-FAST Tunnel.
   Key Hierarchy:           Yes. Provided by the EAP-FAST Tunnel.
   Channel binding:         No, but TLVs could be defined for this.









Cam-Winget & Zhou          Expires May 5, 2009                  [Page 8]

Internet-Draft              EAP-FAST with GTC              November 2008


4.  IANA Considerations

   EAP-FAST-GTC uses the assigned value of 6 (EAP-GTC) for the EAP Type
   in [RFC3748].

   The document defines a registry for EAP-FAST-GTC error codes when
   running inside EAP-FAST, named "EAP-FAST GTC Error Codes".  It may be
   assigned by Specification Required as defined in [RFC5226].  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

   No IANA registry will be created for Labels, as current
   implementations only support the Labels defined in this document and
   new Labels are not expected; if necessary, new Labels can be defined
   in documents updating this document.























Cam-Winget & Zhou          Expires May 5, 2009                  [Page 9]

Internet-Draft              EAP-FAST with GTC              November 2008


5.  Acknowledgments

   The authors would like thank Joe Salowey, Amir Naftali for their
   contributions of the problem space, and Jouni Malinen, Pasi Eronen,
   Jari Arkko, Chris Newman for reviewing this document.














































Cam-Winget & Zhou          Expires May 5, 2009                 [Page 10]

Internet-Draft              EAP-FAST with GTC              November 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.

   [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.

   [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.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, March 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

6.2.  Informative References

   [I-D.cam-winget-eap-fast-provisioning]
              Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
              "Dynamic Provisioning using Flexible Authentication via
              Secure Tunneling  Extensible Authentication Protocol (EAP-
              FAST)", draft-cam-winget-eap-fast-provisioning-10 (work in
              progress), October 2008.

   [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 May 5, 2009                 [Page 11]

Internet-Draft              EAP-FAST with GTC              November 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 May 5, 2009                 [Page 12]

Internet-Draft              EAP-FAST with GTC              November 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 May 5, 2009                 [Page 13]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/