doc: Add RFC documents

1 files changed, 687 insertions, 0 deletions

diff --git a/doc/rfc/rfc9257.txt b/doc/rfc/rfc9257.txt
new file mode 100644
index 0000000..348cd80
--- /dev/null
+++ b/doc/rfc/rfc9257.txt
@@ -0,0 +1,687 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Housley
+Request for Comments: 9257                                Vigil Security
+Category: Informational                                       J. Hoyland
+ISSN: 2070-1721                                          Cloudflare Ltd.
+                                                                M. Sethi
+                                                        Aalto University
+                                                              C. A. Wood
+                                                              Cloudflare
+                                                               July 2022
+
+
+        Guidance for External Pre-Shared Key (PSK) Usage in TLS
+
+Abstract
+
+   This document provides usage guidance for external Pre-Shared Keys
+   (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
+   It lists TLS security properties provided by PSKs under certain
+   assumptions, then it demonstrates how violations of these assumptions
+   lead to attacks.  Advice for applications to help meet these
+   assumptions is provided.  This document also discusses PSK use cases
+   and provisioning processes.  Finally, it lists the privacy and
+   security properties that are not provided by TLS 1.3 when external
+   PSKs are used.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9257.
+
+Copyright Notice
+
+   Copyright (c) 2022 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) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions and Definitions
+   3.  Notation
+   4.  PSK Security Properties
+     4.1.  Shared PSKs
+     4.2.  PSK Entropy
+   5.  External PSKs in Practice
+     5.1.  Use Cases
+     5.2.  Provisioning Examples
+     5.3.  Provisioning Constraints
+   6.  Recommendations for External PSK Usage
+     6.1.  Stack Interfaces
+       6.1.1.  PSK Identity Encoding and Comparison
+       6.1.2.  PSK Identity Collisions
+   7.  Privacy Considerations
+   8.  Security Considerations
+   9.  IANA Considerations
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This document provides guidance on the use of external Pre-Shared
+   Keys (PSKs) in Transport Layer Security (TLS) 1.3 [RFC8446].  This
+   guidance also applies to Datagram TLS (DTLS) 1.3 [RFC9147] and
+   Compact TLS 1.3 [CTLS].  For readability, this document uses the term
+   "TLS" to refer to all such versions.
+
+   External PSKs are symmetric secret keys provided to the TLS protocol
+   implementation as external inputs.  External PSKs are provisioned out
+   of band.
+
+   This document lists TLS security properties provided by PSKs under
+   certain assumptions and demonstrates how violations of these
+   assumptions lead to attacks.  This document discusses PSK use cases,
+   provisioning processes, and TLS stack implementation support in the
+   context of these assumptions.  This document also provides advice for
+   applications in various use cases to help meet these assumptions.
+
+   There are many resources that provide guidance for password
+   generation and verification aimed towards improving security.
+   However, there is no such equivalent for external PSKs in TLS.  This
+   document aims to reduce that gap.
+
+2.  Conventions and Definitions
+
+   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.
+
+3.  Notation
+
+   For purposes of this document, a "logical node" is a computing
+   presence that other parties can interact with via the TLS protocol.
+   A logical node could potentially be realized with multiple physical
+   instances operating under common administrative control, e.g., a
+   server farm.  An "endpoint" is a client or server participating in a
+   connection.
+
+4.  PSK Security Properties
+
+   The use of a previously established PSK allows TLS nodes to
+   authenticate the endpoint identities.  It also offers other benefits,
+   including resistance to attacks in the presence of quantum computers;
+   see Section 4.2 for related discussion.  However, these keys do not
+   provide privacy protection of endpoint identities, nor do they
+   provide non-repudiation (one endpoint in a connection can deny the
+   conversation); see Section 7 for related discussion.
+
+   PSK authentication security implicitly assumes one fundamental
+   property: each PSK is known to exactly one client and one server and
+   they never switch roles.  If this assumption is violated, then the
+   security properties of TLS are severely weakened as discussed below.
+
+4.1.  Shared PSKs
+
+   As discussed in Section 5.1, to demonstrate their attack, [AASS19]
+   describes scenarios where multiple clients or multiple servers share
+   a PSK.  If this is done naively by having all members share a common
+   key, then TLS authenticates only group membership, and the security
+   of the overall system is inherently rather brittle.  There are a
+   number of obvious weaknesses here:
+
+   1.  Any group member can impersonate any other group member.
+
+   2.  If a PSK is combined with the result of a fresh ephemeral key
+       exchange, then compromise of a group member that knows the
+       resulting shared secret will enable the attacker to passively
+       read traffic (and actively modify it).
+
+   3.  If a PSK is not combined with the result of a fresh ephemeral key
+       exchange, then compromise of any group member allows the attacker
+       to passively read all traffic (and actively modify it), including
+       past traffic.
+
+   Additionally, a malicious non-member can reroute handshakes between
+   honest group members to connect them in unintended ways, as described
+   below.  Note that a partial mitigation for this class of attack is
+   available: each group member includes the Server Name Indication
+   (SNI) extension [RFC6066] and terminates the connection on mismatch
+   between the presented SNI value and the receiving member's known
+   identity.  See [Selfie] for details.
+
+   To illustrate the rerouting attack, consider three peers, A, B, and
+   C, who all know the PSK.  The attack proceeds as follows:
+
+   1.  A sends a ClientHello to B.
+
+   2.  The attacker intercepts the message and redirects it to C.
+
+   3.  C responds with a second flight (ServerHello, ...) to A.
+
+   4.  A sends a Finished message to B.  A has completed the handshake,
+       ostensibly with B.
+
+   5.  The attacker redirects the Finished message to C.  C has
+       completed the handshake with A.
+
+   In this attack, peer authentication is not provided.  Also, if C
+   supports a weaker set of ciphersuites than B, cryptographic algorithm
+   downgrade attacks might be possible.  This rerouting is a type of
+   identity misbinding attack [Krawczyk] [Sethi].  Selfie attack
+   [Selfie] is a special case of the rerouting attack against a group
+   member that can act as both a TLS server and a client.  In the Selfie
+   attack, a malicious non-member reroutes a connection from the client
+   to the server on the same endpoint.
+
+   Finally, in addition to these weaknesses, sharing a PSK across nodes
+   may negatively affect deployments.  For example, revocation of
+   individual group members is not possible without establishing a new
+   PSK for all of the members that have not been revoked.
+
+4.2.  PSK Entropy
+
+   Entropy properties of external PSKs may also affect TLS security
+   properties.  For example, if a high-entropy PSK is used, then PSK-
+   only key establishment modes provide expected security properties for
+   TLS, including establishment of the same session keys between peers,
+   secrecy of session keys, peer authentication, and downgrade
+   protection.  See Appendix E.1 of [RFC8446] for an explanation of
+   these properties.  However, these modes lack forward security.
+   Forward security may be achieved by using a PSK-DH mode or by using
+   PSKs with short lifetimes.
+
+   In contrast, if a low-entropy PSK is used, then PSK-only key
+   establishment modes are subject to passive exhaustive search attacks,
+   which will reveal the traffic keys.  PSK-DH modes are subject to
+   active attacks in which the attacker impersonates one side.  The
+   exhaustive search phase of these attacks can be mounted offline if
+   the attacker captures a single handshake using the PSK, but those
+   attacks will not lead to compromise of the traffic keys for that
+   connection because those also depend on the Diffie-Hellman (DH)
+   exchange.  Low-entropy keys are only secure against active attack if
+   a Password-Authenticated Key Exchange (PAKE) is used with TLS.  At
+   the time of writing, the Crypto Forum Research Group (CFRG) is
+   working on specifying recommended PAKEs (see [CPACE] and [OPAQUE] for
+   the symmetric and asymmetric cases, respectively).
+
+5.  External PSKs in Practice
+
+   PSK ciphersuites were first specified for TLS in 2005.  PSKs are now
+   an integral part of the TLS 1.3 specification [RFC8446].  TLS 1.3
+   also uses PSKs for session resumption.  It distinguishes these
+   resumption PSKs from external PSKs that have been provisioned out of
+   band.  This section describes known use cases and provisioning
+   processes for external PSKs with TLS.
+
+5.1.  Use Cases
+
+   This section lists some example use cases where pairwise external
+   PSKs (i.e., external PSKs that are shared between only one server and
+   one client) have been used for authentication in TLS.  There was no
+   attempt to prioritize the examples in any particular order.
+
+   *  Device-to-device communication with out-of-band synchronized keys.
+      PSKs provisioned out of band for communicating with known
+      identities, wherein the identity to use is discovered via a
+      different online protocol.
+
+   *  Intra-data-center communication.  Machine-to-machine communication
+      within a single data center or Point of Presence (PoP) may use
+      externally provisioned PSKs; this is primarily for the purpose of
+      supporting TLS connections with early data.  See Section 8 for
+      considerations when using early data with external PSKs.
+
+   *  Certificateless server-to-server communication.  Machine-to-
+      machine communication may use externally provisioned PSKs; this is
+      primarily for the purposes of establishing TLS connections without
+      requiring the overhead of provisioning and managing PKI
+      certificates.
+
+   *  Internet of Things (IoT) and devices with limited computational
+      capabilities.  [RFC7925] defines TLS and DTLS profiles for
+      resource-constrained devices and suggests the use of PSK
+      ciphersuites for compliant devices.  The Open Mobile Alliance
+      Lightweight Machine-to-Machine (LwM2M) Technical Specification
+      [LwM2M] states that LwM2M servers MUST support the PSK mode of
+      DTLS.
+
+   *  Securing RADIUS [RFC2865] with TLS.  PSK ciphersuites are optional
+      for this use case, as specified in [RFC6614].
+
+   *  3GPP server-to-user equipment authentication.  The Generic
+      Authentication Architecture (GAA) defined by 3GPP mentions that
+      TLS PSK ciphersuites can be used between server and user equipment
+      for authentication [GAA].
+
+   *  Smart Cards.  The German electronic Identity (eID) card supports
+      authentication of a card holder to online services with TLS PSK
+      [SmartCard].
+
+   *  Quantum resistance.  Some deployments may use PSKs (or combine
+      them with certificate-based authentication as described in
+      [RFC8773]) because of the protection they provide against quantum
+      computers.
+
+   There are also use cases where PSKs are shared between more than two
+   entities.  Some examples below (as noted by Akhmetzyanova, et al.
+   [AASS19]):
+
+   *  Group chats.  In this use case, group participants may be
+      provisioned an external PSK out of band for establishing
+      authenticated connections with other members of the group.
+
+   *  IoT and devices with limited computational capabilities.  Many PSK
+      provisioning examples are possible in this use case.  For example,
+      in a given setting, IoT devices may all share the same PSK and use
+      it to communicate with a central server (one key for n devices),
+      have their own key for communicating with a central server (n keys
+      for n devices), or have pairwise keys for communicating with each
+      other (n^2 keys for n devices).
+
+5.2.  Provisioning Examples
+
+   The exact provisioning process depends on the system requirements and
+   threat model.  Whenever possible, avoid sharing a PSK between nodes;
+   however, sharing a PSK among several nodes is sometimes unavoidable.
+   When PSK sharing happens, other accommodations SHOULD be used as
+   discussed in Section 6.
+
+   Examples of PSK provisioning processes are included below.
+
+   *  Many industrial protocols assume that PSKs are distributed and
+      assigned manually via one of the following approaches: (1) typing
+      the PSK into the devices or (2) using a trust-on-first-use (TOFU)
+      approach with a device completely unprotected before the first
+      login took place.  Many devices have a very limited UI.  For
+      example, they may only have a numeric keypad or even fewer
+      buttons.  When the TOFU approach is not suitable, entering the key
+      would require typing it on a constrained UI.
+
+   *  Some devices provision PSKs via an out-of-band, cloud-based
+      syncing protocol.
+
+   *  Some secrets may be baked into hardware or software device
+      components.  Moreover, when this is done at manufacturing time,
+      secrets may be printed on labels or included in a Bill of
+      Materials for ease of scanning or import.
+
+5.3.  Provisioning Constraints
+
+   PSK provisioning systems are often constrained in application-
+   specific ways.  For example, although one goal of provisioning is to
+   ensure that each pair of nodes has a unique key pair, some systems do
+   not want to distribute pairwise shared keys to achieve this.  As
+   another example, some systems require the provisioning process to
+   embed application-specific information in either PSKs or their
+   identities.  Identities may sometimes need to be routable, as is
+   currently under discussion for [EAP-TLS-PSK].
+
+6.  Recommendations for External PSK Usage
+
+   Recommended requirements for applications using external PSKs are as
+   follows:
+
+   1.  Each PSK SHOULD be derived from at least 128 bits of entropy,
+       MUST be at least 128 bits long, and SHOULD be combined with an
+       ephemeral key exchange, e.g., by using the "psk_dhe_ke" Pre-
+       Shared Key Exchange Mode in TLS 1.3 for forward secrecy.  As
+       discussed in Section 4, low-entropy PSKs (i.e., those derived
+       from less than 128 bits of entropy) are subject to attack and
+       SHOULD be avoided.  If only low-entropy keys are available, then
+       key establishment mechanisms such as PAKE that mitigate the risk
+       of offline dictionary attacks SHOULD be employed.  Note that no
+       such mechanisms have yet been standardized, and further that
+       these mechanisms will not necessarily follow the same
+       architecture as the process for incorporating external PSKs
+       described in [RFC9258].
+
+   2.  Unless other accommodations are made to mitigate the risks of
+       PSKs known to a group, each PSK MUST be restricted in its use to
+       at most two logical nodes: one logical node in a TLS client role
+       and one logical node in a TLS server role.  (The two logical
+       nodes MAY be the same, in different roles.)  Two acceptable
+       accommodations are described in [RFC9258]: (1) exchanging client
+       and server identifiers over the TLS connection after the
+       handshake and (2) incorporating identifiers for both the client
+       and the server into the context string for an external PSK
+       importer.
+
+   3.  Nodes SHOULD use external PSK importers [RFC9258] when
+       configuring PSKs for a client-server pair when applicable.
+       Importers make provisioning external PSKs easier and less error-
+       prone by deriving a unique, imported PSK from the external PSK
+       for each key derivation function a node supports.  See the
+       Security Considerations of [RFC9258] for more information.
+
+   4.  Where possible, the main PSK (that which is fed into the
+       importer) SHOULD be deleted after the imported keys have been
+       generated.  This prevents an attacker from bootstrapping a
+       compromise of one node into the ability to attack connections
+       between any node; otherwise, the attacker can recover the main
+       key and then re-run the importer itself.
+
+6.1.  Stack Interfaces
+
+   Most major TLS implementations support external PSKs.  Stacks
+   supporting external PSKs provide interfaces that applications may use
+   when configuring PSKs for individual connections.  Details about some
+   existing stacks at the time of writing are below.
+
+   *  OpenSSL and BoringSSL: Applications can specify support for
+      external PSKs via distinct ciphersuites in TLS 1.2 and below.
+      Also, they can then configure callbacks that are invoked for PSK
+      selection during the handshake.  These callbacks must provide a
+      PSK identity and key.  The exact format of the callback depends on
+      the negotiated TLS protocol version, with new callback functions
+      added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support.
+      The PSK length is validated to be between 1-256 bytes (inclusive).
+      The PSK identity may be up to 128 bytes long.
+
+   *  mbedTLS: Client applications configure PSKs before creating a
+      connection by providing the PSK identity and value inline.
+      Servers must implement callbacks similar to that of OpenSSL.  Both
+      PSK identity and key lengths may be between 1-16 bytes long
+      (inclusive).
+
+   *  gnuTLS: Applications configure PSK values as either raw byte
+      strings or hexadecimal strings.  The PSK identity and key size are
+      not validated.
+
+   *  wolfSSL: Applications configure PSKs with callbacks similar to
+      OpenSSL.
+
+6.1.1.  PSK Identity Encoding and Comparison
+
+   Section 5.1 of [RFC4279] mandates that the PSK identity should be
+   first converted to a character string and then encoded to octets
+   using UTF-8.  This was done to avoid interoperability problems
+   (especially when the identity is configured by human users).  On the
+   other hand, [RFC7925] advises implementations against assuming any
+   structured format for PSK identities and recommends byte-by-byte
+   comparison for any operation.  When PSK identities are configured
+   manually, it is important to be aware that visually identical strings
+   may, in fact, differ due to encoding issues.
+
+   TLS 1.3 [RFC8446] follows the same practice of specifying the PSK
+   identity as a sequence of opaque bytes (shown as opaque
+   identity<1..2^16-1> in the specification) that thus is compared on a
+   byte-by-byte basis.  [RFC8446] also requires that the PSK identities
+   are at least 1 byte and at the most 65535 bytes in length.  Although
+   [RFC8446] does not place strict requirements on the format of PSK
+   identities, note that the format of PSK identities can vary depending
+   on the deployment:
+
+   *  The PSK identity MAY be a user-configured string when used in
+      protocols like Extensible Authentication Protocol (EAP) [RFC3748].
+      For example, gnuTLS treats PSK identities as usernames.
+
+   *  PSK identities MAY have a domain name suffix for roaming and
+      federation.  In applications and settings where the domain name
+      suffix is privacy sensitive, this practice is NOT RECOMMENDED.
+
+   *  Deployments should take care that the length of the PSK identity
+      is sufficient to avoid collisions.
+
+6.1.2.  PSK Identity Collisions
+
+   It is possible, though unlikely, that an external PSK identity may
+   clash with a resumption PSK identity.  The TLS stack implementation
+   and sequencing of PSK callbacks influences the application's behavior
+   when identity collisions occur.  When a server receives a PSK
+   identity in a TLS 1.3 ClientHello, some TLS stacks execute the
+   application's registered callback function before checking the
+   stack's internal session resumption cache.  This means that if a PSK
+   identity collision occurs, the application's external PSK usage will
+   typically take precedence over the internal session resumption path.
+
+   Because resumption PSK identities are assigned by the TLS stack
+   implementation, it is RECOMMENDED that these identifiers be assigned
+   in a manner that lets resumption PSKs be distinguished from external
+   PSKs to avoid concerns with collisions altogether.
+
+7.  Privacy Considerations
+
+   PSK privacy properties are orthogonal to security properties
+   described in Section 4.  TLS does little to keep PSK identity
+   information private.  For example, an adversary learns information
+   about the external PSK or its identifier by virtue of the identifier
+   appearing in cleartext in a ClientHello.  As a result, a passive
+   adversary can link two or more connections together that use the same
+   external PSK on the wire.  Depending on the PSK identity, a passive
+   attacker may also be able to identify the device, person, or
+   enterprise running the TLS client or TLS server.  An active attacker
+   can also use the PSK identity to suppress handshakes or application
+   data from a specific device by blocking, delaying, or rate-limiting
+   traffic.  Techniques for mitigating these risks require further
+   analysis and are out of scope for this document.
+
+   In addition to linkability in the network, external PSKs are
+   intrinsically linkable by PSK receivers.  Specifically, servers can
+   link successive connections that use the same external PSK together.
+   Preventing this type of linkability is out of scope.
+
+8.  Security Considerations
+
+   Security considerations are provided throughout this document.  It
+   bears repeating that there are concerns related to the use of
+   external PSKs regarding proper identification of TLS 1.3 endpoints
+   and additional risks when external PSKs are known to a group.
+
+   It is NOT RECOMMENDED to share the same PSK between more than one
+   client and server.  However, as discussed in Section 5.1, there are
+   application scenarios that may rely on sharing the same PSK among
+   multiple nodes.  [RFC9258] helps in mitigating rerouting and Selfie-
+   style reflection attacks when the PSK is shared among multiple nodes.
+   This is achieved by correctly using the node identifiers in the
+   ImportedIdentity.context construct specified in [RFC9258].  One
+   solution would be for each endpoint to select one globally unique
+   identifier to use in all PSK handshakes.  The unique identifier can,
+   for example, be one of its Media Access Control (MAC) addresses, a
+   32-byte random number, or its Universally Unique IDentifier (UUID)
+   [RFC4122].  Note that such persistent, global identifiers have
+   privacy implications; see Section 7.
+
+   Each endpoint SHOULD know the identifier of the other endpoint with
+   which it wants to connect and SHOULD compare it with the other
+   endpoint's identifier used in ImportedIdentity.context.  However, it
+   is important to remember that endpoints sharing the same group PSK
+   can always impersonate each other.
+
+   Considerations for external PSK usage extend beyond proper
+   identification.  When early data is used with an external PSK, the
+   random value in the ClientHello is the only source of entropy that
+   contributes to key diversity between sessions.  As a result, when an
+   external PSK is used more than one time, the random number source on
+   the client has a significant role in the protection of the early
+   data.
+
+9.  IANA Considerations
+
+   This document has no IANA actions.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC9258]  Benjamin, D. and C. A. Wood, "Importing External Pre-
+              Shared Keys (PSKs) for TLS 1.3", RFC 9258,
+              DOI 10.17487/RFC9258, July 2022,
+              <https://www.rfc-editor.org/info/rfc9258>.
+
+10.2.  Informative References
+
+   [AASS19]   Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A.
+              Sokolov, "Continuing to reflect on TLS 1.3 with external
+              PSK", April 2019, <https://eprint.iacr.org/2019/421.pdf>.
+
+   [CPACE]    Abdalla, M., Haase, B., and J. Hesse, "CPace, a balanced
+              composable PAKE", Work in Progress, Internet-Draft, draft-
+              irtf-cfrg-cpace-06, 24 July 2022,
+              <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
+              cpace-06>.
+
+   [CTLS]     Rescorla, E., Barnes, R., Tschofenig, H., and B. M.
+              Schwartz, "Compact TLS 1.3", Work in Progress, Internet-
+              Draft, draft-ietf-tls-ctls-06, 9 July 2022,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
+              ctls-06>.
+
+   [EAP-TLS-PSK]
+              Mattsson, J. P., Sethi, M., Aura, T., and O. Friel, "EAP-
+              TLS with PSK Authentication (EAP-TLS-PSK)", Work in
+              Progress, Internet-Draft, draft-mattsson-emu-eap-tls-psk-
+              00, 9 March 2020, <https://datatracker.ietf.org/doc/html/
+              draft-mattsson-emu-eap-tls-psk-00>.
+
+   [GAA]      ETSI, "Digital cellular telecommunications system (Phase
+              2+); Universal Mobile Telecommunications System (UMTS);
+              LTE; 3G Security; Generic Authentication Architecture
+              (GAA); System description", version 12.0.0, ETSI TR 133
+              919, October 2014, <https://www.etsi.org/deliver/
+              etsi_tr/133900_133999/133919/12.00.00_60/
+              tr_133919v120000p.pdf>.
+
+   [Krawczyk] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
+              Authenticated Diffie-Hellman and Its Use in the IKE
+              Protocols", DOI 10.1007/978-3-540-45146-4_24, 2003,
+              <https://link.springer.com/content/
+              pdf/10.1007/978-3-540-45146-4_24.pdf>.
+
+   [LwM2M]    Open Mobile Alliance, "Lightweight Machine to Machine
+              Technical Specification", version 1.0, February 2017,
+              <http://www.openmobilealliance.org/release/LightweightM2M/
+              V1_0-20170208-A/OMA-TS-LightweightM2M-
+              V1_0-20170208-A.pdf>.
+
+   [OPAQUE]   Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The
+              OPAQUE Asymmetric PAKE Protocol", Work in Progress,
+              Internet-Draft, draft-irtf-cfrg-opaque-09, 6 July 2022,
+              <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
+              opaque-09>.
+
+   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+              "Remote Authentication Dial In User Service (RADIUS)",
+              RFC 2865, DOI 10.17487/RFC2865, June 2000,
+              <https://www.rfc-editor.org/info/rfc2865>.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
+              <https://www.rfc-editor.org/info/rfc3748>.
+
+   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
+              Unique IDentifier (UUID) URN Namespace", RFC 4122,
+              DOI 10.17487/RFC4122, July 2005,
+              <https://www.rfc-editor.org/info/rfc4122>.
+
+   [RFC4279]  Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
+              Ciphersuites for Transport Layer Security (TLS)",
+              RFC 4279, DOI 10.17487/RFC4279, December 2005,
+              <https://www.rfc-editor.org/info/rfc4279>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <https://www.rfc-editor.org/info/rfc6066>.
+
+   [RFC6614]  Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
+              "Transport Layer Security (TLS) Encryption for RADIUS",
+              RFC 6614, DOI 10.17487/RFC6614, May 2012,
+              <https://www.rfc-editor.org/info/rfc6614>.
+
+   [RFC7925]  Tschofenig, H., Ed. and T. Fossati, "Transport Layer
+              Security (TLS) / Datagram Transport Layer Security (DTLS)
+              Profiles for the Internet of Things", RFC 7925,
+              DOI 10.17487/RFC7925, July 2016,
+              <https://www.rfc-editor.org/info/rfc7925>.
+
+   [RFC8773]  Housley, R., "TLS 1.3 Extension for Certificate-Based
+              Authentication with an External Pre-Shared Key", RFC 8773,
+              DOI 10.17487/RFC8773, March 2020,
+              <https://www.rfc-editor.org/info/rfc8773>.
+
+   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
+              Datagram Transport Layer Security (DTLS) Protocol Version
+              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
+              <https://www.rfc-editor.org/info/rfc9147>.
+
+   [Selfie]   Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3
+              with PSK", DOI 10.1007/s00145-021-09387-y, May 2021,
+              <https://eprint.iacr.org/2019/347.pdf>.
+
+   [Sethi]    Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks
+              on Secure Device Pairing and Bootstrapping",
+              DOI 10.1145/3321705.3329813, May 2019,
+              <https://arxiv.org/pdf/1902.07550>.
+
+   [SmartCard]
+              Bundesamt für Sicherheit in der Informationstechnik,
+              "Technical Guideline TR-03112-7 eCard-API-Framework -
+              Protocols", version 1.1.5, April 2015, <https://www.bsi.bu
+              nd.de/SharedDocs/Downloads/DE/BSI/Publikationen/
+              TechnischeRichtlinien/TR03112/TR-
+              03112-api_teil7.pdf?__blob=publicationFile&v=1>.
+
+Acknowledgements
+
+   This document is the output of the TLS External PSK Design Team,
+   comprised of the following members: Benjamin Beurdouche, Björn Haase,
+   Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland,
+   Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel,
+   and Russ Housley.
+
+   This document was improved by high-quality reviews by Ben Kaduk and
+   John Preuß Mattsson.
+
+Authors' Addresses
+
+   Russ Housley
+   Vigil Security, LLC
+   Email: housley@vigilsec.com
+
+
+   Jonathan Hoyland
+   Cloudflare Ltd.
+   Email: jonathan.hoyland@gmail.com
+
+
+   Mohit Sethi
+   Aalto University
+   Email: mohit@iki.fi
+
+
+   Christopher A. Wood
+   Cloudflare
+   Email: caw@heapingbits.net