Subject: [Sipping] Screened From: and Privacy

From: "Dean Willis" <[email-masked]>
Date: Tue, 16 Apr 2002 08:14:27 -0500

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: Tue, 16 Apr 2002 09:22:02 -0400

Viewing things this way, where the "principal" sending and receiving SIP
messages is some amalgam of a "user" and "the phone" is just asking for
trouble, IMHO. It gets into all sorts of issues about who is doing what,
what the "phone" part is trusted with as opposed to the "user", which
identity various identifiers are bound to, etc., etc., etc.

I believe a much cleaner and simpler model is where there is just a
"user". If there are multiple "users" of a single device, then there
are, logically speaking, multiple UAs in the device, as there would be
for a multi-line phone.

To handle the binding between user and device where needed you do two
things:
A) have the user "login" to the device, using whatever local (or at
least non-SIP, machinery you like)
A) have the UA support a "default" user who is logged in automagically
at boot time to handle the lobby phone, auto-login, etc.

This way there is no confusion about who is doing what and who should be
trusted for what. Trust between the device and user is established
outside SIP. Trust between the user and the rest of the SIP elements is
established via SIP security mechanisms. The device is no more or less
privileged than the user using it.

Dave.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Dean Willis
> Sent: Tuesday, April 16, 2002 9:14 AM
> 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.
> 
> 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
> 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
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 16 Apr 2002 08:33:02 -0500

As I said: Provisioning nightmare.

And when you're using the lobby phone, don't you want to set a display
name? You want to set your own Subject: too, right?

--
Dean

----- Original Message -----
From: "David R. Oran" <[email-masked]>
To: "'Dean Willis'" <[email-masked]>; "'Sipping (E-mail)'"
<[email-masked]>
Sent: Tuesday, April 16, 2002 8:22 AM
Subject: RE: [Sipping] Screened From: and Privacy

---

From: [email-masked]
Date: Tue, 16 Apr 2002 16:39:48 +0300

> from Dad, she wants it to be "from" her.

then you simply define a new "line" to your 7960 phone for your kid and
things work as he/she wants.  the username/password can be either the
same as yours or the kid's own.

 > Now her friend comes over and wants to use the phone to call his mother

in this case, the friend most likely would use your kid's "line" rather
than defining his/her own to the phone.  it is the same as using
someone's cell phone.  most likely the friend would not open it and
replace his/her own sim to the phone in order to make the call, because
that would be too complicated.

i again fail to see what this has to do with the privacy discussion.
when you use someone else's phone, you will also use his/her privacy
setup.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 16 Apr 2002 08:49:01 -0500

> that would be too complicated.

Exactly. But they're going to defin their own Subject field and other
user (not SUBSCRIBER) data. I'm arguing that the display name field
(From:) falls into this category.

> when you use someone else's phone, you will also use his/her privacy

Because if the display name field (From:) is part of the SUBSCRIBER
data, as you are arguing, then it falls into network-controlled privacy
management regulation and we end up with "MUST B2BUA everything." If it
is a USER field, then regulation affects it much more lightly.

What would be the implication if we added a "New" header for
"UserDisplayName" intended for just what I've proposed above? Simple:
The phone people would inist that that be rewritten by the network,
because this MIGHT conflict with Subscriber privacy requirements. Since
the protocol allows extension with arbitrary new headers, the logical
requirement is for "the network" to be required to block arbitrary new
headers, thereby destroying service transparency.

Life is much better if we consider "From:", along with "Subject:" and
other such fields, as  per-call user-provided data intended for display
to the other end of the dialog. Filtering the From, as you are doing,
forces it into the regulatory realm in a way that you're not going to
like.

--
Dean

--
Dean

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 16 Apr 2002 09:45:51 -0400

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, April 16, 2002 9:33 AM
> To: David R. Oran; 'Sipping (E-mail)'
> Subject: Re: [Sipping] Screened From: and Privacy
> 
> 
> 
Why?

> And when you're using the lobby phone, don't you want to set 
> a display name? You want to set your own Subject: too, right?
>
If you care enough, then log into the phone (or authenticate to it for a
single call). Then it's yours, has your secret(s), can authenticate as
you, etc. etc. etc.

If you don't care enough, just use the phone. Then the From: will be 
	From: Unsecured Public Lobby phone <[email-masked]>

