[VIPR] VIPR Privacy

Marc Petit-Huguenin <petithug@acm.org> Thu, 19 January 2012 15:37 UTC

Message-ID: <4F1838B9.4050400@acm.org>
Date: Thu, 19 Jan 2012 07:37:29 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0
MIME-Version: 1.0
To: "vipr@ietf.org" <vipr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: [VIPR] VIPR Privacy
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Restarting the discussion on the subject of VIPR privacy, based on Michael
Procter document draft-procter-vipr-privacy-concerns.

1.1. Caller-ID leaks

The VIPR drafts have been modified to hash the Caller-ID when method A is
used.  A new method "C" will also be published in the coming weeks, methods
that invert the Caller-ID and the start/stop time.

1.2. Source IP identification

One of the solution to hide the source of a PVP request is to use an
intermediate TURN server, TURN server which is already available is the RELOAD
overlay has to support -ICE transports.  Depending on the decision about ICE,
we may have to design another mechanism to hide the PVP client IP address.

1.3. Traffic statistics leakage

One of the proposed solution is to make random PVP calls to increase the
noise.  Unfortunately the this would increase the load on the PVP servers
without really preventing a motivated party to collect statistical information.

2.1 Obtaining the PVP credentials in an office environment

This attack uses the facts that PVP credentials are shared inside an
organization (enterprise) and that people assume that nothing bad can happen
inside this organization.  This is the same fallacy that make people think
that they are protected by their firewall.

One proposed solution is to not share the credentials between users inside an
organization by assigning a different VServiceID to each user.  This also
makes the case for ICE support, as assigning a VServiceID to each user is
equivalent to running a VIPR server in each device.

2.2 Registering multiple PVP servers to validate based on time tolerance

The idea is to register enough PVP servers to increase the probability of
guessing the right start/stop time for a call.  If the maximum duration of the
calls is D and the rounding is R then registering (D/R * (D/R - 1) / 2) PVP
servers permits to validate 100% of the calls made inside this duration.

Not sharing PVP credentials inside an organization also makes this attack less
interesting.

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPGDi1AAoJECnERZXWan7EkfoP/ipfb32y+PbRjkYW8kRnB9bV
yGdU5GvLH0pqWzPXZ22RR4ckkuajTjToPNUV7QulwxU0e7015cMYEgkbM1tMyZBO
0/574QbT7PEUF+S83HhTqG55Htvb3NAjxp8B4x4zjVlpvN0Ful54ciIq8laGkjHC
UweIiQn9I3LKtzks9/rxhWnzqajbA3gzHaLyWYUu7UVr8B3u7pEqZ9NiUTGhFpmC
AqR0pmCkbmWUypDbm5SU2UqlADFC+maTu63587/TOx8o5AGxvM24WKccdtS7tbPM
wiQEMi/bX6nLtz4eqFxMHFzaAOoQo/dYEan/5vsslz6VaYSnla20Mm1JwRTcBnI1
NpJR07RjT1NXV4FlHj43Q0ZIxrJiBl6UkvUpTpvzA/eteI1RomBh3kix3QD6OYYW
HZ5VBYv0i42ii5qxVQ0sFDk+BTajaybFxBlC3zLOzCoGXovDnDbp0Q8li9FiIGn3
2mTZxx9IEjBjwYRxycFmoDN3UNDcAq8hfMfh1vqTkHBxxf7DmGQ5ZgcBfzS4qIgE
6MFGplu/FYTICV7pCtSObPiV2vNrmjbSbly2gDc6Ubomcz0kiLFMQObkOW0Lhj5c
Az+V9j925afZLLfB9ceLesLjzUBT+gSiimvGxcMyhu5FIsZq1XdfxmQyiIH3/ytB
FEwK1PmW13bK6WfFjHhf
=cRJu
-----END PGP SIGNATURE-----

[VIPR] VIPR Privacy Marc Petit-Huguenin