doc/standardisation/draft-ietf-krb-wg-anon-00.txt

   1
   2
   3
   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
   8                                                             June 3, 2006
   9
  10
  11                      Anonymity Support for Kerberos
  12                        draft-ietf-krb-wg-anon-00
  13
  14 Status 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 December 5, 2006.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2006).
  42
  43 Abstract
  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
  55 Zhu, et al.             Expires December 5, 2006                [Page 1]
  56 \f
  57 Internet-Draft         Kerberos Anonymity Support              June 2006
  58
  59
  60 Table 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 . . . . . . . . . . . . . . . . .  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
  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
 111 Zhu, et al.             Expires December 5, 2006                [Page 2]
 112 \f
 113 Internet-Draft         Kerberos Anonymity Support              June 2006
 114
 115
 116 1.  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
 141 2.  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
 148 3.  Definitions
 149
 150    An anonymous ticket is a ticket that has all of the following
 151    properties:
 152
 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",
 158       "ANONYMOUS".
 159
 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".
 164
 165
 166
 167 Zhu, et al.             Expires December 5, 2006                [Page 3]
 168 \f
 169 Internet-Draft         Kerberos Anonymity Support              June 2006
 170
 171
 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.
 175
 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.
 191
 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
 194       authentication path.
 195
 196    o  The anonymous ticket flag (as defined later in this section) is
 197       set.
 198
 199    The anonymous ticket flag is defined as bit 14 (with the first bit
 200    being bit 0) in the TicketFlags:
 201
 202            TicketFlags     ::= KerberosFlags
 203              -- anonymous(14)
 204              -- TicketFlags and KerberosFlags are defined in [RFC4120]
 205
 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
 208    this section.
 209
 210    The request-anonymous KDC option is defined as bit 14 (with the first
 211    bit being bit 0) in the KDCOptions:
 212
 213            KDCOptions      ::= KerberosFlags
 214              -- request-anonymous(14)
 215              -- KDCOptions and KerberosFlags are defined in [RFC4120]
 216
 217    The anonymous transited encoding type is defined as follows:
 218
 219            NO-TRANSITED-INFO    0
 220
 221
 222
 223 Zhu, et al.             Expires December 5, 2006                [Page 4]
 224 \f
 225 Internet-Draft         Kerberos Anonymity Support              June 2006
 226
 227
 228    This transited encoding type indicates that there is no information
 229    available about the authentication path.
 230
 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.
 234
 235
 236 4.  Protocol Description
 237
 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.
 242
 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
 246    anonymous ticket.
 247
 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
 257    ticket.
 258
 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].
 263
 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.
 270
 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].
 276
 277
 278
 279 Zhu, et al.             Expires December 5, 2006                [Page 5]
 280 \f
 281 Internet-Draft         Kerberos Anonymity Support              June 2006
 282
 283
 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
 287    different clients.
 288
 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.
 292
 293
 294 5.  GSS-API Implementation Notes
 295
 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().
 300
 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.
 307
 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
 317    "un-done".
 318
 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
 327    equivalent.
 328
 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().
 332
 333
 334
 335 Zhu, et al.             Expires December 5, 2006                [Page 6]
 336 \f
 337 Internet-Draft         Kerberos Anonymity Support              June 2006
 338
 339
 340 6.  Security Considerations
 341
 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.
 346
 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.
 355
 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.
 360
 361
 362 7.  Acknowledgements
 363
 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.
 368
 369
 370 8.  IANA Considerations
 371
 372    No IANA actions are required for this document.
 373
 374 9.  Normative References
 375
 376    [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints",
 377               draft-ietf-krb-wg-naming, work in progress.
 378
 379    [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
 380               RFC 1964, June 1996.
 381
 382    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 383               Requirement Levels", BCP 14, RFC 2119, March 1997.
 384
 385    [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 386               RFC 2246, January 1999.
 387
 388    [RFC2743]  Linn, J., "Generic Security Service Application Program
 389
 390
 391
 392 Zhu, et al.             Expires December 5, 2006                [Page 7]
 393 \f
 394 Internet-Draft         Kerberos Anonymity Support              June 2006
 395
 396
 397               Interface Version 2, Update 1", RFC 2743, January 2000.
 398
 399    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 400               Kerberos Network Authentication Service (V5)", RFC 4120,
 401               July 2005.
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448 Zhu, et al.             Expires December 5, 2006                [Page 8]
 449 \f
 450 Internet-Draft         Kerberos Anonymity Support              June 2006
 451
 452
 453 Authors' Addresses
 454
 455    Larry Zhu
 456    Microsoft Corporation
 457    One Microsoft Way
 458    Redmond, WA  98052
 459    US
 460
 461    Email: lzhu@microsoft.com
 462
 463
 464    Paul Leach
 465    Microsoft Corporation
 466    One Microsoft Way
 467    Redmond, WA  98052
 468    US
 469
 470    Email: paulle@microsoft.com
 471
 472
 473    Karthik Jaganathan
 474    Microsoft Corporation
 475    One Microsoft Way
 476    Redmond, WA  98052
 477    US
 478
 479    Email: karthikj@microsoft.com
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504 Zhu, et al.             Expires December 5, 2006                [Page 9]
 505 \f
 506 Internet-Draft         Kerberos Anonymity Support              June 2006
 507
 508
 509 Intellectual Property Statement
 510
 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.
 519
 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.
 526
 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
 531    ietf-ipr@ietf.org.
 532
 533
 534 Disclaimer of Validity
 535
 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.
 543
 544
 545 Copyright Statement
 546
 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.
 550
 551
 552 Acknowledgment
 553
 554    Funding for the RFC Editor function is currently provided by the
 555    Internet Society.
 556
 557
 558
 559
 560 Zhu, et al.             Expires December 5, 2006               [Page 10]
 561 \f
 562