Subject: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt

From: [email-masked]
Date: Mon, 12 Nov 2007 01:00:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title           : Framework for Establishing an SRTP Security Context using DTLS
	Author(s)       : J. Fischl, et al.
	Filename        : draft-ietf-sip-dtls-srtp-framework-00.txt
	Pages           : 28
	Date            : 2007-11-12

This document specifies how to use the Session Initiation Protocol
(SIP) to establish an Secure Real-time Transport Protocol (SRTP)
security context using the Datagram Transport Layer Security (DTLS)
protocol.  It describes a mechanism of transporting a fingerprint
attribute in the Session Description Protocol (SDP) that identifies
the key that will be presented during the DTLS handshake.  It relies
on the SIP identity mechanism to ensure the integrity of the
fingerprint attribute.  The key management exchange travels along the
media path as opposed to the signaling path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-sip-dtls-srtp-framework-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-dtls-srtp-framework-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 Nov 2007 08:06:18 +0000

In Security Considerations, concerning UPDATE:
"OPEN ISSUE:  Note that there is a window of vulnerability during
   the early media phase of this operation before Alice receives the
   UPDATE (which immediately follows the SDP answer).  During this
   window, Alice cannot be sure of Bob's identity."
There is a vulnerability in any case during the early media phase if the
SDP answer does not arrive until the SIP 200 OK. So the additional
vulnerability is the short window between the 200 OK and the UPDATE
request. Also the UPDATE request can be sent earlier if reliable
provisional responses (RFC 3262) are used.

Concerning use of SIPS:
"The security issue with this approach is that if one of
   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
   flowing through a man in the middle media relay."
In fact, even a well-behaved proxy could forward the INVITE request to
Chuck (in accordance with Bob's requirements presumably), so Alice might
think she is talking to Bob when in fact she is talking to Chuck.

Concerning use of S/MIME:
"RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that
   could be used to sign that the fingerprint was from Bob. This would
   be secure.  However, so far there have been no deployments of S/MIME
   for SIP."
It fails to mention that PKIX certs need to be provided on endpoints.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 12 November 2007 06:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt
> 
> 	"FILE 
> /internet-drafts/draft-ietf-sip-dtls-srtp-framework-00.txt".
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 13 Nov 2007 13:50:47 -0600

(copying Flemming)

Good draft. Very helpful.

On the SDP side of things.

I didn't seen anything in the SDP format that specifically indicated in the offer that 
you are trying to setup DTLS-SRTP.

Is the assumption that if there is no indication besides the RTP/SAVP in the tcap, that
DTLS-SRTP may be negotiated, and that therefore we do not need an explicit indication
that DTLS-SRTP is supported?

Do we think it's good enough? In other words, is RTP/SAVP without a=crypto or a=key-mgmt 
good enough to indicate DTLS-SRTP? Or should we have another attribute?

A side comment is that the example shows usage with Best-Effort SRTP. My take is
that it could also be used in "DTLS-SRTP-always" mode by having the m-line
use UDP/TLS/RTP/AVP instead of RTP/AVP and not using a a=tcap/a=pcfg line. It
would probably be worthwile to describe it in the draft.