Feature: RawPublicKey authentication in TLS 1.3 (RFC 7250)

[reneme]

Pull Request Dependencies

• FIX: Some minor TLS bugs found along the way #3792

Description

This adds support for authentication with "raw public keys" to the TLS 1.3 implementation. This is useful for applications that want to avoid or don't need the complexity of a PKI. Such applications bear the responsibility to manage the trust-relationship of the public key pairs they use.

The commits build the feature from the ground up, starting with the public API, new TLS extensions, integration into Certificate/CertificateVerify messages, and the actual implementation in client and server. I hope this aids in reviewing this patch.

New user-facing APIs

• TLS::Policy
  • ::accepted_client_certificate_types() / ::accepted_server_certificate_types() determines what trust credentials are supported for client and server authentication respectively. By default, this returns X.509. Applications that want to use raw public keys need to override or configure this accordingly.
• Credentials_Manager
  • ::find_raw_public_key() is called when usage of raw public keys was negotiated to obtain a public key from the downstream application. This is the very same concept as the existing ::find_cert_chain()
  • ::private_key_for(Public_Key&) is called to obtain the associated private key. It is an overload of the existing ::private_key_for(X509_Certificate&) method.
• TLS::Callbacks
  • ::tls_verify_raw_public_key() must be implemented by the downstream application to establish trust in a raw public key received from a peer. In contrast to tls_verify_cert_chain() this does not provide a best-effort default implementation; instead it rejects all raw public keys.
• TLS::Channel
  • ::peer_raw_public_key() returns the raw public key used to authenticate this Channel's active session (or nullptr) if no raw public key was used.
• TLS::Session_Summary
  • ::peer_raw_public_key() returns the raw public key used to authenticate the session (or nullptr) if no raw public key was used.

Test Examples

GnuTLS Client connects to Botan Server

Start a Botan Server

Create a policy.txt:

allow_tls13 = true
allow_tls12 = false
accepted_server_certificate_types = RawPublicKey

... and run the server:

./botan keygen --algo=RSA > rsa_priv.pem
./botan pkcs8 --pub-out rsa_priv.pem > rsa_pub.pem
./botan tls_server rsa_pub.pem rsa_priv.pem --port=5555 --policy=policy.txt

Connect with a GnuTLS Client

gnutls-cli --port=5555 --priority="NORMAL:+CTYPE-RAWPK" --insecure --print-cert localhost

Botan Client connects to GnuTLS Server

Start a gnutls server

./botan keygen --algo=RSA > rsa_priv.pem
./botan pkcs8 --pub-out rsa_priv.pem > rsa_pub.pem
gnutls-serv --rawpkfile=rsa_pubkey.pem --rawpkkeyfile=rsa_privkey.pem --disable-client-cert --priority="NORMAL:+CTYPE-RAWPK" --port=5555

Connect with a Botan client

Create a policy.txt:

allow_tls13 = true
allow_tls12 = false
accepted_server_certificate_types = RawPublicKey

... and run the client:

# without explicitly trusting the Raw Public Key
./botan tls_client --port=5555 --policy=policy.txt localhost

# with a trusted public key fingerprint
./botan fingerprint --algo=SHA-256 rsa_pub.pem
# -> copy the fingerprint string into the placeholder below:
./botan tls_client --port=5555 --debug --policy=rawpk_policy.txt --trusted-pubkey-sha256="ba:ad:ca:fe:..." localhost

[reneme]

This should be ready for a review now.

Two things:

1. That's the second feature I implemented for TLS 1.3 only (after RecordSizeLimit). I feel that is something we should track somewhere.
2. It feels inconsistent that we use std::shared_ptr or std::unique_ptr for asymmetric keys. Having those classes explicitly allow/prohibit to be copied and/or moved would be more modern, in my opinion (like X509_Certificate). That might be something to consider for Botan 4.0 when splitting the Public_Key and Private_Key base classes. Where would I note that, so that we don't forget it?

[coveralls]

coverage: 92.061% (-0.008%) from 92.069%
when pulling ba11760 on Rohde-Schwarz:feature/rfc7250
into 201cfe5 on randombit:master.

[FAlbertDev]

Good job. Looks very clean! I only left some comments and suggestions.

Do we also want to update doc/cli.rst?

[FAlbertDev]

Is there some check that prevents servers from asking for a RawPublicKey in the server's ClientCertTypeExtension even if the client does not list it in its initial ClientCertTypeExtension? If not, a malicious server could force raw public key client authentication even if the client's policy forbids it (of course, find_raw_public_key must be implemented for this scenario to work).

[reneme]

No there wasn't! Very important catch. Thanks.

[reneme]

Thanks for the reviews. I had a quick skim-through. Lot's of valuable remarks, I believe. I'm hoping to get back to this on Monday, but it might slip to Thursday.

[reneme]

@FAlbertDev @lieser I addressed your comments. Thanks a lot. You've both found very relevant issues.