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

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

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

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

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

o Agenda

- - Move SIP intermediaries in a future draft (5 min)
- - RELOAD registration (5 min)
- - Replacement ticket by client certificate (10 min)
- - PVP privacy (10 min)
- - PVP method priority and registration (10 min)
- - PVP method entropy (10 min)
- - Ticket renewal (10 min)
- - Infrastructure overlays (5 min)

o Action items

- - Treat SIP interworking as an extension.
- - Remove the text saying that the phone number must be stored 3 times at the
VIPR level.
- - Explain the problem and requirements for the ticket mechanism.

o Minutes

- - Move SIP intermediaries in a future draft

Marc: The proposal is to treat SIP intermediaries as an extension to VIPR, in a
separate draft, but to be sure that we have the required hooks in the VIPR
drafts to not have to modify VIPR later.  The last part of the proposal is to
add a milestone for this after finishing the work on the base VIPR.

Jon: The viability of this proposal would depends on what the hooks are.  Second
I would be careful to not put this in term of SIP intermediaries, a more generic
problem is inter-working. But I am really interested on what the hooks are.

Marc: I do not know what the hooks would be.  I just published what the problem
is, as I said I would do in the previous meeting. I will release another version
that will contain multiple solutions and we can see from here what the hooks
will be, if there is any needed.

Dean: If we are going to place a lot of requirements, it becomes a location
server.  It's a simple lookup operation.

Jon: Documenting the hooks in the intermediary draft is one thing but the hooks
will be in the base draft, we need to be clear on this.  We need to not scope
this work too narrowly.

Marc: Do we agree to work on this later?

Mary: Yes.

Dean:  I disagree slightly with Jon. One hop is straightforward, but more
raises a set of transitive trust issues.

Jon: If we have two overlays then we have a disaster.  Keep the milestone high
level.

- - RELOAD registration

Marc: The current spec is saying that each phone number is registered 3 times,
which with the normal RELOAD replication, means that it is stored 9 times.  So
the question was what to do when there is a difference between the copies
retrieved.  The proposal was to require to have at least two identical copies.
But the discussion moved to why do we require 3 copies in the first place.  So
the next proposal was to store the phone number one time, to verify that there
was 3 identical replicas, and to use the voting algorithm when retrieved.

Hakim: What does identical mean?

Marc: Which return the same Node-ID.  The idea is that a rogue peer should not
prevent PVP to work.  But the discussion was more about the requirement of
having 3 copies at the VIPR level.

Hakim:  Does it really mater? The data in the overlay is not trusted.

Marc: Do we want to say that all nodes need to register 3 times or keep it
simple, i.e. one time?  It does not make a difference when storing, but the
nodes that will fetch need to know the number of copies.  One way it can be
solved is to put a parameter in the configuration file that indicate the number
of copies at the VIPR level.

Jon: Did we ever find why there was 3 copies?

Hakim: That was to increase the security - I am not sure.

Michael: It is easy to retrieve the replica?

Marc: Yes, what you do is that you put the Node-ID of the successor in the Fetch
request, instead of using just the Resource-ID.

Michael:  If the first node is compromised, why should I trust it to give me the
successor?

Marc: An excellent question, but more of a RELOAD problem.

Michael: So RELOAD protects against network outages, no malicious nodes.  So to
go back to Jon's point, we will validate any request anyway because we do not
trust anything from RELOAD.

Hakim: Yes, the idea was to protect in case a copy is lost.

Jon: OK, so just need one copy.

Hakim: It does not matter for an application point of view.

Jon: It is related to the SIP intermediaries.

Hakim: No its a dictionary storage.  Also having multiple copies permits to
increase the trust in a copy.

Marc: So one proposal would be to add a variable ion the configuration file that
contain the number of copies at the VIPR level.

Michael: I am reluctant to add a configuration variable.  I do not think we need
to replicate at the VIPR level, because we will verify everything we get.

Marc:  OK so everybody agree to remove the duplication at the VIPR level.

- - Replacement ticket by client certificate

Marc: The first problem with the ticket is that the ticket is signed using a
symmetrical key, key that need to be shared between the PVP server and the call
agent.  The second problem is that the ticket is separated from the TLS
certificate, so you have to validate the TLS connection, then verify the ticket.
 Another problem is that there is not existing proven code for processing the
ticket.  So the idea is to replace the ticket by an X.509 certificate, which
already contains all the fields required by the ticket, can use asymmetrical
keys, and has existing proven libraries.

Jon: This is a significant change, and we would need more time.  We should not
diverge too much from what SIP is doing.  TLS is not use much so pushing all the
security features into TLS might not be a guarantee of widespread success.  How
do you push this certificate onto systems that want to use it, and how do you
capture the parameters of the call so that you verify that it is the right
person you are talking to.

Marc: To push the certificate, you just send it instead of the ticket.  As for
the significant change, I will publish code that shows that it is less work to
use a certificate than a ticket.

Hakim: If sharing the secret is a concern, we should consider diverging?

Marc: It is a concern for me.

Jon: It's unclear to me why you need to share the symmetrical key.  The proxy
could just pass the ticket to the element that can verify it.

Michael: A middle ground would be to use public keys to sign the ticket.

Marc: It's not like there is 100's of implementations that need to be modified.

Hakim: I agree with Jon that keeping the semantics of SIP is important.  If that
means changing whatever Cisco implemented, it is fine.

Marc: A certificate is not that different from a ticket using asymmetrical keys.

Hakim: If it falls within regular TLS, then OK.

Jon: If the symmetrical key is the problem, then we need to go back to the
requirements.  This proposal is worth considering, but there is a huge space of
solutions that can be considered.

Marc: One problem is that in the current version of VAP there is no possibility
to verify the ticket at another place than on the call agent.

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

iEYEARECAAYFAk6TDwQACgkQ9RoMZyVa61e7bgCdHV+MWYw7kK+2sPY/0/CfIo6A
6wAAnjrrsEj7RSlRj3zgBaM1hJ1jA0zL
=3Pch
-----END PGP SIGNATURE-----