Subject: RE: [SIP] Redirect server returning new From header

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2000 06:39:04 -0400

I thought we had put this issue to bed.

As Henning pointed out previously, allowing a UAC to insert a telephone
number into a request, which is then passed to the PSTN (via a gateway) as
the originating number, is a recipe for a security disaster. Nothing stops
me from inserting fake telephone numbers, and calling people pretending to
be someone else. You can expect a call from the FCC about that one.

So, in fact, this proposed used of the Also-From header is, in practice,
unusable without a massive security/PKI infrastructure which really doesn't
exist (you would need someone to certify that [email-masked] owns the number
555-1212. I don't even know who would be able to adequately certify this,
and I suspect no CA in their right mind would ever put this in a
certificate). 

So, by corollary, having a proxy tell a UA what number it owns is even more
of a security nightmare, and even less likely to ever work. Thus, the
mechanics of how best to accomplish it are moot.

Perhaps I sound harsh, but I am trying really hard to push back on everyones
"lets add X to SIP" request. SIP is already an RFC, folks. We are obliged to
carefully scrutinize everything that gets added, and only put things in when
they are truly needed, broadly useful, and backwards compatible. This
Also-From thing has only one proposed application, which is interoperation
with the PSTN, and in this application is frought with serious security
issues. 

-Jonathan R.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2000 1:47 AM
> To: [email-masked]
> Cc: Igor Slepchin; [email-masked]
> Subject: Re: [SIP] Redirect server returning new From header
> 
> 
> 
> Hi,
> 
> >You can use URL headers to specify SIP message headers, 
> e.g., the Contact >in the 302 may look like
> > 
> >Contact: sip:chirster@ericsson?from=tel:12345
> > 
> >It's then up to the UAC to trust your redirect server and 
> overwrite its
> >default From header. See section 2 of 2543bis for details.
> 
> True, but in this case the redirect server (what I mean by that is
> actually any SIP node, server or UA, with redirect functionality...)
> will not know if the UAC is going to use the new header or 
> not. For some
> reason, the redirect server may behave in different ways 
> (maybe, in some
> case, it won't even allow the UAC to contact a certain host if the
> feature is not supported...) depending on if it can give the UAC a new
> From header or not.
> 
> But, if we have a new header for this, the UAC can indicate in the
> Supported header that it supports this feature. Then, the redirect
> server can add the new "Also-From" header in the response, 
> and indicate
> in the Require header that the UAC must use it. Maybe this is possible
> also in the case where you just add it to the Contact header, 
> but in any
> case I think you would have to define a new Supported/Require 
> tag value
> (?)

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Simon Barber" <[email-masked]>
Date: Thu, 26 Oct 2000 16:52:18 -0700

> and I suspect no CA in their right mind would ever put this in a

This security infrastructure already exists in the current telephone network -
although it is implemented in hardware rather than software. Phone companies have a
network of trust with each other, and exchange ISUP messages with each other only
secure lines setup along these lines of trust. Where signalling is exchanged with an
end user (Q.931) checks are made to ensure the user is authorised to send the numbers
he sends. A similar trust network is required if we want to have authenticated CLI in
SIP. Currently SIP-T does require exactly the same (physical or secure VPN) trust
network as regular ISUP telephony. Indeed this is probably one of the main
constraining factors that limits whom SIP-T is available to.

Your telephone company will be very well positioned to certify that you have the
right to present your telephone number. I would suggest that it will be your phone
company, or a third party acting on their behalf who will do so.

Authenticated CLI in SIP may play a very important part in keeping SIP spamming down.

Simon Barber