I do think that AIB was (and I stress *was*) potentially a tool that could be used in place of Digest, for example, for the registration use case. Nothing about that work limited it to the end-to-end case. Anyway, the new draft does insist that end-to-end is a requirement.
But that's not really material - my note certainly wasn't an attempt to rekindle or in any way glamorize S/MIME or AIB. It was rather a reminder that no small part of the reason why those mechanisms didn't set the world on fire was because of generic certificate enrollment problems, user mobility requiring mobile certificate management, the implausibility of certificates with SIP identifiers as subjects, and a myriad of similar problems that have little to do with whether authentication is end-to-end or what have you - they are rather rooted in the easily-underestimated difficulty of managing the relationship between SIP users, SIP devices, and certificates. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Friday, June 29, 2007 1:00 AM > To: Peterson, Jon; 'Jonathan Rosenberg'; 'DRAGE, Keith (Keith)' > Cc: 'IETF SIP List' > Subject: RE: [Sip] Certificate authentication in SIP > > > The certificate authentication would be used in place of today's Digest > authentication. > > S/MIME and AIB were never used where Digest is used; I don't see the > relationship between what's on the table now and S/MIME and > AIB -- except > that they are two certificate-based authentication schemes, > S/MIME and AIB > are both intended to work end-to-end (between the two SIP > peers desiring to > establish communication with each other), whereas the certificate > authentication being discussed is to replace ("enhance", > whatever word you > prefer) the username/password digest authentication. Digest > authentication > isn't done between peers establishing communication with each > other (except > in a laboratory environment), but Digest is done to > authenticate yourself to > a SIP network so you can gain authorization to interact with that SIP > network --- and that's what's on the table for certificate > authentication. > > -d > > > > -----Original Message----- > > From: Peterson, Jon [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 27, 2007 1:40 PM > > To: Jonathan Rosenberg; DRAGE, Keith (Keith) > > Cc: IETF SIP List > > Subject: RE: [Sip] Certificate authentication in SIP > > > > > > I also have to admit I'm a skeptical. Various forms of > > non-hop-by-hop authentication with certificates were enabled > > by S/MIME, especially in conjunction with entities like AIBs. > > As far as I'm concerned, the mechanics have had their day in > > court, and it didn't go well. We can grapple with the syntax > > to try to find something slightly different that will > > actually appeal to the implementation community, but I don't > > think the problem was that we had the wrong syntax. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 26, 2007 3:50 PM > > > To: DRAGE, Keith (Keith) > > > Cc: IETF SIP List > > > Subject: Re: [Sip] Certificate authentication in SIP > > > > > > > > > Well, I'm going to be contrarian here. I'm not convinced > > that this is > > > needed. > > > > > > I think certificate based authentication is a great idea. > > > However, I am > > > not sure I understand why TLS is not an appropriate solution. > > > > > > DRAGE, Keith (Keith) wrote: > > > > > > > (As WG chair) > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica > > > te-auth-03 > > > > .txt > > > > > > > > Describes a set of requirements for: > > > > > > > > This document defines requirements for adding certificate > > > > authentication to the Session Initiation Protocol > (SIP). This > > > > document is being presented with the intention of > > providing clear > > > > requirements to any potential solutions specifying > certificate > > > > authentication within SIP networks. Supporting certificate > > > > authentication in SIP would provide strong authentication and > > > > increase the types of possible deployment scenarios. > > > > > > > > (Before we go any further, please forget all about the solutions > > > > document - that comes later and we are not dealing with it now) > > > > > > > > We need to decide whether there is support for a body of > > > work in this > > > > area, and therefore whether we should charter some > > > requirements work in > > > > the SIP WG. > > > > > > > > (Because this is security related we have agreed that > SIP does the > > > > requirements drafting and not SIPPING) > > > > > > > > So can I hear opinions of the WG on: > > > > > > > > - whether this represents a problem space that > the working group > > > > should draft requirements on? > > > > > > > > - whether the problem space exists but is > something slightly > > > > different, and if so what is that problem space? > > > > > > > > - whether there is a more general problem that > the security area > > > > should be addressing, rather than the SIP group > > addressing something > > > > specific? > > > > > > > > - 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? > > > > > > > > - 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? > > > > > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ > > > 07054-2711 > > > Cisco Systems > > > [EMAIL PROTECTED] FAX: > (973) 952-5050 > > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > > http://www.cisco.com > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ 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
