< draft-ietf-avt-dtls-srtp-05.txt		draft-ietf-avt-dtls-srtp-06.txt >
	Network Working Group D. McGrew		Network Working Group D. McGrew
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track E. Rescorla		Intended status: Standards Track E. Rescorla
	Expires: March 15, 2009 RTFM, Inc.		Expires: May 2, 2009 RTFM, Inc.
	September 11, 2008		October 29, 2008
	Datagram Transport Layer Security (DTLS) Extension to Establish Keys for		Datagram Transport Layer Security (DTLS) Extension to Establish Keys for
	Secure Real-time Transport Protocol (SRTP)		Secure Real-time Transport Protocol (SRTP)
	draft-ietf-avt-dtls-srtp-05.txt		draft-ietf-avt-dtls-srtp-06.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 36 ¶		skipping to change at page 1, line 36 ¶
	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 March 15, 2009.		This Internet-Draft will expire on May 2, 2009.
	Abstract		Abstract
	This document describes a Datagram Transport Layer Security (DTLS)		This document describes a Datagram Transport Layer Security (DTLS)
	extension to establish keys for secure RTP (SRTP) and secure RTP		extension to establish keys for secure RTP (SRTP) and secure RTP
	Control Protocol (SRTCP) flows. DTLS keying happens on the media		Control Protocol (SRTCP) flows. DTLS keying happens on the media
	path, independent of any out-of-band signalling channel present.		path, independent of any out-of-band signalling channel present.
	Table of Contents		Table of Contents
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	The Secure RTP profile (SRTP) [RFC3711] can provide confidentiality,		The Secure RTP profile (SRTP) [RFC3711] can provide confidentiality,
	message authentication, and replay protection to RTP data and RTP		message authentication, and replay protection to RTP data and RTP
	Control (RTCP) traffic. SRTP does not provide key management		Control (RTCP) traffic. SRTP does not provide key management
	functionality, but instead depends on external key management to		functionality, but instead depends on external key management to
	exchange secret master keys, and to negotiate the algorithms and		exchange secret master keys, and to negotiate the algorithms and
	parameters for use with those keys.		parameters for use with those keys.
	Datagram Transport Layer Security (DTLS) [RFC4347] is a channel		Datagram Transport Layer Security (DTLS) [RFC4347] is a channel
	security protocol that offers integrated key management, parameter		security protocol that offers integrated key management, parameter
	negotiation, and secure data transfer. Because DTLS's data transfer		negotiation, and secure data transfer. Because DTLS data transfer
	protocol is generic, it is less highly optimized for use with RTP		protocol is generic, it is less highly optimized for use with RTP
	than is SRTP, which has been specifically tuned for that purpose.		than is SRTP, which has been specifically tuned for that purpose.
	This document describes DTLS-SRTP, an SRTP extension for DTLS which		This document describes DTLS-SRTP, an SRTP extension for DTLS which
	combine the performance and encryption flexibility benefits of SRTP		combines the performance and encryption flexibility benefits of SRTP
	with the flexibility and convenience of DTLS's integrated key and		with the flexibility and convenience of DTLS integrated key and
	association management. DTLS-SRTP can be viewed in two equivalent		association management. DTLS-SRTP can be viewed in two equivalent
	ways: as a new key management method for SRTP, and a new RTP-		ways: as a new key management method for SRTP, and a new RTP-
	specific data format for DTLS.		specific data format for DTLS.
	The key points of DTLS-SRTP are that:		The key points of DTLS-SRTP are that:
	o application data is protected using SRTP,		o application data is protected using SRTP,
	o the DTLS handshake is used to establish keying material,		o the DTLS handshake is used to establish keying material,
	algorithms, and parameters for SRTP,		algorithms, and parameters for SRTP,
	o a DTLS extension used to negotiate SRTP algorithms, and		o a DTLS extension is used to negotiate SRTP algorithms, and
	o other DTLS record layer content types are protected using the		o other DTLS record layer content types are protected using the
	ordinary DTLS record format.		ordinary DTLS record format.
	The remainder of this memo is structured as follows. Section 2		The remainder of this memo is structured as follows. Section 2
	describes conventions used to indicate normative requirements.		describes conventions used to indicate normative requirements.
	Section 3 provides an overview of DTLS-SRTP operation. Section 4		Section 3 provides an overview of DTLS-SRTP operation. Section 4
	specifies the DTLS extensions, while Section 5 discusses how RTP and		specifies the DTLS extensions, while Section 5 discusses how RTP and
	RTCP are transported over a DTLS-SRTP channel. Section 6 describes		RTCP are transported over a DTLS-SRTP channel. Section 6 describes
	use with multi-party sessions. Section 7 and Section 9 describe		use with multi-party sessions. Section 7 and Section 9 describe
	Security and IANA considerations.		Security and IANA considerations.
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	performance of DTLS, but may cause problems when RTCP and RTP are		performance of DTLS, but may cause problems when RTCP and RTP are
	subject to different network treatment (e.g., for bandwidth		subject to different network treatment (e.g., for bandwidth
	reservation or scheduling reasons.)		reservation or scheduling reasons.)
	Between a single pair of participants, there may be multiple media		Between a single pair of participants, there may be multiple media
	sessions. There MUST be a separate DTLS-SRTP session for each		sessions. There MUST be a separate DTLS-SRTP session for each
	distinct pair of source and destination ports used by a media session		distinct pair of source and destination ports used by a media session
	(though the sessions can share a single DTLS session and hence		(though the sessions can share a single DTLS session and hence
	amortize the initial public key handshake!).		amortize the initial public key handshake!).
	A DTLS-SRTP session MAY be indicated by an external signaling		A DTLS-SRTP session may be indicated by an external signaling
	protocol like SIP. When the signaling exchange is integrity-		protocol like SIP. When the signaling exchange is integrity-
	protected (e.g when SIP Identity protection via digital signatures is		protected (e.g when SIP Identity protection via digital signatures is
	used), DTLS-SRTP can leverage this integrity guarantee to provide		used), DTLS-SRTP can leverage this integrity guarantee to provide
	complete security of the media stream. A description of how to		complete security of the media stream. A description of how to
	indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to		indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to
	authenticate the endpoints using fingerprints can be found in		authenticate the endpoints using fingerprints can be found in
	[I-D.ietf-sip-dtls-srtp-framework].		[I-D.ietf-sip-dtls-srtp-framework].
	In a naive implementation, when there are multiple media sessions,		In a naive implementation, when there are multiple media sessions,
	there is a new DTLS session establishment (complete with public key		there is a new DTLS session establishment (complete with public key
	cryptography) for each media channel. For example, a videophone may		cryptography) for each media channel. For example, a videophone may
	be sending both an audio stream and a video stream, each of which		be sending both an audio stream and a video stream, each of which
	would use a separate DTLS session establishment exchange, which would		would use a separate DTLS session establishment exchange, which would
	proceed in parallel. As an optimization, the DTLS-SRTP		proceed in parallel. As an optimization, the DTLS-SRTP
	implementation SHOULD use the following strategy: a single DTLS		implementation SHOULD use the following strategy: a single DTLS
	association is established, and all other DTLS associations wait		association is established, and all other DTLS associations wait
	until that connection is established before proceeding with their		until that connection is established before proceeding with their
	handshakes establishment exchanges. This strategy allows the later		handshakes. This strategy allows the later sessions to use DTLS
	sessions to use DTLS session resumption, which allows the		session resumption, which allows the amortization of the expensive
	amortization of the expensive public key cryptography operations over		public key cryptography operations over multiple DTLS handshakes.
	multiple DTLS handshakes.
	The SRTP keys used to protect packets originated by the client are		The SRTP keys used to protect packets originated by the client are
	distinct from the SRTP keys used to protect packets originated by the		distinct from the SRTP keys used to protect packets originated by the
	server. All of the RTP sources originating on the client for the		server. All of the RTP sources originating on the client for the
	same channel use the same SRTP keys, and similarly, all of the RTP		same channel use the same SRTP keys, and similarly, all of the RTP
	sources originating on the server for the same channel use the same		sources originating on the server for the same channel use the same
	SRTP keys. The SRTP implementation MUST ensure that all of the SSRC		SRTP keys. The SRTP implementation MUST ensure that all of the SSRC
	values for all of the RTP sources originating from the same device		values for all of the RTP sources originating from the same device
	over the same channel are distinct, in order to avoid the "two-time		over the same channel are distinct, in order to avoid the "two-time
	pad" problem (as described in Section 9.1 of RFC 3711). Note that		pad" problem (as described in Section 9.1 of RFC 3711). Note that
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 47 ¶
	port quartets) which use independent keying material even if an SSRC		port quartets) which use independent keying material even if an SSRC
	collision occurs.		collision occurs.
	4. DTLS Extensions for SRTP Key Establishment		4. DTLS Extensions for SRTP Key Establishment
	4.1. The use_srtp Extension		4.1. The use_srtp Extension
	In order to negotiate the use of SRTP data protection, clients		In order to negotiate the use of SRTP data protection, clients
	include an extension of type "use_srtp" in the DTLS extended client		include an extension of type "use_srtp" in the DTLS extended client
	hello. This extension MUST only be used when the data being		hello. This extension MUST only be used when the data being
	transported is RTP and RTCP [RFC3550]. The "extension_data" field of		transported is RTP or RTCP [RFC3550]. The "extension_data" field of
	this extension contains the list of acceptable SRTP protection		this extension contains the list of acceptable SRTP protection
	profiles, as indicated below.		profiles, as indicated below.
	Servers that receive an extended hello containing a "use_srtp"		Servers that receive an extended hello containing a "use_srtp"
	extension can agree to use SRTP by including an extension of type		extension can agree to use SRTP by including an extension of type
	"use_srtp", with the chosen protection profile in the extended server		"use_srtp", with the chosen protection profile in the extended server
	hello. This process is shown below.		hello. This process is shown below.
	Client Server		Client Server
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 26 ¶
	Certificate*		Certificate*
	ClientKeyExchange		ClientKeyExchange
	CertificateVerify*		CertificateVerify*
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished -------->		Finished -------->
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<-------- Finished		<-------- Finished
	SRTP packets <-------> SRTP packets		SRTP packets <-------> SRTP packets
	Note that '*' indicates messages which are not always sent in DTLS.		Note that '*' indicates messages which are not always sent in DTLS.
	The CertificateRequest, client Certificate, and CertificateVerify		The CertificateRequest, client and server Certificates, and
	will be sent in DTLS-SRTP.		CertificateVerify will be sent in DTLS-SRTP.
	Once the "use_srtp" extension is negotiated, the RTP or RTCP		Once the "use_srtp" extension is negotiated, the RTP or RTCP
	application data is protected solely using SRTP. Application data is		application data is protected solely using SRTP. Application data is
	never sent in DTLS record-layer "application_data" packets. Rather,		never sent in DTLS record-layer "application_data" packets. Rather,
	complete RTP or RTCP packets are passed to the DTLS stack which		complete RTP or RTCP packets are passed to the DTLS stack which
	passes them to the SRTP stack which protects them appropriately.		passes them to the SRTP stack which protects them appropriately.
	Note that if RTP/RTCP multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] is		Note that if RTP/RTCP multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] is
	in use, this means that RTP and RTCP packets may both be passed to		in use, this means that RTP and RTCP packets may both be passed to
	the DTLS stack. Because the DTLS layer does not process the packets,		the DTLS stack. Because the DTLS layer does not process the packets,
	it does not need to distinguish them. The SRTP stack can use the		it does not need to distinguish them. The SRTP stack can use the
	procedures of [I-D.ietf-avt-rtp-and-rtcp-mux] to distinguish RTP from		procedures of [I-D.ietf-avt-rtp-and-rtcp-mux] to distinguish RTP from
	RTCP.		RTCP.
	When the "use_srtp" extension is in effect, implementations MUST NOT		When the "use_srtp" extension is in effect, implementations must not
	place more than one application data "record" per datagram. (This is		place more than one application data "record" per datagram. (This is
	only meaningful from the perspective of DTLS because SRTP is		only meaningful from the perspective of DTLS because SRTP is
	inherently oriented towards one payload per packet, but is stated		inherently oriented towards one payload per packet, but is stated
	purely for clarification.)		purely for clarification.)
	Records of type other than "application_data" MUST use ordinary DTLS		Data other than RTP/RTCP (i.e., TLS control messages) MUST use
	framing and must be placed in separate datagrams from SRTP data.		ordinary DTLS framing and MUST be placed in separate datagrams from
			SRTP data.
	4.1.1. use_srtp Extension Definition		4.1.1. use_srtp Extension Definition
	The client MUST fill the extension_data field of the "use_srtp"		The client MUST fill the extension_data field of the "use_srtp"
	extension with an UseSRTPData value (see Section 9 for the		extension with an UseSRTPData value (see Section 9 for the
	registration):		registration):
	uint8 SRTPProtectionProfile[2];		uint8 SRTPProtectionProfile[2];
	struct {		struct {
	skipping to change at page 9, line 6 ¶		skipping to change at page 9, line 6 ¶
	maximum_lifetime: 2^31		maximum_lifetime: 2^31
	auth_function: HMAC-SHA1		auth_function: HMAC-SHA1
	auth_key_length: 160		auth_key_length: 160
	auth_tag_length: 32		auth_tag_length: 32
	RTCP auth_tag_length: 80		RTCP auth_tag_length: 80
	With all of these SRTP Parameter profiles, the following SRTP options		With all of these SRTP Parameter profiles, the following SRTP options
	are in effect:		are in effect:
	o The TLS PseudoRandom Function (PRF) is used to generate keys to		o The TLS PseudoRandom Function (PRF) is used to generate keys to
	feed into the SRTP KDF. When DTLS 1.2 is in use, the PRF is the		feed into the SRTP KDF. When DTLS 1.2 [I-D.ietf-tls-rfc4347-bis]
	one associated with the cipher suite.		is in use, the PRF is the one associated with the cipher suite.
			Note that this specification is compatible with DTLS 1.0 or DTLS
			1.2
	o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are		o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are
	not re-derived based on the SRTP sequence number.		not re-derived based on the SRTP sequence number.
	o The key derivation procedures from Section 4.3 with the AES-CM PRF		o The key derivation procedures from Section 4.3 with the AES-CM PRF
	from RFC 3711 is used.		from RFC 3711 is used.
	o For all other parameters, (in particular, SRTP replay window size		o For all other parameters, (in particular, SRTP replay window size
	and FEC order) the default values are used.		and FEC order) the default values are used.
	If values other than the defaults for these parameters are required,		If values other than the defaults for these parameters are required,
	they can be enabled by writing a separate specification specifying		they can be enabled by writing a separate specification specifying
	SDP syntax to signal them.		SDP syntax to signal them.
	Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection		Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection
	Profiles between the DTLS-SRTP session that protects an RTP flow and		Profiles between the DTLS-SRTP session that protects an RTP flow and
	the DTLS-SRTP session that protects the associated RTCP flow (in		the DTLS-SRTP session that protects the associated RTCP flow (in
	those case in which the RTP and RTCP are not multiplexed over a		those case in which the RTP and RTCP are not multiplexed over a
	common port). In particular, identical ciphers SHOULD be used.		common port). In particular, identical ciphers SHOULD be used.
	New SRTPProtectionProfile values must be defined by RFC 5226		New SRTPProtectionProfile values must be defined according to the
	Specification Required. See Section 9 for IANA Considerations.		"Specification Required" policy as defined by RFC 5226 [RFC5226].
			See Section 9 for IANA Considerations.
	4.1.3. srtp_mki value		4.1.3. srtp_mki value
	The srtp_mki value MAY be used to indicate the capability and desire		The srtp_mki value MAY be used to indicate the capability and desire
	to use the SRTP Master Key Indicator (MKI) field in the SRTP and		to use the SRTP Master Key Indicator (MKI) field in the SRTP and
	SRTCP packets. The MKI field indicates to an SRTP receiver which key		SRTCP packets. The MKI field indicates to an SRTP receiver which key
	was used to protect the packet that contains that field. The		was used to protect the packet that contains that field. The
	srtp_mki field contains the value of the SRTP MKI which is associated		srtp_mki field contains the value of the SRTP MKI which is associated
	with the SRTP master keys derived from this handshake. Each SRTP		with the SRTP master keys derived from this handshake. Each SRTP
	session MUST have exactly one master key that is used to protect		session MUST have exactly one master key that is used to protect
	skipping to change at page 9, line 50 ¶		skipping to change at page 10, line 4 ¶
	Upon receipt of a "use_srtp" extension containing a "srtp_mki" field,		Upon receipt of a "use_srtp" extension containing a "srtp_mki" field,
	the server MUST either (assuming it accepts the extension at all):		the server MUST either (assuming it accepts the extension at all):
	1. include a matching "srtp_mki" value in its "use_srtp" extension		1. include a matching "srtp_mki" value in its "use_srtp" extension
	to indicate that it will make use of the MKI, or		to indicate that it will make use of the MKI, or
	2. return an empty "srtp_mki" value to indicate that it cannot make		2. return an empty "srtp_mki" value to indicate that it cannot make
	use of the MKI.		use of the MKI.
	If the client detects a nonzero-length MKI in the server's response		If the client detects a nonzero-length MKI in the server's response
	that is different than the one the client offered MUST abort the		that is different than the one the client offered then the client
	handshake and SHOULD send an invalid_parameter alert. If the client		MUST abort the handshake and SHOULD send an invalid_parameter alert.
	and server agree on an MKI, all SRTP packets protected under the new		If the client and server agree on an MKI, all SRTP packets protected
	security parameters MUST contain that MKI.		under the new security parameters MUST contain that MKI.
	4.2. Key Derivation		4.2. Key Derivation
	When SRTP mode is in effect, different keys are used for ordinary		When SRTP mode is in effect, different keys are used for ordinary
	DTLS record protection and SRTP packet protection. These keys are		DTLS record protection and SRTP packet protection. These keys are
	generated using a TLS extractor [I-D.ietf-tls-extractor] to generate		generated using a TLS extractor [I-D.ietf-tls-extractor] to generate
	2 * (SRTPSecurityParams.master_key_len +		2 * (SRTPSecurityParams.master_key_len +
	SRTPSecurityParams.master_salt_len) bytes of data, which are assigned		SRTPSecurityParams.master_salt_len) bytes of data, which are assigned
	as shown below. The per-association context value is empty.		as shown below. The per-association context value is empty.
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	| | +------+ keys		| | +------+ keys
	| |		| |
	| | +------+ SRTCP		| | +------+ SRTCP
	| +--->|SRTCP |-> server		| +--->|SRTCP |-> server
	+----->| KDF | write		+----->| KDF | write
	+------+ keys		+------+ keys
	Figure 1: The derivation of the SRTP keys.		Figure 1: The derivation of the SRTP keys.
	When both RTCP and RTP use the same source and destination ports,		When both RTCP and RTP use the same source and destination ports,
	then both the SRTP and SRTCP keys are need. Otherwise, there are two		then both the SRTP and SRTCP keys are needed. Otherwise, there are
	DTLS-SRTP sessions, one of which protects the RTP packets and one of		two DTLS-SRTP sessions, one of which protects the RTP packets and one
	which protects the RTCP packets; each DTLS-SRTP session protects the		of which protects the RTCP packets; each DTLS-SRTP session protects
	part of an SRTP session that passes over a single source/destination		the part of an SRTP session that passes over a single source/
	transport address pair, as shown in Figure 2. When a DTLS-SRTP		destination transport address pair, as shown in Figure 2. When a
	session is protecting RTP, the SRTCP keys derived from the DTLS		DTLS-SRTP session is protecting RTP, the SRTCP keys derived from the
	handshake are not needed and are discarded. When a DTLS-SRTP session		DTLS handshake are not needed and are discarded. When a DTLS-SRTP
	is protecting RTCP, the SRTP keys derived from the DTLS handshake are		session is protecting RTCP, the SRTP keys derived from the DTLS
	not needed and are discarded.		handshake are not needed and are discarded.
	Client Server		Client Server
	(Sender) (Receiver)		(Sender) (Receiver)
	(1) <----- DTLS ------> src/dst = a/b and b/a		(1) <----- DTLS ------> src/dst = a/b and b/a
	------ SRTP ------> src/dst = a/b, uses client write keys		------ SRTP ------> src/dst = a/b, uses client write keys
	(2) <----- DTLS ------> src/dst = c/d and d/c		(2) <----- DTLS ------> src/dst = c/d and d/c
	------ SRTCP -----> src/dst = c/d, uses client write keys		------ SRTCP -----> src/dst = c/d, uses client write keys
	<----- SRTCP ------ src/dst = d/c, uses server write keys		<----- SRTCP ------ src/dst = d/c, uses server write keys
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	first followed by the reception process.		first followed by the reception process.
	Within each RTP session, SRTP processing MUST NOT take place before		Within each RTP session, SRTP processing MUST NOT take place before
	the DTLS handshake completes.		the DTLS handshake completes.
	5.1.1. Transmission		5.1.1. Transmission
	DTLS and TLS define a number of record content types. In ordinary		DTLS and TLS define a number of record content types. In ordinary
	TLS/DTLS, all data is protected using the same record encoding and		TLS/DTLS, all data is protected using the same record encoding and
	mechanisms. When the mechanism described in this document is in		mechanisms. When the mechanism described in this document is in
	effect, this is modified so that data of type "application_data"		effect, this is modified so that data written by upper level protocol
	(used to transport data traffic) is encrypted using SRTP rather than		clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP
	the standard TLS record encoding.		rather than the standard TLS record encoding.
	When a user of DTLS wishes to send an RTP packet in SRTP mode it		When a user of DTLS wishes to send an RTP packet in SRTP mode it
	delivers it to the DTLS implementation as a single write of type		delivers it to the DTLS implementation as an ordinary application
	"application_data". The DTLS implementation then invokes the		data write (e.g., SSL_write()). The DTLS implementation then invokes
	processing described in RFC 3711 Sections 3 and 4. The resulting		the processing described in RFC 3711 Sections 3 and 4. The resulting
	SRTP packet is then sent directly on the wire as a single datagram		SRTP packet is then sent directly on the wire as a single datagram
	with no DTLS framing. This provides an encapsulation of the data		with no DTLS framing. This provides an encapsulation of the data
	that conforms to and interoperates with SRTP. Note that the RTP		that conforms to and interoperates with SRTP. Note that the RTP
	sequence number rather than the DTLS sequence number is used for		sequence number rather than the DTLS sequence number is used for
	these packets.		these packets.
	5.1.2. Reception		5.1.2. Reception
	When DTLS-SRTP is used to protect an RTP session, the RTP receiver		When DTLS-SRTP is used to protect an RTP session, the RTP receiver
	needs to demultiplex packets that are arriving on the RTP port.		needs to demultiplex packets that are arriving on the RTP port.
	skipping to change at page 15, line 13 ¶		skipping to change at page 15, line 13 ¶
	SSRC to that association.		SSRC to that association.
	4. If the decryption and verification fails, then the packet is		4. If the decryption and verification fails, then the packet is
	silently discarded.		silently discarded.
	5. When a DTLS-SRTP association is closed (for instance because the		5. When a DTLS-SRTP association is closed (for instance because the
	fork is abandoned) its entries MUST be removed from the mapping		fork is abandoned) its entries MUST be removed from the mapping
	table.		table.
	The average cost of this algorithm for a single SSRC is the		The average cost of this algorithm for a single SSRC is the
	decryption and verification time of a single packet times the number		decryption and verification time of a single packet times the number
	valid DTLS-SRTP associations corresponding to a single receiving port		of valid DTLS-SRTP associations corresponding to a single receiving
	on the host. In practice, this means the number of forks, so in the		port on the host. In practice, this means the number of forks, so in
	case shown in Figure 4, that would be two. This cost is only		the case shown in Figure 4, that would be two. This cost is only
	incurred once for any given SSRC, since afterwards that SSRC is		incurred once for any given SSRC, since afterwards that SSRC is
	placed in the map table and looked up immediately. As with normal		placed in the map table and looked up immediately. As with normal
	RTP, this algorithm allows new SSRCs to be introduced by the source		RTP, this algorithm allows new SSRCs to be introduced by the source
	at any time. They will automatically be mapped to the correct DTLS		at any time. They will automatically be mapped to the correct DTLS
	association.		association.
	Note that this algorithm explicitly allows multiple SSRCs to be sent		Note that this algorithm explicitly allows multiple SSRCs to be sent
	from the same address/port pair. One way in which this can happen is		from the same address/port pair. One way in which this can happen is
	an RTP translator. This algorithm will automatically assign the		an RTP translator. This algorithm will automatically assign the
	SSRCs to the correct associations. Note that because the SRTP		SSRCs to the correct associations. Note that because the SRTP
	skipping to change at page 19, line 49 ¶		skipping to change at page 19, line 49 ¶
	[RFC5246]:		[RFC5246]:
	enum { use_srtp (??) } ExtensionType;		enum { use_srtp (??) } ExtensionType;
	[[ NOTE: This value needs to be assigned by IANA ]]		[[ NOTE: This value needs to be assigned by IANA ]]
	This extension MUST only be used with DTLS, and not with TLS		This extension MUST only be used with DTLS, and not with TLS
	[RFC4572] which specifies that TLS can be used over TCP but does not		[RFC4572] which specifies that TLS can be used over TCP but does not
	address TCP for RTP/SAVP.		address TCP for RTP/SAVP.
	Section 4.1.2 requires that all SRTPProtectionProfile values be		Section 4.1.2 requires that all SRTPProtectionProfile values be
	defined by RFC 5226 Specification Required. IANA SHOULD create a		defined by RFC 5226 Specification Required. IANA will create/(has
	DTLS SRTPProtectionProfile registry initially populated with values		created) a DTLS SRTPProtectionProfile registry initially populated
	from Section 4.1.2 of this document. Future values MUST be allocated		with values from Section 4.1.2 of this document. Future values MUST
	via Specification Required as described in [RFC5226]		be allocated via the "Specification Required" profile of [RFC5226]
	This specification updates the "Session Description Protocol (SDP)		This specification updates the "Session Description Protocol (SDP)
	Parameters" registry as defined in Appendix B of RFC 4566 [RFC4566].		Parameters" registry as defined in section 8.2.2 of RFC 4566
	Specifically it adds the following values to the table for the		[RFC4566]. Specifically it adds the following values to the table
	"proto" field.		for the "proto" field.
	Type SDP Name Reference		Type SDP Name Reference
	---- ------------------ ---------		---- ------------------ ---------
	proto UDP/TLS/RTP/SAVP [RFC-XXXX]		proto UDP/TLS/RTP/SAVP [RFC-XXXX]
	proto DCCP/TLS/RTP/SAVP [RFC-XXXX]		proto DCCP/TLS/RTP/SAVP [RFC-XXXX]
	proto UDP/TLS/RTP/SAVPF [RFC-XXXX]		proto UDP/TLS/RTP/SAVPF [RFC-XXXX]
	proto DCCP/TLS/RTP/SAVPF [RFC-XXXX]		proto DCCP/TLS/RTP/SAVPF [RFC-XXXX]
	Note to RFC Editor: Please replace RFC-XXXX with the RFC number of		Note to RFC Editor: Please replace RFC-XXXX with the RFC number of
	this specification.		this specification.
	IANA should register/has registered the "EXTRACTOR-dtls_srtp". value		IANA should register/has registered the "EXTRACTOR-dtls_srtp". value
	in the TLS Extractor Label Registry to correspond to this		in the TLS Extractor Label Registry to correspond to this
	specification.		specification.
	10. Acknowledgments		10. Acknowledgments
	Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen,		Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen,
	Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, and Dan		Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing,
	Wing, for input, discussions, and guidance. Pasi Eronen provided		and Ben Campbell for input, discussions, and guidance. Pasi Eronen
	Figure 1.		provided Figure 1.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-avt-rtp-and-rtcp-mux]		[I-D.ietf-avt-rtp-and-rtcp-mux]
	Perkins, C. and M. Westerlund, "Multiplexing RTP Data and		Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
	Control Packets on a Single Port",		Control Packets on a Single Port",
	draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),		draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
	August 2007.		August 2007.
	[I-D.ietf-tls-extractor]		[I-D.ietf-tls-extractor]
	Rescorla, E., "Keying Material Extractors for Transport		Rescorla, E., "Keying Material Extractors for Transport
	Layer Security (TLS)", draft-ietf-tls-extractor-01 (work		Layer Security (TLS)", draft-ietf-tls-extractor-02 (work
	in progress), February 2008.		in progress), September 2008.
	[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.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, March 2004.		RFC 3711, March 2004.
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, April 2006.		Security", RFC 4347, April 2006.
	skipping to change at page 21, line 38 ¶		skipping to change at page 21, line 38 ¶
	[I-D.ietf-behave-rfc3489bis]		[I-D.ietf-behave-rfc3489bis]
	Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,		Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for (NAT) (STUN)",		"Session Traversal Utilities for (NAT) (STUN)",
	draft-ietf-behave-rfc3489bis-18 (work in progress),		draft-ietf-behave-rfc3489bis-18 (work in progress),
	July 2008.		July 2008.
	[I-D.ietf-sip-dtls-srtp-framework]		[I-D.ietf-sip-dtls-srtp-framework]
	Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing an SRTP Security Context using DTLS",		for Establishing an SRTP Security Context using DTLS",
	draft-ietf-sip-dtls-srtp-framework-03 (work in progress),		draft-ietf-sip-dtls-srtp-framework-04 (work in progress),
	August 2008.		October 2008.
			[I-D.ietf-tls-rfc4347-bis]
			Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security version 1.2", draft-ietf-tls-rfc4347-bis-00 (work
			in progress), June 2008.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.		Applications", STD 64, RFC 3550, July 2003.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, July 2006.
	[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the		[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
	Transport Layer Security (TLS) Protocol in the Session		Transport Layer Security (TLS) Protocol in the Session
	skipping to change at page 22, line 22 ¶		skipping to change at page 22, line 28 ¶
	This section provides a brief overview of Datagram TLS (DTLS) for		This section provides a brief overview of Datagram TLS (DTLS) for
	those who are not familiar with it. DTLS is a channel security		those who are not familiar with it. DTLS is a channel security
	protocol based on the well-known Transport Layer Security (TLS)		protocol based on the well-known Transport Layer Security (TLS)
	[RFC5246] protocol. Where TLS depends on a reliable transport		[RFC5246] protocol. Where TLS depends on a reliable transport
	channel (typically TCP), DTLS has been adapted to support unreliable		channel (typically TCP), DTLS has been adapted to support unreliable
	transports such as UDP. Otherwise, DTLS is nearly identical to TLS		transports such as UDP. Otherwise, DTLS is nearly identical to TLS
	and generally supports the same cryptographic mechanisms.		and generally supports the same cryptographic mechanisms.
	Each DTLS association begins with a handshake exchange (shown below)		Each DTLS association begins with a handshake exchange (shown below)
	during which the peers authenticated each other and negotiate		during which the peers authenticate each other and negotiate
	algorithms, modes, and other parameters and establish shared keying		algorithms, modes, and other parameters and establish shared keying
	material, as shown below. In order to support unreliable transport,		material, as shown below. In order to support unreliable transport,
	each side maintains retransmission timers to provide reliable		each side maintains retransmission timers to provide reliable
	delivery of these messages. Once the handshake is completed,		delivery of these messages. Once the handshake is completed,
	encrypted data may be sent.		encrypted data may be sent.
	Client Server		Client Server
	ClientHello -------->		ClientHello -------->
	ServerHello		ServerHello
End of changes. 25 change blocks.
	60 lines changed or deleted		68 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/