[VIPR] Minutes for 2011/10/14 conference call

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

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

VIPR Design Team conference call on Friday October 14th, from 9:05am to 9:50am PST.

o Attendees:
  Daryl Malas
  Hakim Mehmood
  Muthu Arul Mozhi Perumal
  Jon Peterson
  Marc Petit-Huguenin
  Michael Procter
  Dean Willis

o Regrets:
  Mary Barnes
  John Ward

o Agenda

- - Replacement ticket by client certificate (10 min)
- - PVP method priority and registration (10 min)
- - PVP privacy (10 min)
- - PVP method entropy (10 min)
- - Ticket renewal (10 min)
- - Infrastructure overlays (5 min)

o Action items

- - Add template for IANA registration for PVP methods, with priority.
- - Work on new method inverting the selector with the secret.
- - Send an email in the list detailing the entropy solutions (client-side vs
server-side).

o Minutes

- - Replacement ticket by client certificate

Marc: The goal of this meeting is to discuss items that are not discussed in the
mailing-list, and as there is good discussions on the mailing-list about this
item, I propose to skip it for this conference call.

- - PVP method priority and registration

Marc: There is currently two PVP methods defined in the draft: method "a' which
use the caller and callee number, and method "b" which uses the callee number
and the time in the middle of the call.  But there is more methods that can be
used (fingerprint, DTMF, SMS, etc...).  The first part of the proposal is to
establish a IANA registry for new methods and to assign a priority to each
method.  The second part of the proposal is to advertize the methods supported
by the PVP server in the RELOAD database, to accelerate the validation process.
 The third part of the proposal is to move the PVP algorithm into -framework and
to keep only the description of the methods in -pvp.

Hakim: So the proposal is to put the priority of the methods for PVP.

Marc: I was proposing to put only the list of methods supported.  I am not sure
it is interesting to put also the priority in the RELOAD database.

Hakim: OK, its just a list of methods supported for this particular resource.

Marc: Yes, and this should not be an issue for security.

Jon: It would matter if one method was weaker than another and a domain was
claiming it prefers it.

Marc: That's a good reason to not put the priority in the RELOAD database.

Jon: From an administrative point view, you do not have to move out the current
methods to provide a template.  Also how an implementation knows if Caller-ID is
going to work or not?  That maybe specific to the method, so can you really say
at the registry level that a method will work or not?

Marc: If a domain will never ever receive the Caller-ID, then it should not
advertize method "a".  But if there is a chance that method "a" succeed, then it
should advertize.

Jon: So anything that could work, you will ask to try it.

Marc: Yes, but the advantage is that methods we are absolutely sure that will
not work, like SMS on a non mobile connection, can be excluded.  If you have no
access to the audio stream, then a method using fingerprint can also be excluded.

Jon: OK, there is language that can capture that.

Marc: And what about priority in the IANA registry?

Hakim: That's fine.

Jon: The more methods we have, the more an attacker will be able to choose the
weakest.  So I think that what it will come down to what we think our
requirements a method has to meet to validate.  Until we understand that, it
will be tough to say that all these methods are secure.

Marc: In the framework document, I will list exactly what should be in the
document defining a method.

- - PVP privacy

The problem, reported by Michael Procter, is that the Caller-ID is send in clear
in method "a".  I proposed three additional definitions, to make the discussion
on this topic easier.  The PVP selector, which is sent in clear, is used to
select the call record on the server side. In method "a" the selector is the
called number and the Caller-ID, in method "b", it is the called number and the
time in the middle of the call.  The PVP parameters are a set of parameters that
are also sent in clear, for example the rounding value for "a" and "b".  The PVP
secret is what is verified, and cannot be discovered if the verification fails.
 For the two methods, it is the beginning and end of the audio call. The privacy
problem here is that someone can register a phone number and knows who is
calling this phone number.  There was a discussion on the mailing between
Michael and Cullen Jennings, where the idea was to hash the phone numbers. But
perhaps that instead of fixing methods "a" and "b" we should just create new
methods.  So a first new method is to use the same than "a", but hashing with
something like bcrypt.  A second new method would be to invert the selector and
the secret.

Hakim: If I understand correctly, the problem here is that someone can learn who
calls.

Marc: Yes

Jon: Hashing is a speed bump, but I suspect not worth enough to do it.  The idea
of inverting the secret with the selector is interesting.  I agree that the call
start and stop is not sufficiently unique and it has the property that the more
people are using VIPR the more likely there will be collision.  But it can be
combined with part of the numbers, i.e. area code or area code and prefixes that
are longer.

Hakim: Method "a" is more secure than method "b", but method "b" is not exposing
the Caller-ID at all, so domains that have concerns over privacy simply do not
advertize method "a".

