Draft: draft-ietf-tls-exported-authenticator

Commentary: A couple things may have snuck in that are only editorial from a certain point of view ... 
 This LGTM , pending one question around normative language .
This document provides a way to authenticate one party of a Transport
Layer Security (TLS) connection to its peer using a Certificate
message after the session has been established.  This allows both the
client and server to prove ownership of additional identities at any
time after the handshake has completed.  This proof of authentication
can be exported and transmitted out-of-band from one party to be
validated by its peer.
This document provides a way to authenticate one party of a Transport
Layer Security (TLS) connection to its peer using a CertificateVerify
message after the session has been established.  This allows both the
client and server to prove ownership of additional identities at any
time after the handshake has completed.  This proof of authentication
can be exported and transmitted out-of-band from one party to be
validated by its peer.
Endpoints can authenticate after a connection is established, in
response to events in a higher-layer protocol, as well as
integrating more context.
Endpoints can authenticate after a connection is established, in
response to events in a higher-layer protocol, as well as
integrating more context (such as context from the application).
TLS (or DTLS) version 1.2 RFC5246 RFC6347. or later are REQUIRED to
implement the mechanisms described in this document.
TLS (or DTLS) version 1.2 RFC5246 RFC6347 or later are REQUIRED to
implement the mechanisms described in this document.
The authenticator request is a structured message that can be created
by either party of a TLS connection using data exported from that
connection.  It can be transmitted to the other party of the TLS
connection at the application layer.  The application layer protocol
used to send the authenticator request SHOULD use a secure with
equivalent security to TLS, such as QUIC QUIC-TLS, as its as its
underlying transport to keep the request confidential.  The
application MAY use the existing TLS connection to transport the
authenticator.
The authenticator request is a structured message that can be created
by either party of a TLS connection using data exported from that
connection.  It can be transmitted to the other party of the TLS
connection at the application layer.  The application layer protocol
used to send the authenticator request SHOULD use a secure protocol
with equivalent security to TLS, such as QUIC QUIC-TLS, as its as its
underlying transport to keep the request confidential.  The
application MAY use the existing TLS connection to transport the
authenticator.
An authenticator request message can be constructed by either the
client or the server.  Server-generated authenticator requests use
the CertificateRequest message from Section 4.3.2 of TLS13.  Client-
generated authenticator requests use a new message, called the
ClientCertificateRequest, which uses the same structure as
CertificateRequest.  These messages structures are used even if the
TLS connection protocol is TLS 1.2.
The CertificateRequest and ClientCertificateRequest messages are used
to define the parameters in a request for an authenticator.  These
are encoded as TLS handshake messages, including length and type
fields.  They do not include any TLS record layer framing and are not
encrypted with a handshake key.
An authenticator request message can be constructed by either the
client or the server.  Server-generated authenticator requests use
the CertificateRequest message from Section 4.3.2 of TLS13.  Client-
generated authenticator requests use a new message, called the
ClientCertificateRequest, which uses the same structure as
CertificateRequest.  (Note that the latter is not a request for a
client certificate, but rather a certificate request generated by the
client.)  These messages structures are used even if the TLS
connection protocol is TLS 1.2.
The CertificateRequest and ClientCertificateRequest messages are used
to define the parameters in a request for an authenticator.  These
are encoded as TLS handshake messages, including length and type
fields.  They do not include any TLS record layer framing and are not
encrypted with a handshake or application-data key.
The uniqueness requirements of the certificate_request_context apply
only to CertificateRequest and ClientCertificateRequest messages that
are used as part of authenticator requests.  There is no impact if
the value of a certificate_request_context used in an authenticator
request matches the value of a certificate_request_context in the
handshake or in a post-handshake message.
The uniqueness requirements of the certificate_request_context apply
only to CertificateRequest and ClientCertificateRequest messages that
are used as part of authenticator requests, but do apply across
CertificateRequest and ClientCertificateRequest messages.  A
certificate_request_context value used in a ClientCertificateRequest
cannot be used in an authenticator CertificateRequest on the same
connection, and vice versa.  There is no impact if the value of a
certificate_request_context used in an authenticator request matches
the value of a certificate_request_context in the handshake or in a
post-handshake message.
The authenticator is a structured message that can be exported from
either party of a TLS connection.  It can be transmitted to the other
party of the TLS connection at the application layer.  The
application layer protocol used to send the authenticator SHOULD use
a secure with equivalent security to TLS, such as QUIC QUIC-TLS, as
its as its underlying transport to keep the authenticator
confidential.  The application MAY use the existing TLS connection to
transport the authenticator.
The authenticator is a structured message that can be exported from
either party of a TLS connection.  It can be transmitted to the other
party of the TLS connection at the application layer.  The
application layer protocol used to send the authenticator SHOULD use
a secure protocol with equivalent security to TLS, such as QUIC QUIC-
TLS, as its as its underlying transport to keep the authenticator
confidential.  The application MAY use the existing TLS connection to
transport the authenticator.
The context_value used for the exporter is empty (zero length) for
all four values.  There is no need to include additional context
information at this stage since the application-supplied context is
included in the authenticator itself.  The length of the exported
value is equal to the length of the output of the hash function
selected in TLS for the pseudorandom function (PRF).  Exported
authenticators cannot be used with cipher suites that do not use the
TLS PRF and have not defined a hash function for this purpose.  This
hash is referred to as the authenticator hash.
To avoid key synchronization attacks, Exported Authenticators MUST
NOT be generated or accepted on TLS 1.2 connections that did not
negotiate the extended master secret RFC7627.
An authenticator is formed from the concatenation of TLS 1.3 TLS13
Certificate, CertificateVerify, and Finished messages.  These
messages are encoded as TLS handshake messages, including length and
type fields.
If the peer creating the certificate_request_context has already
created or correctly validated an authenticator with the same value,
then no authenticator should be constructed.  If there is no
authenticator request, the extensions are chosen from those presented
in the TLS handshake's ClientHello.  Only servers can provide an
authenticator without a corresponding request.
ClientHello extensions are used to determine permissible extensions
in the Certificate message.  This follows the general model for
extensions in TLS in which extensions can only be included as part of
a Certificate message if they were previously sent as part of a
CertificateRequest message or ClientHello message, to ensure that the
recipient will be able to process such extensions.
The context_value used for the exporter is empty (zero length) for
all four values.  There is no need to include additional context
information at this stage since the application-supplied context is
included in the authenticator itself.  The length of the exported
value is equal to the length of the output of the hash function
associated with the selected cipher suite (for TLS 1.3) or the hash
function used for the pseudorandom function (PRF) (for TLS 1.2).
Exported authenticators cannot be used with TLS 1.2 cipher suites
that do not use the TLS PRF and with TLS 1.3 cipher suites that do
not have an associated hash function.  This hash is referred to as
the authenticator hash.
To avoid key synchronization attacks, Exported Authenticators MUST
NOT be generated or accepted on TLS 1.2 connections that did not
negotiate the extended master secret extension RFC7627.
An authenticator is formed from the concatenation of TLS 1.3 TLS13
Certificate, CertificateVerify, and Finished messages.  These
messages are encoded as TLS handshake messages, including length and
type fields.  They do not include any TLS record layer framing and
are not encrypted with a handshake or application-data key.
If the peer populating the certificate_request_context field in an
authenticator's Certificate message has already created or correctly
validated an authenticator with the same value, then no authenticator
should be constructed.  If there is no authenticator request, the
extensions are chosen from those presented in the TLS handshake's
ClientHello.  Only servers can provide an authenticator without a
corresponding request.
ClientHello extensions are used to determine permissible extensions
in the server's unsolicited Certificate message in order to follow
the general model for extensions in TLS in which extensions can only
be included as part of a Certificate message if they were previously
sent as part of a CertificateRequest message or ClientHello message.
This ensures that the recipient will be able to process such
extensions.
If an authenticator request was provided, the Certificate message
MUST contain only extensions present in the authenticator request.
Otherwise, the Certificate message MUST contain only extensions
present in the TLS handshake.  Unrecognized extensions in the
authenticator request MUST be ignored.
If an authenticator request was provided, the Certificate message
MUST contain only extensions present in the authenticator request.
Otherwise, the Certificate message MUST contain only extensions
present in the TLS ClientHello.  Unrecognized extensions in the
authenticator request MUST be ignored.
If an authenticator request is present, the signature algorithm MUST
be chosen from one of the signature schemes present in the
authenticator request.  Otherwise, with spontaneous server
authentication, the signature algorithm used MUST be chosen from the
"signature_algorithms" sent by the peer in the ClientHello of the TLS
handshake.  If there are no available signature algorithms, then no
authenticator should be constructed.
If an authenticator request is present, the signature algorithm MUST
be chosen from one of the signature schemes present in the
"signature_algorithms" extensino of the authenticator request.
Otherwise, with spontaneous server authentication, the signature
algorithm used MUST be chosen from the "signature_algorithms" sent by
the peer in the ClientHello of the TLS handshake.  If there are no
available signature algorithms, then no authenticator should be
constructed.
An authenticator is valid if the CertificateVerify message is
correctly constructed given the authenticator request (if used) and
the Finished message matches the expected value.  When validating an
authenticator, a constant-time comparison SHOULD be used.
An authenticator is valid if the CertificateVerify message is
correctly constructed given the authenticator request (if used) and
the Finished message matches the expected value.  When validating an
authenticator, constant-time comparisons SHOULD be used for signature
and MAC validation.
If, given an authenticator request, the endpoint does not have an
appropriate identity or does not want to return one, it constructs an
authenticated refusal called an empty authenticator.  This is a
Finished message sent without a Certificate or CertificateVerify.
This message is an HMAC over the hashed authenticator transcript with
a Certificate message containing no CertificateEntries and the
CertificateVerify message omitted.  The HMAC is computed using the
authenticator hash, using the Finished MAC Key as a key.  This
message is encoded as a TLS handshake message, including length and
type field.  It does not include TLS record layer framing.
If, given an authenticator request, the endpoint does not have an
appropriate identity or does not want to return one, it constructs an
authenticated refusal called an empty authenticator.  This is a
Finished message sent without a Certificate or CertificateVerify.
This message is an HMAC over the hashed authenticator transcript with
a Certificate message containing no CertificateEntries and the
CertificateVerify message omitted.  The HMAC is computed using the
authenticator hash, using the Finished MAC Key as a key.  This
message is encoded as a TLS handshake message, including length and
type field.  It does not include TLS record layer framing and is not
encrypted with a handshake or application-data key.
When validating an authenticator, a constant-time comparison should
be used.
When validating an authenticator, constant-time comparison should be
used.
IANA is requested to update the entry for server_name(0) in the
registry for ExtensionType (defined in TLS13) by replacing the value
in the "TLS 1.3" column with the value "CH, EE, CR" and this document
in the "Reference" column.
IANA is requested to update the entry for server_name(0) in the
registry for ExtensionType (defined in TLS13) by replacing the value
in the "TLS 1.3" column with the value "CH, EE, CR" and adding this
document in the "Reference" column.