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

From: [email-masked]
Date: Tue, 16 Apr 2002 10:50:44 EDT

In a message dated 4/16/02 9:50:43 AM Eastern Daylight Time, 
[email-masked] writes:

> > 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.
> 
> Exactly. But they're going to define their own Subject field and other
> user (not SUBSCRIBER) data. I'm arguing that the display name field
> (From:) falls into this category.
> 
> 

No, they are going to simply pick up the phone and dial a number. They are 
not going to log on to a device and create a new profile and whatever else 
just to call home and say "am at Susie's house".

Reminds me of a quote I heard one time. Many years ago when IBM came out with 
the first PC, one of their top execs said "Our goal is to make the computer 
as easy to use as the telephone". Unfortunately, the opposite has happened!

Mike

---

From: "Mark Watson"<[email-masked]>
Date: Wed, 17 Apr 2002 10:41:55 +0100

Juha wrote:

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

Minor point, but when you borrow someone elses phone, you become the 'user'
and you have a right to restrict the delivery of the identity (be it yours,
the phones, the phone owner, the 'line' etc.).

If the subscriber (who may or may not be the person who you have borrowed
the phone from) has requested that this information not be delivered, you do
not have the right to override this.

[At least this is my understanding of the legislation in Europe]

...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Wed, 17 Apr 2002 16:40:41 +0100

Anyone still left apart from me & Dave :-)

> 
> That one's even easier since you don't need to authenticate a blocking
> list. Anybody who masquerades as someone you block will get blocked.
> They just screwed themselves.
> 

I'm worried about the person I have blocked masquerading as someone else,
and so circumventing the blocking.

> > Perhaps I'm missing something, but in the absence of some 
> > global PKI I can't see how authentication helps me as a 
> > called party, except for calls from a limited set of people 
> > that I know and have a relationship with. 
> Right. Is it any different to accept a call from "Bugs Bunny" 
> when it's
> actually Bugs or Osama Bin Laden?
> 

No, but after he has called twenty times, I want to add him to my blocking
list. But then he just calls as "Donald Duck" and I am no better off. I
agree there's nothing I can do about this if the calls are coming from the
an untrusted source and I am stupid enough to accept them at all.

But if the calls were made through a service provider who could authenticate
the caller, I would thank them for not allowing their subscribers to
masquerade as cartoon characters.

> > In the interim 
> > (whilst this PKI is set up), we have a 'trusted service 
> > provider' arrangement (as in 3GPP), where the originating 
> > service provider does authentication and verifies that the 
> > use is who they say they are in the From: field. 
> That doesn't help at all unless I trust the calling user's service
> provider. What good does it do me that "George Bush" using the Chaos
> Computer Club service provider? In the PSTN doing this requires global
> transitive trust, which is unrealistic for the Internet and SIP in
> general. 
>

But this is what we will have in 3GPP. There are other reasons why
inter-operator agreements are needed which are much more important than this
discussion.
 
<snip>
> And I have no problem with somebody wanting to verify them if that's
> what they want to do. It just doesn't have anything to do with SIP the
> protocol.
> 

It does when people are arguing that there is never a requirement to modify
the information in these fields.

<snip>
> > > It's perfectly OK to verify anything in any field if you 
> > want. I'm not
> > > sure this is in fact relevant to the discussion. 
> > > 
> > It is, because if you 'verify' the field (and refuse service 
> > if it is not 'right') you take on responsibility for its 
> > value and this has Data Protection implications.
> >  
> This logical leap does not seem to be justified. It is much 
> better IMHO
> to not depend on this implication. What in the regs leads you 
> to believe
> this is required? If I do RPF verification on the source IP 
> address of a
> packet, does that mean I take responsibility to not reveal the address
> or the subscriber who is using that address? This is a very slippery
> slope!
> 

There is no legislation that I know of which requires Internet Service
Providers to provide an anoymous packet delivery service - i.e. delivering a
packet without revealing the source address.

There is legislation which requires providers of Publically Available
Telecommunications Services to allow their users to make anonymous calls,
and to allow subscriber to require that all calls from that subscription be
anonymous.

