RFC 8773

TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key

📅 published March 2020, from ietf

RFC 8773 💖 TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key

okay bestie, this one is a TLS 1.3 extension, and it's giving "keep the certificate AND bring your own secret" 🔐✨

  • Author: R. Housley, from Vigil Security 🎀
  • Category: Experimental 🧪 (not a Standards Track thing, it's for trying stuff out and gathering deployment experience)
  • Date: March 2020 📅
  • ISSN: 2070-1721
  • Obsoletes / Updates: the title block doesn't list any RFCs this one obsoletes or updates, so it stands on its own 🦋

Abstract ✨

okay so the big idea is this: this doc defines a TLS 1.3 extension that lets a server prove who it is using both a certificate and an external pre-shared key (PSK) 🫶

Status of This Memo 📝

so this document is NOT an Internet Standards Track spec. it's been published so people can look at it, implement it experimentally, and evaluate it 🧪

it defines an Experimental Protocol for the Internet community 🌈 it's a product of the IETF, it represents the consensus of the IETF community, and it got public review and was approved for publication by the IESG. not every IESG-approved doc is a candidate for any level of Internet Standard, which is lowkey a whole thing, so check Section 2 of RFC 7841 if you want the deets 🙈

for the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8773 💜

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were in effect on the date of publication. please actually read these, bestie, because they explain your rights and restrictions for this doc 📜 any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💅

Table of Contents 🗂️

1.  Introduction
2.  Terminology
3.  Motivation and Design Rationale
4.  Extension Overview
5.  Certificate with External PSK Extension
  5.1.  Companion Extensions
  5.2.  Authentication
  5.3.  Keying Material
6.  IANA Considerations
7.  Security Considerations
8.  Privacy Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Author's Address

1. Introduction 🌸

okay so TLS 1.3 [RFC8446] handshakes give you two mutually exclusive ways for a server to authenticate. option one: the server shows a signature certificate and makes a valid digital signature, which proves it has the matching private key 🔑 option two: the server proves it has a pre-shared key (PSK) that was set up in a previous handshake. a PSK set up that way is called a resumption PSK. any PSK set up some other way is called an external PSK 🧚

this doc adds a TLS 1.3 extension that lets certificate-based server auth get combined with an external PSK as an input to the TLS 1.3 key schedule. so you get both at once, which is so iconic 👑

several implementors wanted more experience with this before making a Standards Track RFC, so this spec is being published as an Experimental RFC. that way people can build interoperable implementations and collect deployment and operational experience 🦋

2. Terminology 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💅 so the caps are doing the heavy lifting here, iykyk

3. Motivation and Design Rationale 🔮

okay the scary part first 😭 a large-scale quantum computer would be a serious problem for the crypto algorithms we use everywhere today, including the digital signature algorithms that authenticate the server in the TLS 1.3 handshake. it's an open question whether we can actually build one, and if we can, nobody knows when. but if one does get invented, a lot of these algorithms and the security protocols built on them would become vulnerable 💀

the TLS 1.3 handshake uses key agreement and digital signature algorithms that a large-scale quantum computer could break [TRANSITION]. the key agreement algorithms include Diffie-Hellman (DH) [DH1976] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. the digital signature algorithms include RSA [RFC8017] and the Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS186]. so an adversary who stores a TLS 1.3 handshake exchange today could decrypt the encrypted communications later, once a large-scale quantum computer shows up 😱

so in the near term, this doc describes an extension that protects today's communications from a future large-scale quantum computer. it does this by adding a strong external PSK as an input to the TLS 1.3 key schedule, while keeping the authentication that the existing certificate and digital signature mechanisms already give you 🛡️✨

4. Extension Overview 🧚‍♀️

this section is a quick overview of the "tls_cert_with_extern_psk" extension 🎀

the client includes the "tls_cert_with_extern_psk" extension in the ClientHello message. the "tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share", "psk_key_exchange_modes", and "pre_shared_key" extensions. the client MAY also find it useful to include the "supported_groups" extension. since the "tls_cert_with_extern_psk" extension is only meant for initial handshakes, it MUST NOT be sent alongside the "early_data" extension. these extensions are all described in Section 4.2 of [RFC8446], which also requires the "pre_shared_key" extension to be the last extension in the ClientHello message 📌

if the client includes both the "tls_cert_with_extern_psk" extension and the "early_data" extension, then the server MUST terminate the connection with an "illegal_parameter" alert. 🚨 yikes, don't do that one

