< draft-weis-gdoi-mac-tek-02.txt		draft-weis-gdoi-mac-tek-03.txt >
	MSEC Working Group B. Weis		MSEC Working Group B. Weis
	Internet-Draft S. Rowles		Internet-Draft S. Rowles
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Cisco Systems
	Expires: September 13, 2011 March 12, 2011		Expires: March 15, 2012 September 12, 2011
	GDOI Generic Message Authentication Code Policy		GDOI Generic Message Authentication Code Policy
	draft-weis-gdoi-mac-tek-02		draft-weis-gdoi-mac-tek-03
	Abstract		Abstract
	A number of IETF signaling and routing applications require a set of		A number of IETF signaling and routing applications require a set of
	devices to share the same policy and keying material and include a		devices to share the same policy and keying material and include a
	message authentication code in their protocols packets for		message authentication code in their protocols packets for
	authentication . It is often beneficial for this keying material to		authentication . It is often beneficial for this keying material to
	be chosen dynamically using a group key management protocol. This		be chosen dynamically using a group key management protocol. This
	memo describes the policy required for the Group Domain of		memo describes the policy required for the Group Domain of
	Interpretation (GDOI) group key management system to distribute a		Interpretation (GDOI) group key management system to distribute a
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 13, 2011.		This Internet-Draft will expire on March 15, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . . 16		9.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Group Domain of Interpretation (GDOI) [RFC3547] is a group key		The Group Domain of Interpretation (GDOI) [I-D.ietf-msec-gdoi-update]
	management protocol fitting into the Multicast Security Group Key		is a group key management protocol fitting into the Multicast
	Management Architecture [RFC3740]. GDOI is used to disseminate group		Security Group Key Management Architecture [RFC3740]. GDOI is used
	security policy and keying material to group members for use with a		to disseminate group security policy and keying material to group
	particular cryptographic system. RFC 3547 describes the distribution		members for use with a particular cryptographic system. GDOI
	of group security policy and keying material for network traffic		describes the distribution of group security policy and keying
	protected by IPsec [RFC4301], however group security policy and		material for network traffic protected by IPsec [RFC4301], however
	keying material for other types of cryptographic systems can also be		group security policy and keying material for other types of
	distributed by GDOI as well.		cryptographic systems can also be distributed by GDOI as well.
	A number of transport and routing protocol specifications specify a		A number of transport and routing protocol specifications specify a
	MAC to provide packet authentication between devices. When the		MAC to provide packet authentication between devices. When the
	protocol instantiation includes a group of devices, they all need to		protocol instantiation includes a group of devices, they all need to
	share a common set of authentication policy and keying material to		share a common set of authentication policy and keying material to
	create and validate the Message Authentication Code (MAC) included in		create and validate the Message Authentication Code (MAC) included in
	protocol packets. The requirements for each of the protocol		protocol packets. The requirements for each of the protocol
	specifications are generally similar. This document describes how		specifications are generally similar. This document describes how
	GDOI can be used to distribute the group authentication policy and		GDOI can be used to distribute the group authentication policy and
	keying material for these protocols.		keying material for these protocols.
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	"applications" of the GDOI Generic Message Authentication Code		"applications" of the GDOI Generic Message Authentication Code
	Policy. Policy distribution for two applications is described:		Policy. Policy distribution for two applications is described:
	Resource reSerVation Protocol (RSVP) and Network Layer Signaling		Resource reSerVation Protocol (RSVP) and Network Layer Signaling
	(NLS).		(NLS).
	1.1. Scope		1.1. Scope
	This memo is intended to provide policy for applications not		This memo is intended to provide policy for applications not
	specifying the use of ESP [RFC4303] or AH [RFC4302] for		specifying the use of ESP [RFC4303] or AH [RFC4302] for
	authentication. Such applications SHOULD use the relevant payload		authentication. Such applications SHOULD use the relevant payload
	definitions described in RFC 3547. Group applications requiring the		definitions described in [I-D.ietf-msec-gdoi-update]. Group
	use of encryption MUST NOT use payloads described in this memo, and		applications requiring the use of encryption MUST NOT use payloads
	are encouraged to use ESP.		described in this memo, and are encouraged to use ESP.
	1.2. Requirements notation		1.2. Requirements notation
	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].
	2. GDOI Discussion		2. GDOI Discussion
	This section provides a short informative discussion of the GDOI		This section provides a short informative discussion of the GDOI
	group key management protocol. For definitive information regarding		group key management protocol. For definitive information regarding
	the GDOI protocol, please refer to RFC 3547. For more information on		the GDOI protocol, please refer to [I-D.ietf-msec-gdoi-update]. For
	group security, please refer to RFC 3740.		more information on group security, please refer to RFC 3740.
	The GDOI group key management protocol actively manages security		The GDOI group key management protocol actively manages security
	policy and keying material for a set of group members. GDOI begins		policy and keying material for a set of group members. GDOI begins
	operation when a client application on the group member initiates a		operation when a client application on the group member initiates a
	request to the GDOI subsystem on the group member. The GDOI		request to the GDOI subsystem on the group member. The GDOI
	subsystem "registers" to a GDOI Group Controller/Key Server (GCKS)		subsystem "registers" to a GDOI Group Controller/Key Server (GCKS)
	device using the GROUPKEY_PULL protocol. The group member and GCKS		device using the GROUPKEY_PULL protocol. The group member and GCKS
	setup a private and authenticated exchange. After successful		setup a private and authenticated exchange. After successful
	authentication and authorization, the GCKS provides group security		authentication and authorization, the GCKS provides group security
	policy and keying material to the GDOI subsystem on the group member.		policy and keying material to the GDOI subsystem on the group member.
	When the GDOI subsystem on the group member receives both security		When the GDOI subsystem on the group member receives both security
	policy and keying material, it makes it available to the client		policy and keying material, it makes it available to the client
	application on the device that originally requested the MAC policy.		application on the device that originally requested the MAC policy.
	The GDOI key server also distributes policy and keys that describe		The GDOI key server also distributes policy and keys that describe
	how it will distribute updates to group policy over time. Described		how it will distribute updates to group policy over time. Described
	in RFC 3547 as the GROUPKEY_PUSH message, it is more generally known		in GDOI as the GROUPKEY_PUSH message, it is more generally known as a
	as a "rekey" message. Rekey messages are typically distributed as IP		"rekey" message. Rekey messages are typically distributed as IP
	multicast packets. They provide replacement security policy and		multicast packets. They provide replacement security policy and
	keying material to group members (e.g., prior to a key expiration) or		keying material to group members (e.g., prior to a key expiration) or
	to revoke group members in a manner that is non-disruptive to the		to revoke group members in a manner that is non-disruptive to the
	extant group members.		extant group members.
	3. New GDOI Payload Definitions		3. New GDOI Payload Definitions
	The following sections describe how the GDOI Generic Message		The following sections describe how the GDOI Generic Message
	Authentication Code Policy is applied to GDOI protocol payloads.		Authentication Code Policy is applied to GDOI protocol payloads.
	There are two affected payloads: the Security Association (SA)		There are two affected payloads: the Security Association (SA)
	payload and the Key Download (KD) payload.		payload and the Key Download (KD) payload.
	The GDOI SA payload includes a set of SA attribute payloads,		The GDOI SA payload includes a set of SA attribute payloads,
	including an SA attribute payload which distributes a definition of		including an SA attribute payload which distributes a definition of
	the traffic to be secured. This payload is known as the SA TEK.		the traffic to be secured. This payload is known as the SA TEK.
	This memo describes a new type of SA TEK for distributing GDOI		This memo describes a new type of SA TEK for distributing GDOI
	Generic Message Authentication Code Policy. For more information on		Generic Message Authentication Code Policy. For more information on
	the SA TEK attribute payload, please refer to Section 5.4 of RFC		the SA TEK attribute payload, please refer to Section 5.5 of
	3547.		[I-D.ietf-msec-gdoi-update].
	The GDOI KD payload carries keying material associated with policy		The GDOI KD payload carries keying material associated with policy
	previously distributed in SA attribute payloads. This memo does not		previously distributed in SA attribute payloads. This memo does not
	define any new types of key policy for the Message Authentication		define any new types of key policy for the Message Authentication
	Protocol Policy, but does place restrictions on the types of keys		Protocol Policy, but does place restrictions on the types of keys
	that can be distributed.		that can be distributed.
	3.1. Message Authentication Code Policy SA TEK		3.1. Message Authentication Code Policy SA TEK
	This section describes the SA TEK payload used to distribute MAC		This section describes the SA TEK payload used to distribute MAC
	skipping to change at page 13, line 8 ¶		skipping to change at page 13, line 8 ¶
	o Define key lifetime parameters.		o Define key lifetime parameters.
	o Define valid SPI values and lengths.		o Define valid SPI values and lengths.
	o Description of Optional Attributes.		o Description of Optional Attributes.
	7. IANA Considerations		7. IANA Considerations
	A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned		A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned
	from the Standards Action space. The new algorithm id should be		from the Unassigned space. The new algorithm id should be called
	called GDOI_PROTO_MAC, and refers to the Message Authentication Code		GDOI_PROTO_MAC, and refers to the Message Authentication Code Policy
	Policy SA TEK described in Section 3.1 of this memo.		SA TEK described in Section 3.1 of this memo.
	Terms describing policies for allocating new name space types below		Terms describing policies for allocating new name space types below
	are defined in [RFC5226].		are defined in [RFC5226].
	The following applications are defined as part of this memo.		The following applications are defined as part of this memo.
	Application Type Value		Application Type Value
	------------------ -----		------------------ -----
	RESERVED 0		RESERVED 0
	RSVP 1		RSVP 1
	skipping to change at page 15, line 11 ¶		skipping to change at page 15, line 11 ¶
	Authz 2		Authz 2
	Specification Required 3-127		Specification Required 3-127
	Private Use 128-255		Private Use 128-255
	8. Security Considerations		8. Security Considerations
	This memo describes the passing of policy and keying material used by		This memo describes the passing of policy and keying material used by
	two applications: an RSVP speaker producing an RFC 2747 INTEGRITY		two applications: an RSVP speaker producing an RFC 2747 INTEGRITY
	Object, and an NLS speaker producing A_RESPONSE, B_RESPONSE, and		Object, and an NLS speaker producing A_RESPONSE, B_RESPONSE, and
	AUTHENTICATION TLVs. This policy and keying material is protected by		AUTHENTICATION TLVs. This policy and keying material is protected by
	the GDOI protocol described in [RFC3547]. The security		the GDOI protocol described in [I-D.ietf-msec-gdoi-update]. The
	considerations in that memo apply fully to this memo as well.		security considerations in that memo apply fully to this memo as
			well.
	The use of the MAC SA TEK to distribute policy and keys is only		The use of the MAC SA TEK to distribute policy and keys is only
	appropriate when the application is using a group security model.		appropriate when the application is using a group security model.
	[I-D.ietf-tsvwg-rsvp-security-groupkeying] describes the		[I-D.ietf-tsvwg-rsvp-security-groupkeying] describes the
	circumstances when a group security model may be used with RSVP. NLS		circumstances when a group security model may be used with RSVP. NLS
	always uses a group security model.		always uses a group security model.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The		[I-D.ietf-msec-gdoi-update]
	Group Domain of Interpretation", RFC 3547, July 2003.		Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
			of Interpretation", draft-ietf-msec-gdoi-update-11 (work
			in progress), August 2011.
	9.2. Informative References		9.2. Informative References
	[GDOI-REG]		[GDOI-REG]
	Internet Assigned Numbers Authority, "Group Domain of		Internet Assigned Numbers Authority, "Group Domain of
	Interpretation (GDOI) Payload Type Values", IANA Registry,		Interpretation (GDOI) Payload Type Values", IANA Registry,
	December 2004,		December 2004,
	<http://www.iana.org/assignments/gdoi-payloads>.		<http://www.iana.org/assignments/gdoi-payloads>.
	[I-D.ietf-tsvwg-rsvp-security-groupkeying]		[I-D.ietf-tsvwg-rsvp-security-groupkeying]
	Behringer, M., Faucheur, F., and B. Weis, "Applicability		Behringer, M., Faucheur, F., and B. Weis, "Applicability
	of Keying Methods for RSVP Security",		of Keying Methods for RSVP Security",
	draft-ietf-tsvwg-rsvp-security-groupkeying-09 (work in		draft-ietf-tsvwg-rsvp-security-groupkeying-11 (work in
	progress), December 2010.		progress), September 2011.
	[I-D.shore-nls-tl]		[I-D.shore-nls-tl]
	Shore, M., McGrew, D., and K. Biswas, "Network-Layer		Shore, M., McGrew, D., and K. Biswas, "Network-Layer
	Signaling: Transport Layer", draft-shore-nls-tl-06 (work		Signaling: Transport Layer", draft-shore-nls-tl-06 (work
	in progress), July 2008.		in progress), July 2008.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	February 1997.		February 1997.
End of changes. 12 change blocks.
	30 lines changed or deleted		33 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/