Subject: Re: [VIPR] VIPR privacy issue

From: Dean Willis <[email-masked]>
Date: Fri, 3 Feb 2012 11:07:40 -0600

On Jan 27, 2012, at 9:08 AM, Richard L. Barnes wrote:

> <hat type="geopriv"/>
> 
> Could we please distinguish between "location privacy" and "IP address privacy"?  They are related, but distinct concepts.
> 

Yep. Mobile IP can give us location privacy without IP address privacy.

Hmm ...  a separate RELOAD usage for MobileIP, then bootstrap VIPR on top of that. Might work.

What ever happened to HIP, anyhow? We're just dancing around the locator-separator problem here.

--
Dean

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 03 Feb 2012 09:16:50 -0800

On 02/03/2012 09:07 AM, Dean Willis wrote:
>> Could we please distinguish between "location privacy" and "IP address
>> privacy"?  They are related, but distinct concepts.
>> 
> 

There is already a draft explaining how to use RELOAD on top of HIP
(draft-ietf-hip-reload-instance).  I do not know which of the privacy leaks
HIP would fix, but that is worth studying.  I would have no problem making HIP
mandatory (and as we are at it, IPv6) for VIPR.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 5 Feb 2012 21:57:38 -0700

Just as an idle question that I have not thought about much ... how does this attack change if you assume the VIPR server and SIP edge element for a domain are running on an Amazon EC2 node?

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 06 Feb 2012 06:51:04 -0800

On 02/05/2012 08:57 PM, Cullen Jennings wrote:
> 
> Just as an idle question that I have not thought about much ... how does
> this attack change if you assume the VIPR server and SIP edge element for a
> domain are running on an Amazon EC2 node?

It does not matter for the SIP edge element, as SIP is used only after a
successful PVP transaction, which is not the case we are concerned with here.

For the VIPR server (i.e. RELOAD and PVP), running it on an EC2 node
effectively anonymizes the source IP address, as if a TURN server was used.

Note that even in this case, the certificate of the signer of the AppAttachReq
RELOAD message is leaked, which may contain sensible information in the
Subject or subjectAltName.

But my main concern is that protecting privacy using this method requires a
action from the VIPR domain to make sure that the IP address used cannot be
resolved back to them.  A small number of domains will care, but the vast
majority will not.  I think that privacy has a better chance if the mechanism
does not depends on the actions of individual domains, like always using a
TURN server or adding onion routing in RELOAD.

This still does not fix the certificate leak but one way to fix it could be to
use a Traceable Anonymous Certificate (RFC 5636), which would provide the
right amount of privacy while still permitting to blacklist a domain that
abused its anonymity.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 06 Feb 2012 09:35:57 -0800

On 02/06/2012 06:51 AM, Marc Petit-Huguenin wrote:
>> this attack change if you assume the VIPR server and SIP edge element for
>> a domain are running on an Amazon EC2 node?
> 
> Note that even in this case, the certificate of the signer of the
> AppAttachReq RELOAD message is leaked, which may contain sensible
> information in the

s/sensible/confidential/ (false friends)

> But my main concern is that protecting privacy using this method requires
> a action from the VIPR domain to make sure that the IP address used cannot
> be resolved back to them.  A small number of domains will care, but the
> vast majority will not.  I think that privacy has a better chance if the
> mechanism does not depends on the actions of individual domains, like
> always using a TURN server or adding onion routing in RELOAD.
> 
> This still does not fix the certificate leak but one way to fix it could be
> to use a Traceable Anonymous Certificate (RFC 5636), which would provide
> the right amount of privacy while still permitting to blacklist a domain
> that abused its anonymity.
> 

- -- 
Marc Petit-Huguenin