Subject: [Sip] Preventing unanticipated respondent syndrome when retargeting

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 02:30:15 -0500

I define "unanticipated respondent syndrome" as the sense of surprise  
Alice gets when she calls Bob, only to have the call answered by  
Charlie. This is especially problematic if the sorts of security  
operations that depend on Alice having some sort of keying  
relationship with Charlie become important.

Alice is expecting:

Alice--1-->Proxy--2-->Bob

but instead she gets:

Alice--1-->Proxy--2-->Charlie

because Bob forwarded his phone to Charlie, or because Charlie, who is  
authorized to do so, registered as a contact for Bob, and Bob didn't  
answer (or has a lwoer qvalue, or whatever)

RFC 4916 lets Alice find out who answered the phone in the most  
difficult of cases, and other techniques like P-Asserted-Identity in a  
response address simpler cases (or we can use endpoint- asserted RFC  
4474 Identity when the keys are known or discoverable). So that's not  
a problem. Alice can figure out that she's talking to Charlie, once  
they get connected.

The only problem is cluing in Alice that she's about to be talking to  
Charlie instead of Bob.

In the cases I've identified above, the proxy knows that it is  
retargeting the request to Charlie, not rerouting the request to Bob.  
How does it know this? It either a) knows that the Call Forwarding  
feature has been activated, and that's always a retarget, or b) knows  
that the contact for Bob was registered by Charlie, who isn't Bob (but  
that Charlie is authorized to register for Bob's AOR). In fact, if  
this the case, it knows both Charlie's authentication identity and his  
contact.

Since the proxy knows, it should be able to inform Alice.

I therefore propose a provisional response from Proxy to Alice, which  
I'll provisionally call "121 (Retargeting)"

A proxy executing a retargeting operation (by which we mean an  
operation that replaces the request URI such that the authenticated  
identity of the new request URI is different from the authenticated  
identity of the old one) SHOULD return a 121 (Retargeting) provisional  
response. The 121 response contains a Contact header field, the value  
of which is the new identity being targeted. Optionally, we might  
include some sort of "cause" parameter, explaining why the request is  
being retargeted (like "Bob's dead, talk to Charlie").

If a proxy doesn't know whether it is rerouting or retargeting, it  
SHOULD assume that it is retargeting, and send the appropriate 121  
response.

In conclusion, this preserves the proxy-mediated functionality  
required for draft-ietf-sip-outbound, while giving us the I-know-who-I- 
expect-to-reach function of a 302 (Redirect).

Yeah, this should be an I-D. I'm now accepting volunteer co-authors to  
do the dirty work, assuming this idea gets any traction.

--
Dean

_______________________________________________
Sip mailing list  https://www.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: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 4 Apr 2008 09:45:21 +0200

Is this any different then 181 Call Is Being Forwarded from RFC3261? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Friday, April 04, 2008 9:30 AM
To: [email-masked] List
Subject: [Sip] Preventing unanticipated respondent syndrome when
retargeting

I define "unanticipated respondent syndrome" as the sense of surprise
Alice gets when she calls Bob, only to have the call answered by
Charlie. This is especially problematic if the sorts of security
operations that depend on Alice having some sort of keying relationship
with Charlie become important.

Alice is expecting:

but instead she gets:

RFC 4916 lets Alice find out who answered the phone in the most
difficult of cases, and other techniques like P-Asserted-Identity in a
response address simpler cases (or we can use endpoint- asserted RFC
4474 Identity when the keys are known or discoverable). So that's not a
problem. Alice can figure out that she's talking to Charlie, once they
get connected.

In the cases I've identified above, the proxy knows that it is
retargeting the request to Charlie, not rerouting the request to Bob.  
How does it know this? It either a) knows that the Call Forwarding
feature has been activated, and that's always a retarget, or b) knows
that the contact for Bob was registered by Charlie, who isn't Bob (but
that Charlie is authorized to register for Bob's AOR). In fact, if this
the case, it knows both Charlie's authentication identity and his
contact.

A proxy executing a retargeting operation (by which we mean an operation
that replaces the request URI such that the authenticated identity of
the new request URI is different from the authenticated identity of the
old one) SHOULD return a 121 (Retargeting) provisional response. The 121
response contains a Contact header field, the value of which is the new
identity being targeted. Optionally, we might include some sort of
"cause" parameter, explaining why the request is being retargeted (like
"Bob's dead, talk to Charlie").

