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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Nov 2000 02:22:35 -0500

> -----Original Message-----
> From: Keith Robinson [mailto:[email-masked]]
> Sent: Thursday, October 26, 2000 12:01 PM
> To: Jonathan Rosenberg
> Cc: 'Christer Holmberg'; [email-masked]; Igor Slepchin;
> [email-masked]
> Subject: RE: [SIP] Redirect server returning new From header
> 
> 
> 
> 
> 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.

Well, such mappings (from a phone number to a SIP URL) are the subject of
enum. Who owns such mappings, and how they are managed, is currently the
subject of intense political and regulatory struggles. I'm hoping to stay
away from such things.

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

In this case, I would argue that what you want is to use the privacy spec:

http://search.ietf.org/internet-drafts/draft-dcsgroup-sip-privacy-02.txt

but always use a telephone number in there. All this network-level
authentication of names is very much a PSTN thing. I suspect the
Remote-Party-ID identification will be used most commonly in PSTN bypass or
PSTN emulation, in which case you only ever want a PSTN number anyway. For
IP to IP signaling, an end to end authentication mechanism is preferrable.

The next best thing is to update the privacy spec to allow multiple
addresses in there. This way, you don't touch the base spec, which is what I
really, really want to avoid.

Simon writes:
> > 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).
> 
> 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.

Huh? SIP-T does not anywhere require the same trust network as regular ISUP
telephony. Where in the drafts does it say that?

Juha writes:
>  > 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.
> 
> why is that?  the proxy receives the invite message and authenticates
> it.  then it checks from the user database if the telephone number in
> the from field is among those that has been allocated to the user.  if
> so, it accepts the call and passes it to the uas at the pstn 
> gw. if not,
> it rejects the invite.  the uas only talks to the proxy and thus knows
> that it can use the number in the from field as calling party number.

If the calling UA is known only by this number, you are correct. The privacy
specification addresses exactly this requirement. The problem is when I make
a call from my yahoo SIP account (sip:[email-masked]), and the yahoo
proxy needs to insert my phone number into the request. What I am saying is
that since yahoo does not own or adminster the PSTN numbering space, it has
no way to verifiably correlate my yahoo address with my phone number. The
same problem exists in the reverse; my phone company has no easy way to
reliably verify that a valid additional sip address for me is
[email-masked]. 

-Jonathan R.

---
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: Juha Heinanen <[email-masked]>
Date: Thu, 9 Nov 2000 01:00:30 +0200 (EET)

> reliably verify that a valid additional sip address for me is

i fully agree.  in the yahoo case, the sip/ss7 gateway could
authenticate the user and use its own pstn number as the calling number.

-- juha