Subject: RE: [Sipping] Privacy comment (was Re: calling number blocking at sip/isup gate way)

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 26 Feb 2002 18:01:31 -0600

Well, I mean, it's three days to IETF cut-off and sip-privacy needs to pass.
There's only so much we're going to be able to agree to in this time frame.
I continue to feel strongly that we should restrict the scope of RPID to
network-asserted identity. If it is in this scope, then I for one wouldn't
oppose the passage of the draft.

Just to be clear, what I object to here is the use of sip-privacy-03 for
user-asserted identity, not for user-requested privacy. I can live with
allowing UAs to add RPID-Privacy to requests; once the user then proves the
identity that will be asserted by the network in the RPID, the network can
include the privacy preferences expressed in the RPID-P  - although of
course IMHO having separate headers for either user-asserted identity or
privacy is cumbersome.

Below I don't believe that you substantiate any new need for user-asserted
identity. 

To the 'evaluation of the existing headers' point, Proxy-Authorization is
such an existing header - so in fact I'm not arguing that the result of
authentication is insufficient; I was just speaking to the fact that a
'public' identity sounds like a name for the identity that a user would like
other users to see (is there a name for that identity in your scheme?). I
would also note that there are numerous elements of RPID in sip-privacy-03
(including the screening indicator, the presence of a "privacy" parameter in
RPID separate from the RPID-Privacy header) that suggest to me that RPID
should not be added by untrusted entities (i.e. users) - eliminating or
reinterpreting these would seem to change the sense of RPID a bit.

To go into this much further will probably raise more serious questions
about the draft overall. I can't say I would recommend that at this
juncture. Suffice it to say that I hope you agree that Basic Privacy
(sip-privacy-03 7.1) is not going to be regulatory-grade in most countries.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, February 26, 2002 11:40 AM
To: Peterson, Jon; [email-masked]
Subject: RE: [Sipping] Privacy comment (was Re: calling number blocking at
sip/isup gate way)

The difference between RPID and the existing headers is that RPID includes
support for Privacy. The UA cannot include anything in any of the existing
headers that the user is not happy to have presented to other users.
However, if the UA trusts the proxy, it can insert such information in the
RPID.
 
If you accept that an RPID inserted by a proxy might need to be based on
'evaluation of the [existing] headers ...', then you accept that it is not
sufficient to have it based only on the authentication result. But if you
only allow the existing headers to be evaluated, you limit the information
the UA can provide for this purpose to 'public' information.
 
In the 3GPP case, your proposal would equate to placing the 'public
identity' in the From, Reply-To or Contact field:
 
'From' cannot be used (in all cases) because the UA cannot be required to
reveal the public identity to other users (due to Data Protection), and the
proxy cannot modify the From field. The From field therefore contains a
crypto-random hash or something similar.
 
Both Reply-To and Contact have meanings of their own, which may result in a
need to include in them a different address from the 'public identity'
making the call. As with From, Contact is limited to containing information
which can be revealed to other users and although Reply-To could be policed
out by a proxy before forwarding to an untrusted element, there is no way
for the UA to indicate to the Proxy that it should do this (although I guess
this could be added).
 
The UA is required to declare the public identity that is making the call to
the network, though.
 
I agree with your concern about proliferation of 'identity' headers, and I
did advocate implementing Reply-To using RPID, which would have reduced the
count by one. However, headers without support for privacy are all useless
in an environment where the UA is required to reveal certain information to
the network (proxies) to access a service, but where that information does
not _need to_ be passed to other users in order for the service to operate.
In these circumstances the calling user has a right to keep such information
private from other users. So the UA needs some way of ensuring that the
proxy knows this information must not be so revealed. Encryption is always a
(perhaps cleaner) solution, but has its own problems, and as this scenario
never exists without a trust relationship between UA and proxy, RPID does
the job.
 
Regards...Mark

 -----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 26 February 2002 05:36
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]
Subject: RE: [Sipping] Privacy comment (was Re: calling number blocking at
sip/isup gate way)

Although I appreciate the explanations that you and Dean have given, I don't
think I really understand what these public and private identities signify.
I do believe that the scope of the RPID seems much more comprehensible to me
if it is restricted to network-asserted identity. Again, there are already a
number of fields in SIP where the originating user, and user agent, can
represent themselves with URIs. The user can populate the From and Reply-To
(not to mention Authorization) header fields with AoR identities
representing themselves, and the user agent can populate the Contact header
with a contact address representing itself. Clearly, there is no requirement
that these all say the same thing, and I'd be surprised to learn that in
combination they can't do more or less what you'd need. I'm not sure,
anyway, why the solution would be to throw more headers at the problem. RPID
makes sense to me scoped as an identity that is asserted by network
operators based on their assessment of the user's identity, possibly
resulting from the evaluation of the headers mentioned above (or even
lower-layer or out-of-band security functions).

I think your call center architecture below is permitted today by the
existing baseline authentication system. There is no necessary
correspondence between the username of the URI given in the From field in a
request and the username/password that is provided by a user agent in
response to a challenge. While many proxy servers would legitimately require
that the two be the same, clearly your call center's proxy would be happy to
allow the From field to represent the call center's AoR (an 800-number,
say), while the username/password provides credentials that identify the
user. An even better scenario might involve the Reply-To header as well,
providing a means for the callee to reach the same call center agent when
appropriate. I don't think the requirements of this architecture, at any
rate, give rise to a need for the RPID, let alone for a user to provide an
RPID.
 
