Subject: Re: [Sip] Connected Destination in SIP

From: "Chris Whitaker" <[email-masked]>
Date: Sat, 01 Oct 2005 15:03:29 -0400

>From: Dean Willis <[email-masked]>
>To: Frank Derks <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [Sip] Connected Destination in SIP
>Date: Thu, 29 Sep 2005 11:48:25 -0500
>
>
>On Sep 29, 2005, at 9:35 AM, Frank Derks wrote:
>
>>
>>What is the real problem?
>>
>
>The real problem is that:
>
>1) The call could go to some agent with whom you do not have a pre- 
>established relationship, making it a "general public" scope problem.
>

Not having read any of the supporting drafts I may be wasting time with this 
Q, but:
Why is it someone you do not have a pre-established relationship with?
Is there not a chain of trust?

If A calls B and forwards to C, A need not trust that C is who he claims to 
be A need only trust B and B assert that C is really C.

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Mon, 03 Oct 2005 02:35:12 -0500

Chris Whitaker wrote:

> Not having read any of the supporting drafts I may be wasting time with 
> this Q, but:
> If A calls B and forwards to C, A need not trust that C is who he claims 
> to be A need only trust B and B assert that C is really C.

Depends on the forwarding mechanism that's used.

Problem case:

Alice knows Bob. Bob forwards his calls to Jack.

Alice calls Bob. Bob's proxy returns a 302, saying "Talk to Jack".

Alice sends a new invite to Jack.

Jack's proxy sends the request to Jane, because Jack told it to.

Jane answers.

Alice doesn't know Jane. She doesn't know even know Jack.

What does she do?

Now, if everybody subscribes to an identity service, and Bob identified 
Jack to Alice in terms of the identity service, and Jack identified Jane 
to Alice(which probably required that he 302 her, not proxy her, to 
Jane) then we have a network of trusted introducers, with the trust 
anchorprovided externally (in the identity service, or federation of 
identity services).

Works great. Doesn't work with proxies that actually proxy -- works only 
with redirect servers. This is the model of the SIP "identity" draft 
that works for response identity.

Another variant, and what I think you're proposing:

Alice knows Bob.  Bob forwards his calls to Jack, who forwards to Jane.

Alice calls Bob, who returns her a 302 pointing to Jack, along with a 
half-key (like X, Z, Z^XY). Bob sends the other half-key (Y, Z, Z^XY) to 
Jack via some undefined mechanism (the new, undocumented because I just 
made it up REFERPREP request, perhaps).

Alice calls Jack, and uses her half-key to validate Jack (sends him X, 
he sends back Y, both validate z^XY, proving the other party had the 
correct other half-key). Now Alice knows Bob sent the other half-key to 
Jack, and that he's therefore "trusted". Jack also knows Alice is that 
caller Bob warned him about, and that he can safely pass her on to Jane.

Jack forwards to Jane to the same way, and Alice and Jane repeat the 
key-matching process.

Works great. Doesn't work with proxies that actually proxy -- works only 
with redirect servers. Requires only a small SIP extension, and some 
careful timing management to make sure that the 3rd party has the 
introduction-key before the first party talks to them. You can do some 
slightly fancier crypto to make a session key if you want, or improve 
the crypto in other ways. And my crypto is probably wrong here anyhow, 
but we could get a real Zimmerman to fix it.

Alternative for trusting people:

If you're just willing to assume that all the proxies do the right thing 
all the time, then you can just believe whatever comes back in the 
P-Called-Party-ID (but READ the applicability statement, it's a 
P-header, and not suitable for use in the Internet).

But I bet you'll be spending a lot of time talking to high-dollar 
reverse-charge operators in the Carribbean. Heck, I might install a 
proxy on my phone just to do that for you, ok?

Now, we can work around this a little bit by eliminating 
network-serviced 302 operations, or by constraining them and forcing the 
proxy that executes the redirection to check identity for you, or by 
policing route headers at the edge so that we know that no other proxies 
got added (which breaks many service and composition models, but it's in 
IMS release 6, which IMHO, is broken in this regard). And frankly, these 
are all half-measure hacks with serious side effects.

--
Dean