doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc6806.txt b/doc/rfc/rfc6806.txt
new file mode 100644
index 0000000..b4b292e
--- /dev/null
+++ b/doc/rfc/rfc6806.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   S. Hartman, Ed.
+Request for Comments: 6806                             Painless Security
+Updates: 4120                                                 K. Raeburn
+Category: Standards Track                                            MIT
+ISSN: 2070-1721                                                   L. Zhu
+                                                   Microsoft Corporation
+                                                           November 2012
+
+
+   Kerberos Principal Name Canonicalization and Cross-Realm Referrals
+
+Abstract
+
+   This 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
+   Ticket-Granting Ticket (TGT) to another realm on the referral path.
+   The clients will use this referral information to reach the realm of
+   the target principal and then receive the ticket.  This memo also
+   provides a mechanism for verifying that a request has not been
+   tampered with in transit.  This memo updates RFC 4120.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6806.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+
+
+
+Hartman, et al.              Standards Track                    [Page 1]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
+   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Trust Assumptions  . . . . . . . . . . . . . . . . . . . .  5
+   5.  Enterprise Principal Name Type . . . . . . . . . . . . . . . .  6
+   6.  Name Canonicalization  . . . . . . . . . . . . . . . . . . . .  7
+   7.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  9
+   8.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Cross-Realm Routing  . . . . . . . . . . . . . . . . . . . . . 11
+   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
+   11. Negotiation of FAST and Detecting Modified Requests  . . . . . 12
+   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+     13.1. Shared-Password Case . . . . . . . . . . . . . . . . . . . 16
+     13.2. Pre-Authentication Data  . . . . . . . . . . . . . . . . . 16
+   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
+   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+     15.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+     15.2. Informative References . . . . . . . . . . . . . . . . . . 17
+   Appendix A.  Compatibility with Earlier Implementations of
+                Name Canonicalization . . . . . . . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 2]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos Authentication Service (AS)
+   and Ticket-Granting Service (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 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 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 email name in the style described in [RFC5322].  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 TGT has been obtained, the user would like to be able to
+   access services in any Kerberos realm for which there is an
+   authentication path from the realm of their principal.  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.  Even if insecure
+   DNS queries were not used, managing this table is problematic.
+
+   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.
+
+
+
+Hartman, et al.              Standards Track                    [Page 3]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   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.
+
+   These two types of referrals introduce new opportunities for an
+   attacker.  In order to avoid these attacks, a mechanism is provided
+   to protect the integrity of the request between the client and KDC.
+   This mechanism complements the Flexible Authentication Secure Tunnels
+   (FAST) facility provided in [RFC6113].  A mechanism is provided to
+   negotiate the availability of FAST.  Among other benefits, this can
+   be used to protect errors generated by the referral process.
+
+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)
+                   -- other KDCOptions values omitted
+
+   When sending names with the "canonicalize" KDC option, the client
+   should expect 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].
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 4]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+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 cross-realm relationship.  The
+   KDC also has access to a trusted name service that can resolve any
+   name from within its enterprise into a realm closer along the
+   authentication path to the service.  This trusted name service
+   removes the need to use an untrusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate cross-realm 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.
+
+4.1.  Trust Assumptions
+
+   Two realms participate in any cross-realm relationship: an issuing
+   realm issues a cross-realm ticket, and a consuming realm uses this
+   ticket.  There is a degree of trust of the issuing realm by the
+   consuming realm implied by this relationship.  Whenever a service in
+   the consuming realm permits an authentication path containing the
+   issuing realm, that service trusts the issuing realm to accurately
+   represent the identity of the authenticated principal and any
+   information about the transited path.  If the consuming realm's KDC
+   sets the transited policy checked flag, the KDC is making the same
+   trust assumption that a service would.
+
+   This trust is transitive across a multi-hop authentication path.  The
+   service's realm trusts each hop along the authentication path closer
+   to the client to accurately represent the authenticated identity and
+   to accurately represent transited information.  Any KDC along this
+   path could impersonate the client.
+
+   KDC-signed or -issued authorization data often implies additional
+   trust.  The implications of such trust from a security and
+   operational standpoint is an ongoing topic of discussion during the
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 5]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   development of this specification.  As such, such discussion is out
+   of scope for this memo.
+
+   Administrators have several tools to limit trust caused by cross-
+   realm relationships.  A service or KDC can control what
+   authentication paths are acceptable.  For example, if a given realm
+   is not permitted on the authentication path for a particular client,
+   then that realm cannot affect trust placed in that client principal.
+   Consuming realms can exercise significant control by deciding what
+   principals to place on an access-control list.  If no client using a
+   given issuing realm in authentication paths is permitted to access a
+   resource, then that issuing realm is not trusted in access decisions
+   regarding that resource.
+
+   Creating a cross-realm relationship implies relatively little
+   inherent trust in the issuing realm.  Significant trust only applies
+   as principals dependent on that issuing realm are given access to
+   resources.  However, two deployment characteristics may increase the
+   trust implied by the initial cross-realm relationship.  First, a
+   number of realms provide access to any principal to some resources.
+   Access decisions involving these resources involve a degree of trust
+   in all issuing realms in the transited graph.  Secondly, many realms
+   do not constrain the set of principals to which users of that realm
+   may grant access.  In these realms, creating a cross-realm
+   relationship delegates the decision to trust that realm to users of
+   the consuming realm.  In this situation, creating the cross-realm
+   relationship is the primary trust decision point under the
+   administrator's control.
+
+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
+   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".
+
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 6]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   This utilizes a new principal name type, as the KDC-REQ message only
+   contains a single client realm (crealm) 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 an 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 host name
+   to use.  In order to avoid the need to update the host 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 those in the request.  Names MUST NOT be changed
+   in the response to a TGS request, although it is common for KDCs to
+   maintain a set of aliases for service principals.  Regardless of
+   which alias a client requests, the same service key is used.
+   However, in the TGS request, the client receives a ticket for the
+   alias requested.  Services MUST NOT make distinctions based on which
+   alias is in the issued ticket, because the service name in a ticket
+   is not cryptographically protected and can be changed by parties
+   other than the KDC.
+
+   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
+   an NT-UID [RFC4120].
+
+   (It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out-of-band mechanisms.)
+
+   See Section 11 for a mechanism to detect modification of the request
+   between the client and KDC.  However, for the best protection,
+   Flexible Authentication Secure Tunneling (FAST) [RFC6113] or another
+   mechanism that protects the entire KDC exchange SHOULD be used.
+   Clients MAY reject responses from a KDC where the client or server
+   name is changed if the KDC does not support such a mechanism.
+
+
+
+Hartman, et al.              Standards Track                    [Page 7]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   Clients SHOULD reject an AS response that changes the server name
+   unless the response is protected by such a mechanism or the new
+   server name is one explicitly expected by the client.  For example,
+   many clients permit the realm name to be changed in an AS response,
+   even if the response is not protected.  See Section 13 for a
+   discussion of the tradeoffs in allowing unprotected responses.
+
+   In order to permit authorization decisions to be made based on
+   aliases as well as the canonicalized form of a principal name, 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 80 --
+     login-aliases  [0] SEQUENCE (SIZE (1..MAX)) OF PrincipalName,
+     ...
+   }
+
+   The login-aliases field lists one or more of the aliases the
+   principal is known by.
+
+   In addition to permitting authorization based on aliases, this
+   permits user-to-user exchanges where the party receiving the
+   authenticator knows the other party only by an alias.  The recipient
+   of such an authenticator SHOULD 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 AD-
+   LOGIN-ALIAS information SHOULD be dropped in the general cross-realm
+   case.  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 MUST 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.
+
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 8]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+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 realm trusted to map principals, 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 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]; 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 MUST 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 AS request 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
+   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-REP, 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:
+
+
+
+Hartman, et al.              Standards Track                    [Page 9]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   o  Any realm indicated by the local KDC if the returned KRB-ERROR
+      message is protected by some additional means, for example, FAST
+
+   o  A list of realms configured by an administrator
+
+   o  Any realm accepted by the user when explicitly prompted
+
+   One common approach for limiting the realms from which referrals are
+   accepted is to limit referrals to realms that can construct an
+   authentication path back to the service principal of the local
+   machine.  This tends to work well when realms are generally within an
+   organization and all realms that can form an authentication path back
+   to the local machine have some reasonable level of mapping trust.
+   Deployments involving more complex trust, for example, high
+   probability of malicious realms, are likely to need more complex
+   policy and MAY need to prompt the user before accepting some
+   referrals.
+
+   There is currently no provision for changing the client name in a
+   client referral response.
+
+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.
+
+   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 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).
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 10]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   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
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM
+      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.
+
+9.  Cross-Realm Routing
+
+   RFC 4120 permits a KDC to return a closer referral ticket when a
+   cross-realm TGT is requested.  This specification extends this
+   behavior when the canonicalize flag is set.  When this flag is set, a
+   KDC MAY return a TGT for a realm closer to the service for any
+   service as discussed in the previous section.  When a client follows
+   such a referral, it includes the realm of the referred-to realm in
+   the generated request.
+
+   When the canonicalize flag is not set, the rules defined in RFC 4120
+   apply.
+
+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 recheck with
+   the local KDC to see if the name has been created locally.
+
+   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
+
+
+
+Hartman, et al.              Standards Track                   [Page 11]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   information SHOULD 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.)
+
+   Accordingly, KDC authors and maintainers should consider what factors
+   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
+   into credential expiration times in cases of referrals.
+
+11.  Negotiation of FAST and Detecting Modified Requests
+
+   Implementations of this specification MUST support the FAST
+   negotiation mechanism described in this section.  This mechanism
+   provides detection of KDC requests modified by an attacker when those
+   requests result in a reply instead of an error.  In addition, this
+   mechanism provides a secure way to detect if a KDC supports FAST.
+
+   Clients conforming to this specification MUST send new pre-
+   authentication data of type PA-REQ-ENC-PA-REP (149) in all AS
+   requests and MAY send this padata type in TGS requests.  The value of
+   this padata item SHOULD be empty and its value MUST be ignored by a
+   receiving KDC.  Sending this padata item indicates support for this
+   negotiation mechanism.  KDCs conforming to this specification must
+   always set the ticket flag enc-pa-rep (15) in all the issued tickets.
+   This ticket flag indicates KDC support for the mechanism.
+
+   The KDC response [RFC4120] is extended to support an additional field
+   containing 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
+         }
+
+   The encrypted-pa-data element MUST be absent unless either the
+   "canonicalize" KDC option is set or the PA-REQ-ENC-PA-REP padata item
+   is sent.
+
+
+
+Hartman, et al.              Standards Track                   [Page 12]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   If the PA-REQ-ENC-PA-REP padata item is sent in the request, then the
+   KDC MUST include a PA-REQ-ENC-PA-REP padata item in the encrypted-pa-
+   data item of any generated KDC reply.  The PA-REQ-ENC-PA-REP pa-data
+   value contains the checksum computed over the type AS-REQ or TGS-REQ
+   in the request.  The checksum key is the reply key and the checksum
+   type is the required checksum type for the encryption type of the
+   reply key, and the key usage number is KEY_USAGE_AS_REQ (56).  If the
+   KDC supports FAST, then the KDC MUST include a padata of type PA-FX-
+   FAST in any encrypted-pa-data sequence it generates.  The padata item
+   MUST be empty on sending, and the contents of the padata item MUST be
+   ignored on receiving.
+
+   A client MUST reject a response for which it sent PA-REQ-ENC-PA-REP
+   if the ENC-PA-REP ticket flag is set and the PA-REQ-ENC-PA-REP padata
+   item is absent or the checksum is not successfully verified.
+
+12.  IANA Considerations
+
+   PA-REQ-ENC-PA-REP has been registered in the Kerveros "Pre-
+   authentication and Typed Data" registry
+   <http://www.iana.org/assignments/kerberos-parameters>.
+
+13.  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
+   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 obtained using the user's initial TGT.  That is, rather
+   than trusting the client name in the AS response, a workstation
+   SHOULD perform an AP-REQ authentication against itself as a service
+   and use the client name in the ticket issued for its service by the
+   KDC.
+
+   How the client name and client realm are 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.
+
+   Not all fields in a KDC reply defined by RFC 4120 are protected.
+   None of the fields defined in RFC 4120 for AS request are protected,
+   and some information in a TGS request may not be protected.  The
+   referrals mechanism creates several opportunities for attack because
+
+
+
+Hartman, et al.              Standards Track                   [Page 13]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   of these unprotected fields.  FAST [RFC6113] can be used to
+   completely mitigate these issues by protecting both the KDC request
+   and response.  However, FAST requires that a client obtain an armor
+   ticket before authenticating.  Not all realms permit all clients to
+   obtain armor tickets.  Also, while it is expected to be uncommon, a
+   client might wish to use name canonicalization while obtaining an
+   armor ticket.  The mechanism described in Section 11 detects
+   modification of the request between the KDC and client, mitigating
+   some attacks.
+
+   There is a widely deployed base of implementations that use name
+   canonicalization or server referrals that use neither the negotiation
+   mechanism nor FAST.  So, implementations may be faced with only the
+   limited protection afforded by RFC 4120, by the negotiation mechanism
+   discussed in this document, or by FAST.  All three situations are
+   important to consider from a security standpoint.
+
+   An attacker cannot mount a downgrade attack against a client.  The
+   negotiation mechanism described in this document is securely
+   indicated by the presence of a ticket flag.  So, a client will detect
+   if the facility was available but not used.  It is possible for an
+   attacker to strip the indication that a client supports the
+   negotiation facility.  The client will learn from the response that
+   this happened, but the KDC will not learn that the client is
+   attacked.  So, for a single round-trip Kerberos exchange, the KDC may
+   believe the exchange was successful when the client detects an
+   attack.  Packet loss or client failure can produce a similar result;
+   this is not a significant vulnerability.  The negotiation facility
+   described in this document securely indicates the presence of FAST.
+   So, if a client wishes to use FAST when it is available, an attacker
+   cannot force the client to downgrade away from FAST.  An attacker MAY
+   be able to prevent a client from obtaining an armor ticket, for
+   example, by responding to a request for anonymous Public Key
+   Cryptography for Initial Authentication in Kerberos (PKINIT) with an
+   error response.
+
+   If FAST is used, then the communications between the client and KDC
+   are protected.  However, name canonicalization places a new
+   responsibility for mapping principals onto the KDC.  This can
+   increase the number of KDCs involved in an authentication, which adds
+   additional trusted third parties to the exchange.
+
+   If only the negotiation mechanism is used, then the request from the
+   client to the KDC is protected, but not all of the response is
+   protected.  In particular, the client name is not protected; the
+   ticket is also not protected.  An attacker can potentially modify
+   these fields.  Modification of the client name will result in a
+   denial of service.  When the client attempts to authenticate to a
+
+
+
+Hartman, et al.              Standards Track                   [Page 14]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   service (including the TGS), it constructs an AP-REQ message.  This
+   message includes a client name that MUST match the client name in the
+   ticket according to RFC 4120.  Thus, if the client name is changed,
+   the resulting ticket will fail when used.  This is undesirable
+   because the authentication is separated from the later failure, which
+   may confuse problem determination.  If the ticket is replaced with
+   another ticket, then later authentication to a service will fail
+   because the client will not know the session key for the other
+   ticket.  If the ticket is simply modified, then authentication to a
+   service will fail as with RFC 4120.  More significant attacks are
+   possible if a KDC violates the requirements of RFC 4120 and issues
+   two tickets with the same session key, or if a service violates the
+   requirements of RFC 4120 and does not check the client name against
+   that in the ticket.
+
+   There is an additional attack possible when FAST is not used against
+   KDC_ERR_WRONG_REALM.  Since this is an error response, not an AS
+   response, it is not protected by the negotiation mechanism.  Thus, an
+   attacker may be able to convince a client to authenticate to a realm
+   other than the one intended.  If an attacker is off-path, this may
+   give the attacker an advantage in attacking the client's credentials.
+   Also, see the discussion of shared passwords below.
+
+   More serious attacks are possible if no protection beyond RFC 4120 is
+   used.  In this case, neither the client name nor the service name is
+   protected between the client and KDC.  In the general case, if an
+   attacker changes the client name, then authentication will fail
+   because the client will not have the right credentials (password,
+   certificate, or other) to authenticate as the user selected by the
+   attacker.  However, see the discussion of shared passwords below.
+   Changing the server name can be a very significant attack.  For
+   example, if a user is authenticating in order to send some
+   confidential information, then the attacker could gain this
+   information by directing the user to a server under the attacker's
+   control.  The server name in the response is protected by RFC 4120,
+   but not the one in the request.  Fortunately, users are typically
+   authenticating to the "krbtgt" service in an AS exchange.  Clients
+   that permit changes to the server name when no protection beyond RFC
+   4120 is in use SHOULD carefully restrict what service names are
+   acceptable.  One critical case to consider is the password-changing
+   service.  When a user authenticates to change their password, they
+   use an AS authentication directly to the password-changing service.
+   Clients MUST restrict service name changes sufficiently that the
+   client ends up talking to the correct password-changing service.
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 15]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+13.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 sent 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, this could
+   cause the user to unknowingly use the wrong credentials.
+
+   In normal operation as described in [RFC4120], 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.
+   Using the wrong credentials may provide an advantage to an attacker.
+   For example, if a client uses one principal for administrative
+   operations and one for less privileged operation, an attacker may
+   coerce a client into using the wrong privilege to either cause some
+   later operation to succeed or fail.
+
+13.2.  Pre-Authentication 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 may be compromised
+   by the service.  This is not generally believed to be a problem.  If
+   it is, some form of explicit TGS armor could be added to FAST.
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 16]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+14.  Acknowledgments
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+   Karthik Jaganathan contributed to earlier versions.
+
+   Sam Hartman's work on this document was funded by the MIT Kerberos
+   Consortium.
+
+15.  References
+
+15.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.
+
+   [RFC6113]  Hartman, S. and L. Zhu, "A Generalized Framework for
+              Kerberos Pre-Authentication", RFC 6113, April 2011.
+
+15.2.  Informative References
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 17]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+Appendix A.  Compatibility with Earlier Implementations of Name
+             Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) Windows include an additional encrypted padata element.  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
+          }}
+
+         The referred-principal is never sent.  The referred-realm is
+         included in TGS replies and includes the realm name of the
+         realm to which the client is referred.  This information is
+         redundant with the realm in the second component of the
+         returned TGT.
+
+   2) When PKINIT [RFC4556] is used, the NT-ENTERPRISE client name is
+      encoded as a Subject Alternative Name (SAN) extension [RFC5280] in
+      the client's X.509 certificate.  The type of the otherName field
+      for this SAN extension is AnotherName [RFC5280].  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
+   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 trust 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.
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 18]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+Authors' Addresses
+
+   Sam Hartman (editor)
+   Painless Security
+
+   EMail: hartmans-ietf@mit.edu
+
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+
+   EMail: raeburn@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 19]
+