On Fri, Dec 5, 2008 at 12:34 PM, Elwell, John <[EMAIL PROTECTED]> wrote: > Jiri, > > It is well-known that I am not comfortable that we have a **deployable** > solution for preventing From URI spoofing. The reason it is not > deployable is because of B2BUAs, and to some extent because of > E.164-based URIs and the way they are handled in practice. Furthermore > there are issues with PSTN interworking, but we can't do much about > that. > > I have tried to articulate these issues by means of several I-Ds over > the last year or so, but capturing a "problem statement" acceptable to > all seems to be an elusive goal. > > The reason seems to be that if I describe the problem in a certain way > (e.g., B2BUAs break the RFC 4474 signature), people say "but we can get > round this by doing A", so the problem statement has to be extended to > say why A doesn't work, and then people say "but you can get round it by > doing B", so the problem statement has to be further extended to say why > B will not work, and so on ad infinitum. > > So I would welcome any other attempts to write the problem statement.
The whole identity problem cannot be solved in one shot. IMO the scope of DERIVE is very limited, which I consider to be a good thing if we really want to have a deployable solution. Starting from the very beginning, I'm wondering if folks agree that: - From URI spoofing is a problem - Existing mechanisms present some shortcomings (see draft-elwell-sip-e2e-identity-important) - An "as much end-to-end as possible" solution is desired - This solution is desired to be *simple and deployable* - In the absence of some sort of authentication mechanism, URI verification is "better-than-nothing" - A "better-than-nothing" approach to URI verification may provide the desired level of simplicity and deployability. - The used mechanism should work on a per-session basis. This might be done by using any unique session-identifier/token shared between the calling and the called parties. I'd like to hear your opinions on this. Cheers, -- Victor Pascual Ávila _______________________________________________ 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
