summaryrefslogtreecommitdiff
path: root/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt')
-rw-r--r--third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt961
1 files changed, 961 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
new file mode 100644
index 00000000000..9b41e043045
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
@@ -0,0 +1,961 @@
+
+
+NETWORK WORKING GROUP L. Zhu
+Internet-Draft K. Jaganathan
+Obsoletes: 2478 (if approved) Microsoft Corporation
+Expires: April 25, 2005 October 25, 2004
+
+
+ Generating KDC Referrals to locate Kerberos realms
+ draft-ietf-krb-wg-kerberos-referrals-05
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ 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 April 25, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+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
+ referral information to reach the realm of the target principal and
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 1]
+
+Internet-Draft KDC Referrals October 2004
+
+
+ then receive the ticket.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions Used in This Document . . . . . . . . . . . . . 5
+ 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . 6
+ 4. Realm Organization Model . . . . . . . . . . . . . . . . . . 7
+ 5. Client Name Canonicalization . . . . . . . . . . . . . . . . 8
+ 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . 9
+ 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . 10
+ 8. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . 12
+ 9. Compatibility with Earlier Implementations of Name
+ Canonicalization . . . . . . . . . . . . . . . . . . . . . . 13
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . 14
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 12.1 Normative References . . . . . . . . . . . . . . . . . . . 16
+ 12.2 Informative References . . . . . . . . . . . . . . . . . . 16
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
+ Intellectual Property and Copyright Statements . . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 2]
+
+Internet-Draft KDC Referrals October 2004
+
+
+1. Introduction
+
+ Current implementations of the Kerberos AS and TGS protocols, as
+ defined in [KRBCLR], 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 [RFC822]. 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. In order for this to work on the client, each
+ application canonicalizes the host name of the service, for example
+ by doing a DNS lookup followed by a reverse lookup using the returned
+ IP address. The returned primary host name is then used in the
+ construction of the principal name for the target service. In order
+ for the correct realm to be added for the target host, the mapping
+ table [domain_to_realm] is consulted for the realm corresponding to
+ the DNS host name. 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
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 3]
+
+Internet-Draft KDC Referrals October 2004
+
+
+ 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
+ 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. You 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 you 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 provide a mechanism for
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 4]
+
+Internet-Draft KDC Referrals October 2004
+
+
+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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 5]
+
+Internet-Draft KDC Referrals October 2004
+
+
+3. Requesting a Referral
+
+ In order to request referrals defined in section 5, 6, and 7, the
+ Kerberos client MUST explicitly request the canonicalize KDC option
+ (bit 15) [KRBCLR] 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
+
+ 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 [KRBCLR].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 6]
+
+Internet-Draft KDC Referrals October 2004
+
+
+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:
+
+ MS.COM
+ / \
+ / \
+ OFFICE.MS.COM NTDEV.MS.COM
+
+ In this configuration, all users in the MS.COM enterprise could have
+ a principal name such as alice@MS.COM, with the same realm portion.
+ In addition, servers at MS.COM should be able to have DNS host names
+ from any DNS domain independent of what Kerberos realm their
+ principals reside in.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 7]
+
+Internet-Draft KDC Referrals October 2004
+
+
+5. Client Name Canonicalization
+
+ A client account may have multiple principal names. More useful,
+ though, is a globally unique name that allows unification of email
+ and security principal names. For example, all users at MS may have
+ a client principal name of the form "joe@MS.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 NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
+ "alice@MS.COM" and "bob@MS.COM".
+
+ This utilizes a new client principal name type, as the AS-REQ message
+ only contains a single realm field, and the realm portion of this
+ name doesn't correspond to any Kerberos realm. Thus, the entire name
+ "alice@MS.COM" is transmitted as a single component in the client
+ name field of the AS-REQ message, with a name type of NT-ENTERPRISE
+ [KRBCLR]. The KDC will recognize this name type and then transform
+ the requested name into the true principal name. The true principal
+ name can be using a name type different from the requested name type.
+ Typically the true principal name will be a NT-PRINCIPAL [KRBCLR].
+
+ If the "canonicalize" KDC option is set, then the KDC MAY change the
+ client principal name and type in the AS response and ticket returned
+ from the name type of the client name in the request. For example
+ the AS request may specify a client name of "bob@MS.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.
+
+ It is assumed that the client discovers whether the KDC supports the
+ NT-ENTERPRISE name type via out of band mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 8]
+
+Internet-Draft KDC Referrals October 2004
+
+
+6. 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@MS.COM, the client
+ MAY optimistically choose to send the request to MS.COM. The realm
+ in the AS-REQ is always the name of the realm that the request is for
+ as specified in [KRBCLR].
+
+ 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 will try to lookup
+ the entire name, alice@MS.COM, using a name service. If this lookup
+ is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
+ [KRBCLR]. If the lookup is successful, it MUST return an error
+ KDC_ERR_WRONG_REALM [KRBCLR] 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 a cname returned from a referral until that
+ name is validated.
+
+ 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 from the first request. 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.
+
+ 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 transitional direct rusts between them.
+
+ The true principal name of the client, carried via the KRB_ERROR
+ message, 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 [KRBCLR].
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 9]
+
+Internet-Draft KDC Referrals October 2004
+
+
+7. Server Referrals
+
+ The primary difference in server referrals is that the KDC MUST
+ return 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 [KRBCLR], as specified later in this
+ section.
+
+ If the KDC resolves the server principal name into a principal in the
+ realm specified by the service realm name, it will return a normal
+ ticket.
+
+ If the "canonicalize" flag in the KDC options is not set, the KDC
+ MUST only look up the name as a normal principal name in the
+ specified server realm. If the "canonicalize" flag in the KDC
+ options is set and the KDC doesn't find the principal locally, 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 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
+
+ PA-SERVER-REFERRAL-DATA ::= EncryptedData
+ -- ServerReferralData --
+
+ ServerReferralData ::= SEQUENCE {
+ referred-realm [0] Realm, OPTIONAL
+ -- target realm of the referral TGT
+ true-principal-name [1] PrincipalName OPTIONAL,
+ -- true server principal name
+ ...
+ }
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 10]
+
+Internet-Draft KDC Referrals October 2004
+
+
+ Clients SHALL NOT accept a reply ticket, whose 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 referred-realm field is present if and only if the returned
+ ticket is a referral TGT, not a service ticket for the requested
+ 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.
+
+ Here is an example of a client requesting a service ticket for a
+ service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
+
+ +NC = Canonicalize KDCOption set
+ +PA-REFERRAL = returned PA-SERVER-REFERRAL
+ C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
+ S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
+ containing MS.COM as the referred realm with no
+ true-principal-name
+ C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
+ S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
+ containing NTDEV.MS.COM as the referred realm with no
+ true-principal-name
+ C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
+ S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 11]
+
+Internet-Draft KDC Referrals October 2004
+
+
+8. 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 7, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 12]
+
+Internet-Draft KDC Referrals October 2004
+
+
+9. 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) 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
+ }}
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 13]
+
+Internet-Draft KDC Referrals October 2004
+
+
+10. 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 14]
+
+Internet-Draft KDC Referrals October 2004
+
+
+11. Acknowledgments
+
+ The authors wish to thank Ken Raeburn for his comments and
+ suggestions.
+
+ Sam Hartman, Ken Raeburn, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 15]
+
+Internet-Draft KDC Referrals October 2004
+
+
+12. References
+
+12.1 Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [KRBCLR] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+ Kerberos Network Authentication Service (V5)",
+ draft-ietf-krb-wg-kerberos-clarifications. Work in
+ progress.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", RFC 822, August 1982.
+
+12.2 Informative References
+
+ [XPR] Trostle, J., Kosinovsky, I., and Swift, M.,
+ "Implementation of Crossrealm Referral Handling in the
+ MIT Kerberos Client", In Network and Distributed System
+ Security Symposium, February 2001.
+
+Authors' Addresses
+
+ Larry Zhu
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ US
+
+ EMail: lzhu@microsoft.com
+
+
+ Karthik Jaganathan
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ US
+
+ EMail: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 16]
+
+Internet-Draft KDC Referrals October 2004
+
+
+Intellectual Property Statement
+
+ 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.
+
+
+Disclaimer of Validity
+
+ 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 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.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). 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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Zhu & Jaganathan Expires April 25, 2005 [Page 17]
+
+
View Lorry Controller Status