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

[Amos Jeffries <[e-mail]>]

On 21/07/17 23:26, Leif Johansson wrote:
> 
> Skickat från min iPhone
> 
> 21 juli 2017 kl. 13:03 skrev Denis:
> 
>> Leif,
>>
>> The text that was quoted is in the Security Considerations section 
>> under section "7.1.  Security Token Replay"
>> from draft-ietf-tokbind-protocol.
> 
> I was not responding to that but to your claim that it is not reasonable 
> to expect implementors to read the full set of specs. It is.
> 
>>
>> I already said on the list that the text does not fit under section 
>> 7.1 since it is not a security token *replay* in any sense,
>> since the legitimate client is not playing anything, so it cant' be a 
>> replay.
>>
>> It should be under a specific section called, e.g.: Client collusion.
>>
>> It is particularly important that readers realize that this protection 
>> is not effective under some circumstances.
>>
>> Is there any harm to warn the user in both documents  ?


It is perhapse best to be aware that HTTP itself is stateless. This 
document focus is on how tokens are embeded into a single HTTP message, 
and what manipulations occur to that embedding during transfer. Not the 
content/values of those tokens, nor the content/values of the things 
bound with the token.

There is no need to consider this collusion attack because in HTTP 
context there is only ever *one* client for a given message. There is no 
possibility of multiple clients sending a single message - that would be 
multiple messages in HTTP terms, even if they had identical headers and 
tokens.

Each of those messages sent by the colluding clients MUST be interpreted 
through the draft-ietf-tokbind-protocol procedures independent of all 
other messages (even those really from the same client). Whether those 
procedures are relevant to the attack is a detail for that other 
document to address.

Amos