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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Mar 2005 13:27:47 -0500

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Jonathan Rosenberg
> Sent: Thursday, March 03, 2005 9:49 PM
> To: sipping
> Subject: [Sipping] comments on draft-peterson-sipping-retarget
> 
> 
> 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.

I was trying hard not to draw any premature conclusions in the draft, but I am definitely sympathetic to arguments that solving for response identity would be more trouble than it is worth given the magnitude of the addressed threat.

> 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. 

I think there is an important distinction we need to make between trusting "proxies" and trusting a -specific- proxy server, for instance, the one that happens to be responsible for the domain indicated by the target URI. Unambiguously, there are certain things which that specific (logical) proxy server is authorized to do (like changing the target of the request) that other proxies may not do. Of course, if you can't trust that specific proxy to do its job, you can't build a workable SIP system at all. However, in many architectures there are other intermediaries in the path of SIP requests, ones that are, for practical purposes, unnecessarily with respect to routing SIP requests. As the service hijacking example in sipping-retarget hopefully illustrates, there are very plausible reasons why those proxy servers might behave in ways that go against the normative constraints of RFC3261, and which the UAC certainly does not authorize and essentially cannot detect. One of the questions my draft poses regarding this situation is "can we do better?" If we can't, then we might as well just say that any proxy can retarget requests arbitrarily - then implementers and users will at least be aware of the reality of the situation.

> 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.

I believe that improving channel security (SIPS being an example of that) is one valid approach to the response identity problem. If you are concerned about impersonators forging responses, those impersonators would first need to capture signaling to learn transaction/dialog identifiers and so on, and channel security reduces that risk - perhaps to a tolerable level. It will not, of course, protect against rogue intermediaries... and there are some risks in that space worth considering, anyway.

> 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.
> 

I am happy to cast doubt on that argument, but it is a commonly-used one. In particular, I think I used the term "messaging efficiency" - the argument is that more total messages and RTTs and so on are incurred by redirection that proxying.

> 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...
> 

The differences are enormous, actually, in so far as you can actually see -which- intermediary redirects, but you cannot determine which intermediary retargets. Because you can see which intermediary it is, you can determine whether or not they are actually authorized to change the target of the request. I don't think you can be said to trust an entity taking an action during routing the call if you don't even know who that entity is...

> 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.
> 

Well, I'd prefer not to split hairs about which is really the root cause here. I agree that if triangle-routing were the only permitted mode in SIP, then retargeting would never occur and this problem would never arise (this is of course one possible "solution" to response identity). Clearly, if the local outbound proxy were in some respect completely constrained from changing the Request-URI, again this problem would never arise. The apparent need to allow for unnecessary (from a routing perspective) intermediaries could be said to be the root cause of almost all of SIP's intractable security problems.

> 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.

I think I'm within my rights in referring to policy decisions made regarding authentication information (i.e. identity) as authorization decisions. Surely "response identity", if it existed, would only be useful in so far as it fed into some kind of authorization decision. In a three-way handshake transaction, I suppose Alice might choose to CANCEL rather than ACK if there was some identity defect in the 2xx response - that would be one kind of policy that might be enforced after the fact. If in your case there was an integrity failure indicating the presence of a MitM, I imagine similar action would be taken.

> 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.

I'm sure it could all stand to be flushed out and polished a bit, yes - I thought it was important to get these ideas out there with the limited time I had before I-D cutoff, and thus we are left with the current form.
 
> 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?

I wish there weren't proposed architectures in which this was a plausible case: I might cite the familiar hotel proxy that interposes itself between you and your home domain (your "actual" outbound proxy), or something like that. Another example might be a proxy that controls admission to a farm of PSTN gateways, or something.

> Section 4: another benefit is reduced call setup times.
> 

That's the "messaging efficiency" bit, yes. Perhaps "reduced call setup time" is the right way to describe it.

> 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.
> 

Well, it isn't clear to me prima facie that retargeting, or SIP signaling at all, is the right way to communicate settlement information, but I hear what you're saying. I could wheel out a list of other plausible technologies here (SAML comes to mind), but ultimately, if people's requirement is that they be able to retarget, then one can't answer that requirement with redirection.

> 
> -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
> 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2005 14:53:16 -0500

> The differences are enormous, actually, in so far as you can actually see -which- intermediary redirects, but you cannot determine which intermediary retargets. Because you can see which intermedia…

How is it that the UAC can *see* which intermediary redirected?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2005 15:43:40 -0500

I thought about this a bit more. If alice is calling [email-masked] and 
receives a 3xx, to demonstrate it is valid it should be signed by either 
example.com. (Or [email-masked].) There would have to be a new 
mechanism for an intermediary to do this.

If there was such a mechanism, then why can't example.com also sign the 
response of a retargeted request? (E.g. the first response that 
establishes a dialog.) This would signify that a party responsible for 
example.com approves of whatever destination this request reached.

Suppose example.com retargetted to [email-masked]. Assuming that is 
an AoR, its likely the request will in fact be retargeted twice - first 
by example.com toward [email-masked], and then by example.org to 
charlie's phone. In that case, the response could be signed by both 
example.com and example.org, indicating that they both approve of the 
path taken. It is quite likely that example.com would require the 
signature of example.org before it would apply its own signature.

Note that these signatures aren't quite the same as those of the 
identity draft. These are just assertions by a responsible party for a 
domain that it has been involved and the transaction is according to its 
expectations.

There could also be a connected-party-id for charlie, signed by 
example.org. This may be used by alice just to understand to whom she is 
talking, or to disconnect if she is dissatisfied. It could also be used 
by example.com in deciding whether to apply its signature to the response.

	Paul

Paul Kyzivat wrote:
>> The differences are enormous, actually, in so far as you can actually 
>> see -which- intermediary redirects, but you cannot determine which 
>> intermediary retargets. Because you can see which intermediary it is, 
>> you can determine whether or not they are actually authorized to 
>> change the target of the request. I don't think you can be said to 
>> trust an entity taking an action during routing the call if you don't 
>> even know who that entity is...
> 
>