Subject: [Sip] GRUU and Anonymity

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Sep 2006 17:17:58 -0400

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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 12 Sep 2006 09:25:01 +0300

> useful? If so, what degree? Is is one of the ones above or something 

pseudonymity would be ok with me.

at least in finland, anonymity requirement only applies to SIP/PSTN
calls, not to SIP/SIP calls.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 12 Sep 2006 09:49:47 +0300

after thinking this a bit more, it would actually be a very good idea
not to support gruu at all with anonymous calling.  so i change my vote.
let those people who want to make anonymous calls, fall back to non-gruu
calls.

even if someone has chosen anonymous calling to be the default, the
default can be overridden on per call basis using #31# dial prefix.  i
personally never answer anonymous phone calls, because they usually come
from telemarketing guys or some other "undercover" people.  so it is
just good for those guys to loose some functionality.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Sep 2006 09:01:17 -0400

Juha,

So when somebody wants to make an anonymous call to the police, to 
report some issue, you don't think it important that the call be 
transferable to the correct department?

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 12 Sep 2006 16:13:34 +0300

> transferable to the correct department?

i don't believe in soviet union style system with anonymous informers.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 12 Sep 2006 15:30:34 +0200

In Finland people don't call the police. They grab a knife and take care
of things themselves :) 

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: 12. syyskuuta 2006 16:14
> To: Paul Kyzivat
> Cc: IETF SIP List
> Subject: Re: [Sip] GRUU and Anonymity
> 
> Paul Kyzivat writes:
> 
>  > So when somebody wants to make an anonymous call to the 
> police, to  > report some issue, you don't think it important 
> that the call be  > transferable to the correct department?
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Sep 2006 11:41:58 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, September 11, 2006 2:18 PM
> To: IETF SIP List
> Subject: [Sip] GRUU and Anonymity
> 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:
> 

I'm not sure that an annonymity feature that obfuscate the user name but
not
the domain name is good enough.

It may be good enough when the provider is Big Ma Bell, but not
otherwise.

If the people that are susceptible to call me in a specific domain is
small
enough, I could probably guess who the annonymous entity is.

It reminds me of a "confidential feedback" I submitted for my boss's
performance. 
I discovered later that my feedback (submitted to my boss) didn't have
my name, 
but it had my location (I was the only employee working for him located
the Bay 
Area).

In other words, I don't think pseudonymity is good enough.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Sep 2006 11:41:58 -0500

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Sep 2006 15:07:07 -0400

My question is whether this is just a personal bias against anonymous 
calls (which is fine) or a belief that pseudonymity will not meet the 
regulatory requirements which you need to meet.

-JOnathan R.

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 12 Sep 2006 22:25:59 +0300

> regulatory requirements which you need to meet.

jonathan,

there is personal bias, but what comes to regulatory requirements in
europe, as i said, they currently only apply to calls terminating from
sip to pstn and wise versa.  in those cases anonymity is easy to
accomplish with or without gruu without any additions to rfc3261 or the
current gruu spec.

what comes to anonymity of sip-to-sip calls, in my opinion it is not
sufficient if only user part of uri is anonymous, also the host part
needs to be.

-- juha