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