4 NETWORK WORKING GROUP L. Zhu
5 Internet-Draft P. Leach
6 Updates: 4120 (if approved) K. Jaganathan
7 Expires: December 5, 2006 Microsoft Corporation
11 Anonymity Support for Kerberos
12 draft-ietf-krb-wg-anon-00
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.
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-
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."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on December 5, 2006.
41 Copyright (C) The Internet Society (2006).
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
55 Zhu, et al. Expires December 5, 2006 [Page 1]
57 Internet-Draft Kerberos Anonymity Support June 2006
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
111 Zhu, et al. Expires December 5, 2006 [Page 2]
113 Internet-Draft Kerberos Anonymity Support June 2006
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.
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.
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
141 2. Conventions Used in This Document
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].
150 An anonymous ticket is a ticket that has all of the following
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",
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".
167 Zhu, et al. Expires December 5, 2006 [Page 3]
169 Internet-Draft Kerberos Anonymity Support June 2006
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.
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.
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
196 o The anonymous ticket flag (as defined later in this section) is
199 The anonymous ticket flag is defined as bit 14 (with the first bit
200 being bit 0) in the TicketFlags:
202 TicketFlags ::= KerberosFlags
204 -- TicketFlags and KerberosFlags are defined in [RFC4120]
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
210 The request-anonymous KDC option is defined as bit 14 (with the first
211 bit being bit 0) in the KDCOptions:
213 KDCOptions ::= KerberosFlags
214 -- request-anonymous(14)
215 -- KDCOptions and KerberosFlags are defined in [RFC4120]
217 The anonymous transited encoding type is defined as follows:
223 Zhu, et al. Expires December 5, 2006 [Page 4]
225 Internet-Draft Kerberos Anonymity Support June 2006
228 This transited encoding type indicates that there is no information
229 available about the authentication path.
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.
236 4. Protocol Description
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.
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
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
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].
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.
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].
279 Zhu, et al. Expires December 5, 2006 [Page 5]
281 Internet-Draft Kerberos Anonymity Support June 2006
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
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.
294 5. GSS-API Implementation Notes
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().
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.
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
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
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().
335 Zhu, et al. Expires December 5, 2006 [Page 6]
337 Internet-Draft Kerberos Anonymity Support June 2006
340 6. Security Considerations
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.
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.
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.
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.
370 8. IANA Considerations
372 No IANA actions are required for this document.
374 9. Normative References
376 [KRBNAM] Zhu, L., "Additonal Kerberos Naming Contraints",
377 draft-ietf-krb-wg-naming, work in progress.
379 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
383 Requirement Levels", BCP 14, RFC 2119, March 1997.
385 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
386 RFC 2246, January 1999.
388 [RFC2743] Linn, J., "Generic Security Service Application Program
392 Zhu, et al. Expires December 5, 2006 [Page 7]
394 Internet-Draft Kerberos Anonymity Support June 2006
397 Interface Version 2, Update 1", RFC 2743, January 2000.
399 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
400 Kerberos Network Authentication Service (V5)", RFC 4120,
448 Zhu, et al. Expires December 5, 2006 [Page 8]
450 Internet-Draft Kerberos Anonymity Support June 2006
456 Microsoft Corporation
461 Email: lzhu@microsoft.com
465 Microsoft Corporation
470 Email: paulle@microsoft.com
474 Microsoft Corporation
479 Email: karthikj@microsoft.com
504 Zhu, et al. Expires December 5, 2006 [Page 9]
506 Internet-Draft Kerberos Anonymity Support June 2006
509 Intellectual Property Statement
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.
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.
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
534 Disclaimer of Validity
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.
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.
554 Funding for the RFC Editor function is currently provided by the
560 Zhu, et al. Expires December 5, 2006 [Page 10]