< draft-ietf-krb-wg-cammac-10.txt		draft-ietf-krb-wg-cammac-11.txt >
	Internet Engineering Task Force S. Sorce, Ed.		Internet Engineering Task Force S. Sorce, Ed.
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Updates: 4120 (if approved) T. Yu, Ed.		Updates: 4120 (if approved) T. Yu, Ed.
	Intended status: Standards Track T. Hardjono, Ed.		Intended status: Standards Track T. Hardjono, Ed.
	Expires: March 14, 2015 MIT Kerberos Consortium		Expires: April 6, 2015 MIT Kerberos Consortium
	September 10, 2014		October 3, 2014
	Kerberos Authorization Data Container Authenticated by Multiple MACs		Kerberos Authorization Data Container Authenticated by Multiple MACs
	draft-ietf-krb-wg-cammac-10		draft-ietf-krb-wg-cammac-11
	Abstract		Abstract
	Abstract: This document specifies a Kerberos Authorization Data		Abstract: This document specifies a Kerberos Authorization Data
	container that supersedes AD-KDC-ISSUED. It allows for multiple		container that supersedes AD-KDC-ISSUED. It allows for multiple
	Message Authentication Codes (MACs) or signatures to authenticate the		Message Authentication Codes (MACs) or signatures to authenticate the
	contained Authorization Data elements.		contained Authorization Data elements. This document updates RFC
			4120.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 March 14, 2015.		This Internet-Draft will expire on April 6, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 5 ¶		skipping to change at page 5, line 5 ¶
	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 a MAC computed over the ASN.1 DER encoding of the		Contains an RFC 3961 [RFC3961] Checksum (MAC) computed over the
	AuthorizationData value in the elements field of the AD-CAMMAC.		ASN.1 DER encoding of the AuthorizationData value in the elements
	The identifier, kvno, and enctype fields help the recipient locate		field of the AD-CAMMAC. The identifier, kvno, and enctype fields
	the key required for verifying the MAC. For the kdc-verifier and		help the recipient locate the key required for verifying the MAC.
	the svc-verifier, the identifier, kvno and enctype fields are		For the kdc-verifier and the svc-verifier, the identifier, kvno
	often obvious from context and MAY be omitted. For the kdc-		and enctype fields are often obvious from context and MAY be
	verifier, the MAC is computed differently than for the svc-		omitted. For the kdc-verifier, the MAC is computed differently
	verifier and the other-verifiers, as described later. The key		than for the svc-verifier and the other-verifiers, as described
	usage for computing the MAC (Checksum) is 64.		later. The key usage for computing the MAC (Checksum) is 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 the EncTicketPart of the
	surrounding ticket, but where the AuthorizationData value in the		surrounding ticket, but where the AuthorizationData value in the
	EncTicketPart contains the AuthorizationData value contained in		EncTicketPart contains the AuthorizationData value contained in
	the CAMMAC instead of the AuthorizationData value that would		the CAMMAC instead of the AuthorizationData value that would
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	the outer encryption of a local TGT is sufficient to protect the		the outer encryption of a local TGT is sufficient to protect the
	CAMMAC of a local TGT from tampering, assuming that all of the KDCs		CAMMAC of a local TGT from tampering, assuming that all of the KDCs
	in the local realm consistently filter out CAMMAC authorization data		in the local realm consistently filter out CAMMAC authorization data
	submitted by clients. The KDC MAY create a new CAMMAC from an		submitted by clients. The KDC MAY create a new CAMMAC from an
	existing CAMMAC lacking a kdc-verifier if that CAMMAC is contained		existing CAMMAC lacking a kdc-verifier if that CAMMAC is contained
	within a local TGT and all of the local realm KDCs are configured to		within a local TGT and all of the local realm KDCs are configured to
	filter out CAMMAC authorization data submitted by clients.		filter out CAMMAC authorization data submitted by clients.
	An application service might not use the S4U2Proxy extension, or the		An application service might not use the S4U2Proxy extension, or the
	realm policy might disallow the use of S4U2Proxy by that service. In		realm policy might disallow the use of S4U2Proxy by that service. In
	this situation, the application service could modify the CAMMAC		such situations where there is no flow of authorization data from the
			service to the KDC, the application service could modify the CAMMAC
	contents, but such modifications would have no effect on other		contents, but such modifications would have no effect on other
	services. The KDC MAY create a new CAMMAC from an existing CAMMAC		services. Because of the lack of security impact, the KDC MAY create
	lacking a kdc-verifier if it is inserting the new CAMMAC into a		a new CAMMAC from an existing CAMMAC lacking a kdc-verifier if it is
	service ticket for the same service principal as the ticket that		inserting the new CAMMAC into a service ticket for the same service
	contained the existing CAMMAC, but MUST NOT place a kdc-verifier in		principal as the ticket that contained the existing CAMMAC, but MUST
	the new CAMMAC.		NOT place a kdc-verifier in the new CAMMAC.
	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 of the EncTicketPart. An entity that has access to the keys of		part of the EncTicketPart. An entity that has access to the keys of
	two different service principals can decrypt a ticket for one service		two different service principals can decrypt a ticket for one service
	and encrypt it in the key of the other service, altering the svc-		and encrypt it in the key of the other service, altering the svc-
	verifier to match. Both the kdc-verifier and the svc-verifier would		verifier to match. Both the kdc-verifier and the svc-verifier would
	still validate, but the KDC never issued this fabricated ticket. The		still 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
	skipping to change at page 8, line 32 ¶		skipping to change at page 8, line 32 ¶
	8824-1:2008)", 2008.		8824-1:2008)", 2008.
	[X.690] ISO, , "Information technology -- ASN.1 encoding rules:		[X.690] ISO, , "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)", 1997.		Standard 8825-1:2008)", 1997.
	10.2. Informative References		10.2. Informative References
	[MIT-Athena]
	Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An
	Authentication Service for Open Network Systems. In
	Proceedings of the Winter 1988 Usenix Conference.
	February.", 1988.
	[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,		January 2013,
	<http://msdn.microsoft.com/en-us/library/cc246071.aspx>.		<http://msdn.microsoft.com/en-us/library/cc246071.aspx>.
	[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
	Authentication Service (V5)", RFC 1510, September 1993.
	Authors' Addresses		Authors' Addresses
	Simo Sorce (editor)		Simo Sorce (editor)
	Red Hat		Red Hat
	Email: ssorce@redhat.com		Email: ssorce@redhat.com
	Tom Yu (editor)		Tom Yu (editor)
	MIT Kerberos Consortium		MIT Kerberos Consortium
	Email: tlyu@mit.edu		Email: tlyu@mit.edu
	Thomas Hardjono (editor)		Thomas Hardjono (editor)
	MIT Kerberos Consortium		MIT Kerberos Consortium
	Email: hardjono@mit.edu		Email: hardjono@mit.edu
End of changes. 11 change blocks.
	30 lines changed or deleted		23 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/