Subject: RE: Private Info in To/From (was RE: FW: [Sip] Comment, SIP Priva cy draft)

From: "Mark Watson"<[email-masked]>
Date: Wed, 3 Apr 2002 11:05:23 +0100

Rohan,

I'm not sure Proxy-Authorization is appropriate because the information that
we need to supply is nothing to do with Authentication or Authorisation. The
user is already authenticated and the first-hop proxy knows which user the
INVITE is from by virtue of the first-hop integrity mechanism.

However, for a given user, there are multiple identities which that user is
allowed to use, and the user needs to select on a call by call basis which
of those is being used for this call.

If the user does not require any privacy, then this could go in the From
field. But if the user requires privacy, where should it put it ?

...Mark

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: 02 April 2002 18:46
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: 'Dean Willis'; [email-masked]
> Subject: RE: Private Info in To/From (was RE: FW: [Sip] Comment, SIP
> Privacy draft)
> 
> 
> 
> 
> On Tue, 2 Apr 2002, Mark Watson wrote:
> 
> > Dean wrote:
> >
> > >
> > > "The SIP protocol explicitly sends the From and To fields to the
> > > destination UA. Therefore the sending UA should only insert
> > > information
> > > in the From and To fields that is intended to be delivered to
> > > other UAs
> > > and potentially displayed to the user of the other UA. If 
> the user of
> > > the UA wishes to remain anonymous, they must not insert any
> > > information
> > > into the From or To fields which compromises this 
> anonymity. This same
> > > caveat applies to every other aspect of SIP, including headers and
> > > bodies, except for those elements which are explicitly removed or
> > > encrypted by intermediate elements known to the UA."
> > >
> >
> > OK, so let's work with this and see where we get...
> >
> > 1) The UA may insert information which later becomes 
> private due to the
> > operation of services within the network. The device that 
> detects this must
> > either edit the From/To fields itself, or explicitly route 
> to an Application
> > Server which can do this & anything else needed to provide 
> the necessary
> > privacy.
> >
> > Is everyone happy with this ? Can we descibe it somewhere ?
> >
> > 2) The From/To fields cannot be used for communication from 
> UE to network
> > entities of identity information which the user wishes to 
> be kept private
> > (no way to indicate this)
> >
> > 3GPP has a requirement for information of type (2). They 
> had planned to use
> > RPID, since this was an element 'which is explicitly 
> removed or encrypted by
> > intermediate elements known to the UA'. They cannot use the 
> Authentication
> > mechanism, because in 3GPP this is only done at registration
> 
> It seems that 3GPP could use an unsolicited Proxy-Authorization header
> with the correct public identity identified as the username.
> 
> thanks,
> -rohan
> 
> > (with first hop
> > integrity used for subsequent transactions) and the 
> information to transport
> > can change on a call by call basis.
> >
> > So what should 3GPP use for this information ?
> >
> > Regards,
> >
> > Mark
> >
> 
>

---

From: "Mark Watson"<[email-masked]>
Date: Wed, 3 Apr 2002 11:10:05 +0100

Dean wrote:

> 1) Absolutely not. The information is what was inserted by the UA. It
> cannot become private "somewhere else in the network" for that dialog.
> The only way to change it is to make a new dialog. Or maybe 
> that's what
> you mean and I'm just being dense.
>

Information inserted by the UA absoutely can become private somewhere else
in the network.

Now if this means that a new dialog is required, then so be it, and then a
genuine full-blown B2BUA is required to mediate between incoming and
outgoing dialog.

Examples: (1) The user inserts their identity, but the subscriber of the
outgoing service being used requires outgoing sessions to be anonymous. Only
the outgoing proxy knows this - well, it's a B2BUA now.

(2) A calls B, who forwards to C. B requires privacy, but unfortunately A
has inserted B's identity in the To field. So the proxy performing
forwarding for B must modify the To field - OK, so it's a B2BUA too.

Anyone offering a public service will need to deal with (1).

Anyone offering a public service who wants to provide call forwarding will
need to deal with (2).

Also, as per my reply to Christian yesterday, it's unclear to me why these
requirements should not also apply to 'private' services in the case that
these are extended outside individual organsiations so as to effectively
replace 'public' services.

If we place no requirements whatsoever on the contents of the To/From
fields, then I guess we could argue that, like Subject: etc., it's not our
lookout what the UA puts in those fields. But we are a very long away from
this - the clear intention of the specification is that the To/From fields
should contain URIs for the called/calling parties resp. A genuine
'anonymous forwarding' service would probably have to remove things like
Subject as well.

