Subject: Re: [VIPR] Review of draft-jennings-vipr-overview-01

From: Cullen Jennings <[email-masked]>
Date: Mon, 11 Jul 2011 11:54:06 -0700

Thee are excellent points. The first few were easy and fixed in next version but on to some of the harder issues you raised ...

On May 13, 2011, at 1:37 , Michael Procter wrote:

> 
> Section 8.2
>  The TLS-SRP uses the caller ID and called number as a "username"
> 
> This seems to open up an interesting information leak, since the
> 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 CLIs for people who
> called their competitor's sales line.  I'm not a salesperson, but I
> believe that supplying a list of 'hot leads' like this would make
> EvilCorp's sales team quite happy.

I think we need to protect against the attack you describe. It's been awhile since have looked at SRP. Perhaps hashing the username would solve this?  

> 
> 
> Section 9.2: 3rd attack
>  "the TTL for cached routes is set to match the
>   duration that carriers typically hold numbers."
> 
> I understand the reason for this, but I think it might lead to a poor
> user experience.  If someone becomes accustomed to having a videocall
> / wideband audio with a regular recipient, and then finds that one day
> it falls back to PSTN, I doubt that "ViPR cached route TTL expiry" will
> be the first thing that springs to mind.  If you have a moderate number
> of ViPR-connected regular destinations, and a cache time of 3-6 months,
> then you will find that this happens quite often, which will lead to a
> perception of unreliability for the technology.  Once a fallback call
> is made, it will take up to 12 hours (from my reading of the PVP draft)
> to refresh the SIP route, which essentially means it won't be 'fixed'
> on the same day.  It might help if there were a faster way to revalidate
> routes that have expired recently, or a way to qualify a route for
> continued use whilst still protecting against this attack.

total agree. I'd like to see a better way of doing validation for video calls. 

> 
> 
> Section 9.2: 5th attack
> 
> I think you may be understating the risk here.  An environment that uses
> phones supporting the dialog event package, for example, will allow
> mischievous colleagues to mount this attack.  Even someone sitting in the
> next cubical to the caller, wielding a stop watch, probably stands a good
> chance of mounting this attack.  Rather than recommending that ViPR is not
> deployed in enterprises with moderately clueful staff, is there
> something that can be done to tighten up the defences to this attack?
> 

again I agree. Of course the guy in the next cube could probably just walk over and forward the phone too. One things that can be done is not share the validation you learn for one phone in an enterprise with other phones in the enterprise. 

> Best regards,
> 
> Michael
> _______________________________________________
> VIPR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vipr

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Michael Procter <[email-masked]>
Date: Fri, 22 Jul 2011 18:42:51 +0100

>>  The TLS-SRP uses the caller ID and called number as a "username"
[Discussion of CLI leaks of callers to a specific number]

> I think we need to protect against the attack you describe. It's been
> awhile since have looked at SRP. Perhaps hashing the username would
> solve this?

I don't think hashing would be enough.  I hashed the entire UK number
space in a few hours using a naive piece of Python and my
not-exactly-state-of-the-art computer.  Then I googled and found out
about using graphics cards for number crunching, which apparently can
do the same job in a couple of seconds.  Hashing the CLI doesn't sound
like a sufficient deterrent to me.

In fact, whatever technique used to obscure the CLI is probably only
slightly helpful as the source IP address of the validation attempt
would probably leak too much information for larger users (I accept
that smaller users will probably have fairly generic reverse IP
information and probably their ISP's info in whois).

Going a step further, even without knowing the source IP (validation
over TOR anyone?), I still think there is a worrying leak.  Spotting a
noticeable spike in competitor's sales line traffic following this ad
campaign, but not that one, is perfectly doable once you have a
statistically significant number of calls.  No doubt far more
information can be extracted given time and inspiration.

>>   duration that carriers typically hold numbers."
[Description of route expiry leading to poor user experience]

> total agree. I'd like to see a better way of doing validation for video calls.

Not thought of any bright ideas here, sorry!

>> Section 9.2: 5th attack
[Discussion of falsely claiming a number by knowing the start and end
times of a call]

> again I agree. Of course the guy in the next cube could probably just
> walk over and forward the phone too. One things that can be done is
> not share the validation you learn for one phone in an enterprise with
> other phones in the enterprise.

That restriction isn't enough to stop the attack if you time the
victim making the call on their own phone, which wouldn't take too
much social engineering.  Remember that you only need to get the
timings accurate to 2 seconds, which I think sounds fairly
straightforward.

Actually, you can handle a looser tolerance if you register multiple
times.  For each registration in the DHT, the original caller will
attempt a validation, giving you another guess at the times, so you
can use your best guesses (Tb and Te) for the first go, (Tb, Te+2) for
the second, (Tb+2, Te) for the third and (Tb+2, Te+2) for the fourth.
4 registrations and you have doubled the tolerance to timing errors to
4 seconds for both call beginning and end.  More registrations would
allow you to relax the tolerances further.  You could even defeat
Hadriel's "You expect accurate call lengths?" attack like this!  And
once you have had a correct with the caller, you can use your new
accurate times to talk to the real registered owner of the number and
set up a MITM for the next few months.

Best regards,

Michael

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 25 Jul 2011 15:39:39 -0400

> like a sufficient deterrent to me.

But I am not a security specialist, but here's an idea:  VIPR servers on both
side use bcrypt to hash the phone numbers, 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.

> information and probably their ISP's info in whois).

It should not be too difficult to define a RELOAD Link Layer that use TURN TCP
to hide the source of a PVP connection.

As the PVP stream will go over TURN node susceptible to eavesdropping, 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).

> information can be extracted given time and inspiration.

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.

The reverse is problably also useful:  VIPR servers would want to randomly
register E.164 phone numbers from other providers, so the real owner of a phone
number cannot be discovered by looking at the messages in transit through peers.

This two techniques obviously increase the load on the VIPR servers, but as long
this is specified from the beginning the cost is known so it should be fine to
do so.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org