I could speculate about why there is this difference between services, but
that is not the point.

If the slope is slippery, it's not me what put oil on it. I am just trying
to explain the situation and ensure that we do not ignore potentially
important requirements. The price for ignoring this stuff is that *more*
regulation gets thrust down your throat - this slope is more slippery still.

> > > <snip>
> > > > > > 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? 
> > > > > 
> > > > The field is NOT 'user-controlled' if the user is forced to
> > > > insert a specific piece of information. 
> > > Sure it is. I can still put anything I want in there. If I 
> > don't like
> > > the fact that the service provider rejects the call I go 
> > use somebody 
> > > else. This is like saying the RequestURI: field isn't user 
> > controlled, 
> > > because I may have subscribed to a free-phone service that 
> > > only lets me 
> > > call certain destinations that don't go through a PSTN gateway. 
> > > 
> > I don't think the discussion makes sense at all if we don't 
> > assume that the user wishes to use the service. (*) With this 
> > assumption, if the user is required by the service to put a 
> > particular value in the From: field, then the service 
> > provider absolutely has responsibility for that value being 
> > there with the associated Data Protection responsibility if 
> > that value is Personal Data. 
> Sort of, but I'll grant the point. In this case the service provider
> chose this technique and has to live with it. That means doing B2BUA
> stuff to anonymize. 
> 

Sure.

> > In your free-phone example, the 
> > service provider has responsibility for the fact that the 
> > Request-URI is one of a certain set of destinations (and the 
> > user has control of which one). But this is not Personal 
> > Data, so there is nothing complex about this. If the user can 
> > choose one of ten possibilities for the From field, but all 
> > of them identify the user in some way, 
> > then although the user 
> > has the choice of which value, they have no choice about 
> > whether to include Personal Data.
> > 
> Why is this of necessity true? I could, for example, do a subscription
> with a service provider which consists of the generator for a one time
> pad with full forward security, and the From field is 
> generated based on
> running the one-time pad. Then every call has a different From: field,
> the From: is completely verifiable based on the one-time pad, and it
> reveals absolutely nothing about the user to any third party.
> 

My argument only applies if the possible values of the From field *do*
contain information which would be meaningful to a third party.

The purpose of any verification is to ensure that the user is not
mis-leading the called party, not to authenticate the user, so if the
information is meaningless to the called user, there is no point in
verifying it at all.

> > 
> > > > > > 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.
> > > > > 
> > > > But the subscriber may not want it revealed, and the
> > > > subscriber's wishes may override the users. 
> > > > 
> > > Then the "subscriber" can, in a proxy of B2BUA controlled 
> > by him (like
> > > the proxy in his basement if a residence, or the border 
> proxy of a 
> > > corporate site) do any scrubbing or call rejection he likes. This 
> > > reliance on the PSTN definitions of user and subscriber 
> are really, 
> > > really getting in the way here. I'm not saying that we ignore the 
> > > distinction. Rather, I am saying that, unlike the PSTN world, 
> > > it is easy 
> > > to trivial to insert an intermediary, controlled by you 
> > that you trust 
> > > to verify and screen outgoing calls, incoming calls, or both. 
> > > 
> > The definitions of subscriber and user are certainly not PSTN 
> > ones. It's common-sense concept applying to any time any 
> > business sells a service in which the person contracting for 
> > the service may not be the same as the person who actually 
> > uses it. If you're not happy with that, the European 
> > legislation on electronic communication defines these 
> > concepts, and you'd better believe it's scope is wider than 
> > the PSTN. 
> Sure, but how does this change my argument? Either all calls 
> are treated
> as though they come from the "subscriber" (i.e. the service provider
> cannot distinguish or otherwise vouch for the various users) or the
> subscriber provides the discrimination themselves. This is an
> unavoidable consequence of the endpoints being on one side of a trust
> boundary and the serves being on the other.
> 