It's hard to see how we could argue that service which did not operate as I
described in (1) & (2) had the necessary regulatory privacy capabilities
when we know very well that most UAs will put this information in the
From/To fields.

So, you can't offer a public SIP service without B2BUAs. I'm not casting
judgement on this situation, but I think we should be clear about where we
are. Is everyone happy with this ?

> 2) part 1: Yes! Part 2: 3GPP terminals had better be able to use
> Authentication anytime it's required by a downstream system or they
> aren't conformant to the SIP model as I understand it. Just 
> because they
> think they are only going to authenticate REGISTER doesn't 
> mean they can
> get away with not supporting it in the other usual 
> transactions. So I'd
> suggest that if IETF can come up with something like a third-party
> authentication model that adresses the transitive identity expression
> requirements, that  3GPP could figure out how to use it.

I'm sure that SIP clients on 3GPP mobiles will be able to cope with
Authentication requests from downstream proxies just as well as any other
SIP client. However the requirement in this case is for information to be
passed to the first-hop proxy on all calls.

There is no authentication exchange between UA and first-hop proxy, and
there is no need for an authentication function here because we are using a
first-hop integrity mechanism to link all messages between UA and first hop
proxy back to the authentication performed at registration.

This is not about authentication. It's about the need to pass some
supplementary information to the first-hop proxy which is needed for the
processing of the call, but which must not be shown to the UAS. This
information just so happens to be in the form of an identity.

...Mark

> From: Dean Willis [mailto:[email-masked]]
> Sent: 03 April 2002 05:19
> Cc: [email-masked]
> Mark wrote:
> ---------------
> 1) The UA may insert information which later becomes private 
> due to the
> operation of services within the network. The device that detects this
> must either edit the From/To fields itself, or explicitly route to an
> Application Server which can do this & anything else needed to provide
> the necessary privacy.
> 2) The From/To fields cannot be used for communication from UE to
> network entities of identity information which the user wishes to be
> kept private (no way to indicate this)
> 3GPP has a requirement for information of type (2). They had 
> planned to
> use RPID, since this was an element 'which is explicitly removed or
> encrypted by intermediate elements known to the UA'. They 
> cannot use the
> Authentication mechanism, because in 3GPP this is only done at
> registration (with first hop integrity used for subsequent 
> transactions)
> and the information to transport can change on a call by call basis.
> -------
> 1) Absolutely not. The information is what was inserted by the UA. It
> cannot become private "somewhere else in the network" for that dialog.
> The only way to change it is to make a new dialog. Or maybe 
> that's what
> you mean and I'm just being dense.
> 
> 2) part 1: Yes! Part 2: 3GPP terminals had better be able to use
> Authentication anytime it's required by a downstream system or they
> aren't conformant to the SIP model as I understand it. Just 
> because they
> think they are only going to authenticate REGISTER doesn't 
> mean they can
> get away with not supporting it in the other usual 
> transactions. So I'd
> suggest that if IETF can come up with something like a third-party
> authentication model that adresses the transitive identity expression
> requirements, that  3GPP could figure out how to use it.
> 
> --
> Dean
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 3 Apr 2002 05:33:14 -0600

A quick couple of notes below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 2:10 AM
To: 'Dean Willis'
Cc: [email-masked]
Subject: RE: Private Info in To/From (was RE: FW: [Sip] Comment, SIP Priva
cy draft)

Examples: (1) The user inserts their identity, but the subscriber of the
outgoing service being used requires outgoing sessions to be anonymous. Only
the outgoing proxy knows this - well, it's a B2BUA now.
[Peterson, Jon] One could just as easily argue that this is a requirement
not to force such services into the local outbound proxy. The UA could
always dynamically learn about privacy preferences from the service provider
in some fashion, and the service provider could reject requests (at the
local outbound) that don't conform to the privacy rules. And we should when
possible push SIP features to the endpoints anyway.

(2) A calls B, who forwards to C. B requires privacy, but unfortunately A
has inserted B's identity in the To field. So the proxy performing
forwarding for B must modify the To field - OK, so it's a B2BUA too.
[Peterson, Jon] If B redirects A to C instead, we might get some better
leverage on this problem - that could be one way that B could 'require
privacy'. Today the SIP spec RECOMMENDs that the To field in the new request
following the redirection be the same as the To field in the original
request (although it says UAs MAY update the To and whatnot if they are so
inclined) - however, the spec also allows you to insert replacement headers
into the URL, like:

