1CAT Working Group M. Swift 2Internet Draft Microsoft 3Document: draft-swift-win2k-krb-referrals-00.txt October 1999 4Category: Informational 5 6 7 Generating KDC Referrals to locate Kerberos realms 8 9 10Status of this Memo 11 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 14 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 23 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 29 301. Abstract 31 32 The draft documents a new method for a Kerberos Key Distribution 33 Center (KDC) to respond to client requests for tickets as is used in 34 Microsoft's Windows 2000 implementation of Kerberos. The KDC will 35 handle requests for principals in other realms by returning either a 36 referral error or a cross-realm TGT to another realm on the referral 37 path. 38 392. Conventions used in this document 40 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in RFC-2119 [2]. 44 453. Introduction 46 47 The Kerberos TGS and AS protocols, as defined in RFC 1510 [3], 48 require that client software be able to parse principal names into a 49 realm and an account portion. However, if a site want to deploy a 50 Kerberos realm infrastructure separately from its DNS 51 infrastructure, Kerberos must be able to handle the case where the 52 client software does not know what realm contains a given service or 53 user principal name. In addition, the current protocol requires the 54 client to know the hierarchy of realms by explicitly asking for a 55 56 57Swift Category - Informational 1 58 59 KDC Referrals October 1999 60 61 62 referral to a specific realm rather than letting the KDC pick the 63 next realm on the referral path. 64 65 To rectify these problems, this draft introduces three new kinds of 66 KDC referrals: 67 68 1. AS ticket referrals, in which the client doesn�t know which realm 69 contains a user account. 70 2. TGS ticket referrals, in which the client doesn�t know which realm 71 contains a server account. 72 3. Cross realm shortcut referrals, in which the KDC chooses the next 73 path on a referral chain 74 754. Realm Organization Model 76 77 This draft assumes that the world of principals is arranged on 78 multiple levels: the realm, the enterprise, and the world. A KDC may 79 issue tickets for any principal in its realm or cross-realm tickets 80 for realms with which it has a direct trust relationship. The KDC 81 also has access to a trusted directory or name service that can 82 resolve any name from within its enterprise into a realm. This 83 trusted name service removes the need to use an untrusted DNS lookup 84 for name resolution. 85 86 For example, consider the following configuration, where lines 87 indicate trust relationships: 88 89 MS.COM 90 / \ 91 / \ 92 OFFICE.MS.COM NT.MS.COM 93 94 In this configuration, all users in the MS.COM enterprise could have 95 a principal name such as alice@ms.com, with the same realm portion. 96 In addition, servers at MS.COM should be able to have DNS host names 97 from any DNS domain independent of what Kerberos realm their 98 principal resides in. 99 1005. Principal Names 101 1025.1 Service Principal Names 103 104 The standard Kerberos model in RFC 1510 [3] gives each Kerberos 105 principal a single name. However, if a service is reachable by 106 several addresses, it may be useful for a principal to have multiple 107 names. Consider a service running on a multi-homed machine. Rather 108 than requiring a separate principal and password for each name it 109 exports, a single account with multiple names could be used. 110 111 Multiple names are also useful for services in that clients need not 112 perform DNS lookups to resolve a host name into a full DNS address. 113 Instead, the service may have a name for each of its supported host 114 names, including its IP address. Nonetheless, it is still convenient 115 116Swift Category - Informational 2 117 118 KDC Referrals October 1999 119 120 121 for the service to not have to be aware of all these names. Thus a 122 new name may be added to DNS for a service by updating DNS and the 123 KDC database without having to notify the service. In addition, it 124 implies that these aliases are globally unique: they do not include 125 a specifier dictating what domain contains the principal. Thus, an 126 alias for a server is of the form "name/name/name" and may be 127 transmitted as any name type. 128 1295.2 Client Principal Names 130 131 Similarly, a client account may also have multiple principal names. 132 More useful, though, is a globally unique name that allows 133 unification of email and security principal names. For example, all 134 users at Microsoft may have a client principal name of the form 135 "joe@MS.COM" even though the principals are contained in multiple 136 realms. This global name is again an alias for the true client 137 principal name, which is indicates what realm contains the 138 principal. Thus, accounts "alice" in the realm ntdev.MS.COM and 139 "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM". 140 This change requires a new client principal name type, as the AS-REQ 141 message only contains a single realm field, and the realm portion of 142 this name doesn't correspond to any realm security realm. Thus, the 143 entire name "alice@MS.COM" is transmitted in the client name field 144 of the AS-REQ message, with a name type of KRB-NT-ENTERPRISE- 145 PRINCIPAL. 146 147 #define KRB-NT-ENTERPRISE-PRINCIPAL 10 148 1495.3 Name Canonicalization 150 151 In order to support name aliases, the Kerberos client must 152 explicitly request the name-canonicalization KDC option (bit 12) in 153 the ticket flags for the TGS-REQ. This option is an indicator to the 154 KDC that if it fails to find the name in the local database as a 155 normal principal name, it should try to look the name up as an alias 156 both locally and in a global directory. This flag indicates to the 157 KDC that the client is prepared to receive a reply with a different 158 client or server principal name than the request. Thus, the 159 KDCOptions types is redefined as: 160 161 KDCOptions ::= BIT STRING { 162 reserved(0), 163 forwardable(1), 164 forwarded(2), 165 proxiable(3), 166 proxy(4), 167 allow-postdate(5), 168 postdated(6), 169 unused7(7), 170 renewable(8), 171 unused9(9), 172 unused10(10), 173 unused11(11), 174 175Swift Category - Informational 3 176 177 KDC Referrals October 1999 178 179 180 name-canonicalize(12), 181 renewable-ok(27), 182 enc-tkt-in-skey(28), 183 renew(30), 184 validate(31) 185 } 186 1876. Client Referrals 188 189 The simplest form of ticket referral is for a user requesting a 190 ticket using an AS-REQ. In this case, the client machine will send 191 the AS request to a convenient realm, probably either the realm of 192 the client machine or the realm portion of the client name. In the 193 case of the name Alice@MS.COM, the client may optimistically choose 194 to send the request to MS.COM. The client will send the string 195 "alice@MS.COM" in the client principal name field using the KRB-NT- 196 ENTERPRISE-PRINCIPAL name type. The KDC will try to lookup the name 197 in its local account database. If the account is present, it will 198 return a KDC reply structure with the appropriate ticket. If the 199 account is not present and the name-canonicalize option is 200 requested, it will try to lookup the entire name (Alice@MS.COM) in 201 the global directory. If this lookup is unsuccessful, it will return 202 the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, 203 it will return an error KDC_ERR_WRONG_REALM (0x44) and in the error 204 message, the cname and crealm field will contain the client name and 205 the true realm of the client. If the KDC contains the account 206 locally, it will return a normal ticket. The client name and realm 207 portions of the ticket and KDC reply message will be the client's 208 true name in the realm, not the globally unique name. 209 210 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 211 new AS request to the realm specified by the crealm field of the 212 error message. 213 2147. Server Referrals 215 216 The server referral mechanism is a bit more complex than the client 217 referral mechanism. The primary problem is that the KDC must return 218 a referral ticket rather than an error message, so it must include 219 in the TGS response information about what realm contains the 220 service. This is done by returning information about the server name 221 in the pre-auth data field of the KDC reply. 222 223 If the KDC resolves the server principal name into a principal in 224 its realm, it may return a normal ticket. If the name-canonicalize 225 bit is not set, then the KDC should only look up the name as a 226 normal principal name. Otherwise, it should search all aliases as 227 well. The server principal name in both the ticket and the KDC reply 228 should be the true server principal name instead of one of the 229 aliases. This prevents the application server from needing to know 230 about all its aliases. 231 232 233 234Swift Category - Informational 4 235 236 KDC Referrals October 1999 237 238 239 If the KDC doesn�t find the principal locally but is able to 240 resolved it into a realm from the global directory, then it should 241 return a cross-realm ticket granting ticket to the next hop on the 242 trust path towards that realm. In this case, the KDC will return the 243 server realm as a PA data type. The data itself is an ASN.1 encoded 244 structure containing the server's realm, and if known, true 245 principal name. The preauthentication data type is KRB5-PADATA- 246 SERVER-REFERRAL-INFO. 247 248 #define KRB5-PADATA-SERVER-REFERRAL-INFO 20 249 250 KERB-PA-SERV-REFERRAL ::= SEQUENCE { 251 referred-server-name[1] KERB-PRINCIPAL-NAME OPTIONAL, 252 referred-server-realm[0] KERB-REALM 253 } 254 255 The client may use the referred-server-name field to tell if it 256 already has a ticket to the server in its ticket cache. 257 258 The client can use this information to request a chain of cross- 259 realm ticket granting tickets until it reaches this realm, and can 260 then expect to receive a valid service ticket. 261 2628. Cross Realm Routing 263 264 The current Kerberos protocol requires the client libraries to 265 explicitly request a cross-realm TGT for each pair of realms on a 266 referral chain. As a result, the client machines need to be aware of 267 the trust hierarchy and of any short-cut trusts (those that aren�t 268 parent-child trusts). This requires a lot of configuration on the 269 client. Instead, the client should be able to request a TGT to the 270 target realm from each realm on the route. The KDC will determine 271 the best path for the client and return a cross-realm TGT. The 272 client software has to be aware that a request for a cross-realm TGT 273 may return a TGT for a realm different from the one requested. 274 2759. Security Considerations 276 277 The original Kerberos specification stated that the server principal 278 name in the KDC reply was the same as the server name in the 279 request. These protocol changes break that assumption, so the client 280 may be vulnerable to a denial of service attack by an attacker that 281 replays replies from previous requests. It can verify that the 282 request was one of its own by checking the client-address field or 283 authtime field, though, so the damage is limited. 284 28510. References 286 287 288 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 289 9, RFC 2026, October 1996. 290 291 292 293Swift Category - Informational 5 294 295 KDC Referrals October 1999 296 297 298 299 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 300 Levels", BCP 14, RFC 2119, March 1997 301 302 3 Kohl, J., Neuman, C., "The Kerberos Network Authentication 303 Service (V5)", RFC 1510, September 1993 304 305 30610. Author's Addresses 307 308 Michael Swift 309 Microsoft 310 One Microsoft Way 311 Redmond, Washington 312 Email: mikesw@microsoft.com 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352Swift Category - Informational 6 353 354 KDC Referrals October 1999 355 356 357 358Full Copyright Statement 359 360 Copyright (C) The Internet Society (1999). All Rights Reserved. 361 362 This document and translations of it may be copied and furnished to 363 others, and derivative works that comment on or otherwise explain it 364 or assist in its implementation may be prepared, copied, published 365 and distributed, in whole or in part, without restriction of any 366 kind, provided that the above copyright notice and this paragraph 367 are included on all such copies and derivative works. However, this 368 document itself may not be modified in any way, such as by removing 369 the copyright notice or references to the Internet Society or other 370 Internet organizations, except as needed for the purpose of 371 developing Internet standards in which case the procedures for 372 copyrights defined in the Internet Standards process must be 373 followed, or as required to translate it into languages other than 374 English. 375 376 The limited permissions granted above are perpetual and will not be 377 revoked by the Internet Society or its successors or assigns. 378 379 This document and the information contained herein is provided on an 380 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 381 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 382 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 383 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 384 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411Swift Category - Informational 7 412