There has been a WGLC in the Token Binding (tokbind) WG about the
following documents:
draft-ietf-tokbind-protocol
draft-ietf-tokbind-https
draft-ietf-tokbind-negotiation
I have posted the following comments:
This set of documents failed to meet the terms of references of the
WG charter.
It is not resistant to the ABC attack (Alice and Bob collusion attack).
In this attack Bob who is older than 18 colloborates with Alice and
transmits a token to Alice
who is only 14 so that she can demonstrate to a RS that she is older
than 18.
This kind of attack is not even mentionned in the security
considerations section.
========================================================================
There are two options:
*Option A*: drop this series of documents, i.e. :
draft-ietf-tokbind-protocol
draft-ietf-tokbind-https
draft-ietf-tokbind-negotiation
or
**
*Option B*: clearly mention that the ABC attack cannot be countered
using TLS binding.
In case, the latter decision would be taken by the tokbind WG, I have
proposed a few text replacements.
*1 - *In *draft-ietf-tokbind-protocol*, change the abstract in the
following way
(and modify the content of the document in accordance):
This document specifies Version 1.0 of the Token Binding protocol. The
Token Binding protocol allows client/server applications tocreate
long-lived, uniquely identifiable TLS [RFC5246
<https://tools.ietf.org/html/rfc5246>] bindingsspanning multiple TLS
sessions and connections.Applications arethen enabled to
cryptographically bind security tokens to the TLSlayer. *However, the
binding a security token to a TLS connection **is unable to counter collaboration attacks between two clients **since one client can compute the necessary information for the **other client without the need to release his key(s) to the other **client.For an effective protection against collaboration attacks, **an appropriate format of the security token, together with an **appropriate validation of some fields of it, must be used.*To protect
privacy, the Token Binding identifiers are only transmitted encrypted
and can be reset by the user at any time.
Also the introduction states:
(...)
In order to successfully export and replay a bound security token,
the attacker needs to also be able to export the client's private
key, which is hard to do in the case of the key generated in a secure
hardware module.Proposed replacement
This should be replaced with:
(...)
*In order to successfully export and replay a bound security token,
**a client does not need to export the client's private**key, since
it can perform all the necessary computations in the **case of a
collaboration attack.
*
*2 -* In *draft-ietf-tokbind-https* add two additional paragraphs in the
abstract
(and modify the content of the document in accordance):
Abstract This document describes a collection of mechanisms that allow
HTTP servers to cryptographically bind authentication tokens (such
ascookies and OAuth tokens) to TLS [RFC5246
<https://tools.ietf.org/html/rfc5246>] connections. We describe both
_first-party_ and _federated_ scenarios.In afirst-party scenario, an
HTTP server is able to cryptographicallybind the security tokens it
issues to a client, and which the client subsequently returns to the
server, to the TLS connection between the client and server.Such bound
security tokens are protected from misuse since the server can generally
detect if they are replayedinappropriately, e.g., over other TLS
connections.*However, the binding a security token to a TLS connection
is **unable to counter collaboration attacks between two clients since
**one client can compute the necessary information for the other
**client without the need to release his key(s) to the other client. For
an effective protection against collaboration attacks, an **appropriate
format of the security token, together with an **appropriate validation
of some fields of it, must be used.*Federated token bindings, on the
other hand, allow servers tocryptographically bind security tokens to a
TLS connection that theclient has with a _different_ server than the one
issuing the token. This Internet-Draft is a companion document to The
Token BindingProtocol [I-D.ietf-tokbind-protocol
<https://tools.ietf.org/html/draft-ietf-tokbind-https-07#ref-I-D.ietf-tokbind-protocol>]
In section 7.1, change the text in the following way:
7.1. Security Token Export andReplayThe goal of the Federated
Token Binding mechanisms is to preventattackers from exporting and
replaying tokens used in protocols between the client and Token
Consumer, thereby impersonatinglegitimate users and gaining access
to protected resources.Boundtokens can still be replayed by
malware present in the client.
*They can also be exported and re-used when a client collaborates
**with another client.In order to export the token to another
**machine and successfully use it, a client may export the
**corresponding private key to the other client or may perform all
**the necessary computations for the other client without
exporting **the corresponding private**.Protecting the Token
Binding private **key, e.g. in a hardware security module that
prevents key export is **a good practice, but in such a case, it
is inefficient to counter **the clients collaboration attack.*
*3 - draft-ietf-oauth-token-binding-01* is based on the same foundations
and hence is suject to the ABC attack.
The same kind of decision is facing the OAuth WG:
*Option A*: drop draft-ietf-oauth-token-binding.
or
**
*Option B*: clearly mention that the ABC attack cannot be countered
using TLS binding.
In case, the latter decision would be taken by the OAuth WG, the
abstract should be changed
(and the content of the document should be modified in accordance).
The current abstract states:
This specification enables OAuth 2.0 implementations to apply Token
Binding to Access Tokens and Refresh Tokens. This cryptographically
binds these tokens to the TLS connections over which they are
intended to be used. This use of Token Binding protects these tokens
from man-in-the-middle and token export and replay attacks.
This should be changed into:
* This specification enables OAuth 2.0 implementations to apply Token
Binding to Access Tokens and Refresh Tokens. This cryptographically
binds these tokens to the TLS connections over which they are
intended to be used. This use of Token Binding protects these tokens
from man-in-the-middle attacks, but does not protect in case two
clients agree to collaborate, since one client can compute the necessary
information for the other client without the need to release his key(s)
to the other client.*
**
**
Denis
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