And the subject will be 
	Subject: WTF, over?

or whatever the phone vendor stuck into his default config, since nobody
will bother to change it (like the contents of the pad in ISIS hellos,
in which I've seen:
	"this space intentionally left blank"
	"this space for rent"
	"if you're looking at this, you probably are using a sniffer"

Dave.
 
> To: "'Dean Willis'" <[email-masked]>; "'Sipping 
> (E-mail)'" <[email-masked]>
> > This way there is no confusion about who is doing what and 
> who should
> be
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Dean Willis
> > > 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.
> > >
> 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.
> > >
> > > 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
> > > 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: [email-masked]
Date: Tue, 16 Apr 2002 16:52:03 +0300

> name? You want to set your own Subject: too, right?

when i use a lobby phone, i don't want to set anything.  i just use the
phone as it is configured.

how is this relevant to the subject line?

-- juha

---

From: [email-masked]
Date: Tue, 16 Apr 2002 17:22:51 +0300

> (From:) falls into this category.

yes they could if there is an easy way to enter a subject field, which
none of the phones i have seen has.  this is analogous to using someone
else's email account.  you can set the subject line, but not from whom
the message came from, i.e., the from field.

 > is a USER field, then regulation affects it much more lightly.

i'm arguing that the whole from field belongs to the user whose phone
i'm borrowing and there is no problem whatsoever with privacy
regulation.  the privacy what i get is the privacy of the person whose
phone (or "line") i'm using.  if i borrow someone else's cell phone, i
don't get my own privacy, but the privacy of the phone owner. if i want
my own privacy, i need to change the sim.

 > forces it into the regulatory realm in a way that you're not going to

so far we haven't had any other field than the from field to identify
the calling party:

20.20 From The From header field indicates the initiator of the
   request. This may be different from the initiator of the
   dialog. Requests sent by the callee to the caller use the callee s
   address in the From header field. The optional  display-name  is
   meant to be rendered by a human user interface. A system SHOULD use
   4280 the display name  Anonymous  if the identity of the client is to
   remain hidden.

all sip phones on the market include the calling user's address in the
from field.  they do not have any other field for that purpose and thus
i have not had any other way to make sure that the callee address as
seen by the pstn has not been faked.  if i had not used the from field
for that purpose, there could not (for regulatory reasons) have been any
sip to pstn service in finland.

since there is already lots of sip phones on the market owners of which
do want to make pstn calls, i have to keep on screening calls based on
the from field for a very long time to come.  also, many of the proxies
on the marker can today do this from field screening.  changing it so
something else would do nothing else but make things more complicated.

of course operational complexity and backwards compatibility is not a
problem for vendors like dynamicsoft and nortel, who do not need to run
sip services.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Apr 2002 10:27:52 -0400

Bis-09, section 8.1.1.3 says:

  The From header field indicates the logical identity of the initiator
  of the request, possibly the user's address-of-record. Like the To
  header field, it contains a URI and optionally a display name. It is
  used by SIP elements to determine which processing rules to apply to
  a request (for example, automatic call rejection).

For it to be useful for this purpose, there must be some belief
that it is accurate. Otherwise I am going to start claiming I
am Bill Gates every time I call MicroSoft.

Practically speaking it doesn't make sense to consider the display-name portion of the From address when determining processing rules to apply, so that portion should be
open for arbitrary use.

So, in your example, without separate authentication, your kid could set
 
   From: "littlekid" <sip:[email-masked]>

Then the callee would execute call screening rules assuming call was you, but could still see the name "littlekid" displayed.

	Paul

---

From: [email-masked]
Date: Tue, 16 Apr 2002 17:40:09 +0300

Paul Kyzivat writes:

 > Practically speaking it doesn't make sense to consider the
 > display-name portion of the From address when determining processing
 > rules to apply, so that portion should be open for arbitrary use.

i don't check the display name portion except for the value
"Anonymous".
 > Then the callee would execute call screening rules assuming call was you, but could still see the name "littlekid" displayed.

that would be possible to do also in my service, but i agree with david
that is highly unlikely that the friend or lobby phone user would
reconfigure the display name or add a subject line or do anything else, but
would just make the call with the existing settings.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 16 Apr 2002 12:21:10 -0500

Dave asked:
>Dean sad:

We'd have to actually have a provisoined account and establish key
management techniques for each " user" (example, member of the
household) associated with each "subscriber" (example: houselhold).
Operationally speaking, it ain't happenning (there's an RFC for that
term somewhere).

