Re: [VIPR] An alternative to the VIPR ticket

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

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

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.

First of all, let's define exactly what SIP, without even talking about VIPR, is
doing regarding TLS.  The best place for this is RFC 5922.  We can skip the
client behavior discussion (section 7.3) because neither VIPR or my proposal
suggest any modification to this procedure.  Here's what RFC 5922 says about the
server behavior (aka client certificate):

"  When a server accepts a TLS connection, the server presents its own
   X.509 certificate to the client.  Servers that wish to authenticate
   the client will ask the client for a certificate.  If the client
   possesses a certificate, that certificate is presented to the server.
   If the client does not present a certificate, the client MUST NOT be
   considered authenticated.

   [...]

   When authenticating the client, the server MUST obtain the set of SIP
   domain identities from the client certificate as described in
   Section 7.1.  Because the server accepted the TLS connection
   passively, unlike a client, the server does not possess an AUS for
   comparison.  Nonetheless, server policies can use the set of SIP
   domain identities gathered from the certificate in Section 7.1 to
   make authorization decisions.

   For example, a very open policy could be to accept an X.509
   certificate and validate the certificate using the procedures in RFC
   5280 [6].  If the certificate is valid, the identity set is logged.

   Alternatively, the server could have a list of all SIP domains the
   server is allowed to accept connections from; when a client presents
   its certificate, for each identity in the client certificate, the
   server searches for the identity in the list of acceptable domains to
   decide whether or not to accept the connection.  Other policies that
   make finer distinctions are possible."

In other words, the SIP server (or proxy) does whatever it thinks is necessary
with the client certificate, and it does not seems that even following RFC 5280
is required (note in particular that nowhere it is said that the validation must
use a public trust anchor).

VIPR itself adds very little to the requirements of RFC 5922.  Here is what
- -sip-antispam says about TLS and the ticket:

"  The Border Element will receive the TLS ClientHello which begins the
   TLS handshake.  The Border Element will present its own configured
   cert.  Once TLS handshaking is complete, the Border Element notes the
   domain from the SubjectAltName on the other side of the TLS
   connection, and associates it with that connection.

   Next, the Border Element will receive an INVITE.  This INVITE will
   contain a ticket in the ViPR-Ticket header field value.  The Border
   Element extracts this header field.  This call flow assumes it is
   present.  The Border Element parses it, and obtains the epoch value
   encoded in the ticket.  This is matched against the current epoch
   value for the configured password.  If they match, processing
   continues.  The Border Element verifies the signature is correct.
   Next, it examines the start and stop time of the validity.  If the
   current time is between the start and stop times, the check is
   passed.  Next, the Border Element checks the granted-to domain in the
   ticket.  It compares that domain against the domain name in the
   SubjectAltName of the peer on the other side of the TLS connection,
   as noted above.  Next, it takes the Request-URI of the SIP INVITE.
   That will be of the form sip:+number@domain.  If it is not in that
   form, and if the number does not begin with a plus, the request is
   dropped.  The value, including the plus, is then compared to the
   number in the ticket.  If it is equal, the check has passed.  The
   Border Element leaves the header field in the request, but forwards
   to the Call Agent."

The only policy that is added to what RFC 5922 says is that the granted-to
domain in the ticket must be equal to the domain in the SubjectAltName of the
client certificate.  Here too, not a word about a public trust anchor.

Now back to my proposal.  The first thing is that the client certificate must be
validated using the CA of the VIPR server as trust anchor, which is already what
a SIP server could do.  It validates according to the rules in RFC 5280, which
is equivalent to verifying the signature of the ticket and the start/stop
validity.  The SubjectAltName in the client certificate (which is not even
required to be used in standard SIP) can be checked against the domain part of
the From header of the INVITE.  The phone number and the granting-domain (which
not even verified in VIPR) can be stored as an URI in the Issuer Alternative
Name extension in the client certificate and be validated against the
Request-URI of the INVITE.  The granting node can be also be stored as a reload
URI in an Issuer Alternative Name extension.

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.

(Note that to -sip-antispam should also be added some text saying that RFC 5923
must be used, because there is no way to create an additional TLS connection in
the other direction for a subsequent SIP transaction).

On 09/03/2011 12:06 PM, Marc Petit-Huguenin wrote:
> 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:[phone]
> - Node-ID: subjectAltName uniformResourceIdentifier
> reload://0110123456789ABCDEF0123456789ABCDEF/
> - Granted domain: subjectAltName dNSName example.com
> - Granting domain: implicit in routes
> - Route(s): subjectAltName uniformResourceIdentifier
> sip:[e-mail]:371;maddr=10.1.1.1
> 


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

iEYEARECAAYFAk6WGmoACgkQ9RoMZyVa61dW3gCeMcKcsvqK27kk2ZW1mRMPYdep
3ZcAn3EIFv8hlBZop57YIDN7HCOUtixU
=v31B
-----END PGP SIGNATURE-----