Re: [VIPR] An alternative to the VIPR ticket

["Peterson, Jon" <[e-mail]>]

On the last design call, I expressed a number of reservations about this change, but the main one was that it was insufficiently motivated. For my part, anyway, I was curious to understand what the problem was with the existing mechanism that you believed this solved - once we understood the problem, we could understand the potential design space to solve it. I had thought we'd left the call understanding that you were going to explain the problem; instead, you're pretty much defending a solution here without reference to what the problem is. 

I've taken a look at the sketch of your proposal below, but it's a bit too high level for me to really understand its properties. I will say that if your argument is:

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

I have to disagree. 5922 cites the relevant text in 3261:
      Each side of the connection SHOULD verify and inspect the
      certificate of the other, noting the domain name that appears in
      the certificate for comparison with the header fields of SIP
      messages.
Now by today's standards, that text is somewhat vague, but back when we wrote that the idea was basically that you compare the domain in the cert (typically the CN or SubjectAltName) used in TLS with the supposed identity of the sender of a request over that transport connection (typically given in the From header field value). That works when the cert has been issued by an authority capable of ascertaining who owns domain names. 5922 introduces qualifications to this in order to support cases where a virtual hosting service has a certificate with multiple names, for example, but it isn't really chipping away at the basic operation. ViPR today, as you cite, requires that same reference integrity between the granted-to field of the ticket and the domain in the cert used in TLS. Again, the idea here is that the granted-to has to correspond with a cert issued by an authority who actually verifies ownership of domain names. Thus, purely on the basis of capturing a ticket with a granted-to of example.com, you cannot impersonate example.com unless you also control a cert issued for that domain by a CA, and incidentally a CA trusted by the target ViPR domain. If you are arguing for a case where a ViPR domain that is not in a position to certify who owns what domain names is issuing certificates that are used for TLS, then you are changing how certificate usage in SIP is commonly understood.

>From what I can gather about your proposal, I suspect you underestimate the complexity of acting as a CA, enrolling peers in the CA and enabling them to use those credentials properly - what it means for two entities that have no pre-existing relationship to suddenly treat each other as trust anchors. I furthermore suspect that TLS operations would not be optimal in this sort of model. Is the antispam property something that is best bound to the transport or to a single SIP request? The use cases, ultimately, answer that for us: consider two large ViPR domains that want to exchange traffic - should they have to establish a new TLS connection for each called number, or should they be able to send signaling for many calls over a single TLS connection? Are there cases where the hop-by-hop property of TLS weakens the utility of the mechanism? Are there environments we want ViPR to be useful where TLS is not available? 

Jon Peterson (as an individual)
NeuStar, Inc.

On Oct 12, 2011, at 3:53 PM, Marc Petit-Huguenin wrote:

> -----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-----
> _______________________________________________
> VIPR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vipr