Marc: The problem is that method "b" probably does not have enough entropy.

Hakim: Yes, it does circumvent to some extend the security concerns.

Marc: So do we want to fix the two methods, or keep them as they are and define
new methods?

Hakim: Invent new methods.

Jon: The problem is that if we invent new things that are less secure, then
people will use them.

Hakim: I do not disagree with that.

Marc: True, but "b" is already not very secure.  We cannot make something less
secure than "b", and we can simply say that we cannot have a method less secure
than "b".

Jon: Let's figure how secure "b" is first.  If we find that "b" is unacceptable,
then we may not want to do that.

Michael: We need to understand what the tradeoff are between have enough entropy
for a reliable call identification compared to leaking too much information.

Marc: I am personally on working on new methods and put explanations on the
security section of the current methods saying, do not use this.

- - PVP method entropy

Marc: Method "b" provides less entropy than method "a", which itself provides
less entropy than the future methods.  The idea is to accumulate entropy, so a
domain can require more than one validation before sending back a route and a
ticket.  Instead of sending back a route and ticket, the server sends back a
temporary ticket that contains the entropy accumulated, which is sent during the
next attempt at validation.  It fits well with what we talked before, priority,
and the fact that some methods have less security than other.  We can put in the
IANA registry the entropy that a specific method would accumulate.

Jon: I do not understand the way entropy is calculated but someone should figure
out if that actually works.

Marc: But is it a direction we want to go to?

Jon: The goal of VIPR is to reduce as much as possible the number of calls to
the PSTN, so something that would require more of those is undesirable.  We need
to evaluate what we get in return.  Is there alternative that accomplish the
same thing?  We can use probe calls during off hours.  If we decide to do this,
we really need to decide what the goals are.

Marc: The goal is to make method "b" better than what it is, because it is will
the best that some domains will be able to do.  I not would like to exclude
method "b" because it would exclude a lot of domains from VIPR.

Jon: Do we have a sense of how many people are excluded by this today?

Marc: This is all the cases where we do not have the Caller-ID.

Jon: How many things that we think will participate in VIPR have PRI?

Hakim: The problem is not necessarily not having access to Caller-ID, but how
enterprise domains send Caller-IDs that are the Caller-Id of the enterprise
versus the calling entity.

Jon: But for VIPR purpose it still works.

Hakim: No it does not because it would create an issue when you match the ticket.

Jon: What I am asking is about the 80/20 rule.  Does it happen 20% of the time,
1% of the time or 0.1% of the time?

Hakim: It's in the 20%.

Dean: The majority of PBXs send their trunk number, so we are talking about how
many PBXs versus SOHO devices.

Jon: If it's 20% we need to do something, if it's 1% we should do something, if
it's less than 1%, I do not care.

Hakim: For sure it's not 1%, but somewhere close.

Michael: For people that are making international calls, like videocalls to
grandma, then using the CLI will fail more often than it succeeds.

Daryl: Good point.

Michael: If you are talking of calls between enterprises, then yes Caller-Id
will work most of the time.

Jon: I am not really sure that this is for grandmas, because things for grandmas
do not have this property that VIPR has.  But point taken about the
international call issues.

Marc: One thing I would like to add is that we are not reducing the user
experience, because the 3 calls are at the beginning.  So doing this is
acceptable.  What is unacceptable would be to switch back to PSTN after having
video.

Jon: I do think that it is a problem.  It's not unacceptable, but it's
undesirable. It's not just video, it's wideband audio, it's presence, and it's
our job here to find the quickest way to enable this.  And if the way is to have
3 PSTN calls, it's definitively undesirable.

Hakim: I agree.  It's the #1 complaint I see today.  That it takes 24 hours, all
these things.

Marc:  I agree that we need to design methods that does this faster. But we
still need to have a bottom line which is method "b" because this is how we will
have many people in the overlay.  We should not require an SS7 connection to
participate in VIPR.

Marc: We need to decide if we want to talk about entropy or not at all.

Hakim: Is it possible to keep the guidance here, and let the implementers decide?

Marc: We still need a way to manage the entropy.  It can be a PVP server side
thing, where the server keeps a log of all the calls.  Or it can be done on the
PVP client side, in which case we have to define what is exchanged.

Hakim:  My preference would be server-side.

Marc: My preference is client side.

Jon: We need to think more about what we need to accomplish.

Dean: Post the question on the mailing-list.

Marc:  OK, I'll do that.

- -- 
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)

iEYEARECAAYFAk6cTbgACgkQ9RoMZyVa61d1GwCfZdYZAScs6i5RddfNN54JVidQ
HnUAn3i+Dg4F62dEaPyziwUTV5F5V69+
=XiDY
-----END PGP SIGNATURE-----