Jon Peter so n
NeuStar, Inc.
-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, February 25, 2002 4:46 AM
To: Peterson, Jon; [email-masked]
Subject: RE: [Sipping] Privacy comment (was Re: calling number blocking at
sip/isup gate way)

Jon wrote:
 
> This works fine for cases in which a single UA is used by multiple users,
or when a single user has multiple provable identities.
> It assumes that you have a one-to-one mapping between credentials and
identities, but that's usually par for the course.
 
This assumption does not hold in the 3GPP case where authentication is based
on a 'private identity' and associated keys in the SIM, but where there may
be multiple 'public identies' associated with this single 'private
identity'. In particular, this allows you easily to add/remove/manage the
'public identies' without getting involved in key management/distribution.
All that is necessary to manage to public identities is to update the
subscription information that the proxy uses to verify that a particular
public identity is allowed for the particular private identity.
 
In addition I can think of cases where the identity that the user may wish
to have presented to the terminating UA, to the PSTN or other elements, may
differ from the identity that they use for local authentication. For
example, imagine an outbound call centre where all the agents use SIP
terminals. For obvious reasons each agent must authenticate to the local
proxy using a personal identity, but the identity they wish to be known by
to the called party is the Freephone number of the call centre (or even a
different, inbound, call centre).

Cheers...Mark

 -----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 22 February 2002 18:26
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]
Subject: RE: [Sipping] Privacy comment (was Re: calling number blocking at
sip/isup gate way)

Actually, I have a few slight confusions about the text below (it seems to
use UA and user interchangeably a bit, which is worrisome when we're talking
about proving identity). One question would probably clear things up:
 
If the proxy still needs to authenticate the user (through whichever
mechanism) to ensure that the identity that has been asserted in the RPID is
valid for the user in question, why does the user need to supply an RPID at
all? Why doesn't the user just authenticate itself to the proxy (however
that happens) and let the proxy insert the RPID corresponding to the
identity that the user has proven? This works fine for cases in which a
single UA is used by multiple users, or when a single user has multiple
provable identities. It assumes that you have a one-to-one mapping between
credentials and identities, but that's usually par for the course.
 
Again, if the proxy server holds a mapping between credentials and valid
identities itself, as you suggest below, it doesn't seem at all unreasonable
to adopt this model.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, February 19, 2002 12:29 PM
To: [email-masked]
Subject: [Sipping] Privacy comment (was Re: calling number blocking at
sip/isup gate way)

As presently described in privacy-03, the Remote-Party-ID header is only
ever inserted by proxies, based on the proxy's knowledge of the identity of
the UA (which it determines from some authentication mechanism out of scope
of the privacy draft).
Privacy-02 allowed the UA to insert Remote-Party-ID too. I think this should
be reintroduced for the *specific case* of a UA with multiple identities, to
allow the UA to choose which identity it wishes to be known by. The Proxy
would still be responsible for ensuring that this identity was valid for the
user and would still use some other authentication scheme to authenticate
the user. The proxy would need knowledge of which identities were valid for
which users.
I believe this is a requirement for 3GPP, where a UA can have multiple
'public identities' and chooses which of these it wishes to be known by for
each call. The proxy authenticates the UA by some other means and then
checks the subscription data to ensure it is really allowed to use the
public Identity it has included. 
I've suggested this a few times, and there has not been much comment for or
against. It would be good if we could get a resolution before the next
version of privacy is published.
So, comments ? 
Regards...Mark 

> -----Original Message----- 
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 18 February 2002 23:12 
> To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]; 
> [email-masked]; [email-masked] 
> Subject: Re: [Sipping] RE: [Sip] calling number blocking at sip/isup 
> gateway 
> 
> 
> Mark said: 
> 
> > Your example below needs only a small extension to 
> illustrate Mike's point 
> > and show why something like Remote-Party-ID as defined in 
> the privacy 
> draft 
> > is needed, and how it works despite the lack of a signature. 
> 
> Yep. And what happens when my misconfigured proxy forwards 
> the call without 
> paying attention to the Privacy header, because for some reason it's 
> forwarding to the outside world instead of a PSTN gateway 
> under my control? 
> We get a privacy leak. 
> 
> But other than that, I'd say you've precisely described a 
> "sunny day" use 
> case for RPID. 
> 
> It still has a lot of security issues based on transitive 
> trust, which make 
> it a lot more palatable in a two-party case than in three or 
> more party 
> transitivity. 
> 
> I believe we're approaching a general consensus that the Privacy draft 
> provides a reasonable approach to solving a specific class of problem 
> wherein interoperator-transitive trust is couple to 
> transport-layer message 
> protection. That's not a general privacy mechanism, but it 
> does seem to have 
> enough constituency to justify publication as long as it has a REALLY 
> serious applicability statement explaining the particular 
> requirements and 
> environments for which it is useful. 
> 
> How does that sound? 
> 
> -- 
> 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: Flemming Andreasen <[email-masked]>
Date: Tue, 26 Feb 2002 20:25:12 -0500

I personally have little preference one way or the other here, but at this point
I need consensus. The current privacy-03 draft specifically does not talk about
untrusted UAs inserting Remote-Party-Id headers, however it defines what a proxy
does when it receives a message with a Remote-Party-Id from either a trusted or
untrusted entity (which of course can be either a proxy or a UA).  I propose to
just leave it at that, which hopefully will give everybody enough of what they
want. If you have a major problem with this, speak up now or forever hold your
peace

Thanks

        Flemming

--
Flemming Andreasen
Cisco Systems