On 6/2/2007 8:26 AM, Cullen Jennings wrote:
On Jun 1, 2007, at 11:29 PM, Lakshminath Dondeti wrote:On 5/11/2007 10:42 AM, Cullen Jennings wrote:Hi All,
<snip>
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.
Are you suggesting that we have added no requirements to the mix after the Montreal BoF? Aren't we still tweaking them? Did I miss the last call for requirements? This is another surprise to me btw and I am following the list and attending all the meetings.
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.
The problem is simply that we are going ahead with a strict client-server imposition on the parties to the communication. For general purpose use, we need to start thinking a little bit broader (see the example of IKEv2). I made a note of this issue at the meeting in Prague and perhaps earlier too.
regards, Lakshminath
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>