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

From: Igor Slepchin <[email-masked]>
Date: Wed, 25 Oct 2000 11:26:40 -0400

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2000 1:47 AM

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

Support of URL headers is required by RFC2543 so I believe your chances of
encountering a UA that understands URL headers are much higher than those of
encountering a UA that knows another one of the gazillion proposed
extensions.

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

A new header doesn't seem to buy you anything over URL headers. Given the
fact that the support of URL headers is mandatory, I don't see much sense in
defining another Supported/Require extension. Your gateway is always free to
reject the INVITE if it doesn't see what it likes in the From or anywhere
else in the message.

---
Igor Slepchin

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

---

From: "Keith Robinson" <[email-masked]>
Date: Thu, 26 Oct 2000 17:01:14 +0100

With respect to the issue of delivering a calling line identity from a SIP user
into the PSTN, consider the following.

A SIP user wishes to be globally reachable; as this means he has to be reachable
from a POTS subscriber in the PSTN who can only dial digits it follows that the
SIP user must also be known by a dialled digit string. Therefore, the
association of the SIP users URL and the dialled digit string to reach this URL
must be fixed so therefore verifiable; if this were not the case then calls from
the PSTN into SIP networks could not happen.

If the association of a SIP URL to a dialled digit string is required to support
calls from the PSTN into a SIP network, it is not unreasonable for this same
digit string to be delivered when making calls from the SIP network into the
PSTN.

The UAC should not be allowed to supply  the CLI;  rather it is supplied by the
network to which he is connected and it is the responsibility of the network to
ensure that the person is who he says he is (verify FROM:) and ensure that the
correct CLI is delivered.

Regards,

K. Robinson

Jonathan Rosenberg <[email-masked]> on 26/10/2000 11:39:04

                                                              

 To:      "'Christer Holmberg'"                               
          <[email-masked]>,                
          [email-masked]                             
                                                              
 cc:      Igor Slepchin <[email-masked]>,          
          [email-masked](bcc: Keith                  
          Robinson/MAIN/MC1)                                  

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

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.

> 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.
>
> 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.
>
> Supported header that it supports this feature. Then, the redirect
> 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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 31 Oct 2000 04:31:52 -0800

Agreed. Operating under the proper trust relationships, couldn't this
problem be solved by a proxy (or B2BUA - but _not_ a redirect server) adding
Remote-Party-Id/Anonimity headers on behalf of the UA (as described in the
dcsgroup-privacy internet draft). 

This only works when the proxy can confirm 
1) that the UA is indeed who they claim to be (ie UA to proxy
Authentication) 
2) that the SIP URL does indeed equate to a tel: number on the destination
network (internal database)
3) and that the proxy has a trust relationship established across the
SIP-PSTN/VoIP network that the proxy is routing the call to (as per
dcsgroup-privacy draft).

.... which are conditions that you would want in the first case.

Due to proper privacy frameowrk on the SIP-PSTN network side, the proxy can
also ensure that the UA's Caller Info doesn't accidentally get sent to
somewhere it shouldn't. Last but not least, no extra PSTN specific features
are needed on the UA which makes the solution a lot more mobile. 

Regards,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 

> From: Simon Barber [mailto:[email-masked]]
> Sent: Friday, October 27, 2000 7:52 AM
> 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
>