Re: draft-kuthan-sip-derive

I've spent quite a bit of time over the past few days pondering the 
approach laid out in the DERIVE draft. I think the approach of using 
some form of "dial-back" to confirm identity has some merit (with a few 
very strong caveats). I think the idea of leveraging already-defined 
behavior is a good idea and somewhat clever; however, I suspect that the 
exact mechanism defined in the current draft is not yet well enough 
deployed for us to accept the limitations that it imposes.


The Need For User-Visible Caveats
=================================

As we've seen with the XMPP system, dial-back approaches can be used 
with a fair amount of success to prevent certain types of identity 
spoofing (see XEP-0220). Caveats associated with this approach in 
general include reliance on security of the DNS and IP routing systems. 
We have seen real-world attacks on bot h in the past [1][2], so we need 
to make sure that user expectations for any dial-back system are set 
appropriately.


SIP and Return Routability of AORs
==================================

However, when the flexibility of SIP routing is thrown into the mix, the 
ability to reliably route back to the calling user's specific device 
using that user's AOR becomes a much larger issue.

For example, a caller at a call center my well advertise a calling 
identity that reflects the contact point for that call center as their 
"From" identity. However, calls made to that identity will either reach 
an IVR or be dispatched to a random call center device that has no 
knowledge of the calling party's dialog. Other normal subscribed 
services, such as time-of-day routing, can have similar results. 
Further, interaction with find-me-follow-me services -- or, really, any 
service with serial forking -- can potentially result in dramatic 
post-dial-delays that make execution of such a call-back service infeasible.

All of which is to say: any dial-back attempt using an AOR may 
legitimately reach a device (or several devices) without reaching the 
calling party's actual device. I would therefore assert that any 
dial-back based strictly on AOR can at best confirm the veracity of the 
"To" header field (with the DNS and routing caveats I mention above). It 
cannot, under any circumstances, *refute* a claim.


Dialog-Package Re-Use
=====================

The actual use of the dialog event package in the DERIVE draft is 
clever. The idea of being able to deploy a system based on what is 
already in the field is very attractive, as it allows us to put the 
solution into play immediately. However, based on results at SIPits, it 
is supported by somewhere less than 50% of current UA implementations 
(the estimate I got was "probably about one out of three").

That's actually not a bad percentage, especially considering that the 
incidence of dialog package implementation should only go up -- it has 
immense value in a number of useful services. However, the behavior that 
the dialog event package needs to exhibit to support DERIVE is not 
sufficiently well defined in RFC 4325. We've had a number of SIP experts 
weigh in on the SIP mailing list with widely differing opinions about 
how UAs *should* operate. And if *we* can't figure it out, I can 
guarantee that implementors have done... let's use the work 
"innovative"... things in this space.

In other words, I fear that whatever gains we achieve by re-using the 
dialog event package are largely negated by the fact that we're using 
the very aspects of it that have been most poorly specified.


Potential Alternate Approaches
==============================

If we don't re-use the dialog event package as-is, then we need to 
either find some other widely-deployed, well-defined UA behavior that we 
can leverage, or we need to define new behavior on both the caller and 
callee equipment. I can't immediately think of a solution that falls 
into the former category -- perhaps someone else can come up with 
something clever. That leaves defining some new mechanism to address a 
call-back mechanism. Jiri has suggest defining a new method for 
call-back validation, and I think this is a reasonable approach.

Regardless of the approach taken, I would suggest that we should 
leverage the use of public GRUUs to assist with routing to the proper 
device. Devices that validate the identity of an incoming request can 
render the public GRUU (with the ;gr parameter stripped) as the calling 
party identity after they use it to reach the exact calling device. With 
GRUUs thrown into the mix, we get around the issue of potentially being 
unable to reach the calling party devices -- this allows us to return 
actual negative hits in addition to positive hits.

In fact, if the calling party is using a GRUU, we might be able to 
achieve some interesting results by taking the GRUU out of the Contact 
header-field of the INVITE and sending back an innocuous in-dialog 
request of some kind (UPDATE? OPTIONS? Dare I say INFO?) *without* any 
route headers to see whether we get a 481 response...


Conclusion
==========

In short, I support work towards dial-back "better than nothing" style 
security. And, while I commend the authors of DERIVE for their 
ingenuity, I fear that the dialog event package is a poor enough fit 
that we should explore other alternatives before going too far down this 
path.

/a


[1] 
http://arstechnica.com/news.ars/post/20080225-insecure-routing-redirects-youtube-to-pakistan.html
[2] 
http://arstechnica.com/news.ars/post/20071212-dns-poisoning-used-to-redirect-unwitting-surfers.html
_______________________________________________
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