In conclusion, this preserves the proxy-mediated functionality required
for draft-ietf-sip-outbound, while giving us the I-know-who-I-
expect-to-reach function of a 302 (Redirect).

--
Dean

_______________________________________________
Sip mailing list  https://www.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
_______________________________________________
Sip mailing list  https://www.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: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 09:04:30 +0100

Dean,

We already have 181 Call is Being Forwarded, which has a very similar
meaning. Of course, we don't specify use of the Contact header field in
that response, but can't we add it?

John 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: 04 April 2008 08:30
> To: [email-masked] List
> Subject: [Sip] Preventing unanticipated respondent syndrome 
> when retargeting
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 03:54:50 -0500

On Apr 4, 2008, at 2:45 AM, Hans Erik van Elburg wrote:
> Dean mumbled:

Well, 181 is rather totally unspecified, AFAIK.

Th main difference is that the proposed 121 has a Contact that tells  
you where the call is being forwarded. It also specifically means that  
the call was "retargeted" meaning that the anticipated respondent has  
changed.

It might be reasonable to "further specify" 181 to mean the same  
thing, since, AFAIK, nobody ever actually used 181 for anything.

John Elwell made a try at it in draft-elwell-sipping-redirection- 
reason-01, but this lacked the whole "Contact" parameter bit that  
tells the recipient where the call is being forwarded to.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 03:56:25 -0500

> that response, but can't we add it?

I suppose that would work. The question is, does 181 imply that the  
anticipated response identity has changed? It seems like one might get  
a 181 on contact-rerouting.

I suppose we could also document 181 to only apply in a retargeting  
(or suspected retargeting, if the proxy doesn't know) case.

--
Dean

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 4 Apr 2008 11:04:29 +0200

ETSI and TISPAN use it for their Communication Diversion service, that
means that people are using it. 

They stick in the History-Info header containing an entry for the
diverting party and an entry for the diverted-to party. In fact they use
History-Info here to say something about the future of the request;-)

/Hans Erik 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, April 04, 2008 10:55 AM
To: Hans Erik van Elburg
Cc: [email-masked]
Subject: Re: [Sip] Preventing unanticipated respondent syndrome when
retargeting

Th main difference is that the proposed 121 has a Contact that tells you
where the call is being forwarded. It also specifically means that the
call was "retargeted" meaning that the anticipated respondent has
changed.

It might be reasonable to "further specify" 181 to mean the same thing,
since, AFAIK, nobody ever actually used 181 for anything.

John Elwell made a try at it in draft-elwell-sipping-redirection-
reason-01, but this lacked the whole "Contact" parameter bit that tells
the recipient where the call is being forwarded to.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Apr 2008 09:12:29 -0400

Dean,

Why response code 121 when we already have 181? Perhaps it needs some 
added info but it seems like the right response.

Second, in the case where Charlie registers with Bob's AOR, how does 
identity work? Won't Charlie appear to *be* Bob? Presumably it depends 
on what credentials Charlie uses. But I think in many cases this will 
indeed look like Bob.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 11:40:58 -0400

