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]