> I must confess that on an initial reading of the draft, I was > lost on the need for requirements that add certificate > authentication to SIP. Using TLS, a registrar and a UAC and > exchange certificates today and authenticate each other, > without resorting to a shared secret, right?
With TLS, the UAC can authenticate its proxy, yes. But the establishment of a TLS session, even mutually-authenticated TLS (which is not mandated by RFC3261, by the way) doesn't inheriently provide authentication of the REGISTER message. I suppose it _could_, but we don't have that written down anywhere that I'm aware of. > I beleive the use case that the author is going for has to do with > using the hop-by-hop signaling path through a SIP proxy mesh to a > registrar, but being able to exchange certificates directly > between the UAC and the registrar. Yes, exactly. -d > As such, the title of the > draft ought to be reflective of this; something along the lines > of "Requirements for direct registrar authentication in the > Session Initiation Protocol (SIP) by a User Agent Client (UAC)". > > > - whether the problem space exists but is something slightly > > different, and if so what is that problem space? > > If the problem space is defined as coming up with requirements > for direct registrar authentication in SIP by a UAC over a > normal SIP proxy mesh, then that is a reasonable problem space, > IMHO. > > > - whether there is a more general problem that the security area > > should be addressing, rather than the SIP group addressing something > > specific? > > I beleive that this is fairly specific to SIP, but will defer > to the chairs and the rest of the WG. > > > - based on your answers to the first three questions, whether this > > draft is essentially in the right direction to be adopted as the WG > > draft assuming we create the charter item, or whether we > > need to seek some other input draft? > > This draft also talks about interpreting the contents of the > certificates (S3, requirement 8). As such, some of the work Scott > Lawrence and I have done in domain-certs provides more > guidelines on this particular aspect. We received good feedback > from the pkix WG in Prague when we presented domain-certs > there; we are in the process of revising the domain-certs draft > to include a discrete set of steps that can be programmed to > do certificate validation. We should be sending a revised > version of this draft out by tomorrow. > > > - and finally, whether (assuming we go ahead with this work) there > > is any work in any other IETF WG that we should take account of? > > domain-certs, as mentioned above. In addition, sip-sipsec could > provide a possible solution set; it appears to fit some of the > requirements. > > Thanks. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: [EMAIL PROTECTED],bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