if the server is willing to use one of the external PSKs listed in the "pre_shared_key" extension and do certificate-based authentication, then the server includes the "tls_cert_with_extern_psk" extension in the ServerHello message. the "tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share" and "pre_shared_key" extensions. if none of the external PSKs in the client's list is acceptable to the server, then the "tls_cert_with_extern_psk" extension gets left out of the ServerHello message 🥀

when the "tls_cert_with_extern_psk" extension is successfully negotiated, the TLS 1.3 key schedule includes both the selected external PSK and the (EC)DHE shared secret value. (EC)DHE just means Diffie-Hellman over either finite fields or elliptic curves 🧮 so the Early Secret, Handshake Secret, and Master Secret all depend on the value of the selected external PSK. of course, the Early Secret does NOT depend on the (EC)DHE shared secret 🙃

server authentication, and optional client authentication, depend on being able to make a signature that validates against the public key in their certificates. the authentication processing is not changed in any way by the selected external PSK 🔐 the vibes stay the same, the PSK just joins the key schedule

each external PSK is tied to a single hash algorithm, which is required by Section 4.2.11 of [RFC8446]. the hash algorithm MUST be set when the PSK is established, and the default is SHA-256 💜

5. Certificate with External PSK Extension 🎀

this section specifies the "tls_cert_with_extern_psk" extension. it MAY appear in the ClientHello message and the ServerHello message. it MUST NOT appear in any other messages. the "tls_cert_with_extern_psk" extension MUST NOT appear in the ServerHello message unless it also appeared in the preceding ClientHello message. if an implementation recognizes the "tls_cert_with_extern_psk" extension and receives it in any other message, then the implementation MUST abort the handshake with an "illegal_parameter" alert 🚫

the general extension mechanisms let clients and servers negotiate specific extensions. clients ask servers for extended functionality using the extensions field in the ClientHello message. if the server responds with a HelloRetryRequest message, then the client sends another ClientHello as described in Section 4.1.2 of [RFC8446], including the same "tls_cert_with_extern_psk" extension as the original ClientHello message, or else it aborts the handshake 🔁

lots of server extensions ride along in the EncryptedExtensions message, but the "tls_cert_with_extern_psk" extension is carried in the ServerHello message instead. successful negotiation of this extension affects the key used for encryption, so it can't go in the EncryptedExtensions message 🔒 that's why the "tls_cert_with_extern_psk" extension only shows up in the ServerHello message if the server recognizes it AND has one of the external PSKs the client offered in the "pre_shared_key" extension of the ClientHello 🧚

the Extension structure is defined in [RFC8446]. it's repeated here for convenience 🎀

struct {
    ExtensionType extension_type;
    opaque extension_data<0..2^16-1>;
} Extension;

the "extension_type" identifies the particular extension type, and the "extension_data" holds information specific to that extension type 💖

this document specifies the "tls_cert_with_extern_psk" extension, which adds one new type to ExtensionType:

enum {
    tls_cert_with_extern_psk(33), (65535)
} ExtensionType;

the "tls_cert_with_extern_psk" extension matters when the client and server both have an external PSK in common that can be used as an input to the TLS 1.3 key schedule 🔑 it's basically just a flag that says "use the external PSK in the key schedule," and it has this syntax:

struct {
    select (Handshake.msg_type) {
        case client_hello: Empty;
        case server_hello: Empty;
    };
} CertWithExternPSK;

5.1. Companion Extensions 🎀

Okay bestie, Section 4 has the full list of extensions that have to tag along with tls_cert_with_extern_psk ✨ Most of them are totally unaffected by this spec, so honestly you can relax 💅 This section is for the ones that need a little extra thought 🧚

First up is psk_key_exchange_modes, which is defined in Section 4.2.9 of [RFC8446] 🌸 This one limits which PSKs can be used, both the ones offered in this ClientHello and the ones the server might hand out later in a NewSessionTicket. So when psk_key_exchange_modes shows up in the ClientHello, clients MUST include psk_dhe_ke mode. Clients MAY also include psk_ke mode if they want to support a NewSessionTicket later 🦋 When psk_key_exchange_modes shows up in the ServerHello, servers MUST select psk_dhe_ke mode for the initial handshake. For later handshakes that bring in the resumption PSK from that first handshake, servers MUST select a key exchange mode the client listed 🫶

Next, the pre_shared_key extension, defined in Section 4.2.11 of [RFC8446] 💜 I'm copying the syntax below so you don't have to flip back. All of the listed PSKs MUST be external PSKs. If a resumption PSK is listed along with tls_cert_with_extern_psk, the server MUST abort the handshake with an illegal_parameter alert. Not allowed, periodt 🙅‍♀️

