Dean, Agreed, and several of the recent drafts focus on defining the problem, rather than a solution.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: 19 July 2008 08:34 > To: SIP IETF > Subject: [Sip] Are we having an Identity crisis? > > > We seem to have some disagreement as to whether we have any issues > with SIP Identity, aka RFC 4474, which defines a certificate-based > authentication service for authentication and partial integrity > protection of SIP messages. > > Some people seem to think the existing approach is complete and > satisfies all the use cases that we believe to be real. > > Others believe that the SBC re-signing use case is either bogus or > requires too much crypto work on the SBC to be useful. > > Others ask "Just exactly how is it you think RFC 4474 is supposed to > work with a transit SBC that is in neither the originating nor > terminating domain and that has no contractual trust agreement with > either?" > > I think we have SOME sort of problem, else we wouldn't have nearly a > dozen related drafts kicking around the archives. But as I said, we > lack universal agreement on the existence of such a problem, and we > certainly lack consensus on use cases that illustrate the problem. > > So it seems to me that before we launch into solutions to the > problem > (which the SIP working group isn't chartered to do), that we should > develop a consensus on what the problem is and what requirements we > would place on a solution. > > Is this something we can do? > > From a "charter" perspective, I believe it is. > > Our charter says: > > ------------- > Specific deliverables toward these goals include: > > 1. Mechanisms for secure expression of identity in requests and > responses. > > 2. Mechanism to securely request services delivery by non-terminal > elements ("end-to-middle"). > > 3. Guidelines for use of existing security mechanisms such as TLS, > IPsec, and certificates. > > 4. Guidelines for the use of descriptive techniques such as SAML > (Security Association Markup Language) with SIP. > > 5. Draft standard versions of SIP and critical supporting > specifications. > -------------- > > RFC 4474 certainly does nothing for identity in responses, so it > doesn't meet the requirement of our charter. so work on responses is > clearly in the scope of the charter. And note that the > charter doesn't > say "A mechanism" but "mechanisms", so revising RFC 4474 or > documenting an alternative is arguably within the scope of > our charter. > > > Is developing the requirements for #1 above something we can > actually > accomplish with a strong consensus? I hope so. > > But do we have the political will to achieve such a > consensus? That's > what I'd like to hear from you. > > -- > Dean > _______________________________________________ > Sip mailing list https://www.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://www.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
