1 2 3 4NETWORK WORKING GROUP L. Zhu 5Internet-Draft P. Leach 6Updates: 4120 (if approved) K. Jaganathan 7Expires: December 5, 2006 Microsoft Corporation 8 June 3, 2006 9 10 11 Anonymity Support for Kerberos 12 draft-ietf-krb-wg-anon-00 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on December 5, 2006. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2006). 42 43Abstract 44 45 This document defines the use of anonymous Kerberos tickets for the 46 purpose of authenticating the servers and enabling secure 47 communication between a client and a server, without identifying the 48 client to the server. 49 50 51 52 53 54 55Zhu, et al. Expires December 5, 2006 [Page 1] 56 57Internet-Draft Kerberos Anonymity Support June 2006 58 59 60Table of Contents 61 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 66 5. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 Intellectual Property and Copyright Statements . . . . . . . . . . 10 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Zhu, et al. Expires December 5, 2006 [Page 2] 112 113Internet-Draft Kerberos Anonymity Support June 2006 114 115 1161. Introduction 117 118 In certain situations or environments, the Kerberos [RFC4120] client 119 may wish to authenticate a server and/or protect communications 120 without revealing its own identity. For example, consider an 121 application which provides read access to a research database, and 122 which permits queries by arbitrary requestors. A client of such a 123 service might wish to authenticate the service, to establish trust in 124 the information received from it, but might not wish to disclose its 125 identity to the service for privacy reasons. 126 127 To accomplish this, a Kerberos mechanism is specified in this 128 document by which a client requests an anonymous ticket and use that 129 to authenticate the server and secure subsequent client-server 130 communications. This provides Kerberos with functional equivalence 131 to TLS [RFC2246] in environments where Kerberos is a more attractive 132 authentication mechanism. 133 134 Using this mechanism, the client has to reveal its identity in its 135 initial request to its own Key Distribution Center (KDC) [RFC4120], 136 and then it can remain anonymous thereafter to KDCs on the cross- 137 realm authentication path, if any, and to the server with which it 138 communicates. 139 140 1412. Conventions Used in This Document 142 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 146 147 1483. Definitions 149 150 An anonymous ticket is a ticket that has all of the following 151 properties: 152 153 o The client's principal name is the anonymous Kerberos principal 154 name. The anonymous Kerberos principal name is defined as 155 follows: it is a reserved Kerberos principal name as defined in 156 [KRBNAM], the name-type is KRB_NT_RESRVED [KRBNAM], and the name- 157 string is a sequence of two KerberosString components: "RESERVED", 158 "ANONYMOUS". 159 160 o The client's realm name is the anonymous kerberos realm name. The 161 anonymous Kerberos realm name is defined as follows: it is a 162 reserved realm name as defined in [KRBNAM] and the realm name is 163 the literal "RESERVED:ANONYMOUS". 164 165 166 167Zhu, et al. Expires December 5, 2006 [Page 3] 168 169Internet-Draft Kerberos Anonymity Support June 2006 170 171 172 o The authtime field in the ticket is set to the time of the ticket 173 request, not the time of the initial authentication for the 174 principal who has made the request. 175 176 o The transited field [RFC4120] can either contain the client's 177 authentication path or contain the anonymous authentication path 178 defined as follows: the tr-type field of the transited field is 179 NO-TRANSITED-INFO (as defined later in this section) and the 180 contents field is an empty OCTET STRING. If a TGS request 181 contains an anonymous ticket with a "normal" authentication path 182 (i.e. the transited field does not contain the anonymous 183 authentication path as defined above), then the reply ticket, if 184 any, MUST NOT contain the anonymous authentication path. For 185 application servers, no transited policy is defined for the 186 anonymous authentication path, but all of the transited checks 187 would still apply if an anonymous ticket contains a "normal" 188 authentication path. Note that the "normal" authentication path 189 in an anonymous ticket can be a partial path, thus it may not be 190 sufficient to identify the originating client realm. 191 192 o It contains no information that can reveal the client's identity 193 other than, at most, the client's realm or the realm(s) on the 194 authentication path. 195 196 o The anonymous ticket flag (as defined later in this section) is 197 set. 198 199 The anonymous ticket flag is defined as bit 14 (with the first bit 200 being bit 0) in the TicketFlags: 201 202 TicketFlags ::= KerberosFlags 203 -- anonymous(14) 204 -- TicketFlags and KerberosFlags are defined in [RFC4120] 205 206 The anonymous ticket flag MUST NOT be set by implementations of this 207 specification if the ticket is not an anonymous ticket as defined in 208 this section. 209 210 The request-anonymous KDC option is defined as bit 14 (with the first 211 bit being bit 0) in the KDCOptions: 212 213 KDCOptions ::= KerberosFlags 214 -- request-anonymous(14) 215 -- KDCOptions and KerberosFlags are defined in [RFC4120] 216 217 The anonymous transited encoding type is defined as follows: 218 219 NO-TRANSITED-INFO 0 220 221 222 223Zhu, et al. Expires December 5, 2006 [Page 4] 224 225Internet-Draft Kerberos Anonymity Support June 2006 226 227 228 This transited encoding type indicates that there is no information 229 available about the authentication path. 230 231 Note that the server principal name and the server realm in a cross- 232 realm referral TGT are not dependent on whether the client is the 233 anonymous principal or not. 234 235 2364. Protocol Description 237 238 In order to request an anonymous ticket, the client sets the request- 239 anonymous KDC option in an AS or TGS request [RFC4120]. Note that if 240 the service ticket in the PA-TGS-REQ [RFC4120] is anonymous, the 241 request-anonymous KDC option MUST be set in the request. 242 243 When policy allows, the KDC issues an anonymous ticket. The KDC that 244 implements this specification MUST NOT carry information that can 245 reveal the client's identity, from the TGS request into the returned 246 anonymous ticket. 247 248 It should be noted that unless otherwise specified by this document 249 the client principal name and the client realm in the Kerberos 250 messages [RFC4120] should be the client name and client realm that 251 can uniquely identify the client principal to the KDC, not the 252 anonymous client principal name and the empty realm name. For 253 example, the client name and realm in the request body and the 254 EncKDCRepPart of the reply [RFC4120] are identifiers of the client 255 principal. In other words, the client name and client realm in the 256 EncKDCRepPart does not match with that of the returned anonymous 257 ticket. 258 259 If either local policy prohibits issuing of anonymous tickets or it 260 is inappropriate to remove information (such as restrictions) from 261 the TGS request in order to produce an anonymous ticket, the KDC MUST 262 return an error message with the code KDC_ERR_POLICY [RFC4120]. 263 264 If a client requires anonymous communication then the client should 265 check to make sure that the resulting ticket is actually anonymous by 266 checking the presence of the anonymous ticket flag. Because KDCs 267 ignore unknown KDC options, a KDC that does not understand the 268 request-anonymous KDC option will not return an error, but will 269 instead return a normal ticket. 270 271 The subsequent client and server communications then proceed as 272 described in [RFC4120]. The client principal name in the 273 Authenticator of the KRB_AP_REQ MUST be the anonymous client 274 principal name and the client realm of the Authenticator MUST be an 275 empty KerberosString [RFC4120]. 276 277 278 279Zhu, et al. Expires December 5, 2006 [Page 5] 280 281Internet-Draft Kerberos Anonymity Support June 2006 282 283 284 A server accepting such an anonymous service ticket may assume that 285 subsequent requests using the same ticket originate from the same 286 client. Requests with different tickets are likely to originate from 287 different clients. 288 289 Interoperability and backward-compatibility notes: the KDC is given 290 the task of rejecting a request for an anonymous ticket when the 291 anonymous ticket is not acceptable by the server. 292 293 2945. GSS-API Implementation Notes 295 296 At the GSS-API [RFC2743] level, the use of an anonymous principal by 297 the initiator/client requires a software change of the initiator/ 298 client software (to assert the "anonymous" flag when calling 299 GSS_Init_Sec_Context(). 300 301 GSS-API does not know or define "anonymous credentials", so the 302 (printable) name of the anonymous principal will rarely be used by or 303 relevant for the initator/client. The printable name is relevant for 304 the acceptor/server when performing an authorization decision based 305 on the name that pops up from GSS_Accept_Sec_Context() upon 306 successful security context establishment. 307 308 A GSS-API initiator MUST carefully check the resulting context 309 attributes from the initial call to GSS_Init_Sec_Context() when 310 requesting anonymity, because (as in the GSS-API tradition and for 311 backwards compatibility) anonymity is just another optional context 312 attribute. It could be that the mechanism doesn't recognize the 313 attribute at all or that anonymity is not available for some other 314 reasons -- and in that case the initiator must NOT send the initial 315 security context token to the acceptor, because it will likely reveal 316 the initiators identity to the acceptor, something that can rarely be 317 "un-done". 318 319 GSS-API defines name_type GSS_C_NT_ANONYMOUS [RFC2743] to represent 320 an anonymous identity. In addition, according to Section 2.1.1 of 321 [RFC1964] the string representation of the anonymous client principal 322 name can be "RESERVED/ANONYMOUS" or "RESERVED/ 323 ANONYMOUS@RESERVED:ANONYMOUS" with the name_type 324 GSS_KRB5_NT_PRINCIPAL_NAME. Implementations conforming to this 325 specification MUST be able to accept the GSS_C_NT_ANONYMOUS name form 326 and the GSS_KRB5_NT_PRINCIPAL_NAME name forms, and consider them 327 equivalent. 328 329 Portable initiators are RECOMMENDED to use default credentials 330 whenever possible, and request anonymity only through the input 331 anon_req_flag to GSS_Init_Sec_Context(). 332 333 334 335Zhu, et al. Expires December 5, 2006 [Page 6] 336 337Internet-Draft Kerberos Anonymity Support June 2006 338 339 3406. Security Considerations 341 342 Since KDCs ignore unknown options [RFC4120], a client requiring 343 anonymous communication needs to make sure that the ticket is 344 actually anonymous. A KDC that that does not understand the 345 anonymous option would not return an anonymous ticket. 346 347 By using the mechanism defined in this specification, the client does 348 not reveal its identity to the server but its identity may be 349 revealed to the KDC of the server principal (when the server 350 principal is in a different realm than that of the client), and any 351 KDC on the cross-realm authentication path. The Kerberos client MUST 352 verify the ticket being used are indeed anonymous before 353 communicating with the cross-realm KDC or the server, otherwise the 354 client's identity may be revealed to the server unintentionally. 355 356 In cases where specific server principals must not have access to the 357 client's identity (for example, an anonymous poll service), the KDC 358 can define server principal specific policy that insure any normal 359 service ticket can NEVER be issued to any of these server principals. 360 361 3627. Acknowledgements 363 364 The authors would like to thank the following individuals for their 365 insightful comments and fruitful discussions: Sam Hartman, Martin 366 Rex, Nicolas Williams, Jeffery Altman, Tom Yu, Chaskiel M Grundman, 367 Love Hoernquist Aestrand, Jeffery Hutzelman, and Clifford Neuman. 368 369 3708. IANA Considerations 371 372 No IANA actions are required for this document. 373 3749. Normative References 375 376 [KRBNAM] Zhu, L., "Additonal Kerberos Naming Contraints", 377 draft-ietf-krb-wg-naming, work in progress. 378 379 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 380 RFC 1964, June 1996. 381 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 385 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 386 RFC 2246, January 1999. 387 388 [RFC2743] Linn, J., "Generic Security Service Application Program 389 390 391 392Zhu, et al. Expires December 5, 2006 [Page 7] 393 394Internet-Draft Kerberos Anonymity Support June 2006 395 396 397 Interface Version 2, Update 1", RFC 2743, January 2000. 398 399 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 400 Kerberos Network Authentication Service (V5)", RFC 4120, 401 July 2005. 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448Zhu, et al. Expires December 5, 2006 [Page 8] 449 450Internet-Draft Kerberos Anonymity Support June 2006 451 452 453Authors' Addresses 454 455 Larry Zhu 456 Microsoft Corporation 457 One Microsoft Way 458 Redmond, WA 98052 459 US 460 461 Email: lzhu@microsoft.com 462 463 464 Paul Leach 465 Microsoft Corporation 466 One Microsoft Way 467 Redmond, WA 98052 468 US 469 470 Email: paulle@microsoft.com 471 472 473 Karthik Jaganathan 474 Microsoft Corporation 475 One Microsoft Way 476 Redmond, WA 98052 477 US 478 479 Email: karthikj@microsoft.com 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504Zhu, et al. Expires December 5, 2006 [Page 9] 505 506Internet-Draft Kerberos Anonymity Support June 2006 507 508 509Intellectual Property Statement 510 511 The IETF takes no position regarding the validity or scope of any 512 Intellectual Property Rights or other rights that might be claimed to 513 pertain to the implementation or use of the technology described in 514 this document or the extent to which any license under such rights 515 might or might not be available; nor does it represent that it has 516 made any independent effort to identify any such rights. Information 517 on the procedures with respect to rights in RFC documents can be 518 found in BCP 78 and BCP 79. 519 520 Copies of IPR disclosures made to the IETF Secretariat and any 521 assurances of licenses to be made available, or the result of an 522 attempt made to obtain a general license or permission for the use of 523 such proprietary rights by implementers or users of this 524 specification can be obtained from the IETF on-line IPR repository at 525 http://www.ietf.org/ipr. 526 527 The IETF invites any interested party to bring to its attention any 528 copyrights, patents or patent applications, or other proprietary 529 rights that may cover technology that may be required to implement 530 this standard. Please address the information to the IETF at 531 ietf-ipr@ietf.org. 532 533 534Disclaimer of Validity 535 536 This document and the information contained herein are provided on an 537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 539 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 540 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 541 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 543 544 545Copyright Statement 546 547 Copyright (C) The Internet Society (2006). This document is subject 548 to the rights, licenses and restrictions contained in BCP 78, and 549 except as set forth therein, the authors retain all their rights. 550 551 552Acknowledgment 553 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society. 556 557 558 559 560Zhu, et al. Expires December 5, 2006 [Page 10] 561 562 563