Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt

draft-ietf-tokbind-protocol-15 already has language which says "The
Token Binding protocol does not prevent cooperating clients from
sharing a bound token.  A client could intentionally export a bound
token with the corresponding Token Binding private key, or perform
signatures using this key on behalf of another client." I don't think
we need any additional language in this draft regarding client
collusion. That clients could collude is a property of the Token
Binding protocol, so it doesn't need to be repeated in this
application profile for using Token Binding.

On Fri, Jul 21, 2017 at 2:21 AM, Denis <denis.ietf@free.fr> wrote:
> This ID is still lacking to indicate that  this mechanism will be
> ineffective in case of a collusion between clients.
>
> This should be clearly indicated in the Security Considerations section.
>
> Denis
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Token Binding WG of the IETF.
>>
>>          Title           : Token Binding over HTTP
>>          Authors         : Andrei Popov
>>                            Magnus Nyström
>>                            Dirk Balfanz
>>                            Adam Langley
>>                            Nick Harper
>>                            Jeff Hodges
>>         Filename        : draft-ietf-tokbind-https-10.txt
>>         Pages           : 22
>>         Date            : 2017-07-21
>>
>> Abstract:
>>     This document describes a collection of mechanisms that allow HTTP
>>     servers to cryptographically bind security tokens (such as cookies
>>     and OAuth tokens) to TLS connections.
>>
>>     We describe both first-party and federated scenarios.  In a first-
>>     party scenario, an HTTP server is able to cryptographically bind 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 replayed
>>     inappropriately, e.g., over other TLS connections.
>>
>>     Federated token bindings, on the other hand, allow servers to
>>     cryptographically bind security tokens to a TLS connection that the
>>     client has with a different server than the one issuing the token.
>>
>>     This Internet-Draft is a companion document to The Token Binding
>>     Protocol.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tokbind-https-10
>> https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-10
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-10
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>
>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable