draft-ietf-kitten-rfc6112bis-03.txt   rfc8062.txt 
Network Working Group L. Zhu Internet Engineering Task Force (IETF) L. Zhu
Internet-Draft P. Leach Request for Comments: 8062 P. Leach
Obsoletes: 6112 (if approved) Microsoft Corporation Obsoletes: 6112 Microsoft Corporation
Updates: 4120, 4121, 4556 (if approved) S. Hartman Updates: 4120, 4121, 4556 S. Hartman
Intended status: Standards Track Painless Security Category: Standards Track Hadron Industries
Expires: May 20, 2017 S. Emery, Ed. ISSN: 2070-1721 S. Emery, Ed.
Oracle Oracle
November 16, 2016 February 2017
Anonymity Support for Kerberos Anonymity Support for Kerberos
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
RFC 6112 and reclassifies that document as historic. RFC 6112 RFC 6112 and reclassifies that document as Historic. RFC 6112
contained errors and the protocol described in that specification is contained errors, and the protocol described in that specification is
not interoperable with any known implementation. This specification not interoperable with any known implementation. This specification
describes a protocol that interoperates with multiple describes a protocol that interoperates with multiple
implementations. implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on May 20, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8062.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 35 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . 6
4.1. Anonymity Support in AS Exchange . . . . . . . . . . . . 5 4.1. Anonymity Support in AS Exchange . . . . . . . . . . . . 6
4.1.1. Anonymous PKINIT . . . . . . . . . . . . . . . . . . 6 4.1.1. Anonymous PKINIT . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . 10 and TGS for Anonymity Support . . . . . . . . . . . . . . 10
5. Interoperability Requirements . . . . . . . . . . . . . . . . 10 5. Interoperability Requirements . . . . . . . . . . . . . . . . 11
6. GSS-API Implementation Notes . . . . . . . . . . . . . . . . 10 6. GSS-API Implementation Notes . . . . . . . . . . . . . . . . 11
7. PKINIT Client Contribution to the Ticket Session Key . . . 11 7. PKINIT Client Contribution to the Ticket Session Key . . . . 12
7.1. Combining Two Protocol Keys . . . . . . . . . . . . . . . 13 7.1. Combining Two Protocol Keys . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 45 skipping to change at page 4, line 19
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 [RFC6112] to correct technical errors in This specification replaces [RFC6112] to correct technical errors in
that specification. RFC 6112 is classified as historic; that specification. RFC 6112 is classified as Historic;
implementation of RFC 6112 is NOT RECOMMENDED: existing implementation of RFC 6112 is NOT RECOMMENDED. All known
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, "KeyExchange", is corrected to In Section 7, the pepper2 string "KeyExchange" used in RFC 6112 is
comply with the string actually used by implementations. corrected to appear in all capital letters to 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 Ticket-Granting Service (TGS) request is reduced
At least one implementation does not require this and is not from a MUST to a SHOULD. At least one implementation does not
necessary that both be used as an indicator of request type. require this; it is not necessary that both the anonymous option and
anonymous ticket be used as an indicator of request type.
Corrected the authorization data type name, AD-INITIAL-VERIFIED-CAS, The authorization data type name "AD-INITIAL-VERIFIED-CAS" used in
referenced in this document. RFC 6112 is corrected to appear as "AD_INITIAL_VERIFIED_CAS" 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
name based on [RFC6111], and the value of this well-known realm name name based on [RFC6111], 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 [RFC6111]. The value of the name- Kerberos principal name based on [RFC6111]. The value of the name-
type field is KRB_NT_WELLKNOWN [RFC6111], and the value of the name- type field is KRB_NT_WELLKNOWN [RFC6111], 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" and "ANONYMOUS".
The anonymous ticket flag is defined as bit 16 (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(16) -- 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 that a ticket is This is a new ticket flag that is used to indicate that a ticket is
an anonymous one. an anonymous one.
skipping to change at page 5, line 29 skipping to change at page 5, line 50
The anonymous KDC option is defined as bit 16 (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(16) -- 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 a an anonymous ticket in an Authentication Service (AS) request or a
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 a TGS request. anonymous KDC option in an AS request or a TGS request.
The rest of this section is organized as follows: it first describes The rest of this section is organized as follows: it first describes
protocol actions specific to AS exchanges, then it describes those of protocol actions specific to AS exchanges, then it describes those of
TGS exchanges. These are then followed by the description of TGS exchanges. These are then followed by the description of
protocol actions common to both AS and TGS and those in subsequent protocol actions common to both AS and TGS and those in subsequent
exchanges. exchanges.
4.1. Anonymity Support in AS Exchange 4.1. Anonymity Support in AS Exchange
The client requests an anonymous ticket by setting the anonymous KDC The client requests an anonymous ticket by setting the anonymous KDC
option in an AS exchange. option in an AS exchange.
The Kerberos client can use the client's long-term keys, the client's The Kerberos client can use the client's long-term keys, the client's
X.509 certificates [RFC4556], or any other pre-authentication data, X.509 certificates [RFC4556], or any other pre-authentication data to
to authenticate to the KDC and request an anonymous ticket in an AS authenticate to the KDC and request an anonymous ticket in an AS
exchange where the client's identity is known to the KDC. exchange where the client's identity is known to the KDC.
If the client in the AS request is anonymous, the anonymous KDC If the client in the AS request is anonymous, the anonymous KDC
option MUST be set in the request. Otherwise, the KDC MUST return a option MUST be set in the request. Otherwise, the KDC MUST return a
KRB-ERROR message with the code KDC_ERR_BADOPTION. KRB-ERROR message with the code KDC_ERR_BADOPTION.
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]. the code KDC_ERR_NULL_KEY [RFC4120].
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.
The KDC MUST NOT reveal the client's identity in the authorization The KDC MUST NOT reveal the client's identity in the authorization
data of the returned ticket when populating the authorization data in data of the returned ticket when populating the authorization data in
a returned anonymous ticket. a returned anonymous ticket.
skipping to change at page 6, line 40 skipping to change at page 7, line 10
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.
The client can use the client's key to mutually authenticate with the The client can use the client's key to mutually authenticate with the
KDC and request an anonymous Ticket Granting Ticket (TGT) in the AS KDC and request an anonymous Ticket-Granting Ticket (TGT) in the AS
request. In that case, the reply key is selected as normal, request. In that case, the reply key is selected as normal,
according to Section 3.1.3 of [RFC4120]. according to Section 3.1.3 of [RFC4120].
4.1.1. Anonymous PKINIT 4.1.1. Anonymous PKINIT
This sub-section defines anonymous PKINIT. This sub-section defines anonymous PKINIT.
As described earlier in this section, the client can request an As described earlier in this section, the client can request an
anonymous ticket by authenticating to the KDC using the client's anonymous ticket by authenticating to the KDC using the client's
identity; alternatively, without revealing the client's identity to identity; alternatively, without revealing the client's identity to
the KDC, the Kerberos client can request an anonymous ticket as the KDC, the Kerberos client can request an anonymous ticket as
follows: the client sets the client name as the anonymous principal follows: the client sets the client name as the anonymous principal
in the AS exchange and provides PA_PK_AS_REQ pre-authentication data in the AS exchange and provides PA_PK_AS_REQ pre-authentication data
[RFC4556] where the signerInfos field of the SignedData [RFC5652] of [RFC4556] where the signerInfos field of the SignedData [RFC5652] of
the PA_PK_AS_REQ is empty, and the certificates field is absent. the PA_PK_AS_REQ is empty, and the certificates field is absent.
Because the anonymous client does not have an associated asymmetric Because the anonymous client does not have an associated asymmetric
key pair, the client MUST choose the Diffie-Hellman key agreement key pair, the client MUST choose the Diffie-Hellman key agreement
method by filling in the Diffie-Hellman domain parameters in the method by filling in the Diffie-Hellman domain parameters in the
clientPublicValue [RFC4556]. This use of the anonymous client name clientPublicValue [RFC4556]. This use of the anonymous client name
in conjunction with PKINIT is referred to as anonymous PKINIT. If in conjunction with PKINIT is referred to as "anonymous PKINIT". If
anonymous PKINIT is used, the realm name in the returned anonymous anonymous PKINIT is used, the realm name in the returned anonymous
ticket MUST be the anonymous realm. ticket MUST be the anonymous realm.
Upon receiving the anonymous PKINIT request from the client, the KDC Upon receiving the anonymous PKINIT request from the client, the KDC
processes the request, according to Section 3.1.2 of [RFC4120]. The processes the request, according to Section 3.1.2 of [RFC4120]. The
KDC skips the checks for the client's signature and the client's KDC skips the checks for the client's signature and the client's
public key (such as the verification of the binding between the public key (such as the verification of the binding between the
client's public key and the client name), but performs otherwise client's public key and the client name) but performs otherwise
applicable checks, and proceeds as normal, according to [RFC4556]. applicable checks and proceeds as normal, according to [RFC4556].
For example, the AS MUST check if the client's Diffie-Hellman domain For example, the AS MUST check if the client's Diffie-Hellman domain
parameters are acceptable. The Diffie-Hellman key agreement method parameters are acceptable. The Diffie-Hellman key agreement method
MUST be used and the reply key is derived according to MUST be used and the reply key is derived according to
Section 3.2.3.1 of [RFC4556]. If the clientPublicValue is not Section 3.2.3.1 of [RFC4556]. If the clientPublicValue is not
present in the request, the KDC MUST return a KRB-ERROR with the code present in the request, the KDC MUST return a KRB-ERROR with the code
KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556]. If all goes KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556]. If all goes
well, an anonymous ticket is generated, according to Section 3.1.3 of well, an anonymous ticket is generated, according to Section 3.1.3 of
[RFC4120], and PA_PK_AS_REP [RFC4556] pre-authentication data is [RFC4120], and PA_PK_AS_REP [RFC4556] pre-authentication data is
included in the KDC reply, according to [RFC4556]. If the KDC does included in the KDC reply, according to [RFC4556]. If the KDC does
not have an asymmetric key pair, it MAY reply anonymously or reject not have an asymmetric key pair, it MAY reply anonymously or reject
skipping to change at page 7, line 51 skipping to change at page 8, line 22
(the reply is anonymous), the client MUST reject the returned ticket (the reply is anonymous), the client MUST reject the returned ticket
if it cannot authenticate the KDC otherwise. if it cannot authenticate the KDC otherwise.
A KDC that supports anonymous PKINIT MUST indicate the support of A KDC that supports anonymous PKINIT MUST indicate the support of
PKINIT, according to Section 3.4 of [RFC4556]. In addition, such a PKINIT, according to Section 3.4 of [RFC4556]. In addition, such a
KDC MUST indicate support for anonymous PKINIT by including a padata KDC MUST indicate support for anonymous PKINIT by including a padata
element of padata-type PA_PKINIT_KX and empty padata-value when element of padata-type PA_PKINIT_KX and empty padata-value when
including PA-PK-AS-REQ in an error reply. including PA-PK-AS-REQ in an error reply.
When included in a KDC error, PA_PKINIT_KX indicates support for When included in a KDC error, PA_PKINIT_KX indicates support for
anonymous PKINIT. As discussed in Section 7, when included in an AS- anonymous PKINIT. As discussed in Section 7, when included in an
REP, PA_PKINIT_KX proves that the KDC and client both contributed to AS-REP, PA_PKINIT_KX proves that the KDC and client both contributed
the session key for any use of Diffie-Hellman key agreement with to the session key for any use of Diffie-Hellman key agreement with
PKINIT. PKINIT.
Note that in order to obtain an anonymous ticket with the anonymous Note that in order to obtain an anonymous ticket with the anonymous
realm name, the client MUST set the client name as the anonymous realm name, the client MUST set the client name as the anonymous
principal in the request when requesting an anonymous ticket in an AS principal in the request when requesting an anonymous ticket in an AS
exchange. Anonymous PKINIT is the only way via which an anonymous exchange. Anonymous PKINIT is the only way via which an anonymous
ticket with the anonymous realm as the client realm can be generated ticket with the anonymous realm as the client realm can be generated
in this specification. in this specification.
4.2. Anonymity Support in TGS Exchange 4.2. Anonymity Support in TGS Exchange
The client requests an anonymous ticket by setting the anonymous KDC The client requests an anonymous ticket by setting the anonymous KDC
option in a TGS exchange, and in that request the client can use a option in a TGS exchange, and in that request, the client can use a
normal Ticket Granting Ticket (TGT) with the client's identity, or an normal Ticket-Granting Ticket (TGT) with the client's identity, an
anonymous TGT, or an anonymous cross-realm TGT. If the client uses a anonymous TGT, or an anonymous cross-realm TGT. If the client uses a
normal TGT, the client's identity is known to the TGS. normal TGT, the client's identity is known to the TGS.
Note that the client can completely hide the client's identity in an Note that the client can completely hide the client's identity in an
AS exchange using anonymous PKINIT, as described in the previous AS exchange using anonymous PKINIT, as described in the previous
section. section.
If the ticket in the PA-TGS-REQ of the TGS request is an anonymous If the ticket in the PA-TGS-REQ of the TGS request is an anonymous
one, the anonymous KDC option SHOULD be set in the request. one, the anonymous KDC option SHOULD be set in the request.
When policy allows, the KDC issues an anonymous ticket. If the When policy allows, the KDC issues an anonymous ticket. If the
ticket in the TGS request is an anonymous one, the client name and ticket in the TGS request is an anonymous one, the client name and
the client realm are copied from that ticket; otherwise, the ticket the client realm are copied from that ticket; otherwise, the ticket
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.
The TGS MUST NOT reveal the client's identity in the authorization The TGS MUST NOT reveal the client's identity in the authorization
data of the returned ticket. When propagating authorization data in data of the returned ticket. When propagating authorization data in
the ticket or in the enc-authorization-data field of the request, the the ticket or in the enc-authorization-data field of the request, the
TGS MUST ensure that the client confidentiality is not violated in TGS MUST ensure that the client confidentiality is not violated in
skipping to change at page 9, line 15 skipping to change at page 9, line 38
specification of a new authorization data type MUST specify the specification of a new authorization data type MUST specify the
processing rules of the authorization data when an anonymous ticket processing rules of the authorization data when an anonymous ticket
is returned. If there is no processing rule defined for an is returned. If there is no processing rule defined for an
authorization data element or the authorization data element is authorization data element or the authorization data element is
unknown, the TGS MUST process it when an anonymous ticket is returned unknown, the TGS MUST process it when an anonymous ticket is 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
applicable to both critical and optional authorization data. applicable to both critical and optional authorization data.
o If the authorization data element is unknown, the TGS MAY remove o If the authorization data element is unknown, the TGS MAY remove
it, or transfer it into the returned anonymous ticket, or reject it, or transfer it into the returned anonymous ticket, or reject
the authentication attempt, based on local policy for that the authentication attempt, based on local policy for that
authorization data type unless otherwise specified. If there is authorization data type unless otherwise specified. If there is
skipping to change at page 9, line 39 skipping to change at page 10, line 13
when the authentication is rejected. when the authentication is rejected.
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. If it [RFC4556], contains the issuer name of the client certificate. 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 an anonymous ticket. removed from an anonymous ticket.
The TGS encodes the name of the previous realm into the transited The TGS encodes the name of the previous realm into the transited
field, according to Section 3.3.3.2 of [RFC4120]. Based on local field, according to Section 3.3.3.2 of [RFC4120]. Based on local
policy, the TGS MAY omit the previous realm, if the cross realm TGT policy, the TGS MAY omit the previous realm, if the cross-realm TGT
is an anonymous one, in order to hide the authentication path of the is an anonymous one, in order to hide the authentication path of the
client. The unordered set of realms in the transited field, if client. The unordered set of realms in the transited field, if
present, can reveal which realm may potentially be the realm of the present, can reveal which realm may potentially be the realm of the
client or the realm that issued the anonymous TGT. The anonymous client or the realm that issued the anonymous TGT. The anonymous
Kerberos realm name MUST NOT be present in the transited field of a Kerberos realm name MUST NOT be present in the transited field of a
ticket. The true name of the realm that issued the anonymous ticket ticket. The true name of the realm that issued the anonymous ticket
MAY be present in the transited field of a ticket. MAY be present in the transited field of a ticket.
4.3. Subsequent Exchanges and Protocol Actions Common to AS and TGS for 4.3. Subsequent Exchanges and Protocol Actions Common to AS and TGS for
Anonymity Support Anonymity Support
skipping to change at page 10, line 21 skipping to change at page 10, line 38
Absent other information, the KDC MUST NOT include any identifier in Absent other information, the KDC MUST NOT include any identifier in
the returned anonymous ticket that could reveal the client's identity the returned anonymous ticket that could reveal the client's identity
to the server. to the server.
Unless anonymous PKINIT is used, if a client requires anonymous Unless anonymous PKINIT is used, if a client requires anonymous
communication, then the client MUST check to make sure that the communication, then the client MUST check to make sure that the
ticket in the reply is actually anonymous by checking the presence of ticket in the reply is actually anonymous by checking the presence of
the anonymous ticket flag in the flags field of the EncKDCRepPart. the anonymous ticket flag in the flags field of the EncKDCRepPart.
This is because KDCs ignore unknown KDC options. A KDC that does not This is because KDCs ignore unknown KDC options. A KDC that does not
understand the anonymous KDC option will not return an error, but understand the anonymous KDC option will not return an error but will
will instead return a normal ticket. 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].
Note that the anonymous principal name and realm are only applicable Note that the anonymous principal name and realm are only applicable
to the client in Kerberos messages, the server cannot be anonymous in to the client in Kerberos messages, and the server cannot be
any Kerberos message per this specification. anonymous in any Kerberos message per this specification.
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.
Upon receipt of an anonymous ticket, the transited policy check is Upon receipt of an anonymous ticket, the transited policy check is
performed in the same way as that of a normal ticket if the client's performed in the same way as that of a normal ticket if the client's
realm is not the anonymous realm; if the client realm is the realm is not the anonymous realm; if the client realm is the
anonymous realm, absent other information any realm in the anonymous realm, absent other information, any realm in the
authentication path is allowed by the cross-realm policy check. authentication path is allowed by the cross-realm policy check.
5. Interoperability Requirements 5. Interoperability Requirements
Conforming implementations MUST support the anonymous principal with Conforming implementations MUST support the anonymous principal with
a non-anonymous realm, and they MAY support the anonymous principal a non-anonymous realm, and they MAY support the anonymous principal
with the anonymous realm using anonymous PKINIT. with the anonymous realm using anonymous PKINIT.
6. GSS-API Implementation Notes 6. GSS-API Implementation Notes
GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
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
API anonymous principal. A principal with the anonymous principal GSS-API anonymous principal. A principal with the anonymous
name and a non-anonymous realm is an authenticated principal; hence, principal name and a non-anonymous realm is an authenticated
such a principal does not correspond to the anonymous principal in principal; hence, such a principal does not correspond to the
GSS-API with the GSS_C_NT_ANONYMOUS name type. The [RFC1964] name anonymous principal in GSS-API with the GSS_C_NT_ANONYMOUS name type.
syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the The [RFC1964] name syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used
anonymous principal name with a non-anonymous realm name and for for importing the anonymous principal name with a non-anonymous realm
displaying and exporting these names. In addition, this syntax must name and for displaying and exporting these names. In addition, this
be used along with the name type GSS_C_NT_ANONYMOUS for displaying syntax must be used along with the name type GSS_C_NT_ANONYMOUS for
and exporting the anonymous principal with the anonymous realm. 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 36 skipping to change at page 12, line 11
for the acceptor/server when performing an authorization decision for the acceptor/server when performing an authorization decision
based on the initiator name that is returned from the acceptor side based on the initiator name that is returned from the acceptor side
upon the successful security context establishment. upon the successful security context establishment.
A GSS-API initiator MUST carefully check the resulting context A GSS-API initiator MUST carefully check the resulting context
attributes from the initial call to GSS_Init_Sec_Context() when attributes from the initial call to GSS_Init_Sec_Context() when
requesting anonymity, because (as in the GSS-API tradition and for requesting anonymity, because (as in the GSS-API tradition and for
backwards compatibility) anonymity is just another optional context backwards compatibility) anonymity is just another optional context
attribute. It could be that the mechanism doesn't recognize the attribute. It could be that the mechanism doesn't recognize the
attribute at all or that anonymity is not available for some other attribute at all or that anonymity is not available for some other
reasons -- and in that case the initiator MUST NOT send the initial reasons -- and in that case, the initiator MUST NOT send the initial
security context token to the acceptor, because it will likely reveal security context token to the acceptor, because it will likely reveal
the initiators identity to the acceptor, something that can rarely be the initiator's identity to the acceptor, something that can rarely
"un-done". be "undone".
Portable initiators are RECOMMENDED to use default credentials Portable initiators are RECOMMENDED to use default credentials
whenever possible, and request anonymity only through the input whenever possible and request anonymity only through the input
anon_req_flag [RFC2743] to GSS_Init_Sec_Context(). anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
7. PKINIT Client Contribution to the Ticket Session Key 7. PKINIT Client Contribution to the Ticket Session Key
The definition in this section was motivated by protocol analysis of The definition in this section was motivated by protocol analysis of
anonymous PKINIT (defined in this document) in building secure anonymous PKINIT (defined in this document) in building secure
channels [RFC6113] and subsequent channel bindings [RFC5056]. In channels [RFC6113] and subsequent channel bindings [RFC5056]. In
order to enable applications of anonymous PKINIT to form secure order to enable applications of anonymous PKINIT to form secure
channels, all implementations of anonymous PKINIT need to meet the channels, all implementations of anonymous PKINIT need to meet the
requirements of this section. There is otherwise no connection to requirements of this section. There is otherwise no connection to
the rest of this document. the rest of this document.
PKINIT is useful for constructing secure channels. To ensure that an PKINIT is useful for constructing secure channels. To ensure that an
active attacker cannot create separate channels to the client and KDC active attacker cannot create separate channels to the client and KDC
with the same known key, it is desirable that neither the KDC nor the with the same known key, it is desirable that neither the KDC nor the
client unilaterally determine the ticket session key. The specific client unilaterally determine the ticket session key. The specific
reason why the ticket session key is derived jointly is discussed at reason why the ticket session key is derived jointly is discussed at
the end of this section. To achieve that end, a KDC conforming to the end of this section. To achieve that end, a KDC conforming to
this definition MUST encrypt a randomly generated key, called the KDC this definition MUST encrypt a randomly generated key, called the
contribution key, in the PA_PKINIT_KX padata (defined next in this "KDC contribution key", in the PA_PKINIT_KX padata (defined next in
section). The KDC contribution key is then combined with the reply this section). The KDC contribution key is then combined with the
key to form the ticket session key of the returned ticket. These two reply key to form the ticket session key of the returned ticket.
keys are then combined using the KRB-FX-CF2 operation defined in These two keys are combined using the KRB-FX-CF2 operation defined in
Section 7.1, where K1 is the KDC contribution key, K2 is the reply Section 7.1, where K1 is the KDC contribution key, K2 is the reply
key, the input pepper1 is American Standard Code for Information key, the input pepper1 is US-ASCII [ANSI.X3-4] string "PKINIT", and
Interchange (ASCII) [ASAX34] string "PKINIT", and the input pepper2 the input pepper2 is US-ASCII string "KEYEXCHANGE".
is ASCII string "KEYEXCHANGE".
PA_PKINIT_KX 147 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]
skipping to change at page 12, line 43 skipping to change at page 13, line 16
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-Hellman key exchange but the client is not anonymous; with the Diffie-Hellman key exchange but the client is not anonymous;
it MUST NOT be included otherwise (e.g., when PKINIT is used with the it MUST NOT be included otherwise (e.g., when PKINIT is 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 [X.680] [X.690] encoding of the Abstract Syntax Notation One DER [X.680] [X.690] encoding of the Abstract Syntax Notation One
(ASN.1) type PA-PKINIT-KX. The PA-PKINIT-KX structure is an (ASN.1) type PA-PKINIT-KX. The PA-PKINIT-KX structure is an
EncryptedData. The cleartext data being encrypted is the DER-encoded EncryptedData. The cleartext data being encrypted is the DER-encoded
KDC contribution key randomly generated by the KDC. The encryption KDC contribution key randomly generated by the KDC. The encryption
key is the reply key and the key usage number is 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 that
ticket session key in the returned ticket is the combined key of the the ticket session key in the returned ticket is the combined key of
KDC contribution key and the reply key as described above. A the 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
the KDC reply. the KDC reply.
This protocol provides a binding between the party which generated This protocol provides a binding between the party that generated the
the session key and the DH exchange used to generate the reply key. session key and the Diffie-Hellman exchange used to generate the
Hypothetically, if the KDC did not use PA-PKINIT-KX, the client and reply key. Hypothetically, if the KDC did not use PA-PKINIT-KX, the
KDC would perform a DH key exchange to determine a shared key, and client and KDC would perform a Diffie-Hellman key exchange to
that key would be used as a reply key. The KDC would then generate a determine a shared key, and that key would be used as a reply key.
ticket with a session key encrypting the reply with the DH agreement. The KDC would then generate a ticket with a session key encrypting
A MITM attacker would just decrypt the session key and ticket using the reply with the Diffie-Helman agreement. A man-in-the-middle
the DH key from the attacker-KDC DH exchange, and re-encrypt it using (MITM) attacker would just decrypt the session key and ticket using
the key from the attacker-client DH exchange, while keeping a copy of the Diffie-Hellman key from the attacker-KDC Diffie-Hellman exchange
the session key and ticket. This protocol binds the ticket to the DH and re-encrypt it using the key from the attacker-client Diffie-
exchange and prevents the MITM attack by requiring the session key to Hellman exchange, while keeping a copy of the session key and ticket.
be created in a way that can be verified by the client. This protocol binds the ticket to the Diffie-Hellman exchange and
prevents the MITM attack by requiring the session key to be created
in a way that can be verified by the client.
7.1. Combining Two Protocol Keys 7.1. Combining Two Protocol Keys
KRB-FX-CF2() combines two protocol keys based on the pseudo-random() KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
function defined in [RFC3961]. function defined in [RFC3961].
Given two input keys, K1 and K2, where K1 and K2 can be of two Given two input keys, K1 and K2, where K1 and K2 can be of two
different enctypes, the output key of KRB-FX-CF2(), K3, is derived as different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
follows: follows:
skipping to change at page 14, line 13 skipping to change at page 14, line 46
removed from the tail. removed from the tail.
8. Security Considerations 8. Security Considerations
Since KDCs ignore unknown options, a client requiring anonymous Since KDCs ignore unknown options, a client requiring anonymous
communication needs to make sure that the returned ticket is actually communication needs to make sure that the returned ticket is actually
anonymous. This is because a KDC that does not understand the anonymous. This is because a KDC that does not understand the
anonymous option would not return an anonymous ticket. 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 the client's identity to the server but the client not reveal the client's identity to the server, but the client's
identity may be revealed to the KDC of the server principal (when the identity may be revealed to the KDC of the server principal (when the
server principal is in a different realm than that of the client), server principal is in a different realm than that of the client) and
and any KDC on the cross-realm authentication path. The Kerberos any KDC on the cross-realm authentication path. The Kerberos client
client MUST verify the ticket being used is indeed anonymous before MUST verify the ticket being used is indeed anonymous before
communicating with the server, otherwise, the client's identity may communicating with the server, otherwise, the client's identity may
be revealed unintentionally. be revealed unintentionally.
In cases where specific server principals must not have access to the In cases where specific server principals must not have access to the
client's identity (for example, an anonymous poll service), the KDC client's identity (for example, an anonymous poll service), the KDC
can define server-principal-specific policy that ensures any normal can define the server-principal-specific policy that ensures any
service ticket can NEVER be issued to any of these server principals. normal service ticket can NEVER be issued to any of these server
principals.
If the KDC that issued an anonymous ticket were to maintain records If the KDC that issued an anonymous ticket were to maintain records
of the association of identities to an anonymous ticket, then someone of the association of identities to an anonymous ticket, then someone
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) KDCs respond to requests at the
the time that they are received. Traffic analysis on the connection time that they are received. Traffic analysis on the connection to
to the KDC will allow an attacker to match client identities 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. A service that is observer is relatively straightforward. A service that is
authenticated by the anonymous principals may be able to infer the authenticated by the anonymous principals may be able to infer the
identity of the client by examining and linking quasi-static protocol identity of the client by examining and linking quasi-static protocol
information such as the IP address from which a request is received, information such as the IP address from which a request is received
or by linking multiple uses of the same anonymous ticket. or by linking multiple uses of the same anonymous ticket.
Two mechanisms, the FAST facility with the hide-client-names option Two mechanisms, the FAST facility with the hide-client-names option
in [RFC6113] and the Kerberos5 starttls option [STARTTLS], protect in [RFC6113] and the Kerberos5 starttls option [RFC6251], protect the
the client identity so that an attacker would never be able to client identity so that an attacker would never be able to observe
observe the client identity sent to the KDC. Transport or network the client identity sent to the KDC. Transport- or network-layer
layer security between the client and the server will help prevent security between the client and the server will help prevent tracking
tracking of a particular ticket to link a ticket to a user. In of a particular ticket to link a ticket to a user. In addition,
addition, clients can limit how often a ticket is reused to minimize clients can limit how often a ticket is reused to minimize ticket
ticket linking. 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. Acknowledgments
JK Jaganathan helped editing early revisions of this document.
Clifford Neuman contributed the core notions of this document.
Ken Raeburn reviewed the document and provided suggestions for
improvements.
Martin Rex wrote the text for GSS-API considerations.
Nicolas Williams reviewed the GSS-API considerations section and
suggested ideas for improvements.
Sam Hartman and Nicolas Williams were great champions of this work.
Miguel Garcia and Phillip Hallam-Baker reviewed the document and
provided helpful suggestions.
In addition, the following individuals made significant
contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love
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 9. IANA Considerations
This document defines an 'anonymous' Kerberos well-known name and an This document defines an 'anonymous' Kerberos well-known name and an
'anonymous' Kerberos well-known realm based on [RFC6111]. IANA has 'anonymous' Kerberos well-known realm based on [RFC6111]. IANA has
added these two values to the Kerberos naming registries that are updated these two entries in the "Well-Known Kerberos Principal
created in [RFC6111]. Names" and "Well-Known Kerberos Realm Names" registries,
respectively, to refer to this document.
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. In addition, IANA has updated the reference for PA_PKINIT_KX (147) in
the "Pre-authentication and Typed Data" registry to refer to this
document.
11. References 10. References
11.1. Normative References 10.1. Normative References
[ASAX34] American Standards Institute, "American Standard Code for [ANSI.X3-4]
Information Interchange", ASA X3.4-1963, June 1963. American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3-4, 1986.
[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>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 16, line 45 skipping to change at page 16, line 47
[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, Authentication in Kerberos (PKINIT)", RFC 4556,
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, DOI 10.17487/RFC6111, April 2011,
<http://www.rfc-editor.org/info/rfc6111>.
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for [RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
Kerberos", RFC 6112, April 2011. Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011,
<http://www.rfc-editor.org/info/rfc6112>.
[X.680] "Abstract Syntax Notation One (ASN.1): Specification of [X.680] International Telecommunications Union, "Information
Basic Notation", ITU-T Recommendation X.680: ISO/IEC technology - Abstract Syntax Notation One (ASN.1):
International Standard 8824-1:1998, 1997. Specification of Basic Notation", ITU-T Recommendation
X.680, ISO/IEC International Standard 8824-1:1998, 1997.
[X.690] "ASN.1 encoding rules: Specification of Basic Encoding [X.690] International Telecommunications Union, "Information
Rules (BER), Canonical Encoding Rules (CER) and technology - ASN.1 encoding rules: Specification of Basic
Encoding 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 10.2. Informative References
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<http://www.rfc-editor.org/info/rfc5056>.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for
Kerberos Pre-Authentication", RFC 6113, April 2011. Kerberos Pre-Authentication", RFC 6113,
DOI 10.17487/RFC6113, April 2011,
<http://www.rfc-editor.org/info/rfc6113>.
[STARTTLS] [RFC6251] Josefsson, S., "Using Kerberos Version 5 over the
Josefsson, S., "Using Kerberos V5 over the Transport Layer Transport Layer Security (TLS) Protocol", RFC 6251,
Security (TLS) protocol", Work in Progress, August 2010. DOI 10.17487/RFC6251, May 2011,
<http://www.rfc-editor.org/info/rfc6251>.
Acknowledgments
JK Jaganathan helped edit early draft revisions of RFC 6112.
Clifford Neuman contributed the core notions of this document.
Ken Raeburn reviewed the document and provided suggestions for
improvements.
Martin Rex wrote the text for the GSS-API considerations.
Nicolas Williams reviewed the GSS-API considerations section and
suggested ideas for improvements.
Sam Hartman and Nicolas Williams were great champions of this work.
Miguel Garcia and Phillip Hallam-Baker reviewed the document and
provided helpful suggestions.
In addition, the following individuals made significant
contributions: Jeffrey Altman, Tom Yu, Chaskiel M. Grundman, Love
Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.
Greg Hudson and Robert Sparks provided helpful text in this document.
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 United States of America
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 United States of America
EMail: paulle@microsoft.com Email: pauljleach@msn.com
Sam Hartman Sam Hartman
Painless Security Hadron Industries
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@gmail.com
 End of changes. 71 change blocks. 
190 lines changed or deleted 195 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/