Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 01.txt

From: "Elwell, John" <[email-masked]>
Date: Sun, 29 Oct 2006 09:19:56 +0000

Dan,

It would probably need to be something like:
a=srtp key-mgmt:0=96,18=97 crypto:0=98,18=99 fingerprint:0=100,18=101
zrtp:0=102,18=103

John 

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 27 October 2006 18:46
> To: Elwell, John; 'Francois Audet'; 'Hadriel Kaplan'; [email-masked]
> Subject: RE: [MMUSIC] RE: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt
> 
> And another for srtp-dtls and another for zrtp?
> 
> Maybe there is a more efficient way to combine these.  Perhaps only
> including a=srtp for those key exchange mechanisms which can allow
> decrypting SRTP media that arrives prior to the SDP answer?  
> Or perhaps
> specifying the payload types in such a way that they're 
> assigned to each of
> the a= key management mechanisms understood by the answerer.  
> As a possible
> strawman for this last idea:
> 
>   m=blahblah
>   a=key-mgmt blahblah
>   a=crypto blahblah
>   a=fingerprint blahblah (used by srtp-dtls)
>   a=zrtp
>   a=srtp key-mgmt 40 crypto 41 fingerprint 42 zrtp 43
>   
> -d
>  
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Thursday, October 26, 2006 11:07 PM
> > To: Francois Audet; Hadriel Kaplan; [email-masked]
> > Subject: RE: [MMUSIC] RE: I-D 
> > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt
> > 
> > Francois,
> > 
> > Yes, that would work.
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Francois Audet [mailto:[email-masked]] 
> > > Sent: 27 October 2006 01:22
> > > To: Elwell, John; Hadriel Kaplan; [email-masked]
> > > Subject: RE: [MMUSIC] RE: I-D 
> > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt
> > > 
> > > Maybe we could use one a=srtp line for crypto, and another one for
> > > kmgmt?
> > > 
> > > (i.e., have a different PT for each?) 
> > > 
> > > > -----Original Message-----
> > > > From: Elwell, John [mailto:[email-masked]] 
> > > > Sent: Thursday, October 26, 2006 5:56 AM
> > > > To: Hadriel Kaplan; Audet, Francois (SC100:3055); 
> [email-masked]
> > > > Subject: [MMUSIC] RE: I-D 
> > > > ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt
> > > > 
> > > > Hadriel, Francois,
> > > > 
> > > > Thanks for working on this update. Just one point. If both 
> > > > SDescriptions and MIKEY are offered (inclusion of a=crypto 
> > > > and a=key-mgmt lines) and a different payload type is also 
> > > > indicated for SRTP, this payload type would apply whether the 
> > > > SDescription-derived key or the MIKEY-derived key is used.
> > > > So until the SDP answer arrives, it would still not be 
> > > > possible to render SRTP. Of course, in the case of 
> > > > SDescriptions it is not possible anyway, but in the case of 
> > > > certain MIKEY options it ought to be possible. Unfortunately 
> > > > to resolve this we would need somewhat more complex syntax in 
> > > > the a=srtp line.
> > > > 
> > > > John
> > > > 
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> [mailto:[email-masked]]
> > > > > Sent: 25 October 2006 20:50
> > > > > To: [email-masked]
> > > > > Subject: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt
> > > > > 
> > > > > A New Internet-Draft is available from the on-line 
> > > Internet-Drafts 
> > > > > directories.
> > > > > 
> > > > > 
> > > > > 	Title		: Session Description Protocol (SDP) 
> > > > > Offer/Answer Negotiation For Best-Effort Secure Real-Time 
> > > Transport 
> > > > > Protocol
> > > > > 	Author(s)	: F. Audet, H. Kaplan
> > > > > 	Filename	: 
> > draft-kaplan-mmusic-best-effort-srtp-01.txt
> > > > > 	Pages		: 17
> > > > > 	Date		: 2006-10-25
> > > > > 	
> > > > > This document defines the requirements and a proposed 
> > > solution for 
> > > > >    an SDP Offer/Answer exchange model for negotiating 
> > > > best-effort SRTP
> > > > >    keys, i.e., in a backward-compatible manner with 
> > > > non-SRTP devices.
> > > > >    The proposed solution is a trivial interpretation of the 
> > > > usage of 
> > > > >    the profile and the usage of SDP indication of [sdesc] 
> > > > and [kmgmt].
> > > > > 
> > > > > A URL for this Internet-Draft is:
> > > > > http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e
> > > > > ffort-srtp-01.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-kaplan-mmusic-best-effort-srtp-01.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-kaplan-mmusic-best-effort-srtp-01.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.
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > mmusic mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/mmusic
> > > > 
> > > 
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 29 Oct 2006 21:14:34 -0500

