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

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

Starting at the end of Dave's response to my comments..

> > 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 :-)

Comments, please, to the requirements I suggested in the Network Asserted
Identity thread - perhaps we can make some rapid progress on this thereby
decide what to do with the current privacy draft.

If you're more interested in the 'philosophy of the From field', read on...

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

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.

Service of this kind can only work if you have some confidence in the field
they are based on. 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.

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

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

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

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

As noted above, the SIP specification does seem to imply that there is some
advantage to be gained by checking the From field is valid, as it is used
for terminating end services other than display.

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

Juha described how his service verified the From field. It is unlikely that
3GPP would be pursuaded to do otherwise if they are pursuaded to use the
From field at all. I described in some detail on the SIP list thread why
this may imply a Data Protetcion requirement to modift the field. I don't
dispute that this may require a B2BUA.

...Mark

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Mark Watson
> Sent: Wednesday, April 17, 2002 5:31 AM
> To: 'David R. Oran'; 'Dean Willis'; 'Sipping (E-mail)'
> Subject: RE: [Sipping] Screened From: and Privacy
> 
> 
> > > Certainly the

Mark responded:
> 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.

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

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

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

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

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

> As noted above, the SIP specification does seem to imply that 
> there is some advantage to be gained by checking the From 
> field is valid, as it is used for terminating end services 
> other than display.
I would agree with you if you reworded to say "that the From field in a
SIP message that you have authenticated and integrity checked contains a
value which leads you to believe you want to accept the call".

> Juha described how his service verified the From field. 
There's nothing wrong with what Juha is doing. If I don't like it I go
get my service from somebody else. He isn't rewiting or asserting random
alternate identifies for me without my knowledge. He's only deciding
what calls to process based on who he believes the call is from. If we
wanted to reject all calls that didn't have the IP address of one of his
customers in the first VIA header that would be OK too!

> It is 
> unlikely that 3GPP would be pursuaded to do otherwise if they 
> are pursuaded to use the From field at all. I described in 
> some detail on the SIP list thread why this may imply a Data 
> Protetcion requirement to modift the field. I don't dispute 
> that this may require a B2BUA.
> 
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?
 
> ...Mark 
Dave. 

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Wed, 17 Apr 2002 11:09:13 -0500

RE: [Sipping] Screened From: and Privacy
Mark says:
---------------
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.
Service of this kind can only work if you have some confidence in the
field they are based on. 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.
---------------

Funny, the From and To fields on your email were "user provided" and my
procmail filter managed to put them in the right place.

There's a fundamental dualism that everybody seems to be missing:

There are user-asserted and network-asserted aspects of alomst
everything, including privacy and identity. Although similar, the
network-asserted thing is NOT exactly the same as the user-asserted
thing. Therefore, I can quite reasonably define services which treat
them differently.

For example, I might have a call filtering service that accepts calls
from phones identified by the network as pay-phones where the
user-provided identity is "George W. Bush", just in case the President
calls me from a pay phone. There's no assurance it will REALLY be him,
but it MIGHT be, so I'm willing to take the call . . .

-----------
> How does this follow as long as you define From: as only
Mark wrote:
-----------

SO STOP REQUIRING THEM TO ENTER SOMETHING SPECIFIC!

----------
> is something the user by definition wants to reveal.
Mark wrote:
But the subscriber may not want it revealed, and the subscriber's wishes
may override the users.
-----------

Fine! The subscriber controls the service routing. This may route the
call through an anonymizer service, which terminates the dialog and
creates a new "safe" dialog. This still leaves the From: field  as "end
to end" as far as SIP is concerned -- the network delivers the
user-entered From: to the far end of the dialog, exactly as required by
the specification.

---------------------
Indeed.
> that's of course just my considered technical opinion.
Mark wrote:
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.
---------------------
In the absence of subscriber or regulatory policy forcing the use of an
anoynizer service, the user's From field gets delivered to the
terminating user. No problem. I have a BIG problem if you want to try to
sell me a service that NEVER delivers my From fields . . .

------------------
somebody wrote
> What is irreversible here?
Mark wrote:
As noted above, the SIP specification does seem to imply that there is
some advantage to be gained by checking the From field is valid, as it
is used for terminating end services other than display.
------------------

Yes! It is useful BECAUSE it is user-provided information, not
controlled by the caprice of  the network, and MAY contain additional
useful infromation. But by no means is it the ONLY pirce of useful
information, and, in the absence of an authentication mechanism, can be
treated only as a hint as to how the message should be processed.

---------------------
> can munge ANYTHING and still comply with the SIP spec.
Mark wrote:
Juha described how his service verified the From field. It is unlikely
that 3GPP would be pursuaded to do otherwise if they are pursuaded to
use the From field at all. I described in some detail on the SIP list
thread why this may imply a Data Protetcion requirement to modift the
field. I don't dispute that this may require a B2BUA.
-----------------------

Juha's service works the way it does because nobody gave him a better
alternative. Like many early implementations, it's a hack. A necessary
hack, but a hack. I suggest not perpetuating it.

--
Dean