Subject: [Sip] RE: Identity after reinvite

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 16 Nov 2004 01:40:57 -0500

Well, yes, now one begins to appreciate why we originally coupled the
request identity problem with the response identity problem. :)

In the next revision of the identity draft, which will incorporate the list
comments up to date, I do intend to include some text about dialogs. I agree
that the draft should apply to requests regardless of the dialog context.

Moreover, I don't think the problem you raise below is limited merely to
re-INVITEs within a dialog. I believe it applies equally to BYE requests
sent in the backwards direction in a dialog. Ideally, the originator of the
dialog should have some assurance that requests sent in the backwards
direction come from the same identity that positively responded to the
dialog (i.e., the sender of the 200 and any provisional responses).

In the absence of response identity, though, it is difficult for Alice to
have any such assurance. Equally, as you point out below, Bob can have no
assurance that his BYE or re-INVITE has been fielded by Alice if he is
unable to get a cryptographically-assured 200 response to his own requests.
Alice can't even be certain that she actually connected to Bob, thanks to
retargeting; this is the essence of the connected-ID/response identity
problem, and threatens to drag us back into the morass of retargeting
restrictions and so on that populated the sip-identity-02 draft.

A lack of such a strong binding of backwards-direction BYE requests to the
dialog is a significant limitation; if BYE can be spoofed, then an attacker
can terminate existing dialogs. However, I'm not sure that the situation is
so dire as you suggest below. Without identity, it is trivial for any
attacker to impersonate a dialog-forming request. It is harder, though, for
an attacker to impersonate a response or mid-dialog request; this requires
the attacker to gather dialog state through eavesdropping or some similar
means. 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).

Ultimately, request identity can protect against the former but not the
latter. While it is imperfect, I feel that this is an improvement over the
current situation. In cases where retargeting has not occurred, Alice will
see a re-INVITE or BYE from the expected URI (blessed, as you say); in cases
where retargeting has occurred, Alice may receive a warning from her UI that
an unexpected but assured URI has responded. Likewise, Bob will have to
trust, given the signature over the Contact header field in the
dialog-forming INVITE request, that his request in the backwards direction
is forwarded to the appropriate UA instance. In terms of what Bob's UI
should display, well, that really depends on the sophistication of attacks
you are willing to consider plausible. Personally, I don't think Bob's UI
should suggest any uncertainty about the matter.

To improve on all this, we will ultimately need to solve the response
identity problem; however, I maintain that sip-identity as it stands will
have addressed the simplest and most common variety of impersonation, the
one that does not require any eavesdropping whatsoever. Once we feel we have
the right answer to request identity, we can revisit the response identity
problem and try to eliminate the remaining attacks.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, November 15, 2004 3:58 PM
> To: Peterson, Jon; Cullen Jennings; [email-masked]
> Subject: Identity after reinvite
> 
> 
> Jon,
> 
> After the meetings last week a question came to mind re the 
> identity draft.
> 
> First, I want to double check on usage in dialogs. The draft doesn't 
> say, but I presume that every message in a dialog needs to be signed, 
> not just the one that initiates a dialog. If that is a bad assumption, 
> it would be good to hear why.
> 
> Assuming that, what happens when the initial invite was from Alice to 
> Bob, and later a reinvite is sent from Bob to Alice? Initially Bob knew 
> that Alice had called, while Alice had no assurance about who she had 
> reached with her call. The reinvite is from Bob, so if his identity is 
> blessed, then Alice will know she is talking to Bob, but Bob will no 
> longer have any assurance that he is still talking to Alice.
> 
> This could even manifest itself in the UI presented to Alice and Bob. 
> Initially Bob would have a "callerid" display showing Alice as a 
> certified caller. But after putting Alice on hold and back off hold the 
> display might stop showing Alice, or at least might show the identity as 
> suspect. (There may be strong temptations to avoid this via some sort of 
> hack.)
> 
> I don't see any good solution for this other than solving the connected 
> party id problem as well.
> 
> 	Just checking my understanding,
> 	Paul
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 03:05:36 -0500

> that the draft should apply to requests regardless of the dialog context.

I do believe there are issues related to mid-dialog requests, but I'm 
not sure I agree that Paul's characterization is the problem.

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. The identity service will then reject these requests.

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

