Subject: RE: [Sip] RE: Identity after reinvite

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 16 Nov 2004 16:46:19 -0500

> > The problem is that, due to retargeting, the URI in the To field of the 
> > INVITE may not identify the user that was eventually reached. In RFC 
> > 3261, requests from the called party to the caller carry the value from 
> > the original To field in the From. As a result, the requests will have a

> > From field value which does not actually correspond to the originator of

> > the reuqest.
> Very good point!

This is a more significant problem with mid-dialog requests and the request
identity system, agreed.

>  > The identity service will then reject these requests.
> 
> Hmm. Will the request be rejected, or will it just not get a 
> authentication that it is valid? I suppose that is local policy. It may 
> be necessary to permit this, without authentication, just to avoid 
> breaking these common scenarios.

Yes, this is the crux of the matter. The text in Section 6 of
sip-identity-03 says the following:

   If the identity field contains a SIP or SIPS URI,
   the authentication service MUST extract the hostname portion of the
   identity field and compare it to the domain(s) for which it is
   responsible...
   If the authentication service is not responsible for the identity in
   question, it MAY handle the request normally, but it MUST NOT add an
   Identity header; see below for more information on authentication
   service handling of an existing Identity header.

So it isn't that the auth service will reject the request; it MAY just
forward the request normally. What will happen in that instance? Well, if
the auth service role is instantiated by a proxy server, it will forward the
request in accordance with the URI without adding an Identity header; it
won't challenge the request, or what have you.

> > The solution, which rfc3261 warns of, is that a UA has to put its actual

> > identity in the From field URI, not what it saw in the To field of the 
> > original request.
> 
> Yes, this would be a good solution, if we can sort out the compatibility 
> issues getting to it.

I am extremely wary of predicating request identity on solving the
connected-party problem, in part because I believe doing so will dictate a
direction for the response identity problem. If we go down this path here
(changing the From header field value), we will be forced to do the same for
response identity. I think this is the wrong approach, as sip-identity-02
suggested; I think we are sacrificing certain valuable security properties
for the long term if we go down this path.

I have a number of arguments about this, but here are just three:

- Identity will succeed in the marketplace if it can be used
opportunistically. Requiring UAs to change the From header field in this
fashion forces them to become identity-aware, which is an impediment to
adoption. Basically, we force UAs to be either backwards-compliant with
RFC2543 or compliant with Identity. Tough choice, especially given that the
UA might not be aware of its need to be either of those things.

- I also question whether or not the callee UA will even know which identity
it needs to stick in the From header of requests in the backwards direction:
after all, if the UA is registered under multiple AoRs, what exactly about
the dialog-forming request will tell it definitively which identity it is
supposed to use? While in some cases, this could be inferred from the
Request-URI of the dialog-forming requests, it won't be sufficient in all
cases, I think. The previous hop (last proxy server to handle the request)
might also be a hint. Now, it could be that there's a good answer to this
question, but if so, we need to know that answer.

- Retargeting is inherently insecure, and no amount of wiggling with the
sip-identity mechanism will repair this. If Alice sent a request to Bob, and
a new request in the backwards direction comes from Edgar, I think there is
-no- circumstance in which Alice should not view this as a potential
security risk, regardless of the presence or absence of an Identity header,
SIPS, or what have you. Trying to explain this aware flies in the face of
common sense, and will be incomprehensible to actual users who will need to
make security decisions based on the evidence collected from the protocol by
their user agent.

> > This will break all compatibility with rfc2543, but
> > will work with other rfc3261 compliant endpoints, since the URI is no 
> > longer used for dialog identification.
> 
> If we were going to switch to this, then it could begin with the first 
> response to the invite. That would be the first step to really solving 
> the connected-partiy-id problem.

Not just 'could begin' but 'should begin'. If the identity you see in the
response to the INVITE does not equal the identity you see in requests in
the backwards direction, I believe that is extremely problematic. Yes, this
is what I mean by solving the response identity problem.

> > Doesn't sips prevent that? With sips, you won't be able to identify the 
> > called party from the 200 OK, but it will guarantee that no one except 
> > the party you reach can terminate the call.
> 
> Well, if there are multiple hops that isn't proof against every possible 
> attack. But it certainly makes it harder. And the kinds of attacks that 
> would work here could probably just as well compromise the 
> authentication server itself.
> 

Don't forget, for example, that SIPS does not apply after the domain
indicated by the Request-URI of the request, and so on. SIPS is not a
powerful mechanism. Until we all acknowledge that we were mistaken in our
formulation in RFC3261, and that SIPS, when present, signifies unambiguously
that TLS should be used end-to-end, I do not think SIPS can be said to solve
any of our problems. Once we have the connect-reuse mechanism nailed down
firmly, I think it will be possible to shift to that understanding of SIPS,
if we want to.

> > Indeed, it occurs to me that one can "simulate" response identity by 
> > having the called party send an UPDATE or nearly any other request in 
> > the reverse direction immediately upon receipt of the ACK. If you 
> > structure the From field of that request as I have proposed above, the 
> > net result provides a form of response identity - it tells you who was 
> > reached. This doesnt tell you *why* it was reached (as redirection 
> > would), but it seems valuable nonetheless.
> 
> As I mention above, if the To were changed in responses, then the caller 
> would know right away, without the extra request. But it wouldn't be 
> signed. However then the way forward would be clear - have a callee 
> suthentiation server sign the To header of responses.
> 

Yet more justification for the idea that this solution must share its core
with our longer-term response identity mechanism.

