draft-ietf-kitten-rfc6112bis-01.txt   draft-ietf-kitten-rfc6112bis-02.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: January 27, 2017 S. Emery, Ed. Expires: March 8, 2017 S. Emery, Ed.
Oracle Oracle
July 26, 2016 September 4, 2016
Anonymity Support for Kerberos Anonymity Support for Kerberos
draft-ietf-kitten-rfc6112bis-01 draft-ietf-kitten-rfc6112bis-02
Abstract Abstract
This document defines extensions to the Kerberos protocol to allow a This document defines extensions to the Kerberos protocol to allow a
Kerberos client to securely communicate with a Kerberos application Kerberos client to securely communicate with a Kerberos application
service without revealing its identity, or without revealing more service without revealing its identity, or without revealing more
than its Kerberos realm. It also defines extensions that allow a than its Kerberos realm. It also defines extensions that allow a
Kerberos client to obtain anonymous credentials without revealing its Kerberos client to obtain anonymous credentials without revealing its
identity to the Kerberos Key Distribution Center (KDC). This identity to the Kerberos Key Distribution Center (KDC). This
document updates RFCs 4120, 4121, and 4556. This document obsoletes document updates RFCs 4120, 4121, and 4556. This document obsoletes
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2017. This Internet-Draft will expire on March 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 9 skipping to change at page 5, line 9
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 as being in a particular group of users can be identifiable only as being in a particular group of users can be
implemented using authorization data. Such authorization data, if implemented using authorization data. Such authorization data, if
included in the anonymous ticket, would disclose the that the included in the anonymous ticket, would disclose that the client
client is a member of the group observed. 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]
skipping to change at page 11, line 45 skipping to change at page 11, line 45
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
attacker cannot create a channel by observing exchanges, it is active attacker cannot create separate channels to the client and KDC
desirable that neither the KDC nor the client unilaterally determine with the same known key, it is desirable that neither the KDC nor the
the ticket session key. The specific reason why the ticket session client unilaterally determine the ticket session key. The specific
key is derived jointly is discussed at the end of this section. To reason why the ticket session key is derived jointly is discussed at
achieve that end, a KDC conforming to this definition MUST encrypt a the end of this section. To achieve that end, a KDC conforming to
randomly generated key, called the KDC contribution key, in the this definition MUST encrypt a randomly generated key, called the KDC
PA_PKINIT_KX padata (defined next in this section). The KDC contribution key, in the PA_PKINIT_KX padata (defined next in this
contribution key is then combined with the reply key to form the section). The KDC contribution key is then combined with the reply
ticket session key of the returned ticket. These two keys are then key to form the ticket session key of the returned ticket. These two
combined using the KRB-FX-CF2 operation defined in Section 7.1, where keys are then combined using the KRB-FX-CF2 operation defined in
K1 is the KDC contribution key, K2 is the reply key, the input Section 7.1, where K1 is the KDC contribution key, K2 is the reply
pepper1 is American Standard Code for Information Interchange (ASCII) key, the input pepper1 is American Standard Code for Information
[ASAX34] string "PKINIT", and the input pepper2 is ASCII string Interchange (ASCII) [ASAX34] string "PKINIT", and the input pepper2
"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 44 skipping to change at page 12, line 44
The client then decrypts the KDC contribution key and verifies the The client then decrypts the KDC contribution key and verifies the
ticket session key in the returned ticket is the combined key of the ticket session key in the returned ticket is the combined key of the
KDC contribution key and the reply key as described above. A KDC contribution key and the reply key as described above. A
conforming client MUST reject anonymous PKINIT authentication if the conforming client MUST reject anonymous PKINIT authentication if the
PA_PKINIT_KX padata is not present in the KDC reply or if the ticket PA_PKINIT_KX padata is not present in the KDC reply or if the ticket
session key of the returned ticket is not the combined key of the KDC session key of the returned ticket is not the combined key of the KDC
contribution key and the reply key when PA-PKINIT-KX is present in contribution key and the reply key when PA-PKINIT-KX is present in
the KDC reply. the KDC reply.
This protocol provides a binding between the party which generated This protocol provides a binding between the party which generated
the session key and the DH exchange used to generate they reply key. the session key and the DH exchange used to generate the reply key.
Hypothetically, if the KDC did not use PA-PKINIT-KX, the client and 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 KDC would perform 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 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. ticket with a session key encrypting the reply with the DH agreement.
A MITM attacker would just decrypt the session key + ticket using the A MITM attacker would just decrypt the session key and ticket using
DH key from the attacker and KDC DH exchange, and re-encrypt it using the DH key from the attacker-KDC DH exchange, and re-encrypt it using
the key from the attacker and client DH exchange, while keeping a the key from the attacker-client DH exchange, while keeping a copy of
copy of the session key and ticket. By requiring the session key in the session key and ticket. This protocol binds the ticket to the DH
a way that can be verified by the client, this protocol binds the exchange and prevents the MITM attack by requiring the session key to
ticket to the DH exchange and prevents the MITM attack. 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:
 End of changes. 9 change blocks. 
28 lines changed or deleted 28 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/