1
2
3NETWORK WORKING GROUP                                             L. Zhu
4Internet-Draft                                                  P. Leach
5Updates: 4120 (if approved)                                K. Jaganathan
6Intended status: Standards Track                   Microsoft Corporation
7Expires: September 3, 2007                                 March 2, 2007
8
9
10                     Anonymity Support for Kerberos
11                       draft-ietf-krb-wg-anon-03
12
13Status of this Memo
14
15   By submitting this Internet-Draft, each author represents that any
16   applicable patent or other IPR claims of which he or she is aware
17   have been or will be disclosed, and any of which he or she becomes
18   aware will be disclosed, in accordance with Section 6 of BCP 79.
19
20   Internet-Drafts are working documents of the Internet Engineering
21   Task Force (IETF), its areas, and its working groups.  Note that
22   other groups may also distribute working documents as Internet-
23   Drafts.
24
25   Internet-Drafts are draft documents valid for a maximum of six months
26   and may be updated, replaced, or obsoleted by other documents at any
27   time.  It is inappropriate to use Internet-Drafts as reference
28   material or to cite them other than as "work in progress."
29
30   The list of current Internet-Drafts can be accessed at
31   http://www.ietf.org/ietf/1id-abstracts.txt.
32
33   The list of Internet-Draft Shadow Directories can be accessed at
34   http://www.ietf.org/shadow.html.
35
36   This Internet-Draft will expire on September 3, 2007.
37
38Copyright Notice
39
40   Copyright (C) The IETF Trust (2007).
41
42Abstract
43
44   This document defines extensions to the Kerberos protocol for the
45   Kerberos client to authenticate the Kerberos Key Distribution Center
46   and the Kerberos server, without revealing the client's identity.
47   These extensions can be used to secure communication between the
48   anonymous client and the server.
49
50
51
52
53
54Zhu, et al.             Expires September 3, 2007               [Page 1]
55
56Internet-Draft         Kerberos Anonymity Support             March 2007
57
58
59Table of Contents
60
61   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
62   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
63   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
64   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  4
65   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  7
66   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
67   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
68   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
69   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
70   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
71   Intellectual Property and Copyright Statements . . . . . . . . . . 11
72
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
110Zhu, et al.             Expires September 3, 2007               [Page 2]
111
112Internet-Draft         Kerberos Anonymity Support             March 2007
113
114
1151.  Introduction
116
117   In certain situations, the Kerberos [RFC4120] client may wish to
118   authenticate a server and/or protect communications without revealing
119   its own identity.  For example, consider an application which
120   provides read access to a research database, and which permits
121   queries by arbitrary requestors.  A client of such a service might
122   wish to authenticate the service, to establish trust in the
123   information received from it, but might not wish to disclose its
124   identity to the service for privacy reasons.
125
126   Extensions to [RFC4120] are specified in this document by which a
127   client can authenticate the Key Distribution Center (KDC) and request
128   an anonymous ticket.  The client can use the anonymous ticket to
129   authenticate the server and protect subsequent client-server
130   communications.  These extensions provide Kerberos with functional
131   equivalence to Transport Layer Security (TLS) [RFC4346].
132
133   By using the extensions defined in this specification, the client may
134   reveal its identity in its initial request to its own KDC, but it can
135   remain anonymous thereafter to KDCs on the cross-realm authentication
136   path, and to the server with which it communicates.
137
138
1392.  Conventions Used in This Document
140
141   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143   document are to be interpreted as described in [RFC2119].
144
145
1463.  Definitions
147
148   The anonymous Kerberos realm name is defined as a well-known realm
149   name based on [KRBNAM].  The value is the literal "WELLKNOWN:
150   ANONYMOUS".  An anonymous Kerberos realm name MUST NOT be present in
151   the transited field [RFC4120] of a ticket.
152
153   The anonymous Kerberos principal name is defined as a well-known
154   Kerberos principal name based on [KRBNAM].  The value of the name-
155   type field [RFC4120] is KRB_NT_RESRVED [KRBNAM], and the value of the
156   name-string field [RFC4120] is a sequence of two KerberosString
157   components: "WELLKNOWN", "ANONYMOUS".
158
159   Note that in this specification, the anonymous principal name and
160   realm are only applicable to the client in Kerberos messages, the
161   server MUST NOT be anonymous in any Kerberos message.
162
163
164
165
166Zhu, et al.             Expires September 3, 2007               [Page 3]
167
168Internet-Draft         Kerberos Anonymity Support             March 2007
169
170
171   The anonymous ticket flag is defined as bit TBA (with the first bit
172   being bit 0) in the TicketFlags:
173
174           TicketFlags     ::= KerberosFlags
175             -- anonymous(TBA)
176             -- TicketFlags and KerberosFlags are defined in [RFC4120]
177
178   An anonymous ticket is a ticket that has all of the following
179   properties:
180
181   o  The cname field [RFC4120] contains the anonymous Kerberos
182      principal name.
183
184   o  The crealm field [RFC4120] contains the client's realm name, or
185      the name of the realm that issued the initial ticket for the
186      client principal, or the anonymous realm name.
187
188   o  The anonymous ticket contains no information that can reveal the
189      client's identity.  However the ticket may contain the client
190      realm, intermediate realms on the client's authentication path,
191      and authorization data that may provide information related to the
192      client's identity.  For example, an anonymous principal that is
193      identifiable only within a particular group of users can be
194      implemented using authorization data and such authorization data,
195      if included in the anonymous ticket, shall disclose the client's
196      membership of that group.
197
198   o  The anonymous ticket flag is set.
199
200   The request-anonymous KDC option is defined as bit TBA (with the
201   first bit being bit 0) in the KDCOptions:
202
203           KDCOptions      ::= KerberosFlags
204             -- request-anonymous(TBA)
205             -- KDCOptions and KerberosFlags are defined in [RFC4120]
206
207   As described in Section 4, the request-anonymous KDC option is set to
208   request an anonymous ticket.
209
210
2114.  Protocol Description
212
213   In order to request an anonymous ticket, the client sets the request-
214   anonymous KDC option in an Authentication Exchange (AS) or Ticket
215   Granting Service (TGS) request [RFC4120].  The client can request an
216   anonymous Ticket Granting Ticket (TGT) based on a normal TGT.  Unless
217   otherwise specified, the client can obtain an anonymous ticket with
218   the anonymous realm name only by requesting an anonymous ticket in an
219
220
221
222Zhu, et al.             Expires September 3, 2007               [Page 4]
223
224Internet-Draft         Kerberos Anonymity Support             March 2007
225
226
227   AS exchange with the client realm set as anonymous in the request.
228
229   If the client wishes to authenticate the KDC anonymously, it sets the
230   client name as anonymous in the AS exchange and provides a
231   PA_PK_AS_REQ pre-authentication data [RFC4556] where both the
232   signerInfos field and the certificates field of the SignedData
233   [RFC3852] of the PA_PK_AS_REQ are empty.  Because the anonymous
234   client does not have an associated asymmetric key pair, the client
235   MUST choose the Diffie-Hellman key agreement method by filling in the
236   Diffie-Hellman domain parameters in the clientPublicValue [RFC4556].
237
238   If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is
239   anonymous, or if the client in the AS request is anonymous, the
240   request-anonymous KDC option MUST be set in the request.  Otherwise,
241   the KDC MUST return a KRB-ERROR message with the code
242   KDC_ERR_BADOPTION [RFC4120], and there is no accompanying e-data
243   defined in this document.
244
245   Upon receiving the AS request with a PA_PK_AS_REQ [RFC4556] from the
246   anonymous client, the KDC processes the request according to Section
247   3.1.2 of [RFC4120].  The KDC skips the checks for the client's
248   signature and the client's public key (such as the verification of
249   the binding between the client's public key and the client name), but
250   performs otherwise-applicable checks, and proceeds as normal
251   according to [RFC4556].  For example, the AS MUST check if the
252   client's Diffie-Hellman domain parameters are acceptable.  The
253   Diffie-Hellman key agreement method MUST be used and the reply key is
254   derived according to Section 3.2.3.1 of [RFC4556].  If the
255   clientPublicValue is not present in the request, the KDC MUST return
256   a KRB-ERROR [RFC4120] with the code
257   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556] and there is no
258   accompanying e-data.  If all goes well, an anonymous ticket is
259   generated according to Section 3.1.3 of [RFC4120] and a PA_PK_AS_REP
260   [RFC4556] pre-authentication data is included in the KDC reply
261   according to [RFC4556].  If the KDC does not have an asymmetric key
262   pair, it MAY reply anonymously or reject the authentication attempt.
263   If the KDC replies anonymously, both the signerInfos field and the
264   certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the
265   reply are empty.  The server name in the anonymous KDC reply contains
266   the name of the TGS.
267
268   Upon receipt of the KDC reply that contains an anonymous ticket and a
269   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then
270   authenticate the KDC based on the KDC's signature in the
271   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply
272   (the reply is anonymous), the client MUST reject the returned ticket
273   if it cannot authenticate the KDC otherwise.
274
275
276
277
278Zhu, et al.             Expires September 3, 2007               [Page 5]
279
280Internet-Draft         Kerberos Anonymity Support             March 2007
281
282
283   The client can use the client keys to mutually authenticate with the
284   KDC, request an anonymous TGT in the AS request.  And in that case,
285   the reply key is selected as normal according to Section 3.1.3 of
286   [RFC4120].
287
288   For the TGS exchange, the reply key is selected as normal according
289   to Section 3.3.3 of [RFC4120].
290
291   When policy allows, the KDC issues an anonymous ticket.  Based on
292   local policy, the client realm in the anonymous ticket can be the
293   anonymous realm name or the realm of the KDC.  However, in all cases,
294   the client name and the client realm in the EncKDCRepPart of the
295   reply [RFC4120] MUST match with the corresponding client name and the
296   client realm of the anonymous ticket in the reply.  The client MUST
297   use the client name and the client realm returned in the
298   EncKDCRepPart in subsequent message exchanges when using the obtained
299   anonymous ticket.
300
301   During the TGS request, when propagating authorization data, care
302   MUST be taken by the TGS to ensure that the client confidentiality is
303   not violated.  If a anonymous ticket is returned, any authorization
304   element that may reveal the client's identity MUST be removed.  The
305   authentication attempt MUST be rejected if there is an authorization
306   element that is intended to restrict the use of the ticket thus
307   cannot be removed or the local policy prevents the removal of an
308   authorization element, and this rule MUST be applied to all critical
309   and optional authorization data.  An optional authorization element
310   unknown by the TGS MUST be removed if it does not potentially convey
311   any rights or limit the rights otherwise conveyed in the ticket.  If
312   there is a critical unknown authorization element, unless this
313   element is encapsulated in a known authorization data element
314   amending the criticality of the elements it contains, authentication
315   MUST fail according to [RFC4120].  If it is inappropriate to remove
316   an authorization element from the TGS request in order to produce an
317   anonymous ticket, the KDC MUST return an error message with the code
318   KDC_ERR_POLICY [RFC4120], and there is no accompanying e-data defined
319   in this document.
320
321   The TGS MUST add the name of the previous realm according to Section
322   3.3.3.2 of [RFC4120].  If the client's realm is the anonymous realm,
323   the abbreviation forms [RFC4120] that build on the preceding name
324   cannot be used at the start of the transited encoding.  The null-
325   subfield form (e.g., encoding ending with ",") [RFC4120] could not be
326   used next to the anonymous realm that can potentially be at the
327   beginning where the client realm is filled in.
328
329   The KDC fills out the authtime field of the anonymous ticket in the
330   reply as follows: If the anonymous ticket is returned in an AS
331
332
333
334Zhu, et al.             Expires September 3, 2007               [Page 6]
335
336Internet-Draft         Kerberos Anonymity Support             March 2007
337
338
339   exchange, the authtime field of the ticket contains the request time.
340   If the anonymous ticket is returned in a TGS exchange, the authtime
341   field contains the authtime of the ticket in the PA-TGS-REQ pre-
342   authentication data [RFC4120].  An anonymous ticket can be renewed,
343   and the authtime field of a renewed ticket is the authtime in the
344   anonymous ticket on which the renewed ticket was based.
345
346   If the client is anonymous and the KDC does not have a key to encrypt
347   the reply (this can happen when, for example, the KDC does not
348   support PKINIT [RFC4556]), the KDC MUST return an error message with
349   the code KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying
350   e-data defined in this document.
351
352   If a client requires anonymous communication then the client MUST
353   check to make sure that the ticket in the reply is actually anonymous
354   by checking the presence of the anonymous ticket flag.  This is
355   because KDCs ignore unknown KDC options.  A KDC that does not
356   understand the request-anonymous KDC option will not return an error,
357   but will instead return a normal ticket.
358
359   The subsequent client and server communications then proceed as
360   described in [RFC4120].
361
362   A server accepting an anonymous service ticket may assume that
363   subsequent requests using the same ticket originate from the same
364   client.  Requests with different tickets are likely to originate from
365   different clients.
366
367
3685.  GSS-API Implementation Notes
369
370   At the GSS-API [RFC2743] level, the use of an anonymous principal by
371   the initiator/client requires the initiator/client to assert the
372   "anonymous" flag when calling GSS_Init_Sec_Context().
373
374   GSS-API does not know or define "anonymous credentials", so the
375   (printable) name of the anonymous principal will rarely be used by or
376   relevant for the initiator/client.  The printable name is relevant
377   for the acceptor/server when performing an authorization decision
378   based on the initiator name that is returned from the acceptor side
379   upon the successful security context establishment.
380
381   A GSS-API initiator MUST carefully check the resulting context
382   attributes from the initial call to GSS_Init_Sec_Context() when
383   requesting anonymity, because (as in the GSS-API tradition and for
384   backwards compatibility) anonymity is just another optional context
385   attribute.  It could be that the mechanism doesn't recognize the
386   attribute at all or that anonymity is not available for some other
387
388
389
390Zhu, et al.             Expires September 3, 2007               [Page 7]
391
392Internet-Draft         Kerberos Anonymity Support             March 2007
393
394
395   reasons -- and in that case the initiator must NOT send the initial
396   security context token to the acceptor, because it will likely reveal
397   the initiators identity to the acceptor, something that can rarely be
398   "un-done".
399
400   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
401   represent the anonymous identity.  In addition, Section 2.1.1 of
402   [RFC1964] defines the single string representation of a Kerberos
403   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
404   the anonymous principals, the name component within the exportable
405   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
406   name according to Section 2.1.1 of [RFC1964].  Note that in this
407   specification only the client/initiator can be anonymous.
408
409   Portable initiators are RECOMMENDED to use default credentials
410   whenever possible, and request anonymity only through the input
411   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
412
413
4146.  Security Considerations
415
416   Since KDCs ignore unknown options [RFC4120], a client requiring
417   anonymous communication needs to make sure that the ticket is
418   actually anonymous.  This is because a KDC that that does not
419   understand the anonymous option would not return an anonymous ticket.
420
421   By using the mechanism defined in this specification, the client does
422   not reveal its identity to the server but its identity may be
423   revealed to the KDC of the server principal (when the server
424   principal is in a different realm than that of the client), and any
425   KDC on the cross-realm authentication path.  The Kerberos client MUST
426   verify the ticket being used is indeed anonymous before communicating
427   with the server, otherwise the client's identity may be revealed
428   unintentionally.
429
430   In cases where specific server principals must not have access to the
431   client's identity (for example, an anonymous poll service), the KDC
432   can define server principal specific policy that insure any normal
433   service ticket can NEVER be issued to any of these server principals.
434
435   If the KDC that issued an anonymous ticket were to maintain records
436   of the association of identities to an anonymous ticket, then someone
437   obtaining such records could breach the anonymity.  Additionally, the
438   implementations of most (for now all) KDC's respond to requests at
439   the time that they are received.  Traffic analysis on the connection
440   to the KDC will allow an attacker to match client identities to
441   anonymous tickets issued.  Because there are plaintext parts of the
442   tickets that are exposed on the wire, such matching by a third party
443
444
445
446Zhu, et al.             Expires September 3, 2007               [Page 8]
447
448Internet-Draft         Kerberos Anonymity Support             March 2007
449
450
451   observer is relatively straightforward.
452
453
4547.  Acknowledgements
455
456   Clifford Neuman contributed the core notions of this document.
457
458   Ken Raeburn reviewed the document and provided suggestions for
459   improvements.
460
461   Martin Rex wrote the text for GSS-API considerations.
462
463   Nicolas Williams reviewed the GSS-API considerations section and
464   suggested ideas for improvements.
465
466   Sam Hartman and Nicolas Williams were great champions of this work.
467
468   In addition, the following individuals made significant
469   contributions: Jeffery Altman, Tom Yu, Chaskiel M Grundman, Love
470   Hoernquist Aestrand, and Jeffery Hutzelman.
471
472
4738.  IANA Considerations
474
475   Section 3 defines the anonymous Kerberos name and the anonymous
476   Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
477   need to be updated to add references to this document.
478
479
4809.  Normative References
481
482   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
483              draft-ietf-krb-wg-naming, work in progress.
484
485   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
486              RFC 1964, June 1996.
487
488   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
489              Requirement Levels", BCP 14, RFC 2119, March 1997.
490
491   [RFC2743]  Linn, J., "Generic Security Service Application Program
492              Interface Version 2, Update 1", RFC 2743, January 2000.
493
494   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
495              RFC 3852, July 2004.
496
497   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
498              Kerberos Network Authentication Service (V5)", RFC 4120,
499              July 2005.
500
501
502
503Zhu, et al.             Expires September 3, 2007               [Page 9]
504
505Internet-Draft         Kerberos Anonymity Support             March 2007
506
507
508   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
509              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
510
511   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
512              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
513
514
515Authors' Addresses
516
517   Larry Zhu
518   Microsoft Corporation
519   One Microsoft Way
520   Redmond, WA  98052
521   US
522
523   Email: lzhu@microsoft.com
524
525
526   Paul Leach
527   Microsoft Corporation
528   One Microsoft Way
529   Redmond, WA  98052
530   US
531
532   Email: paulle@microsoft.com
533
534
535   Karthik Jaganathan
536   Microsoft Corporation
537   One Microsoft Way
538   Redmond, WA  98052
539   US
540
541   Email: karthikj@microsoft.com
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559Zhu, et al.             Expires September 3, 2007              [Page 10]
560
561Internet-Draft         Kerberos Anonymity Support             March 2007
562
563
564Full Copyright Statement
565
566   Copyright (C) The IETF Trust (2007).
567
568   This document is subject to the rights, licenses and restrictions
569   contained in BCP 78, and except as set forth therein, the authors
570   retain all their rights.
571
572   This document and the information contained herein are provided on an
573   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
574   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
575   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
576   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
577   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
578   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
579
580
581Intellectual Property
582
583   The IETF takes no position regarding the validity or scope of any
584   Intellectual Property Rights or other rights that might be claimed to
585   pertain to the implementation or use of the technology described in
586   this document or the extent to which any license under such rights
587   might or might not be available; nor does it represent that it has
588   made any independent effort to identify any such rights.  Information
589   on the procedures with respect to rights in RFC documents can be
590   found in BCP 78 and BCP 79.
591
592   Copies of IPR disclosures made to the IETF Secretariat and any
593   assurances of licenses to be made available, or the result of an
594   attempt made to obtain a general license or permission for the use of
595   such proprietary rights by implementers or users of this
596   specification can be obtained from the IETF on-line IPR repository at
597   http://www.ietf.org/ipr.
598
599   The IETF invites any interested party to bring to its attention any
600   copyrights, patents or patent applications, or other proprietary
601   rights that may cover technology that may be required to implement
602   this standard.  Please address the information to the IETF at
603   ietf-ipr@ietf.org.
604
605
606Acknowledgment
607
608   Funding for the RFC Editor function is provided by the IETF
609   Administrative Support Activity (IASA).
610
611
612
613
614
615Zhu, et al.             Expires September 3, 2007              [Page 11]
616
617
618