> >> There is a very important distinction in sophistication between an
> >> attacker who can merely formulate a plausible dialog-forming request
with an
> >> inappropriate From header field versus an attacker who can capture
> >> dialog-forming requests and improvise appropriate responses (with
correct
> >> tags, correct Call-ID/CSeq, etc).
> > 
> > sips, of course, prevents this fully.

SIPS would be sufficient if it were not crippled by restrictions about the
final administrative domain, and the ambiguity about finality in the context
of retargeting.

Jon Peterson
NeuStar, Inc.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Nov 2004 18:05:47 -0500

Jon,

One of your key points below seems to be to resist tying any of these 
remedies to the identity draft itself. I have no problem with that - 
despite the remaining problems the identity feature does add value and 
need not wait for solution of the other problems. I didn't intend to 
imply otherwise.

More comments below.

	Paul

> won't challenge the request, or what have you.

Good. You confirm what I was assuming.

> for the long term if we go down this path.

I agree the basic request identity problem is separable from the others. 
But it does seem that connected-party, response-identity, and reverse 
direction requests in dialog are all entangled, and that changing 
to/from may be a single solution good for all of them.

> UA might not be aware of its need to be either of those things.

Agree.

> question, but if so, we need to know that answer.

There are many reasons why a UA with multiple registrations needs to 
know which one was the source of an incoming call. And the UA can easily 
achieve this by using distinct contacts in the registrations. I don't 
think we need to lose sleep over those that choose not to do so.

> make security decisions based on the evidence collected from the protocol by

Of course it is a potential security risk, which is why it is good to 
report that it happened. (A good UA will hopefully note that the 
connected party is not the called party and make a big fuss at its UI.) 
But it is still good to know who in fact you ended up talking to.

This is however not in any way a surprising event. It happens all the 
time for a variety of reasons. Usually it is detected because the voice 
you hear isn't the one you expected to hear. The fact that we can do 
better than that is itself of value. But I don't think we need to 
deprecate the call any further. While it would be good to know more 
about why the retargetting occured, in most cases people will do fine 
without that.

> is what I mean by solving the response identity problem.

The 'could' was a response to Jonathan, who didn't seem to have that in 
mind.

Re having the identity in a subsequent request differ from the one in 
the response to the invite: I'm not sure it is so problematic. The 
identity can change in mid call, and that will then probably first 
manifest itself in the first message sent following the identity change. 
This could happen if one party is a B2BUA or gateway.

Perhaps it would be more problematic if the change was first seen in 
some random message (e.g. INFO or OPTIONS) rather than in a message 
intended to change dialog state (e.g. INVITE or UPDATE). But it is only 
problematic if we enact some rule that says changes in identity must be 
formally announced.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Nov 2004 11:08:03 -0500

inline.

> Good. You confirm what I was assuming.

The MAY isn't good enough here. You want to be certain it WONT reject 
the request just because the From is wrong.

> to/from may be a single solution good for all of them.

I see a clear line between the various problems, but perhaps its just 
because I've not thought about it enough ;)

One problem, which I am calling the "request identity problem", is how 
to identify the sender of a request. That problem exists for initial 
requests and mid-dialog requests alike. indeed, because the identity 
exists on a request by request basis, the fact that a request is part of 
a dialog has no bearing. If you buy this argument, it would strongly 
argue in favor of the approach I suggested - modifying the From for 
reverse requests in a dialog so that the From properly identifies the 
sender.

A separate problem is how a UAC can securely determine the sequence of 
events that led to a request being retargeted. This is the much harder 
problem that I think is out of scope right now.

Another problem is how to identify the sender of a response, and it is 
the exact inverse of the request identity problem.

>> UA might not be aware of its need to be either of those things.

This is a fair point. There is a middle ground though. If a UA doesn't 
set the From properly, the identity service simply doesn't sign the 
request. Thus, it is always OK for a client to do nothing to support 
identity. The consequence is that, in the case of retargeting, their 
identity won't be delivered to the caller for a mid-dialog request. I 
think that this is reasonable. However, if a UA wants, it can set the 
 From properly, and then these requests can be signed.

> think we need to lose sleep over those that choose not to do so.

I don't see the problem. It should be able to use any identity it might 
otherwise assert in a request outside of the dialog. If the route set 
doesn't include the identity service for that domain, then there won't 
be any asserted identity. What this means is that servers that provide 
the identity service probably should record-route.

> But it is still good to know who in fact you ended up talking to.

I agree. Indeed, with SIP today you not only don't know its been 
retargeted, nothing evne identifies who its been retargeted to. This 
seems even more of a risk.

>> firmly, I think it will be possible to shift to that understanding of 

SIPS is clear that there MUST be a secure channel at each hop - it just 
doesn't mandate TLS. In hindsight I agree it should have ideally done 
that, it does imply a security property which does, IMHO, prevent 
outsiders from launching the attack you describe.

-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

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Nov 2004 18:32:32 -0600

>firmly, I think it will be possible to shift to that understanding of SIPS,

Even if SIPS was specified to be end-to-end, it would not resolve the 
issue of  a non-compliant (for whatever reason) proxy. This is one of 
the reasons I argued for the current text in 3261.  That which is on 
"the other side" of the responsible proxy might be SIP, it might be 
SIPS, or it might be H.323, there's no way to tell using just SIPS from 
"outside", and no amount of "requiring" otherwise in a specification 
will change this reality. In SIPS, each proxy is a transitive trust 
boundary, and that's just the way it is.

--
Dean