Re: [Sip] Are we having an Identity crisis?

["Elwell, John" <john.elwell at siemens.com>]

Dean,

Agreed, and several of the recent drafts focus on defining the problem,
rather than a solution.

John 
 

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip