Subject: [VIPR] Agenda & Handout for 2012/01/20

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 19 Jan 2012 08:05:48 -0800

A. Agenda

- - ICE support in VIPR
- - Traffic statistics leakage
- - Obtaining the PVP credentials in an office environment
- - Registering multiple PVP servers to validate based on time tolerance

Note that the sum of the time allocated to each topic may exceeds the time
allocated to the whole call.  The topics that cannot make it to the discussion
will be postponed to the next conference call if they are not subsequently
decided in the mailing-list.

Because the conference bridge as a limited capacity, an individual invitation to
the conference will be sent shortly after this email to each member of the
design team.  Please send me an email if you are not on this list and want to
receive an invitation.

Note that the design team conference call is not a way to short-circuit the
normal process, but a way to accelerate it by increasing face to face time.  All
decisions made must be confirmed on the mailing-list.

This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated
by RFC 4879).

B. Handout (reading time: 5 min)

B.1. ICE support in VIPR

Section 1.2.1 of draft-procter-vipr-privacy-concerns proposes to use TURN to
anonymise the source of a PVP validation.  This proposal is probably incomplete,
but the main problem is that we still do not know what transports will be used
on the RELOAD overlay used by VIPR.  First here's a list of what we currently
know about this overlay:

- - The algorithm is RELOAD-CHORD
- - The Node-ID size is 16 bytes (128 bits).
- - Clients are not authorized because of the quota algorithm.
- - Self-signed certificates are not authorized.
- - There will be one or more root-certs.
- - There will be one or more bootstrap peers (unicast or anycast - no multicast).
- - Clients are not authorized because of the quota algorithm.
- - Shared secret are not used.
- - The overlay link protocol is TLS.
- - There will be a list of kind and configuration signers.
- - The urn:ietf:params:xml:ns:p2p:config-chord, urn:ietf:params:xml:ns:p2p:quota
and urn:ietf:params:xml:ns:p2p:vipr extensions are mandatory.
- - The Kind VIPR-REGISTRATION will be authorized.

What we do not know yet:

- - Do we need to authorize the CERTIFICATE-BY-NODE and CERTIFICATE-BY-USER Kinds?
- - Will TURN server deployed in the overlay?
- - Will ICE overlay link protocols be used?

The important question for this topic is the support of ICE in the RELOAD overlay:

Pros:  With ICE support the RELOAD nodes, the PVP client and the PVP server can
be installed behind a NAT/Firewall without having to put them on the DMZ or to
open pinholes (the bootstrap servers will still need to be installed in the DMZ
or on the Internet).  TURN servers are required for ICE support, so they would
also be available for anonymising the connections.

Cons:  ICE is complex to implement and debug.

If we decide to exclude ICE, then the TURN servers are no longer available by
default, and the idea of using them for anonymising the connections is moot.

An additional consideration is that the RELOAD transports are currently limited
to UDP and TCP, neither of them being really well suited to carry RELOAD or PVP
messages.  If we decide to exclude ICE support, I will then propose to use
(D)TLS over SCTP instead (and write the I-D for this).

So the initial question is:  Do we need ICE or not?

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

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

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