< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/