Subject: RE: [Sip] GRUU and Anonymity

From: Jeroen Van Bemmel <[email-masked]>
Date: Tue, 12 Sep 2006 08:29:46 +0200

Andrew,

Minor remark: de-allocation of a temporary GRUU would happen after call tear down, and not as part of call setup. Moreover, it could be optional.

Regards,

Jeroen

-----Oorspronkelijk bericht -----
Van: "Andrew Allen" <[email-masked]>
Aan: "Jonathan Rosenberg" <[email-masked]>; "IETF SIP List" <[email-masked]>
Verzonden: 12-9-06 02:46
Onderwerp: RE: [Sip] GRUU and Anonymity

Jonathan,

I don't think it is accurate to state that 3gpp has specified that the
terminal (UE) must indicate privacy and hence it is very difficult to
apply GRUU into 3gpp. This is what TS 24.229 actually states for UE
behavior with regard to Anonymity: 

------------------------------------------------------------------------
----
Where privacy is required, in any initial request for a dialog or
request for a standalone transaction, the UE shall set the From header
to "Anonymous".

NOTE 5: The contents of the From header should not be relied upon to be
modified by the network based on any privacy specified by the user
either within the UE indication of privacy or by network subscription or
network policy. Therefore the user should include the value "Anonymous"
whenever privacy is explicitly required. As the user may well have
privacy requirements, terminal manufacturers should not automatically
derive and include values in this header from the public user identity
or other values stored in or derived from the UICC. Where the user has
not expressed a preference in the configuration of the terminal
implementation, the implementation should assume that privacy is
required. Users that require to identify themselves, and are making
calls to SIP destinations beyond the IM CN subsystem, where the
destination does not implement RFC 3325 [34], will need to include a
value in the From header other than Anonymous.

------------------------------------------------------------------------
----

My view is that the most important aspect to provide is Pseudonymity.
This seems to provide an equivalent level of anonymity to including an
IP address in the contact header as assumed in RFC 3261. Temporal
Privacy along the lines you have described seems to be a nice to have
which I think we should try and incorporate in the draft if the solution
is easy to specify without delaying the completion. I think Serial
Pseudonymity is a rat hole which really requires a full requirement
discussion (particularly on the lifetime requirements) and also has all
sorts of issues including that having a refresh registration every call
would not be acceptable from a 3gpp wireless perspective. 3gpp has just
completed an optimization of the call setup procedures to reduce the
number of messages exchanged to the bare minimum in order to make call
setup time acceptable so the addition of a REGISTER and 200 OK
transaction to the call setup is not going to go down very well. 

If you require true anonymity today with RFC 3261 you need an SBC
anonymizer function to hide the IP Addresses and I think for now we can
live with an SBC anonymizer mechanism performing similar hiding on GRUUs
for those deployments that require it. Future work can attempt a more
general and friendly solution to these more stringent privacy
requirements which go beyond the privacy provided today using RFC 3261.

Andrew

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, September 11, 2006 5:18 PM
To: IETF SIP List
Subject: [Sip] GRUU and Anonymity

Several folks got together to discuss the review comments on the GRUU 
spec. Much of the time was spent discussing the issue of anonymity.

Today, GRUU doesn't provide any anonymity functions at all. Indeed, the 
recommendations for construction of gruus are such that they would 
contain the users AOR. So, if a user wants to make an anonymous call, 
what would they do? The GRUU spec says nothing about this, and 
unfortunately the answer is that they cannot use the GRUU specification 
at all.

The point was raised that there were many places, such as Europe, where 
anonymous calls are the norm. This is because privacy laws require that 
caller ID be given out as an opt-in feature, and the default is privacy.

This results in a very large percentage of calls being anonymous. In 
these kinds of situations, GRUU would never get used, and the problems 
it solves (like making transfer work) won't be applicable.

A similar problem arises in network deployments which utilize network 
signaled privacy (in other words, the phone doesn't know the call is 
anonymous, but the network does). To support these kinds of deployments,

the UA has to act as if every call was anonymous. This is how 3gpp is 
currently spec'd out, and it would make it very difficult to apply GRUU 
into 3gpp.

Thus, the concern was raised that a GRUU specification that didn't 
address anonymity at all was undeployable in many locales and unusable 
by many potential SDO customers. The question, then, is can it be 
addressed in this spec, and at what cost?

Unfortunately, anonymity is a big, thorny and hard problem. Indeed, 
there are many different types of anonymity. Consequently, I think its 
worth looking at a few different properties and seeing what the cost 
would be to add them to the GRUU spec.

Pseudonymity
------------

One feature that can be provided is pseudonymity. The idea is that the 
registrar, when it first creates a GRUU for an AOR/insteance-ID pair, 
actually would create two. One is the 'normal' one (generally 
constructed by adding an opaque parameter to the AOR), and another is a 
pseudonym for the GRUU:

sip:[email-masked];gruu;opaque=9asd8bvghasd8
sip:[email-masked];gruu

