draft-ietf-sip-dtls-srtp-framework-00.txt		draft-fischl-sipping-media-dtls-03.txt
	SIP J. Fischl		SIPPING J. Fischl
	Internet-Draft CounterPath Solutions, Inc.		Internet-Draft CounterPath Solutions, Inc.
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: May 9, 2008 Nokia Siemens Networks		Expires: January 10, 2008
	E. Rescorla		E. Rescorla
	Network Resonance		Network Resonance
	November 6, 2007		July 9, 2007
	Framework for Establishing an SRTP Security Context using DTLS		Datagram Transport Layer Security (DTLS) Protocol for Protection of
	draft-ietf-sip-dtls-srtp-framework-00.txt		Media Traffic Established with the Session Initiation Protocol
			draft-fischl-sipping-media-dtls-03.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 38
	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 May 9, 2008.		This Internet-Draft will expire on January 10, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document specifies how to use the Session Initiation Protocol		This document specifies how to use the Session Initiation Protocol
	(SIP) to establish an Secure Real-time Transport Protocol (SRTP)		(SIP) to establish secure media sessions using or over the Datagram
	security context using the Datagram Transport Layer Security (DTLS)		Transport Layer Security (DTLS) protocol. It describes a mechanism
	protocol. It describes a mechanism of transporting a fingerprint		of transporting a fingerprint attribute in the Session Description
	attribute in the Session Description Protocol (SDP) that identifies		Protocol (SDP) that identifies the key that will be presented during
	the key that will be presented during the DTLS handshake. It relies		the DTLS handshake. It relies on the SIP identity mechanism to
	on the SIP identity mechanism to ensure the integrity of the		ensure the integrity of the fingerprint attribute. This allows the
	fingerprint attribute. The key management exchange travels along the		establishment of media security along the media path.
	media path as opposed to the signaling path.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Verifying Certificate Integrity . . . . . . . . . . . . . . . 7		5. Verifying Certificate Integrity . . . . . . . . . . . . . . . 6
	6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 8		6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 7
	6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 8		6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 8
	6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 9		6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 8
	6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 9		6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 9
	6.5. Session Modification . . . . . . . . . . . . . . . . . . . 10		6.5. Session Modification . . . . . . . . . . . . . . . . . . . 9
	6.6. UDP Payload De-multiplex . . . . . . . . . . . . . . . . . 10		6.6. UDP Payload De-multiplex . . . . . . . . . . . . . . . . . 9
	6.7. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.7. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.8. Conference Servers and Shared Encryptions Contexts . . . . 11		6.8. Conference Servers and Shared Encryptions Contexts . . . . 10
	6.9. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 11		6.9. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 10
	7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 11		7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.4. Single-sided Verification . . . . . . . . . . . . . . . . 18		8.4. Single-sided Verification . . . . . . . . . . . . . . . . 17
	8.5. Continuity of Authentication . . . . . . . . . . . . . . . 18		8.5. Continuity of Authentication . . . . . . . . . . . . . . . 17
	8.6. Short Authentication String . . . . . . . . . . . . . . . 19		8.6. Short Authentication String . . . . . . . . . . . . . . . 18
	8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 19		8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 18
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 18
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		9.1. Forking and retargeting (R1, R2, R3) . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		9.2. Clipping (R5) . . . . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 20		9.3. Passive Attacks (R6) . . . . . . . . . . . . . . . . . . . 19
	11.2. Informational References . . . . . . . . . . . . . . . . . 21		9.4. Perfect Forward Secrecy (R7) . . . . . . . . . . . . . . . 19
	Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 23		9.5. Algorithm Negotiation (R8, R9) . . . . . . . . . . . . . . 19
	A.1. Forking and retargeting (R1, R2, R3) . . . . . . . . . . . 23		9.6. Endpoint Idenfification When Forking (R10) . . . . . . . . 19
	A.2. Reusage of a Security Context (R4), (R11) . . . . . . . . 23		9.7. 3rd Party Certificates (R11) . . . . . . . . . . . . . . . 19
	A.3. Clipping (R5) . . . . . . . . . . . . . . . . . . . . . . 23		9.8. FIPS 140-2 (R12) . . . . . . . . . . . . . . . . . . . . . 20
	A.4. Passive Attacks on the Media Path (R6) . . . . . . . . . . 24		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	A.5. Passive Attacks on the Signaling Path (R7) . . . . . . . . 24		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	A.6. Perfect Forward Secrecy (R8) . . . . . . . . . . . . . . . 24		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	A.7. Algorithm Negotiation (R9) . . . . . . . . . . . . . . . . 24		12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	A.8. RTP Validity Check (R10) . . . . . . . . . . . . . . . . . 24		12.2. Informational References . . . . . . . . . . . . . . . . . 21
	A.9. 3rd Party Certificates (R12, R18) . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	A.10. FIPS 140-2 (R13) . . . . . . . . . . . . . . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . . . 25
	A.11. Linkage between Keying Exchange and SIP Signaling (R14) . 24
	A.12. Start with RTP and Upgrade to SRTP (R15) . . . . . . . . . 25
	A.13. Denial of Service Vulnerability (R16) . . . . . . . . . . 25
	A.14. Adversary Model (R17) . . . . . . . . . . . . . . . . . . 25
	A.15. Crypto-Agility (R19) . . . . . . . . . . . . . . . . . . . 25
	A.16. Downgrading Protection (R20) . . . . . . . . . . . . . . . 25
	A.17. Media Security Negotation (R21) . . . . . . . . . . . . . 25
	A.18. Signaling Protocol Independence (R22) . . . . . . . . . . 25
	A.19. Media Recording (R23) . . . . . . . . . . . . . . . . . . 25
	A.20. Lawful Interception (R24) . . . . . . . . . . . . . . . . 26
	A.21. Interworking with Intermediaries (R25) . . . . . . . . . . 26
	A.22. PSTN Gateway Termination (R26) . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
	Intellectual Property and Copyright Statements . . . . . . . . . . 28
	1. Introduction		1. Introduction
	The Session Initiation Protocol (SIP) [RFC3261] and the Session		The Session Initiation Protocol (SIP) [RFC3261] and the Session
	Description Protocol (SDP) [I-D.ietf-mmusic-sdp-new] are used to set		Description Protocol (SDP) [I-D.ietf-mmusic-sdp-new] are used to set
	up multimedia sessions or calls. SDP is also used to set up TCP		up multimedia sessions or calls. SDP is also used to set up TCP
	[I-D.ietf-mmusic-sdp-comedia] and additionally TCP/TLS connections		[I-D.ietf-mmusic-sdp-comedia] and additionally TCP/TLS connections
	for usage with media sessions [RFC4572]. The Real-Time Protocol		for usage with media sessions [I-D.ietf-mmusic-comedia-tls]. The
	(RTP) [RFC3550] is used to transmit real time media on top of UDP,		Real-Time Protocol (RTP) [RFC3550] is used to transmit real time
	TCP [I-D.ietf-avt-rtp-framing-contrans], and TLS [RFC4572]. Datagram		media on top of UDP, TCP [I-D.ietf-avt-rtp-framing-contrans], and TLS
	TLS [RFC4347] was introduced to allow TLS functionality to be applied		[I-D.ietf-mmusic-comedia-tls]. Datagram TLS [RFC4347] was introduced
	to datagram transport protocols, such as UDP and DCCP. This draft		to allow TLS functionality to be applied to datagram transport
	provides guidelines on how to use and to support for (a) transmission		protocols, such as UDP and DCCP. This draft provides guidelines on
	of media over DTLS and (b) to establish SRTP security using		how to use and to support for (a) transmission of media over DTLS and
	extensions to DTLS (see [I-D.ietf-avt-dtls-srtp]).		(b) to establish SRTP security using extensions to DTLS (see
			[I-D.ietf-avt-dtls-srtp]).
	The goal of this work is to provide a key negotiation technique that		The goal of this work is to provide a key negotiation technique that
	allows encrypted communication between devices with no prior		allows encrypted communication between devices with no prior
	relationships. It also does not require the devices to trust every		relationships. It also does not require the devices to trust every
	call signaling element that was involved in routing or session setup.		call signaling element that was involved in routing or session setup.
	This approach does not require any extra effort by end users and does		This approach does not require any extra effort by end users and does
	not require deployment of certificates to all devices that are signed		not require deployment of certificates to all devices that are signed
	by a well-known certificate authority.		by a well-known certificate authority.
	The media is transported over a mutually authenticated DTLS session		The media is transported over a mutually authenticated DTLS session
	where both sides have certificates. The certificate fingerprints are		where both sides have certificates. The certificate fingerprints are
	sent in SDP over SIP as part of the offer/answer exchange. The SIP		sent in SDP over SIP as part of the offer/answer exchange. The SIP
	Identity mechanism [RFC4474] is used to provide integrity for the		Identity mechanism [I-D.ietf-sip-identity] is used to provide
	fingerprints. It is very important to note that certificates are		integrity for the fingerprints. It is very important to note that
	being used purely as a carrier for the public keys of the peers.		certificates are being used purely as a carrier for the public keys
	This is required because DTLS does not have a mode for carrying bare		of the peers. This is required because DTLS does not have a mode for
	keys, but it is purely an issue of formatting. The certificates can		carrying bare keys, but it is purely an issue of formatting. The
	be self-signed and completely self-generated. All major TLS stacks		certificates can be self-signed and completely self-generated. All
	have the capability to generate such certificates on demand.		major TLS stacks have the capability to generate such certificates on
	However, third party certificates MAY also be used for extra		demand. However, third party certificates MAY also be used for extra
	security.		security.
	This approach differs from previous attempts to secure media traffic		This approach differs from previous attempts to secure media traffic
	where the authentication and key exchange protocol (e.g., MIKEY		where the authentication and key exchange protocol (e.g., MIKEY
	[RFC3830]) is piggybacked in the signaling message exchange. With		[RFC3830]) is piggybacked in the signaling message exchange. With
	this approach, establishing the protection of the media traffic		this approach, establishing the protection of the media traffic
	between the endpoints is done by the media endpoints without		between the endpoints is done by the media endpoints without
	involving the SIP/SDP communication. It allows RTP and SIP to be		involving the SIP/SDP communication. It allows RTP and SIP to be
	used in the usual manner when there is no encrypted media.		used in the usual manner when there is no encrypted media.
	skipping to change at page 6, line 13		skipping to change at page 5, line 15
	Since providing mutual authentication between two arbitrary end		Since providing mutual authentication between two arbitrary end
	points on the Internet using public key based cryptography tends to		points on the Internet using public key based cryptography tends to
	be problematic, we consider more deployment friendly alternatives.		be problematic, we consider more deployment friendly alternatives.
	This document uses one approach and several others are discussed in		This document uses one approach and several others are discussed in
	Section 8.		Section 8.
	Alice sends an SDP offer to Bob over SIP. If Alice uses only self-		Alice sends an SDP offer to Bob over SIP. If Alice uses only self-
	signed certificates for the communication with Bob, a fingerprint is		signed certificates for the communication with Bob, a fingerprint is
	included in the SDP offer/answer exchange. This fingerprint is		included in the SDP offer/answer exchange. This fingerprint is
	integrity protected using the identity mechanism defined in		integrity protected using the identity mechanism defined in
	Enhancements for Authenticated Identity Management in SIP [RFC4474].		Enhancements for Authenticated Identity Management in SIP
	When Bob receives the offer, Bob establishes a mutually authenticated		[I-D.ietf-sip-identity]. When Bob receives the offer, Bob
	DTLS connection with Alice. At this point Bob can begin sending		establishes a mutually authenticated DTLS connection with Alice. At
	media to Alice. Once Bob accepts Alice's offer and sends an SDP		this point Bob can begin sending media to Alice. Once Bob accepts
	answer to Alice, Alice can begin sending confidential media to Bob.		Alice's offer and sends an SDP answer to Alice, Alice can begin
			sending confidential media to Bob.
	3. Motivation		3. Motivation
	Although there is already prior work in this area (e.g., Secure		Although there is already prior work in this area (e.g., Secure
	Descriptions for SDP [I-D.ietf-mmusic-sdescriptions], Key Management		Descriptions for SDP [I-D.ietf-mmusic-sdescriptions], Key Management
	Extensions [I-D.ietf-mmusic-kmgmt-ext] combined with MIKEY [RFC3830]		Extensions [I-D.ietf-mmusic-kmgmt-ext] combined with MIKEY [RFC3830]
	for authentication and key exchange), this specification is motivated		for authentication and key exchange), this specification is motivated
	as follows:		as follows:
	o TLS will be used to offer security for connection-oriented media.		o TLS will be used to offer security for connection-oriented media.
	skipping to change at page 7, line 31		skipping to change at page 6, line 35
	client and server present certificates even if one or both		client and server present certificates even if one or both
	certificates are self-signed.		certificates are self-signed.
	5. Verifying Certificate Integrity		5. Verifying Certificate Integrity
	The offer/answer model, defined in [RFC3264], is used by protocols		The offer/answer model, defined in [RFC3264], is used by protocols
	like the Session Initiation Protocol (SIP) [RFC3261] to set up		like the Session Initiation Protocol (SIP) [RFC3261] to set up
	multimedia sessions. In addition to the usual contents of an SDP		multimedia sessions. In addition to the usual contents of an SDP
	[I-D.ietf-mmusic-sdp-new] message, each 'm' line will also contain		[I-D.ietf-mmusic-sdp-new] message, each 'm' line will also contain
	several attributes as specified in [I-D.fischl-mmusic-sdp-dtls],		several attributes as specified in [I-D.fischl-mmusic-sdp-dtls],
	[RFC4145] and [RFC4572].		[RFC4145] and [I-D.ietf-mmusic-comedia-tls].
	The endpoint MUST use the setup and connection attributes defined in		The endpoint MUST use the setup and connection attributes defined in
	[RFC4145]. A setup:active endpoint will act as a DTLS client and a		[RFC4145]. A setup:active endpoint will act as a DTLS client and a
	setup:passive endpoint will act as a DTLS server. The connection		setup:passive endpoint will act as a DTLS server. The connection
	attribute indicates whether or not to reuse an existing DTLS		attribute indicates whether or not to reuse an existing DTLS
	association.		association.
	The endpoint MUST use the certificate fingerprint attribute as		The endpoint MUST use the certificate fingerprint attribute as
	specified in [RFC4572].		specified in [I-D.ietf-mmusic-comedia-tls].
	The setup:active endpoint establishes a DTLS association with the		The setup:active endpoint establishes a DTLS association with the
	setup:passive endpoint [RFC4145]. Typically, the receiver of the SIP		setup:passive endpoint [RFC4145]. Typically, the receiver of the SIP
	INVITE request containing an offer will take the setup:active role.		INVITE request containing an offer will take the setup:active role.
	The certificate presented during the DTLS handshake MUST match the		The certificate presented during the DTLS handshake MUST match the
	fingerprint exchanged via the signaling path in the SDP. The		fingerprint exchanged via the signaling path in the SDP. The
	security properties of this mechanism are described in Section 8.		security properties of this mechanism are described in Section 8.
	If the fingerprint does not match the hashed certificate then the		If the fingerprint does not match the hashed certificate then the
	endpoint MUST tear down the media session immediately.		endpoint MUST tear down the media session immediately.
	When an endpoint wishes to set up a secure media session with another		When an endpoint wishes to set up a secure media session with another
	endpoint it sends an offer in a SIP message to the other endpoint.		endpoint it sends an offer in a SIP message to the other endpoint.
	This offer includes, as part of the SDP payload, the fingerprint of		This offer includes, as part of the SDP payload, the fingerprint of
	the certificate that the endpoint wants to use. The SIP message		the certificate that the endpoint wants to use. The SIP message
	containing the offer is sent to the offerer's sip proxy over an		containing the offer is sent to the offerer's sip proxy over an
	integrity protected channel which will add an identity header		integrity protected channel which will add an identity header
	according to the procedures outlined in [RFC4474]. When the far		according to the procedures outlined in [I-D.ietf-sip-identity].
	endpoint receives the SIP message it can verify the identity of the		When the far endpoint receives the SIP message it can verify the
	sender using the identity header. Since the identity header is a		identity of the sender using the identity header. Since the identity
	digital signature across several SIP headers, in addition to the		header is a digital signature across several SIP headers, in addition
	bodies of the SIP message, the receiver can also be certain that the		to the bodies of the SIP message, the receiver can also be certain
	message has not been tampered with after the digital signature was		that the message has not been tampered with after the digital
	applied and added to the SIP message.		signature was applied and added to the SIP message.
	The far endpoint (answerer) may now establish a mutually		The far endpoint (answerer) may now establish a mutually
	authenticated DTLS association to the offerer. After completing the		authenticated DTLS association to the offerer. After completing the
	DTLS handshake, information about the authenticated identities,		DTLS handshake, information about the authenticated identities,
	including the certificates, are made available to the endpoint		including the certificates, are made available to the endpoint
	application. The answerer is then able to verify that the offerer's		application. The answerer is then able to verify that the offerer's
	certificate used for authentication in the DTLS handshake can be		certificate used for authentication in the DTLS handshake can be
	associated to the certificate fingerprint contained in the offer in		associated to the certificate fingerprint contained in the offer in
	the SDP. At this point the answerer may indicate to the end user		the SDP. At this point the answerer may indicate to the end user
	that the media is secured. The offerer may only tentatively accept		that the media is secured. The offerer may only tentatively accept
	skipping to change at page 8, line 50		skipping to change at page 8, line 11
	fingerprints.		fingerprints.
	6. Miscellaneous Considerations		6. Miscellaneous Considerations
	6.1. Anonymous Calls		6.1. Anonymous Calls
	When making anonymous calls, a new self-signed certificate SHOULD be		When making anonymous calls, a new self-signed certificate SHOULD be
	used for each call so that the calls can not be correlated as to		used for each call so that the calls can not be correlated as to
	being from the same caller. In situations where some degree of		being from the same caller. In situations where some degree of
	correlation is acceptable, the same certificate SHOULD be used for a		correlation is acceptable, the same certificate SHOULD be used for a
	number of calls in order to enable continuity of authentication, see		number of calls in order to enable continuity of authentication
	Section 8.5.		Section 8.5.
	Additionally, it MUST be ensured that the Privacy header [RFC3325] is		Additionally, it MUST be ensured that the Privacy header [RFC3325] is
	used in conjunction with the SIP identity mechanism to ensure that		used in conjunction with the SIP identity mechanism to ensure that
	the identity of the user is not asserted when enabling anonymous		the identity of the user is not asserted when enabling anonymous
	calls. Furthermore, the content of the subjectAltName attribute		calls. Furthermore, the content of the subjectAltName attribute
	inside the certificate MUST NOT contain information that either		inside the certificate MUST NOT contain information that either
	allows correlation or identification of the user that wishes to place		allows correlation or identification of the user that wishes to place
	an anonymous call.		an anonymous call.
	skipping to change at page 17, line 11		skipping to change at page 16, line 11
	name. This works because there are a relatively small number of		name. This works because there are a relatively small number of
	servers with well-defined names; a situation which does not usually		servers with well-defined names; a situation which does not usually
	occur in the VoIP context.		occur in the VoIP context.
	The design described in this document is intended to leverage the		The design described in this document is intended to leverage the
	authenticity of the signaling channel (while not requiring		authenticity of the signaling channel (while not requiring
	confidentiality). As long as each side of the connection can verify		confidentiality). As long as each side of the connection can verify
	the integrity of the SDP INVITE then the DTLS handshake cannot be		the integrity of the SDP INVITE then the DTLS handshake cannot be
	hijacked via a man-in-the-middle attack. This integrity protection		hijacked via a man-in-the-middle attack. This integrity protection
	is easily provided by the caller to the callee (see Alice to Bob in		is easily provided by the caller to the callee (see Alice to Bob in
	Section 7) via the SIP Identity [RFC4474] mechanism. However, it is		Section 7) via the SIP Identity [I-D.ietf-sip-identity] mechanism.
	less straightforward for the responder.		However, it is less straightforward for the responder.
	Ideally Alice would want to know that Bob's SDP had not been tampered		Ideally Alice would want to know that Bob's SDP had not been tampered
	with and who it was from so that Alice's User Agent could indicate to		with and who it was from so that Alice's User Agent could indicate to
	Alice that there was a secure phone call to Bob. This is known as the		Alice that there was a secure phone call to Bob. This is known as the
	SIP connected party problem and is still a topic of ongoing work in		SIP connected party problem and is still a topic of ongoing work in
	the SIP community. In the meantime, there are several approaches		the SIP community. In the meantime, there are several approaches
	that can be used to mitigate this problem: Use UPDATE, Use SIPS, Use		that can be used to mitigate this problem: Use UPDATE, Use SIPS, Use
	S/MIME, Single Sided Verification, or use human-read Short		S/MIME, Single Sided Verification, or use human-read Short
	Authentication String (SAS) to validate the certificates. Each one		Authentication String (SAS) to validate the certificates. Each one
	is discussed here followed by the security implications of that		is discussed here followed by the security implications of that
	approach.		approach.
	8.1. UPDATE		8.1. UPDATE
	[RFC4916] defines an approach for a UA to supply its identity to its		[I-D.ietf-sip-connected-identity] defines an approach for a UA to
	peer UA and for this identity to be signed by an authentication		supply its identity to its peer UA and for this identity to be signed
	service. For example, using this approach, Bob sends an answer, then		by an authentication service. For example, using this approach, Bob
	immediately follows up with an UPDATE that includes the fingerprint		sends an answer, then immediately follows up with an UPDATE that
	and uses the SIP Identity mechanism to assert that the message is		includes the fingerprint and uses the SIP Identity mechanism to
	from Bob@example.com. The downside of this approach is that it		assert that the message is from Bob@example.com. The downside of
	requires the extra round trip of the UPDATE. However, it is simple		this approach is that it requires the extra round trip of the UPDATE.
	and secure even when not all of the proxies are trusted. In this		However, it is simple and secure even when not all of the proxies are
	example, Bob only needs to trust his proxy.		trusted. In this example, Bob only needs to trust his proxy.
	[[OPEN ISSUE: Note that there is a window of vulnerability during		[[OPEN ISSUE: Note that there is a window of vulnerability during
	the early media phase of this operation before Alice receives the		the early media phase of this operation before Alice receives the
	UPDATE (which immediately follows the SDP answer). During this		UPDATE (which immediately follows the SDP answer). During this
	window, Alice cannot be sure of Bob's identity. This risk might be		window, Alice cannot be sure of Bob's identity. This risk might be
	mitigated by including a secret in the offer which must be used to		mitigated by including a secret in the offer which must be used to
	establish the DTLS association, for instance via TLS PSK [RFC4279].		establish the DTLS association, for instance via TLS PSK [RFC4279].
	We are still studying this issue. Obviously, this is more attractive		We are still studying this issue. Obviously, this is more attractive
	if SIPS is used.]]		is SIPS is used.]]
	8.2. SIPS		8.2. SIPS
	In this approach, the signaling is protected by TLS from hop to hop.		In this approach, the signaling is protected by TLS from hop to hop.
	As long as all proxies are trusted, this provides integrity for the		As long as all proxies are trusted, this provides integrity for the
	fingerprint. It does not provide a strong assertion of who Alice is		fingerprint. It does not provide a strong assertion of who Alice is
	communicating with. However, as much as the target domain can be		communicating with. However, as much as the target domain can be
	trusted to correctly populate the From header field value, Alice can		trusted to correctly populate the From header field value, Alice can
	use that. The security issue with this approach is that if one of		use that. The security issue with this approach is that if one of
	the Proxies wished to mount a man-in-the-middle attack, it could		the Proxies wished to mount a man-in-the-middle attack, it could
	convince Alice that she was talking to Bob when really the media was		convince Alice that she was talking to Bob when really the media was
	flowing through a man in the middle media relay. However, this		flowing through a man in the middle media relay. However, this
	attack could not convince Bob that he was taking to Alice.		attack could not convince Bob that he was taking to Alice.
	8.3. S/MIME		8.3. S/MIME
	RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that		[RFC3261] defines a S/MIME security mechanism for SIP that could be
	could be used to sign that the fingerprint was from Bob. This would		used to sign that the fingerprint was from Bob. This would be secure.
	be secure. However, so far there have been no deployments of S/MIME		However, so far there have been no deployments of S/MIME for SIP.
	for SIP.
	8.4. Single-sided Verification		8.4. Single-sided Verification
	In this approach, no integrity is provided for the fingerprint from		In this approach, no integrity is provided for the fingerprint from
	Bob to Alice. In this approach, an attacker that was on the		Bob to Alice. In this approach, an attacker that was on the
	signaling path could tamper with the fingerprint and insert		signaling path could tamper with the fingerprint and insert
	themselves as a man-in-the-middle on the media. Alice would know		themselves as a man-in-the-middle on the media. Alice would know
	that she had a secure call with someone but would not know if it was		that she had a secure call with someone but would not know if it was
	with Bob or a man-in-the-middle. Bob would know that an attack was		with Bob or a man-in-the-middle. Bob would know that an attack was
	happening. The fact that one side can detect this attack means that		happening. The fact that one side can detect this attack means that
	skipping to change at page 18, line 37		skipping to change at page 17, line 36
	encrypted there is not a problem. Keep in mind that in any of the		encrypted there is not a problem. Keep in mind that in any of the
	possible approaches Bob could always reveal the media that was		possible approaches Bob could always reveal the media that was
	received to anyone. We are making the assumption that Bob also wants		received to anyone. We are making the assumption that Bob also wants
	secure communications. In this do nothing case, Bob knows the media		secure communications. In this do nothing case, Bob knows the media
	has not been tampered with or intercepted by a third party and that		has not been tampered with or intercepted by a third party and that
	it is from Alice@example.com. Alice knows that she is talking to		it is from Alice@example.com. Alice knows that she is talking to
	someone and that whoever that is has probably checked that the media		someone and that whoever that is has probably checked that the media
	is not being intercepted or tampered with. This approach is		is not being intercepted or tampered with. This approach is
	certainly less than ideal but very usable for many situations.		certainly less than ideal but very usable for many situations.
			[TODO]
	8.5. Continuity of Authentication		8.5. Continuity of Authentication
	One desirable property of a secure media system is to provide		One desirable property of a secure media system is to provide
	continuity of authentication: being able to ensure cryptographically		continuity of authentication: being able to ensure cryptographically
	that you are talking to the same person as before. With DTLS,		that you are talking to the same person as before. With DTLS,
	continuity of authentication is achieved by having each side use the		continuity of authentication is achieved by having each side use the
	same public key/self-signed certificate for each connection (at least		same public key/self-signed certificate for each connection (at least
	with a given peer entity). It then becomes possible to cache the		with a given peer entity). It then becomes possible to cache the
	credential (or its hash) and verify that it is unchanged. Thus, once		credential (or its hash) and verify that it is unchanged. Thus, once
	a single secure connection has been established, an implementation		a single secure connection has been established, an implementation
	skipping to change at page 19, line 37		skipping to change at page 18, line 38
	One concern about the use of a long-term key is that compromise of		One concern about the use of a long-term key is that compromise of
	that key may lead to compromise of past communications. In order to		that key may lead to compromise of past communications. In order to
	prevent this attack, DTLS supports modes with Perfect Forward Secrecy		prevent this attack, DTLS supports modes with Perfect Forward Secrecy
	using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites.		using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites.
	When these modes are in use, the system is secure against such		When these modes are in use, the system is secure against such
	attacks. Note that compromise of a long-term key may still lead to		attacks. Note that compromise of a long-term key may still lead to
	future active attacks. If this is a concern, a backup authentication		future active attacks. If this is a concern, a backup authentication
	channel such as manual fingerprint establishment or a short		channel such as manual fingerprint establishment or a short
	authentication string should be used.		authentication string should be used.
	9. IANA Considerations		9. Requirements Analysis
			[I-D.wing-media-security-requirements] describes security
			requirements for media keying. This section evaluates this proposal
			with respect to each requirement.
			9.1. Forking and retargeting (R1, R2, R3)
			In this draft, the SDP offer (in the INVITE) is simply an
			advertisement of the capability to do security. This advertisement
			does not depend on the identity of the communicating peer, so forking
			and retargeting work work when all the endpoints will do SRTP (R1).
			When a mix of SRTP and non-SRTP endpoints are present, we expect to
			use the SDP capabilities mechanism currently being defined
			[I-D.ietf-mmusic-sdp-capability-negotiation] to transparently
			negotiate security where possible (R2). Because DTLS establishes a
			new key for each session, only the entity with which the call is
			finally established gets the media encryption keys (R3).
			9.2. Clipping (R5)
			Because the key establishment occurs in the media plane, media need
			not be clipped before the receipt of the SDP answer (R5).
			9.3. Passive Attacks (R6)
			The public key algorithms used by DTLS (RSA, Diffie-Hellman, and
			Elliptic Curve Diffie-Hellman) are secure against passive attacks
			(R6).
			9.4. Perfect Forward Secrecy (R7)
			DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher
			suites which provide PFS (R7).
			9.5. Algorithm Negotiation (R8, R9)
			DTLS negotiates cipher suites before performing significant
			cryptographic computation and therefore supports algorithm
			negotiation (R8) and multiple cipher suites (R9) without additional
			computational expense.
			9.6. Endpoint Idenfification When Forking (R10)
			Once the SDP response is received, the implementation can match the
			fingerprint against the offered client Certificate message (R10).
			Note, however, that if the server is using ephemeral DH or ECDH, it
			still must compute a fresh DH share and sign it in the
			ServerKeyExchange. This could be optimized away by having a DTLS
			ClientHello extension in which the client provide a copy of its
			fingerprint in advance.
			9.7. 3rd Party Certificates (R11)
			Third party certificates are not required. However, if the parties
			share an authentication infrastructure that is compatible with TLS
			(3rd party certificates or shared keys) it can be used (R11).
			9.8. FIPS 140-2 (R12)
			TLS implementations already may be FIPS 140-2 approved and the
			algorithms used here are consistent with the approval of DTLS and
			DTLS-SRTP (R12).
			10. IANA Considerations
	This specification does not require any IANA actions.		This specification does not require any IANA actions.
	10. Acknowledgments		11. Acknowledgments
	Cullen Jennings contributed substantial text and comments to this		Cullen Jennings contributed substantial text and comments to this
	document. This document benefited from discussions with Francois		document. This document benefited from discussions with Francois
	Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful		Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful
	comments by Flemming Andreasen, Rohan Mahy, David McGrew, Miguel		comments by Flemming Andreasen, Rohan Mahy, David McGrew, and David
	Garcia, Steffen Fries, Brian Stucker, and David Oran.		Oran.
	We would like to thank Thomas Belling, Guenther Horn, Steffen Fries,
	Brian Stucker, Francois Audet, Jason Fischl, Dan Wing, Jari Arkko,
	and Vesa Lehtovirta for their input regarding traversal of SBCs.
	11. References		12. References
	11.1. Normative References		12.1. Normative References
	[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the		[I-D.ietf-mmusic-comedia-tls]
			Lennox, J., "Connection-Oriented Media Transport over the
	Transport Layer Security (TLS) Protocol in the Session		Transport Layer Security (TLS) Protocol in the Session
	Description Protocol (SDP)", RFC 4572, July 2006.		Description Protocol (SDP)",
			draft-ietf-mmusic-comedia-tls-06 (work in progress),
			March 2006.
	[I-D.ietf-mmusic-sdp-new]		[I-D.ietf-mmusic-sdp-new]
	Handley, M., "SDP: Session Description Protocol",		Handley, M., "SDP: Session Description Protocol",
	draft-ietf-mmusic-sdp-new-26 (work in progress),		draft-ietf-mmusic-sdp-new-26 (work in progress),
	January 2006.		January 2006.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[I-D.ietf-sip-identity]
			Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, August 2006.		Initiation Protocol (SIP)", draft-ietf-sip-identity-06
			(work in progress), October 2005.
			[I-D.fischl-mmusic-sdp-dtls]
			Fischl, J. and H. Tschofenig, "Session Description
			Protocol (SDP) Indicators for Datagram Transport Layer
			Security (DTLS)", draft-fischl-mmusic-sdp-dtls-02 (work in
			progress), March 2007.
	[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.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	skipping to change at page 21, line 16		skipping to change at page 21, line 43
	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.
	[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in		[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
	the Session Description Protocol (SDP)", RFC 4145,		the Session Description Protocol (SDP)", RFC 4145,
	September 2005.		September 2005.
	[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.
	[I-D.fischl-mmusic-sdp-dtls]		12.2. Informational References
	Fischl, J. and H. Tschofenig, "Session Description
	Protocol (SDP) Indicators for Datagram Transport Layer
	Security (DTLS)", draft-fischl-mmusic-sdp-dtls-03 (work in
	progress), July 2007.
	11.2. Informational References		[I-D.ietf-avt-dtls-srtp]
			McGrew, D. and E. Rescorla, "Datagram Transport Layer
			Security (DTLS) Extension to Establish Keys for Secure
			Real-time Transport Protocol (SRTP)",
			draft-ietf-avt-dtls-srtp-00 (work in progress), July 2007.
			[I-D.ietf-avt-rtp-and-rtcp-mux]
			Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
			Control Packets on a Single Port",
			draft-ietf-avt-rtp-and-rtcp-mux-05 (work in progress),
			May 2007.
	[I-D.ietf-avt-rtp-framing-contrans]		[I-D.ietf-avt-rtp-framing-contrans]
	Lazzaro, J., "Framing RTP and RTCP Packets over		Lazzaro, J., "Framing RTP and RTCP Packets over
	Connection-Oriented Transport",		Connection-Oriented Transport",
	draft-ietf-avt-rtp-framing-contrans-06 (work in progress),		draft-ietf-avt-rtp-framing-contrans-06 (work in progress),
	September 2005.		September 2005.
	[I-D.ietf-mmusic-ice]		[I-D.ietf-mmusic-ice]
	Rosenberg, J., "Interactive Connectivity Establishment		Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols",		Traversal for Offer/Answer Protocols",
	draft-ietf-mmusic-ice-19 (work in progress), October 2007.		draft-ietf-mmusic-ice-16 (work in progress), June 2007.
	[I-D.ietf-mmusic-kmgmt-ext]		[I-D.ietf-mmusic-kmgmt-ext]
	Arkko, J., "Key Management Extensions for Session		Arkko, J., "Key Management Extensions for Session
	Description Protocol (SDP) and Real Time Streaming		Description Protocol (SDP) and Real Time Streaming
	Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in		Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in
	progress), June 2005.		progress), June 2005.
	[I-D.ietf-mmusic-sdescriptions]		[I-D.ietf-mmusic-sdescriptions]
	Andreasen, F., "Session Description Protocol Security		Andreasen, F., "Session Description Protocol Security
	Descriptions for Media Streams",		Descriptions for Media Streams",
	draft-ietf-mmusic-sdescriptions-12 (work in progress),		draft-ietf-mmusic-sdescriptions-12 (work in progress),
	September 2005.		September 2005.
			[I-D.ietf-mmusic-sdp-capability-negotiation]
			Andreasen, F., "SDP Capability Negotiation",
			draft-ietf-mmusic-sdp-capability-negotiation-05 (work in
			progress), March 2007.
	[I-D.ietf-mmusic-sdp-comedia]		[I-D.ietf-mmusic-sdp-comedia]
	Yon, D., "Connection-Oriented Media Transport in the		Yon, D., "Connection-Oriented Media Transport in the
	Session Description Protocol (SDP)",		Session Description Protocol (SDP)",
	draft-ietf-mmusic-sdp-comedia-10 (work in progress),		draft-ietf-mmusic-sdp-comedia-10 (work in progress),
	November 2004.		November 2004.
			[I-D.ietf-sip-connected-identity]
			Elwell, J., "Connected Identity in the Session Initiation
			Protocol (SIP)", draft-ietf-sip-connected-identity-05
			(work in progress), February 2007.
	[I-D.ietf-tls-rfc2246-bis]		[I-D.ietf-tls-rfc2246-bis]
	Dierks, T. and E. Rescorla, "The TLS Protocol Version		Dierks, T. and E. Rescorla, "The TLS Protocol Version
	1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),		1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
	June 2005.		June 2005.
	[I-D.zimmermann-avt-zrtp]
	Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure
	RTP", draft-zimmermann-avt-zrtp-04 (work in progress),
	July 2007.
	[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-03 (work in progress), July 2007.		draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.
	[I-D.ietf-avt-dtls-srtp]		[I-D.wing-media-security-requirements]
	McGrew, D. and E. Rescorla, "Datagram Transport Layer		Wing, D., "Requirements for a Media Security Key
	Security (DTLS) Extension to Establish Keys for Secure		Management Protocol",
	Real-time Transport Protocol (SRTP)",		draft-wing-media-security-requirements-04 (work in
	draft-ietf-avt-dtls-srtp-00 (work in progress), July 2007.		progress), June 2007.
	[I-D.ietf-sip-media-security-requirements]
	Wing, D., Fries, S., Tschofenig, H., and F. Audet,
	"Requirements and Analysis of Media Security Key
	Management Protocols",
	draft-ietf-sip-media-security-requirements-00 (work in
	progress), September 2007.
	[I-D.ietf-mmusic-sdp-capability-negotiation]
	Andreasen, F., "SDP Capability Negotiation",
	draft-ietf-mmusic-sdp-capability-negotiation-07 (work in
	progress), October 2007.
	[I-D.ietf-avt-rtp-and-rtcp-mux]		[I-D.zimmermann-avt-zrtp]
	Perkins, C. and M. Westerlund, "Multiplexing RTP Data and		Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure
	Control Packets on a Single Port",		RTP", draft-zimmermann-avt-zrtp-03 (work in progress),
	draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),		March 2007.
	August 2007.
	[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of		[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
	Provisional Responses in Session Initiation Protocol		Provisional Responses in Session Initiation Protocol
	(SIP)", RFC 3262, June 2002.		(SIP)", RFC 3262, June 2002.
	[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,		[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
	and T. Wright, "Transport Layer Security (TLS)		and T. Wright, "Transport Layer Security (TLS)
	Extensions", RFC 3546, June 2003.		Extensions", RFC 3546, June 2003.
	[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
	Protocol (SIP)", RFC 4916, June 2007.
	[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.
	[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.		[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
	Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,		Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
	August 2004.		August 2004.
	[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites		[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
	for Transport Layer Security (TLS)", RFC 4279,		for Transport Layer Security (TLS)", RFC 4279,
	December 2005.		December 2005.
	[I-D.wing-sipping-srtp-key]
	Wing, D., "Disclosing Secure RTP (SRTP) Session Keys with
	a SIP Event Package", draft-wing-sipping-srtp-key-01 (work
	in progress), July 2007.
	Appendix A. Requirements Analysis
	[I-D.ietf-sip-media-security-requirements] describes security
	requirements for media keying. This section evaluates this proposal
	with respect to each requirement.
	A.1. Forking and retargeting (R1, R2, R3)
	In this draft, the SDP offer (in the INVITE) is simply an
	advertisement of the capability to do security. This advertisement
	does not depend on the identity of the communicating peer, so forking
	and retargeting work work when all the endpoints will do SRTP. When
	a mix of SRTP and non-SRTP endpoints are present, we expect to use
	the SDP capabilities mechanism currently being defined
	[I-D.ietf-mmusic-sdp-capability-negotiation] to transparently
	negotiate security where possible. Because DTLS establishes a new
	key for each session, only the entity with which the call is finally
	established gets the media encryption keys (R3).
	A.2. Reusage of a Security Context (R4), (R11)
	DTLS allows sessions to be resumed with the 'TLS session resumption'
	functionality. This feature can be used to lower the amount of
	cryptographic computation that needs to be done when two peers re-
	initiates the communication.
	A.3. Clipping (R5)
	Because the key establishment occurs in the media plane, media need
	not be clipped before the receipt of the SDP answer.
	A.4. Passive Attacks on the Media Path (R6)
	The public key algorithms used by DTLS ciphersuites, such as RSA,
	Diffie-Hellman, and Elliptic Curve Diffie-Hellman, are secure against
	passive attacks.
	A.5. Passive Attacks on the Signaling Path (R7)
	DTLS provides protection against passive attacks by adversaries on
	the signaling path since only a fingerprint is exchanged using SIP
	signaling.
	A.6. Perfect Forward Secrecy (R8)
	DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher
	suites which provide PFS.
	A.7. Algorithm Negotiation (R9)
	DTLS negotiates cipher suites before performing significant
	cryptographic computation and therefore supports algorithm
	negotiation and multiple cipher suites without additional
	computational expense.
	A.8. RTP Validity Check (R10)
	TBD
	A.9. 3rd Party Certificates (R12, R18)
	Third party certificates are not required. However, if the parties
	share an authentication infrastructure that is compatible with TLS
	(3rd party certificates or shared keys) it can be used.
	A.10. FIPS 140-2 (R13)
	TLS implementations already may be FIPS 140-2 approved and the
	algorithms used here are consistent with the approval of DTLS and
	DTLS-SRTP.
	A.11. Linkage between Keying Exchange and SIP Signaling (R14)
	The signaling exchange is linked to the key management exchange using
	the fingerprints carried in SIP and the certificates are exchanged in
	DTLS.
	A.12. Start with RTP and Upgrade to SRTP (R15)
	DTLS-SRTP as described in this framework does not require an SRTP
	security context to be established as part of the initial
	communication setup. Instead, the DTLS handshake can be initiated
	later during on ongoing session.
	A.13. Denial of Service Vulnerability (R16)
	DTLS offers some degree of DoS protection particuarly as a built-in
	feature.
	A.14. Adversary Model (R17)
	DTLS-SRTP requires that an adversary is at least able to intercept
	the fingerprint exchange along the SIP signaling path (i.e., active
	attack) and to intercept the DTLS handshake by acting as a man-in-
	the-middle adversary (i.e., active attack).
	A.15. Crypto-Agility (R19)
	DTLS allows ciphersuites to be negotiated and hence new algorithms
	can be incrementally deployed. Work on replacing the fixed MD5/SHA-1
	key derivation function is ongoing.
	A.16. Downgrading Protection (R20)
	DTLS provides protection against downgrading attacks since the
	selection of the offered ciphersuites is confirmed in a later stage
	of the handshake. This protection is efficient unless an adversary
	is able to break a ciphersuite in real-time.
	A.17. Media Security Negotation (R21)
	DTLS allows a User Agent to negotiate media security parameters for
	each individual session.
	A.18. Signaling Protocol Independence (R22)
	The DTLS-SRTP framework does not rely on SIP; every protocol that is
	capable of exchanging a fingerprint and the media description can be
	secured.
	A.19. Media Recording (R23)
	An extension, see [I-D.wing-sipping-srtp-key], has been specified to
	support media recording that does not require intermediaries to act
	as a MITM.
	When media recording is done by intermediaries then they need to act
	as a MITM.
	A.20. Lawful Interception (R24)
	Lawful interception requires an active MITM who is located along the
	signaling and the data path.
	A.21. Interworking with Intermediaries (R25)
	A description of the interworking with Session Border Controllers is
	described in this document.
	A.22. PSTN Gateway Termination (R26)
	The DTLS-SRTP framework allows the media security to terminate at a
	PSTN gateway. [Editor's Note: A detailed description will be
	provided in a future version of this document.]
	Authors' Addresses		Authors' Addresses
	Jason Fischl		Jason Fischl
	CounterPath Solutions, Inc.		CounterPath Solutions, Inc.
	Suite 300, One Bentall Centre, 505 Burrard Street		Suite 300, One Bentall Centre, 505 Burrard Street
	Vancouver, BC V7X 1M3		Vancouver, BC V7X 1M3
	Canada		Canada
	Phone: +1 604 320-3340		Phone: +1 604 320-3340
	Email: jason@counterpath.com		Email: jason@counterpath.com
	skipping to change at page 26, line 34		skipping to change at page 24, line 4
	Authors' Addresses		Authors' Addresses
	Jason Fischl		Jason Fischl
	CounterPath Solutions, Inc.		CounterPath Solutions, Inc.
	Suite 300, One Bentall Centre, 505 Burrard Street		Suite 300, One Bentall Centre, 505 Burrard Street
	Vancouver, BC V7X 1M3		Vancouver, BC V7X 1M3
	Canada		Canada
	Phone: +1 604 320-3340		Phone: +1 604 320-3340
	Email: jason@counterpath.com		Email: jason@counterpath.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks
	Otto-Hahn-Ring 6
	Munich, Bavaria 81739
	Germany
	Email: Hannes.Tschofenig@nsn.com		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.com
	Eric Rescorla		Eric Rescorla
	Network Resonance		Network Resonance
	2483 E. Bayshore #212		2483 E. Bayshore #212
	Palo Alto, CA 94303		Palo Alto, CA 94303
	USA		USA
	Email: ekr@networkresonance.com		Email: ekr@networkresonance.com
	Full Copyright Statement		Full Copyright Statement
End of changes. 43 change blocks.
	321 lines changed or deleted		221 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/