Subject: [Sipping] Privacy issues with GRUU

From: "Jesus Javier Arauz \(E2/EEM\)" <[email-masked]>
Date: Thu, 4 May 2006 14:21:24 +0200

Hi,

There is an ongoing discussion in 3GPP about issues when both Privacy
and GRUU are used in IMS. Better than describing it myself, I'm
including some excerpts from a 3GPP document below (the whole document
can be found at
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_52_Shanghai/Docs/S2-061340
.zip for those interested):

"The use of GRUUs in IMS has the potential to introduce new privacy
issues. The specifics depend on how GRUUs are represented and
translated. The requirement in TS 23.808 is "It shall be possible to
apply same level of privacy irrespective whether GRUU is used or not."
Whether a particular use of GRUU passes or fails this test is affected
not only by the GRUU implementation, but also by the level of privacy
afforded by IMS without GRUU."

"The most simple and straightforward representation of a GRUU, described
in draft-ietf-sip-gruu-07, is simply to add 'gruu' and 'opaque' URI
parameters to the Public User Identity, with the value of the 'opaque'
parameter being the instance ID. This has some very convenient
properties, including ease of recovering the Public User Identity from
the GRUU. But that convenience comes at the price. If a request contains
a GRUU of this sort, and 'Privacy:id', then while the recipient will not
get the P-Asserted-Identity header, it will still be able to recover the
public identiy from the GRUU. This is similar to correlation attack with
a regular contact address, but is somewhat worse because the Public
Identity is directly recoverable. A UE that follows standard procedures
will not display the callerid, but a UE that has been suitably "hacked"
can do so. To preserve better privacy when using this kind of GRUU it
would be necessary to use 'Privacy:id,header'"

"We must choose between a few directions:
	a.	A single (public) GRUU format, based on the
recommendation in draft-ietf-sip-gruu-07. 
	b.	Two GRUU formats - one public GRUU format for use in
requests when identity is not hidden, and another private GRUU format
for use when identity is hidden.
	c.	A single (private) GRUU format, supporting multiple
simultaneously active anonymous GRUUs.
		Choice (a) is easier to realize but has some performance
penalties for anonymous calls.
Choice (b) mitigates the performance penalties, but is more complex and
most likely requires a new RFC. It probably cannot be realized in the R7
timeframe because of the new for new standardization work.
Choice (c) doesn't meet the requirement of 23.808 for a single
permanently valid GRUU. It remains to be seen whether than requirement
is negotiable. If it is, then there are still issues managing the
lifetimes of the GRUUs. (Choices (b) and (c) share these issues.)"

The privacy problems pointed by the above-excerpted document can be
solved according to alternative "b" using the TRUU mechanism, described
in draft "draft-jbemmel-sip-truu-01". Unfortunately that draft is
expired now. The draft's author, Jeroem Van Bemmel, and myself are
discussing what would be the best way to proceed with this issue. One
alterntive is to bring back to life the draft and make it become a
standards track. Another alternative would be to enhance the GRUU draft
to include the TRUU mechanism.

If you read the whole 3GPP document and the TRUU draft you'll see that
they match closely. I've developed a method to apply TRUU to IMS so the
privacy problems with GRUU can be solved as required by 3GPP. We would
like to know the sipping community's oppinion on the above matters.

Kind regards,
/Javier Arauz

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 04 May 2006 09:22:57 -0400

Javier,

I had forgotten about that draft. There is also another expired draft 
that also pertains to the subject: 
draft-rosenberg-sip-identity-privacy-00. (I guess perhaps those drafts 
were ahead of their time.) I think it would be worthwhile to discuss 
them again.

I took a quick look at the truu draft again, and I see some technical 
issues with it. They may turn out to be superficial - will need to look 
more closely. Perhaps Jeroen would be willing to refresh that draft?

In the context of 3gpp there remain issues around the precise set of 
requirements that must be met, and those will affect the kind of 
solution that is acceptable. Of course it is the business of 3gpp to 
decide its own requirements, so we should not presume to address that 
here. OTOH, if we are to do standards track work here on the subject 
then we too will need to agree on the requirements that must be met.

There is a tradoff here between the amount of privacy that is achieved 
and what it is still possible to do. GRUU was invented at least in part 
to permit out-of-dialog requests to be sent to a UA discovered via the 
Contact in a dialog. There are a number of features that require that 
kind of behavior in order to work properly. But it is hard to provide 
that and not also potentially permit something unintended - that 
"violates your privacy".

So, I think we need to establish the set of requirements that an 
"anonymous GRUU capability" must satisfy before we can come to a final 
conclusion about a mechanism. The 3gpp needs to do the same, and 
hopefully we will end up with the same set of requirements. While the 
two drafts above don't *explicitly* identify the requirements they are 
trying to meet, they do provide some hints that can be mined.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 4 May 2006 20:03:14 +0200

Paul,

see inline

Regards,

Jeroen

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Jesus Javier Arauz (E2/EEM)" <[email-masked]>
Cc: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 04, 2006 3:22 PM
Subject: Re: [Sipping] Privacy issues with GRUU

