diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt | 725 |
1 files changed, 0 insertions, 725 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt b/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt deleted file mode 100644 index 5845995..0000000 --- a/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt +++ /dev/null @@ -1,725 +0,0 @@ - - -Kerberos Working Group M. Swift -Internet Draft University of WA -Document: draft-ietf-krb-wg-kerberos-referrals-00.txt J. Brezak -Category: Standards Track Microsoft - J. Trostle - Cisco Systems - K. Raeburn - MIT - February 2001 - - - Generating KDC Referrals to locate Kerberos realms - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [1]. - - 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. - -1. Abstract - - The draft documents a new 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 then receive the ticket. - -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 RFC-2119 [2]. - -3. Introduction - - - - -Swift Category - Standards Track 1 - - - - - - - - - KDC Referrals February 2001 - - - Current implementations of the Kerberos AS and TGS protocols, as - defined in RFC 1510 [3], 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's host 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 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 the environment. - - Current implementations of Kerberos also have difficulty with - services on hosts that can have multiple host names (multi-homed - hosts). Traditionally, each host name would need to have a distinct - principal and a corresponding key. An extreme example of this would - be a Web server with multiple host names for each domain that it is - -Swift Category - Standards Track 2 - - - - - - - - - KDC Referrals February 2001 - - - supporting. Principal aliases allow multi-homed hosts to have a - single Kerberos principal (with a single key) that can have - identities for each distinct host name. This mechanism allows the - Kerberos client to request a service ticket for the distinct - hostname and allows the KDC to return a ticket for the single - principal that the host is using. This canonical principal name - allows the host to only have to manage a single key for all of the - identities that it supports. In addition, the client only needs to - know the realm of the canonical service name, not all of the - identities. - - This draft 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. - - To rectify these problems, this draft introduces three new kinds of - KDC referrals: - - 1. AS ticket referrals, in which the client doesn't know which realm - contains a user account. - 2. TGS ticket referrals, in which the client doesn't know which - realm contains a server account. - 3. Cross realm shortcut referrals, in which the KDC chooses the next - path on a referral chain - -4. Realm Organization Model - - This draft 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 untrusted DNS lookup for name resolution. - - For example, consider the following configuration, where lines - indicate trust relationships: - - MS.COM - / \ - / \ - OFFICE.MS.COM NT.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 - principal resides in. - -Swift Category - Standards Track 3 - - - - - - - - - KDC Referrals February 2001 - - - -5. Principal Names - -5.1 Service Principal Names - - The standard Kerberos model in RFC 1510 [3] gives each Kerberos - principal a single name. However, if a service is reachable by - several addresses, it is useful for a principal to have multiple - names. Consider a service running on a multi-homed machine. Rather - than requiring a separate principal and password for each name it - exports, a single account with multiple names could be used. - - Multiple names are also useful for services in that clients need not - perform DNS lookups to resolve a host name into a full DNS address. - Instead, the service may have a name for each of its supported host - names, including its IP address. Nonetheless, it is still convenient - for the service to not have to be aware of all these names. Thus a - new name may be added to DNS for a service by updating DNS and the - KDC database without having to notify the service. In addition, it - implies that these aliases are globally unique: they do not include - a specifier dictating what realm contains the principal. Thus, an - alias for a server is of the form "class/instance/name" and may be - transmitted as any name type. - -5.2 Client Principal Names - - Similarly, a client account may also 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 is 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 requires 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 in the client name field of the - AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. - - KRB-NT-ENTERPRISE-PRINCIPAL 10 - -5.3 Name Canonicalization - - In order to support name aliases, the Kerberos client must - explicitly request the name-canonicalization KDC option (bit 15) in - the ticket flags for the TGS-REQ. This flag indicates to the KDC - that the client is prepared to receive a reply with a different - client or server principal name than the request. Thus, the - KDCOptions types is redefined as: - - KDCOptions ::= BIT STRING { - -Swift Category - Standards Track 4 - - - - - - - - - KDC Referrals February 2001 - - - reserved(0), - forwardable(1), - forwarded(2), - proxiable(3), - proxy(4), - allow-postdate(5), - postdated(6), - unused7(7), - renewable(8), - unused9(9), - unused10(10), - unused11(11), - name-canonicalize(15), - renewable-ok(27), - enc-tkt-in-skey(28), - renew(30), - validate(31) - } - -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 request to a convenient trusted realm, either the realm of - the client machine or the realm of the client name. In the case of - the name Alice@MS.COM, the client may optimistically choose to send - the request to MS.COM. - - The client will send the string "alice@MS.COM" in the client - principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type - with the crealm set to MS.COM. The KDC will try to lookup the name - in its local account database. If the account is present in the - crealm of the request, it MUST return a KDC reply structure with the - appropriate ticket. If the account is not present in the crealm - specified in the request and the name-canonicalize flag in the - KDCoptions 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. If the lookup - is successful, it MUST return an error KDC_ERR_WRONG_REALM (0x44) - and in the error message the cname and crealm field MUST contain the - client name and the true realm of the client. If the KDC contains - the account locally, it MUST return a normal ticket. The client name - and realm portions of the ticket and KDC reply message MUST be the - client's true name in the realm, not the globally unique name. - - 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 crealm field of the - kerberos error message from the first request. This request MUST - produce a valid AS response with a ticket for the canonical user - name. The ticket MUST also include the ticket extension containing - the TE-REFERRAL-DATA with the referred-names set to the name from - - -Swift Category - Standards Track 5 - - - - - - - - - KDC Referrals February 2001 - - - the AS request. Any other error or referral will terminate the - request and result in a failed AS request. - -7. Server Referrals - - The server referral mechanism is a bit more complex than the client - referral mechanism. The primary problem is that the KDC must return - a referral ticket rather than an error message, so it will include - in the TGS response information about what realm contains the - service. This is done by returning information about the server name - in the pre-auth data field of the KDC reply. - - If the KDC resolves the server principal name into a principal in - its realm, it may return a normal ticket. If the name-canonicalize - flag in the KDCoptions is not set, then the KDC MUST only look up - the name as a normal principal name. Otherwise, it MUST search all - aliases as well. The server principal name in both the ticket and - the KDC reply MUST be the true server principal name instead of one - of the aliases. This frees the application server from needing to - know about all its aliases. - - If the name-canonicalize flag in the KDCoptions is set and the KDC - doesn't find the principal locally, the KDC can 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. - - If the KDC can determine the service principal's realm, it can - return the server realm as ticket extension data. The ticket - extension MUST be encrypted using the session key from the ticket, - and the same etype as is used to protect the TGS reply body. - - The data itself is an ASN.1 encoded structure containing the - server's realm, and if known, canonical principal name and alias - names. The first name in the sequence is the canonical principal - name. - - TE-REFERRAL-INFO 20 - - TE-REFERRAL-DATA ::= SEQUENCE { - referred-server-realm[0] KERB-REALM - referred-names[1] SEQUENCE OF - PrincipalNames OPTIONAL - } - - - The client can use this 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. - - In order to facilitate cross-realm interoperability, a client SHOULD - NOT send short names in TGS requests to the KDC. A short name is - defined as a Kerberos name that includes a DNS name that is not - fully qualified. The client MAY use forward DNS lookups to obtain - -Swift Category - Standards Track 6 - - - - - - - - - KDC Referrals February 2001 - - - the long name that corresponds to the user entered short name (the - short name will be a prefix of the corresponding long name). - - The client may use the referred-names field to tell if it already - has a ticket to the server in its ticket cache. - - The client can use this 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. - -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 machines need to be aware of the - trust hierarchy and of any short-cut trusts (those that aren't - parent-child trusts). This requires more configurations on the - client. Instead, the client should be able to request a TGT to the - target realm from each realm on the route. The KDC will determine - the best path for the client and return a cross-realm TGT. The - client has to be aware that a request for a cross-realm TGT may - return a TGT for a realm different from the one requested. - -9. Security Considerations - - The original Kerberos specification stated that the server principal - name in the KDC reply was the same as the server name in the - request. These protocol changes break that assumption, so the client - may be vulnerable to a denial of service attack by an attacker that - replays replies from previous requests. It can verify that the - request was one of its own by checking the client-address field or - authtime field, though, so the damage is limited and detectable. - - 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. - -10. Discussion - -Swift Category - Standards Track 7 - - - - - - - - - KDC Referrals February 2001 - - - - This section contains issues and suggestions that need to be - incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]: - - 1) No means to do name canonicalization if you're not - authenticating. Is it okay to require credentials in order to do - canonicalization? If so, how about this: Send a TGS_REQ for the - service name you have. If you get back a TGS_REP for a service, - great; pull out the name and throw out the credentials. If you - get back a TGS_REP for a TGT service, ask again in the specified - realm. If you get back a KRB_ERROR because policy prohibits you - from authenticating to that service, we can add to the - specification that the {realm,sname} in the KRB_ERROR must be the - canonical name, and the checksum must be used. As long as the - checksum is present, it's still a secure exchange with the KDC. - - If we have to be able to do name canonicalization without any - sort of credentials, either client-side (tickets) or server-side - (tickets automatically acquired via service key), I think we just - lose. But maybe GSSAPI should be changed if that's the case. - - 2) Can't refer to another realm and specify a different service name - to give to that realm's KDC. The local KDC can tell you a - different service name or a different realm name, but not both. - This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type - of case I've mentioned. - - Except ... the KDC-REP structure includes padata and ticket - extensions fields that are extensible. We could add a required - value to one of them -- perhaps only in the case where you return - a TGT when not asked -- that contains signed information about - the principal name to ask for in the other realm. (It would have - to be required, otherwise a man-in-the-middle could make it go - away.) Signing would be done using the session key for the TGS. - - 3) Secure canonicalization of service name in AS_REQ. If the - response is an AS_REP, we need a way to tell that the altered - server name wasn't a result of a MITM attack on the AS_REQ - message. Again, the KDC-REP extensible fields could have a new - required value added when name canonicalization happens, - indicating what the original principal name (in the AS_REQ - message) was, and signed using the same key as protects the - AS_REP. If it doesn't match what the client requested, the - messages were altered in transit. - - 4) Client name needs referral to another realm, and server name - needs canonicalization of some sort. The above fixes wouldn't - work for this case, and I'm not even sure which KDC should be - doing the canonicalization anyways. - - - The other-principal-name datum would probably look something like: - - -Swift Category - Standards Track 8 - - - - - - - - - KDC Referrals February 2001 - - - PrincipalAndNonce ::= SEQUENCE { - name[0] PrincipalName, - nonce[1] INTEGER -- copied from KDC_REQ - } - SignedPrincipal ::= SEQUENCE { - name-and-nonce[0] PrincipalAndNonce, - cksum[1] Checksum - } - {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal - {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal - - with the checksum computed over the encoding of the 'name-and-nonce' - field, and appropriate PA- or TE- numbers assigned. I don't have a - strong opinion on whether it'd be a pa-data or ticket extension; - conceptually it seems like an abuse of either, but, well, I think - I'd rather abuse them than leave the facility both in and - inadequate. - - The nonce is needed because multiple exchanges may be made with the - same key, and these extension fields aren't packed in with the other - encrypted data in the same response, so a MITM could pick apart - multiple messages and mix-and-match components. (In a TGS_REQ - exchange, a subsession key would help, but it's not required.) - - The extension field would be required to prevent a MITM from - discarding the field from a response; a flag bit in a protected part - of the message (probably in 'flags' in EncKDCRepPart) could also let - us know of a cases where the information can be omitted, namely, - when no name change is done. Perhaps the bit should be set to - indicate that a name change *was* done, and clear if it wasn't, - making the no-change case more directly compatible with RFC1510. - -11. References - - - 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997 - - 3 Kohl, J., Neuman, C., "The Kerberos Network Authentication - Service (V5)", RFC 1510, September 1993 - - -12. Author's Addresses - - Michael Swift - University of Washington - Seattle, Washington - Email: mikesw@cs.washington.edu - - John Brezak - -Swift Category - Standards Track 9 - - - - - - - - - KDC Referrals February 2001 - - - Microsoft - One Microsoft Way - Redmond, Washington - Email: jbrezak@Microsoft.com - - Jonathan Trostle - Cisco Systems - 170 W. Tasman Dr. - San Jose, CA 95134 - Email: jtrostle@cisco.com - - Kenneth Raeburn - Massachusetts Institute of Technology 77 - Massachusetts Avenue - Cambridge, Massachusetts 02139 - Email: raeburn@mit.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Swift Category - Standards Track 10 - - - - - - - - - KDC Referrals February 2001 - - - Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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." - - - - - - - - - - - - - - - - - - - - - - - - - - - -Swift Category - Standards Track 11 - - - - - - - |
