idnits 2.17.1 draft-ietf-krb-wg-anon-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 409. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC4120, updated by this document, for RFC5378 checks: 2002-02-27) -- 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 (July 16, 2006) is 6465 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) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft P. Leach 4 Updates: 4120 (if approved) K. Jaganathan 5 Expires: January 17, 2007 Microsoft Corporation 6 July 16, 2006 8 Anonymity Support for Kerberos 9 draft-ietf-krb-wg-anon-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 17, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines the use of anonymous Kerberos tickets for the 43 purpose of authenticating the servers and enabling secure 44 communication between a client and a server, without identifying the 45 client to the server. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 51 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 53 5. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 7 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 57 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 59 Intellectual Property and Copyright Statements . . . . . . . . . . 11 61 1. Introduction 63 In certain situations or environments, the Kerberos [RFC4120] client 64 may wish to authenticate a server and/or protect communications 65 without revealing its own identity. For example, consider an 66 application which provides read access to a research database, and 67 which permits queries by arbitrary requestors. A client of such a 68 service might wish to authenticate the service, to establish trust in 69 the information received from it, but might not wish to disclose its 70 identity to the service for privacy reasons. 72 To accomplish this, a Kerberos mechanism is specified in this 73 document by which a client requests an anonymous ticket and use that 74 to authenticate the server and secure subsequent client-server 75 communications. This provides Kerberos with functional equivalence 76 to TLS [RFC2246] in environments where Kerberos is a more attractive 77 authentication mechanism. 79 Using this mechanism, the client has to reveal its identity in its 80 initial request to its own Key Distribution Center (KDC) [RFC4120], 81 and then it can remain anonymous thereafter to KDCs on the cross- 82 realm authentication path, if any, and to the server with which it 83 communicates. 85 2. Conventions Used in This Document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Definitions 93 The anonymous Kerberos realm name is a reserved realm name as defined 94 in [KRBNAM] and its value is the literal "RESERVED:ANONYMOUS". 96 The anonymous Kerberos principal name is a reserved Kerberos 97 principal name as defined in [KRBNAM], its name-type [RFC4120] is 98 KRB_NT_RESRVED [KRBNAM], and its name-string [RFC4120] is a sequence 99 of two KerberosString components: "RESERVED", "ANONYMOUS". 101 In this specification, only the client name or the client realm can 102 be anonymous; the server name or the server realm can not be 103 anonymous. 105 The transited field [RFC4120] of a ticket is an anonymous 106 authentication path if the tr-type field of the TransitedEncoding 107 type [RFC4120] is NO-TRANSITED-INFO and the contents field is an 108 empty OCTET STRING. 110 NO-TRANSITED-INFO TBA 112 This transited encoding type indicates that there is no information 113 available about the authentication path. 115 The anonymous ticket flag is defined as bit TBA (with the first bit 116 being bit 0) in the TicketFlags: 118 TicketFlags ::= KerberosFlags 119 -- anonymous(TBA) 120 -- TicketFlags and KerberosFlags are defined in [RFC4120] 122 An anonymous ticket is a ticket that has all of the following 123 properties: 125 o The cname field [RFC4120] contains the anonymous Kerberos 126 principal name. 128 o The crealm field [RFC4120] contains either the realm name of the 129 client who made the request or the anonymous kerberos realm name, 130 based on the local policy of the KDC. 132 o The transited field [RFC4120] can contain either the client's 133 "normal" authentication path according to Section 3.3.3.2 of 134 [RFC4120] or the anonymous authentication path. 136 o It contains no information that can reveal the client's identity. 137 However the ticket can contain the client realm and the realms on 138 the authentication path, and the authorization data may provide 139 additional information of the client. For example, an anonymous 140 principal that is only identifiable within a particular group of 141 users can be implemented by using authorization data. 143 o The anonymous ticket flag is set. 145 Notes: The anonymous ticket flag MUST NOT be set by implementations 146 of this specification if the ticket is not an anonymous ticket. The 147 server principal name and the server realm in a cross-realm referral 148 TGT are not dependent on whether the client is the anonymous 149 principal or not. 151 The request-anonymous KDC option is defined as bit TBA (with the 152 first bit being bit 0) in the KDCOptions: 154 KDCOptions ::= KerberosFlags 155 -- request-anonymous(TBA) 156 -- KDCOptions and KerberosFlags are defined in [RFC4120] 158 4. Protocol Description 160 In order to request an anonymous ticket, the client sets the request- 161 anonymous KDC option in an Authentication Exchange (AS) or Ticket 162 Granting Service (TGS) request [RFC4120]. The client can request an 163 anonymous TGT based on a normal TGT. Note that if the ticket in the 164 PA-TGS-REQ [RFC4120] is anonymous, the request-anonymous KDC option 165 MUST be set in the request. 167 When propagating authorization data, care MUST be taken by the TGS to 168 ensure that the client confidentiality is not violated: the TGS MUST 169 either fail the request or remove authorization data that may reveal 170 the client's identity. An optional authorization element unknown by 171 the TGS MUST be removed if it can be ignored (such as ones enclosed 172 in the AD-IF-RELEVANT or the AD-KDCIssued containers [RFC4120]). The 173 TGS can strip critical unknown authorization data if such data do not 174 convey any rights based on the requesting client's identity. Here is 175 a table of the known authorization-data elements, flagged with 176 whether they interfere with client anonymity and recommendations for 177 how to process them. 179 ad-type References Can Breach Confidentiality? 180 ------------------------------------------------------------------ 181 AD-IF-RELEVANT RFC4120 Yes, remove if unknown 182 AD-KDCIssued RFC4120 Yes, remove if unknown 183 AD-AND-OR RFC4120 Yes, remove if unknown 184 AD-MANDATORY-FOR-KDC RFC4120 Yes, fail the request if unknown 186 If it is inappropriate to remove an authorization element from the 187 TGS request in order to produce an anonymous ticket, the KDC MUST 188 return an error message with the code KDC_ERR_POLICY [RFC4120]. 190 When policy allows, the KDC issues an anonymous ticket. The client 191 realm in the anonymous ticket can be the anonymous realm name based 192 on local policy. The client name and the client realm the 193 EncKDCRepPart of the reply [RFC4120] MUST match with the 194 corresponding client name and the client realm of the anonymous reply 195 ticket. The client then MUST use the client name and the client 196 realm returned in the EncKDCRepPart in subsequent message exchanges 197 when using that anonymous ticket. 199 If there is a key known by both the client and the KDC for encrypting 200 the KDC reply, the cname field in the request [RFC4120] can be 201 anonymous. If the client is anonymous and the KDC does not have a 202 key to encrypt the reply, the KDC MUST return an error message with 203 the code KDC_ERR_NULL_KEY [RFC4120]. For AS exchange, if the reply 204 key is selected from the client keys (for example, as described in 205 Section 3.1.3 of [RFC4120]), then the client principal MUST NOT be 206 anonymous. The client can use the client keys to request an 207 anonymous TGT in the AS request. The anonymous client name, for 208 example, can be used in conjunction with PKINIT [RFC4556]. An 209 anonymous PKINIT client can authenticate the KDC based on the KDC 210 certificate. For TGS exchange, the reply key is selected according 211 to Section 3.3.3 of [RFC4120] as normal. 213 The KDC fills out the transited field of the anonymous ticket in the 214 reply as follows: If the service ticket in a TGS request is an 215 anonymous ticket with a "normal" authentication path, then the 216 authentication path in the reply ticket MUST also contain a "normal" 217 authentication path: the TGS MUST add the name of the previous realm. 218 However, if the service ticket in a TGS request is an anonymous 219 ticket with an anonymous authentication path, then the reply ticket 220 can contain either an anonymous authentication path or a "normal" 221 authentication path, based on the local policy of the KDC. Thus a 222 "normal" authentication path in an anonymous ticket can be a partial 223 path: it may not include all the intermediate realms on the 224 authentication path. 226 The KDC fills out the authtime field of the anonymous ticket in the 227 reply as follows: If the anonymous ticket is returned in an AS 228 exchange, the authtime field of the ticket contains the request time. 229 If the anonymous ticket is returned in a TGS exchange, the authtime 230 field contains the time of the initial authentication for the 231 principal who has made the request. An anonymous ticket can be 232 renewed, and the authtime field of a renewed ticket is the authtime 233 in the anonymous ticket that the renewed ticket was based on. 235 If a client requires anonymous communication then the client MUST 236 check to make sure that the ticket in the reply is actually anonymous 237 by checking the presence of the anonymous ticket flag. Because KDCs 238 ignore unknown KDC options, a KDC that does not understand the 239 request-anonymous KDC option will not return an error, but will 240 instead return a normal ticket. 242 The subsequent client and server communications then proceed as 243 described in [RFC4120]. No transited policy checking is needed for 244 the anonymous authentication path. However, transited policy checks 245 defined in Section 2.7 of [RFC4120] would apply to an anonymous 246 ticket that contains a "normal" authentication path. 248 A server accepting an anonymous service ticket may assume that 249 subsequent requests using the same ticket originate from the same 250 client. Requests with different tickets are likely to originate from 251 different clients. 253 Interoperability and backward-compatibility notes: the KDC is given 254 the task of rejecting a request for an anonymous ticket when the 255 anonymous ticket is not acceptable by the server. 257 5. GSS-API Implementation Notes 259 At the GSS-API [RFC2743] level, the use of an anonymous principal by 260 the initiator/client requires a software change of the initiator/ 261 client software (to assert the "anonymous" flag when calling 262 GSS_Init_Sec_Context(). 264 GSS-API does not know or define "anonymous credentials", so the 265 (printable) name of the anonymous principal will rarely be used by or 266 relevant for the initator/client. The printable name is relevant for 267 the acceptor/server when performing an authorization decision based 268 on the name that pops up from GSS_Accept_Sec_Context() upon 269 successful security context establishment. 271 A GSS-API initiator MUST carefully check the resulting context 272 attributes from the initial call to GSS_Init_Sec_Context() when 273 requesting anonymity, because (as in the GSS-API tradition and for 274 backwards compatibility) anonymity is just another optional context 275 attribute. It could be that the mechanism doesn't recognize the 276 attribute at all or that anonymity is not available for some other 277 reasons -- and in that case the initiator must NOT send the initial 278 security context token to the acceptor, because it will likely reveal 279 the initiators identity to the acceptor, something that can rarely be 280 "un-done". 282 GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to 283 represent the anonymous identity. In addition, Section 2.1.1 of 284 [RFC1964] defines the single string representation of a Kerberos 285 principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. For 286 the anonymous principals, the name component within the exportable 287 name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm 288 name according to Section 2.1.1 of [RFC1964]. In this specification 289 only the client/initiator can be the anonymous identity. 291 Portable initiators are RECOMMENDED to use default credentials 292 whenever possible, and request anonymity only through the input 293 anon_req_flag [RFC2743] to GSS_Init_Sec_Context(). 295 6. Security Considerations 297 Since KDCs ignore unknown options [RFC4120], a client requiring 298 anonymous communication needs to make sure that the ticket is 299 actually anonymous. A KDC that that does not understand the 300 anonymous option would not return an anonymous ticket. 302 By using the mechanism defined in this specification, the client does 303 not reveal its identity to the server but its identity may be 304 revealed to the KDC of the server principal (when the server 305 principal is in a different realm than that of the client), and any 306 KDC on the cross-realm authentication path. The Kerberos client MUST 307 verify the ticket being used is indeed anonymous before communicating 308 with the cross-realm KDC or the server, otherwise the client's 309 identity may be revealed to the server unintentionally. 311 In cases where specific server principals must not have access to the 312 client's identity (for example, an anonymous poll service), the KDC 313 can define server principal specific policy that insure any normal 314 service ticket can NEVER be issued to any of these server principals. 316 If the KDC that issued an anonymous ticket were to maintain records 317 of the association of identities to an anonymous ticket, then someone 318 obtaining such records could breach the anonymity. Additionally, the 319 implementation of most (for now all) KDC's respond to requests at the 320 time that they are received. Traffic analasys on the connection to 321 the KDC will allow an attacket to match client identities to 322 anonymous tickets issued. Because there are plaintext parts of the 323 tickets that are exposed on the wire, such matching by a third party 324 observer is relatively straigtforward. 326 7. Acknowledgements 328 The authors would like to thank the following individuals for their 329 insightful comments and fruitful discussions: Sam Hartman, Clifford 330 Neuman, Martin Rex, Nicolas Williams, Jeffery Altman, Tom Yu, 331 Chaskiel M Grundman, Love Hoernquist Aestrand, and Jeffery Hutzelman. 333 8. IANA Considerations 335 No IANA actions are required for this document. 337 9. Normative References 339 [KRBNAM] Zhu, L., "Additonal Kerberos Naming Contraints", 340 draft-ietf-krb-wg-naming, work in progress. 342 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 343 RFC 1964, June 1996. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 349 RFC 2246, January 1999. 351 [RFC2743] Linn, J., "Generic Security Service Application Program 352 Interface Version 2, Update 1", RFC 2743, January 2000. 354 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 355 Kerberos Network Authentication Service (V5)", RFC 4120, 356 July 2005. 358 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 359 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 361 Authors' Addresses 363 Larry Zhu 364 Microsoft Corporation 365 One Microsoft Way 366 Redmond, WA 98052 367 US 369 Email: lzhu@microsoft.com 371 Paul Leach 372 Microsoft Corporation 373 One Microsoft Way 374 Redmond, WA 98052 375 US 377 Email: paulle@microsoft.com 379 Karthik Jaganathan 380 Microsoft Corporation 381 One Microsoft Way 382 Redmond, WA 98052 383 US 385 Email: karthikj@microsoft.com 387 Intellectual Property Statement 389 The IETF takes no position regarding the validity or scope of any 390 Intellectual Property Rights or other rights that might be claimed to 391 pertain to the implementation or use of the technology described in 392 this document or the extent to which any license under such rights 393 might or might not be available; nor does it represent that it has 394 made any independent effort to identify any such rights. Information 395 on the procedures with respect to rights in RFC documents can be 396 found in BCP 78 and BCP 79. 398 Copies of IPR disclosures made to the IETF Secretariat and any 399 assurances of licenses to be made available, or the result of an 400 attempt made to obtain a general license or permission for the use of 401 such proprietary rights by implementers or users of this 402 specification can be obtained from the IETF on-line IPR repository at 403 http://www.ietf.org/ipr. 405 The IETF invites any interested party to bring to its attention any 406 copyrights, patents or patent applications, or other proprietary 407 rights that may cover technology that may be required to implement 408 this standard. Please address the information to the IETF at 409 ietf-ipr@ietf.org. 411 Disclaimer of Validity 413 This document and the information contained herein are provided on an 414 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 415 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 416 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 417 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 418 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 419 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 421 Copyright Statement 423 Copyright (C) The Internet Society (2006). This document is subject 424 to the rights, licenses and restrictions contained in BCP 78, and 425 except as set forth therein, the authors retain all their rights. 427 Acknowledgment 429 Funding for the RFC Editor function is currently provided by the 430 Internet Society.