On Jun 1, 2007, at 11:29 PM, Lakshminath Dondeti wrote:
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).
It is not clear any changes are needed but it is possible that the RTPSEC solution might end up using the TLS extractor work. Once the specific changes are clear we can decide if it would need a milestone update, charter update, or nothing in TLS. It is clear that the TLS WG is the place that has the best affinity with the security expertise to review this work.
(I have no idea what you mean about surprised by hurried up process as what happened in Prague was actually more or less a meeting late from what we agreed to do in Montreal but never mind that. )
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.
Well, before the Montreal BOF would have been the place and time to bring up that requirement. Luckily, I think you are pretty safe in that this requirement is supported by the solution we are on. SIP allows an INVITE to have and offer and also allows INVITES without an offer where the UAS sends the offer. I think this will meet your requirement.
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?
Clearly this works needs both security and avt review. Some of the reasons it needs AVT review has to do with the multiplexing of the packets and the impact that has to existing RTP systems. The actually security related changes that this work implies to DTLS are relatively small given it does not change how any of the security works, just how the bits are encoded in the transmission. The RAI and SEC ADs thought about this for awhile and came to the conclusion that we needed to have somewhere to review it, quite likely about the same people will review it no matter where we do it, and it looked more like AVT than TLS.
The really important thing is all the ADs are in agreement with you that this does need both security and rai people to look at it.
thanks, LakshminathMMUSICProvide 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>