[VIPR] Agenda & Handout for 2011/10/14

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

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

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

Note that the sum of the time allocated to each topic exceeds the time allocated
to the whole call.  The topics that cannot make it to the discussion will be
postponed to the next conference call if they are not subsequently decided in
the mailing-list.

Because the conference bridge as a limited capacity, an individual invitation to
the conference will be sent shortly after this email to each member of the
design team.  Please send me an email if you are not on this list and want to
receive an invitation.

Note that the design team conference call is not a way to short-circuit the
normal process, but a way to accelerate it by increasing face to face time.  All
decisions made must be confirmed on the mailing-list.

This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated
by RFC 4879).


B. Handout (reading time: 10 min)

B.1. Ticket vs Client certificate

In the current specification, the PVP server builds and signs a VIPR ticket, and
sends it back to the PVP client, which passes it to the SIP element.  The SIP
element will insert this ticket in the next SIP method to the remote SIP
element, which will check the validity of the ticket and the domain of the TLS
client.

The problem with this process is that the verification of the ticket use
HMAC-SHA1, and so the same password has to be provisioned in both the SIP
element (to verify the ticket) and the PVP server (to generate the ticket).
Also the ticket uses an adhoc format, for which no code currently exist, and
there is no provision for security agility.

So the proposal would be to replace the ticket by a client certificate, which
could work like this:

Instead of using a symmetrical key, the local PVP server generates an RSA key
pair, with the public key distributed to the SIP element(s).  After a successful
PVP connection, the remote PVP client sends a PKCS#10 certificate request,
containing the domain name and signed with a private key.  The local PVP server
generates a new certificate, sign it with its private key and send it back to
the remote PVP client, which pass it back to the remote SIP element.  The
SubjectAltName contains the granted-by field, and the phone number and the
granting-domain are stored as one URI in the Issuer Alternative Name extension,
and the granting node is also be stored as a reload URI in another Issuer
Alternative Name extension.

With this first step, we use the X.509 certificate just like the current ticket,
as a container to carry the parameters in the ticket.  This means that the
border element on the originating side establishes a TLS connection using a
static client certificate, and then send an INVITE with a Vipr-Ticket header
containing the X.509 certificate received from the PVP transaction and encoded
in base64.  The border element on the receiving side verifies the client
certificate as per RFC 5280 (using public trust anchors), then verifies the
certificate inside the Vipr-Ticket (or pass it to another element to verify this
second certificate), using RFC 5280 with the PVP CA certificate as trust anchor
and by using the same algorithm than currently. At this point we have exactly
the same process than before, expected for the container used to carry the
ticket values.

Now let's add two very small modifications on the server processing side:

- - The VIPR server CA is added to the list of public trust anchor that the TLS
server uses to validate the client certificate.
- - If there is no Vipr-Ticket in the INVITE, the client certificate received from
the other side is used as if it was received in a Vipr-Ticket header field.

With this, we now can have the TLS client choose to either work as a standard
SIP client, i.e. it uses its static client certificate for the TLS connection,
and put the certificate received from PVP in the Vipr-Ticket field, or work more
dynamically, by using directly the certificate received from PVP as the client
certificate for the TLS connection.  On the server side all the processing can
be done at one point, or it can have the ticket processing delegated to another
server.

B.2. PVP Methods Registry

On the PVP subject, The VIPR specification currently defines two methods for the
PSTN validation:  Method "a", which is used when the Caller-ID is available and
method "b", which is used when it is not.  The PVP draft also permits to define
new validation methods, but it does not explain when and how to use this
extended methods.

This proposal is in two parts.  First we need to establish a IANA registry for
the PVP methods, and to assign a priority to each of these methods.  Let's say
for now that the priority is between -∞ (lowest priority) to +∞ (highest
priority) and that priorities should be assigned by steps of 100.  With this
scale we could assign priority 0 to method "b" and priority 100 to method "a".
Then we say in the spec that a VIPR server must try available methods starting
from the highest priority to the lowest priority, until one succeeds or all
fail.  This implements the same algorithm that is currently in -pvp ("a" first,
then "b").

Now the problem with this is that the number of methods will increase in the
future, but we may not want that the PVP client tries all the methods available
each time.  So the second part of this proposal is to have each VIPR domain
publishing the list of methods supported by each of its phone numbers in the
RELOAD distributed database, in the existing VIPR-REGISTRATION resource record.

With this information, the PVP client immediately knows what methods to try from
the VIPR-REGISTRATION record, and the order to try them from the IANA registry,
and can also accumulate statistics on the usage of unsupported methods.

