< draft-ietf-kitten-rfc6112bis-00.txt   draft-ietf-kitten-rfc6112bis-01.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, Ed.
Intended status: Standards Track Painless Security Intended status: Standards Track Painless Security
Expires: September 4, 2014 March 3, 2014 Expires: January 27, 2017 S. Emery, Ed.
Oracle
July 26, 2016
Anonymity Support for Kerberos Anonymity Support for Kerberos
draft-ietf-kitten-rfc6112bis-00 draft-ietf-kitten-rfc6112bis-01
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 43 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 September 4, 2014. This Internet-Draft will expire on January 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
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 2, line 35
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 . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . 12 7.1. Combining Two Protocol Keys . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 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 37 skipping to change at page 3, line 38
Initial Authentication in Kerberos (PKINIT) as defined in Initial Authentication in Kerberos (PKINIT) as defined in
Section 4.1. Using the returned anonymous ticket, the client remains Section 4.1. Using the returned anonymous ticket, the client remains
anonymous in subsequent Kerberos exchanges thereafter to KDCs on the anonymous in subsequent Kerberos exchanges thereafter to KDCs on the
cross-realm authentication path and to the server with which it cross-realm authentication path and to the server with which it
communicates. communicates.
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
the membership of 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 RFC 6112 to correct technical errors in
that specification. RFC 6112 is classified is historic; that specification. RFC 6112 is classified is 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, pepper string 2 is corrected to comply with the string In Section 7, the pepper2 string is corrected to comply with the
actually used by implementations. 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.
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].
skipping to change at page 4, line 29 skipping to change at page 4, line 34
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", "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.
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.
o The crealm field contains the client's realm name or the anonymous o The crealm field contains the client's realm name or the anonymous
realm name. realm name.
o The anonymous ticket contains no information that can reveal the o The anonymous ticket contains no information that can reveal the
client's identity. However, the ticket may contain the client client's identity. However, the ticket may contain the client
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 as being in a particular group of users can be
implemented using authorization data and such authorization data, implemented using authorization data. Such authorization data, if
if included in the anonymous ticket, would disclose the client's included in the anonymous ticket, would disclose the that the
membership of that group. client is a member of the group observed.
o The anonymous ticket flag is set. o The anonymous ticket flag is set.
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.
skipping to change at page 5, line 38 skipping to change at page 5, line 43
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 authenticate to the KDC and requests an anonymous ticket in an AS to 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. According to [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 Care MUST be taken by the KDC not to reveal the client's identity in
the authorization data of the returned ticket when populating the the authorization data of the returned ticket when populating the
authorization data in a returned anonymous ticket. authorization data in 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.
The client can use the client keys 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
skipping to change at page 7, line 48 skipping to change at page 8, line 4
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 AS-
REP, PA_PKINIT_KX proves that the KDC and client both contributed to REP, PA_PKINIT_KX proves that the KDC and client both contributed to
the session key for any use of Diffie-Hellman key agreement with 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. Anonymity 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, or 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 optionSHOULD 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
skipping to change at page 9, line 21 skipping to change at page 9, line 24
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
no policy defined for a given unknown authorization data type, the no policy defined for a given unknown authorization data type, the
authentication MUST be rejected. The error code is KDC_ERR_POLICY authentication MUST be rejected. The error code is KDC_ERR_POLICY
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
skipping to change at page 11, line 34 skipping to change at page 11, line 37
the initiators identity to the acceptor, something that can rarely be the initiators identity to the acceptor, something that can rarely be
"un-done". "un-done".
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 tunneling anonymous PKINIT (defined in this document) in building secure
channels [RFC6113] and subsequent channel bindings. In order to channels [RFC6113] and subsequent channel bindings [RFC5056]. In
enable applications of anonymous PKINIT to form channels, all order to enable applications of anonymous PKINIT to form secure
implementations of anonymous PKINIT need to meet the requirements of channels, all implementations of anonymous PKINIT need to meet the
this section. There is otherwise no connection to the rest of this requirements of this section. There is otherwise no connection to
document. the rest of this document.
PKINIT is useful for constructing tunneling channels. To ensure that PKINIT is useful for constructing secure channels. To ensure that an
an attacker cannot create a channel with a given name, it is attacker cannot create a channel by observing exchanges, it is
desirable that neither the KDC nor the client unilaterally determine desirable that neither the KDC nor the client unilaterally determine
the ticket session key. To achieve that end, a KDC conforming to the ticket session key. The specific reason why the ticket session
this definition MUST encrypt a randomly generated key, called the KDC key is derived jointly is discussed at the end of this section. To
contribution key, in the PA_PKINIT_KX padata (defined next in this achieve that end, a KDC conforming to this definition MUST encrypt a
section). The KDC contribution key is then combined with the reply randomly generated key, called the KDC contribution key, in the
key to form the ticket session key of the returned ticket. These two PA_PKINIT_KX padata (defined next in this section). The KDC
keys are then combined using the KRB-FX-CF2 operation defined in contribution key is then combined with the reply key to form the
Section 7.1, where K1 is the KDC contribution key, K2 is the reply ticket session key of the returned ticket. These two keys are then
key, the input pepper1 is American Standard Code for Information combined using the KRB-FX-CF2 operation defined in Section 7.1, where
Interchange (ASCII) [ASAX34] string "PKINIT", and the input pepper2 K1 is the KDC contribution key, K2 is the reply key, the input
is ASCII string "KEYEXCHANGE". pepper1 is American Standard Code for Information Interchange (ASCII)
[ASAX34] string "PKINIT", and the input pepper2 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 39 skipping to change at page 12, line 43
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
the KDC reply. the KDC reply.
This protocol provides a binding between the party which generated
the session key and the DH exchange used to generate they reply key.
Hypothetically, if the KDC did not use PA-PKINIT-KX, the client and
KDC would perfrom a DH key exchange to determine a shared key, and
that key would be used as a reply key. The KDC would then generate a
ticket with a session key encrypting the reply with the DH agreement.
A MITM attacker would just decrypt the session key + ticket using the
DH key from the attacker and KDC DH exchange, and re-encrypt it using
the key from the attacker and client DH exchange, while keeping a
copy of the session key and ticket. By requiring the session key in
a way that can be verified by the client, this protocol binds the
ticket to the DH exchange and prevents the MITM attack.
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:
KRB-FX-CF2(protocol key, protocol key, octet string, KRB-FX-CF2(protocol key, protocol key, octet string,
skipping to change at page 15, line 19 skipping to change at page 15, line 36
has added these two values to the Kerberos naming registries that are has added these two values to the Kerberos naming registries that are
created in [RFC6111]. created in [RFC6111].
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", RFC [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
1964, June 1996. RFC 1964, DOI 10.17487/RFC1964, June 1996,
<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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743,
DOI 10.17487/RFC2743, January 2000,
<http://www.rfc-editor.org/info/rfc2743>.
[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, DOI 10.17487/RFC3961, February
2005, <http://www.rfc-editor.org/info/rfc3961>.
[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. DOI 10.17487/RFC4120, July 2005,
<http://www.rfc-editor.org/info/rfc4120>.
[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,
DOI 10.17487/RFC4556, June 2006,
<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, September 2009. RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[RFC6111] Zhu, L., "Additional Kerberos Naming Constraints", RFC [RFC6111] Zhu, L., "Additional Kerberos Naming Constraints",
6111, April 2011. RFC 6111, 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
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[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, April 2011.
[STARTTLS] [STARTTLS]
Josefsson, S., "Using Kerberos V5 over the Transport Layer Josefsson, S., "Using Kerberos V5 over the Transport Layer
Security (TLS) protocol", Work in Progress, August 2010. Security (TLS) protocol", Work in Progress, August 2010.
Authors' Addresses Authors' Addresses
Larry Zhu Larry Zhu
skipping to change at page 16, line 23 skipping to change at page 17, line 4
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 (editor)
Painless Security Painless Security
EMail: hartmans-ietf@mit.edu EMail: hartmans-ietf@mit.edu
Shawn Emery (editor)
Oracle
EMail: shawn.emery@oracle.com
 End of changes. 39 change blocks. 
60 lines changed or deleted 90 lines changed or added

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