< draft-ietf-msec-gdoi-srtp-00.txt		draft-ietf-msec-gdoi-srtp-01.txt >
	Network Working Group M. Baugher		Network Working Group M. Baugher
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track A. Rueegsegger		Intended status: Standards Track A. Rueegsegger
	Expires: August 24, 2007 secunet SwissIT AG		Expires: June 5, 2008 secunet SwissIT AG
	S. Rowles		S. Rowles
	Cisco Systems, Inc.		Cisco Systems, Inc.
	February 20, 2007		December 3, 2007
	GDOI Key Establishment for the SRTP Data Security Protocol		GDOI Key Establishment for the SRTP Data Security Protocol
	draft-ietf-msec-gdoi-srtp-00.txt		draft-ietf-msec-gdoi-srtp-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 24, 2007.		This Internet-Draft will expire on June 5, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Secure Real-time Transport Protocol (SRTP) protects unicast and		The Secure Real-time Transport Protocol (SRTP) protects unicast and
	multicast RTP packets. Multicast receivers of SRTP session data		multicast RTP packets. Multicast receivers of SRTP session data
	therefore share an SRTP master key for message authentication and		therefore share an SRTP master key for message authentication and
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	Interpretation (GDOI) and RFC 2408, the Internet Security Association		Interpretation (GDOI) and RFC 2408, the Internet Security Association
	and Key Management Protocol. This document extends GDOI for SRTP		and Key Management Protocol. This document extends GDOI for SRTP
	group key establishment.		group key establishment.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Overview of This Document . . . . . . . . . . . . . . . . 3		1.1. Overview of This Document . . . . . . . . . . . . . . . . 3
	1.2. Conformance Language . . . . . . . . . . . . . . . . . . . 3		1.2. Conformance Language . . . . . . . . . . . . . . . . . . . 3
	2. GDOI Signaling of an SRTP Crypto Context . . . . . . . . . . . 4		2. GDOI Signaling of an SRTP Crypto Context . . . . . . . . . . . 4
	2.1. GDOI and EKT . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. GDOI Signaling and SDP Signaling . . . . . . . . . . . . . 6
	2.2. GDOI Exchanges for SRTP . . . . . . . . . . . . . . . . . 7		2.2. GDOI and EKT . . . . . . . . . . . . . . . . . . . . . . . 7
	2.3. SRTP SA-TEK Definitions . . . . . . . . . . . . . . . . . 9		2.3. GDOI Exchanges for SRTP . . . . . . . . . . . . . . . . . 8
	2.4. EKT SA-TEK Definitions . . . . . . . . . . . . . . . . . . 14		2.4. SRTP SA-TEK Definitions . . . . . . . . . . . . . . . . . 10
	2.5. SRTP Key Download . . . . . . . . . . . . . . . . . . . . 15		2.5. EKT SA-TEK Definitions . . . . . . . . . . . . . . . . . . 14
			2.6. SRTP Key Download . . . . . . . . . . . . . . . . . . . . 15
	3. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 16		3. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 16
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 17		4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	4.1. No Sharing Counter-Mode Encryption Keys . . . . . . . . . 17		4.1. No Sharing Counter-Mode Encryption Keys . . . . . . . . . 17
	4.2. Enable Distributed Key Management . . . . . . . . . . . . 17		4.2. Enable Distributed Key Management . . . . . . . . . . . . 17
	4.3. Support Strong Source Authentication . . . . . . . . . . . 18		4.3. Support Strong Source Authentication . . . . . . . . . . . 18
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 21		7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	7.2. Informative References . . . . . . . . . . . . . . . . . . 22		7.2. Informative References . . . . . . . . . . . . . . . . . . 22
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	"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].
	2. GDOI Signaling of an SRTP Crypto Context		2. GDOI Signaling of an SRTP Crypto Context
	A service can use GDOI to establish keys (security associations) for		A service can use GDOI to establish keys (security associations) for
	a data security protocol provided that GDOI is extended with one or		a data security protocol provided that GDOI is extended with one or
	more payload definitions for that data security protocol. For GDOI,		more payload definitions for that data security protocol. For GDOI,
	a "data security protocol" is any protocol that uses the services of		a "data security protocol" is any protocol that uses the services of
	GDOI. By contrast, TLS key establishment is packaged with the TLS		GDOI. By contrast, TLS key establishment is packaged with the TLS
	data-security protocol. GDOI follows the ISAKMP model in which key		data-security protocol. This memo will review the GDOI model and how
	management and data security MAY use separate transport addresses and		the key management correlates to the traffic for which it provides
	underlying transport protocols, typically UDP or TCP. By default,		keys. GDOI follows the ISAKMP model in which key management and data
	GDOI uses UDP to negotiate an IKE phase 1 security association		security may use separate transport addresses and underlying
	between a GDOI Group Controller/Key Server (GCKS) and group member;		transport protocols, typically UDP or TCP. By default, GDOI uses UDP
	the IKE phase 1 protects an exchange to establish a security		to negotiate an IKE phase 1 security association between a GDOI Group
	association on behalf of an application security protocol. In SRTP,		Controller/Key Server (GCKS) and group member; the IKE phase 1
	a "security association" is called a "cryptographic context", and		protects an exchange to establish a security association on behalf of
	this is the application-specific information carried in GDOI payloads		an application security protocol. In SRTP, a "security association"
	between the GCKS and a GDOI member. This section defines these SRTP		is called a "cryptographic context", and this is the application-
	payloads for GDOI.		specific information carried in GDOI payloads between the GCKS and a
			GDOI member. This section defines these SRTP payloads for GDOI.
	Figure 2.0-1: Member and SRTP Interfaces in a Central GCKS		Figure 2.0-1: Member and SRTP Interfaces in a Central GCKS
	Configuration		Configuration
	+-------+		+-------+
	| GDOI |		| GDOI |
	| GCKS |		| GCKS |
	+-------+		+-------+
	^		^
	|		|
	V		V
	+--------------------------+		+--------------------------+
	| GDOI with SRTP payloads |		| GDOI with SRTP payloads |
	V V		V V
	+----------+ +----------+		+----------+ +----------+
	|+--------+| |+--------+|		|+--------+| |+--------+|
	|| GDOI || || GDOI ||		|| GDOI || || GDOI ||
	|| Member || || Member ||		|| Member || || Member ||
	|+--------+| |+--------+|		|+--------+| |+--------+|
	| ^ | | ^ |		| ^ | | ^
	| | | | | |		| | | | | |
	| API | | API |		| API | | API |
	| | | | | |		| | | | | |
	| V | | V |		| V | | V |
	|+--------+| SRTP/SRTCP |+--------+|		|+--------+| SRTP/SRTCP |+--------+|
	|| SRTP |---------------->| SRTP ||		|| SRTP |---------------->| SRTP ||
	|| Source |<----------------|Receiver||		|| Source |<----------------|Receiver||
	|+--------+| SRTCP |+--------+|		|+--------+| SRTCP |+--------+|
	+----------+ +----------+		+----------+ +----------+
	MEMBERi MEMBERj		MEMBERi MEMBERj
	This section gives the SRTP payloads for GDOI key management		This section gives the SRTP payloads for GDOI key management
	exchanges. SRTP is an application-layer security protocol that		exchanges. SRTP is an application-layer security protocol that
	operates above the TCP/IP services (sockets) interface. GDOI also		operates above the transport layer. GDOI also operates above the
	operates above the transport service. SRTP communicates with GDOI		transport service. SRTP communicates with GDOI using the API shown
	using the API shown in Figure 2.0-1. SRTP or another application		in Figure 2.0-1. SRTP or another application uses the API to request
	uses the API to request that GDOI establish an SRTP cryptographic		that GDOI establish an SRTP cryptographic context (i.e. a GDOI
	context (i.e. a GDOI "security association"), which is described in		"security association"), which is described in Section 3.2 of the
	Section 3.2 of the SRTP specification [RFC3711]. The API of Figure		SRTP specification [RFC3711]. The API of Figure 2.0-1 is not
	2.0-1 is not considered further in this document, which is concerned		considered further in this document, which is concerned solely with
	solely with extending the GDOI protocol with new payloads for SRTP.		extending the GDOI protocol with new payloads for SRTP. Using this
	Using this protocol extension, the GDOI Group Controller/Key Server		protocol extension, the GDOI Group Controller/Key Server (GCKS) can
	(GCKS) can provide the cryptographic keys, cryptographic parameters		provide the cryptographic keys, cryptographic parameters and session
	and session parameters to SRTP (via the API to a GDOI Member) in		parameters to SRTP (via the API to a GDOI Member) in accordance with
	accordance with pre-configured group policy regarding which		pre-configured group policy regarding which parameters are acceptable
	parameters are acceptable and which are not. The GCKS might obtain		and which are not. The GCKS might obtain policy and some SRTP
	policy and some SRTP crypto-context information through a user		crypto-context information through a user console or event database.
	console or event database. The GCKS generates some information		The GCKS generates some information automatically, such as keying
	automatically, such as keying materials. How the GCKS obtains or		materials. How the GCKS obtains or generates policy information for
	generates policy information for the SRTP payload fields is specific		the SRTP payload fields is specific to an implementation and not
	to an implementation and not considered further in this document.		considered further in this document.
	Figure 2.0-2: A Distributed GCKS Configuration		Figure 2.0-2: A Distributed GCKS Configuration
	+----------+		+----------+
	+----------+ |+--------+|		+----------+ |+--------+|
	+|+--------+| GDOI with || GDOI ||		+|+--------+| GDOI with || GDOI ||
	||| GCKS & |<--------------->| GCKS & ||		||| GCKS & |<--------------->| GCKS & ||
	||| Member || SRTP payloads|| Member ||		||| Member || SRTP payloads|| Member ||
	||+--------+| |+--------+|		||+--------+| |+--------+|
	|| ^ | | ^ |		|| ^ | | ^ |
	|| | | | | |		|| | | | | |
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	|| V | | V |		|| V | | V |
	||+--------+| SRTP/SRTCP |+--------+|		||+--------+| SRTP/SRTCP |+--------+|
	||| SRTP |---------------->| SRTP ||		||| SRTP |---------------->| SRTP ||
	||| Source |<----------------|Receiver||		||| Source |<----------------|Receiver||
	||+--------+| SRTCP |+--------+|		||+--------+| SRTCP |+--------+|
	|| MEMBERi | | MEMBERj |		|| MEMBERi | | MEMBERj |
	|+----------+ +----------+		|+----------+ +----------+
	| MEMBERk |		| MEMBERk |
	+----------+		+----------+
	In a physical realization of GDOI system, the GDOI GKCS can either be		In the Distributed GCKS, each group member is physically co-located
	separate from or co-located with a GDOI Member. When physically co-		with its own GKCS. This configuration is labeled a "Distributed
	located with a member, the GCKS can be dedicated to maintaining the		GCKS" in Figure 2.0-2 in that the function of establishing the key
	group keys for that member's "SRTP Source", and the GCKS can more		for a particular sender to the group is distributed among each such
	easily obtain the SRTP-specific information for its payloads across		sender to the group. Whereas a centralized GCKS establishes keys for
	the API. This configuration is shown in Figure 2.0-2. It is often		all senders to a group (Figure 2.0-1), a distributed GCKS establishes
	more scalable for the GCKS to be physically co-located in the same		keys for a single sender to a group. A distributed GCKS, therefore,
	computer as the SRTP source of the multicast stream. When this		is co-located with each sender to a group and is dedicated to
	configuration is possible, there is no need for a centralized Group		maintaining the group keys for that member's "SRTP Source". In this
	Controller/Key Server.		configuration, the GCKS can more easily obtain the SRTP-specific
			information for its payload across an API. The distinction between
			Figures 2.0-1 and 2.0-2 are important because the SRTP data security
			protocol has tight coupling with its key management in the use of the
			SSRC, SEQ,and ROC parameters as discussed in the next section.
	2.1. GDOI and EKT		2.1. GDOI Signaling and SDP Signaling
			SDP is a standard means to signal SRTP sessions when the SDP (RFC
			4566) transport identifier for a media session is "SAVP." Some of
			the information contained in an SDP message is identical to the
			information conveyed in an GDOI-SRTP message such as the transport
			addresses. This is unavoidable since both signaling messages need to
			identify and describe the SRTP session. There is generally more
			information in the GDOI-SRTP message than in the SDP such as the
			keying material for the session, and it is possible that the two
			messages may be linked. For example, an SDP message could be used to
			trigger the initiation of the GDOI exchange for the SRTP session.
			For example, an RFC 4566 "k=" field can designate the URI of a GDOI
			key server in the SDP message. In this case, k=http://
			GCKS.example.com would direct the receiver of the SDP message to
			obtain the keys for the SRTP session. Such usage is Informative
			according to this document, not Normative, and further consideration
			of SDP signaling is beyond the scope of this document.
			2.2. GDOI and EKT
	When the Group Controller/Key Server (GCKS) is centralized as a		When the Group Controller/Key Server (GCKS) is centralized as a
	third-party device, it is not co-located with the SRTP source, and it		third-party device, it is not co-located with the SRTP source, and it
	is not always possible for the GCKS to get access to important SRTP		is not always possible for the GCKS to get access to important SRTP
	keystream parameters, which are the SSRC, the Rollover Counter (ROC)		keystream parameters, which are the SSRC, the Rollover Counter (ROC)
	and current SRTP sequence number (SEQ). This information is		and current SRTP sequence number (SEQ). This information is
	generated internally by the SRTP source and used in the SRTP ciphers		generated internally by the SRTP source and used in the SRTP ciphers
	and SRTP replay protection; the SSRC is used in combination with the		and SRTP replay protection; the SSRC is used in combination with the
	destination transport address to identify an RTP session [RFC3550]		destination transport address to identify an RTP session [RFC3550]
	and thus identify an SRTP session's crypto context. When the GCKS is		and thus identify an SRTP session's crypto context. When the GCKS is
	skipping to change at page 7, line 45 ¶		skipping to change at page 8, line 20 ¶
	SRTP SA-TEK payload that describes an SRTP master key and salt; the		SRTP SA-TEK payload that describes an SRTP master key and salt; the
	SRTP SA-TEK is always present. Second, there is an EKT SA-TEK		SRTP SA-TEK is always present. Second, there is an EKT SA-TEK
	payload that describes an EKT key. In either case, there is exactly		payload that describes an EKT key. In either case, there is exactly
	one Key Download payload sent in a GDOI-SRTP exchange. If EKT is		one Key Download payload sent in a GDOI-SRTP exchange. If EKT is
	signaled by the presence of an EKT SA-TEK, then the Key Download		signaled by the presence of an EKT SA-TEK, then the Key Download
	payload SHALL carry an EKT key. If EKT is not signaled, then the KEY		payload SHALL carry an EKT key. If EKT is not signaled, then the KEY
	Download payload SHALL carry an SRTP master key and master salt. In		Download payload SHALL carry an SRTP master key and master salt. In
	either case, there MUST be exactly one Key Download payload when		either case, there MUST be exactly one Key Download payload when
	signaling SRTP in GDOI.		signaling SRTP in GDOI.
	2.2. GDOI Exchanges for SRTP		2.3. GDOI Exchanges for SRTP
	As mentioned above, GDOI exchanges for SRTP are protected by a "phase		As mentioned above, GDOI exchanges for SRTP are protected by a "phase
	1 security association", which is an IKE phase 1 connection in which		1 security association", which is an IKE phase 1 connection in which
	the GCKS and the member identify and authenticate each other. For		the GCKS and the member identify and authenticate each other. For
	the IKE phase 1, RFC 3547 allows any defined IKE identity such as IP		the IKE phase 1, RFC 3547 allows any defined IKE identity such as IP
	address, fully-qualified domain name or an opaque byte string that		address, fully-qualified domain name or an opaque byte string that
	identifies a pre-shared key[ISAKMP-REG]. Also, any of the IKE		identifies a pre-shared key[ISAKMP-REG]. Also, any of the IKE
	authentication methods MAY be used including pre-shared key, public-		authentication methods MAY be used including pre-shared key, public-
	key encryption, and digitial signatures. The IKE phase 1 connection		key encryption, and digital signatures. The IKE phase 1 connection
	is established using a six-message "Main Mode" exchange if identity		is established using a six-message "Main Mode" exchange if identity
	protection is desired or a 3-message "Aggressive Mode" if identity		protection is desired or a 3-message "Aggressive Mode" if identity
	protection is not needed [RFC2409]. With identity protection, a		protection is not needed [RFC2409]. With identity protection, a
	passive attack will not reveal the identities that the initiator or		passive attack will not reveal the identities that the initiator or
	responder use to authenticate themselves.		responder use to authenticate themselves.
	In GDOI, the initiator is usually the group member and the responder		In GDOI, the initiator is usually the group member and the responder
	is usually the Group Controller/Key Server. This is true in both the		is usually the Group Controller/Key Server. This is true in both the
	phase 1 and phase 2 exchanges. The phase 2 exchange uses a 4-message		phase 1 and phase 2 exchanges. The phase 2 exchange uses a 4-message
	exchange as defined in RFC 3547, Section 3 [RFC3547] and is		exchange as defined in RFC 3547, Section 3 [RFC3547] and is
	reproduced below for the convenience of the reader.		reproduced below for the convenience of the reader.
	Figure 2.2-1: GDOI Phase 2 Exchange, from Section 3.2 [RFC3547]		Figure 2.3-1: GDOI Phase 2 Exchange, from Section 3.2 [RFC3547]
	Initiator (Member) Responder (GCKS)		Initiator (Member) Responder (GCKS)
	------------------ ----------------		------------------ ----------------
	HDR*, HASH(1), Ni, ID -->		HDR*, HASH(1), Ni, ID -->
	<-- HDR*, HASH(2), Nr, SA		<-- HDR*, HASH(2), Nr, SA
	HDR*, HASH(3) [,KE_I] -->		HDR*, HASH(3) [,KE_I] -->
	[,CERT] [,POP_I]		[,CERT] [,POP_I]
	<-- HDR*, HASH(4),[KE_R,][SEQ,]		<-- HDR*, HASH(4),[KE_R,][SEQ,]
	KD [,CERT] [,POP_R]		KD [,CERT] [,POP_R]
	* Protected by the Phase 1 SA, encryption occurs after HDR		* Protected by the Phase 1 SA, encryption occurs after HDR
	When sent to the GDOI port, the message header (HDR) of Fig. 2.2-1		When sent to the GDOI port, the message header (HDR) of Fig. 2.3-1
	identifies the phase 2 exchange, i.e. by the ISAKMP message id (M-ID)		identifies the phase 2 exchange, i.e. by the ISAKMP message id (M-ID)
	field of HDR. Everything else is encrypted using the phase 1		field of HDR. Everything else is encrypted using the phase 1
	encryption key and authenticated in the HASH payloads that appear in		encryption key and authenticated in the HASH payloads that appear in
	each message. A nonce and an ID are sent in the first message from		each message. A nonce and an ID are sent in the first message from
	the member to the GCKS, which responds by downloading the		the member to the GCKS, which responds by downloading the
	cryptographic parameters, session parameters, authentication policy		cryptographic parameters, session parameters, authentication policy
	and other information that the member needs to identify and		and other information that the member needs to identify and
	authenticate itself to the GCKS. The GCKS provides these parameters		authenticate itself to the GCKS. The GCKS provides these parameters
	and policy information in the Security-Association (SA) payload of		and policy information in the Security-Association (SA) payload of
	the second message along with its nonce, Nr. As described in the		the second message along with its nonce, Nr. As described in the
	previous section of this document, how these policies and parameters		previous section of this document, how these policies and parameters
	are defined is out of scope for this document. The successful GDOI-		are defined is out of scope for this document. The successful GDOI-
	SRTP exchange establishes an SRTP cryptographic context (i.e. a		SRTP exchange establishes an SRTP cryptographic context (i.e. a
	security association among SRTP endpoints).		security association among SRTP endpoints).
	The third message of Fig 2.2-1 is from the member to the GCKS. If		The third message of Fig 2.3-1 is from the member to the GCKS. If
	perfect forward secrecy is desired, Diffie-Hellman public value are		perfect forward secrecy is desired, Diffie-Hellman public value are
	exchanged in the Key-Exchange (KE) payloads (KE_I and KE_R), which		exchanged in the Key-Exchange (KE) payloads (KE_I and KE_R), which
	are optional. If additional authorization and authentication are		are optional. If additional authorization and authentication are
	desired beyond the IKE Phase 1, then a digital certificate can be		desired beyond the IKE Phase 1, then a digital certificate can be
	passed in a Cerficate (CERT) payload with an optional proof-of-		passed in a Cerficate (CERT) payload with an optional proof-of-
	possession exchange to prove possession of the corresponding private		possession exchange to prove possession of the corresponding private
	key (POP_I and POP_R).		key (POP_I and POP_R).
	The fourth and final message concludes a successful GDOI phase 2		The fourth and final message concludes a successful GDOI phase 2
	exchange by passing a Key-Download (KD) payload. Any KE, CERT or POP		exchange by passing a Key-Download (KD) payload. Any KE, CERT or POP
	exchanges are completed in the final message. Another optional field		exchanges are completed in the final message. Another optional field
	is SEQ, which is the sequence number associated with messages that		is SEQ, which is the sequence number associated with messages that
	are sent (pushed) from the GCKS to the member. For pushed messages,		are sent (pushed) from the GCKS to the member. For pushed messages,
	the SA payload will include a GDOI key-encrypting key (KEK)		the SA payload will include a GDOI key-encrypting key (KEK)
	definition in an SA-KEK payload. A GDOI group will not use pushed		definition in an SA-KEK payload. A GDOI group will not use pushed
	messages if it does not need to perform key update of the SRTP Master		messages if it does not need to perform key update of the SRTP Master
	Key (SA-TEK) or member revocation. Thus, an SA-KEK is OPTIONAL		Key (SA-TEK) or member revocation. Thus, an SA-KEK is OPTIONAL
	whereas one or two SA-TEKs are REQUIRED by this document; these are		whereas one or two SA-TEKs are REQUIRED by this document; these are
	the SRTP SA-TEK and the optional EKT SA-TEK. The SA-KEK and SA-TEK		the SRTP SA-TEK and the optional EKT SA-TEK. The SA-KEK and SA-TEK
	are part of the SA payload shown in Figure 2.2-1.		are part of the SA payload shown in Figure 2.3-1.
	2.3. SRTP SA-TEK Definitions		2.4. SRTP SA-TEK Definitions
	The RFC 3547 SA TEK payload has a header and a protocol-specific		The RFC 3547 SA TEK payload has a header and a protocol-specific
	payload. The SRTP SA TEK is identified by the GDOI_PROTO_SRTP value		payload. The SRTP SA TEK is identified by the GDOI_PROTO_SRTP value
	(assigned by IANA) in the Protocol-ID field of the SA TEK header,		(assigned by IANA) in the Protocol-ID field of the SA TEK header,
	which is defined in Section 5.4 of RFC 3547 [RFC3547]. The SA TEK		which is defined in Section 5.4 of RFC 3547 [RFC3547]. The SA TEK
	protocol-specific payload for SRTP is given in Figure 2.2-1. The SAT		protocol-specific payload for SRTP is given in Figure 2.3-1. The SAT
	Payload fields are shown in Figure 2.3-1.		Payload fields are shown in Figure 2.4-1.
	Figure 2.3-1: SRTP SA-TEK		Figure 2.4-1: SRTP SA-TEK
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! SRC ID Type ! SRC ID Port !SRC ID Date Len!		! SRC ID Type ! SRC ID Port !SRC ID Data Len!
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! SRC Identification Data ~		! SRC Identification Data ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! DST ID Type ! DST ID Port !DST ID Data Len!		! DST ID Type ! DST ID Port !DST ID Data Len!
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! DST Identification Data ~		! DST Identification Data ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! Replay Window ! KD Rate ! SRTP Lifetime ! SRTCP Lifetime!		! Replay Window ! KD Rate ! SRTP Lifetime ! SRTCP Lifetime!
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! Options ! Crypto Suite ! SPI ! Attributes ~		! Options ! Crypto Suite ! SPI ! Attributes ~
	skipping to change at page 10, line 38 ¶		skipping to change at page 10, line 50 ¶
	SEQ 3 B		SEQ 3 B
	MKI 4 V		MKI 4 V
	The Group Controller/Key Server (GCKS) provides SA-TEK and Key-		The Group Controller/Key Server (GCKS) provides SA-TEK and Key-
	Download payload information to an SRTP implementation through the		Download payload information to an SRTP implementation through the
	GDOI member to SRTP, which uses this information to initialize the		GDOI member to SRTP, which uses this information to initialize the
	cryptographic context of an SRTP session. An SRTP crypto context is		cryptographic context of an SRTP session. An SRTP crypto context is
	identified by the SSRC and RTP destination transport address as		identified by the SSRC and RTP destination transport address as
	explained in Section 8 of the SRTP specification [RFC3711]. The RTP		explained in Section 8 of the SRTP specification [RFC3711]. The RTP
	destination address is identified in the SA-TEK, which is shown in		destination address is identified in the SA-TEK, which is shown in
	Figure 2.3-1. The "DST ID Type" defines the type of DST		Figure 2.4-1. The "DST ID Type" defines the type of DST
	Identification data, which is an IP address or a fully-qualified		Identification data, which is an IP address or a fully-qualified
	domain name that resolves to one. The destination port is also		domain name that resolves to one. The destination port is also
	carried in the DST ID Port, also shown in Figure 2.3-1 following the		carried in the DST ID Port, also shown in Figure 2.4-1 following the
	similar definitions for the source.		similar definitions for the source.
	Replay window, key-derivation (KD) rate, SRTP and SRTCP lifetimes are		Replay window, key-derivation (KD) rate, SRTP and SRTCP lifetimes are
	the crypto context parameters for the particular SRTP session. Also		the crypto context parameters for the particular SRTP session. Also
	shown in Figure 2.3-1 is the options field, that declares values for		shown in Figure 2.4-1 is the options field, that declares values for
	boolean SRTP configuration parameters and also whether EKT is to be		boolean SRTP configuration parameters and also whether EKT is to be
	used or not. Crypto Suite identifies the SRTP encryption and		used or not. Crypto Suite identifies the SRTP encryption and
	authentication transforms. GDOI-SRTP uses the same encryption and		authentication transforms. GDOI-SRTP uses the same encryption and
	authentication transforms for SRTP and SRTCP. Finally, the SPI is		authentication transforms for SRTP and SRTCP. Finally, the SPI is
	the "security parameter index", which identifies the particular		the "security parameter index", which identifies the particular
	security association (SRTP crypto context) by a 8-bit number, a		security association (SRTP crypto context) by a 8-bit number, a
	positive integer.		positive integer.
	The Attributes payloads are optional. The attributes must follow the		The Attributes payloads are optional. The attributes must follow the
	format defined in ISAKMP [RFC3547] section 3.3. In the table,		format defined in ISAKMP [RFC3547] section 3.3. In the table,
	attributes that are defined as TV are marked as Basic (B); attributes		attributes that are defined as TV are marked as Basic (B); attributes
	that are defined as TLV are marked as Variable (V). The SSRC,		that are defined as TLV are marked as Variable (V). The SSRC,
	rollover counter (ROC) and current sequence number (SEQ) MAY be		rollover counter (ROC) and current sequence number (SEQ) MAY be
	carried in the SA TEK payload that is shown in Figure 2.3-1. When		carried in the SA TEK payload that is shown in Figure 2.4-1. When
	the SSRC, ROC and the SEQ are not carried in the SRTP SA-TEK payload,		the SSRC, ROC and the SEQ are not carried in the SRTP SA-TEK payload,
	the EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt]. EKT is		the EKT protocol SHOULD be used [I-D.mcgrew-srtp-ekt].
	signaled in the options field described above. If EKT is signaled in
	Options, then the SSRC, ROC and SEQ Attributes MUST be ignored. If
	EKT is not signaled in Options, the the SSRC, ROC and SEQ MUST be
	present.
	Each of the fields of Figure 2.3-1 is defined as follows.		Each of the fields of Figure 2.4-1 is defined as follows.
	o SRC ID Type (1 octet) -- Value describing the identity information		o SRC ID Type (1 octet) -- Value describing the identity information
	found in the SRC Identification Data field. Defined values are		found in the SRC Identification Data field. Defined values are
	specified by the IPSEC Identification Type section in the IANA		specified by the IPSEC Identification Type section in the IANA
	isakmpd-registry [ISAKMP-REG].		isakmp-registry [ISAKMP-REG].
	o SRC ID Port (2 octets) -- Value specifying a port associated with		o SRC ID Port (2 octets) -- Value specifying a port associated with
	the SRC Identification data. A value of zero means that the SRC		the SRC Identification data. A value of zero means that the SRC
	ID Port field should be ignored.		ID Port field should be ignored.
	o SRC ID Data Len (1 octet) -- Value specifying the length of the		o SRC ID Data Len (1 octet) -- Value specifying the length of the
	SRC Identification Data field.		SRC Identification Data field.
	o SRC Identification Data (variable length) -- Value as indicated by		o SRC Identification Data (variable length) -- Value as indicated by
	the SRC ID Type. According to RFC 3547, SRC Identification Data		the SRC ID Type. According to RFC 3547, SRC Identification Data
	consists of three bytes of zero for multiple-source multicast		consists of three bytes of zero for multiple-source multicast
	groups that use a common TEK for all senders. The TEK in an SRTP		groups that use a common TEK for all senders. The TEK in an SRTP
	Key Download payload is an SRTP master key, however, and it is NOT		Key Download payload is an SRTP master key, however, and it is NOT
	RECOMMENDED that this key be shared for the counter mode and f8		RECOMMENDED that this key be shared for the counter mode and f8
	ciphers of SRTP. Thus, it is NOT RECOMMENDED that this field		ciphers of SRTP. Thus, it is NOT RECOMMENDED that this field
	consist of three bytes of zero. It SHOULD be ID_FQDN (see the		consist of three bytes of zero, because that would cause the TEK
	"NAT Considerations" section).		to be shared. It SHOULD be ID_FQDN (see the "NAT Considerations"
			section).
	o DST ID Type (1 octet) -- Value describing the identity information		o DST ID Type (1 octet) -- Value describing the identity information
	found in the DST Identification Data field. Defined values are		found in the DST Identification Data field. Defined values are
	specified by the IPSEC Identification Type section in the IANA		specified by the IPSEC Identification Type section in the IANA
	isakmpd-registry [ISAKMP-REG].		isakmpd-registry [ISAKMP-REG].
	o DST ID Port (2 octets) -- Value specifying a port associated with		o DST ID Port (2 octets) -- Value specifying a port associated with
	the source Id. A value of zero means that the DST ID Port field		the source Id. A value of zero means that the DST ID Port field
	should be ignored.		should be ignored.
	o DST ID Data Len (1 octet) -- Value specifying the length of the		o DST ID Data Len (1 octet) -- Value specifying the length of the
	DST Identification Data field.		DST Identification Data field.
	o DST Identification Data (variable length) -- Value, as indicated		o DST Identification Data (variable length) -- Value, as indicated
	by the DST ID Type.		by the DST ID Type.
	o Replay Window Size (1 octet) - The size of the SRTP Replay Window		o Replay Window Size (1 octet) - The suggested size of the SRTP
	as specified in Section 3.3.2 of the SRTP standard [RFC3711].		Replay Window as specified in Section 3.3.2 of the SRTP standard
			[RFC3711].
	o KD Rate (1 octet) - SRTP Key Derivation Rate as specified in		o KD Rate (1 octet) - SRTP Key Derivation Rate as specified in
	Section 4.3.1, second paragraph of the standard [RFC3711]. KD		Section 4.3.1, second paragraph of the standard [RFC3711]. KD
	Rate is an integer that is greater than or equal to zero. The		Rate is an integer that is greater than or equal to zero. The
	SRTP "packet index" of an outgoing or incoming SRTP packet is		SRTP "packet index" of an outgoing or incoming SRTP packet is
	computed modulo the KD Rate in cases where the KD Rate is greater		computed modulo the KD Rate in cases where the KD Rate is greater
	than zero. The reader is referred to Sections 3.3.1 and 4.3.1 of		than zero. The reader is referred to Sections 3.3.1 and 4.3.1 of
	the SRTP specification for the definitions of "packet index" and		the SRTP specification for the definitions of "packet index" and
	"Key Derivation Rate".		"Key Derivation Rate".
	o SRTP Lifetime (1 octet) - The SRTP key lifetime is encoded as an		o SRTP Lifetime (1 octet) - The SRTP key lifetime is encoded as an
	integer N to represent a lifetime of 2^N packets, where N cannot		integer N to represent a lifetime of 2^N packets, where N cannot
	exceed the maximum lifetime as specified by the Crypto Suite. A		exceed the maximum lifetime as specified by the Crypto Suite. A
	value of zero signals the SRTP default (N=48).		value of zero signals the SRTP default (N=48). It is recommended
			that SRTP Lifetime be set to the default.
	o SRTCP Lifetime (1 octet) - The SRTCP key lifetime is encoded as an		o SRTCP Lifetime (1 octet) - The SRTCP key lifetime is encoded as an
	integer N to represent a lifetime of 2^N packets, where N cannot		integer N to represent a lifetime of 2^N packets, where N cannot
	exceed the maximum lifetime as specified by the Crypto Suite. A		exceed the maximum lifetime as specified by the Crypto Suite. A
	value of zero signals the SRTP default (N=31).		value of zero signals the SRTP default (N=31). It is recommended
			that SRTCP Lifetime be set to the default.
	o Options (1 octet) - Reading from left to right (big-endian), SRTP		o Options (1 octet) - Reading from left to right (big-endian), SRTP
	is unencrypted when bit 0 is set to '1'. SRTP is unauthenticated		is unencrypted when bit 0 is set to '1'. SRTP is unauthenticated
	when bit 1 is set to '1'. SRTCP is unencrypted when bit 2 is set		when bit 1 is set to '1'. SRTCP is unencrypted when bit 2 is set
	to '1'. EKT is not used when bit 3 is set to '1'. The SSRC, ROC		to '1'. The SSRC, ROC and SEQ are not included and MUST be
	and SEQ are not included and MUST be ignored when bit 4 is set to		ignored when bit 3 is set to '1'.
	'1'.
	o SSRC (2 octets) - Value of the Sender's SSRC when there is a		o SSRC (2 octets) - Value of the Sender's SSRC when there is a
	single sender associated with the KEK and TEK signaled in the SA-		single sender associated with the KEK and TEK signaled in the SA-
	TEK and Key Download payload.		TEK and Key Download payload.
	o Crypto Suite (1 octet) -- The set of parameters that defines the		o Crypto Suite (2 octets) -- The set of parameters that defines the
	SRTP and SRTCP encryption transform, authentication transform, key		SRTP and SRTCP encryption transform, authentication transform, key
	length, and salt length. The values are defined in the Table		length, and salt length. The values are defined in the Table
	2.1-2. Each row in the table defines a suite of parameters. Any		2.4-2. Each row in the table defines a suite of parameters. Any
	parameter can be changed and new parameters added by creating a		parameter can be changed and new parameters added by creating a
	new Crypto Suite, documenting it in an Internet RFC, and		new Crypto Suite, documenting it in an Internet RFC, and
	requesting a Suite Value for it from IANA.		requesting a Suite Value for it from IANA. The lifetimes
			mentioned in the crypto-suites are superseded by the lifetimes
			passed in the fields mentioned above.
	Table 2.1-2: SRTP Crypto Suites		Table 2.4-2: SRTP Crypto Suites
	Suite Master Master Max SRTP Max SRTCP		Suite Master Master Max SRTP Max SRTCP
	Value Cipher Keylen Saltlen Lifetime Lifetime MAC/len		Value Cipher Keylen Saltlen Lifetime Lifetime MAC/len
	----- ------ ------ ------- -------- -------- -------		----- ------ ------ ------- -------- -------- -------
	0 AES-CM 128 112 2^48 2^31 HMAC-SHA1/80		0 AES-CM 128 112 2^48 2^31 HMAC-SHA1/80
	1 AES-CM 128 112 2^48 2^31 HMAC-SHA1/32		1 AES-CM 128 112 2^48 2^31 HMAC-SHA1/32
	2 AES-F8 128 112 2^48 2^31 HMAC-SHA1/80		2 AES-F8 128 112 2^48 2^31 HMAC-SHA1/80
	3 AES-CM 192 112 2^48 2^31 HMAC-SHA1/80		3 AES-CM 192 112 2^48 2^31 HMAC-SHA1/80
	4 AES-CM 192 112 2^48 2^31 HMAC-SHA1/32		4 AES-CM 192 112 2^48 2^31 HMAC-SHA1/32
	5 AES-CM 256 112 2^48 2^31 HMAC-SHA1/80		5 AES-CM 256 112 2^48 2^31 HMAC-SHA1/80
	skipping to change at page 13, line 31 ¶		skipping to change at page 13, line 45 ¶
	Internet Draft document [I-D.mcgrew-srtp-big-aes]. In the vast		Internet Draft document [I-D.mcgrew-srtp-big-aes]. In the vast
	majority of SRTP applications, the BIG AES values SHOULD NOT be		majority of SRTP applications, the BIG AES values SHOULD NOT be
	used since they do not increase security as a practical matter but		used since they do not increase security as a practical matter but
	could diminish interoperability, see Section 7 of the Big AES I-D.		could diminish interoperability, see Section 7 of the Big AES I-D.
	o SPI (2 octets) - The value of the security parameter index that		o SPI (2 octets) - The value of the security parameter index that
	identifies this security association between the GCKS and the		identifies this security association between the GCKS and the
	group member.		group member.
	o SSRC (1 octet) - The value of the SRTP SSRC; this attribute MUST		o SSRC (1 octet) - The value of the SRTP SSRC; this attribute MUST
	be present when bit 4 of Options is set to '1' but MUST be ignored		be present when bit 3 of Options is cleared ('0') but MUST be
	otherwise.		ignored otherwise.
	o ROC (4 octets) - The current value of the SRTP rollover counter		o ROC (4 octets) - The current value of the SRTP rollover counter
	(ROC); this attribute value MUST be present when bit 4 of Options		(ROC); this attribute value MUST be present when bit 3 of Options
	is set to '1' but MUST be ignored otherwise.		is cleared ('1') but MUST be ignored otherwise.
	o SEQ (2 octets) - The current value of the SRTP sequence number;		o SEQ (2 octets) - The current value of the SRTP sequence number;
	this attribute MUST be present when bit 4 of Options is set to '0'		this attribute MUST be present when bit 3 of Options is cleared
	but MUST be ignored otherwise.		('0') but MUST be ignored otherwise.
	o MKI (variable) - An SRTP Master Key Indicator (MKI) SHALL appear		o MKI Length(variable) - An SRTP Master Key Indicator (MKI) SHALL
	in SRTP packets when this attribute is present. As defined in		appear in SRTP packets when this attribute is present. As defined
	Section 3 of RFC 3711 [RFC3711], the maximum MKI length is 128		in Section 3 of RFC 3711 [RFC3711], the maximum MKI length is 128
	(bytes) though a smaller length of one or two bytes IS		(bytes) though a smaller length of one or two bytes IS
	RECOMMENDED. The MKI Length attribute MUST be present when an MKI		RECOMMENDED. The MKI Length attribute MUST be present when an MKI
	attribute is given.		attribute is given. It is RECOMMENDED that the MKI Length be zero
			(i.e., the MKI is not being used) unless there is a compelling
			reason to change SRTP master keys for a particular source.
	2.4. EKT SA-TEK Definitions		2.5. EKT SA-TEK Definitions
	EKT is an abbreviation for "encrypted key transport", which carries		EKT is an abbreviation for "encrypted key transport", which carries
	an SRTP master key, SEQ and ROC in an SRTCP packet. As described		an SRTP master key, SEQ and ROC in an SRTCP packet. As described
	above, these values are generated internally to SRTP, and a central		above, these values are generated internally to SRTP, and a central
	GCKS typically cannot obtain these values and the SSRC when it has no		GCKS typically cannot obtain these values and the SSRC when it has no
	interface to the SRTP sender. In this case, EKT is RECOMMENDED as a		interface to the SRTP sender. In this case, EKT is RECOMMENDED as a
	means to correctly initialize an SRTP receiver with the SSRC, SEQ,		means to correctly initialize an SRTP receiver with the SSRC, SEQ,
	ROC and SRTP master key. In this case, GDOI-SRTP serves to		ROC and SRTP master key. In this case, GDOI-SRTP serves to
	initialize the EKT system in a GDOI member by providing EKT		initialize the EKT system in a GDOI member by providing EKT
	parameters and a key called the "EKT key", which is used to encrypt		parameters and a key called the "EKT key", which is used to encrypt
	the SRTP master key in the SRTCP packet. Thus, the security		the SRTP master key in the SRTCP packet. Thus, the security
	association between the GCKS and GDOI member establishes and		association between the GCKS and GDOI member establishes and
	maintains an EKT key.		maintains an EKT key.
	The EKT identifying information and parameters are shown in Figure		The EKT identifying information and parameters are shown in Figure
	2.4-1.		2.5-1.
	Figure 2.4-1: EKT-TEK		Figure 2.5-1: EKT-TEK
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! DST ID Type ! DST ID Port !DST ID Data Len!		! DST ID Type ! DST ID Port !DST ID Data Len!
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! DST Identification Data ~		! DST Identification Data ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
	! EKT Cipher ! SPI !		! EKT Cipher ! SPI !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Each of the fields of Figure 2.3-1 is defined as follows.		Each of the fields of Figure 2.5-1 is defined as follows.
	o DST ID Type (1 octet) -- Value describing the identity information		o DST ID Type (1 octet) -- Value describing the identity information
	found in the DST Identification Data field. Defined values are		found in the DST Identification Data field. Defined values are
	specified by the IPSEC Identification Type section in the IANA		specified by the IPSEC Identification Type section in the IANA
	isakmpd-registry [ISAKMP-REG].		isakmpd-registry [ISAKMP-REG].
	o DST ID Port (2 octets) -- Value specifying a port associated with		o DST ID Port (2 octets) -- Value specifying a port associated with
	the source Id. A value of zero means that the DST ID Port field		the source Id. A value of zero means that the DST ID Port field
	should be ignored.		should be ignored.
	skipping to change at page 15, line 12 ¶		skipping to change at page 15, line 27 ¶
	o DST Identification Data (variable length) -- Value, as indicated		o DST Identification Data (variable length) -- Value, as indicated
	by the DST ID Type.		by the DST ID Type.
	o EKT Cipher (1 octet) - Value specifying the cipher and mode used		o EKT Cipher (1 octet) - Value specifying the cipher and mode used
	by EKT for the EKT key, which is carried in a GDOI Key Download		by EKT for the EKT key, which is carried in a GDOI Key Download
	payload. The following table correlates each EKT Cipher Suite		payload. The following table correlates each EKT Cipher Suite
	[I-D.mcgrew-srtp-ekt] with a Suite Value. New EKT Cipher Suites		[I-D.mcgrew-srtp-ekt] with a Suite Value. New EKT Cipher Suites
	MAY be added when documented by an Internet RFC and once IANA		MAY be added when documented by an Internet RFC and once IANA
	assigns a Suite Value to that Cipher Suite.		assigns a Suite Value to that Cipher Suite.
	Table 2.1-3: EKT Cipher Suites		Table 2.5-2: EKT Cipher Suites
	EKT Cipher Suite		EKT Cipher Suite
	Suite Value		Suite Value
	------ -----		------ -----
	RESERVED 0		RESERVED 0
	AES_128 1		AES_128 1
	AESKW_128 2		AESKW_128 2
	AESKW_196 3		AESKW_196 3
	AESKW_256 4		AESKW_256 4
	RESERVED 5-127		RESERVED 5-127
	o EKT SPI (1 octet) - The EKT security parameter index, which		o EKT SPI (1 octet) - The EKT security parameter index, which
	identifies the EKT security association between the GCKS and the		identifies the EKT security association between the GCKS and the
	GDOI member.		GDOI member.
	2.5. SRTP Key Download		2.6. SRTP Key Download
	The SRTP SA-TEK Crypto Suite of Table 2.3-1 defines two keys, the		The SRTP SA-TEK Crypto Suite of Table 2.4-2 defines both the SRTP
	SRTP master key and master salt key. These two keys are concatenated		master key and master salt. These two values are concatenated, with
	with the SRTP master key followed by the SRTP master salt in a Key		the SRTP master key being followed by the SRTP master salt, in a Key
	Download (KD) payload's TEK_ALGORITHM_KEY attribute.		Download (KD) payload's TEK_ALGORITHM_KEY attribute.
	When EKT is used, there is no KD payload corresponding to the SRTP		When EKT is used, there is no KD payload corresponding to the SRTP
	SA-TEK. Instead, the KD payload carries the EKT key as defined by		SA-TEK. Instead, the KD payload carries the EKT key as defined by
	the EKT SA-TEK EKT Cipher.		the EKT SA-TEK EKT Cipher.
	3. NAT Considerations		3. NAT Considerations
	Transport addresses are carried in the SA-TEK payloads and this		Transport addresses are carried in the SA-TEK payloads and this
	contradicts recommendations for application-layer signaling through		contradicts recommendations for application-layer signaling through
	network address translators (NATs) [RFC2663][RFC3235]. The SA-TEK		network address translators (NATs) [RFC2663][RFC3235]. The SA-TEK
	destination IP address and port, however, are multicast addresses		destination IP address and port, however, are multicast addresses
	which are not re-written by a NAT. The source address, however,		which are not re-written by a NAT. The source address, however,
	might be re-written on outgoing multicast packets		might be re-written on outgoing multicast packets
	[I-D.wing-behave-multicast].		[I-D.wing-behave-multicast].
	If the SA TEK SRC ID type of Figure 2.3-1 is an IP address and if		If the SA TEK SRC ID type of Figure 2.4-1 is an IP address and if
	there is an outgoing NAT that re-writes the source IP address field		there is an outgoing NAT that re-writes the source IP address field
	of outgoing packets, then there will likely be a discrepancy between		of outgoing packets, then there will likely be a discrepancy between
	the source address in the IP packet and the SRC Identification Data		the source address in the IP packet and the SRC Identification Data
	field of Figure 2.3-1. It is therefore RECOMMENDED that SRC ID Type		field of Figure 2.4-1. It is therefore RECOMMENDED that SRC ID Type
	be ID_FQDN [ISAKMP-REG] whenever there is network address translation		be ID_FQDN [ISAKMP-REG] whenever there is network address translation
	present on the network of the multicast source.		present on the network of the multicast source.
	4. Security Considerations		4. Security Considerations
	The security of GDOI and its payloads is discussed in Section 6 of		The security of GDOI and its payloads is discussed in Section 6 of
	the GDOI specification [RFC3547]. The security of SRTP and its		the GDOI specification [RFC3547]. The security of SRTP and its
	parameter settings is discussed in Section 9 of the SRTP		parameter settings is discussed in Section 9 of the SRTP
	specification[RFC3711]. There are some additional risks in GDOI and		specification[RFC3711]. There are some additional risks in GDOI and
	SRTP that are considered here.		SRTP that are considered here.
	skipping to change at page 17, line 27 ¶		skipping to change at page 17, line 27 ¶
	SRTP specifies that the SSRC is used in the AES counter mode and f8		SRTP specifies that the SSRC is used in the AES counter mode and f8
	initialization vectors (IV) to prevent counter reuse. RFC 3711		initialization vectors (IV) to prevent counter reuse. RFC 3711
	states that key management "SHOULD" install a unique SSRC. GDOI		states that key management "SHOULD" install a unique SSRC. GDOI
	relaxes this requirement since SSRCs collide. It is also difficult		relaxes this requirement since SSRCs collide. It is also difficult
	to support an unchanged RTP module in a "bump-in-the-stack" SRTP		to support an unchanged RTP module in a "bump-in-the-stack" SRTP
	configuration. Instead of depending on SSRC uniqueness, IT IS		configuration. Instead of depending on SSRC uniqueness, IT IS
	RECOMMENDED that the GDOI SA-TEK SHOULD provide a unique SRTP master		RECOMMENDED that the GDOI SA-TEK SHOULD provide a unique SRTP master
	key for each sender.		key for each sender.
	To ensure SRTP master key uniqueness among senders to an SRTP		To ensure SRTP master key uniqueness among senders to an SRTP
	session, SA-TEK SRC Identification Data (Figure 2.1.1) MUST NOT		session, SA-TEK SRC Identification Data (Figure 2.4.1) MUST NOT
	signal a group of senders sharing a key. GDOI specifies a means for		signal a group of senders sharing a key. GDOI specifies a means for
	sharing a traffic encrypting key (TEK) among senders, but a GDOI TEK		sharing a traffic encrypting key (TEK) among senders, but a GDOI TEK
	is an SRTP master key and this specification RECOMMENDS that a TEK		is an SRTP master key and this specification RECOMMENDS that a TEK
	SHOULD NOT be shared among SRTP sources.		SHOULD NOT be shared among SRTP sources.
	4.2. Enable Distributed Key Management		4.2. Enable Distributed Key Management
	In many cases, SRTP sources are not co-located with a GCKS. This is		In many cases, SRTP sources are not co-located with a GCKS. This is
	one possible configuration in a large scale "video pump", for		one possible configuration in a large scale "video pump", for
	example, that is specialized to a purpose other than key management.		example, that is specialized to a purpose other than key management.
	skipping to change at page 21, line 21 ¶		skipping to change at page 21, line 21 ¶
	[RFC3547], http://www.iana.org/assignments/gdoi-payloads",		[RFC3547], http://www.iana.org/assignments/gdoi-payloads",
	2003.		2003.
	[I-D.mcgrew-srtp-big-aes]		[I-D.mcgrew-srtp-big-aes]
	McGrew, D., "The use of AES-192 and AES-256 in Secure		McGrew, D., "The use of AES-192 and AES-256 in Secure
	RTP", draft-mcgrew-srtp-big-aes-00 (work in progress),		RTP", draft-mcgrew-srtp-big-aes-00 (work in progress),
	April 2006.		April 2006.
	[I-D.mcgrew-srtp-ekt]		[I-D.mcgrew-srtp-ekt]
	McGrew, D., "Encrypted Key Transport for Secure RTP",		McGrew, D., "Encrypted Key Transport for Secure RTP",
	draft-mcgrew-srtp-ekt-01 (work in progress), June 2006.		draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.
	[ISAKMP-REG]		[ISAKMP-REG]
	"FROM RFC 2407 and RFC 2408 Magic Numbers for ISAKMP		"FROM RFC 2407 and RFC 2408 Magic Numbers for ISAKMP
	Protocol,		Protocol,
	http://www.iana.org/assignments/isakmp-registry",		http://www.iana.org/assignments/isakmp-registry",
	September 2006.		September 2006.
	[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, March 1997.
End of changes. 52 change blocks.
	108 lines changed or deleted		136 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/