I don't follow this. The subscriber *could* provide their own proxy, but if
the Service Provider accepts that multiple users might make calls under the
same subscription (in the legal sense), they cannot later require the
subscriber to install their own proxy when the subscriber decides to ask for
anonymity services.

The Service Provider could fulfil their obligations by *requiring* that all
subscribers first install such a proxy, before accepting them for service,
but this does not sound like a good business proposition.

> Sure the subscriber can deploy a proxy of their 
> > own. But the legislation requires the subscriber to have a 
> > 'simple means, free of charge' to request the privacy 
> > service, and the responsibility to provide this is placed on 
> > the Service provider. And where would the subscribe put the 
> > proxy for a wireless terminal using a Wireless WAN ?
> Anywhere they want. This is IP.
>
OK, I'm thinking 3GPP. 

<snip>

> > My feeling is that not generalizing enough is what is causing 
> > half this problem in the first place. It would be good to 
> > have a generic mechanism for carrying information subject to 
> > potential Data Protection requirements - somewhere to 
> > 'quarantine' such information - so that future services could 
> > use this container in the knowledge that its Data Protection 
> > status will be recognised even by devices which do not 
> > support the new service. <snip> 
> I respectfully disagree. I think this approach is an infinite 
> sinkhole.
> The cases that need separate identities asserted by the 
> provider are few
> and highly specific, tricky, and not IMHO of general utility beyond
> their specific functions.
> 

I guess my experience from PSTN/ISDN CLI discussions is that there were
vastly more applications for Calling Line Identity than anyone ever
envisaged when they defined the single Calling Party Number field, or even
the Additional Calling Party Number field.

Trying to key services with different requirements off a single field often
resulted in mutually incompatible requirements on which identity should be
in the field, resulting in poorer service to the user.

...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Wed, 17 Apr 2002 17:37:31 +0100

So, there is clearly disagreement on whether screened From: is a BAD THING
or a GOOD THING.

I really feel that trying to argue that one side is RIGHT and the other
WRONG will not get us anywhere, and we should just work with the situation
as it is. I've just been trying to point out why some people have taken the
screening route.

Two things are independent of this, though:
1) The need for Network Asserted Identity
2) The need for anonymity services

For the example service Juha gave, (1) is the only thing which would allow
him to turn off his From screening, so it is a little churlish to argue that
From screening is WRONG when there is presently no alternative.

Regards,

Mark

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]]
> Sent: 17 April 2002 17:14
> To: Watson, Mark [MDN05:EP10:EXCH]; 'David R. Oran'; 'Dean Willis';
> 'Sipping (E-mail)'
> Subject: RE: [Sipping] Screened From: and Privacy
> 
> 
> 
> Mark wrote:
> 
> >I was trying to explain why the text in the SIP 
> specification may have
> led Service
> >Providers to believe that they ought to verify the From: 
> field. You are
> arguing this is
> >a wrong interpretation, but independent of that, I don't think people
> who have
> >interpreted the text that way are being unreasonable.
> 
> I must have missed the 4xx From Header Incorrect response code which
> must be somewhere in bis for this verification of From 
> identity to work
> :-)
> 
> I think this interpretation is totally unreasonable and should be
> dispelled right now for what it is - a mistake.
> 
> Service providers must read Internet specifications very 
> carefully - the
> Internet and its protocols were not designed for them (fortunately).
> 
> Thanks,
> Alan Johnston
> WorldCom
> sip:[email-masked]
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 17 Apr 2002 13:14:38 -0700

> Do you trust your browser to know that the web server you're banking
> with is actually your bank's server, and not somebody else? Probably
--
> but in doing so you trusted Microsoft (really?) to give you good root
CA
> certs. You then trusted the CA to validate the cert of the bank.
> Reasonably solid crypto. It's not impossible to do something similar
for
> SIP identity assertion. How much do we really need?

