Internet DRAFT - draft-procter-vipr-privacy-concerns
draft-procter-vipr-privacy-concerns
VIPR M. Procter
Internet-Draft VoIP.co.uk
Intended status: Informational October 21, 2011
Expires: April 23, 2012
Privacy Concerns relating to the PSTN Validation Protocol (PVP)
draft-procter-vipr-privacy-concerns-00
Abstract
This document describes some issues with privacy leaks (real or
imagined) associated with VIPR, and also some of the countermeasures
that could be deployed to avoid them.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Procter Expires April 23, 2012 [Page 1]
Internet-Draft VIPR Privacy October 2011
Table of Contents
1. Leaks during validation . . . . . . . . . . . . . . . . . . . . 3
1.1. Caller ID . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Mitigation: Hash the Caller ID . . . . . . . . . . . . 3
1.1.2. Mitigation: Reverse the direction of the lookup . . . . 3
1.1.3. Mitigation: Use the times in the username instead . . . 4
1.2. Source IP identification . . . . . . . . . . . . . . . . . 4
1.2.1. Mitigation: Anonymising the validation attempt . . . . 4
1.3. Traffic statistics leakage . . . . . . . . . . . . . . . . 4
1.3.1. Mitigation: Random validations . . . . . . . . . . . . 5
2. Office Pranks . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Obtaining the PVP credentials . . . . . . . . . . . . . . . 5
2.1.1. Mitigation: Don't share validations between phones . . 6
2.2. Increasing the time tolerances . . . . . . . . . . . . . . 6
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
4. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Procter Expires April 23, 2012 [Page 2]
Internet-Draft VIPR Privacy October 2011
1. Leaks during validation
1.1. Caller ID
PVP[1] defines a validation method A that encodes the calling and
called numbers in the username of a TLS-SRP secured session. This
seems to open up an interesting information leak, since the resulting
username is sent in the clear.
Let's assume EvilCorp registers its node-id against the hash of the
sales number of its competitor, VictimCorp. Then, whenever a ViPR-
enabled caller tries to call VictimCorp to buy something, a few hours
later their ViPR server will attempt to establish a connection to
EvilCorp. Even assuming that EvilCorp can't complete the handshake
because it has no idea of the call details, EvilCorp still ends up
with a list of Caller IDs for people who called their competitor's
sales line.
1.1.1. Mitigation: Hash the Caller ID
To make the Caller ID harder to extract, we could hash it before
constructing the SRP username. We could choose an expensive hash
such as bcrypt and using a key common to everybody, and a salt that
is derived from the time of the day, modulo 48 hours. Because the
complexity of the bcrypt hash (and so the time it takes to generate
it) can be increased as the processing power becomes available, we
can define a minimum time that it will take to generate all the
hashes for the E.164 space. Changing the salt each 48 hours
increases the difficulty of precomputing the hashes. The key itself
and bcrypt complexity can be stored in the RELOAD config file, and be
changed in a safe way from time to time.
1.1.2. Mitigation: Reverse the direction of the lookup
This attack leaks information about who calls a specific number, in
no small part because the calling party initiates the verification
protocol. We can easily avoid this by requiring the called party to
perform the verification of the calling party instead.
However, whilst this may prevent an attacker learning the Caller ID
of calls to the attacked number, a trivial change to the attack will
allow an attacker to learn what calls are made from the attacked
number. Instead of EvilCorp registering against VictimCorp's sales
line, they could register against VictimCorp's CEO's number.
Incoming PVP attempts would then correspond to calls made by the CEO,
which might be used to inform a balanced investment portfolio.
Procter Expires April 23, 2012 [Page 3]
Internet-Draft VIPR Privacy October 2011
1.1.3. Mitigation: Use the times in the username instead
The current proposal uses the calling and called party numbers along
with the start and end times of the call to validate both parties.
The times are used as the shared secret, and the numbers as the
username in the TLS SRP handshake. We could swap this information
around so to use the times as the username and the numbers as the
shared secret. Sending the times in the clear is less of a problem
since they are generally not as sensitive as the Caller ID.
In the pranking scenario (discussed below), the calling and called
party numbers are generally known in advance. The only thing to
prevent calls being intercepted for prank purposes is that the call
timing information is not trivial to obtain. By sending the timing
information as the SRP username, pranking becomes almost trivial to
achieve.
1.2. Source IP identification
Assuming the Caller ID can be obscured by some means, there is still
a leak of the source IP address for the validation attempt. EvilCorp
is likely to be able to identify medium and large organisations by
simply performing a 'whois' lookup on the source IP address of the
validation attempt. Smaller organisations may be identifiable from
the reverse DNS, or even a traceroute, depending on how their ISP
configures their network.
1.2.1. Mitigation: Anonymising the validation attempt
It should not be too difficult to define a RELOAD Link Layer that
uses TURN TCP to hide the source of a PVP connection.
As the PVP stream will go through the TURN node, it is susceptible to
eavesdropping. Therefore we may want to be sure that there is no
difference between a successful and a failed validation when looking
at the encrypted stream (packet length for example).
1.3. Traffic statistics leakage
Assuming the source IP address of a validation attempt could be
obscured, the fact that a validation attempt is being performed leaks
statistical information. Spotting a noticeable spike in competitor's
sales line traffic following one ad campaign, but not another, is
perfectly feasible and useful once you have a statistically
significant number of calls. No doubt far more information can be
extracted given time and inspiration.
Procter Expires April 23, 2012 [Page 4]
Internet-Draft VIPR Privacy October 2011
1.3.1. Mitigation: Random validations
An additional protection could be that VIPR servers have a standard
process that randomly select VIPR registrations and try to establish
a PVP connection that will always fail. That should add enough noise
so the real origin of a validation cannot be pinpointed.
Measuring and removing the background noise from this sort of
approach would be quite straightforward, unfortunately. Registering
a couple of numbers for which no service is provided would give a
baseline noise figure to subtract. Far more powerful statistical
methods also exist to remove noise since this is a common problem in
many fields.
2. Office Pranks
VIPR offers some interesting possibilities for playing jokes on
colleagues. Whilst this attack is described in terms of a prank, the
underlying mechanisms may be used to eavesdrop or misroute calls for
less benign reasons.
PVP[1] method A requires knowledge of the called number, calling
number, and call start and end times. Method B dispenses with the
calling number. The VIPR Overview [2] hints at the problems of
securing this information within a typical enterprise environment in
the last paragraph of section 6.2, but the full scale of the problem
is not explored.
2.1. Obtaining the PVP credentials
If a colleague makes a call, then a moderately dedicated prankster
will find the called and calling numbers easy to discover. The
called number can be obtained from the phone's dialled call list
(next time the victim makes some tea, for example), and the calling
number is easy to obtain since it will almost certainly be fixed for
calls from that deskphone. If this isn't already locally known, a
quick test call to a mobile phone will suffice. All that remains are
the start and end time of the call.
Since PVP only requires times to be accurate to the nearest two
seconds, this isn't too difficult. A prankster in an open-plan
office, or an adjacent cubicle should have little difficulty in
determining the start and end times with a stop-watch to sufficient
accuracy. Improved timing might be possible if the office uses
bridged line appearances, or busy lamps. For the more technical
prankster, a dialog event package[3] subscription to the victim's
deskphone will provide all the necessary details with more than
Procter Expires April 23, 2012 [Page 5]
Internet-Draft VIPR Privacy October 2011
enough accuracy.
Once these details have been collected, the prankster will have an
hour or so to enter them in a website such as
http://prank.your.coworker.example.com, which will make the necessary
entries in the DHT and await the validation attempts. Once
validated, the prank server may perform a number of amusing pranks
for future calls, including forwarding to another SIP URI, or onward
routing to the original called number with media copied to the
prankster.
2.1.1. Mitigation: Don't share validations between phones
To prevent a compromise of one phone affecting all phones within an
enterprise, we can ensure that validations are not shared between
phones. This protects against certain types of attack (e.g. abusing
a visitor's phone in reception to set up a VIPR route to catch later
calls from the CEO's office), but doesn't protect against in-house
prank attacks as described above, which use the victim's own phone,
and indeed a call made by the victim themselves. Not sharing
validations also may give rise to odd situations when enhanced calls
are available to some destinations from certain phones but not
others. Whether this is an acceptable trade-off will depend very
much on the nature of the enterprise.
2.2. Increasing the time tolerances
PVP at present transforms the start and end times into pairs of times
rounded to the nearest second, which represent a 2-second interval
which spans the measured start or end time. These are called
Tstart-1, Tstart-2, Tend-1 and Tend-2. To handle a certain amount of
uncertainty in timing, four validation attempts are made, with
different combinations of start and end times. These are given in
the draft as:
1. Try Tstart-1 and Tend-1.
2. Try Tstart-2 and Tend-1.
3. Try Tstart-1 and Tend-2.
4. Try Tstart-2 and Tend-2.
A server answers each of these four attempts with the start and end
times rounded down to the nearest second. For prank purposes, these
are best guesses, and we will call them Gs and Ge. If they were good
guesses, then one of these four attempts will succeed.
Since the group of four validation attempts will be performed against
each registration in the DHT, we can take advantage by registering
multiple times and trying variations on Gs and Ge. For example,
Procter Expires April 23, 2012 [Page 6]
Internet-Draft VIPR Privacy October 2011
registering twice will get a second set of validation attempts, which
would allow us to try Gs, Ge+2. Two more registrations would allow
us to test Gs+2, Ge and Gs+2, Ge+2 meaning that with four
registrations, we have relaxed the accuracy requirements from 2
seconds to 4 seconds. 9 registrations allows times within 6 seconds
to work and 16 registrations will allow times with 8 seconds to work.
Whilst further registrations will permit the timing to be relaxed
even more, timing a call to the nearest 8 seconds is remarkably easy
if you are in the same room.
Finally, now that the start and end time guesses have been corrected
(by successfully validating against a PVP client), these corrected
times could be used to validate against the true owner of the called
number, allowing the prank server to execute a Man-In-The-Middle
attack, eavesdropping on all signalling and media during future
calls.
3. Acknowledgements
Much of the text of this draft is taken from emails on the vipr list
between myself, Marc Petit-Huguenin and Cullen Jennings.
4. Informative References
[1] Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "The Public
Switched Telephone Network (PSTN) Validation Protocol (PVP)",
draft-petithuguenin-vipr-pvp-00 (work in progress), April 2011.
[2] Jennings, C., Rosenberg, J., and M. Petit-Huguenin,
"Verification Involving PSTN Reachability: Requirements and
Architecture Overview", draft-jennings-vipr-overview-00 (work in
progress), April 2011.
[3] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
Procter Expires April 23, 2012 [Page 7]
Internet-Draft VIPR Privacy October 2011
Author's Address
Michael Procter
VoIP.co.uk
Commerce House
Telford Road
Bicester, Oxfordshire OX26 4LD
UK
Email: michael@voip.co.uk
URI: http://www.voip.co.uk
Procter Expires April 23, 2012 [Page 8]