Both the pseudonym and the regular GRUU would be returned in the 
REGISTER response. The pseudonym would have the same temporal lifetime 
as the regular GRUU. The pseudonym can easily be constructed by 
encrypting the AOR and instance ID, or it can be computed and stored 
statefully.

The pseudonym would have the property that one could not, by inspection,

determine the AOR. However, the pseudonym persists indefinitely, and 
consequently, two subsequent calls from the same UA instance would be 
known as coming from the same UA instance. Also, a recipient of the 
pseudonym could call the user back, at that instance, at any time in the

future.

Adding this pseudonymity feature to GRUU is relatively low cost, in 
terms of complexity and time delay. I believe it would require the 
addition of one feature from:

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-coexist
ence-00.txt

namely, the user=anonymous URI parameter, so that a recipient knows to 
not try to render sip:[email-masked].

Temporal Privacy
----------------

There is probably a better name for this feature, but for now I'll call 
it temporal privacy.

The idea is that the Contact header field contains a pseudonym. The UA 
at the other end of the call can use that pseudonym for a certain 
duration. After that duration expires, the pseudonym is invalid. Being 
invalid means that any entity which makes a call to that URI, will not 
cause the phone to ring and the call will not succeed.

The most useful temporal scope is for the lifetime of the dialog. This 
is particularly useful for transfer and KPML, where that is exactly the 
desired temporal scope. However, other scopes could be possible. Indeed,

another application of GRUU is in a call center, where you could call 
back the specific help desk person who you just talked to, without 
knowing their identity. This would work best with a temporal validity 
that is something like an hour or so, and possibly even longer.

This is most easily implemented in the UA. Consider temporal privacy 
with a scope equal to the lifetime of a dialog. The UA would obtain a 
psedononymous GRUU as above, and then add a unique grid parameter for 
each distinct dialog. When the UA receives a request that was targeted 
towards that GRUU, it will know the grid that was used. If the 
corresponding dialog is still in progress, the request is accepted. If 
not, the request is rejected with a 403.

Pushing the validity checking into the network is harder, since it would

require proxies to retain dialog statefulness, store the correlation 
between grid and dialog, and know that the desired temporal scope of the

anonymity is indeed for a dialog. No doubt some folks who like B2BUAs 
would be more than happy to do this.

Adding this feature to the UA is relatively low cost (in terms of 
specification work).

Note that, even though the grid would rotate on each call, the rest of 
the pseudononymous GRUU would not. This makes it easily to correlate. 
Thus, if Bob makes a call to Carol one day, and again to Carol the next 
day, Carol will know that this was the same person that called on the 
day previous.

Serial Pseudonymity
-------------------

With serial pseudonymity, the UA would be able to get multiple 
pseudonyms, and use a different one for each dialog. The pseudonyms 
could not be correlated together, except that they come from the same 
domain. Serial pseudonymity is orthogonal to temporal privacy. Each of 
the pseudonyms can have any temporal lifetime that is desired. The most 
obvious lifetime is to bind the validity to that of the dialog the 
pseudonym is used in. This would allow a UA to have a different GRUU
for each call, and for that GRUU only to be usable during the duration 
of the call.

Serial pseudonymity is harder to address. The TRUU draft:
http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-02.txt
takes a stab at this. Any solution to this problem needs to deal with 
the question of how the UA instance gets a new pseudonym (the TRUU spec 
proposes a REGISTER with a new Contact URI) and what its validity is 
(the TRUU spec says that the clients explicitly invalidate them at the 
end of the dialog). Its possible to separate the validity issue out. In 
particular, if the network treats them as valid for the duration of the 
registration, and they are rejected by the UA, there is no need for the 
client to explicitly de-allocate them. Without de-allocation, the 
pseodonym can be considered valid for the duration that the contact URI 
itself is registered to that AOR with that instance ID. Doing that is 
relatively easy to add to GRUU, I believe.

However, obtaining them is something that is requried in any solution. 
Generating a register refresh is easy, however it has the drawback of 
incurring an additional delay and bandwidth utilization at the time of 
call setup. This may be a non-issue for enterprises or broadband access 
providers, but may be a huge issue for wireless (think 3gpp). 
Consequently, if folks believe that wireless providers will require 
serial pseudonymity, I suspect a query-based mechanism (like a REGISTER 
refresh) won't work. Any alternatives to that are much more complicated.

The two I can think of are to try and coordinate a generator function 
between UA and proxy, or more likely, to make use of a network privacy 
server ala RFC 3323 to request serial pseudonymity. Both would probably 
require specification beyond the scope of the current GRUU spec.

True Anonymity
--------------

In true anonymity, each request is truly without identity. Nothing - 
absolutely nothing - in the request tells you anything about who is 
making it. This feature is nearly impossible to provide, GRUU or not. IP

addresses alone will provide a ton of information. So, I think this is 
clearly out of scope. That is why I've focused on grades of 
pseudonymity, since that is what we are talking about here.

