Re: [VIPR] An alternative to the VIPR ticket

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

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

On 10/13/2011 12:29 AM, Michael Procter wrote:
> On 12 October 2011 23:53, Marc Petit-Huguenin <[e-mail]> wrote:
>> During the last conference call, this proposal was criticized as been a
>> significant change from the way SIP is processing TLS requests.  My research
>> shows that it is not the case.
> [...]
>> So in conclusion, my proposal does not change what a normal SIP stack is doing,
>> because the specification does not say what a SIP stack should do with a client
>> certificate.
> 
> What you describe is that the server side of the connection will need
> to validate a client certificate whatever happens, and changing the
> ticket to a certificate does not substantively change the validation
> process.  It does force the ticket validation to the edge of your
> network though, which having the ticket in a header field doesn't.
> Since ticket validation is a new process introduced with ViPR, this
> may be a reasonable change.
> 
> However, what is overlooked in this analysis is that the client side
> must present a different certificate on a per-call basis.  Most
> implementations that I have seen tend to have a fairly statically
> configured certificate (or several, but not lots) that is valid for
> the duration of the process/between scheduled maintenance.  Having the
> certificate change on a per-call basis is a change for these
> implementations.  How significant a change depends on their
> architecture, but it is a change nonetheless.

True.

> 
> Why does this matter?  With the ViPR ticket in a header field, I can
> route ViPR traffic out in much the same way as I route other SIP
> traffic.  Granted it has an additional header, but that doesn't
> substantively change the job my egress points perform.  With a ViPR
> certificate instead of a ticket, my egress points need to be
> sufficiently ViPR-aware to know to use a dynamically selected
> certificate, and how to get hold of that certificate.  Not
> insurmountable problems, but ones that are introduced by changing to a
> certificate over a simple header field.

Another argument to add to your point is that using a different certificate for
each different phone number reduces the possibility of session caching or
session resumption.

> 
> There may be other problems (Jon seemed to jump on the change quite
> fast so he may have more reasons), but this is the one that struck me.
>  I think this change warrants wider discussion before deciding whether
> to adopt or not.

OK, so I think that there is a way to keep the properties of the ticket (can be
processed separately from the TLS server processing, does not require to
dynamically choose the certificate on the client side), and still let "advanced"
implementations not use this.

The first step is to simply say that an X.509 certificate is a better
replacement for the ticket as defined currently, independently to its usage in TLS:

- - Existing and proven libraries.
- - Support for asymmetrical keys.
- - Security agility.

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, then verifies the certificate inside the
vipr-ticket (or pass it to another element to verify this second certificate).
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.

This way we have the best of the two worlds.

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

iEYEARECAAYFAk6W+4sACgkQ9RoMZyVa61crEgCfeBmjMOtgbQ62tmcCfQXrzOH0
8FsAnj/lq24IXVOSv89MjHweoJLQwLCZ
=WGHo
-----END PGP SIGNATURE-----