On 5/11/2007 10:42 AM, Cullen Jennings wrote:
Hi All,I have talked to the RAI and SEC ADs and here is the rough plan for how I would like to move forward with this. I would like to split the work off into the following working groups.TLSMake any modifications that may be required to DTLS to allow DTLS to generate the keys for SRTP.
I haven't followed the TLS working group closely over the years, but I don't recall DTLS being a TLS WG product. In any event, DTLS is not part of the TLS charter. Are we talking about rechartering that group to include this item? When will that happen? For the record, this work is not high priority on my list, but I am curious about the timeline. I would like to be not surprised by a suddenly hurried up process (e.g., the "decision making" at the Prague meeting).
One of the things I would like to see done is to make the protocol truly peer-to-peer, or put another way, either side can initiate and more importantly allow requesting the other side to authenticate first. One of the applications I recently came across has the Caller having the Callee authenticate first and within the resulting secure channel use a legacy method to authenticate itself.
AVTDescribe how DTLS is used to key SRTP and how SRTP is used in combination with DTLS. This includes the issues of multiplexing DTLS and SRTP on one port. draft-mcgrew-tls-srtp will be the starting draft for this.
My take is that draft-mcgrew-tls-srtp specifies a DTLS extension for SRTP and thus belongs in a security area WG, and not in AVT. Of course, this kind of thing is up to the AD. But I wonder if you are willing to share your thought process in arriving at this conclusion. Specifically, why do you think that the AVT WG is a better place to get the necessary reviews for this work?
thanks, Lakshminath
MMUSICProvide a scheme for transporting DTLS fingerprints in SDP offer/answer (suspect this is already done but it not, MMUSIC does it). Provide a scheme that allow an offer to say it is willing to do SRTP or RTP but would prefer SRTP. The ongoing draft-ietf-mmusic-sdp-media-capabilities work should meet this need.RAI/SECWrite overview document on how SIP UA can secure media using combination of DTLS/SRTP, SDP Fingerprint, Identity, Outbound, and Digest and TLS for SIP. This document will not describe new mechanisms, it just provides the roadmap of how they all fit together. Jon Peterson has the token to start this.Cullen <with my AD hat on>