(removed some direct CC's.) > -----Original Message----- > From: Steve Dotson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 03, 2007 2:13 PM > To: Sumanth Channabasappa; Peterson, Jon; Dan Wing; Jonathan > Rosenberg; DRAGE, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Certificate authentication in SIP > > Jon, > > I don't want to downplay the challenges of certificate > management. However, with TLS gaining traction in different > forms, it would seem these issues are being faced already. > There are current PKI deployments that could leverage > existing investments, and certificates are starting to be > used and/or required in different ways in the SIP and mobile > space. Using large IPsec deployments as another example, some > operators are perfectly fine with managing IPsec > relationships with shared secrets, and some see the benefit > of certificates. > > I honestly don't have much background on the "issues" with > S/MIME or AIB, and we very well may find after discussing the > requirements that an existing solution could be enhanced to > meet the requirements. We are obviously open and encourage re-use.
AIB copies the headers into a separate MIME part and uses S/MIME to sign that part. The unfortunate lack of MIME support in SIP is a significant barrier to the successful deployment of anything using multipart MIME messages, such as AIB. From the last SIPit, http://www.sipforum.org/content/view/287/171/: > > 2% I break if someone sends me multipart/mime > 24% I pretend multipart/mime doesn't exist if someone > sends it to me > 24% I ignore multipart/mime but will proxy it or hand > it to my application if it shows up > 10% I try to do something useful with multipart/mime I > receive, but I never send it > 4% I ignore multipart/mime that I receive, but I try > to do something useful with multipart/mime I send > 24% I try to do something useful with multipart/mime I > send and receive > 12% Other > If you re-used AIB just for Register, the situation may be better, as you only need the SIP proxy to ignore the multipart portion of the message. You might also read draft-camarillo-sip-body-handling-01.txt on this topic. -d > Thanks. > > Steve. > > ________________________________ > > From: Sumanth Channabasappa [mailto:[EMAIL PROTECTED] > Sent: Friday, June 29, 2007 7:35 AM > To: Peterson, Jon; Dan Wing; Jonathan Rosenberg; DRAGE, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Certificate authentication in SIP > > > Jon, > > > 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. > [S] Would this not be part of the reason that we want to > tackle this problem? There are large deployments which use > certificates successfully today (such as cable clients). > There are potential deployments which would like to use > certificates for authentication in SIP networks, without a > specified explicit way to do this (or perhaps, lack the > understanding). Now, certificate management is a valid > concern, and potentially a hard problem, but that is only one > part of the puzzle (and may not apply to all deployments). > > I think we should start by identifying the requirements > (since there seems to be some confusion; and the I-D has not > been discussed in the WG) and see if existing or new > solutions are required. And if we find that certificates need > some work to support this initiative (e.g., SIP identifiers > as subjects), perhaps we can present some of those > requirements to other WGs. If we find an existing solutions > that can be used, good (and we can document them as such :) ). > > - s > > > > > 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 <http://www.jdrosen.net/> > PHONE: > > (973) 952-5000 > > > > http://www.cisco.com <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 > > > _______________________________________________ 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
