1 2 3 4NETWORK WORKING GROUP L. Zhu 5Internet-Draft P. Leach 6Updates: 4120 (if approved) K. Jaganathan 7Expires: January 17, 2007 Microsoft Corporation 8 July 16, 2006 9 10 11 Anonymity Support for Kerberos 12 draft-ietf-krb-wg-anon-01 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 January 17, 2007. 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 January 17, 2007 [Page 1] 56 57Internet-Draft Kerberos Anonymity Support July 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 . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . . . . 11 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 January 17, 2007 [Page 2] 112 113Internet-Draft Kerberos Anonymity Support July 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 The anonymous Kerberos realm name is a reserved realm name as defined 151 in [KRBNAM] and its value is the literal "RESERVED:ANONYMOUS". 152 153 The anonymous Kerberos principal name is a reserved Kerberos 154 principal name as defined in [KRBNAM], its name-type [RFC4120] is 155 KRB_NT_RESRVED [KRBNAM], and its name-string [RFC4120] is a sequence 156 of two KerberosString components: "RESERVED", "ANONYMOUS". 157 158 In this specification, only the client name or the client realm can 159 be anonymous; the server name or the server realm can not be 160 anonymous. 161 162 The transited field [RFC4120] of a ticket is an anonymous 163 authentication path if the tr-type field of the TransitedEncoding 164 165 166 167Zhu, et al. Expires January 17, 2007 [Page 3] 168 169Internet-Draft Kerberos Anonymity Support July 2006 170 171 172 type [RFC4120] is NO-TRANSITED-INFO and the contents field is an 173 empty OCTET STRING. 174 175 NO-TRANSITED-INFO TBA 176 177 This transited encoding type indicates that there is no information 178 available about the authentication path. 179 180 The anonymous ticket flag is defined as bit TBA (with the first bit 181 being bit 0) in the TicketFlags: 182 183 TicketFlags ::= KerberosFlags 184 -- anonymous(TBA) 185 -- TicketFlags and KerberosFlags are defined in [RFC4120] 186 187 An anonymous ticket is a ticket that has all of the following 188 properties: 189 190 o The cname field [RFC4120] contains the anonymous Kerberos 191 principal name. 192 193 o The crealm field [RFC4120] contains either the realm name of the 194 client who made the request or the anonymous kerberos realm name, 195 based on the local policy of the KDC. 196 197 o The transited field [RFC4120] can contain either the client's 198 "normal" authentication path according to Section 3.3.3.2 of 199 [RFC4120] or the anonymous authentication path. 200 201 o It contains no information that can reveal the client's identity. 202 However the ticket can contain the client realm and the realms on 203 the authentication path, and the authorization data may provide 204 additional information of the client. For example, an anonymous 205 principal that is only identifiable within a particular group of 206 users can be implemented by using authorization data. 207 208 o The anonymous ticket flag is set. 209 210 Notes: The anonymous ticket flag MUST NOT be set by implementations 211 of this specification if the ticket is not an anonymous ticket. The 212 server principal name and the server realm in a cross-realm referral 213 TGT are not dependent on whether the client is the anonymous 214 principal or not. 215 216 The request-anonymous KDC option is defined as bit TBA (with the 217 first bit being bit 0) in the KDCOptions: 218 219 220 221 222 223Zhu, et al. Expires January 17, 2007 [Page 4] 224 225Internet-Draft Kerberos Anonymity Support July 2006 226 227 228 KDCOptions ::= KerberosFlags 229 -- request-anonymous(TBA) 230 -- KDCOptions and KerberosFlags are defined in [RFC4120] 231 232 2334. Protocol Description 234 235 In order to request an anonymous ticket, the client sets the request- 236 anonymous KDC option in an Authentication Exchange (AS) or Ticket 237 Granting Service (TGS) request [RFC4120]. The client can request an 238 anonymous TGT based on a normal TGT. Note that if the ticket in the 239 PA-TGS-REQ [RFC4120] is anonymous, the request-anonymous KDC option 240 MUST be set in the request. 241 242 When propagating authorization data, care MUST be taken by the TGS to 243 ensure that the client confidentiality is not violated: the TGS MUST 244 either fail the request or remove authorization data that may reveal 245 the client's identity. An optional authorization element unknown by 246 the TGS MUST be removed if it can be ignored (such as ones enclosed 247 in the AD-IF-RELEVANT or the AD-KDCIssued containers [RFC4120]). The 248 TGS can strip critical unknown authorization data if such data do not 249 convey any rights based on the requesting client's identity. Here is 250 a table of the known authorization-data elements, flagged with 251 whether they interfere with client anonymity and recommendations for 252 how to process them. 253 254 ad-type References Can Breach Confidentiality? 255 ------------------------------------------------------------------ 256 AD-IF-RELEVANT RFC4120 Yes, remove if unknown 257 AD-KDCIssued RFC4120 Yes, remove if unknown 258 AD-AND-OR RFC4120 Yes, remove if unknown 259 AD-MANDATORY-FOR-KDC RFC4120 Yes, fail the request if unknown 260 261 If it is inappropriate to remove an authorization element from the 262 TGS request in order to produce an anonymous ticket, the KDC MUST 263 return an error message with the code KDC_ERR_POLICY [RFC4120]. 264 265 When policy allows, the KDC issues an anonymous ticket. The client 266 realm in the anonymous ticket can be the anonymous realm name based 267 on local policy. The client name and the client realm the 268 EncKDCRepPart of the reply [RFC4120] MUST match with the 269 corresponding client name and the client realm of the anonymous reply 270 ticket. The client then MUST use the client name and the client 271 realm returned in the EncKDCRepPart in subsequent message exchanges 272 when using that anonymous ticket. 273 274 If there is a key known by both the client and the KDC for encrypting 275 the KDC reply, the cname field in the request [RFC4120] can be 276 277 278 279Zhu, et al. Expires January 17, 2007 [Page 5] 280 281Internet-Draft Kerberos Anonymity Support July 2006 282 283 284 anonymous. If the client is anonymous and the KDC does not have a 285 key to encrypt the reply, the KDC MUST return an error message with 286 the code KDC_ERR_NULL_KEY [RFC4120]. For AS exchange, if the reply 287 key is selected from the client keys (for example, as described in 288 Section 3.1.3 of [RFC4120]), then the client principal MUST NOT be 289 anonymous. The client can use the client keys to request an 290 anonymous TGT in the AS request. The anonymous client name, for 291 example, can be used in conjunction with PKINIT [RFC4556]. An 292 anonymous PKINIT client can authenticate the KDC based on the KDC 293 certificate. For TGS exchange, the reply key is selected according 294 to Section 3.3.3 of [RFC4120] as normal. 295 296 The KDC fills out the transited field of the anonymous ticket in the 297 reply as follows: If the service ticket in a TGS request is an 298 anonymous ticket with a "normal" authentication path, then the 299 authentication path in the reply ticket MUST also contain a "normal" 300 authentication path: the TGS MUST add the name of the previous realm. 301 However, if the service ticket in a TGS request is an anonymous 302 ticket with an anonymous authentication path, then the reply ticket 303 can contain either an anonymous authentication path or a "normal" 304 authentication path, based on the local policy of the KDC. Thus a 305 "normal" authentication path in an anonymous ticket can be a partial 306 path: it may not include all the intermediate realms on the 307 authentication path. 308 309 The KDC fills out the authtime field of the anonymous ticket in the 310 reply as follows: If the anonymous ticket is returned in an AS 311 exchange, the authtime field of the ticket contains the request time. 312 If the anonymous ticket is returned in a TGS exchange, the authtime 313 field contains the time of the initial authentication for the 314 principal who has made the request. An anonymous ticket can be 315 renewed, and the authtime field of a renewed ticket is the authtime 316 in the anonymous ticket that the renewed ticket was based on. 317 318 If a client requires anonymous communication then the client MUST 319 check to make sure that the ticket in the reply is actually anonymous 320 by checking the presence of the anonymous ticket flag. Because KDCs 321 ignore unknown KDC options, a KDC that does not understand the 322 request-anonymous KDC option will not return an error, but will 323 instead return a normal ticket. 324 325 The subsequent client and server communications then proceed as 326 described in [RFC4120]. No transited policy checking is needed for 327 the anonymous authentication path. However, transited policy checks 328 defined in Section 2.7 of [RFC4120] would apply to an anonymous 329 ticket that contains a "normal" authentication path. 330 331 A server accepting an anonymous service ticket may assume that 332 333 334 335Zhu, et al. Expires January 17, 2007 [Page 6] 336 337Internet-Draft Kerberos Anonymity Support July 2006 338 339 340 subsequent requests using the same ticket originate from the same 341 client. Requests with different tickets are likely to originate from 342 different clients. 343 344 Interoperability and backward-compatibility notes: the KDC is given 345 the task of rejecting a request for an anonymous ticket when the 346 anonymous ticket is not acceptable by the server. 347 348 3495. GSS-API Implementation Notes 350 351 At the GSS-API [RFC2743] level, the use of an anonymous principal by 352 the initiator/client requires a software change of the initiator/ 353 client software (to assert the "anonymous" flag when calling 354 GSS_Init_Sec_Context(). 355 356 GSS-API does not know or define "anonymous credentials", so the 357 (printable) name of the anonymous principal will rarely be used by or 358 relevant for the initator/client. The printable name is relevant for 359 the acceptor/server when performing an authorization decision based 360 on the name that pops up from GSS_Accept_Sec_Context() upon 361 successful security context establishment. 362 363 A GSS-API initiator MUST carefully check the resulting context 364 attributes from the initial call to GSS_Init_Sec_Context() when 365 requesting anonymity, because (as in the GSS-API tradition and for 366 backwards compatibility) anonymity is just another optional context 367 attribute. It could be that the mechanism doesn't recognize the 368 attribute at all or that anonymity is not available for some other 369 reasons -- and in that case the initiator must NOT send the initial 370 security context token to the acceptor, because it will likely reveal 371 the initiators identity to the acceptor, something that can rarely be 372 "un-done". 373 374 GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to 375 represent the anonymous identity. In addition, Section 2.1.1 of 376 [RFC1964] defines the single string representation of a Kerberos 377 principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. For 378 the anonymous principals, the name component within the exportable 379 name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm 380 name according to Section 2.1.1 of [RFC1964]. In this specification 381 only the client/initiator can be the anonymous identity. 382 383 Portable initiators are RECOMMENDED to use default credentials 384 whenever possible, and request anonymity only through the input 385 anon_req_flag [RFC2743] to GSS_Init_Sec_Context(). 386 387 388 389 390 391Zhu, et al. Expires January 17, 2007 [Page 7] 392 393Internet-Draft Kerberos Anonymity Support July 2006 394 395 3966. Security Considerations 397 398 Since KDCs ignore unknown options [RFC4120], a client requiring 399 anonymous communication needs to make sure that the ticket is 400 actually anonymous. A KDC that that does not understand the 401 anonymous option would not return an anonymous ticket. 402 403 By using the mechanism defined in this specification, the client does 404 not reveal its identity to the server but its identity may be 405 revealed to the KDC of the server principal (when the server 406 principal is in a different realm than that of the client), and any 407 KDC on the cross-realm authentication path. The Kerberos client MUST 408 verify the ticket being used is indeed anonymous before communicating 409 with the cross-realm KDC or the server, otherwise the client's 410 identity may be revealed to the server unintentionally. 411 412 In cases where specific server principals must not have access to the 413 client's identity (for example, an anonymous poll service), the KDC 414 can define server principal specific policy that insure any normal 415 service ticket can NEVER be issued to any of these server principals. 416 417 If the KDC that issued an anonymous ticket were to maintain records 418 of the association of identities to an anonymous ticket, then someone 419 obtaining such records could breach the anonymity. Additionally, the 420 implementation of most (for now all) KDC's respond to requests at the 421 time that they are received. Traffic analasys on the connection to 422 the KDC will allow an attacket to match client identities to 423 anonymous tickets issued. Because there are plaintext parts of the 424 tickets that are exposed on the wire, such matching by a third party 425 observer is relatively straigtforward. 426 427 4287. Acknowledgements 429 430 The authors would like to thank the following individuals for their 431 insightful comments and fruitful discussions: Sam Hartman, Clifford 432 Neuman, Martin Rex, Nicolas Williams, Jeffery Altman, Tom Yu, 433 Chaskiel M Grundman, Love Hoernquist Aestrand, and Jeffery Hutzelman. 434 435 4368. IANA Considerations 437 438 No IANA actions are required for this document. 439 4409. Normative References 441 442 [KRBNAM] Zhu, L., "Additonal Kerberos Naming Contraints", 443 draft-ietf-krb-wg-naming, work in progress. 444 445 446 447Zhu, et al. Expires January 17, 2007 [Page 8] 448 449Internet-Draft Kerberos Anonymity Support July 2006 450 451 452 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 453 RFC 1964, June 1996. 454 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 457 458 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 459 RFC 2246, January 1999. 460 461 [RFC2743] Linn, J., "Generic Security Service Application Program 462 Interface Version 2, Update 1", RFC 2743, January 2000. 463 464 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 465 Kerberos Network Authentication Service (V5)", RFC 4120, 466 July 2005. 467 468 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 469 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503Zhu, et al. Expires January 17, 2007 [Page 9] 504 505Internet-Draft Kerberos Anonymity Support July 2006 506 507 508Authors' Addresses 509 510 Larry Zhu 511 Microsoft Corporation 512 One Microsoft Way 513 Redmond, WA 98052 514 US 515 516 Email: lzhu@microsoft.com 517 518 519 Paul Leach 520 Microsoft Corporation 521 One Microsoft Way 522 Redmond, WA 98052 523 US 524 525 Email: paulle@microsoft.com 526 527 528 Karthik Jaganathan 529 Microsoft Corporation 530 One Microsoft Way 531 Redmond, WA 98052 532 US 533 534 Email: karthikj@microsoft.com 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559Zhu, et al. Expires January 17, 2007 [Page 10] 560 561Internet-Draft Kerberos Anonymity Support July 2006 562 563 564Intellectual Property Statement 565 566 The IETF takes no position regarding the validity or scope of any 567 Intellectual Property Rights or other rights that might be claimed to 568 pertain to the implementation or use of the technology described in 569 this document or the extent to which any license under such rights 570 might or might not be available; nor does it represent that it has 571 made any independent effort to identify any such rights. Information 572 on the procedures with respect to rights in RFC documents can be 573 found in BCP 78 and BCP 79. 574 575 Copies of IPR disclosures made to the IETF Secretariat and any 576 assurances of licenses to be made available, or the result of an 577 attempt made to obtain a general license or permission for the use of 578 such proprietary rights by implementers or users of this 579 specification can be obtained from the IETF on-line IPR repository at 580 http://www.ietf.org/ipr. 581 582 The IETF invites any interested party to bring to its attention any 583 copyrights, patents or patent applications, or other proprietary 584 rights that may cover technology that may be required to implement 585 this standard. Please address the information to the IETF at 586 ietf-ipr@ietf.org. 587 588 589Disclaimer of Validity 590 591 This document and the information contained herein are provided on an 592 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 593 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 594 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 595 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 596 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 598 599 600Copyright Statement 601 602 Copyright (C) The Internet Society (2006). This document is subject 603 to the rights, licenses and restrictions contained in BCP 78, and 604 except as set forth therein, the authors retain all their rights. 605 606 607Acknowledgment 608 609 Funding for the RFC Editor function is currently provided by the 610 Internet Society. 611 612 613 614 615Zhu, et al. Expires January 17, 2007 [Page 11] 616 617 618