Howdy,
Can you describe more succinctly why this is a problem that needs fixing?  (not that I don't think it would be - I'm just low on caffeine and can't grasp the issue being solved)  I guess I don't get why Alice needs to know this before getting a 200? (or before a 180/183)

Also, how would this "work" with forking?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 13:13:12 -0500

On Apr 4, 2008, at 8:12 AM, Paul Kyzivat wrote:
> Dean,
>
> Why response code 121 when we already have 181? Perhaps it needs  
> some added info but it seems like the right response.
>

181 might well make sense. I used 121 so we could fish out any real  
differences with 181.

> identity work? Won't Charlie appear to *be* Bob? Presumably it  
> depends on what credentials Charlie uses. But I think in many cases  
> this will indeed look like Bob.
>

In the case I envision, Charlie registers like so:

REGISTER example.com SIP/2.0
To: sip:[email-masked]
From: sip:[email-masked]
....

The registrar authenticates the request as coming from Charlie, and  
checks its configuration to determine that Charlie is authorized to  
register to the Bob AOR. Hence, it knows that Charlie is not Bob, and  
that "contact routing" using the associated contact is retargeting,  
not rerouting.

 From an RFC 4474 perspective, the identity that Charlie's requests  
might carry would be "sip:[email-masked]".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 13:25:00 -0500

On Apr 4, 2008, at 10:40 AM, Hadriel Kaplan wrote:
> Howdy,
> Can you describe more succinctly why this is a problem that needs  
> fixing?  (not that I don't think it would be - I'm just low on  
> caffeine and can't grasp the issue being solved)  I guess I don't  
> get why Alice needs to know this before getting a 200? (or before a  
> 180/183)

There are several reasons why we need it before a 200. As to a a 180  
or 183, I suppose it makes as much sense to convey the retargeting  
identity in a 100 as in a 121. As for as a 180: There's no assurance  
there will ever be one sent by the terminating UAS -- it may well  
answer immediately.

First, it may be important for Alice to know that her call is going to  
not-Bob, lest in the earliest media phases she say something mean only  
for Bob's ears.

If we're using sipping-certs and end-node asserted identity, Alice  
needs to get Charlie's cert before she can validate Charlie's identity  
assertion. This is not instantaneous, and the earlier the notice, the  
better.

One can also postulate that Alice might be using other  
cryptotechniques (like IBE, instead of IBA) that require knowing the  
identity of the target and might require some setup time.

You might want to go back to Jon Peterson's diatribe on how proxy  
retargeting breaks many things, suggesting that we should have just  
used 302 with end-to-end direct SIP all along. Of course, the 302  
model doesn't work with the much-needed NAT traversal functions of sip- 
outbound, so the idea here is to offer a compromise that preserves  
both function sets.

> Also, how would this "work" with forking?

Either multiple responses (one per fork) or multiple Contacts (one per  
fork) in one response. Personally, I like multiple Contacts.

Or we could just go ahead and deprecate forking ;-).

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 15:33:19 -0400

> there will ever be one sent by the terminating UAS -- it may well

Yes, but my point was I think you only need/want this info at the same time a 180/183/200 comes back, so why not use them instead of creating more responses?  In other words, if there is no 180 sent back but in fact Charlie answers immediately, and Alice finds out in the 200 then, isn't that ok?
Less is more. :)

> not-Bob, lest in the earliest media phases she say something mean only

Alice can't say anything to Charlie until she gets SDP from Charlie, in a 18x or 2xx, which is why I keep wondering what's wrong with just using the already existent 18x/2xx.

> assertion. This is not instantaneous, and the earlier the notice, the