> If you care enough, then log into the phone (or authenticate 
> to it for a single call). Then it's yours, has your 
> secret(s), can authenticate as you, etc. etc. etc.
> 

Well, when I sit down at the lobby PC, or the i-café PC, or whatever, I
manually enter From: and Subject lines on my email. Given a SIP phone
that isn't crippled by a ten-key pad (get over this "it has todays
interface and must therefore be crippled" willya?) why shouldn't I use
the same capability in SIP?

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 16 Apr 2002 12:21:10 -0500

Juha writes:
> Dean Willis writes:
> 
>  > Exactly. But they're going to defin their own Subject 
> field and other  > user (not SUBSCRIBER) data. I'm arguing 
> that the display name field  > (From:) falls into this category.
> 
> yes they could if there is an easy way to enter a subject 
> field, which none of the phones i have seen has.  this is 
> analogous to using someone else's email account.  you can set 
> the subject line, but not from whom the message came from, 
> i.e., the from field.

Look, I realize today's SIP phone's user interfaces are not ideal. I
have however supreme confidence that they'll get better. I just bought a
nifty PDA with a full keyboard under a slide-down cover -- this would
make a nice portable SIP phone.

Remainder of message snipped due to inclusion of name-calling . . . 

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 16 Apr 2002 14:34:13 -0400

> the message came from, i.e., the from field.

Editing the From field is just one more click away on many systems
(Netscape mail). The bad part about the user interfaces is that it is
hard to "escape" temporarily and then reset the old value. More
pernicious are certain email providers (such as a large NY/NJ DSL
provider) that enforce that the From field has to have a certain value,
in a pointless attempt at spam prevention.

> my own privacy, i need to change the sim.

In many cases, just knowing the local policy would be helpful.

---

From: Ofir Arkin <[email-masked]>
Date: Tue, 16 Apr 2002 16:02:48 +0100

Or it would relate to

<sip:[email-masked]>

the way we apply incoming mail rules and will discard "littlekid"?

Ofir

Paul Kyzivat wrote:

>>>in this case, the friend most likely would use your kid's "line"
>>>
>>rather
>>
>>>replace his/her own sim to the phone in order to make the call,
>>>
>>because
>>

-- 
Ofir Arkin
Managing Security Architect
@stake, Limited.
http://www.atstake.com
email: [email-masked]
Tel: +44 (0) 207 495 7002
Fax: +44 (0) 207 495 7062
Mobile: +44 (0) 779 630 8632

-----------------------------
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material.  Any review, re transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you received this in error, please contact the sender and delete the material from any computer.

---

From: Ofir Arkin <[email-masked]>
Date: Tue, 16 Apr 2002 15:00:47 +0100

So you are going to require people to authenticate... or login to the 
device as you put it

Enjoy...
I guess they will appreciate the user experience

Ofir

Dean Willis wrote:

>>Viewing things this way, where the "principal" sending and receiving
>>
>SIP
>
>>messages is some amalgam of a "user" and "the phone" is just asking
>>
>for
>
>>trouble, IMHO. It gets into all sorts of issues about who is doing
>>
>what,
>
>>This way there is no confusion about who is doing what and who should
>>
>be
>
>>outside SIP. Trust between the user and the rest of the SIP elements
>>
>is
>
>>>and Her Very Own RPID (which is contractually iffy in many
>>>
>countries)
>

---

From: John W Noerenberg II <[email-masked]>
Date: Tue, 16 Apr 2002 12:58:15 -0700

>when you use someone else's phone, you will also use his/her privacy

That simplifies things.  It also denies the possibility that one user 
would have different privacy/authentication requirement than another. 
Consequently, it oversimplifies things.

best,

jwn2

---

From: [email-masked]
Date: Tue, 16 Apr 2002 23:34:44 +0300

> Consequently, it oversimplifies things.

no it doesn't.  you can always depending on the situation buy your own
phone or sim or login as yourself to the other person's phone.  the
trade off is between simplicity (use the other person's setting) and
configuration complexity.

-- juha