The PVP server can use this mechanism to simplify the process.  For example if
it knows that it will never receive the Caller-ID, it just have to never
advertize the "a" method.  Another example is with analog FXO ports that cannot
be used with either method "a" or "b".  In this case the VIPR server can still
advertize a new method using DTMF or fingerprint.

Note that because the methods supported per phone number are stored in the
RELOAD distributed database, the SIP call agent cannot retrieve them to decide
what method to use when starting a call, as it would take too much time to
retrieve it (same reason the validation is not done in real-time).  But it can
query them in the background using the history of calls or just before
scheduling a re-validation.

I would also propose to move the description of the generic PVP algorithm to the
- -framework document, to add a section in -framework explaining how to register a
new method on a IANA registry and to keep the two existing methods ("a" and "b")
into the -pvp draft.

B.3. PVP Privacy

As reported by Michael Procter, there is ways with the current PVP methods to
discover valuable information about a competitor.  But first let's add some
common vocabulary related to PVP:

- - The PVP selector is a list of parameters that are sent by the PVP client side
to retrieve a set of call records in the PVP server side.  The resulting set can
be empty, in which case the validation fails, can contain one element, or can
contain multiple elements in which case the method description must also defines
what call record should be selected (e.g. in the case of method "a", the most
recent call record is selected).  One important point is that the selector is
always passed from the PVP client to the PVP server in clear, and so this is
where the privacy leakage happens.

- - The PVP parameter is a list of name/value pairs that are passed in clear
between the PVP client and PVP server to aid the verification.  Examples are the
rounding value and the vservice id for methods "a" and "b".

- - The PVP secret is the information that each side of the PVP transaction tries
to verify.  The algorithm used (SRP) uses a zero-knowledge password proof, so
neither side can deduce the secret if the verification fails.  In the case of
methods "a" and "b" the secret is the rounded start and end time for the call,
but there is a lot of other possible secrets that can be used in new methods
(DTMF, UUIE, fingerprint, SMS hash, etc...).

In the privacy issue, the problem is that callee number and caller numbers are
disclosed in the PVP selector for method "a" and the callee number is disclosed
in the PVP selector for method "b".

One proposed solution would be to hash these numbers, but finding the phone
numbers would still be trivial for a determined competitor.  Passing the hash
salt as a PVP parameter and using an adaptive hash method like bcrypt will force
the PVP server to rehash all the current terminating call record, but will force
a competitor to rehash probably half of the total E.164 space to find the
numbers.  This is still possible but can provide an adequate privacy protection
level.

Another possibility would be to invert the selector and the secret.  After all
the star/stop time of a call is not as sensitive as the caller/callee phone
numbers.  In this method the PVP selector would be the start/stop time and the
secret would be the caller/callee numbers.  The problem is that it will be more
difficult to design an algorithm to select a unique call record if the returned
set contains more than one.  One solution could be to add more data in the PVP
selector, for example by adding the call initiation time and the direction of
the termination.

We do not even need to decide - we can define these two algorithms as different
methods (in addition to "a" and "b") and let the VIPR domain choose (see PVP
registry proposal).

B.4. PVP Entropy

Another issue related to PVP is the management of entropy (Section 10.1 of the
- -pvp draft).  The idea is that the fact that one validation succeeds is not
always enough for a remote VIPR server to give back routes and ticket for this
destination.  For example a VIPR domain could decide that at least 3 different
calls validated with method "b" are needed to let a SIP call reach the endpoint.

This proposal describes a mechanism for PVP to implement this.  The idea is that
when a PVP validation succeeds, the PVP server will return a ticket but may not
return the list of routes if the entropy threshold is not reached.  The ticket
will contain an opaque value set by the PVP server that contain the level of
entropy that this caller has reached.  The PVP client stores the ticket but does
not notify the call agent as there is no routes available.  The next time the
PVP client has a successful validation with the same destination, it sends the
saved ticket in addition to the domain.  The PVP server then evaluates the
ticket, increases the entropy value stored and sends back a new ticket.  If the
threshold has been reached, then the PVP server sends back the routes at the
same time, routes that the PVP client can now send with the ticket to the SIP
element.

When renewing the routes/ticket, the PVP client also sends the existing ticket,
so the PVP server can decide to lower the threshold based on the entropy
collected the previous time and the date of the ticket.

This can be combined with the proposal for method priority.  If multiple methods
are available for a destination but the first that succeeds does not return the
routes then the PVP client can use the next available methods in the list to try
to increase the entropy and receive them.

A PVP server may even use different thresholds, depending on the domains to
validate.  This then becomes an extension to the white/black list, where a
blacklist is implemented as a default threshold of X and an infinite threshold
for the domains blacklisted, and where a whitelist is implemented as a default
infinite threshold and a threshold of X for the domains whitelisted.

B.5. Ticket renewal