> dialog (i.e., the sender of the 200 and any provisional responses).

Useful, yes, but a different problem. I like the current scope of the 
identity draft - to provide the identity of the sender of a request. 
That is not a panacea for all of our security problems, of course.

> can terminate existing dialogs.

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.

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.

  However, I'm not sure that the situation is
> tags, correct Call-ID/CSeq, etc).

sips, of course, prevents this fully.

> latter.

But, its not supposed to. Its not supposed to provide all of the 
security functions for sip - just the function which identifies the 
originator of a request.

-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: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Nov 2004 09:42:56 -0500

Jon,

I generally agree with what you say. I wasn't trying to suggest that we 
hold up identity for connected-party support. I just wanted to get a 
clear understanding of the issues remaining. It seems that they are a 
bit more than just not getting confirmation of who you connected to.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Nov 2004 10:01:00 -0500

Jonathan Rosenberg wrote:
> From field value which does not actually correspond to the originator of 
> the reuqest.

Very good point!

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

> original request.

Yes, this would be a good solution, if we can sort out the compatibility 
issues getting to it.

 > This will break all compatibility with rfc2543, but

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.

>> sent in the backwards direction in a dialog.

Yes, that is true.

 >> Ideally, the originator
>>  of the

This of course is considered a feature by some, who want a proxy to 
morph into a B2BUA just to send a BYE.

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

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

> security functions for sip - just the function which identifies the 

Agreed. But is helpful to put it in its place in the bigger context.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 16 Nov 2004 09:29:38 -0800

> longer used for dialog identification.

At this point, I really see two paths forward for the connected party
problem.

1) We do as suggested above and allow everything in the From and To other
than the tags to be changed in a Re-INVITE or UPDATE.

2) We create a new thing that is like invite with replaces but add a new tag
that is called say "subsumes". So if A and B have a dialog, or early dialog,
and one of them wants to change a From. The UA sends an INVITE for a new
dialog, indicates it replaces the old dialog, and indicates that it subsumes
it. The subsumes flag would mean that any existing media session, qos
reservations, etc did not change and got moved to the new dialog.

---

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

> reservations, etc did not change and got moved to the new dialog. 

I vote for biting the bullet and changing From/To. It will initially 
cause some pain, but it will solve a number of problems in a clean way.

We could define an option to be announced in Supported that indicates 
ability to do this. Could end up with:

	INVITE ...
	To: sip:[email-masked]
	From: sip:[email-masked];tag=alice
	Supported: to-from-change
	Identity: aaaaaaaa (signed over From)
	Identity-Info: https://atlanta.com/cert
	...

	180 ...
	To: sip:[email-masked];tag=charlie
	From: sip:[email-masked];tag=alice
	Supported: to-from-change
	Identity: cccccccc (signed over To)
	Identity-Info: https://chicago.com/cert
	...

	200 ...
	To: sip:[email-masked];tag=charlie
	From: sip:[email-masked];tag=alice
	Supported: to-from-change
	Identity: cccccccc (signed over To)
	Identity-Info: https://chicago.com/cert
	...

	ACK ...
	To: sip:[email-masked];tag=charlie
	From: sip:[email-masked];tag=alice
	Supported: to-from-change
	Identity: aaaaaaaa (signed over From)
	Identity-Info: https://atlanta.com/cert
	...

	UPDATE ...
	To: sip:[email-masked];tag=alice
	From: sip:[email-masked];tag=charlie
	Supported: to-from-change
	Identity: cccccccc (signed over From)
	Identity-Info: https://chicago.com/cert
	...

	200 ...
	To: sip:[email-masked];tag=alice
	From: sip:[email-masked];tag=charlie
	Supported: to-from-change
	Identity: aaaaaaaa (signed over To)
	Identity-Info: https://atlanta.com/cert
	...

(Above shown as they look to receiving UA.)

	Paul

---

From: David R Oran <[email-masked]>
Date: Tue, 16 Nov 2004 13:33:21 -0500

I have a strong preference for (1). I intensely dislike accumulated 
hacks and entropy in a protocol. Backward compatibility is an important 
property, but 2543 compatibility is fast becoming a a concrete block 
chained to our legs.

