WATCH-list: client side authentication in s2n

[colmmacc]

trafficstars

I'm going to start work soon on client-side authentication support in s2n. This is also sometimes called "Mutual auth" and means that TLS clients will be able to present a certificate and s2n (as a server) will verify that the client actually has the private key associated with that certificate.

Thankfully our recent TLS1.3 prep work to re-organize the handshake state machine to be even simpler and more modular should make this less effort.

Historical Challenges with TLS client auth

There have been several challenges with the TLS client authentication security model. We'll need to think carefully about how we can mitigate them.

1. Vulnerabilities in ASN.1 and X.509 parsers . Client certificates are presented as X.509 structures, encoded using ASN.1 Both of these specifications are fairly liberal and loose and there's a history of parsing vulnerabilities in several parsing libraries.
2. Challenges with revoking client credentials. If a client credential is compromised, it is critical that it be rendered in-operative. Traditionally client certificates have used a PKI security model where there is no authoritative list of valid credentials. Instead the parentage of a credential is checked when it is presented ("Was this certified signed by a certificate authority I trust?"). If a credential needs to be invalidated, the mechanism is supposed a "Certificate Revocation List" (CRL) - an unbounded list of certificates that have been revoked. Unfortunately it is common to see configurations without any CRLs at all. More recently the Online Certificate Stapling Protocol (OCSP) allows an authenticator to check "online" if a certificate is still valid by communicating with the issuer. In either case if the issuer itself is compromised, it is more complicated still to change the certificate authority and rotate the credentials used for it cleanly.
3. Client auth is channel-level but often mis-understood. TLS client authentication validates that the client is who they claim to be, but at a "channel" level. It does not strongly authorize the actual actions the client may issue across the channel. For example if a client-side vulnerability allows attackers to insert arbitrary requests on a connection (so called "Request smuggling") these malicious requests may be considered authorized if the authentication of the channel is the sole basis for authorization.
4. Client credentials and actions may be mis-aligned. Exacerbating issue 3 is that a TLS session can be renegotiated with several credentials, and so a single action (for example a GET request) may span several TLS contexts, each using different client credentials. Which is to be applied?

Proposal for s2n v1 client auth model

With the above in mind, I'm proposing to add a slightly different take on mutual auth, called Whitelisted Asymmetric TLS Credential autHentication (WATCH), to s2n as a v1 implementation.

With WATCH an application (and presumably operator) would whitelist every valid client credential explicitly:

s2n_config_add_watch_credential(config, cert, context); 
s2n_config_remove_watch_credential(config, cert);

Here "cert" is the PEM encoded certificate, and "context" is arbitrary contextual data for the certificate (e.g. the user the certificate is for). When configured with credentials, s2n would ask clients to present a certificate. If the certificate presented is in the set of active watch credentials (the "watchlist"), then s2n will accept that client and the "context" data will be available via an API call, e.g.

s2n_connection_get_watch_context(conn, &context); 

applications are free to make AAA inferences based on this context. If the client does not present a certificate, or if the certificate is not present in the configured watch-list, s2n's default behavior will be to terminate the connection. However anonymous access can also be permitted by allowing anonymous watch credentials:

s2n_config_allow_anonymous_watch_credential(config, context); 
s2n_config_deny_anonymous_watch_credential(config);

In all cases s2n will continue to refuse re-negotiations and will support only one TLS context (and hence client certificate) per connection.

Under the hood: no online ASN.1 parsing

Why this style of API? This approach means that under the hood s2n can avoid any online ASN.1 or X.509 parsing from untrusted sources, and it means that credentials must be actively managed with explicit revocation procedures; just like passwords are. In general, there is much better maturity at managing passwords than CRLs.

When credentials are added to the watch list, s2n can perform the X.509/ASN.1 parsing then - to determine the certificate authorities to advertise and the public key of the certificate. These inputs are considered trusted and are not received remotely.

When a TLS client credential is presented, its signature is computed by s2n, but no effort to parse or understand it is taken. s2n searches for a key with the matching signature in its watchlist and and uses this key to verify the client. s2n then sets the context for the connection to the context that was provided when the credential was first added.

Addendum

None of the above precludes adding PKI-based certificate validation or OCSP validation to s2n in the future. But such efforts may need to wait until we have more robust ASN.1/X.509 parsers.

[raycoll]

As described above, we'll simply look up the client-provided cert in our watch list. It's not clear how we verify that the client owns the private key associated with the certificate in the CertificateVerify message. I suppose we could store the cert's public key in the "context" parameter?

[goatgoose]

s2n-tls now supports client auth.

[raycoll]

it would be cool to have a code example in the s2n repo of how to implement a WATCH-list style scheme for applications that want to do an allowlist based client auth scheme as opposed to PKI-based.