doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc5421.txt b/doc/rfc/rfc5421.txt
new file mode 100644
index 0000000..dc51938
--- /dev/null
+++ b/doc/rfc/rfc5421.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                      N. Cam-Winget
+Request for Comments: 5421                                       H. Zhou
+Category: Informational                                    Cisco Systems
+                                                              March 2009
+
+
+       Basic Password Exchange within the Flexible Authentication
+   via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+IESG Note
+
+   EAP-FAST has been implemented by many vendors and it is used in the
+   Internet.  Publication of this specification is intended to promote
+   interoperability by documenting current use of existing EAP methods
+   within EAP-FAST.
+
+   The EAP method EAP-FAST-GTC reuses the EAP type code assigned to EAP-
+   GTC (6).  The reuse of previously assigned EAP Type Codes is
+   incompatible with EAP method negotiation as defined in RFC 3748.
+
+
+
+Cam-Winget & Zhou            Informational                      [Page 1]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   Since EAP-GTC does not support method-specific version negotiation,
+   the use of EAP-FAST-GTC is implied when used inside the EAP-FAST
+   tunnel during authentication.  This behavior may cause problems in
+   implementations where the use of another vendor's EAP-GTC is
+   required.  Since such support requires special case execution of a
+   method within a tunnel, it also complicates implementations that use
+   the same method code both within and outside of the tunnel method.
+   If EAP-FAST were to be designed today, these difficulties could be
+   avoided by utilization of unique EAP Type codes.  Given these issues,
+   assigned method types must not be re-used with different meaning
+   inside tunneled methods in the future.
+
+Abstract
+
+   The Flexible Authentication via Secure Tunneling Extensible
+   Authentication Protocol (EAP-FAST) method 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 ....................................................2
+      1.1. Specification Requirements .................................3
+   2. EAP-FAST GTC Authentication .....................................3
+   3. Security Considerations .........................................7
+      3.1. Security Claims ............................................7
+   4. IANA Considerations .............................................8
+   5. Acknowledgments .................................................9
+   6. References ......................................................9
+      6.1. Normative References .......................................9
+      6.2. Informative References .....................................9
+
+1.  Introduction
+
+   EAP-FAST [RFC4851] is an EAP method that can be used to mutually
+   authenticate a 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 cleartext 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 cleartext 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
+
+
+
+Cam-Winget & Zhou            Informational                      [Page 2]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   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 a 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].
+
+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"
+
+
+
+Cam-Winget & Zhou            Informational                      [Page 3]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   where "user@example.com" is the actual username and "secret" is the
+   actual password.  The NULL character "\0" is used to separate the
+   username 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 Initiator ID (I-ID)
+   [RFC5422] in the PAC-Opaque (Protected Access Credential) 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 prompt the peer for additional
+   information, such as a request for the next token or a new pin in the
+   one time password case, or a server failure packet to indicate an
+   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 an 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 implementations SHOULD display the error message to the user
+      and ask the user to try at a later time.
+
+
+
+
+
+
+
+
+Cam-Winget & Zhou            Informational                      [Page 4]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   o  647 ERROR_ACCT_DISABLED
+
+      Indicates that the requested account is disabled.  Peer
+      implementations 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 that the password has expired and a password change is
+      required.  Peer implementations SHOULD prompt the 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 implementations SHOULD display the error message
+      to the user, which helps the user to resolve the issue with the
+      administrator.
+
+   o  691 ERROR_AUTHENTICATION_FAILURE
+
+      Indicates that there was authentication failure due to an
+      incorrect username or password.  Based on the retry flag described
+      below, peer implementations MAY prompt the user again for a new
+      set of username and password or simply send back an empty
+      acknowledgment packet to acknowledge the failure and go into the
+      termination phase of the authentication session.
+
+   o  709 ERROR_CHANGING_PASSWORD
+
+      Indicates that the password change failed, most likely because the
+      new password fails to meet the password complexity policy.  Peer
+      implementations 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.  Based on the
+      retry flag described below, peer implementations MAY prompt the
+      user again for a new set of username and password or simply send
+      back an empty acknowledgment packet to acknowledge the failure and
+      go into the 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
+
+
+
+Cam-Winget & Zhou            Informational                      [Page 5]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   new credentials and to 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 pairs using
+   the space character as the separator.  The only value that may
+   contain the space character is the <msg> value, which is always the
+   last value pair in the failure packet.  The peer SHOULD ignore any
+   unknown label/value pair in the failure packet.
+
+   The error format described above is similar to what is defined in the
+   Microsoft Challenge Handshake Authentication Protocol version 2
+   (MSCHAPv2) [RFC2759], except for the omission of a server challenge.
+   So if the EAP-FAST server is distributing MSCHAPv2 exchanges to the
+   backend inner method server, it can simply return what the backend
+   inner method server returns less the server challenge.  In the case
+   of connecting to a one time password or Lightweight Directory Access
+   Protocol (LDAP) [RFC4511] server, the EAP-FAST server can translate
+   the error message into this format.  With the addition of the retry
+   count, the peer can potentially prompt the user for new credentials
+   to try again without restarting the EAP-FAST authentication from the
+   beginning.  The peer will respond to the error code with another EAP-
+   FAST-GTC Response packet with both the new username and password, or
+   in case of other unrecoverable failures, an empty EAP-FAST-GTC packet
+   for acknowledgement.  The peer uses empty EAP-FAST-GTC payload as an
+   acknowledgment of the unrecoverable failure.
+
+   If the EAP-FAST server finishes authentication for the 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 the 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 [RFC3629] and processed with a certain algorithm to
+
+
+
+
+
+Cam-Winget & Zhou            Informational                      [Page 6]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   ensure a canonical representation.  The username and password input
+   SHOULD be processed according to Section 2.4 of [RFC4282], and the
+   server challenges SHOULD be processed according to [RFC5198].
+
+   Since EAP-FAST-GTC does not generate session keys, the MSKi (Master
+   Session Key) used for crypto-binding for EAP-FAST will be filled with
+   all zeros.
+
+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 [RFC5422],
+   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: No.  However, such negotiation is provided
+                            by EAP-FAST for the outer authentication.
+   Mutual authentication:   No.  However, EAP-FAST provides server-side
+                            authentication.
+   Integrity protection:    No.  However, any method executed within the
+                            EAP-FAST tunnel is protected.
+   Replay protection:       See above.
+   Confidentiality:         See above.
+   Key derivation:          Keys are not generated, see Section 2.
+                            However, when used inside EAP-FAST, the
+                            outer method will provide keys.  See
+                            [RFC4851] for the properties of those keys.
+   Key strength:            See above.
+   Dictionary attack prot.: No.  However, when used inside the EAP-FAST
+                            tunnel, the protection provided by the TLS
+                            tunnel prevents an off-line dictionary
+                            attack.
+
+
+
+Cam-Winget & Zhou            Informational                      [Page 7]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   Fast reconnect:          No.  However, EAP-FAST provides a fast
+                            reconnect capability that allows the reuse
+                            of an earlier session authenticated by EAP-
+                            FAST-GTC.
+   Cryptographic binding:   No.  Given that no keys are generated, EAP-
+                            FAST-GTC or its use within EAP-FAST cannot
+                            provide a cryptographic assurance that no
+                            binding attack has occurred.  EAP-FAST-GTC
+                            is required only to run within a protected
+                            tunnel, but even the use of the same
+                            credentials in some other, unprotected
+                            context might lead to a vulnerability.  As a
+                            result, credentials used in EAP-FAST-GTC
+                            SHOULD NOT be used in other unprotected
+                            authentication mechanisms.
+   Session independence:    No.  However, EAP-FAST provides session
+                            independence.
+   Fragmentation:           No.  However, EAP-FAST provides support for
+                            this.
+   Key Hierarchy:           Not applicable.
+   Channel binding:         No, though EAP-FAST can be extended for
+                            this.
+
+4.  IANA Considerations
+
+   EAP-FAST-GTC uses the assigned value of 6 (EAP-GTC) for the EAP Type
+   in [RFC3748].
+
+   This 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
+
+
+
+
+
+Cam-Winget & Zhou            Informational                      [Page 8]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   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.
+
+5.  Acknowledgments
+
+   The authors would like thank Joe Salowey and Amir Naftali for their
+   contributions of the problem space, and Jouni Malinen, Pasi Eronen,
+   Jari Arkko, and Chris Newman for reviewing this document.
+
+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.
+
+   [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.
+
+   [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
+
+   [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            Informational                      [Page 9]
+
+RFC 5421                   EAP-FAST with GTC                  March 2009
+
+
+   [RFC5422]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
+              "Dynamic Provisioning Using Flexible Authentication via
+              Secure Tunneling Extensible Authentication Protocol (EAP-
+              FAST)", RFC 5422, March 2009.
+
+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            Informational                     [Page 10]
+