So, the question to the group is - do folks believe that some kind of 
anonymity needs to be addressed in the baseline GRUU draft for it to be 
useful? If so, what degree? Is is one of the ones above or something 
else entirely?

I believe it would be not too hard to add pseudonymity, temporal 
privacy, and limited serial pseudonymity (requriing a REGISTER refresh 
to get a new pseudonym) to the specification. Anything beyond that I 
think is far too complex. However, no doubt there are still issues 
lurking here and these will require time to ferret out.

Thoughts?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Sep 2006 08:59:01 -0400

The need to deallocate temporary gruus could be a problem. If you put 
the responsibility on the UAC to do it, what incentive does it have? Its 
easier to just not bother. And the registrar doesn't in general know 
when the old temp gruu is no longer needed. You could try to couple it, 
so that you can't get a new one without giving up your old one, but that 
isn't necessarily workable. (Wanting a new gruu for a new call doesn't 
mean that you are done with the earlier call.)

Its *way* better if the gruus are arranged so that there is no state 
retained that must be deallocated.

	Paul

---

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Tue, 12 Sep 2006 15:33:52 +0200

With TRUU, the network drops the TRUU when the UE does not refresh it
anymore. The incentive for the UE is to not have to remember and refresh
all the obtained TRUUs.

/Javier

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: martes, 12 de septiembre de 2006 14:59
To: Jeroen Van Bemmel
Cc: IETF SIP List
Subject: Re: [Sip] GRUU and Anonymity

	Paul

Jeroen Van Bemmel wrote:
> Andrew,
> 
> Minor remark: de-allocation of a temporary GRUU would happen after
call tear down, and not as part of call setup. Moreover, it could be
optional.

> to "Anonymous".
> 
> NOTE 5: The contents of the From header should not be relied upon to 
> be modified by the network based on any privacy specified by the user 
> either within the UE indication of privacy or by network subscription 
> or network policy. Therefore the user should include the value
"Anonymous"

> which I think we should try and incorporate in the draft if the 
> solution is easy to specify without delaying the completion. I think 
> Serial Pseudonymity is a rat hole which really requires a full 
> requirement discussion (particularly on the lifetime requirements) and

> also has all sorts of issues including that having a refresh 
> registration every call would not be acceptable from a 3gpp wireless 
> perspective. 3gpp has just completed an optimization of the call setup

> procedures to reduce the number of messages exchanged to the bare 
> minimum in order to make call setup time acceptable so the addition of

> a REGISTER and 200 OK transaction to the call setup is not going to go
down very well.
> anonymizer function to hide the IP Addresses and I think for now we 
> can live with an SBC anonymizer mechanism performing similar hiding on

> GRUUs for those deployments that require it. Future work can attempt a

> more general and friendly solution to these more stringent privacy 
> Today, GRUU doesn't provide any anonymity functions at all. Indeed, 
> the recommendations for construction of gruus are such that they would

> unfortunately the answer is that they cannot use the GRUU 
> specification at all.
> 
> The point was raised that there were many places, such as Europe, 
> where anonymous calls are the norm. This is because privacy laws 
> require that caller ID be given out as an opt-in feature, and the
default is privacy.

> currently spec'd out, and it would make it very difficult to apply 
> GRUU into 3gpp.
> 

> constructed by adding an opaque parameter to the AOR), and another is 
> a pseudonym for the GRUU:
> 

> There is probably a better name for this feature, but for now I'll 
> call it temporal privacy.
> 

> is particularly useful for transfer and KPML, where that is exactly 
> the desired temporal scope. However, other scopes could be possible. 
> Indeed,
> 

> Thus, if Bob makes a call to Carol one day, and again to Carol the 
> next day, Carol will know that this was the same person that called on

> the day previous.

> the pseudonyms can have any temporal lifetime that is desired. The 
> most obvious lifetime is to bind the validity to that of the dialog 
> the pseudonym is used in. This would allow a UA to have a different 
> GRUU for each call, and for that GRUU only to be usable during the 
> duration of the call.
> 
> the question of how the UA instance gets a new pseudonym (the TRUU 
> spec proposes a REGISTER with a new Contact URI) and what its validity

> is (the TRUU spec says that the clients explicitly invalidate them at 
> the end of the dialog). Its possible to separate the validity issue 
> out. In particular, if the network treats them as valid for the 
> duration of the registration, and they are rejected by the UA, there 
> is no need for the client to explicitly de-allocate them. Without 
> de-allocation, the pseodonym can be considered valid for the duration 
> that the contact URI itself is registered to that AOR with that 
> instance ID. Doing that is relatively easy to add to GRUU, I believe.
> 

> call setup. This may be a non-issue for enterprises or broadband 
> access providers, but may be a huge issue for wireless (think 3gpp).

> server ala RFC 3323 to request serial pseudonymity. Both would 
> probably require specification beyond the scope of the current GRUU
spec.

> anonymity needs to be addressed in the baseline GRUU draft for it to 
> be useful? If so, what degree? Is is one of the ones above or 
> something else entirely?
>