Draft: draft-ietf-tls-exported-authenticator

Commentary: Addressed by 
 Several really long lines might benefit from rewrapping , but only small nits on the changes here .
This document describes a mechanism in Transport Layer Security (TLS)
to provide an exportable proof of ownership of a certificate that can
be transmitted out of band and verified by the other party.
This document provides a way to authenticate one party of a Transport
Layer Security (TLS) communication to another using a certificate
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 the other party.
Endpoints that are authoritative for multiple identities - but do
not have a single certificate that includes all of the identities
- can authenticate with those identities over a single connection.
This document intends to replace much of the functionality of
renegotiation in previous versions of TLS.  It has the advantages
over renegotiation of not requiring additional on-the-wire changes
during a connection.  For simplicity, only TLS 1.2 and later are
supported.
Post-handshake authentication is defined in TLS 1.3, but it has the
disadvantage of requiring additional state to be stored in the TLS
state machine and it composes poorly with multiplexed connection
protocols like HTTP/2 RFC7540.  It is also only available for client
authentication.  This mechanism is intended to be used as part of a
replacement for post-handshake authentication in applications.
This document describes a mechanism in Transport Layer Security (TLS)
to provide an exportable proof of ownership of a certificate that can
be transmitted out of band and verified by the peer.
This document provides a way to authenticate one party of a Transport
Layer Security (TLS) communication to its peer using a certificate
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 that are authoritative for multiple identities - but do
not have a single certificate that includes all of the identities
- can authenticate additional identities over a single connection.
Versions of TLS prior to TLS 1.3 used renegotiation as a way to
enable post-handshake client authentication given an existing TLS
connection.  The mechanism described in this document may be used to
replace the post-handshake authentication functionality provided by
renegotiation.  Unlike renegotiation, exported Authenticator-based
post-handshake authentication does not require any changes at the TLS
layer.
Post-handshake authentication is defined in TLS 1.3, but it has the
disadvantage of requiring additional state to be stored as part of
the TLS state machine.  Furthermore, the authentication boundaries of
TLS 1.3 post-handshake authentication align with TLS record
boundaries, which are often not aligned with the authentication
boundaries of the higher-layer protocol.  For example, multiplexed
connection protocols like HTTP/2 RFC7540 do not have a notion of
which TLS record a given message is a part of.
For simplicity, the mechanisms described in this document require a
TLS version 1.2 or later.
The authenticator request 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 TLS as its underlying transport to keep the
request confidential.
An authenticator request message can be constructed by either the
client or the server.  This authenticator request uses the
CertificateRequest message structure from Section 4.3.2 of TLS13.
This message does not include the TLS record layer and is therefore
not encrypted with a handshake key.
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 SHOULD use TLS as its underlying
transport to keep the request confidential.
An authenticator request message can be constructed by either the
client or the server.  This authenticator request uses the
CertificateRequest message structure from Section 4.3.2 of TLS13.
This message does not include any TLS framing and is not encrypted
with a handshake key.
An opaque string which identifies the certificate request and
which will be echoed in the authenticator message.  A
certificate_request_context value MUST be unique for each
authenticator request within the scope of a connection (preventing
replay and context confusion).  The certificate_request_context
SHOULD be chosen to be unpredictable to the peer (e.g., by
randomly generating it) in order to prevent an attacker who has
temporary access to the peer's private key from pre-computing
valid authenticators.  This value is unrelated to the
certificate_request_context used in post-handshake authentication
and collisions do not need to be avoided.
An opaque string which identifies the certificate request and
which will be echoed in the authenticator message.  A
certificate_request_context value MUST be unique for each
authenticator request within the scope of a connection (preventing
replay and context confusion).  The certificate_request_context
SHOULD be chosen to be unpredictable to the peer (e.g., by
randomly generating it) in order to prevent an attacker who has
temporary access to the peer's private key from pre-computing
valid authenticators.
An authenticator message can be constructed by either the client or
the server given an established TLS connection, a certificate, and a
corresponding private key.  Clients MUST NOT send an authenticator
without a preceding authenticator request; for servers an
authenticator request is optional.  The authenticator uses the
message structures from Section 4.4 of TLS13, but different
parameters.  These messages do not include the TLS record layer and
are therefore not encrypted with a handshake key.
An authenticator message can be constructed by either the client or
the server given an established TLS connection, a certificate, and a
corresponding private key.  Clients MUST NOT send an authenticator
without a preceding authenticator request; for servers an
authenticator request is optional.  For authenticators that do not
correspond to authenticator requests, the certificate_request_context
is chosen by the server.
The context_value used for the exporter is empty (zero length) for
all four values.  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).  Cipher suites that do not use the TLS
PRF MUST define a hash function that can be used for this purpose or
they cannot be used.  For TLS 1.3 symmetric cipher suites, the hash
algorithm used with HKDF is used.
If the connection is TLS 1.2, the master secret MUST have been
computed with the extended master secret RFC7627 to avoid key
synchronization attacks.
If an authenticator request is present, the extensions used to guide
the construction of these messages are taken from the authenticator
request.  Unrecognized extensions MUST be ignored.  If the
certificate_request_context from the authenticator request has
already been used in the connection, then no authenticator should be
constructed.  If there is no authenticator request, the extensions
are chosen from the TLS handshake.  Only servers can provide an
authenticator without a corresponding request.  In such cases,
ClientHello extensions are used to determine permissible extensions
in the Certificate message.
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.
Exported Authenticators MUST NOT be generated or accepted on
connections not using the extended master secret RFC7627 extension,
to avoid key synchronization attacks", to be very explicit about the
prohibited behavior.
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 the TLS
handshake.  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.
In addition to "signature_algorithms" and
"signature_algorithms_cert", the "server_name" RFC6066,
"certificate_authorities" (Section 4.2.4. of TLS13), and
"oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide
certificate selection.  The extensions, or others that might affect
certificate selection, are taken from the authenticator request if
present, or the TLS handshake if not.
Alternative certificate formats such as RFC7250 Raw Public Keys are
not supported in this version of the specification.
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.
In addition to "signature_algorithms" and
"signature_algorithms_cert", the "server_name" RFC6066,
"certificate_authorities" (Section 4.2.4. of TLS13), and
"oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide
certificate selection.
Only the X509 certificate type defined in TLS13 is supported.
Alternative certificate formats such as RFC7250 Raw Public Keys are
not supported in this version of the specification and their use in
this context has not yet been analysed.
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 is present, the signature algorithm MUST
be chosen from one of the signature schemes in the authenticator
request.  Otherwise, the signature algorithm used should be chosen
from the "signature_algorithms" sent by the peer in the TLS
handshake.
If an authenticator request is present, the signature algorithm MUST
be chosen from one of the signature schemes present in the
authenticator request.  Otherwise, the signature algorithm used
should 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.
Where Hash is the hash function negotiated by TLS.  If the
authenticator request is not present, it is omitted from this
construction (that is, it is zero length).
Where Hash is the authenticator hash defined in section 4.1.  If the
authenticator request is not present, it is omitted from this
construction (that is, it is zero length).
The HMAC is computed using the authenticator hash, using the Finished
MAC Key as a key.
A given authenticator can be validated by checking the validity of
the CertificateVerify message given the authenticator request (if
used) and recomputing the Finished message to see if it matches.
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.
The creation and validation of both authenticator requests and
authenticators SHOULD be implemented inside the TLS library even if
it is possible to implement it at the application layer.  TLS
implementations supporting the use of exported authenticators MUST
provide application programming interfaces by which clients and
servers may request and verify exported authenticator messages.
The HMAC is computed using the authenticator hash, using the Finished
MAC Key as a key.  This message does not include any TLS framing.
The creation and validation of both authenticator requests and
authenticators SHOULD be implemented inside the TLS library even if
it is possible to implement it at the application layer.  TLS
implementations supporting the use of exported authenticators SHOULD
provide application programming interfaces by which clients and
servers may request and verify exported authenticator messages.
It returns an authenticator request, which is a sequence of octets
that includes a CertificateRequest message.
It returns an authenticator request, which is a sequence of octets
that comprises a CertificateRequest message.
It returns either the exported authenticator or an empty
authenticator as a sequence of octets.  It is RECOMMENDED that the
logic for selecting the certificates and extensions to include in the
exporter is implemented in the TLS library.  Implementing this in the
TLS library lets the implementer take advantage of existing extension
and certificate selection logic.
It returns either the exported authenticator or an empty
authenticator as a sequence of octets.  It is RECOMMENDED that the
logic for selecting the certificates and extensions to include in the
exporter is implemented in the TLS library.  Implementing this in the
TLS library lets the implementer take advantage of existing extension
and certificate selection logic and more easily remember which
extensions were sent in the ClientHello.
It returns the certificate chain and extensions and a status to
indicate whether the authenticator is valid or not.  If the
authenticator was empty - that is, it did not contain a certificate -
the certificate chain will contain no certificates.
It returns the certificate chain and extensions and a status to
indicate whether the authenticator is valid or not.  If the
authenticator was empty - that is, it did not contain a certificate -
the certificate chain will contain no certificates.  The API MUST
return a failure if the certificate_request_context of the
authenticator was used in a previously validated authenticator.
Well-formed empty authenticators are returned as valid.
The Certificate/Verify/Finished pattern intentionally looks like the
TLS 1.3 pattern which now has been analyzed several times.  In the
case where the client presents an authenticator to a server, SIGMAC
presents a relevant framework for analysis.
Authenticators are independent and unidirectional.  There is no
explicit state change inside TLS when an authenticator is either
created or validated.
The Certificate/Verify/Finished pattern intentionally looks like the
TLS 1.3 pattern which now has been analyzed several times.  For
example, SIGMAC presents a relevant framework for analysis.
Authenticators are independent and unidirectional.  There is no
explicit state change inside TLS when an authenticator is either
created or validated.  The application in possession of a validated
authenticator can rely on any semantics associated with data in the
certificate_request_context.