[VIPR] Using only method "b" for privacy

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

During the conference call last Friday, we had a discussion on which the
conclusion was that privacy conscious VIPR domains could simply require the use
of method "b" for validation, as this method does not send the Caller-ID in the
PVP login, and so does not disclose the phone number of the callers to VIPR
domains that registers the phone number of one of their competitors.

Unfortunately, I do not think that doing this would work.  Here's a diagram
explaining that:

DomainA      RELOAD   DomainB     DomainC
   |            |   Store|           |
1  |            |<-------|     Store |
2  |            |<-------------------|
   :            :        :           :
   | SETUP      |        |           |
3  |~~~~~~~~~~~~~~~~~~~~~|           |
   |            |        |           |
4  |<~~~~~~~~~~~~~~~~~~~~|           |
   :            :        :           :
   | Fetch      |        |           |
5  |----------->|        |           |
   | PVP        |        |           |
6  |::::::::::::::::::::::::::::::::X|
   | PVP        |        |           |
7  |::::::::::::::::::::>|           |
   |            |        |           |

In 1, the legitimate "owner" of the phone number registers a mapping between
this number and its PVP server in the distributed RELOAD database.  In 2, a
competitor registers its own PVP server for the same phone number.  In 3 and 4
we have the PSTN call itself, that generates the originating VCR in domain A and
the terminating VCR in domain B.  Shortly after this, 5 shows that DomainA
retrieved the mappings for the called phone number, and so retrieved the address
of the PVP servers from DomainB and DomainC, without knowing which one is the
"owner".  It starts a PVP transaction with both of them, with the transaction to
DomainC failing because DomainC does not know the PVP secret, and the one with
DomainB succeeding.

Now even if DomainB is privacy conscious and refuses to process PVP transactions
using methods "a", that does not prevent DomainC to accept transactions using
methods "a", and so permitting it to learn the caller number.

Even using the registration mechanism, where the Store also contains the list of
methods supported by a specific endpoint, does not fix this problem.

The problem here is that DomainA needs to be privacy conscious on behalf of the
remote domains, and never use method "a".

One simple solution is to never even define method "a", so it can never be used.
 That is a change from what was discussed during the conference call, which was
to keep method "a" and "b" as they are, and to define better methods.

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

iEYEARECAAYFAk6cTpEACgkQ9RoMZyVa61cdlgCdEOdZT6gQbJcCWxXZr0CJOtxb
KxEAnRAQGvMEVThQE+DrVP8JnPYVoy2X
=h5qq
-----END PGP SIGNATURE-----