Subject: RE: [Sipping] Screened From: and Privacy

From: "Mark Watson"<[email-masked]>
Date: Tue, 16 Apr 2002 18:51:14 +0100

Assuming that you only need one 'identity' is always a bad thing in any
application. In these examples there are at least two:
1) An identity the user wishes to be known by
2) An identity the service recognises for the user

Dean is arguing that (1) is what From: is for, and (2) is confined to the
authentication process.

It seems people have assumed that in a Service Provider environment From: is
sometimes used for (2). Certainly the SIP spec points you in this direction
('possibly the address-of-record' ...). Particularly the fact that
*services*, with no qualification, might key off this field imply that it
should be accurate.

There is a requirement from Service Providers to deliver something based on
(2) to the terminator (absent privacy), especially if the terminator is in
the PSTN.

These last two points have led Service Providers to verify the From: field.
They've been encouraged in this by the lack of any other field to
communicate (2) passed the device which does authentication.

As Dean correctly points out, using From: for information like (2) leads to
the need to B2BUA everything for subscriber privacy (if you care about
RFC2543 clients).

I would still argue that a subscriber privacy service may need to remove (1)
as well, so if the idea is to avoid the requirement to modify/control the
From: field, it still might not work.

I can't see a clean way out of this. I don't think it's realistic to assume
that From: is ALWAYS and ONLY of type (1) - purely end-to-end. Sure, some
systems may treat it this way, and there is no harm in that, but it seems to
me too late to make this statement now. Service Providers exist which put it
into class (2). They may need to modify it. As long as we are aware of this
there should be no problem.

I also think it will be common to check the URI portion of the From: field
but not the Display Name.

We can't *assume* From: is ALWAYS of type (2) either. So let's just get on
and define a field for this - Network Asserted Identity.

...Mark

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 16 April 2002 14:14
> To: Sipping (E-mail)
> Subject: [Sipping] Screened From: and Privacy
> 
> 
> 
> Some have suggested that we have everything needed to handle caller ID
> using the From: field, and that we can reasonably screen 
> callas based on
> the "From:" field to assure the veracity of this field value.
> 
> We COULD.
> 
> But there's a very common usage suggesting otherwise.
> 
> Generally, there's some sort of authentication token 
> associated with the
> phone, not the user of the phone. For example, in 3PPP it's in the SIM
> card. For the Cisco 7960 on my desk, it's in the boot file on the TFTP
> server, and for the Pingtel phone on my desk it is stored 
> into the phone
> using a web interface.
> 
> So really, the service platform is authenticating the phone, not the
> user.
> 
> So let's say my kid (I don't have one, but we're pretending here) is
> using the home phone to call her friend. She doesn't want the 
> call to be
> from Dad, she wants it to be "from" her.
> 
> Logically:
> 
>     From: littlekid
>     Authenticated-RPID: Account of Dean Willis 9724735455
> 
> Ok, so we could add "littlekid" to the list of "Approved From Fields".
> Or we could revamp things so that she gets a "login" and Her Very Own
> RPID (which is contractually iffy in many countries)
> 
> Now her friend comes over and wants to use the phone to call 
> his mother
> . . .
> 
> As you can see, this rapidly becomes a provisionng nightmare, and I'd
> argue that the From screening provides no useful value 
> anyhow. Much more
> useful to leave it as a user provided string with the semantic of "How
> the user wants to be though of at the far end".
> 
> --
> Dean
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 17 Apr 2002 01:35:40 -0400

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Mark Watson
> Sent: Tuesday, April 16, 2002 1:51 PM
> To: 'Dean Willis'; Sipping (E-mail)
> Subject: RE: [Sipping] Screened From: and Privacy
> 
> 
> Assuming that you only need one 'identity' is always a bad 
> thing in any application. In these examples there are at least two:
> Dean is arguing that (1) is what From: is for, and (2) is 
> confined to the authentication process. 

That is my contention as well.

> It seems people have assumed that in a Service Provider 
> environment From: is sometimes used for (2). 
My preference would be to clarify that such an assumption is unwarranted
and that is not the purpose of the From: field.

> Certainly the 
> SIP spec points you in this direction ('possibly the 
> address-of-record' ...). Particularly the fact that 
> *services*, with no qualification, might key off this field 
> imply that it should be accurate.
Define "accurate". For me "accurate" simply means that it reflects who
the user wishes to be known by to recipients for this request. 

> There is a requirement from 
> Service Providers to deliver something based on (2) to the 
> terminator (absent privacy), especially if the terminator is 
> in the PSTN. 
Ah, YES YES. Hence RPID. We come full circle yet again (maybe this
discussion needs a loop detect feature :-) )

> These last two points have led Service Providers 
> to verify the From: field. They've been encouraged in this by 
> the lack of any other field to communicate (2) passed the 
> device which does authentication. As Dean correctly points 
> out, using From: for information like (2) leads to the need 
> to B2BUA everything for subscriber privacy (if you care about 
> RFC2543 clients). 
How does this follow as long as you define From: as only
user-controlled?

> I would still argue that a subscriber 
> privacy service may need to remove (1) as well, so if the 
> idea is to avoid the requirement to modify/control the From: 
> field, it still might not work. 
I'm afraid we're destined to disagree here. Anything in the From field
is something the user by definition wants to reveal.

> I can't see a clean way out 
> of this. 
Well, RPID may not be perfect, but it does get us out of this.

> I don't think it's realistic to assume that From: is 
> ALWAYS and ONLY of type (1) - purely end-to-end. 
I think the consequences of any other interpretation are much worse, but
that's of course just my considered technical opinion.

> Sure, some 
> systems may treat it this way, and there is no harm in that, 
> but it seems to me too late to make this statement now. 
Why? What have we done in any SIP spec which causes a problem? (as
opposed to what some implementers and other standards groups have done).
What is irreversible here?

> Service Providers exist which put it into class (2). They may 
> need to modify it. 
Existence proof, please, aside from the obvious case of a B2BUA which
can munge ANYTHING and still comply with the SIP spec.

> As long as we are aware of this there 
> should be no problem. I also think it will be common to check 
> the URI portion of the From: field but not the Display Name. 
> We can't *assume* From: is ALWAYS of type (2) either. So 
> let's just get on and define a field for this - Network 
> Asserted Identity. ...Mark 
> 
Ah, so we wind up in the same place at the end. Hope everybody bothered
to read this far :-)

Dave.
> > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping 
> > This list 
> is for NEW development of the application of SIP

---

From: [email-masked]
Date: Wed, 17 Apr 2002 09:48:04 +0300

> discussion needs a loop detect feature :-) )

today the FROM field is the ONLY CHOICE that a service provider like me
has to figure out what number the user wants to use as the calling party
number and if the user wants to reveal that number to the called party.
former information is carried in the uri of the from field and the
latter in the display string.

in order to prevent the user from spoofing the calling party number, i
MUST check that the number in the uri of the from field indeed has been
allocated for that user.

if the call gets routed (instead of pstn) to another sip user and if the
user doesn't want to reveal the calling party number, i have no other
choice than to implement a b2bua and rewrite the from field, because
most UAs on the market today don't allow me to modify the from field.
if the situation later changes because of the new sip spec, i can get
rid of the b2bua, which, of course, is a good thing.

could someone clarify me once more what value would rpid give over the
above process?  once i understand what it is, i can weight if i makes
sense for me to start using it or save time and money and just stick to
my current working procedure.

-- juha