Unfortunately 4474 won't allow that anyway in responses - you need 4916, as you well know.  If you want to fix that I'm all for it, but it was shot down before. :(

> outbound, so the idea here is to offer a compromise that preserves

I think "end-to-end" would have been broken no matter what 3261 said about 302's, for obvious reasons, but yes I don't disagree that proxy recursion for 3xx (and forking) may end up being a Faustian deal.

-hadriel

---

From: Bob Penfield <[email-masked]>
Date: Fri, 4 Apr 2008 15:42:27 -0400

I think this could mess up User Agents that do not understand the new response code and treat it like any other 1xx. In this situation, the Proxy is acting as the UAS for the 121 response, and RFC 3261 requires that it have a to-tag. The UAC will create an dialog for the 121 response.

The problem is that the Contact does not meet the criteria required for a provisional response in that it does not reach the UAS (the Proxy) that established the dialog.

What will happen to any in-dialog requests sent by the UAC on the early dialog?

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Friday, April 04, 2008 3:30 AM
To: [email-masked] List
Subject: [Sip] Preventing unanticipated respondent syndrome when retargeting

Alice is expecting:

but instead she gets:

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 15:24:49 -0500

On Apr 4, 2008, at 2:33 PM, Hadriel Kaplan wrote:
> Yes, but my point was I think you only need/want this info at the  
> same time a 180/183/200 comes back, so why not use them instead of  
> creating more responses?  In other words, if there is no 180 sent  
> back but in fact Charlie answers immediately, and Alice finds out in  
> the 200 then, isn't that ok?

no, because it's too late. I now have this response from somebody that  
I'm not expecting a response from.

If Bob's proxy tells me to expect a response from Charlie, and I get a  
response from Charlie, that's ok. But if I just get this response from  
Charlie, I don't know if somebody has hacked me or what.

Further, there's a timing thing -- I'm likely to get the 1x1 from  
Bob's proxy long (hundreds of ms)  before I get the 180/200 from  
Charlie. So I can use that time window to prep up any keywork needed  
to talk to Charlie. If I wait until after Charlie sends a 200 OK and  
starts streaming media, it'll be harder to get it done in time.

Ideally, I'd like to see Charlie's media key fingerprint in that 1x1  
response. I think.

> Alice can't say anything to Charlie until she gets SDP from Charlie,  
> in a 18x or 2xx, which is why I keep wondering what's wrong with  
> just using the already existent 18x/2xx.

But how long after that SDP arrives is it before Alice can cognitively  
digest that she's talking to Charlie? How long until she can get  
Charlie's key and verify his authenticity?

> Unfortunately 4474 won't allow that anyway in responses - you need  
> 4916, as you well know.  If you want to fix that I'm all for it, but  
> it was shot down before. :(

I'm working on it one roadblock at a time.

The Identity header mechanism of RFC 4474 works just fine in  
responses  IFF the node inserting the response has the means to  
authenticate the responder's identity. While "traditional" SIP Systems  
using digest auth don't have this (necessitating RFC 4916), "outbound"  
proxies with persistent TLS connections probably can make an identity  
assertion. And if we're using endpoint keys for the assertion rather  
than keys held by proxies, the UAS can clearly make an identity  
assertion in a response.

If we have a real PKIX, or if we have IBE/IBA, or if we have secrets  
shared between users, then we can use RFC 4474 Identity headers end-to- 
end, in both request and responses. Yes, this is a slight extension of  
the RFC 4474 text, but it seems to get the job done. And it's central  
to my current thinking on P2SIP.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 15:27:36 -0500

On Apr 4, 2008, at 2:42 PM, Bob Penfield wrote:
>
> I think this could mess up User Agents that do not understand the  
> new response code and treat it like any other 1xx. In this  
> situation, the Proxy is acting as the UAS for the 121 response, and  
> RFC 3261 requires that it have a to-tag. The UAC will create an  
> dialog for the 121 response.
>
> The problem is that the Contact does not meet the criteria required  
> for a provisional response in that it does not reach the UAS (the  
> Proxy) that established the dialog.
>

This may be true. If so, it means yet more parts of the original SIP  
design are broken by all this early-dialog cruft that we should have  
just said "No, hell no, and what part of no did you not understand?"  
to. If so, put the new targets in Yet Another Header field.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 16:59:26 -0400

> Sent: Friday, April 04, 2008 4:25 PM
>

So then we'll need a 121 for the 121 then too?  ;)

> Charlie, I don't know if somebody has hacked me or what.

You won't know that for the 121 either - if someone has the callid/via/from-tag/etc. necessary to send you a fake matching response, a 121 will not be hard for them to send.  Obviously if a 121 could be signed by Bob's proxy, saying "I'm sending this to Charlie", that would be interesting maybe.  But you could instead just have Bob's proxy put something in the Invite it forwards to Charlie which Charlie copies in his response, to tell you he's legit to have gotten it. (and that mechanism at the same time could help avoid the rfc4474 baiting attack problem)

> Ideally, I'd like to see Charlie's media key fingerprint in that 1x1

Currently that fingerprint is in SDP anyway, and furthermore unique to Charlie (not available to Bob's proxy or even Charlie's proxy).  Isn't what you want then just rfc5027 (sec-preconditions)?

> than keys held by proxies, the UAS can clearly make an identity

I believe, from my google searching of the mail archives a while ago, that the main argument for not signing the responses was not to do with digest auth of the responder - it was because of the retarget scenario, where a retargeted-to domain could not possibly sign the response unless we allowed the To-URI to be changed in responses, which people were not wont to do due to 2543 dialog matching rules. At least that was my google impression. :)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Apr 2008 17:35:05 -0500

> So then we'll need a 121 for the 121 then too?  ;)

No, because teh 121 comes from an attributable source in the expected  
domain.

> You won't know that for the 121 either - if someone has the callid/ 
> via/from-tag/etc. necessary to send you a fake matching response, a  
> 121 will not be hard for them to send.  Obviously if a 121 could be  
> signed by Bob's proxy, saying "I'm sending this to Charlie", that  
> would be interesting maybe.  But you could instead just have Bob's  
> proxy put something in the Invite it forwards to Charlie which  
> Charlie copies in his response, to tell you he's legit to have  
> gotten it. (and that mechanism at the same time could help avoid the  
> rfc4474 baiting attack problem)
>

Well, that's why I want identity-signed responses.

--
dean

> Currently that fingerprint is in SDP anyway, and furthermore unique  
> to Charlie (not available to Bob's proxy or even Charlie's proxy).   
> Isn't what you want then just rfc5027 (sec-preconditions)?

Not really. There are scenarios where getting Charlie's cert  
fingerprint in advance of the 200 OK is useful.

> I believe, from my google searching of the mail archives a while  
> ago, that the main argument for not signing the responses was not to  
> do with digest auth of the responder - it was because of the  
> retarget scenario, where a retargeted-to domain could not possibly  
> sign the response unless we allowed the To-URI to be changed in  
> responses, which people were not wont to do due to 2543 dialog  
> matching rules. At least that was my google impression. :)