struct {
    opaque identity<1..2^16-1>;
    uint32 obfuscated_ticket_age;
} PskIdentity;

opaque PskBinderEntry<32..255>;

struct {
    PskIdentity identities<7..2^16-1>;
    PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;

struct {
    select (Handshake.msg_type) {
        case client_hello: OfferedPsks;
        case server_hello: uint16 selected_identity;
    };
} PreSharedKeyExtension;

So OfferedPsks is basically the client's shopping list: the PSK identities plus their binders, for every external PSK the client is willing to use with the server 🛍️

The identities are the external PSK identities the client is willing to negotiate with the server 🍓 Each external PSK has an identity that both the client and server know. Other parties might know those identities too, which is fine. The binder validation (more on that below) is what confirms that the client and server really share the same key for that identity 🔑

Now obfuscated_ticket_age is a total non-factor for external PSKs 🙈 As Section 4.2.11 of [RFC8446] says, clients SHOULD set this value to 0, and servers MUST ignore the value. Easy 💅

The binders are a series of HMAC [RFC2104] values, one for each external PSK the client offers, in the same order as the identities list 🌈 Each HMAC is computed with a binder_key, which is derived from the external PSK, plus a partial transcript of the current handshake. The binder_key derivation is in Section 7.1 of [RFC8446] ✨ The partial transcript covers a partial ClientHello, up to and including the PreSharedKeyExtension.identities field, as described in Section 4.2.11.2 of [RFC8446] 🧾

Last one, selected_identity. This holds the index of the external PSK identity the server picked from the client's list 👑 As described in Section 4.2.11 of [RFC8446], the server MUST validate the binder that goes with the selected external PSK. If the binder doesn't validate, the server MUST abort the handshake with an illegal_parameter alert. No binder, no handshake, no excuses 😭

5.2. Authentication 🔐

When tls_cert_with_extern_psk is successfully negotiated, server authentication depends on being able to generate a signature that validates against the public key in the server's certificate 💖 That happens when the server sends the Certificate and CertificateVerify messages, as described in Sections 4.4.2 and 4.4.3 of [RFC8446]. Cute and simple 🎀

Here's the plot twist: TLS 1.3 doesn't let the server send a CertificateRequest message when a PSK is being used 🙃 This extension removes that restriction, so certificate-based authentication works for both the client and the server 🫶 If the client wants certificate-based client authentication, it does that by sending the Certificate and CertificateVerify messages, as described in Sections 4.4.2 and 4.4.3 of [RFC8446] 🦋

5.3. Keying Material 🗝️

Section 7.1 of [RFC8446] is where the TLS 1.3 key schedule lives 📜 Successfully negotiating tls_cert_with_extern_psk means the key schedule processing has to include both the external PSK and the (EC)DHE shared secret value. Both ingredients, every time 🍳

Now, if the client and server have different values for the selected external PSK identifier, they'll compute different values for every entry in the key schedule 😬 That leads to the client aborting the handshake with a decrypt_error alert. Mismatched keys, mismatched everything 💀

6. IANA Considerations 📚

IANA has updated the "TLS ExtensionType Values" registry [IANA] 🗂️ The new entry is "tls_cert_with_extern_psk" with a value of 33, and the messages it may appear in are listed as "CH, SH". Registered and official 🌸

7. Security Considerations 🛡️

Okay, bestie, this part is serious, so I'm going full focus mode 🔥 Pay attention to every bit of it 👀

The Security Considerations in [RFC8446] remain relevant 💜

TLS 1.3 [RFC8446] does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when tls_cert_with_extern_psk is offered by the client and accepted by the server. However, TLS 1.3 does not allow an external PSK to be used the same way as a resumption PSK, and this extension doesn't change those restrictions 🙅‍♀️ So a certificate MUST NOT be used with a resumption PSK. Hard stop 🛑

Implementations must protect the external pre-shared key (PSK) 🔒 Compromise of the external PSK will make the encrypted session content vulnerable to the future development of a large-scale quantum computer 😱 The generation, distribution, and management of external PSKs is out of scope for this specification, though, so that's on you 🧾

Implementers should not transmit the same content on a connection protected with an external PSK and on a connection that isn't. Doing so may let an eavesdropper correlate the connections, which would make the content vulnerable to the future invention of a large-scale quantum computer 👀

Implementations must generate external PSKs with a secure key-management technique, such as pseudorandom generation of the key or derivation of the key from one or more other secure keys 🔐 Using inadequate pseudorandom number generators (PRNGs) to generate external PSKs can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the external PSKs and search the resulting small set of possibilities, rather than brute-force searching the whole key space 💀 Generating quality random numbers is genuinely hard. [RFC4086] offers important guidance in this area 📖

If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT be the sole basis for authentication 🚫 The reasoning is explained in Section 4.2 of [K2016]. When this extension is used, authentication is based on certificates, not the external PSK 🎀

In this extension, the external PSK preserves confidentiality if the (EC)DH key agreement is ever broken by cryptanalysis or by the future invention of a large-scale quantum computer ✨ As long as the attacker doesn't know the PSK and the key derivation algorithm remains unbroken, the attacker can't derive the session secrets, even if they can compute the (EC)DH shared secret 🛡️ Should the attacker be able to compute the (EC)DH shared secret, the forward-secrecy advantages usually tied to ephemeral (EC)DH keys stop being relevant. The ephemeral private keys used during a TLS session are destroyed at the end of that session, so the attacker can't access them later. But those private keys would still be recoverable because of the break in the algorithm 😭 A more general notion of "secrecy after key material is destroyed" would still be achievable with external PSKs, though, as long as they're managed so they're destroyed once they're no longer needed, and as long as the algorithms using the external PSKs remain quantum-safe 🌈

TLS 1.3 key derivation uses the HMAC-based Key Derivation Function (HKDF) algorithm, which depends on the HMAC [RFC2104] construction and a hash function 🧪 This extension provides the desired protection for the session secrets, as long as HMAC with the selected hash function is a pseudorandom function (PRF) [GGM1986] 💖

This specification does not require that the external PSK be known only by the client and server 🫂 The external PSK may be known to a group. Since authentication depends on the public key in a certificate, other parties knowing the external PSK doesn't enable impersonation. Since confidentiality depends on the shared secret from (EC)DH, other parties knowing the external PSK doesn't enable eavesdropping. However, group members can record each other's traffic and then decrypt it if they ever gain access to a large-scale quantum computer 😬 Also, when many parties know the external PSK, there are many chances for an attacker to steal it. Once an attacker has the external PSK, they can decrypt stored traffic if they ever gain access to a large-scale quantum computer, the same way a legitimate group member could 🙈

TLS 1.3 [RFC8446] takes a conservative approach to PSKs: they're bound to a specific hash function and KDF 🧐 By contrast, TLS 1.2 [RFC5246] allows PSKs to be used with any hash function and the TLS 1.2 PRF. So the safest approach is to use a PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. Given one PSK, you can derive one PSK for exclusive use with TLS 1.2 and another for exclusive use with TLS 1.3, using the mechanism specified in [IMPORT] 🔁

TLS 1.3 [RFC8446] has received careful security analysis, and the following informal reasoning shows that adding this extension doesn't introduce any security defects 🧠 This extension requires certificates for authentication, but the processing of certificates is unchanged by it. The extension places an external PSK in the key schedule as part of computing the Early Secret. Without this extension, in the initial handshake, the Early Secret is computed as:

Early Secret = HKDF-Extract(0, 0)

With this extension, the Early Secret is computed as:

Early Secret = HKDF-Extract(External PSK, 0)

Any entropy the external PSK contributes can only make the Early Secret better. The External PSK cannot make it worse 💅 For these two reasons, TLS 1.3 keeps meeting its security goals when this extension is used 🌸✨

8. Privacy Considerations 🫣

Okay so, [RFC8446] has an appendix (Appendix E.6) all about identity-exposure attacks on PSKs, and bestie, it is still 100% relevant to everything in this section 📚✨

This extension uses external PSKs so it can hold up better against attackers who might get their hands on a large-scale quantum computer someday 🔮🛡️. It is always paired with the pre_shared_key extension, which sends the PSK identities in plaintext inside the ClientHello message 👀. So if someone is just passively watching traffic, they can see those PSK identities, and that helps them track the people using this extension. Not me being dramatic, it's a real privacy leak 😭🫠

9. References 📖

9.1. Normative References

9.2. Informative References 🧠

Acknowledgments 🫶

Huge thank-yous to Liliya Akhmetzyanova, Roman Danyliw, Christian Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja Kühlewind, Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee for reviewing this and leaving comments 💖. Their work made this doc so much better ✨

Author's Address 💌

Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America

Email: housley@vigilsec.com

📦 where this page comes from