draft-ietf-kitten-cammac-04.txt		rfc7751.txt
	Internet Engineering Task Force S. Sorce		Internet Engineering Task Force (IETF) S. Sorce
	Internet-Draft Red Hat		Request for Comments: 7751 Red Hat
	Updates: 4120 (if approved) T. Yu		Updates: 4120 T. Yu
	Intended status: Standards Track MIT		Category: Standards Track MIT
	Expires: May 4, 2016 November 1, 2015		ISSN: 2070-1721 March 2016
	Kerberos Authorization Data Container Authenticated by Multiple MACs		Kerberos Authorization Data Container Authenticated by Multiple
	draft-ietf-kitten-cammac-04		Message Authentication Codes (MACs)
	Abstract		Abstract
	This document specifies a Kerberos Authorization Data container that		This document specifies a Kerberos authorization data container that
	supersedes AD-KDC-ISSUED. It allows for multiple Message		supersedes AD-KDC-ISSUED. It allows for multiple Message
	Authentication Codes (MACs) or signatures to authenticate the		Authentication Codes (MACs) or signatures to authenticate the
	contained Authorization Data elements. The multiple MACs are needed		contained authorization data elements. The multiple MACs are needed
	to mitigate shortcomings in the existing AD-KDC-ISSUED container.		to mitigate shortcomings in the existing AD-KDC-ISSUED container.
	This document updates RFC 4120.		This document updates RFC 4120.
	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 5741.
	This Internet-Draft will expire on May 4, 2016.		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/rfc7751.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
	3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2		3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2
	4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . 6		6. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	This document specifies a new Authorization Data container for		This document specifies a new authorization data container for
	Kerberos, called the CAMMAC (Container Authenticated by Multiple		Kerberos, called the CAMMAC (Container Authenticated by Multiple
	MACs). The ASN.1 type implementing the CAMMAC concept is the AD-		MACs). The Abstract Syntax Notation One (ASN.1) type implementing
	CAMMAC, which supersedes the AD-KDC-ISSUED Authorization Data type		the CAMMAC concept is the AD-CAMMAC, which supersedes the AD-KDC-
	specified in [RFC4120]. This new container allows both the receiving		ISSUED authorization data type specified in [RFC4120]. This new
	application service and the Key Distribution Center (KDC) itself to		container allows both the receiving application service and the Key
	verify the authenticity of the contained authorization data. The AD-		Distribution Center (KDC) itself to verify the authenticity of the
	CAMMAC container can also include additional verifiers that "trusted		contained authorization data. The AD-CAMMAC container can also
	services" can use to verify the contained authorization data.		include additional verifiers that "trusted services" can use to
			verify the contained authorization data.
	2. Requirements Language		2. Requirements Language
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Motivations		3. Motivations
	The Kerberos protocol allows clients to submit arbitrary		The Kerberos protocol allows clients to submit arbitrary
	skipping to change at page 3, line 33		skipping to change at page 3, line 28
	the evidence ticket constitute a flow of authorization data from the		the evidence ticket constitute a flow of authorization data from the
	application service to the KDC. The properties of the AD-KDC-ISSUED		application service to the KDC. The properties of the AD-KDC-ISSUED
	container are insufficient for this use case because the service		container are insufficient for this use case because the service
	knows the symmetric key for the checksum in the AD-KDC-ISSUED		knows the symmetric key for the checksum in the AD-KDC-ISSUED
	container. Therefore, the KDC has no way to detect whether the		container. Therefore, the KDC has no way to detect whether the
	service has tampered with the contents of the AD-KDC-ISSUED container		service has tampered with the contents of the AD-KDC-ISSUED container
	within the evidence ticket.		within the evidence ticket.
	The new AD-CAMMAC authorization data container specified in this		The new AD-CAMMAC authorization data container specified in this
	document improves upon AD-KDC-ISSUED by including additional verifier		document improves upon AD-KDC-ISSUED by including additional verifier
	elements. The svc-verifier (service verifier) element of the AD-		elements. The svc-verifier (service verifier) element of the
	CAMMAC has the same functional and security properties as the ad-		AD-CAMMAC has the same functional and security properties as the
	checksum element of AD-KDC-ISSUED; the svc-verifier allows the		ad-checksum element of AD-KDC-ISSUED; the svc-verifier allows the
	service to verify the integrity of the AD-CAMMAC contents as it		service to verify the integrity of the AD-CAMMAC contents as it
	already could with the AD-KDC-ISSUED container. The kdc-verifier and		already could with the AD-KDC-ISSUED container. The kdc-verifier and
	other-verifiers elements are new to AD-CAMMAC and provide its		other-verifiers elements are new to AD-CAMMAC and provide its
	enhanced capabilities.		enhanced capabilities.
	The kdc-verifier element of the AD-CAMMAC container allows a KDC to		The kdc-verifier element of the AD-CAMMAC container allows a KDC to
	verify the integrity of authorization data that it previously		verify the integrity of authorization data that it previously
	inserted into a ticket, by using a key that only the KDC knows. The		inserted into a ticket by using a key that only the KDC knows. The
	KDC thus avoids recomputing all of the authorization data for the		KDC thus avoids recomputing all of the authorization data for the
	issued ticket; this recomputation might not always be possible when		issued ticket; this recomputation might not always be possible when
	that data includes ephemeral information such as the strength or type		that data includes ephemeral information such as the strength or type
	of authentication method used to obtain the original ticket.		of authentication method used to obtain the original ticket.
	The verifiers in the other-verifiers element of the AD-CAMMAC		The verifiers in the other-verifiers element of the AD-CAMMAC
	container are not required, but can be useful when a lesser-		container are not required but can be useful when a lesser-privileged
	privileged service receives a ticket from a client and needs to		service receives a ticket from a client and needs to extract the
	extract the AD-CAMMAC to demonstrate to a higher-privileged "trusted		AD-CAMMAC to demonstrate to a higher-privileged "trusted service" on
	service" on the same host that it is legitimately acting on behalf of		the same host that it is legitimately acting on behalf of that
	that client. The trusted service can use a verifier in the other-		client. The trusted service can use a verifier in the
	verifiers element to validate the contents of the AD-CAMMAC without		other-verifiers element to validate the contents of the AD-CAMMAC
	further communication with the KDC.		without further communication with the KDC.
	4. Encoding		4. Encoding
	The Kerberos protocol is defined in [RFC4120] using Abstract Syntax		The Kerberos protocol is defined in [RFC4120] using ASN.1 [X.680] and
	Notation One (ASN.1) [X.680] and using the ASN.1 Distinguished		using the ASN.1 Distinguished Encoding Rules (DER) [X.690]. For
	Encoding Rules (DER) [X.690]. For consistency, this specification		consistency, this specification also uses ASN.1 for specifying the
	also uses ASN.1 for specifying the layout of AD-CAMMAC. The ad-data		layout of AD-CAMMAC. The ad-data of the AD-CAMMAC authorization data
	of the AD-CAMMAC authorization data element is the ASN.1 DER encoding		element is the ASN.1 DER encoding of the AD-CAMMAC ASN.1 type
	of the AD-CAMMAC ASN.1 type specified below.		specified below.
	KerberosV5CAMMAC {		KerberosV5CAMMAC {
	iso(1) identified-organization(3) dod(6) internet(1)		iso(1) identified-organization(3) dod(6) internet(1)
	security(5) kerberosV5(2) modules(4) cammac(7)		security(5) kerberosV5(2) modules(4) cammac(7)
	} DEFINITIONS EXPLICIT TAGS ::= BEGIN		} DEFINITIONS EXPLICIT TAGS ::= BEGIN
	IMPORTS		IMPORTS
	AuthorizationData, PrincipalName, Checksum, UInt32, Int32		AuthorizationData, PrincipalName, Checksum, UInt32, Int32
	FROM KerberosV5Spec2 { iso(1) identified-organization(3)		FROM KerberosV5Spec2 { iso(1) identified-organization(3)
	dod(6) internet(1) security(5) kerberosV5(2)		dod(6) internet(1) security(5) kerberosV5(2)
	skipping to change at page 5, line 16		skipping to change at page 5, line 11
	A sequence of authorization data elements issued by the KDC.		A sequence of authorization data elements issued by the KDC.
	These elements are the authorization data that the verifier fields		These elements are the authorization data that the verifier fields
	authenticate.		authenticate.
	Verifier:		Verifier:
	A CHOICE type that currently contains only one alternative:		A CHOICE type that currently contains only one alternative:
	Verifier-MAC. Future extensions might add support for public-key		Verifier-MAC. Future extensions might add support for public-key
	signatures.		signatures.
	Verifier-MAC:		Verifier-MAC:
	Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the		Contains an RFC 3961 [RFC3961] checksum (MAC) computed over the
	ASN.1 DER encoding of the AuthorizationData value in the elements		ASN.1 DER encoding of the AuthorizationData value in the elements
	field of the AD-CAMMAC. The identifier, kvno, and enctype fields		field of the AD-CAMMAC. The identifier, kvno, and enctype fields
	help the recipient locate the key required for verifying the MAC.		help the recipient locate the key required for verifying the MAC.
	For the kdc-verifier and the svc-verifier, the identifier, kvno		For the kdc-verifier and the svc-verifier, the identifier, kvno,
	and enctype fields are often obvious from context and MAY be		and enctype fields are often obvious from context and MAY be
	omitted. For the kdc-verifier, the MAC is computed differently		omitted. For the kdc-verifier, the MAC is computed differently
	than for the svc-verifier and the other-verifiers, as described		than for the svc-verifier and the other-verifiers, as described
	later. The key usage number for computing the MAC (Checksum) is		later. The key usage number for computing the MAC (checksum) is
	64.		64.
	kdc-verifier:		kdc-verifier:
	A Verifier-MAC where the key is a long-term key of the local		A Verifier-MAC where the key is a long-term key of the local
	Ticket-Granting Service (TGS). The checksum type is the required		Ticket-Granting Service (TGS). The checksum type is the required
	checksum type for the enctype of the TGS key. In contrast to the		checksum type for the enctype of the TGS key. In contrast to the
	other Verifier-MAC elements, the KDC computes the MAC in the kdc-		other Verifier-MAC elements, the KDC computes the MAC in the kdc-
	verifier over the ASN.1 DER encoding of the EncTicketPart of the		verifier over the ASN.1 DER encoding of a modified version of the
	surrounding ticket, but where the AuthorizationData value in the		EncTicketPart of the surrounding ticket. To construct this
	EncTicketPart contains the AuthorizationData value contained in		modified version of the EncTicketPart, the KDC replaces the
	the AD-CAMMAC instead of the AuthorizationData value that would		AuthorizationData value that would have appeared in the
	otherwise be present in the ticket. This altered Verifier-MAC		authorization-data field of the EncTicketPart with the
	computation binds the kdc-verifier to the other contents of the		AuthorizationData value from the elements field of the AD-CAMMAC.
	ticket, assuring the KDC that a malicious service has not		The original authorization-data field in the EncTicketPart would
	substituted a mismatched AD-CAMMAC received from another ticket.		have contained the AD-CAMMAC itself, possibly accompanied by other
			authorization data outside of the AD-CAMMAC. This altered
			Verifier-MAC computation binds the kdc-verifier to the other
			contents of the ticket, assuring the KDC that a malicious service
			has not substituted a mismatched AD-CAMMAC received from another
			ticket.
	svc-verifier:		svc-verifier:
	A Verifier-MAC where the key is the same long-term service key		A Verifier-MAC where the key is the same long-term service key
	that the KDC uses to encrypt the surrounding ticket. The checksum		that the KDC uses to encrypt the surrounding ticket. The checksum
	type is the required checksum type for the enctype of the service		type is the required checksum type for the enctype of the service
	key used to encrypt the ticket. This field MUST be present if the		key used to encrypt the ticket. This field MUST be present if the
	service principal of the ticket is not the local TGS, including		service principal of the ticket is not the local TGS, including
	when the ticket is a cross-realm Ticket-Granting Ticket (TGT).		when the ticket is a cross-realm Ticket-Granting Ticket (TGT).
	other-verifiers:		other-verifiers:
	A sequence of additional verifiers. In each additional Verifier-		A sequence of additional verifiers. In each additional Verifier-
	MAC, the key is a long-term key of the principal name specified in		MAC, the key is a long-term key of the principal name specified in
	the identifier field. The PrincipalName MUST be present and be a		the identifier field. The PrincipalName MUST be present and be a
	valid principal in the realm. KDCs MAY add one or more "trusted		valid principal in the realm. KDCs MAY add one or more "trusted
	service" verifiers. Unless otherwise administratively configured,		service" verifiers. Unless otherwise administratively configured,
	the KDC SHOULD determine the "trusted service" principal name by		the KDC SHOULD determine the "trusted service" principal name by
	replacing the service identifier component of the sname of the		replacing the service identifier component of the sname element of
	surrounding ticket with "host". The checksum is computed using a		the surrounding ticket with "host". The checksum is computed
	long-term key of the identified principal, and the checksum type		using a long-term key of the identified principal, and the
	is the required checksum type for the enctype of that long-term		checksum type is the required checksum type for the enctype of
	key. The kvno and enctype SHOULD be specified to disambiguate		that long-term key. The kvno and enctype SHOULD be specified to
	which of the long-term keys of the trusted service is used.		disambiguate which of the long-term keys of the trusted service is
			used.
	5. Usage		5. Usage
	Application servers and KDCs MAY ignore the AD-CAMMAC container and		Application servers and KDCs MAY ignore the AD-CAMMAC container and
	the authorization data elements it contains. For compatibility with		the authorization data elements it contains. For compatibility with
	older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD		older Kerberos implementations, a KDC issuing an AD-CAMMAC SHOULD
	enclose it in an AD-IF-RELEVANT container [RFC4120] unless the KDC		enclose it in an AD-IF-RELEVANT container [RFC4120] unless the KDC
	knows that the application server is likely to recognize it.		knows that the application server is likely to recognize it.
	6. Assigned numbers		6. Assigned Numbers
	RFC 4120 is updated in the following ways:		RFC 4120 is updated in the following ways:
	o The ad-type number 96 is assigned for AD-CAMMAC, updating the		o The ad-type number 96 is assigned for AD-CAMMAC, updating the
	table in Section 7.5.4 of [RFC4120].		table in Section 7.5.4 of [RFC4120].
	o The table in Section 5.2.6 of [RFC4120] is updated to map the ad-		o The table in Section 5.2.6 of [RFC4120] is updated to map the ad-
	type 96 to "DER encoding of AD-CAMMAC".		type 96 to "DER encoding of AD-CAMMAC".
	o The key usage number 64 is assigned for the Verifier-MAC checksum,		o The key usage number 64 is assigned for the Verifier-MAC checksum,
	updating the table in Section 7.5.1 of [RFC4120].		updating the table in Section 7.5.1 of [RFC4120].
	7. IANA Considerations		7. Security Considerations
	[ RFC Editor: please remove this section prior to publication. ]
	There are no IANA considerations in this document. Any numbers
	assigned in this document are not in IANA-controlled number spaces.
	8. Security Considerations
	The CAMMAC provides data origin authentication for authorization data		The CAMMAC provides data origin authentication for authorization data
	contained in it, attesting that it originated from the KDC. This		contained in it, attesting that it originated from the KDC. This
	section describes the precautions required to maintain the integrity		section describes the precautions required to maintain the integrity
	of that data origin authentication through various information flows		of that data origin authentication through various information flows
	involving a Kerberos ticket containing a CAMMAC.		involving a Kerberos ticket containing a CAMMAC.
	When handling a TGS-REQ containing a CAMMAC, a KDC makes a policy		When handling a TGS-REQ containing a CAMMAC, a KDC makes a policy
	decision on how to produce the CAMMAC contents of the newly issued		decision on how to produce the CAMMAC contents of the newly issued
	ticket based on properties of the ticket(s) accompanying the TGS-REQ.		ticket based on properties of the ticket(s) accompanying the TGS-REQ.
	This policy decision can involve filtering, transforming, or verbatim		This policy decision can involve filtering, transforming, or verbatim
	copying of the original CAMMAC contents. The following paragraphs		copying of the original CAMMAC contents. The following paragraphs
	provide some guidance on formulating such policies.		provide some guidance on formulating such policies.
	A KDC verifies a CAMMAC as originating from a local realm KDC when at		A KDC verifies a CAMMAC as originating from a local-realm KDC when at
	least one of following the criteria is true:		least one of following the criteria is true:
	1. The KDC successfully verifies the kdc-verifier; or		1. the KDC successfully verifies the kdc-verifier; or
	2. The KDC successfully verifies the svc-verifier, and the svc-		2. the KDC successfully verifies the svc-verifier, and the svc-
	verifier uses a key known only to the local realm KDCs; or		verifier uses a key known only to the local-realm KDCs; or
	3. No verifiers are present, the ticket-encrypting key is known only		3. no verifiers are present, the ticket-encrypting key is known only
	to local realm KDCs, and all local realm KDCs properly filter out		to local-realm KDCs, and all local-realm KDCs properly filter out
	client-submitted CAMMACs. (This can require particular caution		client-submitted CAMMACs. (This can require particular caution
	in a realm that has KDCs with mixed CAMMAC support, as might		in a realm that has KDCs with mixed CAMMAC support, as might
	happen when incrementally upgrading KDCs in a realm to support		happen when incrementally upgrading KDCs in a realm to support
	CAMMAC.)		CAMMAC.)
	A CAMMAC that originates from a local realm KDC might contain		A CAMMAC that originates from a local-realm KDC might contain
	information that originates from elsewhere. Originating from a local		information that originates from elsewhere. Originating from a
	realm KDC means that a local realm KDC attests that the CAMMAC		local-realm KDC means that a local-realm KDC attests that the CAMMAC
	contents conform to the local realm's policy, regardless of the		contents conform to the policies of the local realm, regardless of
	ultimate origin of the information in the CAMMAC (which could be a		the ultimate origin of the information in the CAMMAC (which could be
	remote realm in the case of a CAMMAC contained in a cross-realm TGT).		a remote realm in the case of a CAMMAC contained in a cross-realm
			TGT).
	Local policy determines when a KDC can apply a kdc-verifier to a		Local policy determines when a KDC can apply a kdc-verifier to a
	CAMMAC (or otherwise creates a CAMMAC that satisfies the local origin		CAMMAC (or otherwise creates a CAMMAC that satisfies the local-origin
	criteria listed above). Semantically, a CAMMAC that a KDC verifies		criteria listed above). Semantically, a CAMMAC that a KDC verifies
	as originating from a local realm KDC attests that the CAMMAC		as originating from a local-realm KDC attests that the CAMMAC
	contents conformed to local policy at the time of creation of the		contents conformed to local policy at the time of creation of the
	CAMMAC. Such a local policy can include allowing verbatim copying of		CAMMAC. Such a local policy can include allowing verbatim copying of
	CAMMAC contents from cross-realm TGTs from designated remote realms		CAMMAC contents from cross-realm TGTs from designated remote realms
	and applying a kdc-verifier to the new CAMMAC.		and applying a kdc-verifier to the new CAMMAC.
	Usually, when a KDC verifies a CAMMAC as originating from a local		Usually, when a KDC verifies a CAMMAC as originating from a local-
	realm KDC, the KDC can assume that the CAMMAC contents continue to		realm KDC, the KDC can assume that the CAMMAC contents continue to
	conform to the local realm's policies. It is generally safe for a		conform to the policies of the local realm. It is generally safe for
	KDC to make verbatim copies of the contents of such a CAMMAC into a		a KDC to make verbatim copies of the contents of such a CAMMAC into a
	new CAMMAC when handling a TGS-REQ. Particularly strict		new CAMMAC when handling a TGS-REQ. Particularly strict
	implementations might conduct additional policy checks on the		implementations might conduct additional policy checks on the
	contents of a CAMMAC originating from a local realm KDC if the local		contents of a CAMMAC originating from a local-realm KDC if the policy
	realm's policy materially changes during the life of the CAMMAC.		of the local realm materially changes during the life of the CAMMAC.
	A KDC MAY omit the kdc-verifier from the CAMMAC when it is not		A KDC MAY omit the kdc-verifier from the CAMMAC when it is not needed
	needed, according to how realm policies will subsequently treat the		according to how realm policies will subsequently treat the
	containing ticket. An implementation might choose to do this		containing ticket. An implementation might choose to do this
	omission to reduce the size of tickets it issues. Some examples of		omission to reduce the size of tickets it issues. Some examples of
	when such an omission is safe are:		when such an omission is safe are:
	1. For a local realm TGT, if all local realm KDCs correctly filter		1. For a local-realm TGT, if all local-realm KDCs correctly filter
	out client-submitted CAMMACs, the local realm origin criteria		out client-submitted CAMMACs, the local-realm origin criteria
	listed above allow omission of the kdc-verifier.		listed above allow omission of the kdc-verifier.
	2. An application service might not use the S4U2Proxy extension, or		2. An application service might not use the S4U2Proxy extension, or
	the realm policy might disallow the use of S4U2Proxy by that		the realm policy might disallow the use of S4U2Proxy by that
	service. In such situations where there is no flow of		service. In such situations where there is no flow of
	authorization data from the service to the KDC, the application		authorization data from the service to the KDC, the application
	service could modify the CAMMAC contents, but such modifications		service could modify the CAMMAC contents, but such modifications
	would have no effect on other services. Because of the lack of		would have no effect on other services. Because of the lack of
	security impact to other application services, the KDC MAY omit		security impact to other application services, the KDC MAY omit
	the kdc-verifier from a CAMMAC contained in a ticket for that		the kdc-verifier from a CAMMAC contained in a ticket for that
	skipping to change at page 8, line 41		skipping to change at page 8, line 41
	The method for computing the kdc-verifier binds it only to the		The method for computing the kdc-verifier binds it only to the
	authorization data contained within the CAMMAC; it does not bind the		authorization data contained within the CAMMAC; it does not bind the
	CAMMAC to any authorization data within the containing ticket but		CAMMAC to any authorization data within the containing ticket but
	outside the CAMMAC. At least one (non-standard) authorization data		outside the CAMMAC. At least one (non-standard) authorization data
	type, AD-SIGNEDPATH, attempts to bind to other authorization data in		type, AD-SIGNEDPATH, attempts to bind to other authorization data in
	a ticket, and it is very difficult for two such authorization data		a ticket, and it is very difficult for two such authorization data
	types to coexist.		types to coexist.
	The kdc-verifier in CAMMAC does not bind the service principal name		The kdc-verifier in CAMMAC does not bind the service principal name
	to the CAMMAC contents, because the service principal name is not		to the CAMMAC contents because the service principal name is not part
	part of the EncTicketPart. An entity that has access to the keys of		of the EncTicketPart. An entity that has access to the keys of two
	two different service principals can decrypt a ticket for one service		different service principals can decrypt a ticket for one service and
	and encrypt it in the key of the other service, altering the svc-		encrypt it in the key of the other service, altering the svc-verifier
	verifier to match. Both the kdc-verifier and the svc-verifier would		to match. Both the kdc-verifier and the svc-verifier would still
	still validate, but the KDC never issued this fabricated ticket. The		validate, but the KDC never issued this fabricated ticket. The
	impact of this manipulation is minor if the CAMMAC contents only		impact of this manipulation is minor if the CAMMAC contents only
	communicate attributes related to the client. If an application		communicate attributes related to the client. If an application
	requires an authenticated binding between the service principal name		requires an authenticated binding between the service principal name
	and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC		and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC
	some authorization data element that names the service principal.		some authorization data element that names the service principal.
	9. Acknowledgements		8. References
	Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Barry Leiba, Meral
	Shirazipour, Zhanna Tsitkov, Qin Wu, and Kai Zheng provided helpful
	technical and editorial feedback on earlier versions of this
	document. Thomas Hardjono helped with the initial editing to split
	this document from a predecessor document that had a wider scope.
	10. References
	10.1. Normative References		8.1. Normative References
	[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>.
	[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>.
	[X.680] ITU-T, "Information technology -- Abstract Syntax Notation		[X.680] ITU-T, "Information technology -- Abstract Syntax Notation
	One (ASN.1): Specification of basic notation -- ITU-T		One (ASN.1): Specification of basic notation", ITU-T
	Recommendation X.680 (ISO/IEC International Standard		Recommendation X.680, ISO/IEC International Standard
	8824-1:2008)", 2008.		8824-1:2008, November 2008.
	[X.690] ITU-T, "Information technology -- ASN.1 encoding rules:		[X.690] ITU-T, "Information technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER) -- ITU-T Recommendation X.690 (ISO/IEC International		(DER)", ITU-T Recommendation X.690, ISO/IEC International
	Standard 8825-1:2008)", 2008.		Standard 8825-1:2008, November 2008.
	10.2. Informative References		8.2. Informative References
	[MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions:		[MS-SFU] Microsoft, "[MS-SFU]: Kerberos Protocol Extensions:
	Service for User and Constrained Delegation Protocol",		Service for User and Constrained Delegation Protocol",
	January 2013,		October 2015,
	<http://msdn.microsoft.com/en-us/library/cc246071.aspx>.		<http://msdn.microsoft.com/en-us/library/cc246071.aspx>.
			Acknowledgements
			Shawn Emery, Sam Hartman, Greg Hudson, Ben Kaduk, Barry Leiba, Meral
			Shirazipour, Zhanna Tsitkov, Qin Wu, and Kai Zheng provided helpful
			technical and editorial feedback on earlier draft versions of this
			document. Thomas Hardjono helped with the initial editing to split
			this document from a predecessor document that had a wider scope.
	Authors' Addresses		Authors' Addresses
	Simo Sorce		Simo Sorce
	Red Hat		Red Hat
	Email: ssorce@redhat.com		Email: ssorce@redhat.com
	Tom Yu		Tom Yu
	MIT		MIT
	Email: tlyu@mit.edu		Email: tlyu@mit.edu
End of changes. 46 change blocks.
	130 lines changed or deleted		132 lines changed or added
This html diff was produced by rfcdiff 1.43. The latest version is available from http://tools.ietf.org/tools/rfcdiff/