Subject: RE: [Sip] GRUU and Anonymity

From: "Andrew Allen" <[email-masked]>
Date: Mon, 11 Sep 2006 20:46:04 -0400

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

---

From: Jeroen Van Bemmel <[email-masked]>
Date: Tue, 12 Sep 2006 18:41:11 +0200

Paul (and others),

The reason that the TRUU draft proposes explicit invalidation 
(which implies state at the registrar/proxy), is that I assumed a requirement that the UA would not even receive requests sent to an expired TRUU. The idea behind that is that it would prevent SPAM from consuming (wireless) resources; the UA could "step away" from an attack.

If this feature is not desired, then I agree a stateless approach is better (at least not state linear in the number of clients). The UA could mint its own TRUUs, along the lines that Dale sketched 

Regards,
Jeroen

--Oorspronkelijk bericht -----
Van: "Paul Kyzivat" <[email-masked]>
Aan: "Jeroen Van Bemmel" <[email-masked]>
CC: "Andrew Allen" <[email-masked]>; "Jonathan Rosenberg" <[email-masked]>; "IETF SIP List" <[email-masked]>
Verzonden: 12-9-06 14:59
Onderwerp: Re: [Sip] GRUU and Anonymity

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

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 12 Sep 2006 17:12:27 -0400

Dale,

I didn't understand the Public-Private Key pair aspect and the statement
of one private key per domain?

Isn't that one private key per user?

Mike 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, September 12, 2006 3:25 PM
> To: [email-masked]
> Subject: Re: [Sip] GRUU and Anonymity
> 
>    From: Paul Kyzivat <[email-masked]>
> 
>    I'm not sure I follow all the details, but I get the gist. 
> I gather the 
>    proxy isn't expected to have any idea which sequence 
> numbers are/aren't 
>    valid. If so, then it seems that the sequence number is 
> analogous to the 
>    grid parameter. It may be possible align the two 
> approaches closely.
> 
>    For instance, perhaps the normal gruu is of form:
> 	   sip:user@domain;gruu;opaque=xyz;grid=abc
> 
>    Then an anonymous form of it could be
> 	   sip:PublicKey(user,opaque,grid)@domain;gruu
> 
>    and as you suggest, the proxy could turn this back into the 
>    non-anonymous form and then process it normally. 
> Ultimately the UA would 
>    receive the grid.
> 
> The reason that the pseudo-grid's are numbers is so that the 
> UA can store a threshold, before which all pseudo-grid's are 
> known to be invalid.  If they didn't form an ordered 
> sequence, the UA would have to record in non-volatile memory 
> all invalid ones.  Or all valid ones.
> 
> Uh, yes, the number of valid ones at any given moment is 
> expected to be small.  So you don't really need them to be 
> numbers, as long as there is some way to avoid using the same 
> one twice (very often).
> 
>    But a piece I am missing in the above and below is how the proxy 
>    determines what private key to apply to the incoming truu. 
> It could 
>    potentially get the one currently assigned to a registered 
> contact, but 
>    to do so it would need to know what user, and then which contact.
> 
>    I guess the anonymous form of the gruu could be:
> 	   sip:PublicKey(user,opaque,grid)@domain;gruu;key=foo
> 
> There's only one private key for the domain.
> 
>    Another messy aspect of this is that it couples the UA and 
> the proxy 
>    regarding the details of the format of the URI, and that 
> might cause 
>    some difficulties.
> 
> Yeah, it's a pretty tight coupling between the processing in 
> the proxy and in the UA.  In particular, they have to 
> implement opposite halves of the encryption operation.
> 
>    For instance, one problem I have encountered with IMS (and 
> which may 
>    apply to other large domains) is that the user space is 
> partitioned, 
>    with a different home proxy handling each partition. In 
> the kind of 
>    scheme you have proposed, it becomes necessary to guarantee that 
>    anonymous gruus are routed to the proper home proxy.
> 
> Not really.  Since there is only one private key, any proxy 
> can open any TRUU for the domain.  Once it does that, it has 
> the GRUU for the UA, but we already assume that any proxy can 
> route any GRUU for the domain.
> 
> This scheme seems to have a problem in that it's not too hard 
> to forge TRUUs that might get partially routed before they 
> are rejected.
> 
> Dale
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 19 Sep 2006 19:28:39 +0200

What I also believe we need is text that covers how the UA
implementation recovers from the situation where the GRUU has been
accidently revealed. It seems to me that where the user has to
explicitly turn it off before he calls the kitchen salesman is
definitely prone to error. If the GRUU lasts for ever, then the kitchen
salesman has the opportunity of calling that UA for ever.

On the call we discussed that the user should request a new GRUU, and
that we would then bar the old GRUU within the UA itself, but this
sounds a bit like a fudge rather than a real fix.

Regards

Keith 

