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

"Hadriel Kaplan" <HKaplan@acmepacket.com> Mon, 30 October 2006 02:30 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMvG-0000SG-EV; Sun, 29 Oct 2006 21:30:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMgj-0006iw-SB for mmusic@ietf.org; Sun, 29 Oct 2006 21:15:45 -0500
Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeMgh-0006MJ-D3 for mmusic@ietf.org; Sun, 29 Oct 2006 21:15:45 -0500
Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id A0170614; Sun, 29 Oct 2006 21:14:47 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "'Elwell, John'" <john.elwell@siemens.com>, 'Dan Wing' <dwing@cisco.com>, 'Francois Audet' <audet@nortel.com>, mmusic@ietf.org
Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt
Date: Sun, 29 Oct 2006 21:14:34 -0500
Message-ID: <006001c6fbc9$2530a0e0$0500a8c0@acmepacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acb7O2c3PZUDoigIQoirauJsm96rFQAjOO/g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <50B1CBA96870A34799A506B2313F26670A38D722@ntht201e.siemenscomms.co.uk>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186
Cc:
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org

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

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: Sunday, October 29, 2006 4:20 AM
> To: Dan Wing; 'Francois Audet'; 'Hadriel Kaplan'; mmusic@ietf.org
> Subject: RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-
> 01.txt
> 
> 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:dwing@cisco.com]
> > Sent: 27 October 2006 18:46
> > To: Elwell, John; 'Francois Audet'; 'Hadriel Kaplan'; mmusic@ietf.org
> > 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:john.elwell@siemens.com]
> > > Sent: Thursday, October 26, 2006 11:07 PM
> > > To: Francois Audet; Hadriel Kaplan; mmusic@ietf.org
> > > 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:audet@nortel.com]
> > > > Sent: 27 October 2006 01:22
> > > > To: Elwell, John; Hadriel Kaplan; mmusic@ietf.org
> > > > 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:john.elwell@siemens.com]
> > > > > Sent: Thursday, October 26, 2006 5:56 AM
> > > > > To: Hadriel Kaplan; Audet, Francois (SC100:3055);
> > mmusic@ietf.org
> > > > > 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: Internet-Drafts@ietf.org
> > [mailto:Internet-Drafts@ietf.org]
> > > > > > Sent: 25 October 2006 20:50
> > > > > > To: i-d-announce@ietf.org
> > > > > > 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
> > > > > > i-d-announce-request@ietf.org 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:
> > > > > > 	mailserv@ietf.org.
> > > > > > 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
> > > > > mmusic@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/mmusic
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > mmusic mailing list
> > > mmusic@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mmusic
> >


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic