< draft-zhu-kerb-anon-00.txt   draft-zhu-kerb-anon-01.txt >
NETWORK WORKING GROUP L. Zhu NETWORK WORKING GROUP L. Zhu
Internet-Draft P. Leach Internet-Draft P. Leach
Updates: 4120 (if approved) K. Jaganathan Updates: 4120 (if approved) K. Jaganathan
Expires: April 18, 2006 Microsoft Corporation Expires: September 7, 2006 Microsoft Corporation
October 15, 2005 March 6, 2006
Anonymity Support for Kerberos Anonymity Support for Kerberos
draft-zhu-kerb-anon-00 draft-zhu-kerb-anon-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines the use of anonymous Kerberos tickets for the This document defines the use of anonymous Kerberos tickets for the
purpose of authenticating the servers and enabling secure purpose of authenticating the servers and enabling secure
communication between a client and a server, without identifying the communication between a client and a server, without identifying the
client to the server. client to the server.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
In certain situations or environments, the Kerberos [RFC4120] client In certain situations or environments, the Kerberos [RFC4120] client
may wish to authenticate a server and/or protect communications may wish to authenticate a server and/or protect communications
without revealing its own identity. For example, consider an without revealing its own identity. For example, consider an
application which provides read access to a research database, and application which provides read access to a research database, and
which permits queries by arbitrary requestors. A client of such a which permits queries by arbitrary requestors. A client of such a
service might wish to authenticate the service, to establish trust in service might wish to authenticate the service, to establish trust in
the information received from it, but might not wish to disclose its the information received from it, but might not wish to disclose its
skipping to change at page 3, line 41 skipping to change at page 3, line 41
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definitions 3. Definitions
An anonymous ticket is a ticket that has all of the following An anonymous ticket is a ticket that has all of the following
properties: properties:
o The name-type of the client principal name is NT-UNKNOWN o The name-type of the client principal name is NT-UNKNOWN
[RFC4120], and the name-string is an empty SEQUENCE (this client [RFC4120], and the name-string is a sequence of three
principal name is referred hereafter as the anonymous client KerberosString components: "ANONYMOUS", "ANONYMOUS", and
principal name in this document). "ANONYMOUS". This client principal name is referred hereafter as
the anonymous client principal name in this document. A note on
why this anonymous principal was chosen historically: at the time
of writing it was believed that there exist implementations that
do not handle empty sequences as principal names correctly thus
using an empty sequence as the anonymous principal name, that can
be otherwise perceived as a more natural choice, could create a
security weakness for these implementations; the anonymous
principal is therefore chosen to be both non-empty and
exceedingly-unlikely-to-have-been-used so as to maximize backward
compatibility for deployed implementations.
o The client realm name is an empty KerberosString [RFC4120]. o The client realm name is an empty KerberosString [RFC4120].
o The tr-type field of the transited field [RFC4120] is NO- o The transited field [RFC4120] can either contain the client's
TRANSITED-INFO (as defined later in this section) and the contents authentication path or contain the anonymous authentication path
field is an empty OCTET STRING. No transited policy is defined defined as follows: the tr-type field of the transited field is
for anonymous tickets. NO-TRANSITED-INFO (as defined later in this section) and the
contents field is an empty OCTET STRING. If a TGS request
contains an anonymous ticket with a "normal" authentication path
(i.e. the transited field does not contain the anonymous
authentication path as defined above), then the reply ticket, if
any, MUST NOT contain the anonymous authentication path. For
application servers, no transited policy is defined for the
anonymous authentication path, but all of the transited checks
would still apply if an anonymous ticket contains a "normal"
authentication path. Note that the "normal" authentication path
in an anonymous ticket can be a partial path, thus it may not be
used to identify the originating client realm.
o It contains no information that can reveal the client's identity. o It contains no information that can reveal the client's identity
other than, at most, the client's realm or the realm(s) on the
authentication path.
o The anonymous ticket flag (as defined later in this section) is o The anonymous ticket flag (as defined later in this section) is
set. set.
The anonymous ticket flag is defined as bit 14 (with the first bit The anonymous ticket flag is defined as bit 14 (with the first bit
being bit 0) in the TicketFlags: being bit 0) in the TicketFlags:
TicketFlags ::= KerberosFlags TicketFlags ::= KerberosFlags
-- anonymous(14) -- anonymous(14)
-- TicketFlags and KerberosFlags are defined in [RFC4120] -- TicketFlags and KerberosFlags are defined in [RFC4120]
The anonymous ticket flag MUST NOT be set by implementations of this The anonymous ticket flag MUST NOT be set by implementations of this
specification if the ticket is not an anonymous ticket as defined. specification if the ticket is not an anonymous ticket as defined in
this section.
The request-anonymous KDC option is defined as bit 14 (with the first The request-anonymous KDC option is defined as bit 14 (with the first
bit being bit 0) in the KDCOptions: bit being bit 0) in the KDCOptions:
KDCOptions ::= KerberosFlags KDCOptions ::= KerberosFlags
-- request-anonymous(14) -- request-anonymous(14)
-- KDCOptions and KerberosFlags are defined in [RFC4120] -- KDCOptions and KerberosFlags are defined in [RFC4120]
The anonymous transited encoding type is defined as follows: The anonymous transited encoding type is defined as follows:
NO-TRANSITED-INFO 0 NO-TRANSITED-INFO 0
This transited encoding type indicates there is no information This transited encoding type indicates there is no information
available about the authentication path. available about the authentication path.
Note that the server principal name and the server realm in a cross-
realm referral TGT are not dependent on whether the client is the
anonymous principal or not.
4. Protocol Description 4. Protocol Description
In order to request an anonymous ticket, the client sets the request- In order to request an anonymous ticket, the client sets the request-
anonymous KDC option in an AS or TGS request [RFC4120]. Note that if anonymous KDC option in an AS or TGS request [RFC4120]. Note that if
the service ticket in the PA-TGS-REQ [RFC4120] is anonymous, the the service ticket in the PA-TGS-REQ [RFC4120] is anonymous, the
request-anonymous KDC option MUST be set in the request. request-anonymous KDC option MUST be set in the request.
When policy allows, the KDC issues an anonymous ticket. The KDC that When policy allows, the KDC issues an anonymous ticket. The KDC that
implements this specification MUST NOT carry information that can implements this specification MUST NOT carry information that can
reveal the client's identity, from the TGS request into the returned reveal the client's identity, from the TGS request into the returned
skipping to change at page 5, line 36 skipping to change at page 6, line 16
A server accepting such an anonymous service ticket may assume that A server accepting such an anonymous service ticket may assume that
subsequent requests using the same ticket originate from the same subsequent requests using the same ticket originate from the same
client. Requests with different tickets are likely to originate from client. Requests with different tickets are likely to originate from
different clients. different clients.
Interoperability and backward-compatibility notes: the KDC is given Interoperability and backward-compatibility notes: the KDC is given
the task of rejecting a request for an anonymous ticket when the the task of rejecting a request for an anonymous ticket when the
anonymous ticket is not acceptable by the server. anonymous ticket is not acceptable by the server.
5. Security Considerations 5. GSS-API Implementation Notes
Since KDCs ignore unknown options, a client requiring anonymous At the GSS-API level, the use of an anonymous principal by the
communication needs to make sure that the ticket is actually initiator/client requires a software change of the initiator/client
anonymous. A KDC that that does not understand the anonymous option software (to assert the "anonymous" flag when calling
would not return an anonymous ticket. GSS_Init_Sec_Context().
GSS-API does not know or define "anonymous credentials", so the
(printable) name of the anonymous principal will rarely be used by or
relevant for the initator/client. The printable name is relevant for
the acceptor/server when performing an authorization decision based
on the name that pops up from GSS_Accept_Sec_Context() upon
successful security context establishment.
A GSS-API initiator MUST carefully check the resulting context
attributes from the initial call to GSS_Init_Sec_Context() when
requesting anonymity, because (as in the GSS-API tradition and for
backwards compatibility) anonymity is just another optional context
attribute. It could be that the mechanism doesn't recognize the
attribute at all or that anonymity is not available for some other
reasons -- and in that case the initiator must NOT send the initial
security context token to the acceptor, because it will likely reveal
the initiators identity to the acceptor, something that can rarely be
"un-done".
GSS-API [RFC2743] defines name_type GSS_C_NT_ANONYMOUS to represent
an anonymous identity. In addition, according to Section 2.1.1 of
[RFC1964] the string representation of the anonymous client principal
name can be "ANONYMOUS/ANONYMOUS/ANONYMOUS" with the name_type
GSS_KRB5_NT_PRINCIPAL_NAME. Implementations conforming to this
specification MUST accept both forms and consider them equivalent.
Portable initiators are RECOMMENDED to use default credentials
whenever possible, and request anonymity only through the input
anon_req_flag to GSS_Init_Sec_Context().
6. Security Considerations
Since KDCs ignore unknown options [RFC4120], a client requiring
anonymous communication needs to make sure that the ticket is
actually anonymous. A KDC that that does not understand the
anonymous option would not return an anonymous ticket.
By using the mechanism defined in this specification, the client does By using the mechanism defined in this specification, the client does
not reveal its identity to the server but its identity may be not reveal its identity to the server but its identity may be
revealed to the KDC of the server principal (when the server revealed to the KDC of the server principal (when the server
principal is in a different realm than that of the client), and any principal is in a different realm than that of the client), and any
KDC on the cross-realm authentication path. The Kerberos client MUST KDC on the cross-realm authentication path. The Kerberos client MUST
verify the ticket being used are indeed anonymous before verify the ticket being used are indeed anonymous before
communicating with the cross-realm KDC or the server, otherwise the communicating with the cross-realm KDC or the server, otherwise the
client's identity may be revealed to the server unintentionally. client's identity may be revealed to the server unintentionally.
6. Acknowledgements In cases where specific server principals must not have access to the
client's identity (for example, an anonymous poll service), the KDC
can define server principal specific policy that insure any normal
service ticket can NEVER be issued to any of these server principals.
Most of this document is based on earlier versions of [RFC4120]. 7. Acknowledgements
The authors would like to thank Sam Hartman for his comments and The authors would like to thank the following individuals for their
suggestions. insightful comments and fruitful discussions: Sam Hartman, Martin
Rex, Nicolas Williams, Jeffery Altman, Tom Yu Love Hoernquist
Aestrand, and Jeffery Hutzelman.
7. IANA Considerations 8. IANA Considerations
No IANA actions are required for this document. No IANA actions are required for this document.
8. Normative References 9. Normative References
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
Authors' Addresses Authors' Addresses
Larry Zhu Larry Zhu
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
skipping to change at page 8, line 41 skipping to change at page 10, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 19 change blocks. 
36 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/