You are correct in pointing out the elements in the trust chain: in the
case of HTTPS, the software you run, and the list of root-CA that the
software trusts. Am I entirely satisfied that all root-CA are doing a
good job? Well, not entirely, I tend to find that there are too many of
them, about 100; but it is relatively easy to yank a compromised CA from
the list -- I can do that locally, on my PC. OTOH, there are many more
ISP than root-CA, several 10,000, so it is quite obvious that I cannot
trust them all; besides, each enterprise is going to run its own server,
so I would have to trust a few 1,000,000 domains in addition to the ISP.
And I have no way to yank an ISP from the list. So I believe that, if we
want real screening, we need S-MIME.

-- Christian Huitema

_______________________________________________
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: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 17 Apr 2002 14:34:21 -0600

> > Can we assume a Network Asserted Identity is a requirement?  
> > I actually don't agree with all of Mark's proposed requirements 
> > yet, but I think we HAVE to have it.
> 
> No, I do not agree.

Could you elaborate, Christian? What is the alternative?

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 17 Apr 2002 14:47:42 -0600

> So I believe that, if we want real screening, 
> we need S-MIME.
> 
> -- Christian Huitema

Are you suggesting that screening is an all-or-nothing proposition? Imagine what would happen in the web or email systems were held to these standards. 

At some point, it becomes more important to indicate a level of trust and allow the end-user to decide. Reasonable identity assertions are far preferable to toothless guarantees.

--Andy Zmolek 

            [email-masked] 
              +1 720 444 4001

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 17 Apr 2002 13:57:49 -0700

> Could you elaborate, Christian? What is the alternative?

User asserted identity backed by S-MIME or other similar technology.

-- Christian Huitema

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 17 Apr 2002 15:23:41 -0600

> User asserted identity backed by S-MIME or other similar technology.

So we're back to the UAI vs. NAI debate. 

I don't see any compelling reason to pick a winner, but I do agree with earlier assertions that each has unique requirements. What is the benefit gained by precluding NAI? 

--Andy

---

From: [email-masked]
Date: Wed, 17 Apr 2002 19:21:08 EDT

In a message dated 4/17/02 3:31:39 PM Eastern Daylight Time, 
[email-masked] writes:

> I think trusting a network asserted identity would be a big mistake --
> much like trusting a source IP address. Real end-to-end assessment of
> the third party's identity can only result from end-to-end
> authentication, as in S-MIME. Trying to push the trust in the network
> requires a chain of trust between all relays, which is bound to fail in
> a system the size of the Internet.
> 
> 

This all depends on your "network" model. If a telephone call is set up 
through a sucession of "networks" and each one trusts the previous to pass 
valid data because they have interworking agreements, then if the first 
network aserts an identity and labels it as "verified", then every succesive 
network must believe it, just as each network must believe that the sucessive 
network will honor any request to keep the identity private. Yes, there is a 
chain of trust which can not fail in this model. (Yes, I know people will 
jump on that final sentence!)

If, on the other hand, your "network" model is one of a collection of routers 
and entities and network segments in which none can trust anyone else, then 
you are correct. End-to-end authentication becomes necessary if you want to 
believe the identity. However, because of the lack of trust, the identity 
will never be there to check if the originator wanted privacy.

Mike

---

From: [email-masked]
Date: Wed, 17 Apr 2002 19:21:16 EDT

In a message dated 4/17/02 8:13:25 AM Eastern Daylight Time, [email-masked] 
writes:

> > > > to verify the From: field. They've been encouraged in this by 
> > > > to B2BUA everything for subscriber privacy (if you care about 
> > > > RFC2543 clients). 
> Sure it is. I can still put anything I want in there. If I don't like
> the fact that the service provider rejects the call I go use somebody
> else. This is like saying the RequestURI: field isn't user controlled,
> because I may have subscribed to a free-phone service that only lets me

I'm having a hard time understanding why the discussion keeps going around in 
circles. (Except that we're obviously talking about two completely different 
network models.)

Part of the clear requirement expressed before was that the service provider 
would be required to verify the identity of the originator to support 
government mandated tracing capability, etc. If you believe "From" is used 
for this, as some obviously did, then this field is mandatory, it must 
contain a valid identity, and the service provider verifies it. If a service 
provider rejects a call attempt when there is false information in this 
field, it is because they are required to reject it. Every other legitimate 
service provider will do the same.