right -- so we use a previous provisional response from a node on the  
"expected path" to solve the unanticipated response problem resulting  
from the retarget!

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 5 Apr 2008 12:24:39 -0400

> Sent: Friday, April 04, 2008 6:35 PM
>

Signing the response won't avoid baiting.  Baiting is an attack on the called party, not the calling.  The issue is Charlie or his verifier doesn't know if he should be receiving the request, since the signed To-URI is Bob's.

In an early un-published form of the baiting draft I proposed a possible solution whereby Bob's proxy would in fact sign some new "re-target" header that effectively says "Charlie, Bob's domain is sending this to you".  The original 4474 identity would be left as is, and none of the headers it signs would be changed so that it's verifiable, and the additional re-target identity also signs some of the same headers (minus call-id/cseq/contact) plus the new re-target header. (you can think of it as signing Christer's Target header)  I removed that because I thought the solution was hokey and a troubleshooting/performance nightmare and highly unlikely to ever be deployed, and instead that Charlie could just decide who he wanted to answer calls re-targeted from, even without 4474.

But if you do something like that, then that target signature could actually be copied into the 18x/2xx responses, and the UAC can verify them to see that Bob's domain explicitly allowed Charlie to get the request.

But I'm not personally convinced that this is a problem which needs to be solved, given the overhead of the solution.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 5 Apr 2008 12:35:43 -0400

> "expected path" to solve the unanticipated response problem resulting

It won't help.  If we're stuck with 2543-type dialog matching rules, then the 121 AND the 18x/2xx can't change them, even if the 121 was sent saying "prepare for changing", since 121 would be treated by legacy nodes as a 1xx.  IF you're suggesting the 121 and subsequent responses use a new header for the re-targeted-to URI, then that solution could have been done to begin with instead of 4916 sending an UPDATE (and indeed I don't know why it wasn't, but I presume there was some valid reason).

Whether we *are* stuck with 2543-type dialog matching or not is a different topic, and my guess is its subject title would be "Here there be dragons". :)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sat, 5 Apr 2008 12:15:26 -0500

On Apr 5, 2008, at 11:35 AM, Hadriel Kaplan wrote:
> It won't help.  If we're stuck with 2543-type dialog matching rules,  
> then the 121 AND the 18x/2xx can't change them, even if the 121 was  
> sent saying "prepare for changing", since 121 would be treated by  
> legacy nodes as a 1xx.  IF you're suggesting the 121 and subsequent  
> responses use a new header for the re-targeted-to URI, then that  
> solution could have been done to begin with instead of 4916 sending  
> an UPDATE (and indeed I don't know why it wasn't, but I presume  
> there was some valid reason).
>
> Whether we *are* stuck with 2543-type dialog matching or not is a  
> different topic, and my guess is its subject title would be "Here  
> there be dragons". :)

Alice calls Bob, gets a provisional response from Bob's proxy saying  
the call has been forwarded to Charlie.

The prov response lets Alice know to expect something about about the  
response -- specifically, that it is going to be coming from someone  
who is not the target.

So if the response from Charlie says "Yeah, I'm Bob, signed by  
Charlie", then Alice would understand that despite the "From" being  
Bob, that she's really talking to Charlie.