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
