draft-ietf-krb-wg-anon-10.txt   draft-ietf-krb-wg-anon-11.txt 
NETWORK WORKING GROUP L. Zhu NETWORK WORKING GROUP L. Zhu
Internet-Draft P. Leach Internet-Draft P. Leach
Updates: 4120, 4121 and 4556 Microsoft Corporation Updates: 4120, 4121 and 4556 Microsoft Corporation
(if approved) October 8, 2008 (if approved) S. Hartman
Intended status: Standards Track Intended status: Standards Track Painless Security
Expires: April 11, 2009 Expires: December 31, 2010 June 29, 2010
Anonymity Support for Kerberos Anonymity Support for Kerberos
draft-ietf-krb-wg-anon-10 draft-ietf-krb-wg-anon-11
Abstract
This document defines extensions to the Kerberos protocol to allow a
Kerberos client to securely communicate with a Kerberos application
service without revealing its identity, or without revealing more
than its Kerberos realm. It also defines extensions which allow a
Kerberos client to obtain anonymous credentials without revealing its
identity to the Kerberos Key Distribution Center (KDC). This
document updates RFC 4120, RFC 4121, and RFC 4556.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 11, 2009. This Internet-Draft will expire on December 31, 2010.
Abstract Copyright Notice
This document defines extensions to the Kerberos protocol to allow a Copyright (c) 2010 IETF Trust and the persons identified as the
Kerberos client to securely communicate with a Kerberos application document authors. All rights reserved.
service without revealing its identity, or without revealing more
than its Kerberos realm. It also defines extensions which allow a This document is subject to BCP 78 and the IETF Trust's Legal
Kerberos client to obtain anonymous credentials without revealing its Provisions Relating to IETF Documents
identity to the Kerberos Key Distribution Center (KDC). This (http://trustee.ietf.org/license-info) in effect on the date of
document updates RFC 4120, RFC 4121, and RFC 4556. publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5
4.1. Anonymity Support in AS Exchange . . . . . . . . . . . . . 5 4.1. Anonymity Support in AS Exchange . . . . . . . . . . . . . 5
4.1.1. Anonymous PKINIT . . . . . . . . . . . . . . . . . . . 6 4.1.1. Anonymous PKINIT . . . . . . . . . . . . . . . . . . . 6
4.2. Anonymity Support in TGS Exchange . . . . . . . . . . . . 7 4.2. Anonymity Support in TGS Exchange . . . . . . . . . . . . 7
skipping to change at page 2, line 27 skipping to change at page 4, line 4
6. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 10 6. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 10
7. PKINIT Client Contribution to the Ticket Session Key . . . . . 11 7. PKINIT Client Contribution to the Ticket Session Key . . . . . 11
7.1. Combinging Two protocol Keys . . . . . . . . . . . . . . . 12 7.1. Combinging Two protocol Keys . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
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
the client's own identity. For example, consider an application the client's own identity. For example, consider an application
which provides read access to a research database, and which permits which 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
wish to authenticate the service, to establish trust in the wish to authenticate the service, to establish trust in the
information received from it, but might not wish to disclose the information received from it, but might not wish to disclose the
skipping to change at page 4, line 13 skipping to change at page 5, line 13
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], and the value of this well-known realm name name based on [KRBNAM], and the value of this well-known realm name
is the literal "WELLKNOWN:ANONYMOUS". is the literal "WELLKNOWN:ANONYMOUS".
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 is KRB_NT_WELLKNOWN [KRBNAM], and the value of the name- type field is KRB_NT_WELLKNOWN [KRBNAM], and the value of the name-
string field is a sequence of two KerberosString components: string field is a sequence of two KerberosString components:
"WELLKNOWN", "ANONYMOUS". "WELLKNOWN", "ANONYMOUS".
The anonymous ticket flag is defined as bit 14 (with the first bit The anonymous ticket flag is defined as bit 16 (with the first bit
being bit 0) in the TicketFlags: being bit 0) in the TicketFlags:
TicketFlags ::= KerberosFlags TicketFlags ::= KerberosFlags
-- anonymous(14) -- anonymous(16)
-- TicketFlags and KerberosFlags are defined in [RFC4120] -- TicketFlags and KerberosFlags are defined in [RFC4120]
This is a new ticket flag that is used to indicate a ticket is an This is a new ticket flag that is used to indicate a ticket is an
anonymous one. anonymous one.
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 contains the anonymous Kerberos principal name. o The cname field contains the anonymous Kerberos principal name.
skipping to change at page 4, line 43 skipping to change at page 5, line 43
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, would disclose the client's if included in the anonymous ticket, would 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 anonymous KDC option is defined as bit 14 (with the first bit The anonymous KDC option is defined as bit 16 (with the first bit
being bit 0) in the KDCOptions: being bit 0) in the KDCOptions:
KDCOptions ::= KerberosFlags KDCOptions ::= KerberosFlags
-- anonymous(14) -- anonymous(16)
-- KDCOptions and KerberosFlags are defined in [RFC4120] -- KDCOptions and KerberosFlags are defined in [RFC4120]
As described in Section 4, the anonymous KDC option is set to request As described in Section 4, the anonymous KDC option is set to request
an anonymous ticket in an Authentication Service (AS) request or an an anonymous ticket in an Authentication Service (AS) request or an
Ticket Granting Service (TGS) request. Ticket Granting Service (TGS) request.
4. Protocol Description 4. Protocol Description
In order to request an anonymous ticket, the client sets the In order to request an anonymous ticket, the client sets the
anonymous KDC option in an AS request or an TGS request. anonymous KDC option in an AS request or an TGS request.
skipping to change at page 10, line 24 skipping to change at page 11, line 24
represent the anonymous identity. In addition, Section 2.1.1 of represent the anonymous identity. In addition, Section 2.1.1 of
[RFC1964] defines the single string representation of a Kerberos [RFC1964] defines the single string representation of a Kerberos
principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. The principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. The
anonymous principal with the anonymous realm corresponds to the GSS- anonymous principal with the anonymous realm corresponds to the GSS-
API anonymous principal. A principal with the anonymous principal API anonymous principal. A principal with the anonymous principal
name and a non-anonymous realm is an authenticated principal, hence name and a non-anonymous realm is an authenticated principal, hence
such a principal does not correspond to the anonymous principal in such a principal does not correspond to the anonymous principal in
GSS-API with the GSS_C_NT_ANONYMOUS name type. The [RFC1964] name GSS-API with the GSS_C_NT_ANONYMOUS name type. The [RFC1964] name
syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the
anonymous principal name with a non-anonymous realm name and for anonymous principal name with a non-anonymous realm name and for
displaying and exporting these names. displaying and exporting these names. In addition, this syntax must
be used along with the name type GSS_C_NT_ANONYMOUS for displaying
and exporting the anonymous principal with the anonymous realm.
At the GSS-API [RFC2743] level, an initiator/client requests the use At the GSS-API [RFC2743] level, an initiator/client requests the use
of an anonymous principal with the anonymous realm by asserting the of an anonymous principal with the anonymous realm by asserting the
"anonymous" flag when calling GSS_Init_Sec_Context(). The GSS-API "anonymous" flag when calling GSS_Init_Sec_Context(). The GSS-API
implementation MAY provide implementation-specific means for implementation MAY provide implementation-specific means for
requesting the use of an anonymous principal with a non-anonymous requesting the use of an anonymous principal with a non-anonymous
realm. realm.
GSS-API does not know or define "anonymous credentials", so the GSS-API does not know or define "anonymous credentials", so the
(printable) name of the anonymous principal will rarely be used by or (printable) name of the anonymous principal will rarely be used by or
skipping to change at page 11, line 31 skipping to change at page 12, line 33
conforming to this definition MUST encrypt a randomly generated key, conforming to this definition MUST encrypt a randomly generated key,
called the KDC contribution key, in the PA_PKINIT_KX padata (defined called the KDC contribution key, in the PA_PKINIT_KX padata (defined
next in this section). The KDC contribution key is then combined next in this section). The KDC contribution key is then combined
with the reply key to form the ticket session key of the returned with the reply key to form the ticket session key of the returned
ticket. These two keys are then combined using the KRB-FX-CF2 ticket. These two keys are then combined using the KRB-FX-CF2
operation defined in Section 7.1, where K1 is the KDC contribution operation defined in Section 7.1, where K1 is the KDC contribution
key, K2 is the reply key, the input pepper1 is American Standard Code key, K2 is the reply key, the input pepper1 is American Standard Code
for Information Interchange (ASCII) [ASAX34] string "PKINIT", and the for Information Interchange (ASCII) [ASAX34] string "PKINIT", and the
input pepper2 is ASCII string "KeyExchange". input pepper2 is ASCII string "KeyExchange".
PA_PKINIT_KX 135 PA_PKINIT_KX 147
-- padata for PKINIT that contains an encrypted -- padata for PKINIT that contains an encrypted
-- KDC contribution key. -- KDC contribution key.
PA-PKINIT-KX ::= EncryptedData -- EncryptionKey PA-PKINIT-KX ::= EncryptedData -- EncryptionKey
-- Contains an encrypted key randomly -- Contains an encrypted key randomly
-- generated by the KDC (known as the KDC contribution key). -- generated by the KDC (known as the KDC contribution key).
-- Both EncryptedData and EncryptionKey are defined in [RFC4120] -- Both EncryptedData and EncryptionKey are defined in [RFC4120]
The PA_PKINIT_KX padata MUST be included in the KDC reply when The PA_PKINIT_KX padata MUST be included in the KDC reply when
anonymous PKINIT is used; it SHOULD be included if PKINIT is used anonymous PKINIT is used; it SHOULD be included if PKINIT is used
with the Diffie-Helleman key exchange but the client is not with the Diffie-Hellman key exchange but the client is not anonymous;
anonymous; it MUST NOT be included otherwise (e.g. when PKINIT is it MUST NOT be included otherwise (e.g. when PKINIT is used with the
used with the public key encryption as the key exchange). public key encryption as the key exchange).
The padata-value field of the PA-PKINIT-KX type padata contains the The padata-value field of the PA-PKINIT-KX type padata contains the
DER [X680] [X690] encoding of the Abstract Syntax Notation One DER [X680] [X690] encoding of the Abstract Syntax Notation One
(ASN.1) type PA-PKINIT-KX. The PA-PKINIT-KX structure is a (ASN.1) type PA-PKINIT-KX. The PA-PKINIT-KX structure is a
EncryptedData. The clear text data being encrypted is the DER EncryptedData. The clear text data being encrypted is the DER
encoded Kerberos session key randomly generated by the KDC. The encoded KDC contribution key randomly generated by the KDC. The
encryption key is the reply key and the key usage number is encryption key is the reply key and the key usage number is
KEY_USAGE_PA_PKINIT_KX (44). KEY_USAGE_PA_PKINIT_KX (44).
The client then decrypts the KDC contribution key and verifies the The client then decrypts the KDC contribution key and verifies the
ticket session key in the returned ticket is the combined key of the ticket session key in the returned ticket is the combined key of the
KDC contribution key and the reply key as described above. A KDC contribution key and the reply key as described above. A
conforming client MUST reject anonymous PKINIT authentication if the conforming client MUST reject anonymous PKINIT authentication if the
PA_PKINIT_KX padata is not present in the KDC reply or if the ticket PA_PKINIT_KX padata is not present in the KDC reply or if the ticket
session key of the returned ticket is not the combined key of the KDC session key of the returned ticket is not the combined key of the KDC
contribution key and the reply key when PA-PKINIT-KX is present in contribution key and the reply key when PA-PKINIT-KX is present in
skipping to change at page 14, line 35 skipping to change at page 15, line 35
This document defines a new 'anonymous' Kerberos well-known name and This document defines a new 'anonymous' Kerberos well-known name and
a new 'anonymous' Kerberos well-known realm based on [KRBNAM]. IANA a new 'anonymous' Kerberos well-known realm based on [KRBNAM]. IANA
is requested to add these two values to the Kerberos naming is requested to add these two values to the Kerberos naming
registries that are created in [KRBNAM]. registries that are created in [KRBNAM].
11. References 11. References
11.1. Normative References 11.1. Normative References
[ASAX34] American Standard Code for Information Interchange,
ASA X3.4-1963, American Standards Association, June 17,
1963.
[KRBNAM] Zhu, L., "Additional Kerberos Naming Constraints", [KRBNAM] Zhu, L., "Additional Kerberos Naming Constraints",
draft-ietf-krb-wg-naming (work in progress), 2008. draft-ietf-krb-wg-naming (work in progress), 2008.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996. 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.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
skipping to change at page 15, line 13 skipping to change at page 16, line 13
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, February 2005.
[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.
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
11.2. Informative References 11.2. Informative References
[FAST] Zhu, L. and S. Hartman, "A Generalized Framework for [FAST] Zhu, L. and S. Hartman, "A Generalized Framework for
Kerberos Pre-Authentication", Kerberos Pre-Authentication",
draft-ietf-krb-wg-preauth-framework (work in progress), draft-ietf-krb-wg-preauth-framework (work in progress),
2008. 2008.
Authors' Addresses Authors' Addresses
Larry Zhu Larry Zhu
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Email: lzhu@microsoft.com Email: larry.zhu@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
Full Copyright Statement Sam Hartman
Painless Security
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Email: hartmans-ietf@mit.edu
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 20 change blocks. 
76 lines changed or deleted 57 lines changed or added

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