Contact: sip:[email-masked]?To=[email-masked]
<mailto:sip:[email-masked]?To=[email-masked]> 

I bring these points up not because I disagree that intermediaries providing
privacy and identity will often need to be More Than Just A  Proxy - but I
think there are reasonable attacks on the examples you happen to raise here
that don't require resorting to a B2BUA. Let's not be too quick to close
doors.

---

From: [email-masked]
Date: Wed, 3 Apr 2002 08:42:55 -0500

Police departments or emergency shelters may be interested in a forwarding
service that requires anonymity.

"Peterson, Jon" <[email-masked]>@ietf.org on 04/03/2002 09:32:27
AM

Sent by:  [email-masked]

To:   "'Mark Watson'" <[email-masked]>, "'Dean Willis'"
      <[email-masked]>
cc:   [email-masked]

A few  more notes below.

Jon  Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson  [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002  3:59 AM
To: 'Peterson, Jon'; 'Dean Willis'
Cc:  [email-masked]
Subject: RE: Private Info in To/From (was RE: FW: [Sip]  Comment, SIP Priva
cy draft)

MW> I'm happy with any solution which works &  the above sounds promising.
How would we get the privacy preferences to the  UAC & is it backwards
compatible ?
[Peterson, Jon]  It sounds to me like an  instance of the general SIP UA
configuration problem - we already do have an  action item to tackle that.
Sure, there's work to be done, but the same is  true of the B2BUA approach.
Not sure what you're concerned about this being  backwards compatible with,
exactly.

MW> The point I'm trying to make is exactly that intermediaries  providing
privacy *will* often need to be More Than Just A Proxy, and I'm  trying to
see if others on the list agree with this. Some of the 'Bad Things'  that
people are concerned about with respect to From/To are happening because
people are trying to solve these privacy problems *without* realising that
they need More Than Just A Proxy.
[Peterson, Jon] Agreed (but we knew  that).

With respect to your example, I can't see that you could trust  A's UA to
do this correctly, and there is no device that the new A->C call  will pass
through which could reject it if A does not follow the rules in the  new
URI. Passing the privacy requirements back to the UA is a good idea, but
only works if there are proxies in a position to reject requests where the
UA  has not obeyed the privacy requirements.
[Peterson,  Jon] I can't imagine that, in any network likely to interest
you, A  wouldn't have a hardwired pre-loaded Route to its local outbound
that would  ensure the A->C path has some adult supervision, and that the
local  outbound would be in the redirection response path anyway (from the
Vias on  the original A->B request). If it is so exceptionally paranoid
about  misbehaving UAs, it could enact any number of policies to make sure
that  nothing goes awry.

But I wonder, do the regulatory  constraints that make this a requirement
also levy a hefty fine on A if he  reveals to C in the ensuing voice
conversation that he had originally dialed B? When the  redirection with
the Contact address I described in my last mail arrives at A, A would  have
to intentionally countermand it in order to reveal B's identityin the
signaling. But A is of course empowered to reveal  B's identity through
other means anyway. I have a hard time seeing what the  big deal is. B only
remains anonymous at  A's sufferance  anyway.

...Mark

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 3 Apr 2002 07:32:27 -0600

A few more notes below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 3:59 AM
To: 'Peterson, Jon'; 'Dean Willis'
Cc: [email-masked]
Subject: RE: Private Info in To/From (was RE: FW: [Sip] Comment, SIP Priva
cy draft)

With respect to your example, I can't see that you could trust A's UA to do
this correctly, and there is no device that the new A->C call will pass
through which could reject it if A does not follow the rules in the new URI.
Passing the privacy requirements back to the UA is a good idea, but only
works if there are proxies in a position to reject requests where the UA has
not obeyed the privacy requirements.
[Peterson, Jon] I can't imagine that, in any network likely to interest you,
A wouldn't have a hardwired pre-loaded Route to its local outbound that
would ensure the A->C path has some adult supervision, and that the local
outbound would be in the redirection response path anyway (from the Vias on
the original A->B request). If it is so exceptionally paranoid about
misbehaving UAs, it could enact any number of policies to make sure that
nothing goes awry.

But I wonder, do the regulatory constraints that make this a requirement
also levy a hefty fine on A if he reveals to C in the ensuing voice
conversation that he had originally dialed B? When the redirection with the
Contact address I described in my last mail arrives at A, A would have to
intentionally countermand it in order to reveal B's identity in the
signaling. But A is of course empowered to reveal B's identity through other
means anyway. I have a hard time seeing what the big deal is. B only remains
anonymous at A's sufferance anyway.

...Mark

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 5 Apr 2002 14:51:59 +0100

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 02 April 2002 15:55
To: 'Mark Watson'
See below

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

Cc: [email-masked]
Subject: Private Info in To/From (was RE: FW: [Sip] Comment, SIP Privacy
draft)

Mark wrote:
-----
The root problem is this: A UA cannot place 'private' or 'potentially
private' information in the From or To fields.  

This is because there is no mechanism defined to ensure that such
information is not passed to other UAs. In the absence of such a
mechanism, no requirements can be placed on what a UA does with the
From/To fields. If we do not place any requirements on these fields,
then we cannot reliably use them for anything.
------

I think this is statement of the situation clearly brings out the
misunderstanding driving this whole thing.

This logic will eventually lead us to deleting all headers or bodies
provided by the UA in at attempt to enforce "privacy" against the wishes
of the actual user. It also precludes intentially authenticating the
user to a service on the other side of the home proxy, as such
authentication by definition is an exposure of private information.

I would restate as follows:

"The SIP protocol explicitly sends the From and To fields to the
destination UA. Therefore the sending UA should only insert information
in the From and To fields that is intended to be delivered to other UAs
and potentially displayed to the user of the other UA. If the user of
the UA wishes to remain anonymous, they must not insert any information
into the From or To fields which compromises this anonymity. This same
caveat applies to every other aspect of SIP, including headers and
bodies, except for those elements which are explicitly removed or
encrypted by intermediate elements known to the UA."

[KED] I think the issues here are that the SIP specification very clearly
indicates that an identity is inserted in the From field (   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. ) and therefore the protocol denies the
user privacy in this respect. Secondly, if the user has the ability to
insert information in this area, then this is not a location that can be
used for inserting a network asserted identity. I do not therefore see the
From header as a place for putting this network (third party) asserted
calling user identity.

--
Dean

---

From: "Mark Watson"<[email-masked]>
Date: Mon, 8 Apr 2002 11:29:34 +0100

It's not about 'regulated vs non-regulated networks' - the requirements stem
from Data Protection which applies whenever a third party gets involved in
processing personal data of an individual. The involvement of regulators
comes in terms of helping industry understand how the underlying Data
Protection legislation applies to particular services, at least this is what
has happened in Europe. Your first argument in the event of a dispute would
probably be via the regulators, but not necessarily.
 
It is not you or I who would have to defend ourselves in the event of a Data
Protection dispute - it is the Service Providers. I would be interested to
hear from any Service Providers on this list whether they feel the approach
suggested by Dean below would give them enough protection from accusations
of Data Protection breaches.
 
I can't argue with your statement below - From/To get delivered unchanged to
the terminating point of the *dialog* - My contention is that to meet Data
Protection requirements, Service Providers will need to provide services
which modify From/To in the network, necessarily involving terminating the
dialog and joining it onto a new one.
 
Finally, I'll say it again, suppose we put statements in the spec now about
From/To being end-to-end transparent fields. Suppose I offer a 'subscriber
privacy' services, which strips out what it can e.g. Call-Info, Subject
etc., but leaves From/To untouched. Now almost all calls go though with
personal data of the subscriber in the From field. Are you really saying
that this would be a satisfactory 'subscriber privacy' service ? Are there
any Service providers which agree with this ?
 
Regards...Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 06 April 2002 02:16
To: Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon'
Cc: [email-masked]
Subject: Re: Private Info in To/From (was RE: FW: [Sip] Comment, SIP Priva
cy draft)

Mark wrote:
--------
You seem to be arguing that privacy services in the network which modify
From/To are not required at all. This could only be the case if the
'From/To' information had the same status as, say, SMIME bodies in terms of
what the UA is required to put in there. OK, so the SIP spec does not state
a hard requirement on what should be put in there, but there is certainly a
clear implication that it should be the calling/called party identities and
indeed this *is what we want* to happen for the consistent operation of SIP
services.
--------
 
Yes, that's exactly what I'm saying. Do we need to spit out a new draft "SIP
Over Regulated Networks" saying "The stuff in the To and From and fields are
user-provided information which will be delivered without modification to
the termination point of the dialog"? which can the be referenced along with
bis09 by implementors of  regulated services?
 
--
Dean