draft-ietf-krb-wg-anon-03.txt   draft-ietf-krb-wg-anon-04.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) Microsoft Corporation
Intended status: Standards Track Microsoft Corporation Intended status: Standards Track July 7, 2007
Expires: September 3, 2007 March 2, 2007 Expires: January 8, 2008
Anonymity Support for Kerberos Anonymity Support for Kerberos
draft-ietf-krb-wg-anon-03 draft-ietf-krb-wg-anon-04
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 September 3, 2007. This Internet-Draft will expire on January 8, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines extensions to the Kerberos protocol for the This document defines extensions to the Kerberos protocol for the
Kerberos client to authenticate the Kerberos Key Distribution Center Kerberos client to authenticate the Kerberos Key Distribution Center
and the Kerberos server, without revealing the client's identity. and the Kerberos server, without revealing the client's identity.
These extensions can be used to secure communication between the These extensions can be used to secure communication between the
anonymous client and the server. anonymous client and 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 . . . . . . . . . . . . . . . . . . . . . 4
5. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 7 5. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
In certain situations, the Kerberos [RFC4120] client may wish to In certain situations, the Kerberos [RFC4120] client may wish to
authenticate a server and/or protect communications without revealing authenticate a server and/or protect communications without revealing
its own identity. For example, consider an application which its own identity. For example, consider an application which
provides read access to a research database, and which permits provides read access to a research database, and which permits
queries by arbitrary requestors. A client of such a service might queries by arbitrary requestors. A client of such a service might
skipping to change at page 3, line 43 skipping to change at page 3, line 43
3. Definitions 3. Definitions
The anonymous Kerberos realm name is defined as a well-known realm The anonymous Kerberos realm name is defined as a well-known realm
name based on [KRBNAM]. The value is the literal "WELLKNOWN: name based on [KRBNAM]. The value is the literal "WELLKNOWN:
ANONYMOUS". An anonymous Kerberos realm name MUST NOT be present in ANONYMOUS". An anonymous Kerberos realm name MUST NOT be present in
the transited field [RFC4120] of a ticket. the transited field [RFC4120] of a ticket.
The anonymous Kerberos principal name is defined as a well-known The anonymous Kerberos principal name is defined as a well-known
Kerberos principal name based on [KRBNAM]. The value of the name- Kerberos principal name based on [KRBNAM]. The value of the name-
type field [RFC4120] is KRB_NT_RESRVED [KRBNAM], and the value of the type field [RFC4120] is KRB_NT_WELLKNOWN [KRBNAM], and the value of
name-string field [RFC4120] is a sequence of two KerberosString the name-string field [RFC4120] is a sequence of two KerberosString
components: "WELLKNOWN", "ANONYMOUS". components: "WELLKNOWN", "ANONYMOUS".
Note that in this specification, the anonymous principal name and Note that in this specification, the anonymous principal name and
realm are only applicable to the client in Kerberos messages, the realm are only applicable to the client in Kerberos messages, the
server MUST NOT be anonymous in any Kerberos message. server MUST NOT be anonymous in any Kerberos message.
The anonymous ticket flag is defined as bit TBA (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(TBA) -- anonymous(14)
-- TicketFlags and KerberosFlags are defined in [RFC4120] -- TicketFlags and KerberosFlags are defined in [RFC4120]
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 cname field [RFC4120] contains the anonymous Kerberos o The cname field [RFC4120] contains the anonymous Kerberos
principal name. principal name.
o The crealm field [RFC4120] contains the client's realm name, or o The crealm field [RFC4120] contains the client's realm name, or
the name of the realm that issued the initial ticket for the the name of the realm that issued the initial ticket for the
skipping to change at page 4, line 34 skipping to change at page 4, line 34
realm, intermediate realms on the client's authentication path, realm, intermediate realms on the client's authentication path,
and authorization data that may provide information related to the and authorization data that may provide information related to the
client's identity. For example, an anonymous principal that is client's identity. For example, an anonymous principal that is
identifiable only within a particular group of users can be identifiable only within a particular group of users can be
implemented using authorization data and such authorization data, implemented using authorization data and such authorization data,
if included in the anonymous ticket, shall disclose the client's if included in the anonymous ticket, shall disclose the client's
membership of that group. membership of that group.
o The anonymous ticket flag is set. o The anonymous ticket flag is set.
The request-anonymous KDC option is defined as bit TBA (with the The anonymous KDC option is defined as bit 14 (with the first bit
first bit being bit 0) in the KDCOptions: being bit 0) in the KDCOptions:
KDCOptions ::= KerberosFlags KDCOptions ::= KerberosFlags
-- request-anonymous(TBA) -- anonymous(14)
-- KDCOptions and KerberosFlags are defined in [RFC4120] -- KDCOptions and KerberosFlags are defined in [RFC4120]
As described in Section 4, the request-anonymous KDC option is set to As described in Section 4, the anonymous KDC option is set to request
request an anonymous ticket. an anonymous ticket.
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
anonymous KDC option in an Authentication Exchange (AS) or Ticket anonymous KDC option in an Authentication Exchange (AS) or Ticket
Granting Service (TGS) request [RFC4120]. The client can request an Granting Service (TGS) request [RFC4120]. The client can request an
anonymous Ticket Granting Ticket (TGT) based on a normal TGT. Unless anonymous Ticket Granting Ticket (TGT) based on a normal TGT. Unless
otherwise specified, the client can obtain an anonymous ticket with otherwise specified, the client can obtain an anonymous ticket with
the anonymous realm name only by requesting an anonymous ticket in an the anonymous realm name only by requesting an anonymous ticket in an
AS exchange with the client realm set as anonymous in the request. AS exchange with the client realm set as anonymous in the request.
If the client wishes to authenticate the KDC anonymously, it sets the If the client wishes to authenticate the KDC anonymously, it sets the
client name as anonymous in the AS exchange and provides a client name as anonymous in the AS exchange and provides a
PA_PK_AS_REQ pre-authentication data [RFC4556] where both the PA_PK_AS_REQ pre-authentication data [RFC4556] where both the
signerInfos field and the certificates field of the SignedData signerInfos field and the certificates field of the SignedData
[RFC3852] of the PA_PK_AS_REQ are empty. Because the anonymous [RFC3852] of the PA_PK_AS_REQ are empty. Because the anonymous
client does not have an associated asymmetric key pair, the client client does not have an associated asymmetric key pair, the client
MUST choose the Diffie-Hellman key agreement method by filling in the MUST choose the Diffie-Hellman key agreement method by filling in the
Diffie-Hellman domain parameters in the clientPublicValue [RFC4556]. Diffie-Hellman domain parameters in the clientPublicValue [RFC4556].
If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is
anonymous, or if the client in the AS request is anonymous, the anonymous, or if the client in the AS request is anonymous, the
request-anonymous KDC option MUST be set in the request. Otherwise, anonymous KDC option MUST be set in the request. Otherwise, the KDC
the KDC MUST return a KRB-ERROR message with the code MUST return a KRB-ERROR message with the code KDC_ERR_BADOPTION
KDC_ERR_BADOPTION [RFC4120], and there is no accompanying e-data [RFC4120], and there is no accompanying e-data defined in this
defined in this document. document.
Upon receiving the AS request with a PA_PK_AS_REQ [RFC4556] from the Upon receiving the AS request with a PA_PK_AS_REQ [RFC4556] from the
anonymous client, the KDC processes the request according to Section anonymous client, the KDC processes the request according to Section
3.1.2 of [RFC4120]. The KDC skips the checks for the client's 3.1.2 of [RFC4120]. The KDC skips the checks for the client's
signature and the client's public key (such as the verification of signature and the client's public key (such as the verification of
the binding between the client's public key and the client name), but the binding between the client's public key and the client name), but
performs otherwise-applicable checks, and proceeds as normal performs otherwise-applicable checks, and proceeds as normal
according to [RFC4556]. For example, the AS MUST check if the according to [RFC4556]. For example, the AS MUST check if the
client's Diffie-Hellman domain parameters are acceptable. The client's Diffie-Hellman domain parameters are acceptable. The
Diffie-Hellman key agreement method MUST be used and the reply key is Diffie-Hellman key agreement method MUST be used and the reply key is
skipping to change at page 6, line 23 skipping to change at page 6, line 23
When policy allows, the KDC issues an anonymous ticket. Based on When policy allows, the KDC issues an anonymous ticket. Based on
local policy, the client realm in the anonymous ticket can be the local policy, the client realm in the anonymous ticket can be the
anonymous realm name or the realm of the KDC. However, in all cases, anonymous realm name or the realm of the KDC. However, in all cases,
the client name and the client realm in the EncKDCRepPart of the the client name and the client realm in the EncKDCRepPart of the
reply [RFC4120] MUST match with the corresponding client name and the reply [RFC4120] MUST match with the corresponding client name and the
client realm of the anonymous ticket in the reply. The client MUST client realm of the anonymous ticket in the reply. The client MUST
use the client name and the client realm returned in the use the client name and the client realm returned in the
EncKDCRepPart in subsequent message exchanges when using the obtained EncKDCRepPart in subsequent message exchanges when using the obtained
anonymous ticket. anonymous ticket.
During the TGS request, when propagating authorization data, care When propagating authorization data in the ticket or in the enc-
MUST be taken by the TGS to ensure that the client confidentiality is authorization-data field [RFC4120] of the request, the TGS MUST
not violated. If a anonymous ticket is returned, any authorization ensure that the client confidentiality is not violated in the
element that may reveal the client's identity MUST be removed. The returned anonymous ticket. The TGS MUST process the authorization
authentication attempt MUST be rejected if there is an authorization data recursively according to Section 5.2.6 of [RFC4120] beyond the
element that is intended to restrict the use of the ticket thus container levels such that all embedded authorization elements are
cannot be removed or the local policy prevents the removal of an interpreted. Identity-based authorization data SHOULD NOT be present
authorization element, and this rule MUST be applied to all critical in an anonymous ticket in that it typically reveals the client's
and optional authorization data. An optional authorization element identity. The specification of a new authorization data type MUST
unknown by the TGS MUST be removed if it does not potentially convey specify the processing rules of the authorization data when an
any rights or limit the rights otherwise conveyed in the ticket. If anonymous ticket is returned. If there is no processing rule defined
there is a critical unknown authorization element, unless this for an authorization data element or the authorization data element
element is encapsulated in a known authorization data element is unknown, the TGS MUST process it when an anonymous ticket is
amending the criticality of the elements it contains, authentication returned as follows:
MUST fail according to [RFC4120]. If it is inappropriate to remove
an authorization element from the TGS request in order to produce an o If the authorization data element may reveal the client's
anonymous ticket, the KDC MUST return an error message with the code identity, it MUST be removed unless otherwise specified.
KDC_ERR_POLICY [RFC4120], and there is no accompanying e-data defined
in this document. o If the authorization data element is intended to restrict the use
of the ticket or limit the rights otherwise conveyed in the
ticket, it cannot be removed in order to hide the client's
identity. In this case, the authentication attempt MUST be
rejected, and the KDC MUST return an error message with the code
KDC_ERR_POLICY [RFC4120]. There is no accompanying e-data defined
in this document. Note this is applicable to both critical and
optional authorization data.
o If the authorization data element is unknown, the TGS MAY remove
it, or transfer it into the returned anonymous ticket, or reject
the authentication attempt, based on local policy for that
authorization data type unless otherwise specified. If there is
no policy defined for a given unknown authorization data type, the
authentication MUST be rejected. The error code is KDC_ERR_POLICY
when the authentication is rejected.
The AD-INITIAL-VERIFIED-CAS authorization data [RFC4556] MAY be
removed from an anonymous ticket based on local policy of the TGS.
The TGS MUST add the name of the previous realm according to Section The TGS MUST add the name of the previous realm according to Section
3.3.3.2 of [RFC4120]. If the client's realm is the anonymous realm, 3.3.3.2 of [RFC4120]. If the client's realm is the anonymous realm,
the abbreviation forms [RFC4120] that build on the preceding name the abbreviation forms [RFC4120] that build on the preceding name
cannot be used at the start of the transited encoding. The null- cannot be used at the start of the transited encoding. The null-
subfield form (e.g., encoding ending with ",") [RFC4120] could not be subfield form (e.g., encoding ending with ",") [RFC4120] could not be
used next to the anonymous realm that can potentially be at the used next to the anonymous realm that can potentially be at the
beginning where the client realm is filled in. beginning where the client realm is filled in.
The KDC fills out the authtime field of the anonymous ticket in the The KDC fills out the authtime field of the anonymous ticket in the
skipping to change at page 7, line 21 skipping to change at page 7, line 39
If the client is anonymous and the KDC does not have a key to encrypt If the client is anonymous and the KDC does not have a key to encrypt
the reply (this can happen when, for example, the KDC does not the reply (this can happen when, for example, the KDC does not
support PKINIT [RFC4556]), the KDC MUST return an error message with support PKINIT [RFC4556]), the KDC MUST return an error message with
the code KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying the code KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying
e-data defined in this document. e-data defined in this document.
If a client requires anonymous communication then the client MUST If a client requires anonymous communication then the client MUST
check to make sure that the ticket in the reply is actually anonymous check to make sure that the ticket in the reply is actually anonymous
by checking the presence of the anonymous ticket flag. This is by checking the presence of the anonymous ticket flag. This is
because KDCs ignore unknown KDC options. A KDC that does not because KDCs ignore unknown KDC options. A KDC that does not
understand the request-anonymous KDC option will not return an error, understand the anonymous KDC option will not return an error, but
but will instead return a normal ticket. will instead return a normal ticket.
The subsequent client and server communications then proceed as The subsequent client and server communications then proceed as
described in [RFC4120]. described in [RFC4120].
A server accepting an anonymous service ticket may assume that A server accepting 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.
5. GSS-API Implementation Notes 5. GSS-API Implementation Notes
skipping to change at page 9, line 8 skipping to change at page 9, line 27
obtaining such records could breach the anonymity. Additionally, the obtaining such records could breach the anonymity. Additionally, the
implementations of most (for now all) KDC's respond to requests at implementations of most (for now all) KDC's respond to requests at
the time that they are received. Traffic analysis on the connection the time that they are received. Traffic analysis on the connection
to the KDC will allow an attacker to match client identities to to the KDC will allow an attacker to match client identities to
anonymous tickets issued. Because there are plaintext parts of the anonymous tickets issued. Because there are plaintext parts of the
tickets that are exposed on the wire, such matching by a third party tickets that are exposed on the wire, such matching by a third party
observer is relatively straightforward. observer is relatively straightforward.
7. Acknowledgements 7. Acknowledgements
JK Jaganathan helped editing early revisions of this document.
Clifford Neuman contributed the core notions of this document. Clifford Neuman contributed the core notions of this document.
Ken Raeburn reviewed the document and provided suggestions for Ken Raeburn reviewed the document and provided suggestions for
improvements. improvements.
Martin Rex wrote the text for GSS-API considerations. Martin Rex wrote the text for GSS-API considerations.
Nicolas Williams reviewed the GSS-API considerations section and Nicolas Williams reviewed the GSS-API considerations section and
suggested ideas for improvements. suggested ideas for improvements.
skipping to change at page 10, line 29 skipping to change at page 11, line 5
Email: lzhu@microsoft.com Email: lzhu@microsoft.com
Paul Leach Paul Leach
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Email: paulle@microsoft.com Email: paulle@microsoft.com
Karthik Jaganathan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: karthikj@microsoft.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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
 End of changes. 17 change blocks. 
50 lines changed or deleted 62 lines changed or added

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