idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 791 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8198 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 514 looks like a reference -- Missing reference section? '2' on line 404 looks like a reference -- Missing reference section? '3' on line 405 looks like a reference -- Missing reference section? '0' on line 508 looks like a reference -- Missing reference section? '4' on line 406 looks like a reference -- Missing reference section? '5' on line 407 looks like a reference -- Missing reference section? '6' on line 408 looks like a reference -- Missing reference section? '7' on line 409 looks like a reference -- Missing reference section? '8' on line 410 looks like a reference -- Missing reference section? '9' on line 411 looks like a reference -- Missing reference section? '10' on line 412 looks like a reference -- Missing reference section? '11' on line 413 looks like a reference -- Missing reference section? '12' on line 415 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group M. Swift 3 Internet Draft University of WA 4 Document: draft-ietf-krb-wg-kerberos-referrals-02.txt J. Brezak 5 Category: Standards Track Microsoft 6 J. Trostle 7 Cisco Systems 8 November 2001 10 Generating KDC Referrals to locate Kerberos realms 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1. Abstract 33 The draft documents a new method for a Kerberos Key Distribution 34 Center (KDC) to respond to client requests for kerberos tickets when 35 the client does not have detailed configuration information on the 36 realms of users or services. The KDC will handle requests for 37 principals in other realms by returning either a referral error or a 38 cross-realm TGT to another realm on the referral path. The clients 39 will use this referral information to reach the realm of the target 40 principal and then receive the ticket. 42 2. Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC-2119 [2]. 48 3. Introduction 50 Current implementations of the Kerberos AS and TGS protocols, as 51 defined in RFC 1510 [3], use principal names constructed from a 52 known user or service name and realm. A service name is typically 54 Swift Category - Standards Track 1 56 KDC Referrals November 2001 58 constructed from a name of the service and the DNS host name of the 59 computer that is providing the service. Many existing deployments of 60 Kerberos use a single Kerberos realm where all users and services 61 would be using the same realm. However in an environment where there 62 are multiple trusted Kerberos realms, the client needs to be able to 63 determine what realm a particular user or service is in before 64 making an AS or TGS request. Traditionally this requires client 65 configuration to make this possible. 67 When having to deal with multiple trusted realms, users are forced 68 to know what realm they are in before they can obtain a ticket 69 granting ticket (TGT) with an AS request. However, in many cases the 70 user would like to use a more familiar name that is not directly 71 related to the realm of their Kerberos principal name. A good 72 example of this is an RFC-822 style email name. This document 73 describes a mechanism that would allow a user to specify a user 74 principal name that is an alias for the user's Kerberos principal 75 name. In practice this would be the name that the user specifies to 76 obtain a TGT from a Kerberos KDC. The user principal name no longer 77 has a direct relationship with the Kerberos principal or realm. Thus 78 the administrator is able to move the user's principal to other 79 realms without the user having to know that it happened. 81 Once a user has a TGT, they would like to be able to access services 82 in any trusted Kerberos realm. To do this requires that the client 83 be able to determine what realm the target service's host is in 84 before making the TGS request. Current implementations of Kerberos 85 typically have a table that maps DNS host names to corresponding 86 Kerberos realms. In order for this to work on the client, each 87 application canonicalizes the host name of the service by doing a 88 DNS lookup followed by a reverse lookup using the returned IP 89 address. The returned primary host name is then used in the 90 construction of the principal name for the target service. In order 91 for the correct realm to be added for the target host, the mapping 92 table [domain_to_realm] is consulted for the realm corresponding to 93 the DNS host name. The corresponding realm is then used to complete 94 the target service principal name. 96 This traditional mechanism requires that each client have very 97 detailed configuration information about the hosts that are 98 providing services and their corresponding realms. Having client 99 side configuration information can be very costly from an 100 administration point of view - especially if there are many realms 101 and computers in the environment. 103 There are also cases where specific DNS aliases (local names) have 104 been setup in an organization to refer to a server in another 105 organization (remote server). The server has different DNS names in 106 each organization and each organization has a Kerberos realm that is 107 configured to service DNS names within that organization. Ideally 108 users are able to authenticate to the server in the other 109 organization using the local server name. This would mean that the 110 local realm be able to produce a ticket to the remote server under 112 Swift Category - Standards Track 2 114 KDC Referrals November 2001 116 its name. You could give that remote server an identity in the local 117 realm and then have that remote server maintain a separate secret 118 for each alias it is known as. Alternatively you could arrange to 119 have the local realm issue a referral to the remote realm and notify 120 the requesting client of the server's remote name that should be 121 used in order to request a ticket. 123 This draft proposes a solution for these problems and simplifies 124 administration by minimizing the configuration information needed on 125 each computer using Kerberos. Specifically it describes a mechanism 126 to allow the KDC to handle Canonicalization of names, provide for 127 principal aliases for users and services and provide a mechanism for 128 the KDC to determine the trusted realm authentication path by being 129 able to generate referrals to other realms in order to locate 130 principals. 132 To rectify these problems, this draft introduces three new kinds of 133 KDC referrals: 135 1. AS ticket referrals, in which the client doesn't know which realm 136 contains a user account. 137 2. TGS ticket referrals, in which the client doesn't know which 138 realm contains a server account. 139 3. Cross realm shortcut referrals, in which the KDC chooses the next 140 path on a referral chain 142 4. Realm Organization Model 144 This draft assumes that the world of principals is arranged on 145 multiple levels: the realm, the enterprise, and the world. A KDC may 146 issue tickets for any principal in its realm or cross-realm tickets 147 for realms with which it has a direct trust relationship. The KDC 148 also has access to a trusted name service that can resolve any name 149 from within its enterprise into a realm. This trusted name service 150 removes the need to use an untrusted DNS lookup for name resolution. 152 For example, consider the following configuration, where lines 153 indicate trust relationships: 155 MS.COM 156 / \ 157 / \ 158 OFFICE.MS.COM NT.MS.COM 160 In this configuration, all users in the MS.COM enterprise could have 161 a principal name such as alice@MS.COM, with the same realm portion. 162 In addition, servers at MS.COM should be able to have DNS host names 163 from any DNS domain independent of what Kerberos realm their 164 principal resides in. 166 5. Client Name Canonicalization 168 Swift Category - Standards Track 3 170 KDC Referrals November 2001 172 A client account may have multiple principal names. More useful, 173 though, is a globally unique name that allows unification of email 174 and security principal names. For example, all users at MS may have 175 a client principal name of the form "joe@MS.COM" even though the 176 principals are contained in multiple realms. This global name is 177 again an alias for the true client principal name, which indicates 178 what realm contains the principal. Thus, accounts "alice" in the 179 realm NT.MS.COM and "bob" in OFFICE.MS.COM may logon as 180 "alice@MS.COM" and "bob@MS.COM". 182 This utilizes a new client principal name type, as the AS-REQ 183 message only contains a single realm field, and the realm portion of 184 this name doesn't correspond to any Kerberos realm. Thus, the entire 185 name "alice@MS.COM" is transmitted in the client name field of the 186 AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. 188 KRB-NT-ENTERPRISE-PRINCIPAL 10 190 The KDC will recognize this name type and then transform the 191 requested name into the true principal name. The true principal name 192 can be using a name type different from the requested name type. 193 Typically the returned principal name will be a KRB-NT-PRINCIPAL. 194 The returned name will be the same in the AS response and in the 195 ticket. The KDC will always return a different name type than KRB- 196 NT-ENTERPRISE-PRINCIPAL. This is regardless of the presence of the 197 "canonicalize" KDC option. 199 If the "canonicalize" KDC option is set, then the KDC MAY change the 200 client principal name and type in the AS response and ticket 201 regardless of the name type of the client name in the request. For 202 example the AS request may specify a client name of "fred@MS.COM" as 203 an KRB-NT-PRINCIPAL with the "canonicalize" KDC option set and the 204 KDC will return with a client name of "104567" as a KRB-NT-UID. 206 6. Requesting a referral 208 In order to request referrals, the Kerberos client must explicitly 209 request the canonicalize KDC option (bit 15) in the KDC options for 210 the TGS-REQ. This flag indicates to the KDC that the client is 211 prepared to receive a reply that contains a principal name other 212 than the one requested. Thus, the KDCOptions types is redefined as: 214 KDCOptions ::= BIT STRING { 215 reserved(0), 216 forwardable(1), 217 forwarded(2), 218 proxiable(3), 219 proxy(4), 220 allow-postdate(5), 221 postdated(6), 222 unused7(7), 223 renewable(8), 224 unused9(9), 226 Swift Category - Standards Track 4 228 KDC Referrals November 2001 230 unused10(10), 231 unused11(11), 232 canonicalize(15), 233 renewable-ok(27), 234 enc-tkt-in-skey(28), 235 renew(30), 236 validate(31) 237 } 239 The client should expect, when sending names with the "canonicalize" 240 KDC option, that names in the KDC's reply will be different than the 241 name in the request. 243 6.1 Client Referrals 245 The simplest form of ticket referral is for a user requesting a 246 ticket using an AS-REQ. In this case, the client machine will send 247 the AS request to a convenient trusted realm, either the realm of 248 the client machine or the realm of the client name. In the case of 249 the name Alice@MS.COM, the client may optimistically choose to send 250 the request to MS.COM. The realm in the AS request is always the 251 name of the realm that the request is for as specified in the 252 standard [3]. 254 The client will send the string "alice@MS.COM" in the client 255 principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type 256 with the crealm set to MS.COM. The KDC will try to lookup the name 257 in its local account database. If the account is present in the 258 realm of the request, it MUST return a KDC reply structure with the 259 appropriate ticket. 261 If the account is not present in the realm specified in the request 262 and the "canonicalize" KDC option is set, the KDC will try to lookup 263 the entire name, Alice@MS.COM, using a name service. If this lookup 264 is unsuccessful, it MUST return the error 265 KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, it MUST 266 return an error KDC_ERR_WRONG_REALM (0x44) and in the error message 267 the crealm field will contain the the true realm of the client. The 268 client MUST NOT use a cname returned from a referral. 270 If the KDC contains the account locally and "canonicalize" KDC 271 option is not set, it MUST return a normal ticket. The client name 272 and realm portions of the ticket and KDC reply message MUST be the 273 client's true name in the realm, not the globally unique name. 275 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 276 new AS request with the same client principal name used to generate 277 the first referral to the realm specified by the realm field of the 278 kerberos error message from the first request. This request MUST 279 produce a valid AS response with a ticket for the canonical user 280 name. 282 6.2 Service Referrals 284 Swift Category - Standards Track 5 286 KDC Referrals November 2001 288 The primary problem is that the KDC must return a referral ticket 289 rather than an error message as is done in AS request referrals. 290 There needs to be a place to include in the TGS response information 291 about what realm contains the service. This is done by returning 292 information about the service name in the pre-auth data field of the 293 KDC reply. 295 If the KDC resolves the service principal name into a principal in 296 the realm specified by the service realm name, it will return a 297 normal ticket. When using canonicalization, the client can omit the 298 service realm name. If it is supplied, it is used as a hint by the 299 KDC, but the service principal lookup is not constrained to locating 300 the service principal name in that specified realm. If the 301 "canonicalize" flag in the KDC options is not set, then the KDC MUST 302 only look up the name as a normal principal name in the specified 303 service realm. 305 If the "canonicalize" flag in the KDC options is set and the KDC 306 doesn't find the principal locally, the KDC can return a cross-realm 307 ticket granting ticket to the next hop on the trust path towards a 308 realm that may be able to resolve the principal name. 310 If the KDC can determine the service principal's realm, it SHOULD 311 return the service realm as KDC supplied pre-authentication data 312 element. The preauth data MUST be encrypted using the sub-session 313 key from the authenticator if present or the session key from the 314 ticket. 316 The data itself is an ASN.1 encoded structure containing the 317 server's realm, and if known, the real principal name. 319 PA-SERVER-REFERRAL-INFO 25 321 PA-SERVER-REFERRAL :: = KERB-ENCRYPTED-DATA -- PA- 322 SERVER-REFERRAL-DATA 324 PA-SERVER-REFERRAL-DATA ::= SEQUENCE { 325 referred-server-realm[0] KERB-REALM 326 referred-name[1] PrincipalName OPTIONAL 327 } 329 If applicable to the encryption type, the key derivation value will 330 for the PA-SERVER-REFERRAL is 22. 332 In order to facilitate cross-realm interoperability, a client SHOULD 333 NOT send short names in TGS requests to the KDC. A short name is 334 defined as a Kerberos name that includes a DNS name that is not 335 fully qualified. The client MAY use a forward DNS lookups to obtain 336 the long name that corresponds to the user entered short name (the 337 short name will be a prefix of the corresponding long name). 339 Swift Category - Standards Track 6 341 KDC Referrals November 2001 343 If the referred-name field is present, the client MUST use that name 344 in a subsequent TGS request to the service realm when following the 345 referral. 347 The client will use this information to request a chain of cross- 348 realm ticket granting tickets until it reaches the realm of the 349 service, and can then expect to receive a valid service ticket. 351 However an implementation should limit the number of referrals that 352 it processes to avoid infinite referral loops. A suggested limit is 353 5 referrals before giving up. 355 This is an example of a client requesting a service ticket for a 356 service in realm NT.MS.COM where the client is in OFFICE.MS.COM. 358 +NC = Canonicalize KDCOption set 359 +PA-REFERRAL = returned PA-SERVER-REFERRAL-INFO 361 C: TGS-REQ sname=server/foo.nt.ms.com srealm=NULL +NC to 362 OFFICE.MS.COM 363 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 364 containing NT.MS.COM 365 C: TGS-REQ sname=krbtgt/NT.MS.COM@MS.COM +NC to MS.COM 366 S: TGS-REP sname=krbtgt/NT.MS.COM@MS.COM 367 C: TGS-REQ sname=server/foo.nt.ms.com srealm=NT.MS.COM +NC to 368 NT.MS.COM 369 S: TGS-REP sname=server/foo.nt.ms.com@NT.MS.COM 371 Notice that the client only specifies the service name in the 372 initial and final TGS request. 374 7. Cross Realm Routing 376 The current Kerberos protocol requires the client to explicitly 377 request a cross-realm TGT for each pair of realms on a referral 378 chain. As a result, the client need to be aware of the trust 379 hierarchy and of any short-cut trusts (those that aren't parent- 380 child trusts). Instead, the client should be able to request a TGT 381 to the target realm from each realm on the route. The KDC will 382 determine the best path for the client and return a cross-realm TGT. 383 The client has to be aware that a request for a cross-realm TGT may 384 return a TGT for a realm different from the one requested. 386 For compatibility, the client MUST use the "canonicalize" KDC option 387 if it is able to use cross-realm routing from the KDC. 389 8. Compatibility with earlier implementations of name canonicalization 391 The Microsoft Windows 2000 release included an earlier form of name- 392 canonicalization [4]. It has these differences: 394 1) The TGS referral data was returned inside of the KDC message as 395 "encrypted pre auth data". 397 Swift Category - Standards Track 7 399 KDC Referrals November 2001 401 KERB-ENCRYPTED-KDC-REPLY ::= SEQUENCE { 402 session-key[0] KERB-ENCRYPTION-KEY, 403 last-request[1] PKERB-LAST-REQUEST, 404 nonce[2] INTEGER, 405 key-expiration[3] KERB-TIME OPTIONAL, 406 flags[4] KERB-TICKET-FLAGS, 407 authtime[5] KERB-TIME, 408 starttime[6] KERB-TIME OPTIONAL, 409 endtime[7] KERB-TIME, 410 renew-until[8] KERB-TIME OPTIONAL, 411 server-realm[9] KERB-REALM, 412 server-name[10] KERB-PRINCIPAL-NAME, 413 client-addresses[11] PKERB-HOST-ADDRESSES 414 OPTIONAL, 415 encrypted-pa-data[12] SEQUENCE OF KERB-PA-DATA 416 OPTIONAL 417 } 419 2) The preauth data type definition in the encrypted preauth data is 420 as follows: 422 PA-SVR-REFERRAL-INFO 20 424 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 425 referred-server-name[1] PrincipalName OPTIONAL 426 referred-server-realm[0] KERB-REALM 427 } 429 9. Security Considerations 431 The original Kerberos specification stated that the server principal 432 name in the KDC reply was the same as the server name in the 433 request. These protocol changes break that assumption, so the client 434 may be vulnerable to a denial of service attack by an attacker that 435 replays replies from previous requests. It can verify that the 436 request was one of its own by checking the client-address field or 437 authtime field, though, so the damage is limited and detectable. 439 For the AS exchange case, it is important that the logon mechanism 440 not trust a name that has not been used to authenticate the user. 441 For example, the name that the user enters as part of a logon 442 exchange may not be the name that the user authenticates as, given 443 that the KDC_ERR_WRONG_REALM error may have been returned. The 444 relevant Kerberos naming information for logon (if any), is the 445 client name and client realm in the service ticket targeted at the 446 workstation that was obtained using the user's initial TGT. 448 How the client name and client realm is mapped into a local account 449 for logon is a local matter, but the client logon mechanism MUST use 450 additional information such as the client realm and/or authorization 451 attributes from the service ticket presented to the workstation by 453 Swift Category - Standards Track 8 455 KDC Referrals November 2001 457 the user, when mapping the logon credentials to a local account on 458 the workstation. 460 10. Discussion 462 This section contains issues and suggestions that need to be 463 incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]: 465 1) No means to do name canonicalization if you're not 466 authenticating. Is it okay to require credentials in order to do 467 canonicalization? If so, how about this: Send a TGS_REQ for the 468 service name you have. If you get back a TGS_REP for a service, 469 great; pull out the name and throw out the credentials. If you 470 get back a TGS_REP for a TGT service, ask again in the specified 471 realm. If you get back a KRB_ERROR because policy prohibits you 472 from authenticating to that service, we can add to the 473 specification that the {realm,sname} in the KRB_ERROR must be the 474 canonical name, and the checksum must be used. As long as the 475 checksum is present, it's still a secure exchange with the KDC. 477 If we have to be able to do name canonicalization without any 478 sort of credentials, either client-side (tickets) or server-side 479 (tickets automatically acquired via service key), I think we just 480 lose. But maybe GSSAPI should be changed if that's the case. 482 There are cases where GSSAPI is not able to know of a canonical 483 name even without the client name canonicalization proposed in 484 this draft. 486 2) Secure canonicalization of service name in AS_REQ. If the 487 response is an AS_REP, we need a way to tell that the altered 488 server name wasn't a result of a MITM attack on the AS_REQ 489 message. Again, the KDC-REP extensible fields could have a new 490 required value added when name canonicalization happens, 491 indicating what the original principal name (in the AS_REQ 492 message) was, and signed using the same key as protects the 493 AS_REP. If it doesn't match what the client requested, the 494 messages were altered in transit. 496 3) Client name needs referral to another realm, and server name 497 needs canonicalization of some sort. The above fixes wouldn't 498 work for this case, and I'm not even sure which KDC should be 499 doing the canonicalization anyways. 501 The other-principal-name datum would probably look something like: 503 PrincipalAndNonce ::= SEQUENCE { 504 name[0] PrincipalName, 505 nonce[1] INTEGER -- copied from KDC_REQ 506 } 507 SignedPrincipal ::= SEQUENCE { 508 name-and-nonce[0] PrincipalAndNonce, 510 Swift Category - Standards Track 9 512 KDC Referrals November 2001 514 cksum[1] Checksum 515 } 516 {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal 517 {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal 519 with the checksum computed over the encoding of the 'name-and-nonce' 520 field, and appropriate PA- or TE- numbers assigned. I don't have a 521 strong opinion on whether it'd be a pa-data or ticket extension; 522 conceptually it seems like an abuse of either, but, well, I think 523 I'd rather abuse them than leave the facility both in and 524 inadequate. 526 The nonce is needed because multiple exchanges may be made with the 527 same key, and these extension fields aren't packed in with the other 528 encrypted data in the same response, so a MITM could pick apart 529 multiple messages and mix-and-match components. (In a TGS_REQ 530 exchange, a subsession key would help, but it's not required.) 532 The extension field would be required to prevent a MITM from 533 discarding the field from a response; a flag bit in a protected part 534 of the message (probably in 'flags' in EncKDCRepPart) could also let 535 us know of a cases where the information can be omitted, namely, 536 when no name change is done. Perhaps the bit should be set to 537 indicate that a name change *was* done, and clear if it wasn't, 538 making the no-change case more directly compatible with RFC1510. 540 11. References 542 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 543 9, RFC 2026, October 1996. 545 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 546 Levels", BCP 14, RFC 2119, March 1997 548 3 Kohl, J., Neuman, C., "The Kerberos Network Authentication 549 Service (V5)", RFC 1510, September 1993 551 4 J. Trostle, I. Kosinovsky, and M. Swift,"Implementation of 552 Crossrealm Referral Handling in the MIT Kerberos Client", In 553 Network and Distributed System Security Symposium, February 2001. 555 12. Author's Addresses 557 Michael Swift 558 University of Washington 559 Seattle, Washington 560 Email: mikesw@cs.washington.edu 562 John Brezak 563 Microsoft 564 One Microsoft Way 566 Swift Category - Standards Track 10 568 KDC Referrals November 2001 570 Redmond, Washington 571 Email: jbrezak@Microsoft.com 573 Jonathan Trostle 574 Cisco Systems 575 170 W. Tasman Dr. 576 San Jose, CA 95134 577 Email: jtrostle@cisco.com 579 Swift Category - Standards Track 11 581 KDC Referrals November 2001 583 Full Copyright Statement 585 Copyright (C) The Internet Society (1999). All Rights Reserved. 587 This document and translations of it may be copied and furnished to 588 others, and derivative works that comment on or otherwise explain it 589 or assist in its implementation may be prepared, copied, published 590 and distributed, in whole or in part, without restriction of any 591 kind, provided that the above copyright notice and this paragraph 592 are included on all such copies and derivative works. However, this 593 document itself may not be modified in any way, such as by removing 594 the copyright notice or references to the Internet Society or other 595 Internet organizations, except as needed for the purpose of 596 developing Internet standards in which case the procedures for 597 copyrights defined in the Internet Standards process must be 598 followed, or as required to translate it into languages other than 599 English. 601 The limited permissions granted above are perpetual and will not be 602 revoked by the Internet Society or its successors or assigns. 604 This document and the information contained herein is provided on an 605 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 606 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 607 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 608 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 609 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 611 Swift Category - Standards Track 12