draft-ietf-kitten-rfc6112bis-02.txt   draft-ietf-kitten-rfc6112bis-03.txt 
Network Working Group L. Zhu Network Working Group L. Zhu
Internet-Draft P. Leach Internet-Draft P. Leach
Obsoletes: 6112 (if approved) Microsoft Corporation Obsoletes: 6112 (if approved) Microsoft Corporation
Updates: 4120, 4121, 4556 (if approved) S. Hartman, Ed. Updates: 4120, 4121, 4556 (if approved) S. Hartman
Intended status: Standards Track Painless Security Intended status: Standards Track Painless Security
Expires: March 8, 2017 S. Emery, Ed. Expires: May 20, 2017 S. Emery, Ed.
Oracle Oracle
September 4, 2016 November 16, 2016
Anonymity Support for Kerberos Anonymity Support for Kerberos
draft-ietf-kitten-rfc6112bis-02 draft-ietf-kitten-rfc6112bis-03
Abstract Abstract
This document defines extensions to the Kerberos protocol to allow a This document defines extensions to the Kerberos protocol to allow a
Kerberos client to securely communicate with a Kerberos application Kerberos client to securely communicate with a Kerberos application
service without revealing its identity, or without revealing more service without revealing its identity, or without revealing more
than its Kerberos realm. It also defines extensions that allow a than its Kerberos realm. It also defines extensions that allow a
Kerberos client to obtain anonymous credentials without revealing its Kerberos client to obtain anonymous credentials without revealing its
identity to the Kerberos Key Distribution Center (KDC). This identity to the Kerberos Key Distribution Center (KDC). This
document updates RFCs 4120, 4121, and 4556. This document obsoletes document updates RFCs 4120, 4121, and 4556. This document obsoletes
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 8, 2017. This Internet-Draft will expire on May 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes Since RFC 6112 . . . . . . . . . . . . . . . . . 4 1.1. Changes Since RFC 6112 . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . 8 4.2. Anonymity Support in TGS Exchange . . . . . . . . . . . . 8
4.3. Subsequent Exchanges and Protocol Actions Common to AS 4.3. Subsequent Exchanges and Protocol Actions Common to AS
and TGS for Anonymity Support . . . . . . . . . . . . . . 9 and TGS for Anonymity Support . . . . . . . . . . . . . . 10
5. Interoperability Requirements . . . . . . . . . . . . . . . . 10 5. Interoperability Requirements . . . . . . . . . . . . . . . . 10
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. Combining Two Protocol Keys . . . . . . . . . . . . . . . 13 7.1. Combining Two Protocol Keys . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 that the client's own identity. For example, consider an application that
provides read access to a research database and that permits queries provides read access to a research database and that permits queries
by arbitrary requesters. A client of such a service might wish to by arbitrary requesters. A client of such a service might wish to
authenticate the service, to establish trust in the information authenticate the service, to establish trust in the information
received from it, but might not wish to disclose the client's received from it, but might not wish to disclose the client's
skipping to change at page 3, line 44 skipping to change at page 3, line 44
In this specification, the client realm in the anonymous ticket is In this specification, the client realm in the anonymous ticket is
the anonymous realm name when anonymous PKINIT is used to obtain the the anonymous realm name when anonymous PKINIT is used to obtain the
ticket. The client realm is the client's real realm name if the ticket. The client realm is the client's real realm name if the
client is authenticated using the client's long-term keys. Note that client is authenticated using the client's long-term keys. Note that
a membership in a realm can imply a member of the community a membership in a realm can imply a member of the community
represented by the realm. represented by the realm.
The interaction with Generic Security Service Application Program The interaction with Generic Security Service Application Program
Interface (GSS-API) is described after the protocol description. Interface (GSS-API) is described after the protocol description.
This specification replaces RFC 6112 to correct technical errors in This specification replaces [RFC6112] to correct technical errors in
that specification. RFC 6112 is classified is historic; that specification. RFC 6112 is classified as historic;
implementation of RFC 6112 is NOT RECOMMENDED: existing implementation of RFC 6112 is NOT RECOMMENDED: existing
implementations comply with this specification and not RFC 6112. implementations comply with this specification and not RFC 6112.
1.1. Changes Since RFC 6112 1.1. Changes Since RFC 6112
In Section 7, the pepper2 string is corrected to comply with the In Section 7, the pepper2 string, "KeyExchange", is corrected to
string actually used by implementations. comply with the string actually used by implementations.
The requirement for the anonymous option to be used when an anonymous The requirement for the anonymous option to be used when an anonymous
ticket is used in a TGS request is reduced from a MUST to a SHOULD. ticket is used in a TGS request is reduced from a MUST to a SHOULD.
At least one implementation does not require this and is not
necessary that both be used as an indicator of request type.
Corrected the authorization data type name, AD-INITIAL-VERIFIED-CAS,
referenced in this document.
2. Conventions Used in This Document 2. Conventions Used in This Document
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
The anonymous Kerberos realm name is defined as a well-known realm The anonymous Kerberos realm name is defined as a well-known realm
skipping to change at page 6, line 20 skipping to change at page 6, line 26
When policy allows, the KDC issues an anonymous ticket. If the When policy allows, the KDC issues an anonymous ticket. If the
client name in the request is the anonymous principal, the client client name in the request is the anonymous principal, the client
realm (crealm) in the reply is the anonymous realm, otherwise, the realm (crealm) in the reply is the anonymous realm, otherwise, the
client realm is the realm of the AS. As specified by [RFC4120], the client realm is the realm of the AS. As specified by [RFC4120], the
client name and the client realm in the EncTicketPart of the reply client name and the client realm in the EncTicketPart of the reply
MUST match with the corresponding client name and the client realm of MUST match with the corresponding client name and the client realm of
the KDC reply; the client MUST use the client name and the client the KDC reply; the client MUST use the client name and the client
realm returned in the KDC-REP in subsequent message exchanges when realm returned in the KDC-REP in subsequent message exchanges when
using the obtained anonymous ticket. using the obtained anonymous ticket.
Care MUST be taken by the KDC not to reveal the client's identity in The KDC MUST NOT reveal the client's identity in the authorization
the authorization data of the returned ticket when populating the data of the returned ticket when populating the authorization data in
authorization data in a returned anonymous ticket. a returned anonymous ticket.
The AD_INITIAL_VERIFIED_CAS authorization data, as defined in The AD_INITIAL_VERIFIED_CAS authorization data, as defined in
[RFC4556], contains the issuer name of the client certificate. This [RFC4556], contains the issuer name of the client certificate. This
authorization is not applicable and MUST NOT be present in the authorization is not applicable and MUST NOT be present in the
returned anonymous ticket when anonymous PKINIT is used. When the returned anonymous ticket when anonymous PKINIT is used. When the
client is authenticated (i.e., anonymous PKINIT is not used), if it client is authenticated (i.e., anonymous PKINIT is not used), if it
is undesirable to disclose such information about the client's is undesirable to disclose such information about the client's
identity, the AD_INITIAL_VERIFIED_CAS authorization data SHOULD be identity, the AD_INITIAL_VERIFIED_CAS authorization data SHOULD be
removed from the returned anonymous ticket. removed from the returned anonymous ticket.
skipping to change at page 8, line 36 skipping to change at page 8, line 43
in the TGS request is a normal ticket, the returned anonymous ticket in the TGS request is a normal ticket, the returned anonymous ticket
contains the client name as the anonymous principal and the client contains the client name as the anonymous principal and the client
realm as the true realm of the client. In all cases, according to realm as the true realm of the client. In all cases, according to
[RFC4120] the client name and the client realm in the EncTicketPart [RFC4120] the client name and the client realm in the EncTicketPart
of the reply MUST match with the corresponding client name and the of the reply 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 KDC-REP in use the client name and the client realm returned in the KDC-REP in
subsequent message exchanges when using the obtained anonymous subsequent message exchanges when using the obtained anonymous
ticket. ticket.
Care MUST be taken by the TGS not to reveal the client's identity in The TGS MUST NOT reveal the client's identity in the authorization
the authorization data of the returned ticket. When propagating data of the returned ticket. When propagating authorization data in
authorization data in the ticket or in the enc-authorization-data the ticket or in the enc-authorization-data field of the request, the
field of the request, the TGS MUST ensure that the client TGS MUST ensure that the client confidentiality is not violated in
confidentiality is not violated in the returned anonymous ticket. the returned anonymous ticket. The TGS MUST process the
The TGS MUST process the authorization data recursively, according to authorization data recursively, according to Section 5.2.6 of
Section 5.2.6 of [RFC4120], beyond the container levels such that all [RFC4120], beyond the container levels such that all embedded
embedded authorization elements are interpreted. The TGS SHOULD NOT authorization elements are interpreted. The TGS SHOULD NOT populate
populate identity-based authorization data into an anonymous ticket identity-based authorization data into an anonymous ticket in that
in that such authorization data typically reveals the client's such authorization data typically reveals the client's identity. The
identity. The specification of a new authorization data type MUST specification of a new authorization data type MUST specify the
specify the processing rules of the authorization data when an processing rules of the authorization data when an anonymous ticket
anonymous ticket is returned. If there is no processing rule defined is returned. If there is no processing rule defined for an
for an authorization data element or the authorization data element authorization data element or the authorization data element is
is unknown, the TGS MUST process it when an anonymous ticket is unknown, the TGS MUST process it when an anonymous ticket is returned
returned as follows: as follows:
o If the authorization data element may reveal the client's o If the authorization data element may reveal the client's
identity, it MUST be removed unless otherwise specified. identity, it MUST be removed unless otherwise specified.
o If the authorization data element, that could reveal the client's o If the authorization data element, that could reveal the client's
identity, is intended to restrict the use of the ticket or limit identity, is intended to restrict the use of the ticket or limit
the rights otherwise conveyed in the ticket, it cannot be removed the rights otherwise conveyed in the ticket, it cannot be removed
in order to hide the client's identity. In this case, the in order to hide the client's identity. In this case, the
authentication attempt MUST be rejected, and the TGS MUST return authentication attempt MUST be rejected, and the TGS MUST return
an error message with the code KDC_ERR_POLICY. Note this is an error message with the code KDC_ERR_POLICY. Note this is
skipping to change at page 14, line 45 skipping to change at page 15, line 8
ticket linking. ticket linking.
The client's real identity is not revealed when the client is The client's real identity is not revealed when the client is
authenticated as the anonymous principal. Application servers MAY authenticated as the anonymous principal. Application servers MAY
reject the authentication in order to, for example, prevent reject the authentication in order to, for example, prevent
information disclosure or as part of Denial of Service (DoS) information disclosure or as part of Denial of Service (DoS)
prevention. Application servers MUST avoid accepting anonymous prevention. Application servers MUST avoid accepting anonymous
credentials in situations where they must record the client's credentials in situations where they must record the client's
identity; for example, when there must be an audit trail. identity; for example, when there must be an audit trail.
9. Acknowledgements 9. Acknowledgments
JK Jaganathan helped editing early revisions of this document. 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.
skipping to change at page 15, line 22 skipping to change at page 15, line 31
Sam Hartman and Nicolas Williams were great champions of this work. Sam Hartman and Nicolas Williams were great champions of this work.
Miguel Garcia and Phillip Hallam-Baker reviewed the document and Miguel Garcia and Phillip Hallam-Baker reviewed the document and
provided helpful suggestions. provided helpful suggestions.
In addition, the following individuals made significant In addition, the following individuals made significant
contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love
Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia. Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.
Greg Hudson and Robert Sparks had provided helpful text in the bis
version of the draft.
10. IANA Considerations 10. IANA Considerations
This document defines a new 'anonymous' Kerberos well-known name and This document defines an 'anonymous' Kerberos well-known name and an
a new 'anonymous' Kerberos well-known realm based on [RFC6111]. IANA 'anonymous' Kerberos well-known realm based on [RFC6111]. IANA has
has added these two values to the Kerberos naming registries that are added these two values to the Kerberos naming registries that are
created in [RFC6111]. created in [RFC6111].
Note to IANA: Please update the following Kerberos Parameters
registries:
o Well-Known Kerberos Principal Names
o Well-Known Kerberos Realm Names
o Pre-authentication and Typed Data
to reference this document instead of RFC6112.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ASAX34] American Standards Institute, "American Standard Code for [ASAX34] American Standards Institute, "American Standard Code for
Information Interchange", ASA X3.4-1963, June 1963. Information Interchange", ASA X3.4-1963, June 1963.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, DOI 10.17487/RFC1964, June 1996, RFC 1964, DOI 10.17487/RFC1964, June 1996,
<http://www.rfc-editor.org/info/rfc1964>. <http://www.rfc-editor.org/info/rfc1964>.
skipping to change at page 16, line 22 skipping to change at page 16, line 47
DOI 10.17487/RFC4556, June 2006, DOI 10.17487/RFC4556, June 2006,
<http://www.rfc-editor.org/info/rfc4556>. <http://www.rfc-editor.org/info/rfc4556>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <http://www.rfc-editor.org/info/rfc5652>.
[RFC6111] Zhu, L., "Additional Kerberos Naming Constraints", [RFC6111] Zhu, L., "Additional Kerberos Naming Constraints",
RFC 6111, April 2011. RFC 6111, April 2011.
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
Kerberos", RFC 6112, April 2011.
[X.680] "Abstract Syntax Notation One (ASN.1): Specification of [X.680] "Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation", ITU-T Recommendation X.680: ISO/IEC Basic Notation", ITU-T Recommendation X.680: ISO/IEC
International Standard 8824-1:1998, 1997. International Standard 8824-1:1998, 1997.
[X.690] "ASN.1 encoding rules: Specification of Basic Encoding [X.690] "ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690 ISO/IEC International Standard 8825-1:1998, 1997. X.690 ISO/IEC International Standard 8825-1:1998, 1997.
11.2. Informative References 11.2. Informative References
skipping to change at page 17, line 4 skipping to change at page 17, line 31
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: larry.zhu@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
Sam Hartman (editor) Sam Hartman
Painless Security Painless Security
EMail: hartmans-ietf@mit.edu EMail: hartmans-ietf@mit.edu
Shawn Emery (editor) Shawn Emery (editor)
Oracle Oracle
EMail: shawn.emery@oracle.com EMail: shawn.emery@oracle.com
 End of changes. 20 change blocks. 
40 lines changed or deleted 63 lines changed or added

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