I believe that this comment and discussion show the vast difference between 
your network model and others and difference of opinion on the requirements.

Mike

---

From: "Mark Watson"<[email-masked]>
Date: Thu, 18 Apr 2002 13:18:52 +0100

Answers to Brians questions: yes, yes and yes.

Brian wrote:
> I  keep wishing we could slice and dice this down to some things we
> agree on and a short list of things we don't, but it doesn't 
> seem to be
> happening.
> 
> I'll try again.
> 
> Can we assume that Mark is correct about SUBSCRIBER (he who pays) as
> opposed to USER rights?   I don't like it, but I conclude we
> are stuck with it.
> 

The subscriber legally contracts for the service - probably best to leave
payment out of it.

> I actually
> don't agree with all of Mark's proposed requirements yet, but I think
> we HAVE to have it.
> 

My requirements were a straw man - I only have a strong view on the first
two anyway.

> Can we possibly agree that an anonymizing B2BUA, provided by a service
> provider, would be the only way to achieve real privacy?  I 
> don't think any
> of the short cuts like messing with this header or that 
> header will do.
> 

The level of privacy needed to meet regulations, user requirements, service
requirements, common sense etc. is in my view tbd. Different services will
be applicable in different circumstances & we don't have to standardise one
single privacy service now (or ever).

I wasn't arguing for a 'short cut' of header modification, just that From/To
modification was *one aspect* that any privacy service would need to
provide.

> The only practical problems I am aware of with an anonymizing
> B2BUA are crypto and DOS. In general, you can't use any kind of crypto
> unless 
> the B2BUA has the right secrets.  I vaguely remember some research on
> anonymous crypto, but in general, it isn't interesting to be 
> secure and 
> anonymous completely. You could arrange security against outside 
> snooping as long as the service	provider was part of 
> the trust domain 
> (which means the B2BUA could be trusted) and still be anonymous. 
> 
> If we had a reasonable network asserted identity, I think that is
> sufficient to avoid the kinds of problems Christian pointed out
> with anonymizers.  It's not truly anonymous - the SP knows who
> called.
> 
> Brian
> 
>  
> 
> 
> From: Mark Watson [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 12:38 PM
> To: 'Alan Johnston'; 'David R. Oran'; 'Dean Willis'; 'Sipping 
> (E-mail)'

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 18 Apr 2002 09:20:11 -0600

> you could define another header field for that purpose, but in the
> meanwhile, i need to be able to run my sip service with CURRENT UAs,
> proxies, and sip/ss7 gws all of which today support the from uri +
> display string trick as i have described.  since my basic 
> rule is "if it not broken, don't fix it", i'm not interested to 
> change the current working practice just for the sake of it.
> 
> -- juha

Sure, it's possible to hack current SIP to do just about anything, particularly if the right simplifying assumptions are made, but there is always a trade-off and this thread alone has highlighted many. But your argument basically boils down to:

"I don't have a problem with using my hack to solve my problem, so why don't the rest of you go away and leave things the way they are so I don't have to deal with any change"

Given that more than a one good requirements statement has been made for REAL problems with the current approach (and I think Jon's drafts make this abundantly clear), taking a Luddite stance isn't helpful. 

sip-change happens.

--Andy

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 18 Apr 2002 10:10:50 -0600

Juha writes:

> seems that you didn't understand how things happen (which i have
> explained already at least twice before).

Existing practice is only one factor to be considered for standards requirements. Your point has been made and understood, but that doesn't make it normative or binding on the standards process or implementers.

> > Again, what is the benefit gained by forcing a choice 
> > between UAI and NAI? I don't see it.
> 
> i don't understand how this relates to what i have said.  

Your approach, from what I can tell, precludes the possibility of having both UAI and NAI associated with a dialog. Either could be hacked into current headers, but a choice would have to be made by someone along the way. Why force that choice? Backwards compatibility and header reduction appear to be your sole arguments for this, but it's not clear that separable a NAI mechanism would break anything. 

--Andy