We should declare a day that 2543 SIP implementations don't have to 
work right any more. I suggest we make that when 3261 goes to draft 
standard. We can couple that to decreasing entropy in another way - 
don't make more entropic stuff proposed standard until SIP itself gets 
to draft. Then we'll see what existing junk gets pulled from SIP 
because nobody implements it and be moving forward from a stable common 
base.

Donning flame-retardant BVDs...

Dave.

> reservations, etc did not change and got moved to the new dialog.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 14:18:41 -0500

David R Oran wrote:

> We should declare a day that 2543 SIP implementations don't have to work 
> right any more. I suggest we make that when 3261 goes to draft standard. 

Cough... cough... [clutching chest as heart attack ensues]

Draft standard? After the pain we went through to get rfc3261 issued I 
can't imagine doing that again...

Practically speaking, based on the current rules for normative 
references, we are never going to be able to get to draft because 
RFC3261 has too many normative dependencies on protocols that are not at 
draft standard.

I agree we should take approach (1). We could spec it in a backwards 
compatible way, too. If you change the From field in a request you send 
mid-dialog, and you get a 481, you know that something along the way got 
confused about the dialog identifiers. You can then retry, using the 
 From URI from the original INVITE, and include some kind of flag to 
signal to the identity service not to try and insert the Identity header.

Paul wrote:
> We could define an option to be announced in Supported that indicates ability to do this. Could end up with:
> 
>     INVITE ...
>     To: sip:[email-masked]

This helps only if you assume that the problem lies in the UA; I would 
be worred about other nasties along the way.

In any case, I don't see a need for a Supported header field. The 
feature is supposed to work with any rfc3261 client out there.

-Jonathan R.

---

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

Jonathan Rosenberg wrote:
>> hacks and entropy in a protocol. Backward compatibility is an 
>> important property, but 2543 compatibility is fast becoming a a 
>> concrete block chained to our legs.
>>
>> standard. 

The situation is a little more difficult to detect if you change the To 
in the response to the INVITE, which I was suggesting. Error responses 
don't help in this case. The to-from-change option would however help to 
know you could do this.

But as you point out below, that doesn't help if the proxies on the path 
get upset. To get around that problem we could use Proxy-Require, but 
that is pretty heavy handed. Or we could use some more cooperative 
option negotiation, where all the proxies must concur before the UAS can 
use the feature.

> This helps

By "this" I assume you mean the to-from-change option?

 > only if you assume that the problem lies in the UA; I would

For changing on subsequent requests within the dialog, what nasties are 
you thinking of? I think only a call stateful proxy would notice, and it 
seems there aren't many of those. Of course there are B2BUAs, but they 
at least *ought* to be UAs and behave as such.

Maybe there would be problems with SBCs, and with "transparent" B2BUAs 
that normally act as proxy but morph into UAs on occasion. But I think 
these nasties will have other problems with Identity too. I suppose we 
must however confront these.

> feature is supposed to work with any rfc3261 client out there.

Other than just hoping for the best, why would we expect existing 3261 
clients to work with this change?

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Nov 2004 10:52:35 -0500

> at least *ought* to be UAs and behave as such.

Ought, being the operative word here. I fear that a b2bua would pass the 
Supported headers unmodified and then things would be bad.

It is explicitly called out in 12.2.1.1:

> The URI in the To field of the request MUST be set to the remote URI
>    from the dialog state.  The tag in the To header field of the request
>    MUST be set to the remote tag of the dialog ID.  The From URI of the
>    request MUST be set to the local URI from the dialog state.  The tag
>    in the From header field of the request MUST be set to the local tag
>    of the dialog ID.  If the value of the remote or local tags is null,
>    the tag parameter MUST be omitted from the To or From header fields,
>    respectively.
> 
>       Usage of the URI from the To and From fields in the original
>       request within subsequent requests is done for backwards
>       compatibility with RFC 2543, which used the URI for dialog
>       identification.  In this specification, only the tags are used for
>       dialog identification.  It is expected that mandatory reflection
>       of the original To and From URI in mid-dialog requests will be
>       deprecated in a subsequent revision of this specification.

Only the tags are ever used in any normative processing of dialogs in 
RFC 3261. The requirement to set the From field *URI* in the reverse 
direction to the value of the To URI in the original INVITE is *only* 
for backwards compatibility, and rfc3261 stated that this is likely to 
change one day. The day appears to be at hand.

-Jonathan R.