< draft-wing-sipping-srtp-key-01.txt		draft-wing-sipping-srtp-key-02.txt >
	Network Working Group D. Wing		Network Working Group D. Wing
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track F. Audet		Intended status: Standards Track F. Audet
	Expires: January 9, 2008 Nortel		Expires: May 18, 2008 Nortel
	S. Fries		S. Fries
	Siemens AG		Siemens AG
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	July 8, 2007		November 15, 2007
	Disclosing Secure RTP (SRTP) Session Keys with a SIP Event Package		Disclosing Secure RTP (SRTP) Session Keys with a SIP Event Package
	draft-wing-sipping-srtp-key-01		draft-wing-sipping-srtp-key-02
	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 39 ¶		skipping to change at page 1, line 39 ¶
	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 January 9, 2008.		This Internet-Draft will expire on May 18, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Many Secure RTP (SRTP) key exchange mechanisms do not disclose the		Many Secure RTP (SRTP) key exchange mechanisms do not disclose the
	SRTP session keys to intermediate SIP proxies. Howevr, these key		SRTP session keys to intermediate SIP proxies. However, these key
	exchange mechanisms cannot be used In environments where transcoding,		exchange mechanisms cannot be used in environments where transcoding,
	monitoring, or call recording are needed. This document specifies a		monitoring, or call recording are needed. This document specifies a
	secure mechanism for a cooperating endpoint to disclose its SRTP		secure mechanism for a cooperating endpoint to disclose its SRTP
	master keys to an authorized party.		master keys to an authorized party.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Learning Name and Certificate of ESC . . . . . . . . . . . 5		3.1. Learning Name and Certificate of ESC . . . . . . . . . . . 5
	3.2. Authorization of ESC . . . . . . . . . . . . . . . . . . . 5		3.2. Authorization of ESC . . . . . . . . . . . . . . . . . . . 5
	3.3. Sending SRTP Session Keys to ESC . . . . . . . . . . . . . 5		3.3. Sending SRTP Session Keys to ESC . . . . . . . . . . . . . 6
	3.4. Scenarios and Call Flows . . . . . . . . . . . . . . . . . 7		3.4. Scenarios and Call Flows . . . . . . . . . . . . . . . . . 7
	4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	5.1. Incorrect ESC . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Incorrect ESC . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Risks of Sharing SRTP Session Key . . . . . . . . . . . . 9		5.2. Risks of Sharing SRTP Session Key . . . . . . . . . . . . 9
	5.3. Disclosure Flag . . . . . . . . . . . . . . . . . . . . . 9		5.3. Disclosure Flag . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Integrity and encryption of keying information . . . . . . 9		5.4. Integrity and encryption of keying information . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8.2. Informational References . . . . . . . . . . . . . . . . . 12		8.2. Informational References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. Introduction		1. Introduction
	This document addresses 2 difficulties with End-to-end encryption of		This document addresses 2 difficulties with End-to-end encryption of
	RTP (SRTP [RFC3711]): transcoding and media recording. When peering		RTP (SRTP [RFC3711]): transcoding and media recording. When peering
	with other networks, different codecs are sometimes necessary		with other networks, different codecs are sometimes necessary
	(transcoding a surround-sound codec for transmission over a highly-		(transcoding a surround-sound codec for transmission over a highly-
	compressed bandwidth-constrained network, for example). In some		compressed bandwidth-constrained network, for example). In some
	environments (e.g., stock brokerages and banks) regulations and		environments (e.g., stock brokerages and banks) regulations and
	business needs require recording calls with coworkers or with		business needs require recording calls with coworkers or with
	customers. In many environments, quality problems such as echo can		customers. In many environments, quality problems such as echo can
	only be diagnosed by listening to the call (analyzing SRTP headers is		only be diagnosed by listening to the call (analyzing SRTP headers is
	not sufficient).		not sufficient).
	With an RTP stream, transcoding is accomplished by modifying SDP to		With an RTP stream, transcoding is accomplished by modifying SDP to
	offer a different codec through a transcoding device [RFC4117], and		offer a different codec through a transcoding device [RFC4117], and
	call recording or monitoring can be accomplished with an Ethernet		call recording or monitoring can be accomplished with an Ethernet
	sniffer listening for SIP and its associated RTP, with a media relay,		sniffer listening for SIP and its associated RTP, with a media relay,
	or with a Session Border Controller. However, when media is		or with a Session Border Controller. However, when media is
	encrypted end-to-end[I-D.wing-rtpsec-keying-eval], these existing		encrypted end-to-end [I-D.wing-rtpsec-keying-eval], these existing
	techniques fail because they are unable to decrypt the media packets.		techniques fail because they are unable to decrypt the media packets.
	When a media session is encrypted with SRTP, there are three		When a media session is encrypted with SRTP, there are three
	techniques to decrypt the media for monitoring or call recording:		techniques to decrypt the media for monitoring or call recording:
	1. the endpoint establishes a separate media stream to the recording		1. the endpoint establishes a separate media stream to the recording
	device, with a separate SRTP key, and sends the (mixed) media to		device, with a separate SRTP key, and sends the (mixed) media to
	the recording device. The disadvantages of this technique		the recording device. This techniques is often referenced as
	include doubling bandwidth requirements, loss of media recording		active recording here. The disadvantages of this technique
	facility doesn't cause loss of call (as is required in some		include doubling bandwidth requirements in the network and
	environments). A significant advantage of this technique,		additionally the processing power on the client side, Moreover,
	however, is that it's secure: a malicious media recording device		the loss of media recording facility doesn't cause loss of call
	cannot inject media to the connected party on behalf of the		(as is required in some environments). A significant advantage
	endpoint. Depending on the application requirements it may be		of this technique, however, is that it's secure: a malicious
	necessary to establish a reliable connection to the recording		media recording device cannot inject media to the connected party
	device to cope with possible packet loss on the unreliable link,		on behalf of the endpoint. Depending on the application
	typically used for media transport.		requirements it may be necessary to establish a reliable
			connection to the recording device to cope with possible packet
			loss on the unreliable link, typically used for media transport.
	2. the endpoint relays media through a device which forks a separate		2. the endpoint relays media through a device which forks a separate
	media stream to the recording device. This technique is often		media stream to the recording device. This technique is often
	employed by Session Border Controllers, and could also be		employed by Session Border Controllers, and could also be
	employed by TURN servers.		employed by TURN servers.
	3. Network sniffing devices are used to listen to the SRTP traffic		3. Network monitoring devices are used to listen to the SRTP traffic
	and correlate SRTP with SIP (with cooperation of call signaling		and correlate SRTP with SIP (with cooperation of call signaling
	devices, if the call signaling is encrypted).		devices, if the call signaling is encrypted).
	This document describes cases (2) and (3) where a cooperating		This document describes cases (2) and (3) where a cooperating
	endpoints publishes its SRTP master keys to an authorized party using		endpoint publishes its SRTP master keys to an authorized party using
	the SIP Event State Publication Extension [RFC3903]. The mechanism		the SIP Event State Publication Extension [RFC3903]. The mechanism
	described in this paper allows secure disclosure of SRTP session keys		can be described as passive recording, as the client is not directly
	to authorized parties so that an endpoints media stream can be		involved into the media recording. It merely provides the key
	transcoded or decrypted, as needed by that environment.		information to a recording device. The mechanism described in this
			paper allows secure disclosure of SRTP session keys to authorized
			parties so that an endpoints media stream can be transcoded or
			decrypted, as needed by that environment. Technique (1) stated above
			is not considered further in this document, as it does not require
			the disclosure of the key used for the communication between the two
			endpoints.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The following terminology is taken directly from SIP Event State		The following terminology is taken directly from SIP Event State
	Publication Extension [RFC3903]:		Publication Extension [RFC3903]:
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 18 ¶
	describes the TGK transport rather than SRTP master key		describes the TGK transport rather than SRTP master key
	transport).		transport).
	3.1. Learning Name and Certificate of ESC		3.1. Learning Name and Certificate of ESC
	The endpoint will be configured with the AOR of its ESC (e.g.,		The endpoint will be configured with the AOR of its ESC (e.g.,
	"transcoder@example.com"). If S/MIME is used to send the SRTP master		"transcoder@example.com"). If S/MIME is used to send the SRTP master
	key to the ESC, the endpoint is additionally configured with the		key to the ESC, the endpoint is additionally configured with the
	certificate of its ESC.		certificate of its ESC.
	This configuration is outside the scope of this document, but some		The name and public key of the ESC is configured into the endpoint.It
	examples are CLI, [I-D.ietf-sipping-config-framework], or		is vital that the public key of the ESC is not changed by an
	[I-D.ietf-sip-certs].		unauthorized user. Changes to change that public key will cause SRTP
			key disclosure to be encrypted with that key. It is RECOMMENDED that
			endpoints restrict changing the public key of the disclosure device
			using protections similar to changes to the endpoint's SIP username
			and SIP password.
	3.2. Authorization of ESC		3.2. Authorization of ESC
	Depending on the application, authorization of the key disclosure and		Depending on the application, authorization of the key disclosure and
	distribution to the ESC may be necessary besides the pure transport		distribution to the ESC may be necessary besides the pure transport
	security of the key distribution itself. This may be the case when		security of the key distribution itself. This may be the case when
	the config framework [I-D.ietf-sipping-config-framework] is not		the config framework [I-D.ietf-sipping-config-framework] is not
	applied and thus the information about the ESC is not known to the		applied and thus the information about the ESC is not known to the
	client.		client.
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 20 ¶
	describe the master key (and parameters) of the SRTP being received,		describe the master key (and parameters) of the SRTP being received,
	or the SSRC being transmitted. For transcoding and media recording,		or the SSRC being transmitted. For transcoding and media recording,
	both the sending key and receiving key are needed and in some cases		both the sending key and receiving key are needed and in some cases
	the SSRC is needed.		the SSRC is needed.
	Thus, we hereby extend the existing crypto attribute to indicate the		Thus, we hereby extend the existing crypto attribute to indicate the
	SSRC. We also create a new SDP attribute, "rcrypto", which is		SSRC. We also create a new SDP attribute, "rcrypto", which is
	identical to the existing "crypto" attribute, except that it		identical to the existing "crypto" attribute, except that it
	describes the receiving keys and their SSRCs. For example:		describes the receiving keys and their SSRCs. For example:
	a=crypto:1 AES_CM_128_HMAC_SHA1_32		a=crypto:1 AES_CM_128_HMAC_SHA1_80
	inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32		inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
	SSRC=1899		SSRC=1899
	a=rcrypto:1 AES_CM_128_HMAC_SHA1_32		a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
	inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32		inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32
	SSRC=3289		SSRC=3289
	a=rcrypto:1 AES_CM_128_HMAC_SHA1_32		a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
	inline:Hw3JFWNCFqSpTqNiYRj6HmSWKMHAmO4q1KIN1OVA|2^20|1:32		inline:Hw3JFWNCFqSpTqNiYRj6HmSWKMHAmO4q1KIN1OVA|2^20|1:32
	SSRC=4893		SSRC=4893
	Figure 1: Example SDP		Figure 1: Example SDP
	The full SDP, including the keying information, is then sent to the		The full SDP, including the keying information, is then sent to the
	ESC. The keying information MUST be encrypted and integrity		ESC. The keying information MUST be encrypted and integrity
	protected. Existing mechanisms such as S/MIME [RFC3261] and SIPS		protected. Existing mechanisms such as S/MIME [RFC3261] and SIPS
	[I-D.ietf-sip-sips] MAY be used to achieve this goal, or other		[I-D.ietf-sip-sips] or SIP over TLS (on all hops per administrative
	mechanisms may be defined.		means) MAY be used to achieve this goal, or other mechanisms may be
			defined.
	[[ ISSUE-3: if a endpoint is receiving multiple incoming streams		[[ ISSUE-3: if a endpoint is receiving multiple incoming streams
	from multiple endpoints, it will have negotiated different keys		from multiple endpoints, it will have negotiated different keys
	with each of them, and all of that traffic is coming to the same		with each of them, and all of that traffic is coming to the same
	transport address on the endpoint. Thus, we need a way to		transport address on the endpoint. Thus, we need a way to
	describe the different keys we're using to/from different		describe the different keys we're using to/from different
	transport addresses. One solution is to indicate the remote		transport addresses. One solution is to indicate the remote
	transport address. Indicating the remote SSRC is insufficient for		transport address. Indicating the remote SSRC is insufficient for
	this task, as several SRTP keying mechanisms do not include SSRC		this task, as several SRTP keying mechanisms do not include SSRC
	in their signaling (DTLS-SRTP, ZRTP, Security Descriptions).		in their signaling (DTLS-SRTP, ZRTP, Security Descriptions).
	For example, if there were two remote peers with different keys,		For example, if there were two remote peers with different keys,
	we could signal it like this:		we could signal it like this:
	a=crypto:1 AES_CM_128_HMAC_SHA1_32		a=crypto:1 AES_CM_128_HMAC_SHA1_80
	inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32		inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
	192.0.2.1:5678 SSRC=1899 SSRC=3892		192.0.2.1:5678 SSRC=1899 SSRC=3892
	a=rcrypto:1 AES_CM_128_HMAC_SHA1_32		a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
	inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32		inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32
	192.0.2.1:5678 SSRC=3289 SSRC=2813		192.0.2.1:5678 SSRC=3289 SSRC=2813
	a=crypto:1 AES_CM_128_HMAC_SHA1_32		a=crypto:1 AES_CM_128_HMAC_SHA1_80
	inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32		inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32
	192.0.2.222:2893		192.0.2.222:2893
	a=rcrypto:1 AES_CM_128_HMAC_SHA1_32		a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
	inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32		inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32
	192.0.2.222:2893		192.0.2.222:2893
	Figure 2: Strawman solution		Figure 2: Strawman solution
	]]		]]
	3.4. Scenarios and Call Flows		3.4. Scenarios and Call Flows
	The following scenarios and call flows depict the assumptions for the		The following scenarios and call flows depict the assumptions for the
	provision of media key disclosure. Figure 3 shows the general setup		provision of media key disclosure. Figure 3 shows the general setup
	within the home domain of the client. Note that the authors assume		within the home domain of the client. Note that the authors assume
	that the client only discloses media keys only to an entity in the		that the client only discloses media keys only to an entity in the
	client's home network rather than to an arbitrary entity in the		client's home network rather than to an arbitrary entity in the
	visited network.		visited network.
	+--------+ +-------+ +-------+ +--------+		+----------+ +-------+ +---------+ +--------+ +----------+
	| Client | | Proxy | | ESC | | MedRec |		| SIP User | | SIP | |SIP Proxy| | Media | | SIP |
	+--------+ +-------+ +-------+ +--------+		|Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent|
	| | | |		+----------+ +-------+ +---------+ +--------+ +----------+
	+---------------+--------------+--------------+		| | | | |
			+----------+----------+-----------+-----------+
	Figure 3: Network Topology		Figure 3: Network Topology
	Based on this setup there are different options to realize the key		Based on this setup there are different options to realize the key
	disclosure, depending on the environment. In the following two		disclosure, depending on the environment. In the following two
	approaches are distingusihed.		approaches are distingusihed.
	Publishing media keys to the ESC		Publishing media keys to the ESC
	This requires that the configuration management provides the ESC		This requires that the configuration management provides the ESC
	configuration data (e.g., certificate, policy) in a secure way to		configuration data (e.g., certificate, policy) in a secure way to
	the client. As stated above, this configuration is outside the		the client. As stated above, this configuration is outside the
	scope of this document, but an example can be found in		scope of this document, but an example can be found in
	[I-D.ietf-sipping-config-framework]. The key disclosure in this		[I-D.ietf-sipping-config-framework]. The key disclosure in this
	approach uses the PUBLISH method to disclose the key to the ESC		approach uses the PUBLISH method to disclose the key to the ESC
	according to a given policy.		according to a given policy.
	+--------+ +-------+ +-------+ +--------+		+----------+ +-------+ +---------+ +--------+ +----------+
	| Client | | Proxy | | ESC | | MedRec |		| SIP User | | SIP | |SIP Proxy| | Media | | SIP |
	+--------+ +-------+ +-------+ +--------+		|Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent|
	| | | |		+----------+ +-------+ +---------+ +--------+ +----------+
	| - REGISTER -> | | |		| | | | |
	| <- 200 OK -- | | |		|-REGISTER->| | | |
	| | | |		|<-200 OK---| | | |
	| -- INVITE --> | | |		| | | | |
	| <- 200 OK -- | | |		|--INVITE-->|-------------INVITE------------->|
	| | | |		|<-200 Ok---|<------------200 Ok------------- |
	| -- PUBLISH (Key Data) --> | |		| | | | |
	| | | |		|<====SRTP in both directions================>|
			| | | | |
			|-PUBLISH-->|-PUBLISH-->|-key----->| |
			|<-200 Ok---|<--200 Ok--| | |
			Note that the protocol between the ESC and the media recorder is
			out of scope of this document.
	Using SAML assertions for ESC contact		Using SAML assertions for ESC contact
	In this approach authorization is provided via a SAML assertion,		In this approach authorization is provided via a SAML assertion,
	see [I-D.ietf-sip-saml], indicating which ESC is allowed to		see [I-D.ietf-sip-saml], indicating which ESC is allowed to
	perform call recording of a single or a set of calls, depending on		perform call recording of a single or a set of calls, depending on
	the content of the assertion. Here a SAML assertion is provided		the content of the assertion. Here a SAML assertion is provided
	as part of the SUBSCRIBE message, send from the ESC to the client.		as part of the SUBSCRIBE message, send from the ESC to the client.
	The assertion needs to provide at least the call relation, or a		The assertion needs to provide at least the call relation, or a
	time intervall for which media recoding is going to be performed.		time intervall for which media recoding is going to be performed.
	The SAML assertion is signed with the private key associated with		The SAML assertion is signed with the private key associated with
	the domain certificate, which is in possession of the		the domain certificate, which is in possession of the
	authentication service. The call flow would look like following:		authentication service. The call flow would look like following:
	+--------+ +-------+ +-------+ +--------+		+----------+ +-------+ +---------+ +--------+ +----------+
	| Client | | Proxy | | ESC | | MedRec |		| SIP User | | SIP | |SIP Proxy| | Media | | SIP |
	+--------+ +-------+ +-------+ +--------+		|Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent|
	| | | |		+----------+ +-------+ +---------+ +--------+ +----------+
	| - REGISTER -> | | |		| | | | |
	| <- 200 OK -- | | |		|-REGISTER->| | | |
	| | | |		|<-200 OK---| | | |
	| <- SUBSCIBE (call forming) - | |		| | | | |
	| + SAML assertion | |		|<-SUBSCRIBE (SAML as.)-| | |
	| | | |		| | | | |
	| -- INVITE --> | | |		|--INVITE-->|-------------INVITE------------->|
	| <- 200 OK -- | | |		|<-200 Ok---|<------------200 Ok------------- |
	| | | |		| | | | |
	| -- NOTIFY (Key Data) --> | |		|<====SRTP in both directions================>|
			| | | | |
			|--NOTIFY (SRTP data)-->| | |
			| | | | |
	4. Grammar		4. Grammar
	[[Grammar will be provided in a subsequent version of this		[[Grammar will be provided in a subsequent version of this
	document.]]		document.]]
	5. Security Considerations		5. Security Considerations
	5.1. Incorrect ESC		5.1. Incorrect ESC
	Insertion of the incorrect public key of the SRTP ESC will result in		Insertion of the incorrect public key of the SRTP ESC will result in
	disclosure of the SRTP session key to an unauthorized party. Thus,		disclosure of the SRTP session key to an unauthorized party. Thus,
	the UA's configuration MUST be protected to prevent such		the UA's configuration MUST be protected to prevent such
	misconfiguration. If the configuration or the ESC's certificate are		misconfiguration. To avoid changes to the configuration in the end
	obtained over the network [I-D.ietf-sipping-config-framework],		device, the configuration access MUST be suitably protected.
	[I-D.ietf-sip-certs], the certificate MUST be suitably authenticated
	and integrity protected.
	5.2. Risks of Sharing SRTP Session Key		5.2. Risks of Sharing SRTP Session Key
	A party authorized to obtain the SRTP session key can listen to the		A party authorized to obtain the SRTP session key can listen to the
	media stream and could inject data into the media stream as if it		media stream and could inject data into the media stream as if it
	were either party. The alternatives are worse: disclose the		were either party. The alternatives are worse: disclose the
	device's private key to the transcoder or media recording device, or		device's private key to the transcoder or media recording device, or
	abandon using secure SRTP key exchange in environments that require		abandon using secure SRTP key exchange in environments that require
	media transcoding or media recording. As we wish to promote the use		media transcoding or media recording. As we wish to promote the use
	of secure SRTP key exchange mechanisms, disclosure of the SRTP		of secure SRTP key exchange mechanisms, disclosure of the SRTP
	skipping to change at page 10, line 17 ¶		skipping to change at page 11, line 12 ¶
	New SSRC extension of the "crypto" attribute, and the new "rcrypto"		New SSRC extension of the "crypto" attribute, and the new "rcrypto"
	attribute will be registered here.		attribute will be registered here.
	7. Examples		7. Examples
	This is an example showing a SIPS AOR for the ESC. This relies on		This is an example showing a SIPS AOR for the ESC. This relies on
	the SIP network providing TLS encryption of the SRTP master keys to		the SIP network providing TLS encryption of the SRTP master keys to
	the ESC.		the ESC.
	PUBLISH sips:recorder@example.com SIP/2.0		PUBLISH sips:recorder@example.com SIP/2.0
	Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge		Via: SIP/2.0/TLS pua.example.com;branch=z9hG4bK652hsge
	To: <sips:recorder@example.com>		To: <sips:recorder@example.com>
	From: <sip:dan@example.com>;tag=1234wxyz		From: <sips:dan@example.com>;tag=1234wxyz
	Call-ID: 81818181@pua.example.com		Call-ID: 81818181@pua.example.com
	CSeq: 1 PUBLISH		CSeq: 1 PUBLISH
	Max-Forwards: 70		Max-Forwards: 70
	Expires: 3600		Expires: 3600
	Event: srtp		Event: srtp
	Content-Type: application/sdp		Content-Type: application/sdp
	Content-Length: ...		Content-Length: ...
	v=0		v=0
	o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com		o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
	s=-		s=-
	c=IN IP4 192.0.2.101		c=IN IP4 192.0.2.101
	t=0 0		t=0 0
	m=audio 49172 RTP/SAVP 0		m=audio 49172 RTP/SAVP 0
	a=crypto:1 AES_CM_128_HMAC_SHA1_32		a=crypto:1 AES_CM_128_HMAC_SHA1_80
	inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32		inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
	a=rcrypto:1 AES_CM_128_HMAC_SHA1_32		a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
	inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32		inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	Figure 6: Example with "SIPS:" AOR		Figure 6: Example with "SIPS:" AOR
	This is an example showing an S/MIME-encrypted transmission to the		This is an example showing an S/MIME-encrypted transmission to the
	media recorder's AOR, recorder@example.com. The data enclosed in "*"		media recorder's AOR, recorder@example.com. The data enclosed in "*"
	is encrypted with recorder@example.com's public key.		is encrypted with recorder@example.com's public key.
	PUBLISH sip:recorder@example.com SIP/2.0		PUBLISH sip:recorder@example.com SIP/2.0
	Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge		Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
	To: <sip:recorder@example.com>		To: <sip:recorder@example.com>
	From: <sip:dan@example.com>;tag=1234wxyz		From: <sip:dan@example.com>;tag=1234wxyz
	Call-ID: 81818181@pua.example.com		Call-ID: 81818181@pua.example.com
	CSeq: 1 PUBLISH		CSeq: 1 PUBLISH
	Max-Forwards: 70		Max-Forwards: 70
	Expires: 3600		Expires: 3600
	Event: srtp		Event: srtp
	Content-Type: application/pkcs7-mime;smime-type=enveloped-data;		Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
	name=smime.p7m		name=smime.p7m
	Content-Transfer-Encoding: binary		Content-Transfer-Encoding: binary
	Content-ID: 1234@atlanta.example.com		Content-ID: 1234@atlanta.example.com
	Content-Disposition: attachment;filename=smime.p7m;handling=required		Content-Disposition: attachment;filename=smime.p7m;
	Content-Length: ...		handling=required
			Content-Length: ...
	******************************************************************		******************************************************************
	* (encryptedContentInfo) *		* (encryptedContentInfo) *
	* Content-Type: application/sdp *		* Content-Type: application/sdp *
	* Content-Length: ... *		* Content-Length: ... *
	* *		* *
	* v=0 *		* v=0 *
	* o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com*		* o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com*
	* s=- *		* s=- *
	* c=IN IP4 192.0.2.101 *		* c=IN IP4 192.0.2.101 *
	* t=0 0 *		* t=0 0 *
	* m=audio 49172 RTP/SAVP 0 *		* m=audio 49172 RTP/SAVP 0 *
	* a=crypto:1 AES_CM_128_HMAC_SHA1_32 *		* a=crypto:1 AES_CM_128_HMAC_SHA1_80 *
	* inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 *		* inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 *
	* a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 *		* a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 *
	* inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 *		* inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 *
	* a=rtpmap:0 PCMU/8000 *		* a=rtpmap:0 PCMU/8000 *
	* *		* *
	******************************************************************		******************************************************************
	Figure 7: Example with S/MIME-encrypted SDP		Figure 7: Example with S/MIME-encrypted SDP
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, 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.
	[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension		[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
	skipping to change at page 12, line 33 ¶		skipping to change at page 13, line 37 ¶
	[I-D.wing-rtpsec-keying-eval]		[I-D.wing-rtpsec-keying-eval]
	Audet, F. and D. Wing, "Evaluation of SRTP Keying with		Audet, F. and D. Wing, "Evaluation of SRTP Keying with
	SIP", draft-wing-rtpsec-keying-eval-02 (work in progress),		SIP", draft-wing-rtpsec-keying-eval-02 (work in progress),
	February 2007.		February 2007.
	[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session		[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
	Description Protocol (SDP) Security Descriptions for Media		Description Protocol (SDP) Security Descriptions for Media
	Streams", RFC 4568, July 2006.		Streams", RFC 4568, July 2006.
	[I-D.ietf-sipping-config-framework]		[I-D.ietf-sipping-config-framework]
	Petrie, D. and S. Channabasappa, "A Framework for Session		Channabasappa, S., "A Framework for Session Initiation
	Initiation Protocol User Agent Profile Delivery",		Protocol User Agent Profile Delivery",
	draft-ietf-sipping-config-framework-12 (work in progress),		draft-ietf-sipping-config-framework-13 (work in progress),
	June 2007.		October 2007.
	[I-D.ietf-sip-sips]		[I-D.ietf-sip-sips]
	Audet, F., "The use of the SIPS URI Scheme in the Session		Audet, F., "The use of the SIPS URI Scheme in the Session
	Initiation Protocol (SIP)", draft-ietf-sip-sips-05 (work		Initiation Protocol (SIP)", draft-ietf-sip-sips-06 (work
	in progress), June 2007.		in progress), August 2007.
	[I-D.ietf-sip-certs]
	Jennings, C., "Certificate Management Service for The
	Session Initiation Protocol (SIP)",
	draft-ietf-sip-certs-03 (work in progress), March 2007.
	[I-D.ietf-sip-saml]		[I-D.ietf-sip-saml]
	Tschofenig, H., "SIP SAML Profile and Binding",		Tschofenig, H., "SIP SAML Profile and Binding",
	draft-ietf-sip-saml-02 (work in progress), May 2007.		draft-ietf-sip-saml-02 (work in progress), May 2007.
	[I-D.zimmermann-avt-zrtp]		[I-D.zimmermann-avt-zrtp]
	Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure		Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure
	RTP", draft-zimmermann-avt-zrtp-03 (work in progress),		RTP", draft-zimmermann-avt-zrtp-04 (work in progress),
	March 2007.		July 2007.
	[RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van		[RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van
	Wijk, "Transcoding Services Invocation in the Session		Wijk, "Transcoding Services Invocation in the Session
	Initiation Protocol (SIP) Using Third Party Call Control		Initiation Protocol (SIP) Using Third Party Call Control
	(3pcc)", RFC 4117, June 2005.		(3pcc)", RFC 4117, June 2005.
	Authors' Addresses		Authors' Addresses
	Dan Wing		Dan Wing
	Cisco Systems, Inc.		Cisco Systems, Inc.
End of changes. 37 change blocks.
	128 lines changed or deleted		144 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/