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

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

Dave wrote:

> Mark wrote:
> > An incoming call barring service, or other filtering service 
> > based on the origin of the call, is no use whatsoever if it's 
> > based on how the calling user 'wishes to be known', as it 
> > give the caller an easy way to override my service. 
> How did you get there? The screening service can always challege the
> calling user to authenticate. Anything in a callee's call 
> screening list
> is something he put there, and hence can include 
> authentication as well
> as authorization parameters.
> 

Suppose I have a list of people I do NOT want to accept calls from. I'm not
likely to have authentication data for *everyone else in the world*.

> > Service 
> > of this kind can only work if you have some confidence in the 
> > field they are based on. 
> Yup. That's what cryptographic authenication/integrity/authorizationb
> are for. Waving your hands and saying that something 
> (anything!) can be
> relied on because you think it was stuffed in the message by a service
> provider you trust is hoodoo. The need for RPID asises not for these
> mundane reasons, but for the need to cover the very few very tricky
> cases of call trace and anonymous call return and possibly a couple of
> others I can't recall at the moment.
> 

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.

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.

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'm happy to try this agument at 3GPP and see how many people agree with
you. My feeling is that with the specification as it is, and only 2 months
to work with, that the view will remain that these fields need to be
verified if they are used at all.

> > The fact that the SIP specification 
> > implies such services might be based on From: has quite 
> > reasonably led service providers to believe they should 
> > verify this field. You argue that this is a mistake - mayby 
> > so - but that doesn't change the words in the spec. 
> > 
> 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.
 
> <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.

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.

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

> > 
> > > > I can't see a clean way out
> > > > of this. 
> > > Well, RPID may not be perfect, but it does get us out of this.
> > > 
> > Indeed. 
> > > > 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. 
> > > 
> > I think the consequences of the purely end-to-end 
> > interpretation, are that for Service Provider environments, 
> > we essentially invent an 'alternative From' field, and the 
> > From field itself does not get used. I don't have a big 
> > problem with this, but I thought others did.
> I think the problems arise from trying to make this into some
> general-purpose alternate identity scheme where we just re-create all
> the authentication ad authorization problems of the existing 
> end-to-end
> fields except now the problem is middle-to-middle or 
> middle-to-end over
> multiple hops. Something restricted of this sort is needed 
> for malicious
> call trace and aonoymous call return, but my suspicion is 
> that trying to
> over-generalizew is what sends this into la-la-land.
> 

My feeling is that not generalising enough is what is causing half this
problem in the first place. It would be good to have a generic mechanism for
carrying informationm subject to potential Data Protection requirments -
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>

> Look, the basic connundrum is how to process calls for which the user
> has declared anonymity while allowing call trace and a few 
> other special
> cases. Can we agree at least one that?
>  

Yes. I think the need for the Network Asserted Identity is a slightly
different debate where we do agree. Do you have any comments on the
requirements I sent out yesterday ?

...Mark

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 17 Apr 2002 10:56:21 -0400

> -----Original Message-----
> From: Mark Watson [mailto:[email-masked]] 
> Sent: Wednesday, April 17, 2002 8:54 AM
> To: 'David R. Oran'; 'Dean Willis'; 'Sipping (E-mail)'
> Subject: RE: [Sipping] Screened From: and Privacy
> 
> 
> Dave wrote: 
> > Mark wrote:
> > How did you get there? The screening service can always challenge
the
> Suppose I have a list of people I do NOT want to accept calls 
> from. I'm not likely to have authentication data for 
> *everyone else in the world*.

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.

> > Yup. That's what cryptographic 
> authenication/integrity/authorization
> > provider you trust is hoodoo. The need for RPID arises not 
> for these 
> 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?

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

> 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'm 
> happy to try this argument at 3GPP and see how many people 
> agree with you. My feeling is that with the specification as 
> it is, and only 2 months to work with, that the view will 
> remain that these fields need to be verified if they are used at all.
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.

> > > verify this field. You argue that this is a mistake - maybe 
> 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!

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

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

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

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.

> > call trace and anonymous call return, but my suspicion is 
> > that trying to 
> > over-generalize is what sends this into la-la-land. 
> > 
> 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.

> > Look, the basic conundrum is how to process calls for 
> which the user
> Yes. I think the need for the Network Asserted Identity is a 
> slightly different debate where we do agree. Do you have any 
> comments on the requirements I sent out yesterday ? ...Mark 
> 
I think I sent something out already, but I'll check.

_______________________________________________
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: Alan Johnston <[email-masked]>
Date: Wed, 17 Apr 2002 11:14:10 -0500

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]