Subject: [VIPR] An alternative to the VIPR ticket

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 03 Sep 2011 12:06:28 -0700

In the current specification, the PVP server builds and signs a VIPR ticket, and
send it back to the PVP client, that passes it to the Call Agent/ Border Element
(CA/BE).  The CA/BE will insert this ticket in the next SIP INVITE to the remote
CA/BE, which will check the validity of the ticket and the domain of the TLS client.

There is multiple things that bother me with this process:

- - The verification of the ticket use HMAC-SHA1, and so the same password has to
be provisioned in both the CA/BE(s) (to verify the ticket) and the VIPR
server(s) (to generate the ticket).
- - The ticket can be used without TLS (we all know that implementers think of
MUST as SHOULD and SHOULD as MAY).

I would like to propose an alternative that is simpler to implement and, I
think, more secure than the ticket.

Instead of using a symmetrical key, the local VIPR server generates an RSA key
pair, with the public key distributed to the CA/BE(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[1].  The local PVP
server generates a new certificate[2], sign it with its private key and send it
back to the remote PVP client, which pass it back to the remote CA/BE.

The remote CA/BE will use the certificate received to establish the TLS
connection for the SIP transactions to the local CA/BE, which will use a
standard CA based certificate for its domain.  The local CA/BE will be able to
verify with the VIPR public key that it issued the certificate, then will
validate the standard parts of the certificate (expiration date and so on).

There is multiple advantages to this proposal:

- - The private key is stored only in the VIPR server, or better in a physical
token.
- - VIPR does not work without TLS for the SIP connection.
- - There is plenty of commercial or free TLS and X.509 implementations that have
years of experience and testing, which is not the case for the ticket proposal.
- - Security agility is provided by TLS.
- - No additional SIP Header.
- - Because the ticket verification process is folded into the client certificate
verification, there is less resources needed.

[1] This is the private key of the CA/BE, so the CA/BE needs to upload the
PKCS#10 file in the VIPR server.  Depending on the architecture used, each CA/BE
can use a different PKCS#10 or the same, which means that the PVP server must be
able to process more than one PKCS#10 and send back more than one certificate on
one PVP connection.

[2] The certificate sent back can directly contain the SIP routes, increasing
the overall security.  One possible mapping from the ValExchange response to the
certificate could be:

- - Unique ID: serialNumber
- - Epoch: issuer
- - salt: N/A
- - integrity: signature
- - Validity: validity
- - Phone Number: subjectAltName uniformResourceIdentifier tel:+14085551234
- - Node-ID: subjectAltName uniformResourceIdentifier
reload://0110123456789ABCDEF0123456789ABCDEF/
- - Granted domain: subjectAltName dNSName example.com
- - Granting domain: implicit in routes
- - Route(s): subjectAltName uniformResourceIdentifier
sip:[email-masked]:371;maddr=10.1.1.1

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