I wouldn't think zrtp would need port-mapping.  They're supposed to
handshake in clear RTP (or maybe rtcp depending on how the argument in AVT
ends up).  So they should be able to use the m= line ones.  I would expect
that any media-plane key exchange mechanism would be designed such that it
gracefully fails if either side doesn't support it, no?  They may need/want
an attribute so the offerer can tell the answerer to try it, or other info
like a fingerprint, but port-mapping wouldn't be one of them, would it?

-hadriel

> Sent: Sunday, October 29, 2006 4:20 AM
> To: Dan Wing; 'Francois Audet'; 'Hadriel Kaplan'; [email-masked]
> Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-
> 01.txt
> 
> Dan,
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 17:13:39 -0800

> I wouldn't think zrtp would need port-mapping. 

Security Descriptions probably doesn't need it, either -- it can't do early
media unless we resurrect draft-wing-mmusic-sdes-early-media-00.txt or some
idea like it.

> They're supposed to handshake in clear RTP (or maybe rtcp 
> depending on how the argument in AVT ends up).  So they should 
> be able to use the m= line ones.  I would expect
> that any media-plane key exchange mechanism would be designed 
> such that it gracefully fails if either side doesn't support 
> it, no? 

You only want to fail gracefully if your security policy allows
RTP, and your signaling indicates the remote party only supports
RTP.  Otherwise, an attacker could interfere with your media-plane
key exchange so that you can only run RTP.

> They may need/want an attribute so the offerer can tell the 
> answerer to try it, or other info like a fingerprint, but 
> port-mapping wouldn't be one of them, would it?

Currently zrtp defines its own a=zrtp attribute; it might
make sense to use the portmapping attribute to mean the
same thing ("I can do ZRTP; can you?").

-d

> > > > > > > NOTE:	The mail server at ietf.org can return 
> the document
> in

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 30 Oct 2006 20:55:30 -0500

> Sent: Monday, October 30, 2006 8:14 PM
> To: 'Hadriel Kaplan'; 'Elwell, John'; 'Francois Audet'; [email-masked]

Sure, but you may need to know that you can't do it.  I.e., when you make a
best-effort offer, you may need to know that the answerer has chosen srtp
instead of rtp before the SDP answer comes back, so payload-mapping is the
way. (sorry, I said port-mapping originally but meant payload-mapping)  

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 18:03:01 -0800

> > Security Descriptions probably doesn't need it, either -- it can't
> > do early media unless we resurrect
> > draft-wing-mmusic-sdes-early-media-00.txt or some idea like it.
>
> Sure, but you may need to know that you can't do it.  I.e., when you
> make a best-effort offer, you may need to know that the answerer has
> chosen srtp instead of rtp before the SDP answer comes back, so
> payload-mapping is the way.  (Sorry, I said port-mapping originally
> but meant payload-mapping)

Ok, but what can you do with that new knowledge?  Maybe there is something
useful you can do with the various early media things described in
draft-stucker-sipping-early-media-coping (stop playing the RTP that's being
streamed to you), but I'm not sure I know what it is.

-d