draft-ietf-tokbind-tls13-0rtt-01.txt   draft-ietf-tokbind-tls13-0rtt-02.txt 
Token Binding Working Group N. Harper Token Binding Working Group N. Harper
Internet-Draft Google Inc. Internet-Draft Google Inc.
Intended status: Standards Track March 13, 2017 Intended status: Standards Track June 28, 2017
Expires: September 14, 2017 Expires: December 30, 2017
Token Binding for 0-RTT TLS 1.3 Connections Token Binding for 0-RTT TLS 1.3 Connections
draft-ietf-tokbind-tls13-0rtt-01 draft-ietf-tokbind-tls13-0rtt-02
Abstract Abstract
This document describes how Token Binding can be used in the 0-RTT This document describes how Token Binding can be used in the 0-RTT
data of a TLS 1.3 connection. This involves updating how Token data of a TLS 1.3 connection. This involves a new TLS extension to
Binding negotiation works and adding a mechanism for indicating negotiate and indicate the use of Token Binding in 0-RTT data. A
whether a server prevents replay. A TokenBindingMessage sent in TokenBindingMessage sent in 0-RTT data has different security
0-RTT data has different security properties than one sent after the properties than one sent after the TLS handshake has finished, which
TLS handshake has finished, which this document also describes. this document also describes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on December 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Proposed Design . . . . . . . . . . . . . . . . . . . . . . . 3 2. TokenBinding Signature Definition . . . . . . . . . . . . . . 3
2.1. TokenBinding Signature Definition . . . . . . . . . . . . 3 2.1. Selecting Which Exporter Secret to Use . . . . . . . . . 3
2.1.1. Selecting Which Exporter Secret to Use . . . . . . . 3 3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Negotiating Token Binding . . . . . . . . . . . . . . . . 4 3.1. Indicating Use of 0-RTT Token Binding . . . . . . . . . . 4
2.2.1. Negotiation TLS Extension . . . . . . . . . . . . . . 4 3.2. Token Binding Negotiation TLS Extension . . . . . . . . . 4
2.2.2. Replay Protection Indication Extension . . . . . . . 4 3.3. Client Processing Rules . . . . . . . . . . . . . . . . . 4
3. Implementation Challenges . . . . . . . . . . . . . . . . . . 5 3.4. Server Processing Rules . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Implementation Considerations . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4.1. Not Implementing Token Binding on 0-RTT Connections . . . 6
5.1. Proof of Possession of Token Binding Key . . . . . . . . 6 4.2. Adding Support for Token Binding on 0-RTT Connections . . 7
5.2. Attacks on PSK-only Key Exchange and Token Binding . . . 6 4.3. Implementation Challenges . . . . . . . . . . . . . . . . 7
5.3. Exporter Replayability . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.4. Replay Mitigations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.4.1. Server Mitigations . . . . . . . . . . . . . . . . . 8 6.1. Proof of Possession of Token Binding Key . . . . . . . . 8
5.4.2. Client Mitigations . . . . . . . . . . . . . . . . . 8 6.2. Exporter Replayability . . . . . . . . . . . . . . . . . 8
5.5. Early Data Ticket Age Window . . . . . . . . . . . . . . 8 6.3. Replay Mitigations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6.3.1. Server Mitigations . . . . . . . . . . . . . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . . . 9 6.3.2. Client Mitigations . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Early Data Ticket Age Window . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Token Binding ([I-D.ietf-tokbind-protocol]) cryptographically binds Token Binding ([I-D.ietf-tokbind-protocol]) cryptographically binds
security tokens (e.g. HTTP cookies, OAuth tokens) to the TLS layer security tokens (e.g. HTTP cookies, OAuth tokens) to the TLS layer
on which they are presented. It does so by signing an [RFC5705] on which they are presented. It does so by signing an [RFC5705]
exporter value from the TLS connection. TLS 1.3 introduces a new exporter value from the TLS connection. TLS 1.3 introduces a new
mode that allows a client to send application data on its first mode that allows a client to send application data on its first
flight. If this 0-RTT data contains a security token, then a client flight. If this 0-RTT data contains a security token, then a client
using Token Binding would want to prove possession of its Token using Token Binding would want to prove possession of its Token
Binding private key so that the server can verify the binding. The Binding private key so that the server can verify the binding. The
[RFC5705]-style exporter provided by TLS 1.3 cannot be run until the [RFC5705]-style exporter provided by TLS 1.3 cannot be run until the
handshake has finished. TLS 1.3 also provides an exporter that can handshake has finished. TLS 1.3 also provides an exporter that can
be used with 0-RTT data, but it requires that the application be used with 0-RTT data, but it requires that the application
explicitly specify that use. This document specifies how to use the explicitly specify that use. This document specifies how to use the
early_exporter_secret with Token Binding in TLS 1.3 0-RTT data. early_exporter_secret with Token Binding in TLS 1.3 0-RTT data.
Using Token Binding in 0-RTT data involves two main changes to Token
Binding. The first is the use of a new TLS extension
"early_token_binding" to indicate whether a TLS session ticket can be
used with Token Binding in 0-RTT data, and to indicate whether an
attempted 0-RTT connection is using Token Binding in 0-RTT data. The
second change is one that applies only if Token Binding in 0-RTT data
is in use, which changes the definition of the TokenBinding.signature
field to use TLS 1.3's early_exporter_secret.
If a client does not send any 0-RTT data, or if the server rejects
the client's 0-RTT data, then the client MUST use the 1-RTT exporter,
as defined in [I-D.ietf-tokbind-protocol].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Proposed Design 2. TokenBinding Signature Definition
A TokenBinding struct as defined in [I-D.ietf-tokbind-protocol]
contains a signature of the EKM value from the TLS layer. Under
normal circumstances, a TokenBinding on a TLS 1.3 connection would
use the exporter_secret to derive the EKM value. When 0-RTT data is
assembled to be sent, the exporter_secret is not yet available. This
design changes the definition of the TokenBinding.signature field to
use the exporter with either early_exporter_secret or
exporter_secret. Since no negotiation for the connection can happen
before the client sends this TokenBindingMessage in 0-RTT data, this
document also describes how a client decides what TokenBindingMessage
to send in 0-RTT data and how a server should interpret that message.
If a client does not send any 0-RTT data, or if the server rejects
the client's 0-RTT data, then the client MUST use the 1-RTT exporter,
as defined in [I-D.ietf-tokbind-protocol].
2.1. TokenBinding Signature Definition
In [I-D.ietf-tokbind-protocol], the signature field of the In [I-D.ietf-tokbind-protocol], the signature field of the
TokenBinding struct is defined to be the signature of a TokenBinding struct is defined to be the signature of a
concatentation that includes the EKM value. Depending on the concatentation that includes the EKM value. Depending on the
circumstances, the exporter value in section 7.3.3 of circumstances, the exporter value in section 7.3.3 of
[I-D.ietf-tls-tls13] is computed using either exporter_secret or [I-D.ietf-tls-tls13] is computed using either exporter_secret or
early_exporter_secret as the Secret. early_exporter_secret as the Secret.
When early_exporter_secret is used as the Secret, the client MUST When early_exporter_secret is used as the Secret, the client MUST
indicate this use so the server knows which secret to use in indicate this use so the server knows which secret to use in
signature verification. This indication is done through a new Token signature verification. This indication is done through a new Token
Binding extension, "early_exporter" (with extension type TBD). This Binding extension, "early_exporter" (with extension type TBD). This
extension always has 0-length data, so the full Extension struct is extension always has 0-length data, so the full Extension struct is
the bytes {0xTBD, 0x00, 0x00}. The early_exporter extension MUST be the bytes {0xTBD, 0x00, 0x00}. The early_exporter extension MUST be
present in every TokenBinding struct where the exporter that is present in every TokenBinding struct where the exporter that is
signed uses the early_exporter_secret, and it MUST NOT be present in signed uses the early_exporter_secret, and it MUST NOT be present in
any other TokenBinding structs. any other TokenBinding structs.
2.1.1. Selecting Which Exporter Secret to Use 2.1. Selecting Which Exporter Secret to Use
A client which is not sending any 0-RTT data on a connection MUST use A client which is not sending any 0-RTT data on a connection MUST use
the exporter defined in [I-D.ietf-tls-tls13] (using exporter_secret the exporter defined in [I-D.ietf-tls-tls13] (using exporter_secret
as the Secret) for all TokenBindingMessages on that connection so as the Secret) for all TokenBindingMessages on that connection so
that it is compatible with [I-D.ietf-tokbind-protocol]. that it is compatible with [I-D.ietf-tokbind-protocol].
When a client sends a TokenBindingMessage in 0-RTT data, it must use When a client sends a TokenBindingMessage in 0-RTT data, it must use
the early_exporter_secret. After the client receives an application- the early_exporter_secret. If the server accepts the 0-RTT data, the
layer response from the server, it must use the exporter_secret for client must continue to use the early_exporter_secret for the rest of
all future token bindings on that connection. Requests sent after the connection. If the server rejects 0-RTT data, the client must
the client's TLS Finished message, but before the client processes use the exporter_secret.
any application-layer response from the server, may use either
exporter secret in their token bindings.
A server may choose to reject an application message containing a 3. Negotiation
Token Binding that uses the early_exporter_secret. If it chooses to
do so, it may send an application message indicating that the client
should re-send the request (with a new Token Binding). In HTTP, this
could be done with a 307 status code.
2.2. Negotiating Token Binding 3.1. Indicating Use of 0-RTT Token Binding
2.2.1. Negotiation TLS Extension The TLS extension "early_token_binding" (extension type TBD) is used
in the TLS ClientHello and EncryptedExtensions to indicate use of
0-RTT Token Binding on the current connection. It is also used in a
NewSessionTicket message to indicate that 0-RTT Token Binding may be
used on a connection resumed with that ticket. In all cases, the
"extension_data" field of this extension is empty, so the entire
encoding of this extension is 0xTBD 0xTBD 0x00 0x00.
The behavior of the Token Binding negotiation TLS extension does not 3.2. Token Binding Negotiation TLS Extension
change for a 0-RTT connection: the client and server should process
this extension the same way regardless of whether the client also
sent the EarlyDataIndication extension.
For the sake of choosing a key parameter to use in 0-RTT data, the In TLS 1.3, the "token_binding" extension is sent by a server in
client MUST use the same key parameter that was used on the EncryptedExtensions, whereas in previous versions of TLS this
connection during which the ticket (now being used for resumption) extension was sent in the ServerHello message. On a 1-RTT connection
was established. The server MUST NOT accept early data if the (whether it be a new connection or resumption), no application data
negotiated Token Binding key parameter does not match the parameter is sent in either direction before the "token_binding" TLS extension
from the initial connection. This is the same behavior as ALPN and in the EncryptedExtensions, and the choice of Token Binding version
SNI extensions. and key parameter is up to the server based on what the client sent
and what the server's preferences are, following the same processing
rules as in [I-D.ietf-tokbind-negotiation].
If 0-RTT data is being sent with Token Binding using a PSK obtained 3.3. Client Processing Rules
out-of-band, then the Token Binding key parameter to use with that
PSK must also be provisioned to both parties, and only that key
parameter must be used with that PSK.
2.2.2. Replay Protection Indication Extension A client that supports Token Binding in 0-RTT data and receives a
NewSessionTicket containing the "early_token_binding" extension must
store with the ticket the Token Binding version and key parameter of
the connection in which the ticket was issued.
The signed exporter value used in a 0-RTT connection is not A client that wishes to send a Token Binding message in 0-RTT data
guaranteed to be unique to the connection, so an attacker may be able may only do so if the TLS connection in which the 0-RTT data is being
to replay the signature without having possession of the private key. sent is being resumed from a ticket which included the
To combat this attack, a server may implement some sort of replay "early_token_binding" extension. Assuming the ticket included this
prevention, and indicate this to the client. A new TLS extension extension, the client sends a ClientHello containing the
"token_binding_replay_indication" is defined for the client to query "token_binding" extension, "early_data" extension, and
and server to indicate whether it has implemented a mechanism to "early_token_binding" extensions. The client must include in its
prevent replay. "psk_key_exchange_modes" extension psk_dhe_ke.
enum { The contents of the "token_binding" extension SHOULD be the same as
token_binding_replay_indication(TBD), (65535) they would be on a connection without "early_token_binding" to allow
} ExtensionType; for the client and server to negotiate new Token Binding parameters
When sent, this extension always has zero length. If a client wishes if the early data is rejected. The Token Binding message sent in the
to know whether its peer is preventing replay of TokenBinding structs 0-RTT data MUST be sent assuming that the same Token Binding version
across multiple connections, the client can include this extension in and key parameter from the connection where the ticket was received
its ClientHello. Upon receiving this extension, the server must echo will also be negotiated on this connection. If the server includes
it back if it is using such a mechanism (like those described in the "early_data" extension in EncryptedExtensions in response to a
Section 5.4.1) to prevent replay. A client that only wishes to send ClientHello with "early_token_binding", but the server does not
0-RTT Token Binding if the server implements replay protection can include "early_token_binding" in EncryptedExtensions, or if the
send this extension on first connection establishment, and if the server's "token_binding" extension does not match the values of the
server doesn't send it back (but does support Token Binding) the connection where the ticket was received, then the client MUST
client can choose to not send 0-RTT messages to that server. terminate the TLS connection with an illegal_parameter alert.
A client that wishes to use this extension should send it every time It is valid for a client to send a ClientHello that contains both the
it sends a "token_binding" [I-D.ietf-tokbind-negotiation] extension. "early_data" and "token_binding" extensions, but without the
"early_token_binding" extension. This combination means that the
client is attempting to resume a connection and is sending early
data, but the client is not using Token Binding on this resumed
connection (if the server accepts the early data). The presence of
the "token_binding" extension is so the client can negotiate the use
of Token Binding for this connection if the server rejects early
data.
3. Implementation Challenges 3.4. Server Processing Rules
When a server issues a NewSessionTicket on a connection where Token
Binding was negotiated, and the NewSessionTicket includes an
"early_data" extension indicating that the ticket may be used to send
0-RTT data, the server may also include the "early_token_binding"
extension in the NewSessionTicket to indicate that this ticket can be
used for a future connection with Token Binding in 0-RTT data. If
the server includes the "early_token_binding" extension in the
NewSessionTicket, the server MUST store with the ticket the Token
Binding version and key parameter used for the connection in which
the ticket was issued. The "early_token_binding" extension can
appear in a NewSessionTicket message only if the "early_data"
extension also appears in that message.
If a server receives a ClientHello with the "early_token_binding"
extension and supports Token Binding in 0-RTT data, it MUST perform
the following checks:
o If either the "early_data" or "token_binding" extensions are
missing from the ClientHello, terminate the TLS connection with an
illegal_parameter alert.
o If the ticket used for resumption is missing either of the
"early_data" or "early_token_binding" extensions, reject the early
data.
o Process the "token_binding" extension as if it were received on a
1-RTT connection and compute the Token Binding version and key
parameter to use. If either of these values do not match the
values that were negotiated on the connection where the ticket
used for resumption was sent, reject the early data.
o Perform any other checks to decide whether to accept early data.
If the server chooses to accept early data, include in
EncryptedExtensions the "early_data" extension,
"early_token_binding" extension, and "token_binding" extension
with the same version and key parameter from the previous
connection.
If a server accepts early data on a connection where
"early_token_binding" was offered, it MUST use PSK with (EC)DHE key
establishment.
The "early_token_binding" extension must be present in
EncryptedExtensions exactly when both "early_data" and
"token_binding" are present. A server that receives a ClientHello
with "early_token_binding" cannot reject Token Binding and also
accept early data at the same time. Said server may reject early
data but still negotiate Token Binding.
A server might receive a ClientHello that includes both the
"early_data" and "token_binding" extensions, but no
"early_token_binding" extension. In this case, the server has three
options:
1. Accept early data and continue the connection with no Token
Binding,
2. Reject early data and negotiate the use of Token Binding for this
connection, or
3. Reject early data and do not negotiate Token Binding for this
connection.
The behavior for the "token_binding" extension in 0-RTT is similar to
that of ALPN and SNI: the client predicts the result of the
negotiation, and if the actual negotiation differs, the server
rejects the early data.
4. Implementation Considerations
4.1. Not Implementing Token Binding on 0-RTT Connections
This spec has been designed so that both clients and servers can
support Token Binding on some connections and 0-RTT data on other
connections without needing to support Token Binding on 0-RTT
connections.
A client that wishes to support both without supporting Token Binding
on 0-RTT connections can function by completely ignoring the
"early_token_binding" TLS extension. When resuming a connection with
early data, the client can still advertise support for Token Binding,
providing the server the opportunity to accept early data (without
Token Binding) or to reject early data and negotiate Token Binding.
By always including the "token_binding" extension in its ClientHello,
the client can prioritize Token Binding over 0-RTT.
A server can support both Token Binding and 0-RTT data without
supporting Token Binding on 0-RTT connections by never minting
NewSessionTickets containing the "early_token_binding" extension.
Such a server that never mints NewSessionTickets with
"early_token_binding" can ignore that extension in a ClientHello as
it would only appear if the client is not spec compliant. On
connections where a server negotiates Token Binding, the server
SHOULD NOT include the "early_data" extension in a NewSessionTicket.
4.2. Adding Support for Token Binding on 0-RTT Connections
A server that supports early data but not Token Binding may wish to
add support for Token Binding (and Token Binding on 0-RTT
connections) at a later time. For a client to learn that a server
supports Token Binding, the server must reject early data to send the
"token_binding" extension.
4.3. Implementation Challenges
The client has to be able to modify the message it sends in 0-RTT The client has to be able to modify the message it sends in 0-RTT
data if the 0-RTT data gets rejected and needs to be retransmitted in data if the 0-RTT data gets rejected and needs to be retransmitted in
1-RTT data. Even if the Token Binding integration with 0-RTT were 1-RTT data. Even if the Token Binding integration with 0-RTT were
modified so that Token Binding never caused a 0-RTT reject that modified so that Token Binding never caused a 0-RTT reject that
required rewriting a request, the client still has to handle the required rewriting a request, the client still has to handle the
server rejecting the 0-RTT data for other reasons. server rejecting the 0-RTT data for other reasons.
HTTP2 allows for requests to different domains to share the same TLS HTTP2 allows for requests to different domains to share the same TLS
connection if the SAN of the cert covers those domains. If connection if the SAN of the cert covers those domains. If
one.example.com supports 0-RTT and Token Binding, but two.example.com one.example.com supports 0-RTT and Token Binding, but two.example.com
only supports Token Binding as defined in only supports Token Binding as defined in
[I-D.ietf-tokbind-protocol], those servers cannot share a cert and [I-D.ietf-tokbind-protocol], those servers cannot share a cert and
use HTTP2. use HTTP2.
4. IANA Considerations 5. IANA Considerations
This document defines a new TLS extension This document defines a new TLS extension "early_token_binding" with
"token_binding_replay_indication", which needs to be added to the code point TBD which needs to be added to IANA's TLS "ExtensionType
IANA "Transport Layer Security (TLS) Extensions" registry. Values" registry.
This document defines a new Token Binding extension "early_exporter", This document defines a new Token Binding extension "early_exporter",
which needs to be added to the IANA "Token Binding Extensions" which needs to be added to the IANA "Token Binding Extensions"
registry. registry.
5. Security Considerations 6. Security Considerations
Token Binding messages that use the 0-RTT exporter have weaker Token Binding messages that use the 0-RTT exporter have weaker
security properties than with the [RFC5705] exporter. If either security properties than with the [RFC5705] exporter. If either
party of a connection using Token Binding does not wish to use 0-RTT party of a connection using Token Binding does not wish to use 0-RTT
token bindings, they can do so: a client can choose to never send token bindings, they can do so: a client can choose to never send
0-RTT data on a connection where it uses token binding, and a server 0-RTT data on a connection where it uses token binding, and a server
can choose to reject any 0-RTT data sent on a connection that can choose to reject any 0-RTT data sent on a connection that
negotiated token binding. negotiated token binding.
0-RTT data in TLS 1.3 has weaker security properties than other kinds 0-RTT data in TLS 1.3 has weaker security properties than other kinds
of TLS data. Specifically, TLS 1.3 does not guarantee non- of TLS data. Specifically, TLS 1.3 does not guarantee non-
replayability of data between connections. Token Binding has similar replayability of data between connections. Token Binding has similar
replayability issues when in 0-RTT data, but preventing replay of replayability issues when in 0-RTT data, but preventing replay of
Token Binding and preventing replay of 0-RTT data are two separate Token Binding and preventing replay of 0-RTT data are two separate
problems. Token Binding is not designed to prevent replay of 0-RTT problems. Token Binding is not designed to prevent replay of 0-RTT
data, although solutions for preventing the replay of Token Binding data, although solutions for preventing the replay of Token Binding
might also be applicable to 0-RTT data. might also be applicable to 0-RTT data.
5.1. Proof of Possession of Token Binding Key 6.1. Proof of Possession of Token Binding Key
When a Token Binding signature is generated using the exporter with When a Token Binding signature is generated using the exporter with
early_exporter_secret, the value being signed is under the client's early_exporter_secret, the value being signed is under the client's
control. An attacker with temporary access to the Token Binding control. An attacker with temporary access to the Token Binding
private key can generate Token Binding signatures for as many future private key can generate Token Binding signatures for as many future
connections as it has NewSessionTickets for. An attacker can connections as it has NewSessionTickets for. An attacker can
construct these to be usable at any time in the future up until the construct these to be usable at any time in the future up until the
NewSessionTicket's expiration. Section 4.6.1 of [I-D.ietf-tls-tls13] NewSessionTicket's expiration. Section 4.6.1 of [I-D.ietf-tls-tls13]
requires that a NewSessionTicket be valid for a maximum of 7 days. requires that a NewSessionTicket be valid for a maximum of 7 days.
Unlike in [I-D.ietf-tokbind-protocol], where the proof of possession Unlike in [I-D.ietf-tokbind-protocol], where the proof of possession
of the Token Binding key proves that the client had possession at the of the Token Binding key proves that the client had possession at the
time the TLS handshake finished, 0-RTT Token Binding only proves that time the TLS handshake finished, 0-RTT Token Binding only proves that
the client had possession of the Token Binding key at some point the client had possession of the Token Binding key at some point
after receiving the NewSessionTicket used for that connection. after receiving the NewSessionTicket used for that connection.
5.2. Attacks on PSK-only Key Exchange and Token Binding 6.2. Exporter Replayability
An attacker who possesses the PSK can eavesdrop on an existing
connection that uses that PSK to obtain a TokenBindingMessage that is
valid on the connection and then hijack the connection to send
whatever attacker-controlled data it wishes. Because the regular
exporter closes over the server random, this TokenBindingMessage is
valid only for that connection.
If the attacker does the same thing with a pure-PSK connection and
0-RTT Token Binding, the attacker can replay the original ClientHello
and the exporter will stay the same, allowing the attacker to obtain
a TokenBindingMessage from one connection and replay it on future
connections. The only way for a server to prevent this replay is to
prevent the client from ever repeating a client random in the
handshake.
If a server accepting connections with PSK-only key establishment is
concerned about the threat of PSK theft and also implements Token
Binding, then that server must either reject all 0-RTT token
bindings, or implement some form of preventing reuse of a client
random.
5.3. Exporter Replayability
The exporter specified in [I-D.ietf-tokbind-protocol] is chosen so The exporter specified in [I-D.ietf-tokbind-protocol] is chosen so
that a client and server have the same exporter value only if they that a client and server have the same exporter value only if they
are on the same TLS connection. This prevents an attacker who can are on the same TLS connection. This prevents an attacker who can
read the plaintext of a TokenBindingMessage sent on that connection read the plaintext of a TokenBindingMessage sent on that connection
from replaying that message on another connection (without also from replaying that message on another connection (without also
having the token binding private key). The 0-RTT exporter only having the token binding private key). The 0-RTT exporter only
covers the ClientHello and the PSK of the connection, so it does not covers the ClientHello and the PSK of the connection, so it does not
provide this guarantee. provide this guarantee.
skipping to change at page 7, line 42 skipping to change at page 9, line 30
This sort of replayability of a TokenBindingMessage is different than This sort of replayability of a TokenBindingMessage is different than
the replayability caveat of 0-RTT application data in TLS 1.3. A the replayability caveat of 0-RTT application data in TLS 1.3. A
network observer can replay 0-RTT data from TLS 1.3 without knowing network observer can replay 0-RTT data from TLS 1.3 without knowing
any secrets of the client or server, but the application data that is any secrets of the client or server, but the application data that is
replayed is untouched. This replay is done by a more powerful replayed is untouched. This replay is done by a more powerful
attacker who is able to view the plaintext and then spoof a attacker who is able to view the plaintext and then spoof a
connection with the same parameters so that the replayed connection with the same parameters so that the replayed
TokenBindingMessage still validates when sent with different TokenBindingMessage still validates when sent with different
application data. application data.
5.4. Replay Mitigations 6.3. Replay Mitigations
This section presents multiple ways that a client or server can This section presents multiple ways that a client or server can
prevent the replay of a TokenBinding while still using Token Binding mitigate the replay of a TokenBinding while still using Token Binding
with 0-RTT data. with 0-RTT data. Note that even with replay mitigations, 0-RTT Token
Binding is vulnerable to other attacks.
If a client or server implements a measure that prevents all replays,
then its peer does not also need to implement such a mitigation. A
client that is concerned about replay SHOULD implement a replay
mitigation instead of relying solely on a signal from the server
through the replay indication extension. Note that even with replay
mitigations, 0-RTT Token Binding is vulnerable to other attacks.
5.4.1. Server Mitigations 6.3.1. Server Mitigations
If a server uses a session cache instead of stateless tickets, it can If a server uses a session cache instead of stateless tickets, it can
enforce that a PSK generated for resumption can only be used once. enforce that a PSK generated for resumption can only be used once.
If an attacker tries to replay 0-RTT data (with a If an attacker tries to replay 0-RTT data (with a
TokenBindingMessage), the server will reject it because the PSK was TokenBindingMessage), the server will reject it because the PSK was
already used. already used.
Preventing all replay of 0-RTT data is not necessary to prevent Preventing all replay of 0-RTT data is not necessary to prevent
replay of a TokenBinding. A server could implement a mechanism to replay of a TokenBinding. A server could implement a mechanism to
prevent a particular TokenBinding from being presented on more than prevent a particular TokenBinding from being presented on more than
one connection. In cases where a server's TLS termination and one connection. In cases where a server's TLS termination and
application layer processing happen in different locations, this application layer processing happen in different locations, this
option might be easier to implement, especially when not all requests option might be easier to implement, especially when not all requests
have bound tokens. This processing can also take advantage of the have bound tokens. This processing can also take advantage of the
structure of the bound token, e.g. a token that identifies which user structure of the bound token, e.g. a token that identifies which user
is making a request could shard its store of which TokenBindings have is making a request could shard its store of which TokenBindings have
been seen based on the user ID. been seen based on the user ID.
A server can prevent some, but not all, 0-RTT data replay with a A server can prevent some, but not all, 0-RTT data replay with a
tight time window for the ticket age that it will accept. See tight time window for the ticket age that it will accept. See
Section 5.5 for more details. Section 6.4 for more details.
5.4.2. Client Mitigations 6.3.2. Client Mitigations
A client cannot prevent a sufficiently motivated attacker from A client cannot prevent a sufficiently motivated attacker from
replaying a TokenBinding, but it can make it so difficult to replay replaying a TokenBinding, but it can make it so difficult to replay
the TokenBinding that it is easier for the attacker to steal the the TokenBinding that it is easier for the attacker to steal the
Token Binding key directly. If the client secures the resumption Token Binding key directly. If the client secures the resumption
secret with the same level of protection as the Token Binding key, secret with the same level of protection as the Token Binding key,
then the client has made it not worth the effort of the attacker to then the client has made it not worth the effort of the attacker to
attempt to replay a TokenBinding. Ideally the resumption secret (and attempt to replay a TokenBinding. Ideally the resumption secret (and
Token Binding key) are protected strongly and virtually non- Token Binding key) are protected strongly and virtually non-
exportable. exportable.
5.5. Early Data Ticket Age Window 6.4. Early Data Ticket Age Window
When an attacker with control of the PSK secret replays a When an attacker with control of the PSK secret replays a
TokenBindingMessage, it has to use the same ClientHello that the TokenBindingMessage, it has to use the same ClientHello that the
client used. The ClientHello includes an "obfuscated_ticket_age" in client used. The ClientHello includes an "obfuscated_ticket_age" in
its EarlyDataIndication extension, which the server can use to narrow its EarlyDataIndication extension, which the server can use to narrow
the window in which that ClientHello will be accepted. Even if a PSK the window in which that ClientHello will be accepted. Even if a PSK
is valid for a week, the server will only accept that particular is valid for a week, the server will only accept that particular
ClientHello for a smaller time window based on the ticket age. A ClientHello for a smaller time window based on the ticket age. A
server should make their acceptance window for this value as small as server should make their acceptance window for this value as small as
practical to limit an attacker's ability to replay a ClientHello and practical to limit an attacker's ability to replay a ClientHello and
send new application data with the stolen TokenBindingMessage. send new application data with the stolen TokenBindingMessage.
6. Acknowledgements 7. Acknowledgements
The author would like to thank David Benjamin, Steven Valdez, Bill The author would like to thank David Benjamin, Steven Valdez, Bill
Cox, and Andrei Popov for their feedback and suggestions. Cox, and Andrei Popov for their feedback and suggestions.
7. Normative References 8. Normative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-19 (work in progress), Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
March 2017. April 2017.
[I-D.ietf-tokbind-negotiation] [I-D.ietf-tokbind-negotiation]
Popov, A., Nystrom, M., Balfanz, D., and A. Langley, Popov, A., Nystrom, M., Balfanz, D., and A. Langley,
"Transport Layer Security (TLS) Extension for Token "Transport Layer Security (TLS) Extension for Token
Binding Protocol Negotiation", draft-ietf-tokbind- Binding Protocol Negotiation", draft-ietf-tokbind-
negotiation-07 (work in progress), February 2017. negotiation-08 (work in progress), April 2017.
[I-D.ietf-tokbind-protocol] [I-D.ietf-tokbind-protocol]
Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
Hodges, "The Token Binding Protocol Version 1.0", draft- Hodges, "The Token Binding Protocol Version 1.0", draft-
ietf-tokbind-protocol-13 (work in progress), February ietf-tokbind-protocol-14 (work in progress), April 2017.
2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <http://www.rfc-editor.org/info/rfc5705>. March 2010, <http://www.rfc-editor.org/info/rfc5705>.
 End of changes. 36 change blocks. 
153 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/