> Javier,
>
> I had forgotten about that draft. There is also another expired draft that 
> also pertains to the subject: draft-rosenberg-sip-identity-privacy-00. (I 
> guess perhaps those drafts were ahead of their time.) I think it would be 
> worthwhile to discuss them again.
>

Sure, I expect to submit this by the end of next week

> requirements that must be met, and those will affect the kind of solution 
> that is acceptable. Of course it is the business of 3gpp to decide its own 
> requirements, so we should not presume to address that here. OTOH, if we 
> are to do standards track work here on the subject then we too will need 
> to agree on the requirements that must be met.
>
> There is a tradoff here between the amount of privacy that is achieved and 
> what it is still possible to do. GRUU was invented at least in part to 
> permit out-of-dialog requests to be sent to a UA discovered via the 
> Contact in a dialog. There are a number of features that require that kind 
> of behavior in order to work properly. But it is hard to provide that and 
> not also potentially permit something unintended - that "violates your 
> privacy".
>
> conclusion about a mechanism. The 3gpp needs to do the same, and hopefully 
> we will end up with the same set of requirements. While the two drafts 
> above don't *explicitly* identify the requirements they are trying to 
> meet, they do provide some hints that can be mined.
>

Well, unless you consider a section entitled "10. Requirements" to be 
explicit...
I agree that the list is incomplete and up for discussion though.

A question I have: do people feel we are still in time to perhaps 
incorporate some of this into the GRUU draft?

>> recommendation in draft-ietf-sip-gruu-07. b. Two GRUU formats - one 
>> public GRUU format for use in

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 May 2006 19:01:26 -0400

inline.

Jeroen van Bemmel wrote:
> Paul,
> 
> see inline
> 
> Regards,
> 
> Jeroen
> 
> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
>> issues with it. They may turn out to be superficial - will need to 
>> look more closely. Perhaps Jeroen would be willing to refresh that draft?
>>
> 
>> and what it is still possible to do. GRUU was invented at least in 
>> part to permit out-of-dialog requests to be sent to a UA discovered 
>> via the Contact in a dialog. There are a number of features that 
>> require that kind of behavior in order to work properly. But it is 
>> hard to provide that and not also potentially permit something 
>> unintended - that "violates your privacy".
>>

Oops! I just skimmed to refresh my memory, and didn't look that far.

Its a good start. I think there is a distinction between "what are we 
trying to accomplish" and "what are the constraints on the solution". It 
appears to me that your section 10 covers the latter more than the 
former. From the work on this in other forums I think there may be some 
disagreements over what we are trying to accomplish.

In particular, the focus I have had is on privacy. But the privacy is 
limited, because you still want to allow certain things even though to 
some those may appear to be violations of privacy.

> incorporate some of this into the GRUU draft?

IMO, NO. This should be considered as additional work, and I don't 
completing gruu now will prevent this work from being done. I would not 
be surprised if this takes quite awhile to get finalized, and there are 
lots of things that need gruu and don't want to wait.

	Thanks,
	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 May 2006 12:14:32 -0400

A few comments inline.

Jesus Javier Arauz (E2/EEM) wrote:

> public identiy from the GRUU.

Right. That is why the GRUU spec talks about the fact that URI have 
different properties, including the anonymity property. A URI can have 
both the GRUU and anonymity properties, but then it cannot be formatted 
this way.

  This is similar to correlation attack with
> recommendation in draft-ietf-sip-gruu-07. 

It was never the intent of the gruu spec that there be only one format. 
GRUU is a property. The approach of using opaque with the AOR is one 
approach and it has certain properties.

> for use when identity is hidden.

Right - this was what was intended.

> simultaneously active anonymous GRUUs.

Though something like this might make sense as a short term solution, I 
think a proper solution wouldn't require this.

> timeframe because of the new for new standardization work.

Well, that all depends on what the timing is, doesn't it?

> permanently valid GRUU.

I don't see why having one and only one permanently valid gruu is, in 
and of itself, a requirement. Like I said, the GRUU spec itself 
envisions many GRUU with different properties. Indeed, the whole idea of 
the GRID is to generate an infinite number of gruu.

> It remains to be seen whether than requirement

As Paul pointed out, my sip-identity-privacy draft took a stab at this. 
I do have to agree, however, that this is best handled by a separate 
extension given where we are with gruu.

I skimmed the TRUU draft, and I think its a decent approach. I disagree 
with some of the specifics, and in particular, would rather see it as an 
extension to gruu rather than a spec on its own. But, at a high level, 
there are really only a few options:

1. UA gets an anonymous URI from the server
    a. with REGISTER
    b. with something else
2. UA manufacturers URI

Jeroen's draft is doing 1a. I have some ideas on (2) that still route to 
a proxy as GRUU does, which might fix some of the problems of a REGISTER 
approach (namely, requiring re-register on every call).

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 15 May 2006 08:30:28 +0200

>> Sure, I expect to submit this by the end of next week

FYI - I posted an update of this draft, see 
http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg10148.html

Regards,

Jeroen