> Sent: 15 September 2006 16:06
> To: Paul Kyzivat
> Cc: IETF SIP List; Francois Audet
> Back to the original question, I feel strongly that it is not 
> in the scope of gruu to solve THIS level of anonymity. I 
> agree its worth doing but not in the gruu spec.
> 
> I think its fair to ask whether or not the gruu spec should 
> be specified in a way that it provides privacy services that 
> are no worse than what what is defined in RFC 3261. And more 
> specifically, if a user does not explicitly invoke a privacy 
> service (through the privacy header or other mechanisms), 
> does GRUU make things worse, and can we specify it in a way 
> that doesnt make it worse?
> 
> Clearly one could use gruu as defined today, and if you 
> wanted header anonymity, you can use the 'header' privacy 
> service and that would work and provide you a level of 
> anonymity on par with today without gruu.
> 
> It is certainly the case that, in RFC 3261, the SIP invite, 
> without treatment by some external b2bua service, will reveal 
> the domain of the originator, through the IP addresses in the 
> SDP alone. Even with treatment by ANY of the privacy services 
> provided in RFC3323, the domain of the originator is 
> revealed. Consequently I don't think we need to hold up gruu 
> on this feature.
> 
> With RFC 3261 today, if the user didn't use an anonymization 
> service, they could include a From header field of 
> [email-masked]. 
> They could rotate the value of 'username' from call to call, 
> though the IP addresses in various places would probably 
> correlate across calls, since most users have fairly static IPs.
> 
> Thus, I would asser that SIP today, without usage of an 
> anonymity service, provides nothing more than pseudonymity 
> (with the IP address as your pseudonym). This would tell me 
> that it would be acceptable to produce a gruu spec which 
> provides nothing more than pseudonymity. Since IP addresses 
> can change over longer periods of time (reboot cycles), I'd 
> also propose that gruu support slowly changing pseudonyms - 
> namely, different on each registration. This is fairly easy 
> to add to gruu.
> 
> With this proposal, I would assert that GRUU provides privacy 
> services equivalent to the level of anonymity afforded by RFC 
> 3261, and that better anonymity can be provided by the 
> mechanisms in rfc3323, which get no better or worse with the 
> addition of gruu. I think this is the metric we need to meet, 
> and NO BETTER.
> 
> Does this get us out of this conundrum?
> 
> -Jonathan R.
> 
> 
> Paul Kyzivat wrote:
> 
> > Francois,
> > 
> > You are stating a need for a level of anonymity that 
> Jonathan says is 
> > almost impossible to achieve. Something has to give here.
> > 
> > I think the world already deals with differing levels of anonymity. 
> > Callerid blocking in the pstn only blocks your identity from the 
> > receiving party, while the whole intervening network has access to 
> > your identity. And its often negated when making emergency 
> calls. So 
> > if I have a *serious* need to remain anonymous, invoking callerid 
> > blocking already isn't enough. Instead I am forced to seek out an 
> > anonymous phone from which to originate the call, or use some very 
> > complex mechanisms that are not widely available. And when 
> seeking out 
> > an anonymous phone from which to make my call, I will again 
> typically 
> > be limited in the scope of anonymity. For instance if I 
> cannot travel 
> > to an arbitrary location to make my call then the location 
> I make the 
> > call from can be used to guess where I am.
> > 
> > One part of jonathan's old proposal escapes me: why is it 
> important to 
> > support sip identity when making an anonymous call? Does it really 
> > matter to the recipient that the caller is really the particular 
> > anonymous caller it claims to be rather than some other 
> unknown caller?
> > 
> > I am inclined to think that an independent anonymizer service (b2bua
> > based) running in its own domain, would be sufficient for all *my* 
> > worst case anonymity needs, and that anonymity within the 
> domain of my 
> > own provider would be sufficient for those cases when I 
> just want to 
> > "block callerid". YMMV.
> > 
> > It is clear that the more complete forms of anonymity are 
> relatively 
> > expensive to provide, to the point that it probably 
> wouldn't be good 
> > to make that the default. If it became an extra cost 
> service then it 
> > would be self funding. Then people will settle for less 
> when the need 
> > doesn't justify the cost.
> > 
> >     Paul
> > 
> > Francois Audet wrote:
> > 
> >>  
> >>
> >>>> I guess what I'm trying to say is that if we need
> >>>
> >>> annonymity, it needs
> >>>
> >>>> to be full annonymity. I don't see a value in "pseudonymity".
> >>>
> >>> Why? Certainly there are privacy applications (such as 
> calling the 
> >>> police to anonymously report an incident) where pseudonymity is 
> >>> probably sufficient.
> >>
> >>
> >> I don't believe that a system that "works sometimes" is useful.
> >>
> >> To take the "police" example, if my domain is enough for 
> the police 
> >> to track me down (or to a subset small enought that I'm not 
> >> annonymous), then, well, it's not annonymous anymore. 
> Maybe I have my 
> >> own domain, or you can track that there was only one user 
> with that 
> >> particular domain who might have made that call. Maybe I'm 
> reporting 
> >> something to police, and it shows my employer's domain. 
> Suddently, my 
> >> employer is embroiled.
> >>
> >> The end-user will not have confidence that's it's really 
> annonymous 
> >> because it's not always annonymous.
> >>
> >> Maybe I'm missing something that is special to GRUU. I'm reading 
> >> Dean's summary, but I'm not terribly convinced that the claims are 
> >> true.
> >>
> >> I'm highly sceptical that somehow that we (IETF) need to provide a 
> >> solution to the GRUU anonimity problem.
> >>
> >> But I could be missising something.
> >>
> >>
> >>>> So, I agree with you. When we DO solve annonymity, it 
> needs to work 
> >>>> with GRUU and everthing else. In the meanwhile, I don't
> >>>
> >>> think GRUU is
> >>>
> >>>> special and requires immediately a solution to annonymity.
> >>>>
> >>> You may have to wait a while. A LONG while.
> >>>
> >>> In:
> >>> http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-pri
> >>
> >> vacy-00.txt
> >>
> >>> I took a stab at some thoughts on true anonymity. Its nearly 
> >>> impossible to do. Even anonymizers aren't sufficient. It 
> is possible 
> >>> that the only solutions require crazy BGP hacks like I 
> describe else 
> >>> a global, massive p2p mesh.
> >>
> >>
> >> Yeah, I have read this, and I do agree that it's MUCH bigger than 
> >> just GRUU.
> >>
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
> > 
> 
> --