Draft: draft-ietf-tls-external-psk-importer

Commentary: This is mainly editorial , so there should be nothing surprising here . Please let me if that 's not the case ! It also includes clarifying text per recommendation raised during WGLC . cc 
 From   : We should note the latter is a requirement from Section 4.2.11 of RFC8446 . Let 's also fix the typo " import external keys for TLS ... "
Paragraph (version A):
This document describes an interface for importing external PSK (Pre-
Shared Key) into TLS 1.3.
Paragraph (version B):
This document describes an interface for importing external Pre-
Shared Keys (PSKs) into TLS 1.3.
Paragraph (version A):
To mitigate these problems, external PSKs can be bound to a specific
KDF and hash function when used in TLS 1.3, even if they are
associated with a different hash function when provisioned.  This
document specifies an interface by which external PSKs may be
imported for use in a TLS 1.3 connection to achieve this goal.  In
particular, it describes how KDF-bound PSKs can be differentiated by
the target (D)TLS protocol version and KDF for which the PSK will be
used.  This produces a set of candidate PSKs, each of which are bound
to a specific target protocol and KDF.  This expands what would
normally have been a single PSK identity into a set of PSK
identities.
Paragraph (version B):
To mitigate these problems, this document specifies a PSK Importer
interface by which external PSKs may be imported and subsequently
bound to a specific KDF and hash function for use in TLS 1.3.  In
particular, it describes a mechanism for differentiating external
PSKs by the target KDF, (D)TLS protocol version, and an optional
context string.  This process yields a set of candidate PSKs, each of
which are bound to a target KDF and protocol.  This expands what
would normally have been a single PSK and identity into a set of PSKs
and identities.
Paragraph (version A):
Key importers mirror the concept of key exporters in TLS in that they
diversify a key based on some contextual information before use in a
connection.  In contrast to key exporters, wherein differentiation is
done via an explicit label and context string, the key importer
defined herein diversifies external one PSK into one or more PSKs for
use via a target protocol, KDF identifier, and optional context
string.  Additionally, the resulting PSK binder key is modified with
a new derivation label to prevent confusion with non-imported PSKs.
Paragraph (version A):
Imported keys do not require negotiation for use, as a client and
server will not agree upon identities if not imported correctly.
Endpoints may incrementally deploy PSK importer support by offering
non-imported keys for TLS versions prior to TLS 1.3.  Non-imported
and imported PSKs are distinct since their identities are different
on the wire.  See rollout for more details.
Paragraph (version A):
Clients which import external keys TLS MUST NOT use these keys for
any other purpose.  Moreover, each external PSK MUST be associated
with at most one hash function.
Paragraph (version B):
The PSK Importer interface mirrors that of the TLS Exporters
interface in that it diversifies a key based on some contextual
information.  In contrast to the Exporters interface, wherein
differentiation is done via an explicit label and context string, the
PSK Importer interface defined herein takes an external PSK and
identity and "imports" it into TLS, creating a set of "derived" PSKs
and identities.  Each of these derived PSKs are bound a target
protocol, KDF identifier, and optional context string.  Additionally,
the resulting PSK binder keys are modified with a new derivation
label to prevent confusion with non-imported PSKs.
Paragraph (version B):
Imported keys do not require negotiation for use since a client and
server will not agree upon identities if imported incorrectly.
Endpoints may incrementally deploy PSK Importer support by offering
non-imported keys for TLS versions prior to TLS 1.3.  Non-imported
and imported PSKs are distinct since their identities are different
on the wire.  See rollout for more details.
Paragraph (version B):
Clients which import external keys MUST NOT use either the external
keys or the derived keys for any other purpose.  Moreover, each
external PSK MUST be associated with at most one hash function, as
per the rules in Section 4.2.11 from RFC8446.  See security-
considerations for more discussion.
Paragraph (version A):
A key importer diversifies an input EPSK into one or more PSKs
advertised on the wire via a target protocol, KDF identifier, and
optional context string.  Additionally, the resulting PSK binder key
is modified with a new derivation label to prevent confusion with
non-imported PSKs.  This section describes the diversification
mechanism and binder key computation change.
Paragraph (version B):
This section describes the PSK Importer interface and its underlying
diversification mechanism and binder key computation modification.
Paragraph (version A):
L is corresponds to the KDF output length of
ImportedIdentity.target_kdf as defined in IANA.  For hash-based KDFs,
such as HKDF_SHA256(0x0001), this is the length of the hash function
output, i.e., 32 octets.  This is required for the IPSK to be of
length suitable for supported ciphersuites.
Paragraph (version A):
The identity of 'ipskx' as sent on the wire is ImportedIdentity,
i.e., the serialized content of ImportedIdentity is used as the
content of PskIdentity.identity in the PSK extension.
Paragraph (version B):
L corresponds to the KDF output length of ImportedIdentity.target_kdf
as defined in IANA.  For hash-based KDFs, such as
HKDF_SHA256(0x0001), this is the length of the hash function output,
i.e., 32 octets.  This is required for the IPSK to be of length
suitable for supported ciphersuites.
Paragraph (version B):
The identity of "ipskx" as sent on the wire is ImportedIdentity,
i.e., the serialized content of ImportedIdentity is used as the
content of PskIdentity.identity in the PSK extension.  The
corresponding TLS 1.3 binder key is "ipskx".
Paragraph (version A):
The hash function used for HKDF RFC5869 is that which is associated
with the EPSK.  It is not the hash function associated with
ImportedIdentity.target_kdf.  If no hash function is specified,
SHA-256 MUST be used.  Diversifying EPSK by
ImportedIdentity.target_kdf ensures that an IPSK is only used as
input keying material to at most one KDF, thus satisfying the
requirements in RFC8446.
Paragraph (version A):
Endpoints generate a compatible ipskx for each target ciphersuite
they offer.  For example, importing a key for TLS_AES_128_GCM_SHA256
and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256
and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256
and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key
is necessary.
Paragraph (version A):
The resulting IPSK base key 'ipskx' is then used as the binder key in
TLS 1.3 with identity ImportedIdentity.  With knowledge of the
supported KDFs, one may import PSKs before the start of a connection.
Paragraph (version A):
EPSKs may be imported for early data use if they are bound to
protocol settings and configurations that would otherwise be required
for early data with normal (ticket-based PSK) resumption.  Minimally,
that means ALPN, QUIC transport settings, etc., must be provisioned
alongside these EPSKs.
Paragraph (version A):
This new label differentiates non-imported and imported external
PSKs.  Specifically, a client and server will negotiate use of an
external PSK if and only if (a) both endpoints import the PSK or (b)
neither endpoint imports the PSK.  As "binder_key" is a leaf key,
changing its computation does not affect any other key.
Paragraph (version B):
The hash function used for HKDF RFC5869 is that which is associated
with the EPSK.  It is not the hash function associated with
ImportedIdentity.target_kdf.  If no hash function is specified,
SHA-256 MUST be used.  Diversifying EPSK by
ImportedIdentity.target_kdf ensures that an IPSK is only used as
input keying material to at most one KDF, thus satisfying the
requirements in RFC8446.  See security-considerations for more
details.
Paragraph (version B):
Endpoints SHOULD generate a compatible "ipskx" for each target
ciphersuite they offer.  For example, importing a key for
TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two
PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast,
if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are
supported, only one derived key is necessary.
Paragraph (version B):
EPSKs may be imported before the start of a connection if the target
KDFs, protocols, and context string(s) are known a priori.  EPSKs may
also be imported for early data use if they are bound to protocol
settings and configurations that would otherwise be required for
early data with normal (ticket-based PSK) resumption.  Minimally,
that means ALPN, QUIC transport parameters (if used for QUIC), etc.,
must be provisioned alongside these EPSKs.
Paragraph (version B):
This new label ensures a client and server will negotiate use of an
external PSK if and only if (a) both endpoints import the PSK or (b)
neither endpoint imports the PSK.  As "binder_key" is a leaf key,
changing its computation does not affect any other key.
Paragraph (version A):
Recall that TLS 1.2 permits computing the TLS PRF with any hash
algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and
underlying HMAC hash algorithm) as TLS 1.3 with importers.  However,
critically, the derived PSK will not be the same since the importer
differentiates the PSK via the identity, target protocol, and target
KDF.  Thus, PSKs imported for TLS 1.3 are distinct from those used in
TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this
does not preclude endpoints from using non-imported PSKs for TLS 1.2.
Indeed, this is necessary for incremental deployment.
Paragraph (version A):
The Key Importer security goals can be roughly stated as follows:
avoid PSK re-use across KDFs while properly authenticating endpoints.
When modeled as computational extractors, KDFs assume that input
keying material (IKM) is sampled from some "source" probability
distribution and that any two IKM values are chosen independently of
each other Kraw10.  This source-independence requirement implies that
the same IKM value cannot be used for two different KDFs.
Paragraph (version B):
Recall that TLS 1.2 permits computing the TLS PRF with any hash
algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and
underlying HMAC hash algorithm) as TLS 1.3 with importers.  However,
critically, the derived PSK will not be the same since the importer
differentiates the PSK via the identity and target KDF and protocol.
Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
1.2, and thereby avoid cross-protocol collisions.  Note that this
does not preclude endpoints from using non-imported PSKs for TLS 1.2.
Indeed, this is necessary for incremental deployment.
Paragraph (version B):
The PSK Importer security goals can be roughly stated as follows:
avoid PSK re-use across KDFs while properly authenticating endpoints.
When modeled as computational extractors, KDFs assume that input
keying material (IKM) is sampled from some "source" probability
distribution and that any two IKM values are chosen independently of
each other Kraw10.  This source-independence requirement implies that
the same IKM value cannot be used for two different KDFs.
Paragraph (version A):
PSK-based authentication is functionally equivalent to session
resumption in that a connection uses existing key material to
authenticate both endpoints.  Following the work of BAA15, this is a
form of compound authentication.  Loosely speaking, compound
authentication is the property that an execution of multiple
authentication protocols, wherein at least one is uncompromised,
jointly authenticates all protocols.  Authenticating with an
externally provisioned PSK, therefore, should ideally authenticate
both the TLS connection and the external provision process.
Typically, the external provision process produces a PSK and
corresponding context from which the PSK was derived and in which it
should be used.  We refer to an external PSK without such context as
"context free".
Paragraph (version A):
Externally provisioned PSKs imported into TLS achieve compound
authentication of the provision step(s) and connection.
Paragraph (version A):
Imported PSKs are used as IKM for two different KDFs.
Paragraph (version B):
PSK-based authentication is functionally equivalent to session
resumption in that a connection uses existing key material to
authenticate both endpoints.  Following the work of BAA15, this is a
form of compound authentication.  Loosely speaking, compound
authentication is the property that an execution of multiple
authentication protocols, wherein at least one is uncompromised,
jointly authenticates all protocols.  Authenticating with an
externally provisioned PSK, therefore, should ideally authenticate
both the TLS connection and the external provisioning process.
Typically, the external provision process produces a PSK and
corresponding context from which the PSK was derived and in which it
should be used.  If available, this is used as the
ImportedIdentity.context value.  We refer to an external PSK without
such context as "context-free".
Paragraph (version B):
Externally provisioned PSKs imported into a TLS connection achieve
compound authentication of the provisioning process and
connection.
Paragraph (version B):
Imported PSKs are not used as IKM for two different KDFs.