Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt
Amos Jeffries <squid3@treenet.co.nz> Fri, 21 July 2017 15:17 UTC
Return-Path: <squid3@treenet.co.nz>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C69129B10 for <unbearable@ietfa.amsl.com>; Fri, 21 Jul 2017 08:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Level:
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHrij8Yr1v6D for <unbearable@ietfa.amsl.com>; Fri, 21 Jul 2017 08:17:36 -0700 (PDT)
Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 99E0B131761 for <unbearable@ietf.org>; Fri, 21 Jul 2017 08:17:33 -0700 (PDT)
Received: from [192.168.137.92] (unknown [121.98.43.66]) by treenet.co.nz (Postfix) with ESMTPA id 966C066001E for <unbearable@ietf.org>; Sat, 22 Jul 2017 03:17:31 +1200 (NZST)
To: unbearable@ietf.org
References: <150062800542.11311.4823917490193775849@ietfa.amsl.com> <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> <CACdeXi+gPpAvRuPsTgQte8ugmePUra5QLO2N0gHzkE9MKLjy2A@mail.gmail.com> <733401bb-4204-ebfb-1e4d-49c70eec2604@free.fr> <c132c588-3e5e-9004-8ba3-ebed325c08a5@mnt.se> <727870d8-4bb0-b465-9fe5-005073d6c4f1@free.fr> <EF742323-686D-47FD-A6B2-735DCBF97798@mnt.se>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <30205e60-624f-af43-e2af-e1f7c9bd29d9@treenet.co.nz>
Date: Sat, 22 Jul 2017 03:17:31 +1200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <EF742323-686D-47FD-A6B2-735DCBF97798@mnt.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/ltLkHRW2D1REQ7vlcXkOnNghAFs>
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jul 2017 15:17:38 -0000
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
- [Unbearable] I-D Action: draft-ietf-tokbind-https… internet-drafts
- Re: [Unbearable] I-D Action: draft-ietf-tokbind-h… Denis
- Re: [Unbearable] I-D Action: draft-ietf-tokbind-h… Nick Harper
- Re: [Unbearable] I-D Action: draft-ietf-tokbind-h… Denis
- Re: [Unbearable] I-D Action: draft-ietf-tokbind-h… Leif Johansson
- Re: [Unbearable] I-D Action: draft-ietf-tokbind-h… Denis
- Re: [Unbearable] I-D Action: draft-ietf-tokbind-h… Leif Johansson
- Re: [Unbearable] I-D Action: draft-ietf-tokbind-h… Amos Jeffries