Another thing that was discussed in Quebec City was the "First Call Problem",
i.e. the problem that it takes up to 48 hours to verify a call and been able to
use enhanced media.  I think the conclusion of the discussion was that it was
not too annoying for the first call, as it did not degrade the user experience.
On the other hand, the cryptographic ticket granted after the first has an
expiration date and so need to be renewed, and that will degrade the user
experience as it would mean that for each destination, the end-user will
periodically not be able to use enhanced media for the duration of a call.

There was multiple proposals at the microphone to solve this problem, but I
would like to detail the one I proposed.

The idea is, sometimes before the expiration of the ticket, to make in parallel
a PSTN call and a SIP call using the existing SIP route and ticket for the
enhanced media (let's say video for the remaining of this discussion).  There is
already an existing I-D that can be use for this, draft-ietf-mmusic-sdp-cs.  The
way it could work is that the call agent, after retrieving the SIP route and
ticket for a destination, will decide that it is time to re-validate the route,
based for example on the frequency of calls to this number and the remaining
validity of the ticket.  The SIP element then adds an additional m= line to the
SDP that contains a PSTN address.  The offered SDP then looks something like this:

v=0
o=- 2890844526 2890842807 IN IP4 10.47.16.5
s=
c=IN IP4 10.47.16.5
t=0 0
m=audio 49170 RTP/AVP 0
m=audio 9 PSTN -
c=PSTN - -
a=setup:active
a=connection:new
a=cs-correlation: uuie callerid dtmf
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

The SIP element on the other side verifies the ticket then starts to process the
SDP.  If it does not support this feature then, as per the rules in RFC 3264, it
will reject the second m= line by using port 0 in the answer SDP (In this case
the end user will have to have PSTN only calls for the 48 hours after the
expiration of the ticket).  If the remote SIP element supports this extension
then it will send back an offer like this:

v=0
o=- 0 1 IN IP4 192.168.2.1
s=
c=IN IP4 192.168.2.1
t=0 0
m=audio 8000 RTP/AVP 0
m=audio 9 PSTN -
c=PSTN E164 [phone]
a=setup:passive
a=connection:new
a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3
m=video 9000 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

The local SIP element checks that the c= line contains the right number, then
establishes the audio and video media over IP, as usual, but also starts a PSTN
call following the rules in draft-ietf-mmusic-sdp-cs (i.e. sending the
correlation value as needed).  The remote SIP element will receive the PSTN
call, and correlate it with the existing SIP connection.  Both parties must send
audio on both the IP and the PSTN side, but the receivers can choose to play the
audio coming from either the IP or PSTN connection (this is because we may want
to use in the future fingerprint methods for the validation).  The PSTN call is
ended at the same time than the IP connection if the methods used for validation
are based on the call duration (other methods may permit to end the call
before), so the VCRs are processed as for an initial call.  The local party
marks the route as been under re-validation, so to not use the renewal method
for the next 48 hours.  The VIPR server will send a notification before the end
of the 48 hours if there is still a PSTN route to this destination.

B.6. Infrastructure overlays

A new draft to discuss infrastructure overlays has been submitted to DISPATCH.

"[RELOAD] is a peer to peer protocol developed by the P2PSIP Working
 Group.  Each RELOAD instance has a unique name, which is used by the
 process in section 10.2 of this specification to find the
 configuration servers, enrollment servers and bootstrap servers
 needed to join the overlay.  The process assumes that the RELOAD
 instance name is a FQDN, and uses the process in [RFC2782] (SRV RR)
 to find the IP address of the HTTPS server that serves the
 configuration document for this overlay.

 This process is adequate when the management of the overlay does not
 need to be distinguished from the owner of the FQDN used as the
 instance name, which is the case most of the time.  But there is a
 special class of overlays that, by definition, requires to be unique
 on the Internet and for which having the possibility of create
 instances would defeat their very purpose.  This specification calls
 the kind of overlays that are not domain specific, but application
 specific "infrastructure overlays".

 [VIPR] is a technology that is being standardized in the VIPR Working
 Group and that aims to build bridges between SIP islands by
 automatically provision SIP routes after the "ownership" of a PSTN
 phone number has been verified by an actual PSTN phone call.  This
 technology uses an RELOAD overlay as a distributed database where
 mappings between phone numbers and servers responsible for the
 validation process are stored.  The promise of VIPR to bridge these
 SIP islands cannot be fulfilled if there is more than one distributed
 database storing these mappings."

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

iEUEARECAAYFAk6XATsACgkQ9RoMZyVa61euvACYzXUXvaJIjHtdtLw7dY2evIyy
UwCeKkbyUScdiyh5/g9lb2NIB4LWNC4=
=foaT
-----END PGP SIGNATURE-----