Subject: [Sipping] comments on draft-peterson-sipping-retarget

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Mar 2005 00:48:35 -0500

Overall, this is a great draft. It crystallized for me, at least, the 
security issues involved in retargeting. I'm convinced that a signature 
over the response identity is pointless, and I think that was one of the 
main objectives of your draft.

The main question for me, though, is the level of trust that is implied 
by a client sending an INVITE. What does it trust the proxies to do? It 
seems that for SIP to work, we need to at least trust that a proxy 
properly executes SIP routing. If you can't trust proxies to do that, I 
don't see how to build a workable system at all. If you do trust proxies 
to do that, then in conjunction with sips, you can trust the connected 
party identity in the response by nature of its passage along the TLS 
connections between proxies. Now, I know you feel that sips has been 
neutered due to TLS being SHOULD not MUST, but let us leave that separate.

We have already begun to build many other mechanisms which rely on this 
kind of trust; app-interaction, transfer, and many other features rely 
on awareness of the dialog identifiers as a tool for authorization, when 
such a call is made using sips.

Some specific comments on the doc:

The analysis in the introduction states that retargeting is more common 
then redirect because of efficiency. But I dont see how that is the case 
at all. A server that proxies has to handle a server transaction AND a 
client transaction, one that redirects only handles a client 
transaction. Thus, the overall amount of work on the server is roughly 
half for redirect compared to proxy. This work moves to the UAC, which 
pays for the extra client transaction.

The introduction also talks about the primary problem being that you 
can't trust the intermediaries to properly retarget. However, if you 
can't trust the proxies, you can't trust them to redirect instead of 
retarget...

Section 2.1: its interesting to note that the legitimacy issue is 
solvable if you turn the trapezoid back into a triangle. In that case, a 
client would only ever send a request with a URI sip:[email-masked] to 
a server whose TLS credentials are example.com. In other words, the 
legitimacy issue is not a fundamental problem in SIP, its a consequence 
of the usage of outbound proxies and other proxies between a client and 
a server in the domain for the user that is being reached. I'm not 
arguing against the trapezoid model, I just think that this section 
needs to be clear on what the root cause is.

Section 2.2: you talk about alice needing to make policy and 
authorization decisions based on the resonse. What kinds of decisions 
and authorization policies? Its too late to make decisions once the 
response has arrived; I'm not sure what use cases you had in mind. I 
think security properties of the response are needed - mainly integrity 
in order to avoid various mitm attacks. But thats not the same as 
authorization.

Section 2.2.1: This is good stuff, really helps make your argument 
clear. I think it could benefit from some more specifics - show 
different attacks, like mitm and a faked response, and show how response 
identity doesnt help.

Section 2.4, bottom of page 10. The text ends abruptly here.

Section 2.5: why would this challenge occur in the first place? Normally 
on your outbound proxy generates a 407. Sure, another one COULD, but 
alice isn't going to have credentials for biloxi or cleveland, so what 
is the point?

Section 4: another benefit is reduced call setup times.

Another big issue here is the billing issue. Like it or not, the view in 
many providers is that if A calls B and B forwards to C, then B foots 
the bill for the B to C costs. That is feasible in the retargeting case. 
I don't know how to do this in the redirect case.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Mar 2005 11:39:53 -0600

On Mar 3, 2005, at 11:48 PM, Jonathan Rosenberg wrote:
>
> The analysis in the introduction states that retargeting is more 
> common then redirect because of efficiency. But I dont see how that is 
> the case at all. A server that proxies has to handle a server 
> transaction AND a client transaction, one that redirects only handles 
> a client transaction. Thus, the overall amount of work on the server 
> is roughly half for redirect compared to proxy. This work moves to the 
> UAC, which pays for the extra client transaction.
>
>

In addition to the work moving to the UAC, the additional traffic moves 
to the UACs air interface, which is something that the wireless 
operators (bug users of SIP) are keen to avoid.

> can't trust the proxies, you can't trust them to redirect instead of 

The problem we have is that the "target identity" as expressed in the 
URI is not maintained through the SIP routing process. I've come to 
believe that a response needs to be validatable against the 
request-URI. We have this property with https URIs -- if the hostname 
in the cert I get in the response doesn't match the hostname in the 
request, my browser complains and asks me to make a decision.

So if this "end to end reflexivity of identity across a request" 
property were true, we COULD validate that the intervening proxies had 
behaved properly in both redirecting and retargeting cases.

Without it, we can't verify retargetings at all. We can partially 
verify redirection, in that we get to at least validate the identity of 
the next hop in the redirect chain.

> solvable if you turn the trapezoid back into a triangle. In that case, 
> a client would only ever send a request with a URI 
> sip:[email-masked] to a server whose TLS credentials are 
> example.com. In other words, the legitimacy issue is not a fundamental 
> problem in SIP, its a consequence of the usage of outbound proxies and 
> other proxies between a client and a server in the domain for the user 
> that is being reached. I'm not arguing against the trapezoid model, I 
> just think that this section needs to be clear on what the root cause 
> is.
>

Redirection (in the absence of retargeting) has the effect of reducing 
the size of a n-element connectivity graph by one with each application 
-- thereby reducing the initial trapezoid to a triangle.

The problem remains that there is no way for the UAC to validate the 
operation from the proxy to the UAS on the "back side" of that 
triangle. We have to truest that it did the right thing. Jon's argument 
is that in the absence of a requirement for transitive TLS (sips) 
across that triangle, there is no basis for us to trust the proxy. My 
extension to the argument is that I just don't trust proxies to meet 
their requirements anyhow, so even if transitive TLS were required, I 
wouldn't feel we had gained anything.

> think security properties of the response are needed - mainly 
> integrity in order to avoid various mitm attacks. But thats not the 
> same as authorization.

Too late? Not at all. Alice calls Bob. Charlie, no friend of either, 
answers the call using a digitally replicated Bob voice. Alice sees the 
response identity was not Bob, and hangs up.

How did Bob make that attack work? I dunno. Maybe he tricked the mobile 
network into accepting a REGISTER using a hole in the VLR to REGISTRAR 
interface. But IF we have strong response identity and Bob's 
credentials are not completely compromised, Alice should be able to 
detect the attack.

> Another big issue here is the billing issue. Like it or not, the view 
> in many providers is that if A calls B and B forwards to C, then B 
> foots the bill for the B to C costs. That is feasible in the 
> retargeting case. I don't know how to do this in the redirect case.

What we need here is a response identity that says "C received this 
call because C was authorized to do so by B, and here's the cryptoproof 
that both B and C are authentically participating in this 
transference".

In the redirect model, B couldn't redirect A to C and get the billing 
behavior you propose. Instead, B could redirect A to a service (a B2BUA 
is one way to model it) that would connect A to C and handle the 
billing. A would at least know that he wasn't talking to B here, but 
was instead talking to a "proxy for C appointed by B that B thinks 
should be trusted" (using "proxy" to mean "stand-in", in the legal 
sense of "proxy"). Not an incredibly strong assertion, but since B is 
footing the bill (and we don't yet have response identity), all you're 
likely to get . . .

--
Dean