diff --git a/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt b/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
new file mode 100644
index 000000000..54f093802
--- /dev/null
+++ b/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
@@ -0,0 +1,673 @@
+
+
+
+NETWORK WORKING GROUP                                           S. Emery
+Internet-Draft                                          Sun Microsystems
+Updates: 4121 (if approved)                                July 14, 2008
+Intended status: Standards Track
+Expires: January 15, 2009
+
+
+        Kerberos Version 5 GSS-API Channel Binding Hash Agility
+              draft-ietf-krb-wg-gss-cb-hash-agility-04.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 15, 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 1]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+Abstract
+
+   Currently, channel bindings are implemented using a MD5 hash in the
+   Kerberos Version 5 Generic Security Services Application Programming
+   Interface (GSS-API) mechanism [RFC4121].  This document updates
+   RFC4121 to allow the channel binding restriction to be lifted using
+   algorithms negotiated based on Kerberos crypto framework as defined
+   in RFC3961.  In addition, because this update makes use of the last
+   extensible field in the Kerberos client-server exchange message,
+   extensions are defined to allow future protocol extensions.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
+   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 2]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+1.  Introduction
+
+   With the recently discovered weaknesses in the MD5 hash algorithm
+   there is a need to use stronger hash algorithms.  Kerberos Version 5
+   Generic Security Services Application Programming Interface (GSS-API)
+   mechanism [RFC4121] uses MD5 to calculate channel binding verifiers.
+   This document specifies an update to the mechanism that allows it to
+   create channel binding information based on negotiating algorithms
+   securely.  This will allow deploying new algorithms incrementally
+   without break interoperability with older implementations, when new
+   attacks arise in the future.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 3]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+2.  Conventions Used in This Document
+
+   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].
+
+   The term "little endian order" is used for brevity to refer to the
+   least-significant-octet-first encoding, while the term "big endian
+   order" is for the most-significant-octet-first encoding.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 4]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+3.  Channel binding hash agility
+
+   When generating a channel binding verifier, Bnd, a hash is computed
+   from the channel binding fields.  Initiators MUST populate the Bnd
+   field in order to maintain interoperability with existing acceptors.
+   In addition, initiators MUST populate the extension field, Exts, with
+   TYPED-DATA as defined in [RFC4120].  All fields before Exts, do not
+   change from what is described in [RFC4121], they are listed for
+   convenience.  The 0x8003 GSS checksum MUST have the following
+   structure:
+
+      Octet     Name       Description
+      -----------------------------------------------------------------
+      0..3      Lgth       Number of octets in Bnd field;  Represented
+                            in little-endian order;  Currently contains
+                            hex value 10 00 00 00 (16).
+      4..19     Bnd        Channel binding information, as described in
+                            section 4.1.1.2 [RFC4121].
+      20..23    Flags      Four-octet context-establishment flags in
+                            little-endian order as described in section
+                            4.1.1.1 [RFC4121].
+      24..25    DlgOpt     The delegation option identifier (=1) in
+                            little-endian order [optional].  This field
+                            and the next two fields are present if and
+                            only if GSS_C_DELEG_FLAG is set as described
+                            in section 4.1.1.1 [RFC4121].
+      26..27    Dlgth      The length of the Deleg field in
+                            little-endian order [optional].
+      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
+      n..last   Exts       Extensions
+
+      where Exts is the concatenation of zero, one or more individual
+      extensions, each of which consists of, in order:
+
+      type -- big endian order unsigned integer, 32-bits, which contains
+              the type of extension
+      data -- octet string of extension information
+
+      If multiple extensions are present then there MUST be at most one
+      instance of a given extension type.
+
+   When channel binding is used the Exts MUST include the following
+   extension:
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 5]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+      data-type 0x00000000
+
+      data-value
+
+         The output obtained by applying the Kerberos V get_mic()
+         operation [RFC3961], using the sub-session key from the
+         authenticator and key usage number 43, to the channel binding
+         data as described in [RFC4121], section 4.1.1.2 (using get_mic
+         instead of MD5).
+
+   Initiators that are unwilling to use a MD5 hash of the channel
+   bindings MUST set the Bnd field to sixteen octets of hex value FF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 6]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+4.  Security considerations
+
+   Initiators do not know if the acceptor had ignored channel bindings
+   or whether it validated the MD5 hash of the channel bindings
+   [RFC4121].
+
+   Ultimately, it is up to the application whether to use channel
+   binding or not.  This is dependent upon the security policy of these
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 7]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+5.  IANA Considerations
+
+   The IANA is hereby requested to create a new registry of "Kerberos V
+   GSS-API mechanism extension types" with four-field entries (type
+   number, type name, description, and normative reference) and,
+   initially, a single registration: 0x00000000, "Channel Binding MIC,"
+   "Extension for the verifier of the channel bindings," <this RFC>.
+
+   Using the guidelines for allocation as described in [RFC5226], type
+   number assignments are as follows:
+
+      0x00000000 - 0x000003FF IETF Consensus
+
+      0x00000400 - 0xFFFFF3FF Specification Required
+
+      0xFFFFF400 - 0xFFFFFFFF Private Use
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 8]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+6.  Acknowledgements
+
+   Larry Zhu helped in the review of this document overall and provided
+   the suggestions of typed-data.
+
+   Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
+   fields be populated simultaneously.
+
+   Nicolas Williams and Jeffrey Hutzelman had also suggested a number
+   changes to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 9]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009               [Page 10]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+Author's Address
+
+   Shawn Emery
+   Sun Microsystems
+   500 Eldorado Blvd
+   M/S UBRM05-171
+   Broomfield, CO  80021
+   US
+
+   Email: shawn.emery@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009               [Page 11]
+
+Internet-Draft        Channel Binding Hash Agility             July 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.
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009               [Page 12]
+
+
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt
new file mode 100644
index 000000000..7c4c5a365
--- /dev/null
+++ b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt
@@ -0,0 +1,1064 @@
+
+
+
+NETWORK WORKING GROUP                                         K. Raeburn
+Internet-Draft                                                       MIT
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: January 15, 2009                                  July 14, 2008
+
+
+ Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm
+                               Referrals
+                draft-ietf-krb-wg-kerberos-referrals-11
+
+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 15, 2009.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2008).
+
+Abstract
+
+   The memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path.  The clients will use this
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 1]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   referral information to reach the realm of the target principal and
+   then receive the ticket.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
+   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
+   5.  Enterprise Principal Name Type . . . . . . . . . . . . . . . .  5
+   6.  Name Canonicalization  . . . . . . . . . . . . . . . . . . . .  6
+   7.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  9
+   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 12
+   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 12
+   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13
+   12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 13
+   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+     14.1.  Shared-password case  . . . . . . . . . . . . . . . . . . 14
+     14.2.  Preauthentication data  . . . . . . . . . . . . . . . . . 14
+   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
+   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     16.1.  Normative References  . . . . . . . . . . . . . . . . . . 15
+     16.2.  Informative References  . . . . . . . . . . . . . . . . . 15
+   Appendix A.  Compatibility with Earlier Implementations of
+                Name Canonicalization . . . . . . . . . . . . . . . . 15
+   Appendix B.  Document history [REMOVE BEFORE PUBLICATION]  . . . . 17
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
+   Intellectual Property and Copyright Statements . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 2]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [RFC4120], use principal names constructed from a known
+   user or service name and realm.  A service name is typically
+   constructed from a name of the service and the DNS host name of the
+   computer that is providing the service.  Many existing deployments of
+   Kerberos use a single Kerberos realm where all users and services
+   would be using the same realm.  However in an environment where there
+   are multiple trusted Kerberos realms, the client needs to be able to
+   determine what realm a particular user or service is in before making
+   an AS or TGS request.  Traditionally this requires client
+   configuration to make this possible.
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request.  However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an RFC 822 style email name.  This document describes a
+   mechanism that would allow a user to specify a user principal name
+   that is an alias for the user's Kerberos principal name.  In practice
+   this would be the name that the user specifies to obtain a TGT from a
+   Kerberos KDC.  The user principal name no longer has a direct
+   relationship with the Kerberos principal or realm.  Thus the
+   administrator is able to move the user's principal to other realms
+   without the user having to know that it happened.
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm.  To do this requires that the client
+   be able to determine what realm the target service principal is in
+   before making the TGS request.  Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  The user-supplied host name or its domain component
+   is looked up in this table (often using the result of some form of
+   host name lookup performed with insecure DNS queries, in violation of
+   [RFC4120]).  The corresponding realm is then used to complete the
+   target service principal name.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+   the environment.
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 3]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   organization (remote server).  The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization.  Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name.  This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name.  The administrator in the local realm could give that
+   remote server an identity in the local realm and then have that
+   remote server maintain a separate secret for each alias it is known
+   as.  Alternatively the administrator could arrange to have the local
+   realm issue a referral to the remote realm and notify the requesting
+   client of the server's remote name that should be used in order to
+   request a ticket.
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and allow the KDC to
+   determine the trusted realm authentication path by being able to
+   generate referrals to other realms in order to locate principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1. Client referrals, in which the client doesn't know which realm
+      contains a user account.
+   2. Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+
+2.  Conventions Used in This Document
+
+   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].
+
+
+3.  Requesting a Referral
+
+   In order to request referrals as defined in later sections, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 4]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+                   -- other KDCOptions values omitted
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [RFC4120].
+
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship.  The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm.  This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+                      EXAMPLE.COM
+                      /        \
+                     /          \
+          ADMIN.EXAMPLE.COM  DEV.EXAMPLE.COM
+
+   In this configuration, all users in the EXAMPLE.COM enterprise could
+   have principal names such as alice@EXAMPLE.COM, with the same realm
+   portion.  In addition, servers at EXAMPLE.COM should be able to have
+   DNS host names from any DNS domain independent of what Kerberos realm
+   their principals reside in.
+
+
+5.  Enterprise Principal Name Type
+
+   The NT-ENTERPRISE type principal name contains one component, a
+   string of realm-defined content, which is intended to be used as an
+   alias for another principal name in some realm in the enterprise.  It
+   is used for conveying the alias name, not for the real principal
+   names within the realms, and thus is only useful when name
+   canonicalization is requested.
+
+   The intent is to allow unification of email and security principal
+   names.  For example, all users at EXAMPLE.COM may have a client
+   principal name of the form "joe@EXAMPLE.COM" even though the
+   principals are contained in multiple realms.  This global name is
+   again an alias for the true client principal name, which indicates
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 5]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   what realm contains the principal.  Thus, accounts "alice" in the
+   realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as
+   "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
+
+   This utilizes a new principal name type, as the KDC-REQ message only
+   contains a single client realm field, and the realm portion of this
+   name corresponds to the Kerberos realm with which the request is
+   made.  Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a
+   single component in the client name field of the AS-REQ message, with
+   a name type of NT-ENTERPRISE [RFC4120] (and the local realm name).
+   The KDC will recognize this name type and then transform the
+   requested name into the true principal name if the client account
+   resides in the local realm.  The true principal name can have a name
+   type different from the requested name type.  Typically the true
+   principal name will be a NT-PRINCIPAL [RFC4120].
+
+
+6.  Name Canonicalization
+
+   A service or account may have multiple principal names.  For example,
+   if a host is known by multiple names, host-based services on it may
+   be known by multiple names in order to prevent the client from
+   needing a secure directory service to determine the correct hostname
+   to use.  In order that the host should not need to be updated
+   whenever a new alias is created, the KDC may provide the mapping
+   information to the client in the credential acquisition process.
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client and server principal names and types in the AS response and
+   ticket returned from the name type of the client name in the request.
+   In a TGS exchange, the server principal name and type may be changed.
+
+   If the client principal name is changed in an AS exchange, the KDC
+   must include a mandatory PA-DATA object authenticating the client
+   name mapping:
+
+   ClientReferralInfo ::= SEQUENCE {
+     requested-name  [0] PrincipalName,
+     mapped-name     [1] PrincipalName,
+     ...
+   }
+   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
+     names          [0] ClientReferralInfo,
+     canon-checksum [1] Checksum
+   }
+
+   The canon-checksum field is computed over the DER encoding of the
+   names sequences, using the AS reply key and a key usage value of
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 6]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   (TBD).
+
+   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
+   not included.  If the client name is changed, and the PA-CLIENT-
+   CANONICALIZED field does not exist, or the checksum cannot be
+   verified, or the requested-name field doesn't match the client name
+   in the originally-transmitted request, the client should discard the
+   response.
+
+   For example the AS request may specify a client name of "bob@
+   EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
+   option set and the KDC will return with a client name of "104567" as
+   a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT-
+   ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the
+   NT-UID "104567" principal as the mapped-name.
+
+   (It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out of band mechanisms.)
+
+   If the server name is changed, a PA-SERVER-REFERRAL preauth data
+   entry MUST be supplied by the KDC and validated by the client.
+
+   In order to enable one party in a user-to-user exchange to confirm
+   the identity of another when only the alias is known, the KDC MAY
+   include the following authorization data element, wrapped in AD-KDC-
+   ISSUED, in the initial credentials and copy it from a ticket-granting
+   ticket into additional credentials:
+
+   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
+     login-aliases  [0] SEQUENCE(1..MAX) OF PrincipalName,
+   }
+
+   The login-aliases field lists one or more of the aliases the
+   principal may have.
+
+   The recipient of this authenticator must check the AD-LOGIN-ALIAS
+   names, if present, in addition to the normal client name field,
+   against the identity of the party with which it wishes to
+   authenticate; either should be allowed to match.  (Note that this is
+   not backwards compatible with [RFC4120]; if the server side of the
+   user-to-user exchange does not support this extension, and does not
+   know the true principal name, authentication may fail if the alias is
+   sought in the client name field.)
+
+   The use of AD-KDC-ISSUED authorization data elements in cross-realm
+   cases has not been well explored at this writing; hence we will only
+   specify the inclusion of this data in the one-realm case.  The alias
+   information SHOULD be dropped in the general cross-realm case.
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 7]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   However, a realm MAY implement a policy of accepting and re-signing
+   (wrapping in a new AD-KDC-ISSUED element) alias information provided
+   by certain trusted realms, in the cross-realm ticket-granting
+   service.
+
+   The canonical principal name for an alias may not be in the form of a
+   ticket-granting service name, as (in a case of server name
+   canonicalization) that would be construed as a case of cross-realm
+   referral, described below.
+
+
+7.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine.  In the case of the name alice@EXAMPLE.COM, the
+   client MAY optimistically choose to send the request to EXAMPLE.COM.
+   The realm in the AS-REQ is always the name of the realm that the
+   request is for as specified in [RFC4120].
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply structure with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC may look up the
+   client principal name using some kind of name service or directory
+   service.  If this lookup is unsuccessful, it MUST return the error
+   KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120].  If the lookup is successful,
+   it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the
+   error message the crealm field will contain either the true realm of
+   the client or another realm that MAY have better information about
+   the client's true realm.  The client SHALL NOT use the cname returned
+   in this error message.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message corresponding to the first request.  (The
+   client realm name will be updated in the new request to refer to this
+   new realm.)  The client SHOULD repeat these steps until it finds the
+   true realm of the client.  To avoid infinite referral loops, an
+   implementation should limit the number of referrals.  A suggested
+   limit is 5 referrals before giving up.
+
+   Since the same client name is sent to the referring and referred-to
+   realms, both realms must recognize the same client names.  In
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 8]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   particular, the referring realm cannot (usefully) define principal
+   name aliases that the referred-to realm will not know.
+
+   The true principal name of the client, returned in AS-REQ, can be
+   validated in a subsequent TGS message exchange where its value is
+   communicated back to the KDC via the authenticator in the PA-TGS-REQ
+   padata [RFC4120].  However, this requires trusting the referred-to
+   realm's KDCs.  Clients should limit the referral mappings they will
+   accept to realms trusted via some local policy.  Some possible
+   factors that might be taken into consideration for such a policy
+   might include:
+
+   o  Any realm indicated by the local KDC, if the returned KRB-ERROR
+      message is protected by some additional means, for example using a
+      preauthentication scheme using a public key known to be associated
+      with the KDC, or an IPsec tunnel known to have the desired KDC as
+      the remote endpoint
+   o  A list of realms configured by an administrator
+   o  Any realm accepted by the user when explicitly prompted
+
+   There is currently no provision for changing the client name in a
+   client referral response, because there is no method for verifying
+   that a man-in-the-middle attack did not change the requested name in
+   the request on the way to the KDC.
+
+
+8.  Server Referrals
+
+   The primary difference in server referrals is that the KDC returns a
+   referral TGT rather than an error message as is done in the client
+   referrals.  There needs to be a place to include in the reply
+   information about what realm contains the server; this is done by
+   returning information about the server name in the pre-authentication
+   data field of the KDC reply [RFC4120], as specified later in this
+   section.
+
+   If the "canonicalize" flag in the KDC options is set and the KDC
+   doesn't find the principal locally, either as a regular principal or
+   as an alias for another local principal, the KDC MAY return a cross-
+   realm ticket granting ticket to the next hop on the trust path
+   towards a realm that may be able to resolve the principal name.  The
+   true principal name of the server SHALL be returned in the padata of
+   the reply if it is different from what is specified the request.
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response.  This referral information in pre-
+   authentication data MUST be encrypted using the session key from the
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 9]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   reply ticket.  The key usage value for the encryption operation used
+   by PA-SERVER-REFERRAL is 26.
+
+   The pre-authentication data returned by the KDC, which contains the
+   referred realm and the true principal name of server, is encoded in
+   DER as follows.
+
+
+         PA-SERVER-REFERRAL      25
+
+         SERVER-REFERRAL-DATA ::= EncryptedData
+                               -- ServerReferralData
+                               -- returned session key, ku=26
+
+         ServerReferralData ::= SEQUENCE {
+                referred-realm           [0] Realm OPTIONAL,
+                               -- target realm of the referral TGT
+                true-principal-name      [1] PrincipalName OPTIONAL,
+                               -- true server principal name
+                requested-principal-name [2] PrincipalName OPTIONAL,
+                               -- requested server name
+                referral-valid-until     [3] KerberosTime OPTIONAL,
+                rep-cksum                [4] Checksum,
+                               -- associated {AS,TGS}-REP with no padata
+                               -- reply key, ku=[TBD]
+                ...
+         }
+
+   The rep-cksum field is a checksum computed over the DER encoding of
+   the AS-REP or TGS-REP message with which the SERVER-REFERRAL-DATA is
+   included, but with the padata field omitted.  It SHOULD be computed
+   using the mandatory-to-implement checksum type associated with the
+   encryption type of the reply key.  (Encrypting the referral data in
+   with the reply key but without the checksum only proves that it was
+   generated by one of the parties with access to the reply key; it is
+   not proof against cut-and-paste attacks combining parts of different
+   KDC replies using the same reply key.)
+
+   Clients SHALL NOT accept a reply ticket in which the server principal
+   name is different from that of the request, if the KDC response does
+   not contain a PA-SERVER-REFERRAL padata entry.
+
+   The requested-principal-name MUST be included by the KDC, and MUST be
+   verified by the client, if the client sent an AS-REQ, as protection
+   against a man-in-the-middle modification to the AS-REQ message.
+
+   The referred-realm field is present if and only if the returned
+   ticket is a referral TGT, not a service ticket for the requested
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 10]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   server principal.
+
+   When a referral TGT is returned and the true-principal-name field is
+   present, the client MUST use that name in the subsequent requests to
+   the server realm when following the referral.
+
+   Client SHALL NOT accept a true server principal name for a service
+   ticket if the true-principal-name field is not present in the PA-
+   SERVER-REFERRAL data.
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+   The client may cache the mapping of the requested name to the name of
+   the next realm to use and the principal name to ask for.  (See
+   Section 10.)  The referral-valid-until field, if present, conveys how
+   long this information is valid for.
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm DEV.EXAMPLE.COM where the client is in
+   ADMIN.EXAMPLE.COM.
+
+      +NC = Canonicalize KDCOption set
+      +PA-REFERRAL = returned PA-SERVER-REFERRAL
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL
+         containing EXAMPLE.COM as the referred realm with no
+         true-principal-name
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL
+         containing DEV.EXAMPLE.COM as the referred realm with no
+         true-principal-name
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
+      S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
+
+   Note that any referral or alias processing of the server name in
+   user-to-user authentication should use the same data as client name
+   canonicalization or referral.  Otherwise, the name used by one user
+   to log in may not be useable by another for user-to-user
+   authentication to the first.
+
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 11]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+9.  Cross Realm Routing
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain.  As a result, the client need to be aware of the trust
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+   Instead, using the server referral routing mechanism as defined in
+   Section 8, The KDC will determine the best path for the client and
+   return a cross-realm TGT as the referral TGT, and the target realm
+   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
+
+   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
+   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
+   response does not contain the PA-SERVER-REFERRAL padata.
+
+
+10.  Caching Information
+
+   It is possible that the client may wish to get additional credentials
+   for the same service principal, perhaps with different authorization-
+   data restrictions or other changed attributes.  The return of a
+   server referral from a KDC can be taken as an indication that the
+   requested principal does not currently exist in the local realm.
+   Clearly, it would reduce network traffic if the clients could cache
+   that information and use it when acquiring the second set of
+   credentials for a service, rather than always having to re-check with
+   the local KDC to see if the name has been created locally.
+
+   If the referral-valid-until field is provided in the PA-SERVER-
+   REFERRAL-DATA message, it indicates the expiration time of this data;
+   if it is not included, the expiration time of the TGT is used.  When
+   the TGT expires, the previously returned referral from the local KDC
+   should be considered invalid, and the local KDC must be asked again
+   for information for the desired service principal name.  (Note that
+   the client may get back multiple referral TGTs from the local KDC to
+   the same remote realm, with different lifetimes.  The lifetime
+   information must be properly associated with the requested service
+   principal names.  Simply having another TGT for the same remote realm
+   does not extend the validity of previously acquired information about
+   one service principal name.)  If the client is still in contact with
+   the service and needs to reauthenticate to the same service
+   regardless of local service principal name assignments, it should use
+   the referred-realm and true-principal-name values when requesting new
+   credentials.
+
+   Accordingly, KDC authors and maintainers should consider what factors
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 12]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
+   into credential expiration times in cases of referrals.
+
+
+11.  Open Issues
+
+   Client referral info validation
+
+   When should client name aliases be included in credentials?  Should
+   all known client name aliases be included, or only the one used at
+   initial ticket acquisition?
+
+   Should list the policies that need to be defined.
+
+   More examples: u2u, policy checks, maybe cross-realm.
+
+   Possibly generalize the integrity/privacy protection on
+   ServerReferralData into a general padata wrapper?
+
+   Is PA-SERVER-REFERRAL needed in a TGS exchange?
+
+   Do we need to send requested-name fields, or can we just include them
+   in checksums?
+
+
+12.  Number Assignments
+
+   Most number registries in the Kerberos protocol have not been turned
+   over to IANA for management at the time of this writing, hence this
+   is not an "IANA Considerations" section.
+
+   Various values do need assigning for this draft:
+      AD-LOGIN-ALIAS
+      PA-CLIENT-CANONICALIZED
+      key usage value for PA-CLIENT-CANONICALIZED field canon-checksum
+
+
+13.  IANA Considerations
+
+   None at present.
+
+
+14.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 13]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+14.1.  Shared-password case
+
+   A special case to examine is when the user is known (or correctly
+   suspected) to use the same password for multiple accounts.  A man-in-
+   the-middle attacker can either alter the request on its way to the
+   KDC, changing the client principal name, or reply to the client with
+   a response previously send by the KDC in response to a request from
+   the attacker.  The response received by the client can then be
+   decrypted by the user, though if the default "salt" generated from
+   the principal name is used to produce the user's key, a PA-ETYPE-INFO
+   or PA-ETYPE-INFO2 preauth record may need to be added or altered by
+   the attacker to cause the client software to generate the key needed
+   for the message it will receive.  None of this requires the attacker
+   to know the user's password, and without further checking, could
+   cause the user to unknowingly use the wrong credentials.
+
+   In normal [RFC4120] operation, a generated AP-REQ message includes in
+   the Authenticator field a copy of the client's idea of its own
+   principal name.  If this differs from the name in the KDC-generated
+   Ticket, the application server will reject the message.
+
+   With client name canonicalization as described in this document, the
+   client may get its principal name from the response from the KDC.
+   Requiring the PA-CLIENT-CANONICALIZED data lets the client securely
+   check that the requested name was not altered in transit.  If the PA-
+   CLIENT-CANONICALIZED data is absent, the client can use the principal
+   name it requested.
+
+14.2.  Preauthentication data
+
+   In cases of credential renewal, forwarding, or validation, if
+   credentials are sent to the KDC that are not an initial ticket-
+   granting ticket for the client's home realm, the encryption key used
+   to protect the TGS exchange is one known to a third party (namely,
+   the service for which the credential was issued).  Consequently, in
+   such an exchange, the protection described earlier for the
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 14]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   preauthentication data cannot be assumed to provide a secure channel
+   between the KDC and the client, and such preauth data MUST NOT be
+   trusted for any information that needs to come from the KDC.
+
+
+15.  Acknowledgments
+
+   Sam Hartman and authors came up with the idea of using the ticket key
+   to encrypt the referral data, which prevents cut and paste attack
+   using the referral data and referral TGTs.
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+   Karthik Jaganathan contributed to earlier versions.
+
+
+16.  References
+
+16.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+16.2.  Informative References
+
+   [RFC3280]  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.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
+              of Crossrealm Referral Handling in the MIT Kerberos
+              Client",  Network and Distributed System Security
+              Symposium, February 2001.
+
+
+Appendix A.  Compatibility with Earlier Implementations of Name
+             Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 15]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) The TGS referral data is returned inside of the KDC message as
+      "encrypted pre-authentication data".
+
+
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 key-expiration     [3] KerberosTime OPTIONAL,
+                 flags              [4] TicketFlags,
+                 authtime           [5] KerberosTime,
+                 starttime          [6] KerberosTime OPTIONAL,
+                 endtime            [7] KerberosTime,
+                 renew-till         [8] KerberosTime OPTIONAL,
+                 srealm             [9] Realm,
+                 sname             [10] PrincipalName,
+                 caddr             [11] HostAddresses OPTIONAL,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   2) The preauth data type definition in the encrypted preauth data is
+      as follows:
+
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+   3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is
+      encoded as a Subject Alternative Name (SAN) extension [RFC3280] in
+      the client's X.509 certificate.  The type of the otherName field
+      for this SAN extension is AnotherName [RFC3280].  The type-id
+      field of the type AnotherName is id-ms-sc-logon-upn
+      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
+      AnotherName is a KerberosString [RFC4120].  The value of this
+      KerberosString type is the single component in the name-string
+      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
+
+   In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 16]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitive direct rusts between them.
+
+   While we might want to permit multiple aliases to exist and even be
+   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
+   one NT-ENTERPRISE alias to exist, so this question had not previously
+   arisen.
+
+
+Appendix B.  Document history [REMOVE BEFORE PUBLICATION]
+
+   11 Changed title.  Better protection on server referral preauth data.
+      Support server name canonicalization.  Rename ReferralInfo to
+      ClientReferralInfo.  Disallow alias mapping to a TGT principal.
+      Explain why no name change in client referrals.  Add empty IANA
+      Considerations.  Add some notes on preauth data protection during
+      renewal etc.
+   10 Separate enterprise principal names into a separate section.  Add
+      a little wording to suggest server principal name canonicalization
+      might be allowed; not fleshed out.  Advise against AD-KDC-ISSUED
+      in cronn-realm cases.  Advise policy checks on returned client
+      referral info, since there's no security.  List number
+      assignments.  Add security analysis of shared-password case.  No
+      longer plan to remove Microsoft appendix.  Add referral-valid-
+      until field.
+   09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain.
+      Rewrote description of existing practice.  (Don't name the lookup
+      table consulted.  Mention that DNS "canonicalization" is contrary
+      to [RFC4120].)  Noted Microsoft behavior should be moved out into
+      a separate document.  Changed some second-person references in the
+      introduction to identify the proper parties.  Changed PA-CLIENT-
+      CANONICALIZED to use a separate type for the actual referral data,
+      add an extension marker to that type, and change the checksum key
+      from the "returned session key" to the "AS reply key".  Changed
+      AD-LOGIN-ALIAS to contain a sequence of names, to be contained in
+      AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer
+      needed separate checksum.  Attempt to clarify the cache lifetime
+      of referral information.
+   08 Moved Microsoft implementation info to appendix.  Clarify lack of
+      local server name canonicalization.  Added optional authz-data for
+      login alias, to support user-to-user case.  Added requested-
+      principal-name to ServerReferralData.  Added discussion of caching
+      information, and referral TGT lifetime.
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 17]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   07 Re-issued with new editor.  Fixed up some references.  Started
+      history.
+
+
+Authors' Addresses
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA  02139
+   US
+
+   Email: raeburn@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 18]
+
+Internet-Draft                KDC Referrals                    July 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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 19]
+
diff --git a/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt b/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt
new file mode 100644
index 000000000..c40b83459
--- /dev/null
+++ b/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt
@@ -0,0 +1,1848 @@
+
+
+
+Network Working Group                                        G. Richards
+Internet-Draft                         RSA, The Security Division of EMC
+Intended status: Standards Track                           July 14, 2008
+Expires: January 15, 2009
+
+
+                         OTP Pre-authentication
+                    draft-ietf-krb-wg-otp-preauth-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 January 15, 2009.
+
+Abstract
+
+   The Kerberos protocol provides a framework authenticating a client
+   using the exchange of pre-authentication data.  This document
+   describes the use of this framework to carry out One Time Password
+   (OTP) authentication.
+
+
+
+
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009                [Page 1]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Overall Design . . . . . . . . . . . . . . . . . . . . . .  3
+     1.3.  Conventions Used in this Document  . . . . . . . . . . . .  4
+   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  OTP Mechanism Support  . . . . . . . . . . . . . . . . . .  4
+     2.2.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  4
+     2.3.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  5
+     2.4.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  6
+   3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  6
+     3.1.  Initial Client Request . . . . . . . . . . . . . . . . . .  6
+     3.2.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  6
+     3.3.  Client Response  . . . . . . . . . . . . . . . . . . . . .  7
+     3.4.  Verifying the pre-auth Data  . . . . . . . . . . . . . . .  9
+     3.5.  Confirming the Reply Key Change  . . . . . . . . . . . . . 10
+     3.6.  Reply Key Generation . . . . . . . . . . . . . . . . . . . 11
+   4.  OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 13
+     4.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 13
+     4.2.  PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 15
+     4.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 18
+     4.4.  PA-OTP-PIN-CHANGE  . . . . . . . . . . . . . . . . . . . . 19
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+     6.1.  Man-in-the-Middle  . . . . . . . . . . . . . . . . . . . . 19
+     6.2.  Reflection . . . . . . . . . . . . . . . . . . . . . . . . 20
+     6.3.  Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+     6.4.  Brute Force Attack . . . . . . . . . . . . . . . . . . . . 20
+     6.5.  FAST Facilities  . . . . . . . . . . . . . . . . . . . . . 20
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 21
+   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 22
+   Appendix B.  Examples of OTP Pre-Authentication Exchanges  . . . . 24
+     B.1.  Four Pass Authentication . . . . . . . . . . . . . . . . . 24
+     B.2.  Two Pass Authentication  . . . . . . . . . . . . . . . . . 27
+     B.3.  Pin Change . . . . . . . . . . . . . . . . . . . . . . . . 29
+     B.4.  Resynchronization  . . . . . . . . . . . . . . . . . . . . 30
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
+   Intellectual Property and Copyright Statements . . . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009                [Page 2]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+1.  Introduction
+
+1.1.  Scope
+
+   This document describes a FAST [ZhHa07] factor that allows One-Time
+   Password (OTP) values to be used in the Kerberos V5 [RFC4120] pre-
+   authentication in a manner that does not require use of the user's
+   Kerberos password.  The system is designed to work with different
+   types of OTP algorithms such as time-based OTPs [RFC2808], counter-
+   based tokens [RFC4226], challenge-response and [RFC2289] type
+   systems.  It is also designed to work with tokens that are
+   electronically connected to the user's computer via means such as a
+   USB interface.
+
+   This FAST factor provides the following facilities (as defined in
+   [ZhHa07]): client-authentication, replacing-reply-key and KDC-
+   authentication.  It does not provide the strengthening-reply-key
+   facility.
+
+   This proposal is partially based upon previous work on integrating
+   single-use authentication mechanisms into Kerberos [HoReNeZo04] and
+   allows for the use of the existing password-change extensions to
+   handle PIN change as described in [RFC3244].
+
+1.2.  Overall Design
+
+   This proposal supports 4-pass and 2-pass variants.  In the 4-pass
+   system, the client sends the KDC an initial AS-REQ and the KDC
+   responds with a KRB-ERROR containing padata that includes a random
+   nonce.  The client then encrypts the nonce and returns it along with
+   its own random value to the KDC in a second AS-REQ.  Finally, the KDC
+   returns the client's random value encrypted within the padata of the
+   AS-REP.  In the 2-pass variant, the client encrypts a timestamp
+   rather than a nonce from the KDC and the encrypted data is sent to
+   the KDC in the initial AS-REQ.  This variant can be used in cases
+   where the client can determine in advance that OTP pre-authentication
+   is supported by the KDC and which OTP key should be used.
+
+   In both systems, in order to create the message sent to the KDC, the
+   client must generate the OTP value and three keys: the standard Reply
+   Key, a key to encrypt the data sent to the KDC and a final key to
+   decrypt the KDC's reply.  In most cases, the OTP value will be used
+   in the key generation but in order to support algorithms where the
+   KDC cannot obtain the value (e.g.  [RFC2289]), the system also
+   supports the option of including the OTP value in the request along
+   with the encrypted nonce.  In addition, in order to support
+   situations where the KDC is unable to obtain the plaintext OTP value,
+   the system also supports the use of hashed OTP values in the key
+
+
+
+Richards                Expires January 15, 2009                [Page 3]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   derivation.
+
+   The message from the client to the KDC is sent within the encrypted
+   data provided by the FAST padata type of the AS-REQ.  The KDC then
+   obtains the OTP value, generates the same keys and verifies the pre-
+   authentication data by decrypting the nonce.  If the verification
+   succeeds then it confirms knowledge of the Reply Key by returning the
+   client's nonce encrypted under one of the generated keys within the
+   encrypted part of the FAST padata of the AS-REP.
+
+1.3.  Conventions Used in this Document
+
+   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].
+
+   This document assumes familiarity with the Kerberos preauthentication
+   framework [ZhHa07] and so freely uses terminology and notation from
+   this document.
+
+   The word padata is used as shorthand for pre-authentication data.
+
+
+2.  Usage Overview
+
+2.1.  OTP Mechanism Support
+
+   As described above, this document describes a generic system for
+   supporting different OTP mechanisms in Kerberos pre-authentication.
+   However, to ensure interoperability, all implementations of this
+   specification SHOULD provide a mechanism for OTP mechanism support to
+   be added or removed.
+
+2.2.  Pre-Authentication
+
+   The approach uses pre-authentication data in AS-REQ, AS-REP and KRB-
+   ERROR messages.
+
+   In the 4-pass system, the client begins by sending an initial AS-REQ
+   to the KDC that may contain pre-authentication data such as the
+   standard Kerberos password data.  The KDC will then determine, in an
+   implementation dependent fashion, whether OTP authentication is
+   required and if it is, it will respond with a KRB-ERROR message
+   containing a PA-OTP-CHALLENGE in the PA-DATA.
+
+   The PA-OTP-CHALLENGE will contain a KDC generated nonce, an
+   encryption type, an optional list of hash algorithm identifiers, an
+   optional iteration count and optional information on how the OTP
+
+
+
+Richards                Expires January 15, 2009                [Page 4]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   should be generated by the client.  The client will then generate the
+   OTP value, its own nonce and two keys: a Client Key to encrypt the
+   KDC's nonce and a Reply Key used to decrypt the KDC's reply.
+
+   As described in Section 3.6, these keys will be generated from the
+   Armor Key (defined in [ZhHa07]) and the OTP value unless the OTP
+   algorithm does not allow the KDC to obtain the OTP value.  If hash
+   algorithm identifiers were included in the PA-OTP-CHALLENGE then the
+   client will use the hash of the OTP value rather than the plaintext
+   value in the key generation.
+
+   The generated Client Key will be used to encrypt the nonce received
+   from the KDC using the specified encryption type.  The encrypted
+   value, a random nonce generated by the client along with optional
+   information on how the OTP was generated are then sent to the KDC in
+   a PA-OTP-REQUEST element encrypted within the armored-data of a PA-
+   FX-FAST-REQUEST PA-DATA element of a second AS-REQ.
+
+   In the 2-pass system, the client sends the PA-OTP-REQUEST in the
+   initial AS-REQ instead of sending it in response to a PA-OTP-
+   CHALLENGE returned by the KDC.  Since no challenge is received from
+   the KDC, the client includes an encrypted timestamp in the request
+   rather than the encrypted KDC nonce.
+
+   In both cases, on receipt of a PA-OTP-REQUEST, the KDC generate the
+   same keys as the client, and use the generated Client Key to verify
+   the pre-authentication by decrypting the encrypted data sent by the
+   client (either nonce or timestamp).  If the validation succeeds then
+   the KDC will authenticate itself to the client and confirm that the
+   Reply Key has been updated by encrypting the client's nonce under the
+   Reply Key and returning the encrypted value in the encData of a PA-
+   OTP-CONFIRM.  The PA-OTP-CONFIRM is encrypted within the armored-data
+   of a PA-FX-FAST-REPLY PA-DATA element of the AS-REP as described in
+   [ZhHa07].
+
+2.3.  PIN Change
+
+   If, following successful validation of a PA-OTP-REQUEST in a AS-REQ,
+   the KDC requires that the user changes their PIN then it will include
+   a PA-OTP-PIN-CHANGE element in the armored data of the PA-FX-FAST-
+   REPLY PA-DATA element of the AS-REP.  This data can be used to return
+   a new PIN to the user if the KDC has updated the PIN or to indicate
+   to the user that they must change their PIN.
+
+   In the latter case, it is recommended that user PIN change be handled
+   by a PIN change service supporting the ChangePasswdData in a AP-REQ
+   as described in [RFC3244].  If a user PIN for OTP is required to
+   change and such a service is used then the KDC MUST NOT return a TGT
+
+
+
+Richards                Expires January 15, 2009                [Page 5]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   when the user is authenticated using this PIN.  The KDC SHOULD return
+   a service ticket to the PIN change service when the existing PIN is
+   required to change, in order for the client to compute an AP-REQ
+   according to [RFC3244].  In order to complicate stealing service
+   tickets intended for the PIN change service (and the corresponding
+   session keys), the lifetime of the PIN-change service tickets should
+   be just long enough to complete the PIN change, regardless whether
+   the exiting PIN needs to be changed or not.  A 1-minute lifetime is
+   RECOMMENED.  This way the PIN change service can effectively force
+   the user to present the existing PIN in order to change to use a new
+   PIN.
+
+2.4.  Re-Synchronization
+
+   It is possible with time and event-based tokens that the OTP server
+   will lose synchronization with the current token state.  If, when
+   processing a PA-OTP-REQUEST, the pre-authentication validation fails
+   for this reason then the KDC SHALL return a KRB-ERROR message
+   containing a PA-OTP-CHALLENGE in the PA-DATA with the "nextOTP" flag
+   set.  If this flag is set then the client MUST re-try the
+   authentication using the OTP for the token "state" after that used in
+   the failed authentication attempt.
+
+
+3.  Pre-Authentication Protocol Details
+
+3.1.  Initial Client Request
+
+   In the 4-pass mode, the client begins by sending an initial AS-REQ
+   possibly containing other pre-authentication data.  If the KDC
+   determines that OTP-based pre-authentication is required and the
+   request does not contain a PA-OTP-REQUEST then it will respond as
+   described in Section 3.2.
+
+   If the client has all the necessary information, it MAY use the
+   2-pass system by constructing a PA-OTP-REQUEST as described in
+   Section 3.3 and including it in the initial request.
+
+3.2.  KDC Challenge
+
+   If the user is required to authenticate using an OTP then the KDC
+   SHALL respond to the initial AS-REQ with a KRB-ERROR containing:
+
+   o  An error code of KDC_ERR_PREAUTH_REQUIRED
+
+   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
+
+   The PA-OTP-CHALLENGE SHALL contain a random nonce value to be
+
+
+
+Richards                Expires January 15, 2009                [Page 6]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   returned encrypted in the client response and the encryption type to
+   be used by the client.
+
+   If the OTP is to be generated using an server generated challenge
+   then the value of the challenge SHALL be included in the otp-
+   challenge field.  If the OTP is to be generated by combining the
+   challenge with the token's current state (e.g. time) then the
+   "combine" flag SHALL be set.
+
+   The KDC MAY use the otp-service to identify the service provided by
+   the KDC in order to assist the client in locating the OTP token to be
+   used.  For example, this field could be used when a client has
+   multiple OTP tokens from different servers to identify the KDC.
+   Similarly, if the KDC can determine which OTP token key is the be
+   used, then the otp-keyID field MAY be used to pass that value to the
+   client.
+
+   The otp-algID field MAY be used to identify the algorithm that should
+   be used in the OTP calculation.  For example, it could be used when a
+   user has been issued with multiple tokens of different types.
+
+   In order to support connected tokens that can generate OTP values of
+   varying length, the KDC MAY include the desired length of the OTP in
+   the otp-length field.
+
+   In order to support cases where the KDC cannot obtain plaintext
+   values for the OTPs, the challenge MAY also contain a sequence of one
+   way hash function algorithm identifiers and a minimum value of the
+   iteration count to be used by the client when hashing the OTP value.
+
+3.3.  Client Response
+
+   The client response SHALL be sent to the KDC as a PA-OTP-REQUEST
+   included within the enc-fast-req of a PA-FX-FAST-REQUEST encrypted
+   under the current Armor Key as described in [ZhHa07].
+
+   In order to generate its response, the client must generate an OTP
+   value.  The OTP value MUST be based on the parameters in the KDC
+   challenge if present and the response SHOULD include any information
+   on the generated OTP value reported by the OTP token
+
+   If the "nextOTP" flag is set in the PA-OTP-CHALLENGE, then the client
+   MUST generate the OTP value in the next token state that that used in
+   the previous PA-OTP-REQUEST.  The "nextOTP" flag must also be set in
+   the PA-OTP-REQUEST.
+
+   The otp-time and otp-counter fields MAY be used to return the time
+   and counter values used by the token.  The otp-format field MAY be
+
+
+
+Richards                Expires January 15, 2009                [Page 7]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   used to report the format of the generated OTP.  This field SHOULD be
+   used if a token can generate OTP values in multiple formats.  The
+   otp-algID field MAY be used by the client to report the algorithm
+   used in the OTP calculation and the otp-keyID MAY be used to report
+   the identifier of the OTP token key used.
+
+   If an otp-challenge is present in the PA-OTP-CHALLENGE then the OTP
+   value MUST be generated based on a challenge if the token is capable
+   of accepting a challenge.  The client MAY ignore the provided
+   challenge if and only if the token is not capable of including a
+   challenge in the OTP calculation.  If the "combine" flag is not set
+   in the PA-OTP-CHALLENGE then the OTP SHALL be calculated based only
+   the challenge and not the internal state (e.g. time or counter) of
+   the token.  If the "combine" flag is set then the OTP SHALL be
+   calculated using both the internal state and the provided challenge.
+   If the flag is set but otp-challenge is not present then the client
+   SHALL regard the request as invalid.
+
+   If the OTP value was generated by a challenge not sent by the KDC
+   then the challenge SHALL be included in the otp-challenge of the PA-
+   OTP-RESPONSE.  If the OTP was generated by combining a challenge
+   (either received from the KDC or generated by the client) with the
+   token state then the "combine" flag SHALL be set in the PA-OTP-
+   RESPONSE.
+
+   The client MUST derive the Client Key and Reply Key as described in
+   Section 3.6.  In order to support OTP algorithms where the KDC cannot
+   obtain the OTP value, the client MAY include the generated value in
+   the otp-value field of the response.  However, the client MUST NOT
+   include the OTP value in the response unless it is allowed by the
+   algorithm profile.  If it is included then the OTP value MUST NOT be
+   used in the key derivation.
+
+   If the client used hashed OTP values in the key derivation process
+   then it MUST include the hash algorithm and iteration count used in
+   the hashAlg and iterationCount fields of the PA-OTP-REQUEST.  These
+   fields MUST NOT be included if hashed OTP values were not used.  It
+   is RECOMMENDED that the iteration count used by the client be chosen
+   in such a way that it is computationally infeasible/unattractive for
+   an attacker to brute-force search for the given OTP within the
+   lifetime of that OTP.
+
+   If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE
+   that contained hash algorithm identifiers and the OTP value is to be
+   used in the key derivation then the client MUST use hashed OTP values
+   and MUST select the first algorithm from the list that it supports.
+   However, if the algorithm identifiers do not conform to local policy
+   restrictions then the authentication attempt MUST NOT proceed.  If
+
+
+
+Richards                Expires January 15, 2009                [Page 8]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   the iteration count specified in the PA-OTP-CHALLENGE does not
+   conform to local policy then the client MAY use a higher value but
+   MUST NOT use a lower value.  That is, the value in the KDC challenge
+   is a minimum value.
+
+   The generated Client Key is used by the client to encrypt data to be
+   included in the encData of the response to allow the KDC to
+   authenticate the user.  The key usage for this encryption is
+   KEY_USAGE_OTP_REQUEST.
+
+   o  If the response is being generated in response to a KDC challenge
+      then client encrypts a PA-OTP-ENC-REQUEST containing the value of
+      nonce from the corresponding challenge using the encryption type
+      specified in the challenge.
+
+   o  If the response is not in response to a KDC challenge then the
+      client encrypts a PA-ENC-TS-ENC containing the current time as in
+      the encrypted timestamp pre-authentication mechanism [RFC4120].
+
+   If the client is working in 2-pass mode and so is not responding to
+   an initial KDC challenge then the values of the iteration count, hash
+   algorithms and encryption type cannot be obtained from that
+   challenge.  The client SHOULD use any values obtained from a previous
+   PA-OTP-CHALLENGE or, if no values are available, it MAY use initial
+   configured values.
+
+   Finally, the client generates a random value to include in the nonce
+   of the response.  This value will then be returned encrypted by the
+   KDC.
+
+3.4.  Verifying the pre-auth Data
+
+   The KDC validates the pre-authentication data by generating the same
+   keys as the client and using the generated Client Key to decrypt the
+   value of encData from the PA-OTP-REQUEST.
+
+   If the otp-value field is included in the PA-OTP-REQUEST then the KDC
+   MUST use that value in the key generation.  Otherwise, the KDC will
+   need to generate or obtain the value.
+
+   If the otp-challenge field is present, then the OTP was calculated
+   using that challenge.  If the "combine" flag is also set, then the
+   OTP was calculated using the challenge and the token's current state.
+
+   It is RECOMMENDED that the KDC acts upon the values of otp-time, otp-
+   counter, otp-format, otp-algID and otp-keyID if they are present in
+   the PA-OTP-REQUEST.  If the KDC receives a request containing these
+   values but cannot act upon theme then they MAY be ignored.
+
+
+
+Richards                Expires January 15, 2009                [Page 9]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   The KDC generates the Client Key and Reply Key as described in
+   Section 3.6 from the OTP value using the hash algorithm and iteration
+   count if present in the PA-OTP-REQUEST.  However, the client
+   authentication MUST fail if the KDC requires hashed OTP values and
+   the hashAlg field was not present in the PA-OTP-REQUEST, if the hash
+   algorithm identifier or the value of iterationCount included in the
+   PA-OTP-REQUEST do not conform to local KDC policy or if the value of
+   the iterationCount is less than that specified in the PA-OTP-
+   CHALLENGE.
+
+   The generated Client Key is then used to decrypt the encData from the
+   PA-OTP-REQUEST.  If the client response was sent as a result of a PA-
+   OTP-CHALLENGE then decrypted data will be a PA-OTP-ENC-REQUEST and
+   the client authentication MUST fail if the nonce value from the PA-
+   OTP-ENC-REQUEST is not the same as the nonce value sent in the PA-
+   OTP-CHALLENGE.  If the response was not sent as a result of a PA-OTP-
+   CHALLENGE then the decrypted value will be a PA-ENC-TS-ENC and the
+   authentication process will be the same as with standard encrypted
+   timestamp pre-authentication [RFC4120]
+
+   The authentication MUST fail if the encryption type used by the
+   client in the encData does not conform to policy.
+
+   If authentication fails due to the hash algorithm, iteration count or
+   encryption type used by the client then the KDC SHOULD return a PA-
+   OTP-CHALLENGE with the required values in the error response.  If the
+   authentication fails due to the token state on the server no longer
+   being synchronized with the token used then the KDC SHALL return a
+   PA-OTP-CHALLENGE with the "nextOTP" flag set as described in
+   Section 2.4.
+
+   If during the authentication process, the KDC determines that the
+   user's PIN has expired then it MAY include a PA-OTP-PIN-CHANGE in the
+   response as described in Section 2.3
+
+3.5.  Confirming the Reply Key Change
+
+   If the pre-authentication data was successfully verified, then, in
+   order to support mutual authentication, the KDC SHALL respond to the
+   client's PA-OTP-REQUEST by including in the AS-REP, a PA-OTP-CONFIRM
+   containing the client's nonce from PA-OTP-REQUEST encrypted under the
+   generated Reply Key.
+
+   The nonce SHALL be returned within a PA-OTP-ENC-CONFIRM encrypted
+   within the encData of the PA-OTP-CONFIRM.  The key usage SHALL be
+   KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same as
+   used by the client in the encData of the PA-OTP-REQUEST.
+
+
+
+
+Richards                Expires January 15, 2009               [Page 10]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   The PA-OTP-CONFIRM SHALL be sent to the client within the enc-fast-
+   rep of a PA-FX-FAST-REPLY encrypted under the current Armor Key.
+
+   The client then uses its generated Reply Key to decrypt the PA-OTP-
+   ENC-CONFIRM from the encData of the PA-OTP-CONFIRM.  The client MUST
+   fail the authentication process if the nonce value in the PA-OTP-ENC-
+   CONFIRM is not the same as the nonce value sent in the PA-OTP-
+   REQUEST.
+
+3.6.  Reply Key Generation
+
+   In order to authenticate the user, the client and KDC need to
+   generate two encryption keys:
+
+   o  The Client Key to be used by the client to encrypt and by the KDC
+      to decrypt the encData in the PA-OTP-REQUEST.
+
+   o  The Reply Key to be used in the standard manner by the KDC to
+      encrypt data in the AS-REP but also to be used by the KDC to
+      encrypt and by the client to decrypt the encData value in the PA-
+      OTP-CONFIRM.
+
+   The method used to generate the three keys will depend on the OTP
+   algorithm.
+
+   o  If the OTP value is included in the otp-value of the PA-OTP-
+      REQUEST then all three keys SHALL be the same as the Armor Key
+      (defined in [ZhHa07]).
+
+   o  If the OTP value is not included in the otp-value of the PA-OTP-
+      REQUEST then the three keys SHALL be derived from the Armor Key
+      and the OTP value as described below.
+
+   If the OTP value is not included in the PA-OTP-REQUEST, then the
+   Reply Key SHALL be generated using the KRB_FX_CF2 algorithm from
+   [ZhHa07]
+
+             Client Key = KRB_FX_CF2(K1, K2, O1, O2)
+             Reply Key = KRB_FX_CF2(K1, K2, O3, O4)
+
+   The first input keys, K1, shall be the Armor Key. The second input
+   key, K2, shall be derived from the OTP value using string-to-key
+   (defined in [RFC3961]).
+
+   The octet string parameters, O1, O2, O3 and O4, shall be the ASCII
+   string "Combine1", "Combine2", "Combine3" and "Combine4" as shown
+   below:
+
+
+
+
+Richards                Expires January 15, 2009               [Page 11]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31}
+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32}
+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x33}
+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x34}
+
+   If the hash of the OTP value is to be used then K2 SHALL be derived
+   as follows:
+
+   o  An initial hash value, H, is generated:
+
+             H = hash(sname|nonce|OTP)
+
+      Where:
+      *  "|" denotes concatenation
+      *  hash is the hash algorithm selected by the client.
+      *  sname is the UTF-8 encoding of the KDC's fully qualified domain
+         name.  If the domain name is an Internationalized Domain Name
+         then the value shall be the output of nameprep [RFC3491] as
+         described in [RFC3490]
+      *  nonce is the random nonce value generated by the client to be
+         included in the PA-OTP-REQUEST.
+      *  OTP is the OTP value.
+
+   o  The initial hash value is then hashed iterationCount-1 times to
+      produce a final hash value, H'.  (Where iterationCount is the
+      value from the PA-OTP-REQUEST.)
+
+             H' = hash(hash(...(iterationCount-1 times)...(H)))
+
+   o  The value of K2 is then derived from the base64 [RFC2045] encoding
+      of this final hash value.
+
+             K2 = string-to-key(Base64(H')||"Krb-preAuth")
+
+   If the OTP value is binary and the hash value is not used, then K2
+   SHALL be derived from the base64 encoding of the OTP value.
+
+             K2 = string-to-key(Base64(OTP)||"Krb-preAuth")
+
+   If the OTP value is not binary and the hash value is not used, then
+   K2 SHALL be derived by running the OTP value once through string-to-
+   key.
+
+             K2 = string-to-key(OTP||"Krb-preAuth")
+
+   The salt and any additional parameters for string-to-key will be
+   derived as described in section 3.1.3 of [RFC4120] using preauth data
+   or default values defined for the particular enctype.  The symbol
+
+
+
+Richards                Expires January 15, 2009               [Page 12]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   "||" denotes string concatenation.
+
+
+4.  OTP Kerberos Message Types
+
+4.1.  PA-OTP-CHALLENGE
+
+   The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in
+   the PA-DATA of a KRB-ERROR when pre-authentication using an OTP value
+   is required.  The corresponding padata-value field contains the DER
+   encoding of a PA-OTP-CHALLENGE containing a server generated nonce
+   and information for the client on how to generate the OTP.
+
+             PA_OTP_CHALLENGE     << TBA >>
+
+             PA-OTP-CHALLENGE ::= SEQUENCE {
+               flags              OTPFlags,
+               nonce              UInt32,
+               etype              Int32,
+               supportedHashAlg   SEQUENCE OF AlgorithmIdentifier
+                                                  OPTIONAL,
+               iterationCount     INTEGER         OPTIONAL,
+               otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,
+               otp-length     [0] Int32           OPTIONAL,
+               otp-service        UTF8String      OPTIONAL,
+               otp-keyID      [1] OCTET STRING    OPTIONAL,
+               otp-algID          AnyURI          OPTIONAL,
+               ...
+             }
+
+             OTPFlags ::= KerberosFlags
+             -- nextOTP (0)
+             -- combine (1)
+
+   flags
+      If the "nextOTP" flag is set then the OTP SHALL be based on the
+      next token "state" rather than the current one.  As an example,
+      for a time-based token, this means the next time slot and for an
+      event-based token, this could mean the next counter value.
+
+      The "combine flag controls how the challenge included in otp-
+      challenge shall be used.  If the flag is set then OTP SHALL be
+      calculated using the challenge from otp-challenge and the internal
+      token state (e.g. time or counter).  If the "combine" flag is not
+      set then the OTP SHALL be calculated based only on the challenge.
+      If the flag is set and otp-challenge is not present then the
+      request SHALL be regarded as invalid.
+
+
+
+
+Richards                Expires January 15, 2009               [Page 13]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   nonce
+      A KDC-supplied nonce value to be encrypted by the client in the
+      PA-OTP-REQUEST.
+
+   etype
+      The encryption type to be used by the client to encrypt the nonce
+      in the PA-OTP-REQUEST.
+
+   supportedHashAlg
+      If present then a hash of the OTP value MUST be used in the key
+      derivation rather than the plain text value.  Each
+      AlgorithmIdentifier identifies a hash algorithm that is supported
+      by the KDC in decreasing order of preference.  The client MUST
+      select the first algorithm from the list that it supports.
+      Support for SHA1 by both the client and KDC is REQUIRED.  The
+      AlgorithmIdentifer selected by the client MUST be placed in the
+      hashAlg element of the PA-OTP-REQUEST.
+
+   iterationCount
+      The minimum value of the iteration count to be used by the client
+      when hashing the OTP value.  This value MUST be present if and
+      only if supportedHashAlg is present.  If the value of this element
+      does not conform to local policy on the client then the client MAY
+      use a larger value but MUST NOT use a lower value.  The value of
+      the iteration count used by the client MUST be returned in the PA-
+      OTP-REQUEST sent to the KDC.
+
+   otp-challenge
+      The otp-challenge is used by the KDC to send a challenge value for
+      use in the OTP calculation.  The challenge is an optional octet
+      string that SHOULD be uniquely generated for each request it is
+      present in, and SHOULD be eight octets or longer when present.
+      When the challenge is not present, the OTP will be calculated on
+      the current token state only.  The client MAY ignore a provided
+      challenge if and only if the OTP token the client is interacting
+      with is not capable of including a challenge in the OTP
+      calculation.  In this case, KDC policies will determine whether to
+      accept a provided OTP value or not.
+
+   otp-length
+      Use of this field is OPTIONAL, but MAY be used by the KDC to
+      specify the desired length of the generated OTP in octets.  For
+      example, this field could be used when a token is capable of
+      producing OTP values of different lengths.
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 14]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   otp-service
+      Use of this field is OPTIONAL, but MAY be used by the KDC to
+      identify the appropriate OTP tokens to be used.  For example, this
+      field could be used when a client has multiple OTP tokens from
+      different servers.
+
+   otp-keyID
+      Use of this field is OPTIONAL, but MAY be used by the KDC to
+      identify which token key should be used for the authentication.
+      For example, this field could be used when a user has been issued
+      multiple token keys by the same server.
+
+   otp-algID
+      use of this field is OPTIONAL, but MAY be used by the KDC to
+      identify the algorithm to use when generating the OTP.
+
+4.2.  PA-OTP-REQUEST
+
+   The padata-type PA_OTP_REQUEST is sent by the client to the KDC in
+   the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the
+   PA-DATA of an AS-REQ.  The corresponding padata-value field contains
+   the DER encoding of a PA-OTP-REQUEST.
+
+   The message contains pre-authentication data encrypted by the client
+   using the generated Client Key and optional information on how the
+   OTP was generated.  It may also, optionally, contain the generated
+   OTP value.
+
+             PA_OTP_REQUEST     << TBA >>
+
+             PA-OTP-REQUEST ::= SEQUENCE {
+               flags             OTPFlags,
+               nonce             UInt32,
+               encData           EncryptedData,
+                                 -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
+                                 -- Key usage of KEY_USAGE_OTP_REQUEST
+               hashAlg           AlgorithmIdentifier OPTIONAL,
+               iterationCount    INTEGER         OPTIONAL,
+               otp-value         OCTET STRING    OPTIONAL,
+               otp-challenge [0] OCTET STRING    OPTIONAL,
+               otp-time          KerberosTime    OPTIONAL,
+               otp-counter   [1] OCTET STRING    OPTIONAL,
+               otp-format    [2] OTPFormat       OPTIONAL,
+               otp-keyID     [3] OCTET STRING    OPTIONAL,
+               otp-algID         AnyURI          OPTIONAL,
+               ...
+             }
+
+
+
+
+Richards                Expires January 15, 2009               [Page 15]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+             KEY_USAGE_OTP_REQUEST  << TBA >>
+
+
+             PA-OTP-ENC-REQUEST ::= SEQUENCE {
+               nonce     UInt32,
+               ...
+             }
+
+
+             OTPFormat ::= INTEGER {
+               decimal(0),
+               hexadecimal(1),
+               alphanumeric(2),
+               binary(3)
+             }
+
+   flags
+      If the "nextOTP" flag is set then the OTP was calculated based on
+      the next token "state" rather than the current one.  This flag
+      MUST be set if and only if it was set in a corresponding PA-OTP-
+      CHALLENGE.
+
+      If the "combine" flag is set then the OTP was calculated based on
+      a challenge and the token state.
+
+   nonce
+      A random nonce value generated by the client to be returned
+      encrypted by the KDC in the PA-OTP-CONFIRM.
+
+   encData
+      This field contains the pre-authentication data encrypted under
+      the Client Key with a key usage of KEY_USAGE_OTP_REQUEST.  If the
+      PA-OTP-REQUEST is sent as a result of a PA-OTP_CHALLENGE then this
+      MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP-
+      CHALLENGE.  If no challenge was received then this MUST contain a
+      PA-ENC-TS-ENC.
+
+   hashAlg
+      This field MUST be present if and only if a hash of the OTP value
+      was used as input to string-to-key (see Section 3.6) and MUST
+      contain the AlgorithmIdentifier of the hash algorithm used.  If
+      the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then
+      the AlgorithmIdentifer MUST be the first one supported by the
+      client from the supportedHashAlg of the PA-OTP-CHALLENGE.
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 16]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   iterationCount
+      This field MUST be present if and only if a hash of the OTP value
+      was used as input to string-to-key (see Section 3.6) and MUST
+      contain the iteration count used when hashing the OTP value.  If
+      the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then
+      the value MUST NOT be less that that specified in the PA-OTP-
+      CHALLENGE.
+
+   otp-value
+      The generated OTP value.  This value MUST NOT be present unless
+      allowed by the OTP algorithm profile.
+
+   otp-challenge
+      Value used by the client in the OTP calculation.  It MUST be sent
+      to the KDC if and only if the value would otherwise be unknown to
+      the KDC.  For example, the token or client modified or generated
+      challenge.
+
+   otp-time
+      This field MAY be included by the client to carry the time value
+      as reported by the OTP token.  Use of this element is OPTIONAL but
+      it MAY be used by a client to simplify the OTP calculations of the
+      KDC.  It is RECOMMENDED that the KDC act upon this value if it is
+      present in the request and it is capable of using it in the
+      generation of the OTP value.
+
+   otp-counter
+      This field MAY be included by the client to carry the token
+      counter value, as reported by the OTP token.  Use of this element
+      is OPTIONAL but it MAY be used by a client to simplify the OTP
+      calculations of the KDC.  It is RECOMMENDED that the KDC act upon
+      this value if it is present in the request and it is capable of
+      using it in the generation of the OTP value.
+
+   otp-format
+      This field MAY be used by the client to send the format of the
+      generated OTP as reported by the OTP token.  Use of this element
+      is OPTIONAL but it MAY be used by the client to simplify the OTP
+      calculation.  It is RECOMMENDED that the KDC act upon this value
+      if it is present in the request and it is capable of using it in
+      the generation of the OTP value.
+
+   otp-keyID
+      This field MAY be used by the client to send the identifier of the
+      token key used, as reported by the OTP token.  Use of this field
+      is OPTIONAL but MAY be used by the client to simplify the
+      authentication process by identifying a particular token key
+      associated with the user.  It is RECOMMENDED that the KDC act upon
+
+
+
+Richards                Expires January 15, 2009               [Page 17]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+      this value if it is present in the request and it is capable of
+      using it in the generation of the OTP value.
+
+   otp-algID
+      This field MAY be used by the client to send the identifier of the
+      OTP algorithm used, as reported by the OTP token.  Use of this
+      element is OPTIONAL but it MAY be used by the client to simplify
+      the OTP calculation.  It is RECOMMENDED that the KDC act upon this
+      value if it is present in the request and it is capable of using
+      it in the generation of the OTP value.
+
+4.3.  PA-OTP-CONFIRM
+
+   The padata-type PA_OTP_CONFIRM is returned by the KDC in the enc-
+   fast-rep of a PA-FX-FAST-REPLY in the AS-REP of the KDC.  It is used
+   to return the client's nonce encrypted under the new Reply Key in
+   order to authenticate the KDC and confirm the Reply Key change.
+
+   The corresponding padata-value field contains the DER encoding of a
+   PA-OTP-CONFIRM.
+
+             PA_OTP_CONFIRM     << TBA >>
+
+             PA-OTP-CONFIRM ::= SEQUENCE {
+               encData        EncryptedData,
+                                   -- PA-OTP-ENC-CONFIRM
+                                   -- Key usage of KEY_USAGE_OTP_CONFIRM
+               ...
+             }
+
+             KEY_USAGE_OTP_CONFIRM  << TBA >>
+
+
+             PA-OTP-ENC-CONFIRM ::= SEQUENCE {
+               nonce     UInt32,
+               ...
+             }
+
+   encData
+      An EncryptedData containing a PA-OTP-ENC-CONFIRM containing the
+      value of the nonce from the corresponding PA-OTP-REQUEST encrypted
+      under the current Reply Key. The key usage SHALL be
+      KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same
+      as that used by the client in the PA-OTP-REQUEST.
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 18]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+4.4.  PA-OTP-PIN-CHANGE
+
+   The padata-type PA_OTP_PIN_CHANGE is returned by the KDC in the enc-
+   fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change
+   their PIN or if the user's PIN has been changed.
+
+   The corresponding padata-value field contains the DER encoding of a
+   PA-OTP-PIN-CHANGE.
+
+             PA_OTP_PIN_CHANGE     << TBA >>
+
+             PA-OTP-PIN-CHANGE ::= SEQUENCE {
+               flags         PinFlags,
+               pin           UTF8String OPTIONAL,
+               minLength     INTEGER    OPTIONAL,
+               maxLength [1] INTEGER    OPTIONAL,
+               ...
+             }
+
+             PinFlags ::= KerberosFlags
+               -- systemSetPin (0)
+
+   If the "systemSetPin" flag is set then the user's PIN has been
+   changed and the new PIN value is contained in the pin field.  The pin
+   field MUST therefore be present.
+
+   If the "systemSetPin" flag is not set then the user's PIN has not
+   been changed by the server but it MUST instead be changed by the
+   user.  Restrictions on the size of the PIN MAY be given by the
+   minLength and maxLength fields.  If the pin field is present then it
+   contains a PIN value that MAY be used by the user when changing the
+   PIN.
+
+
+5.  IANA Considerations
+
+   A registry may be required for the otp-algID values as introduced in
+   Section 4.1.  No other IANA actions are anticipated.
+
+
+6.  Security Considerations
+
+6.1.  Man-in-the-Middle
+
+   In the system described in this document, the OTP pre-authentication
+   protocol is tunnelled within the FAST Armor channel provided by the
+   pre-authentication framework.  As described in [AsNiNy02], tunneled
+   protocols are potentially vulnerable to man-in-the-middle attacks if
+
+
+
+Richards                Expires January 15, 2009               [Page 19]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   the outer tunnel is compromised and it is generally considered good
+   practice in such cases to bind the inner encryption to the outer
+   tunnel.
+
+   Even though no such attacks are known at this point, the proposed
+   system uses the outer Armor Key in the derivation of the inner Client
+   and Reply keys and so achieve crypto-binding to the outer channel.
+
+6.2.  Reflection
+
+   The 4-pass system described above is a challenge-response protocol
+   and such protocols are potentially vulnerable to reflection attacks.
+   No such attacks are known at this point but to help mitigate against
+   such attacks, the system uses different keys to encrypt the client
+   and server nonces.
+
+6.3.  Replay
+
+   The 2-pass version of the protocol does not involve a server nonce
+   and so the client instead encrypts a timestamp.  To reduce the chance
+   of replay attacks, the KDC must check that the client time used in
+   such a request is later than that used in previous requests.
+
+6.4.  Brute Force Attack
+
+   A compromised or hostile KDC may be able to obtain the OTP value used
+   by the client via a brute force attack.  If the OTP value is short
+   then the KDC could iterate over the possible OTP values until a
+   Client Key is generated that can decrypt the encData sent in the PA-
+   OTP-REQUEST.
+
+   As described in Section 3.6, an iteration count can be used in the
+   generation of the Client Key and the value of the iteration count can
+   be controlled by local client policy.  Use of this iteration count
+   can make it computationally infeasible/unattractive for an attacker
+   to brute-force search for the given OTP within the lifetime of that
+   OTP.
+
+6.5.  FAST Facilities
+
+   The secret used to generate the OTP is known only to the client and
+   the KDC and so successful decryption of the encrypted nonce by the
+   KDC authenticates the user.  Similarly, successful decryption of the
+   encrypted nonce by the client proves that the expected KDC replied.
+   The Reply Key is replaced by a key generated from the OTP and Armor
+   Key. This FAST factor therefore provides the following facilities:
+   client-authentication, replacing-reply-key and KDC-authentication.
+
+
+
+
+Richards                Expires January 15, 2009               [Page 20]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+7.  Acknowledgments
+
+   Many significant contributions were made to this document by RSA
+   employees but special thanks go to Magnus Nystrom, John Linn, Robert
+   Polansky and Boris Khoutorski.
+
+   Many valuable suggestions were also made by members of the Kerberos
+   Working group but special thanks go to Larry Zhu, Jeffrey Hutzelman,
+   Tim Alsop, Henry Hotz and Nicolas Williams.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part One: Format of Internet Message
+              Bodies", RFC 2045, November 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+              Profile for Internationalized Domain Names (IDN)",
+              RFC 3491, March 2003.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [ZhHa07]   Znu, L. and S. Hartman, "A generalized Framework for
+              Kerberos Pre-Authentication",
+              draft-ietf-krb-wg-preauth-framework-08 (work in progress),
+              July 2008.
+
+8.2.  Informative References
+
+   [AsNiNy02]
+              Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
+              in Tunneled Authentication Protocols", Cryptology ePrint
+              Archive Report 2002/163, November 2002.
+
+
+
+Richards                Expires January 15, 2009               [Page 21]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   [HoReNeZo04]
+              Horstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
+              progress), July 2004.
+
+   [RFC2289]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-
+              Time Password System", RFC 2289, February 1998.
+
+   [RFC2808]  Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
+              April 2000.
+
+   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
+              2000 Kerberos Change Password and Set Password Protocols",
+              RFC 3244, February 2002.
+
+   [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
+              O. Ranen, "HOTP: An HMAC-Based One-Time Password
+              Algorithm", RFC 4226, December 2005.
+
+
+Appendix A.  ASN.1 Module
+
+   OTPKerberos
+   DEFINITIONS IMPLICIT TAGS ::=
+   BEGIN
+
+   IMPORTS
+       AnyURI
+       FROM XSD {joint-iso-itu-t asn1(1) specification(0)
+                 modules(0) xsd-module(1)};
+
+       KerberosTime, KerberosFlags, EncryptionKey, UInt32,
+       Int32, EncryptedData
+       FROM KerberosV5Spec2 {iso(1) identified-organization(3)
+                             dod(6) internet(1) security(5)
+                             kerberosV5(2) modules(4) krb5spec2(2)}
+                             -- as defined in RFC 4120.
+       AlgorithmIdentifier
+       FROM PKIX1Explicit88 { iso (1) identified-organization (3)
+                              dod (6) internet (1)
+                              security (5) mechanisms (5) pkix (7)
+                              id-mod (0) id-pkix1-explicit (18) };
+                              -- As defined in RFC 3280.
+
+       PA-OTP-CHALLENGE ::= SEQUENCE {
+         flags              OTPFlags,
+         nonce              UInt32,
+
+
+
+Richards                Expires January 15, 2009               [Page 22]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+         etype              Int32,
+         supportedHashAlg   SEQUENCE OF AlgorithmIdentifier
+                                            OPTIONAL,
+         iterationCount     INTEGER         OPTIONAL,
+         otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,
+         otp-length     [0] Int32           OPTIONAL,
+         otp-service        UTF8String      OPTIONAL,
+         otp-keyID      [1] OCTET STRING    OPTIONAL,
+         otp-algID          AnyURI          OPTIONAL,
+         ...
+       }
+
+       OTPFlags ::= KerberosFlags
+       -- nextOTP (0)
+       -- combine (1)
+
+       PA-OTP-REQUEST ::= SEQUENCE {
+         flags             OTPFlags,
+         nonce             UInt32,
+         encData           EncryptedData,
+                           -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
+                           -- Key usage of KEY_USAGE_OTP_REQUEST
+         hashAlg           AlgorithmIdentifier OPTIONAL,
+         iterationCount    INTEGER         OPTIONAL,
+         otp-value         OCTET STRING    OPTIONAL,
+         otp-challenge [0] OCTET STRING (SIZE(8..MAX)) OPTIONAL,
+         otp-time          KerberosTime    OPTIONAL,
+         otp-counter   [1] OCTET STRING    OPTIONAL,
+         otp-format    [2] OTPFormat       OPTIONAL,
+         otp-keyID     [3] OCTET STRING    OPTIONAL,
+         otp-algID         AnyURI          OPTIONAL,
+         ...
+       }
+
+       PA-OTP-ENC-REQUEST ::= SEQUENCE {
+         nonce     UInt32,
+         ...
+       }
+
+       OTPFormat ::= INTEGER {
+         decimal(0),
+         hexadecimal(1),
+         alphanumeric(2),
+         binary(3)
+       }
+
+       PA-OTP-CONFIRM ::= SEQUENCE {
+         encData        EncryptedData,
+
+
+
+Richards                Expires January 15, 2009               [Page 23]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+                        -- PA-OTP-ENC-CONFIRM
+                        -- Key usage of KEY_USAGE_OTP_CONFIRM
+         ...
+       }
+
+       PA-OTP-ENC-CONFIRM ::= SEQUENCE {
+         nonce     UInt32,
+         ...
+       }
+
+       PA-OTP-PIN-CHANGE ::= SEQUENCE {
+         flags         PinFlags,
+         pin           UTF8String OPTIONAL,
+         minLength     INTEGER    OPTIONAL,
+         maxLength [0] INTEGER    OPTIONAL,
+         ...
+       }
+
+       PinFlags ::= KerberosFlags
+       -- systemSetPin (0)
+
+   END
+
+
+Appendix B.  Examples of OTP Pre-Authentication Exchanges
+
+   This section is non-normative.
+
+B.1.  Four Pass Authentication
+
+   In this mode, the client sends an initial AS-REQ to the KDC that does
+   not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR
+   containing a PA-OTP-CHALLENGE.
+
+   In this example, the user has been issued with a connected, time-
+   based token and the KDC requires hashed OTP values in the key
+   generation with SHA-384 as the preferred hash algorithm and a minimum
+   of 1024 iterations.  It also requires that 256-bit AES be used to
+   encrypt the nonce.  The local policy on the client supports SHA-256
+   and requires 100,000 iterations of the OTP value.
+
+   The basic sequence of steps involved is as follows:
+
+   1.   The client obtains the user name of the user.
+
+   2.   The client sends an initial AS-REQ to the KDC that does not
+        contain a PA-OTP-REQUEST.
+
+
+
+
+Richards                Expires January 15, 2009               [Page 24]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   3.   The KDC determines that the user identified by the AS-REQ
+        requires OTP authentication.
+
+   4.   The KDC constructs a PA-OTP-CHALLENGE as follows:
+
+        flags
+           0
+
+        nonce
+           A randomly generated value.
+
+        etype
+           aes256-cts-hmac-sha1-96
+
+        supportedHashAlg
+           AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1
+
+        iterationCount
+           1024
+
+        otp-service
+           A string that can be used by the client to assist the user in
+           locating the correct token.
+
+   5.   The KDC returns a KRB-ERROR with an error code of
+        KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
+
+   6.   The client displays the value of otp-service and prompts the
+        user to connect the token.
+
+   7.   The client obtains the current OTP value from the token and
+        records the time as reported by the token.
+
+   8.   The client generates Client Key and Reply Key as described in
+        Section 3.6 using SHA-256 from the list of algorithms sent by
+        the KDC and the iteration count of 100,000 as required by local
+        policy.
+
+   9.   The client constructs a PA-OTP-REQUEST as follows:
+
+        flags
+           0
+
+        nonce
+           A randomly generated value.
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 25]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+        encData
+           An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
+           under the Client Key with a key usage of
+           KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts-
+           hmac-sha1-96.  The PA-OTP-ENC-REQUEST contains the nonce from
+           the PA-OTP-CHALLENGE.
+
+        hashAlg
+           SHA-256
+
+        iterationCount
+           100,000
+
+        otp-time
+           The time used in the OTP calculation as reported by the OTP
+           token.
+
+   10.  The client encrypts the PA-OTP-REQUEST within the enc-fast-req
+        of a PA-FX-FAST-REQUEST.
+
+   11.  The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
+        REQUEST within the padata.
+
+   12.  The KDC validates the pre-authentication data in the PA-OTP-
+        REQUEST:
+
+        *  Generates the Client Key and Reply Key from the OTP value for
+           the user identified in the AS-REQ, using an iteration count
+           of 100,000 and hash algorithm of SHA-256 as specified in the
+           PA-OTP-REQUEST.
+
+        *  Uses the generated Client Key to decrypt the PA-OTP-ENC-
+           REQUEST in the encData of the PA-OTP-REQUEST.
+
+        *  Authenticates the user by comparing the nonce value from the
+           decrypted PA-OTP-ENC-REQUEST to that sent in the
+           corresponding PA-OTP-CHALLENGE.
+
+   13.  The KDC constructs a TGT for the user.
+
+   14.  The KDC constructs a PA-OTP-CONFIRM as follows:
+
+        encData
+           An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted
+           under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM
+           and an encryption type of aes256-cts-hmac-sha1-96 (the
+           encryption type used by the client in the PA-OTP-REQUEST).
+           The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-
+
+
+
+Richards                Expires January 15, 2009               [Page 26]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+           REQUEST.
+
+   15.  The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a
+        PA-FX-FAST-REPLY.
+
+   16.  The KDC returns an AS-REP to the client, encrypted using the
+        Reply Key, containing the TGT and padata with the PA-FX-FAST-
+        REPLY.
+
+   17.  The client authenticates the KDC and verifies the Reply Key
+        change.
+
+        *  Uses the generated Reply Key to decrypt the PA-OTP-ENC-
+           CONFIRM in the encData of the PA-OTP-CONFIRM.
+
+        *  Authenticates the KDC by comparing the nonce value from the
+           decrypted PA-OTP-ENC-CONFIRM to that sent in the
+           corresponding PA-OTP-REQUEST.
+
+B.2.  Two Pass Authentication
+
+   In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-
+   FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC.
+
+   In this example, the user has been issued with a hand-held token and
+   so none of the OTP generation parameters (otp-length etc) are
+   included in the PA-OTP-RESPONSE.  The KDC does not require hashed OTP
+   values in the key generation.
+
+   It is assumed that the client has been configured with the following
+   information or has obtained it from a previous PA-OTP-CHALLENGE.
+   o  The encryption type of aes128-cts-hmac-sha1-96 to use to encrypt
+      the encData.
+   o  The fact that hashed OTP values are not required.
+
+   The basic sequence of steps involved is as follows:
+
+   1.   The client obtains the user name and OTP value from the user.
+
+   2.   The client generates Client Key and Reply Key using unhashed OTP
+        values as described in Section 3.6.
+
+   3.   The client constructs a PA-OTP-REQUEST as follows:
+
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 27]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+        flags
+           0
+
+        nonce
+           A randomly generated value.
+
+        encData
+           An EncryptedData containing a PA-ENC-TS-ENC encrypted under
+           the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and
+           an encryption type of aes128-cts-hmac-sha1-96.  The PA-ENC-
+           TS-ENC contains the current client time.
+
+   4.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req
+        of a PA-FX-FAST-REQUEST.
+
+   5.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
+        REQUEST within the padata.
+
+   6.   The KDC validates the pre-authentication data:
+
+        *  Generates the Client Key and Reply Key from the unhashed OTP
+           value for the user identified in the AS-REQ.
+
+        *  Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in
+           the encData of the PA-OTP-REQUEST.
+
+        *  Authenticates the user using the timestamp in the standard
+           manner.
+
+   7.   The KDC constructs a TGT for the user.
+
+   8.   The KDC constructs a PA-OTP-CONFIRM as follows:
+
+        encData
+           An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted
+           under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM
+           and an encryption type of aes128-cts-hmac-sha1-96 (the
+           encryption type used by the client in the PA-OTP-REQUEST).
+           The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-
+           REQUEST.
+
+   9.   The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a
+        PA-FX-FAST-REPLY.
+
+   10.  The KDC returns an AS-REP to the client, encrypted using the
+        Reply Key, containing the TGT and padata with the PA-FX-FAST-
+        REPLY.
+
+
+
+
+Richards                Expires January 15, 2009               [Page 28]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+   11.  The client authenticates the KDC and verifies the key change.
+
+        *  Uses the generated Reply Key to decrypt the PA-OTP-ENC-
+           CONFIRM in the encData of the PA-OTP-CONFIRM.
+
+        *  Authenticates the KDC by comparing the nonce value from the
+           decrypted PA-OTP-ENC-CONFIRM to that sent in the
+           corresponding PA-OTP-REQUEST.
+
+B.3.  Pin Change
+
+   This exchange follows from the point where the KDC receives the PA-
+   OTP-REQUEST from the client in the examples in Appendix B.1 and
+   Appendix B.2.  During the validation of the pre-authentication data
+   (whether encrypted nonce or encrypted timestamp), the KDC determines
+   that the user's PIN has expired and so must be changed.  The KDC
+   therefore includes a PA-OTP-PIN-CHANGE along with the PA-OTP-CONFIRM
+   in the AS-REP.
+
+   In this example, the KDC does not generate PIN values for the user
+   but requires that the user generate a new PIN that is between 4 and 8
+   characters in length.  The actual PIN change is handled by a PIN
+   change service that requires the "initial" bit to be set in the
+   service ticket.
+
+   The basic sequence of steps involved is as follows:
+
+   1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as
+        described in the previous examples.
+
+   2.   The KDC validates the pre-authentication data and authenticates
+        the user as in the previous examples but determines that the
+        user's PIN has expired.
+
+   3.   KDC constructs a ticket for a PIN change service with the
+        "initial" flag set.
+
+   4.   KDC constructs a PA-OTP-CONFIRM as in the previous examples.
+
+   5.   KDC constructs a PA-OTP-PIN-CHANGE as follows:
+
+        flags
+           0
+
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 29]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+        minLength
+           4
+
+        maxLength
+           8
+
+   6.   KDC encrypts the PA-OTP-PIN-CHANGE and PA-OTP-CONFIRM within the
+        enc-fast-rep of a PA-FX-FAST-REPLY.
+
+   7.   KDC returns an AS-REP to the client containing the ticket to the
+        PIN change service and padata containing the PA-FX-FAST-REPLY.
+
+   8.   The client authenticates the KDC as in the previous examples.
+
+   9.   The client uses the ticket in the AS-REP to call the PIN change
+        service and change the user's PIN.
+
+   10.  The client sends a second AS-REQ to the KDC containing a PA-OTP-
+        REQUEST constructed using the new PIN.
+
+   11.  The KDC responds with an AS-REP containing a TGT and a PA-OTP-
+        CONFRIM.
+
+
+B.4.  Resynchronization
+
+   This exchange follows from the point where the KDC receives the PA-
+   OTP-REQUEST from the client.  During the validation of the pre-
+   authentication data (whether encrypted nonce or encrypted timestamp),
+   the KDC determines that the local record of the token's state needs
+   to be re-synchronized with the token.  The KDC therefore includes a
+   KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set.
+
+   The sequence of steps below follows is a variation of the four pass
+   examples shown in Appendix B.1 but the same process would also work
+   in the two-pass case.
+
+   1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as
+        described in the previous examples.
+
+   2.   The KDC validates the pre-authentication data and authenticates
+        the user as in the previous examples but determines that user's
+        token requires re-synchronizing.
+
+   3.   KDC constructs a PA-OTP-CHALLENGE as follows:
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 30]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+        flags
+           nextOTP bit set
+
+        nonce
+           A randomly generated value.
+
+        etype
+           aes256-cts-hmac-sha1-96
+
+        supportedHashAlg
+           AlgorithmIdentifiers for SHA-256 and SHA-1
+
+        iterationCount
+           1024
+
+        otp-service
+           Set to a string that can be used by the client to assist the
+           user in locating the correct token.
+
+   4.   KDC returns a KRB-ERROR with an error code of
+        KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
+
+   5.   The client obtains the next OTP value from the token and records
+        the time as reported by the token.
+
+   6.   The client generates Client Key Reply Key as described in
+        Section 3.6 using SHA-256 from the list of algorithms sent by
+        the KDC and the iteration count of 100,000 as required by local
+        policy.
+
+   7.   The client constructs a PA-OTP-REQUEST as follows:
+
+        flags
+           nextOTP bit set
+
+        nonce
+           A randomly generated value.
+
+        encData
+           An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
+           under the Client Key with a key usage of
+           KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts-
+           hmac-sha1-96.  The PA-OTP-ENC-REQUEST contains the nonce from
+           the PA-OTP-CHALLENGE.
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 31]
+
+Internet-Draft           OTP Pre-authentication                July 2008
+
+
+        hashAlg
+           SHA-256
+
+        iterationCount
+           100,000
+
+        otp-time
+           The time used in the OTP calculation as reported by the OTP
+           token.
+
+   8.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req
+        of a PA-FX-FAST-REQUEST.
+
+   9.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
+        REQUEST within the padata.
+
+   10.  Authentication process now proceeds as with the standard
+        sequence.
+
+
+Author's Address
+
+   Gareth Richards
+   RSA, The Security Division of EMC
+   RSA House
+   Western Road
+   Bracknell, Berkshire  RG12 1RT
+   UK
+
+   Email: gareth.richards@rsa.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 32]
+
+Internet-Draft           OTP Pre-authentication                July 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.
+
+
+
+
+
+
+
+
+
+
+
+Richards                Expires January 15, 2009               [Page 33]
+
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt
new file mode 100644
index 000000000..96f996350
--- /dev/null
+++ b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt
@@ -0,0 +1,2266 @@
+
+
+Kerberos Working Group                                            L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Updates: 4120 (if approved)                                   S. Hartman
+Intended status: Standards Track                       Painless Security
+Expires: January 15, 2009                                  July 14, 2008
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-08
+
+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 15, 2009.
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secret of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key delivery mechanism;
+   this secure channel can be used to protect the authentication
+   exchange thus eliminate offline dictionary attacks.  With these
+   tools, it is relatively straightforward to chain multiple
+   authentication mechanisms, utilize a different key management system,
+   or support a new key agreement algorithm.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Conventions and Terminology Used in This Document  . . . . . .  5
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5
+     3.1.  Information Managed by the Pre-authentication Model  . . .  6
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 16
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 19
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 22
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 23
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 24
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 28
+       6.5.4.  Authenticated Kerberos Error Messages using
+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 30
+       6.5.5.  The Encrypted Challenge FAST Factor  . . . . . . . . . 31
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 32
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 34
+   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 35
+     A.1.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 35
+     A.2.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 35
+   Appendix B.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 35
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
+   Intellectual Property and Copyright Statements . . . . . . . . . . 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secret or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the KDC, and it can optionally deliver a reply
+   key within the protected channel.  Based on FAST, pre-authentication
+   mechanisms can extend Kerberos with ease, to support, for example,
+   password authenticated key exchange (PAKE) protocols with zero
+   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
+   authentication mechanism can be encapsulated in the FAST messages as
+   defined in Section 6.5.  A pre-authentication type carried within
+   FAST is called a FAST factor.  Creating a FAST factor is the easiest
+   path to create a new pre-authentication mechanism.  FAST factors are
+   significantly easier to analyze from a security standpoint than other
+   pre-authentication mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   authentication mechanisms outside of FAST.
+
+
+2.  Conventions and Terminology Used in This Document
+
+   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].
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the KDCs in order to authenticate the client
+   principal.  A conversation as defined here consists of all messages
+   that are necessary to complete the authentication between the client
+   and the KDC.
+
+   Lastly, this document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   padata computed using the wrong pre-authentication mechanism or
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client principal
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a
+   reply key to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key cannot
+   be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of a conversation, the KDC reply is presumed to
+   be verified using the client principal's long-term key.  Any pre-
+   authentication mechanism that sets a new reply key not based on the
+   principal's long-term secret MUST either verify the KDC reply some
+   other way or indicate that the reply is not verified.  If a mechanism
+   indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC reply that will decrypt properly.
+   So, if the client machine needs to authenticate that the user is in
+   fact the named principal, then the client machine needs to do a TGS
+   request for itself as a service.  Some pre-authentication mechanisms
+   may provide a way for the client to authenticate the KDC.  Examples
+   of this include signing the reply that can be verified using a well-
+   known public key or providing a ticket for the client machine as a
+   service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set or offered alone.  For each mechanism that is
+   offered alone, the KDC includes the pre-authentication type ID of the
+   mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where pre-authentication is desirable and where
+   the KDC needs to expose cipher text encrypted in a weak key before
+   the client has proven knowledge of that key.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to optimistically
+   guess values for the information it would normally receive from that
+   error response.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+
+
+
+Zhu & Hartman           Expires January 15, 2009                [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  It then
+   processes the padata in the request.  As mentioned in Section 3.3,
+   the KDC MAY ignore padata that is inappropriate for the configuration
+   and MUST ignore padata of an unknown type.  The KDC MUST NOT ignore
+   padata of types used in previous messages.  For example, if a KDC
+   issues a KDC_ERR_PREAUTH_REQUIRED error including padata of type x,
+   then the KDC cannot ignore padata of type x received in an AS-REQ
+   message from the client.
+
+   At this point the KDC decides whether it will issue an error or a
+   reply.  Typically a KDC will issue a reply if the client's identity
+   has been authenticated to a sufficient degree.
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Next, it generates padata for the error response, modifying
+   the pre-authentication state appropriately as each mechanism is
+   processed.  The KDC chooses the order in which it will generate
+   padata (and thus the order of padata in the response), but it needs
+   to modify the pre-authentication state consistently with the choice
+   of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the subsequent mechanisms in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.  Typically the errors with the
+   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a converstation will include
+   KDC state as discussed in Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly, when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   Typically a mechanism implementing this facility will know that the
+   other side of the exchange supports the facility before the reply key
+   is changed.  For example, a mechanism might need to learn the
+   certificate for a KDC before encrypting a new key in the public key
+   belonging to that certificate.  However, if a mechanism implementing
+   this facility wishes to modify the reply key before knowing that the
+   other party in the exchange supports the mechanism, it proposes
+   modifying the reply key.  The other party then includes a message
+   indicating that the proposal is accepted if it is understood and
+   meets policy.  In many cases it is desirable to use the new reply key
+   for client authentication and for other facilities.  Waiting for the
+   other party to accept the proposal and actually modify the reply key
+   state would add an additional round trip to the exchange.  Instead,
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   mechanism designers are encouraged to include a typed hole for
+   additional padata in the message that proposes the reply key change.
+   The padata included in the typed hole are generated assuming the new
+   reply key.  If the other party accepts the proposal, then these
+   padata are considered as an inner level.  As with the outer level,
+   one authentication set or mechanism is typically chosen for client
+   authentication, along with auxiliary mechanisms such as KDC cookies,
+   and other mechanisms are ignored.  When mechanisms include such a
+   container, the hint provided for use in authentication sets MUST
+   contain a sequence of inner mechanisms along with hints for those
+   mechanisms.  The party generating the proposal can determine whether
+   the padata were processed based on whether the proposal for the reply
+   key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  Mechanisms implementing this facility MUST
+   mark the reply key as replaced in the pre-authentication state.
+   Mechanisms implementing this facility MUST either provide a mechanism
+   to verify the KDC reply to the client or mark the reply as unverified
+   in the pre-authentication state.  Mechanisms implementing this
+   facility SHOULD NOT be used if a previous mechanism has used the
+   reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be the case for both sides to know that the facility
+   is available by the time that the new key is available to be used.
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   However, mechanism designers can use a container for padata in a
+   proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   protocols because much of the KDC exchange is not protected against
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+6.1.  Combining Keys
+
+   Frequently a weak key needs to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) -> x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.
+
+   Mechanism designers MUST specify the values for the input parameter
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there is more than one roundtrip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to avoid a multi-year standardization and deployment cycle to fix a
+   problem that is specific to a particular algorithm, when real attacks
+   do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) is
+   encrypted in a protected channel, thus they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+   authentication mechanisms.
+
+6.3.  Managing States for the KDC
+
+   Kerberos KDCs are stateless.  There is no requirement that clients
+   will choose the same KDC for the second request in a conversation.
+   Proxies or other intermediate nodes may also influence KDC selection.
+   So, each request from a client to a KDC must include sufficient
+   information that the KDC can regenerate any needed state.  This is
+   accomplished by giving the client a potentially long opaque cookie in
+   responses to include in future requests in the same conversation.
+   The KDC MAY respond that a conversation is too old and needs to
+   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            TBA
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE pdata type is defined in this section to facilitate
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   state management.  This padata is sent by the KDC when the KDC
+   requires state for a future transaction.  The client includes this
+   opaque token in the next message in the conversation.  The token may
+   be relatively large; clients MUST be prepared for tokens somewhat
+   larger than the size of all messages in a conversation.
+
+       PA_FX_COOKIE                       TBA
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains the
+   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the
+   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:
+
+      PA-FX-COOKIE ::= SEQUENCE {
+          conversationId  [0] OCTET STRING,
+             -- Contains the identifier of this conversation. This field
+             -- must contain the same value for all the messages
+             -- within the same conversation.
+          enc-binding-key [1] EncryptedData OPTIONAL,
+                          -- EncryptionKey --
+             -- This field is present when and only when a FAST
+             -- padata as defined in Section 6.5 is included.
+             -- The encrypted data, when decrypted, contains an
+             -- EncryptionKey structure.
+             -- This encryption key is encrypted using the armor key
+             -- (defined in Section 6.5.1), and the key usage for the
+             -- encryption is KEY_USAGE_FAST_BINDING_KEY.
+             -- Present only once in a converstation.
+          cookie          [2] OCTET STRING OPTIONAL,
+             -- Opaque data, for use to associate all the messages in
+             -- a single conversation between the client and the KDC.
+             -- This is generated by the KDC and the client MUST copy
+             -- the exact cookie encapsulated in a PA_FX_COOKIE data
+             -- element into the next message of the same conversation.
+          ...
+      }
+      KEY_USAGE_FAST_BINDING_KEY         TBA
+
+   The conversationId field contains a sufficiently-long rand number
+   that uniquely identifies the conversation.  If a PA_FX_COOKIE padata
+   is present in one message, a PA_FX_COOKIE structure MUST be present
+   in all subsequent messages of the same converstation between the
+   client and the KDC, with the same conversationId value.
+
+   The enc-binding-key field is present when and only when a FAST padata
+   (defined in Section 6.5) is included.  The enc-binding-key field is
+   present only once in a conversation.  It MUST be ignored if it is
+   present in a subsequent message of the same conversation.  The
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   encrypted data, when decrypted, contains an EncryptionKey structure
+   that is called the binding key.  The binding key is encrypted using
+   the armor key (defined in Section 6.5.1), and the key usage for the
+   encryption is KEY_USAGE_FAST_BINDING_KEY.
+
+   If a Kerberos FAST padata as defined in Section 6.5 is included in
+   one message, it MUST be included in all subsequent messages of the
+   same conversation.
+
+   When FAST padata as defined Section 6.5 is included, the PA-FX-COOKIE
+   padata MUST be included.
+
+   The cookie token is generated by the KDC and the client MUST copy the
+   exact cookie encapsulated in a PA_FX_COOKIE data element into the
+   next message of the same conversation.  The content of the cookie
+   field is a local matter of the KDC.  However the KDC MUST construct
+   the cookie token in such a manner that a malicious client cannot
+   subvert the authentication process by manipulating the token.  The
+   KDC implementation needs to consider expiration of tokens, key
+   rollover and other security issues in token design.  The content of
+   the cookie field is likely specific to the pre-authentication
+   mechanisms used to authenticate the client.  If a client
+   authentication response can be replayed to multiple KDCs via the
+   PA_FX_COOKIE mechanism, an expiration in the cookie is RECOMMENDED to
+   prevent the response being presented indefinitely.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to
+   identify the conversation with the client according to Section 6.5.4.
+
+        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the
+   PA_AUTHENTICATION_SET padata element.
+
+   A PA_AUTHENTICATION_SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING OPTIONAL,
+            pa-value  [2] OCTET STRING OPTIONAL,
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  The pa-value element of
+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+   first padata-value from the KDC to the client.  If the client chooses
+   this authentication set then the client MUST process this pa-value.
+   The pa-value element MUST be absent for all but the first entry in
+   the authentication set.  Clients MUST ignore pa-value for the second
+   and following entries in the authentication set.
+
+   If the client chooses an authentication set, then its AS-REQ message
+   MUST contain a PA_AUTHENTICATION_SET_SELECTED padata element.  This
+   element contains the encoding of the PA-AUTHENTICATION-SET sequence
+   received from the KDC corresponding to the authentication set that is
+   chosen.  The client MUST use the same octet values received from the
+   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
+   wise comparison to identify the selected authentication set.  The
+   PA_AUTHENTICATION_SET_SELECTED padata element MUST come before any
+   padata elements from the authentication set in the padata sequence in
+   the AS-REQ message.  The client MAY cache authentication sets from
+   prior messages and use them to construct an optimistic initial AS-
+   REQ.  If the KDC receives a PA_AUTHENTICATION_SET_SELECTED padata
+   element that does not correspond to an authentication set that it
+   would offer, then the KDC returns the
+   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The edata in this
+   error contains a sequence of padata just as for the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+      PA_AUTHENTICATION_SET_SELECTED         TBA
+      KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET TBA
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client MAY fail if the
+   authentication mechanism sets change as the conversation progresses.
+   Clients MAY assume that the hints provided in the authentication set
+   contain enough information that the client knows what user interface
+   elements need to be displayed during the entire authentication
+   conversation.  Exceptional circumstances such as expired passwords or
+   expired accounts may require that additional user interface be
+   displayed.  Mechanism designers need to carefully consider the design
+   of their hints so that the client has this information.  This way,
+   clients can construct necessary dialogue boxes or wizards based on
+   the authentication set and can present a coherent user interface.
+   Current standards for user interface do not provide an acceptable
+   experience when the client has to ask additional questions later in
+   the conversation.
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA_FX_COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC along with the first
+   message that contains a PA-AUTHENTICATION-SET, in order to keep track
+   of KDC states.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS_REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
+   in Section 6.3 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+   the METHOD-DATA.  If there is no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If the client sends the last message for a given mechanism, then the
+   KDC sends the first message for the next mechanism.  If the next
+   mechanism does not start with a KDC-side challenge, then the KDC
+   includes a padata item with the appropriate pa-type and an empty pa-
+   data.
+
+   If the KDC sends the last message for a particular mechanism, the KDC
+   also includes the first padata for the next mechanism.
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+6.5.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the entrypted timestap pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attack.  When combined
+   with encrypted timestamp, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply, freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC, instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a FAST
+   factor.  A FAST factor captures the minimal work required for
+   extending Kerberos to support a new pre-authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+   support Kerberos FAST padata.
+
+   Any FAST armor scheme MUST provide a fresh armor key for each
+   conversation.  Clients and KDCs can assume that if a message is
+   encrypted and integrity protected with a given armor key then it is
+   part of the conversation using that armor key.
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors, and the armor-
+   value as an OCTET STRING contains the description of the armor scheme
+   and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+        FX_FAST_ARMOR_AP_REQUEST           TBA
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+6.5.1.1.  Ticket-based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is the subkey in the AP-REQ authenticator.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three ways in the decreasing preference
+   order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has a trust path to the client's realm, the host
+       machine obtains a TGT by pre-authenticating intitialy the realm
+       of the host machine using the host keys.  If the client's realm
+       is different than the realm of the local host, the machine then
+       obtains a cross-realm TGT to the client's realm as the armor
+       ticket.  Otherwise, the host's primary TGT is the armor ticket.
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC4120, but the KDC has an asymmetric signing key that
+       the client can verify the binding between the public key of the
+       signing key and the expected KDC, the client can use anonymous
+       PKINIT [KRB-ANON] [RFC4556] to authenticate the KDC and obtain an
+       anonymous TGT as the armor ticket.  The armor key can be a cross-
+       team TGT obtained based on the initial primary TGT obtained using
+       anonymous PKINIT with KDC authentication.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.  The armor key can be a cross-team TGT obtained based
+       on the initial primary TGT obtained using anonymous PKINIT
+       without KDC authentication.
+
+   Because the KDC does not know if the client is able to trust the
+   ticket it has, the KDC MUST initialize the pre-authentication state
+   to an unverified KDC.
+
+6.5.2.  FAST Request
+
+   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+       PA_FX_FAST                         TBA
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+               -- MUST be absent in TGS-REQ.
+           req-checksum [1] Checksum,
+               -- Checksum performed over the type KDC-REQ-BODY for
+               -- the req-body field of the KDC-REQ structure defined in
+               -- [RFC4120]
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REA_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REA_CHKSUM          TBA
+       KEY_USAGE_FAST_ENC                 TBA
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ARMOR.
+
+        KEY_USAGE_FAST_ARMOR               TBA
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+   o  In a TGS request, the armor field in the KrbFastArmoredReq
+      structure MUST NOT be present and the subkey in the AP-REQ
+      authenticator in the PA-TGS-REQ PA-DATA MUST be present.  In this
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+      case, the armor key is that subkey in the AP-REQ authenticator.
+
+   The req-checksum field contains a checksum that is performed over the
+   type KDC-REQ-BODY for the req-body field of the KDC-REQ [RFC4120]
+   structure of the containing message.  The checksum key is the armor
+   key, and the checksum type is the required checksum type for the
+   enctype of the armor key per [RFC3961].  This checksum is included in
+   order to bind the FAST data to the outer request.  A KDC that
+   implements FAST will ignore the outer request, but including a
+   checksum is relatively cheap and may prevent confusing behavior.
+
+   The KrbFastReq structure contains the following information:
+
+        KrbFastReq ::= SEQUENCE {
+            fast-options [0] FastOptions,
+                -- Additional options.
+            padata       [1] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            req-body     [2] KDC-REQ-BODY,
+                -- Contains the KDC request body as defined in Section
+                -- 5.4.1 of [RFC4120].
+                -- This req-body field is preferred over the outer field
+                -- in the KDC request.
+             ...
+        }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- anonymous(1),
+            -- kdc-referrals(16)
+
+
+      Bits    Name          Description
+     -----------------------------------------------------------------
+      0     RESERVED        Reserved for future expansion of this field.
+      1     anonymous       Requesting the KDC to hide client names in
+                            the KDC response, as described next in this
+                            section.
+      16    kdc-referrals   Requesting the KDC to follow referrals, as
+                            described next in this section.
+
+   Bits 1 through 15 (with bit 2 and bit 15 included) are critical
+   options.  If the KDC does not support a critical option, it MUST fail
+   the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS (there is no
+   accompanying e-data defined in this document for this error code).
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   Bit 16 and onward (with bit 16 included) are non-critical options.
+   KDCs conforming to this specification ignores unknown non-critical
+   options.
+
+        KDC_ERR_UNKNOWN_FAST_OPTIONS       TBA
+
+   The anonymous Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The anonymous option is designed to complicate
+      traffic analysis.  If the anonymous option is set, the KDC
+      implementing PA_FX_FAST MUST identify the client as the anonymous
+      principal [KRB-ANON] in the KDC reply and the error response.
+      Hence this option is set by the client if it wishes to conceal the
+      client identity in the KDC response.  A conforming KD ignores the
+      client principal name in the outer KDC-REQ-BODY field, and
+      identifies the client using the cname and crealm fields in the
+      req-body field of the KrbFastReq structure.
+
+   The kdc-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] need to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-referrals
+      option is designed to minimize the number of messages that need to
+      be processed by the client.  This option is useful when, for
+      example, the client may contact the KDC via a satellite link that
+      has high network latency, or the client has limited computational
+      capabilities.  If the kdc-referrals option is set, the KDC that
+      honors this option acts as the client to follow AS referrals and
+      TGS referrals [REFERRALS], and return the service ticket to the
+      named server principal in the client request using the reply key
+      expected by the client.  The kdc-referrals option can be
+      implemented when the KDC knows the reply key.  The KDC can ignore
+      kdc-referrals option when it does not understand it or it does not
+      allow this option based on local policy.  The client SHOULD be
+      able to process the KDC responses when this option is not honored
+      by the KDC.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
+   REQ-BODY structure SHOULD be filled in for backwards compatibility
+   with KDCs that do not support FAST.  A conforming KDC ignores the
+   outer KDC-REQ-BODY field in the KDC request.
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST
+   padata element in the KDC reply.  In the case of an error, the
+   PA_FX_FAST padata is included in the KDC responses according to
+   Section 6.5.4.
+
+   The corresponding padata-value field [RFC4120] for the PA_FX_FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+   FAST-REPLY.
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 TBA
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+     KrbFastResponse ::= SEQUENCE {
+         padata      [0] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         rep-key     [1] EncryptionKey OPTIONAL,
+             -- This, if present, replaces the reply key for AS and TGS.
+             -- MUST be absent in KRB-ERROR.
+         finished    [2] KrbFastFinished OPTIONAL,
+             -- MUST be present if the client is authenticated,
+             -- absent otherwise.
+             -- Typically this is present if and only if the containing
+             -- message is the last one in a conversation.
+         ...
+     }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.
+
+   The rep-key field, if present, contains the reply key that is used to
+   encrypted the KDC reply.  The rep-key field MUST be absent in the
+   case where an error occurs.  The enctype of the rep-key is the
+   strongest mutually supported by the KDC and the client.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation; it MUST
+   be absent otherwise.  In other words, this field can only be present
+   in an AS-REP or a TGS-REP when a ticket is returned.
+
+   The KrbFastFinished structure contains the following information:
+
+        KrbFastFinished ::= SEQUENCE {
+            timestamp   [0] KerberosTime,
+            usec        [1] Microseconds,
+                -- timestamp and usec represent the time on the KDC when
+                -- the reply was generated.
+            crealm      [2] Realm,
+            cname       [3] PrincipalName,
+                -- Contains the client realm and the client name.
+            checksum    [4] Checksum,
+                -- Checksum performed over all the messages in the
+                -- conversation, except the containing message.
+                -- The checksum key is the binding key as defined in
+                -- Section 6.3, and the checksum type is the required
+                -- checksum type of the binding key.
+            ...
+        }
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+        KEY_USAGE_FAST_FINISHED            TBA
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+   referrals option is requested and honored by the KDC.
+
+   The cname and crealm fields identify the authenticated client.
+
+   The checksum field contains a checksum of all the messages in the
+   conversation prior to the containing message (the containing message
+   is excluded).  The checksum key is the binding key as defined in
+   Section 6.3, and the checksum type is the required checksum type of
+   the enctype of that key, and the key usage number is
+   KEY_USAGE_FAST_FINISHED. [[anchor9: Examples would be good here; what
+   all goes into the checksum?]]
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 6.3 MUST also be included if the KDC expects at least one
+   more message from the client in order to complete the authentication.
+
+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA_FX_FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elments that indicate acceptable pre-authentication mechanisms
+   [RFC4120] and in the KrbFastResponse structure.
+
+   If the Kerberos FAST padata is included in the request but not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection.  The Kerberos client MAY process an error
+   message without a PA-FX-FAST-REPLY, if that is only intended to
+   return better error information to the application, typically for
+   trouble-shooting purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, the
+   PA_FX_TYPED_DATA padata is included in the KrbFastResponse structure
+   to encapsulate the TYPED-DATA [RFC4120] elements.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   [RFC4556].
+
+        PA_FX_TYPED_DATA                   TBA
+            -- This is the padata element that encapsulates a TYPED-DATA
+            -- structure.
+
+   The corresponding padata-value for the PA_FX_TYPED_DATA padata type
+   contains the DER encoding of the ASN.1 type TYPED-DATA [RFC4120].
+
+6.5.5.  The Encrypted Challenge FAST Factor
+
+   The encrypted challenge FAST factor authenticates a client using the
+   client's long-term key.  This factor works similarly to the encrypted
+   time stamp pre-authentication option described in [RFC4120].  The
+   client encrypts a structure containing a timestamp in the challenge
+   key.  The challenge key is KRB-FX-CF2(long_term_key, armor_key,
+   "challengelongterm", "challengearmor").  Because the armor key is
+   fresh and random, the challenge key is fresh and random.  The only
+   purpose of the timestamp is to limit the validity of the
+   authentication so that a request cannot be replayed.  A client MAY
+   base the timestamp based on the KDC time in a KDC error and need not
+   maintain accurate time synchronization itself.  If a client bases its
+   time on an untrusted source, an attacker may trick the client into
+   producing an authentication request that is valid at some future
+   time.  The attacker may be able to use this authentication request to
+   make it appear that a client has authenticated at that future time.
+   If ticket-based armor is used, then the lifetime of the ticket will
+   limit the window in which an attacker can make the client appear to
+   have authenticated.  For many situations, the ability of an attacker
+   to cause a client to appear to have authenticated is not a
+   significant concern; the ability to avoid requiring time
+   synchronization on clients is more valuable.
+
+   The client sends a padata of type PA_ENCRYPTED_CHALLENGE the
+   corresponding padata-value contains the DER encoding of ASN.1 type
+   EncryptedChallenge.
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              --  client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+      PA_ENCRYPTED_CHALLENGE          TBA
+      KEY_USAGE_ENC_CHALLENGE_CLIENT  TBA
+      KEY_USAGE_ENC_CHALLENGE_KDC     TBA
+
+   The client includes some time stamp reasonably close to the KDC's
+   current time and encrypts it in the challenge key.  Clients MAY use
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   the current time; doing so prevents the exposure where an attacker
+   can cause a client to appear to authenticate in the future.  The
+   client sends the request including this factor.
+
+   On receiving an AS-REQ containing the PA_ENCRYPTED_CHALLENGE fast
+   factor, the KDC decrypts the timestamp.  If the decryption fails the
+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including etype-info2 in
+   the error [[anchor11: Or should this be KRB_APP_ERR_MODIFIED?]].  The
+   KDC confirms that the timestamp falls within its current clock skew
+   returning KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see
+   if the encrypted challenge is a replay.  The KDC MUST NOT consider
+   two encrypted challenges replays simply because the time stamps are
+   the same; to be a replay, the ciphertext MUST be identical.  It is
+   not clear that RFC 3961 prevents encryption systems for which an
+   attacker can transform one ciphertext into a different ciphertext
+   yielding an identical plaintext.  So, it may not be safe to base
+   replay detection on the ciphertext in the general case.  However the
+   FAST tunnel provides integrity protection so requiring ciphertext be
+   identical is secure in this instance.  Allowing clients to re-use
+   time stamps avoids requiring that clients maintain state about which
+   time stamps have been used.
+
+   If the KDC accepts the encrypted challenge, it MUST include a padata
+   element of type PA_ENCRYPTED_CHALLENGE.  The KDC encrypts its current
+   time in the challenge key.  The KDC MUST replace the reply key before
+   issuing a ticket. [[anchor12: I'd like to say that the KDC replaces
+   its reply key by this point.  However we need to decide at what
+   points the FAST mechanism for replacing the reply key can be used and
+   how that interacts with this.]]The client MUST check that the
+   timestamp decrypts properly.  The client MAY check that the timestamp
+   is in some reasonable skew of the current time.  The client MUST NOT
+   require that the timestamp be identical to the timestamp in the
+   issued credentials or the returned message.
+
+   The encrypted challenge FAST factor provides the following
+   facilities: client-authentication, KDC authentication.  It does not
+   provide the strengthening-reply-key facility.  The security
+   considerations section of this document provides an explanation why
+   the security requirements are met.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         TBA
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+7.  IANA Considerations
+
+   This document defines several new pa-data types, key usages and error
+   codes.  In addition it would be good to track which pa-data items are
+   only to be used as FAST factors.
+
+
+8.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denied of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   Because the client secrets are known only to the client and the KDC,
+   the verification of the authenticated timestamp proves the client's
+   identity, the verification of the authenticated timestamp in the KDC
+   reply proves that the expected KDC responded.  The encrypted reply
+   key is contained in the rep-key in the PA-FX-FAST-REPLY.  Therefore,
+   the authenticated timestamp FAST factor as a pre-authentication
+   mechanism offers the following facilities: client-authentication,
+   replacing-reply-key, KDC-authentication.  There is no un-
+   authenticated clear text introduced by the authenticated timestamp
+   FAST factor.
+
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+9.  Acknowledgements
+
+   Sam Hartman would like to thank the MIT Kerberos Consortium for its
+   funding of his time on this project prior to April 2008.
+
+   Several suggestions from Jeffery Hutzman based on early revisions of
+   this documents led to significant improvements of this document.
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [ID.CROSS].
+
+   Joel Webber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [REFERRALS]
+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
+              Locate Kerberos Realms",
+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
+              progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 34]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+   [SHA2]     National Institute of Standards and Technology, "Secure 
+              Hash Standard (SHS)", Federal Information Processing 
+              Standards Publication 180-2, August 2002.  
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
+              Information technology - Abstract Syntax Notation One
+              (ASN.1): Specification of basic notation.
+   
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding Rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER).              
+
+10.2.  Informative References
+
+   [EKE]      Bellovin, S. M. and M. Merritt. "Augmented 
+              Encrypted Key Exchange: A Password-Based Protocol Secure 
+              Against Dictionary Attacks and Password File Compromise". 
+              Proceedings of the 1st ACM Conference on Computer and 
+              Communications Security, ACM Press, November 1993.
+   
+   [HKDF]     Dang, Q. and P. Polk, draft-dang-nistkdf, work in 
+              progress.
+
+   [IEEE1363.2] 
+              IEEE P1363.2: Password-Based Public-Key Cryptography, 
+              2004.
+
+   [ID.CROSS]
+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+              Statement on the Operation of Kerberos in a Specific
+              System", draft-sakane-krb-cross-problem-statement-02.txt
+              (work in progress), April 2007.
+
+   [KRB-WG.SAM]
+
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+
+Appendix A.  Change History
+
+   RFC editor, please remove this section before publication.
+
+A.1.  Changes since 07
+
+      Propose replacement of authenticated timestamp with encrypted
+      challenge.  The desire to avoid clients needing time
+      synchronization and to simply the factor.
+      Add a requirement that any FAST armor scheme must provide a fresh
+      key for each conversation.  This allows us to assume that anything
+      encrypted/integrity protected in the right key is fresh and not
+      subject to cross-conversation cut&paste.
+      Removed heartbeat padata.  The KDC will double up messages if it
+      needs to; the client simply sends its message and waits for the
+      next response.
+      Define PA_AUTHENTICATION_SET_SELECTED
+      Clarify a KDC cannot ignore padata is has clamed to support
+
+A.2.  Changes since 06
+
+      Note that even for replace reply key it is likely that the side
+      using the mechanism will know that the other side supports it.
+      Since it is reasonablly unlikely we'll need a container mechanism
+      other than FAST itself, we don't need to optimize for that case.
+      So, we want to optimize for implementation simplicity.  Thus if
+      you do have such a container mechanism interacting with
+      authentication sets we'll assume that the hint need to describe
+      hints for all contained mechanisms.  This closes out a long-
+      standing issue.
+      Write up what Sam believes is the consensus on UI and prompts in
+      the authentication set: clients MAY assume that they have all the
+      UI information they need.
+
+
+Appendix B.  ASN.1 module
+
+     KerberosPreauthFramework {
+           iso(1) identified-organization(3) dod(6) internet(1)
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 35]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+           security(5) kerberosV5(2) modules(4) preauth-framework(3)
+     } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+     IMPORTS
+          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+          Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+          Microseconds, KerberosFlags
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) };
+                 -- as defined in RFC 4120.
+
+     PA-FX-COOKIE ::= SEQUENCE {
+         conversationId  [0] OCTET STRING,
+            -- Contains the identifier of this conversation. This field
+            -- must contain the same value for all the messages
+            -- within the same conversation.
+         enc-binding-key [1] EncryptedData OPTIONAL,
+                         -- EncryptionKey --
+            -- This field is present when and only when a FAST
+            -- padata as defined in Section 6.5 is included.
+            -- The encrypted data, when decrypted, contains an
+            -- EncryptionKey structure.
+            -- This encryption key is encrypted using the armor key
+            -- (defined in Section 6.5.1), and the key usage for the
+            -- encryption is KEY_USAGE_FAST_BINDING_KEY.
+            -- Present only once in a converstation.
+         cookie          [2] OCTET STRING OPTIONAL,
+            -- Opaque data, for use to associate all the messages in
+            -- a single conversation between the client and the KDC.
+            -- This is generated by the KDC and the client MUST copy
+            -- the exact cookie encapsulated in a PA_FX_COOKIE data
+            -- element into the next message of the same conversation.
+         ...
+     }
+
+     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+         pa-type      [0] Int32,
+             -- same as padata-type.
+         pa-hint      [1] OCTET STRING OPTIONAL,
+         pa-value  [2] OCTET STRING OPTIONAL,
+         ...
+     }
+
+     KrbFastArmor ::= SEQUENCE {
+         armor-type   [0] Int32,
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 36]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+             -- Type of the armor.
+         armor-value  [1] OCTET STRING,
+             -- Value of the armor.
+         ...
+     }
+
+     PA-FX-FAST-REQUEST ::= CHOICE {
+         armored-data [0] KrbFastArmoredReq,
+         ...
+     }
+
+     KrbFastArmoredReq ::= SEQUENCE {
+         armor        [0] KrbFastArmor OPTIONAL,
+             -- Contains the armor that identifies the armor key.
+             -- MUST be present in AS-REQ.
+             -- MUST be absent in TGS-REQ.
+         req-checksum [1] Checksum,
+             -- Checksum performed over the type KDC-REQ-BODY for
+             -- the req-body field of the KDC-REQ structure defined in
+             -- [RFC4120]
+             -- The checksum key is the armor key, the checksum
+             -- type is the required checksum type for the enctype of
+             -- the armor key, and the key usage number is
+             -- KEY_USAGE_FAST_REA_CHKSUM.
+         enc-fast-req [2] EncryptedData, -- KrbFastReq --
+             -- The encryption key is the armor key, and the key usage
+             -- number is KEY_USAGE_FAST_ENC.
+         ...
+     }
+
+     KrbFastReq ::= SEQUENCE {
+         fast-options [0] FastOptions,
+             -- Additional options.
+         padata       [1] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         req-body     [2] KDC-REQ-BODY,
+             -- Contains the KDC request body as defined in Section
+             -- 5.4.1 of [RFC4120].
+             -- This req-body field is preferred over the outer field
+             -- in the KDC request.
+          ...
+     }
+
+     FastOptions ::= KerberosFlags
+         -- reserved(0),
+         -- anonymous(1),
+         -- kdc-referrals(16)
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 37]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+     PA-FX-FAST-REPLY ::= CHOICE {
+         armored-data [0] KrbFastArmoredRep,
+         ...
+     }
+
+     KrbFastArmoredRep ::= SEQUENCE {
+         enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+             -- The encryption key is the armor key in the request, and
+             -- the key usage number is KEY_USAGE_FAST_REP.
+         ...
+     }
+
+     KrbFastResponse ::= SEQUENCE {
+         padata      [0] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         rep-key     [1] EncryptionKey OPTIONAL,
+             -- This, if present, replaces the reply key for AS and TGS.
+             -- MUST be absent in KRB-ERROR.
+         finished    [2] KrbFastFinished OPTIONAL,
+             -- MUST be present if the client is authenticated,
+             -- absent otherwise.
+             -- Typically this is present if and only if the containing
+             -- message is the last one in a conversation.
+         ...
+     }
+
+     KrbFastFinished ::= SEQUENCE {
+         timestamp   [0] KerberosTime,
+         usec        [1] Microseconds,
+             -- timestamp and usec represent the time on the KDC when
+             -- the reply was generated.
+         crealm      [2] Realm,
+         cname       [3] PrincipalName,
+             -- Contains the client realm and the client name.
+         checksum    [4] Checksum,
+             -- Checksum performed over all the messages in the
+             -- conversation, except the containing message.
+             -- The checksum key is the binding key as defined in
+             -- Section 6.3, and the checksum type is the required
+             -- checksum type of the binding key.
+         ...
+     }
+
+     EncryptedChallenge ::= EncryptedData
+             -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+             -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+             --  client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+     END
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 38]
+
+Internet-Draft         Kerberos Preauth Framework              July 2008
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Sam hartman
+   Painless Security
+
+   Email: hartmans-ietf@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 39]
+
+Internet-Draft         Kerberos Preauth Framework              July 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.
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman           Expires January 15, 2009               [Page 40]
+
+