Subject: RE: [Sip] Connected Destination in SIP

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Sat, 1 Oct 2005 15:31:09 -0500

this is simple, relay the ID of the connected party backward....this is
all in a semi-trusted  domain...we are not talking about the "OPEN"
internet. If the IETF can not address this need...(reality check...
vendors...services providers need this....so chill paul)

please...some sanity..

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Chris Whitaker
> Sent: Saturday, October 01, 2005 3:03 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] Connected Destination in SIP
> 
> 
> 
> 
> 
> >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
> 

_______________________________________________
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: Mon, 03 Oct 2005 00:04:17 -0400

I agree that this is needed, and I believe that what you are basically 
describing - convey the called party identity in the reverse direction, 
can be made to work and work securely against a specific (albeit 
limited) set of attacks.

What Jon's document has clearly illustrated is that, should an attacker 
maliciously forward a request (i.e., by provisioning false forwarding 
information into a proxy), there is simply no way to detect or prevent 
this attack. So, we should not even try.

The attack that I am more worried about is that user A calls user B, and 
the call is forwarded to C (as it should have been). It arrives at C's 
UA, but C, being a prankster, inserts a faked called-party-identity into 
the response, saying that they are D, and forwards it upstream. A now 
mistakenly thinks they've reached D, when they've actually reached C. 
This attack can be prevented under certain circumstances.

The easy way to provide this functionality is the following. When user C 
registers, they do so over a tls connection to their proxy. 
Authentication is done, so their proxy knows C's identity. When the 200 
OK to the invite arrives from C at C's proxy, C's proxy inserts some 
kind of identifying header containing C's identity. Of course, the proxy 
also removes any existing identity header if one was present.

This is basically the analogous mechanism to P-asserted-ID, but in the 
reverse direction.

Slightly better, I think, is the inverse of the sip-identity mechanism. 
The UAS (user C), would modify the To header field in the 200 OK 
response, to contain its actual identity. User C's proxy would add a 
signature to this, draft-ietf-sip-identity style, if it agrees that the 
called party had this identity.

The reverse sip-identity approach doesn't deal with the fundamental 
forwarding problem; the UAC won't have any way to know whether its call 
was really intended to reach [email-masked] or 
[email-masked], both of which could provide signatures over the 
response. Indeed, the endpoint itself could sign the response using any 
domain it had certs for. However, the endpoint could not claim that they 
were [email-masked]. They could not impersonate another user that 
the caller knows a SIP URI for. If C's domain supports the mechanism, it 
could strip any Identity information in the response, and thus prevent 
attacks where the endpoint acquires domains like witehouse.com and signs 
the response [email-masked].

The net/net is that there definitely is a clear need for this connected 
party identity from a functional perspective, and we should seek to 
provide a mechanism that we can secure to the greatest extent possible. 
That doesnt prevent all of the attacks, but nothing ever can. So, rather 
than the perfect being the enemy of the good, we should strive to do 
something here rather than nothing.

Thanks,
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: Mon, 03 Oct 2005 01:50:17 -0500

> vendors...services providers need this....so chill paul)

Sorry, Martin! This IS the IETF. We ARE talking about the open Internet 
(that's the I in IETF, right? They didn't change the acronym to 
"Interiornet" or something when I wasn't looking?).
In general, it's not in our charter to really consider something else -- 
and when we do have to write up something that works in only a small, 
walled corner of the net, it carries severe "applicability statement" 
warnings.

You want to talk a lot about approaches that only work in a walled 
garden, you need the ITU. ;-).

--
Dean