[Unbearable] clarifying Include-Referred-Token-Binding-ID (was Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT))

Brian Campbell <bcampbell@pingidentity.com> Tue, 08 May 2018 18:33 UTC

Return-Path: <bcampbell@pingidentity.com>
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 42ED412778E for <unbearable@ietfa.amsl.com>; Tue, 8 May 2018 11:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
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 RmlRJVsk68Xu for <unbearable@ietfa.amsl.com>; Tue, 8 May 2018 11:32:58 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8215F1277BB for <unbearable@ietf.org>; Tue, 8 May 2018 11:32:54 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id e20-v6so17471153itc.1 for <unbearable@ietf.org>; Tue, 08 May 2018 11:32:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc; bh=gNWTXaHs5q28Lgtc5SvpmAq42zE1fC93GIShk7kbbG4=; b=EMXG1WNcM3etzOP06X6JPn/YrL5EN5SvcjbBWipwjImcB15f/nyPKq8Lo21RwKStGV NcXmhcQFzxSxMCEQvTDkYewJizqdUKlKPx5SeutrimC4vE6iaSIcRTX9//l5bTJok8qi EJFj0ryVl5VwGeWc1duml+wpNLW+asTDBsMvQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=gNWTXaHs5q28Lgtc5SvpmAq42zE1fC93GIShk7kbbG4=; b=lmOd5pOo7+aBz4uFaaC5nz0wJLHtc8beob1cCMGcSuFyBD+AmV8d3XiMdvORv2IrhU fMUrslhZY5O6yWgaSQRFVG7RaOC592Oj50FqosC8SL4qQjwDIONmLhrbSmXBd2k8k26r 4nIr6nOoiJBBVknp6AFLWL/b1J0AsvVxI2z2UanxNOh4ybNx4HpeMzhqPJfOrPoOM1M2 5Pa4k2MDNFmYpZBQTTh9YXF9HzC9LszlovKFNkyabQUzdeWavFbtSTsPN27zQhIto73j atRJTIKKaijQrWEh7iRu9j85dj8o918ubWeco7/XZ1AZrqrP4b2jJLCEU5Iw7uyT4GrK fdPQ==
X-Gm-Message-State: ALQs6tCeVw6WN/Zd9C/4aiSBnYiVkyprL2apPnicKXWoe0K0mMjFdcV4 7kTC6Q4ofxM9Di3mA50IXuB9FrXR9rBHMR8CHFr1HMAO2SSXFto36R6J3uCMsUeakgXBZ4urKjt A75YXSRWWsACvOIzGRWQn
X-Google-Smtp-Source: AB8JxZoiH1Y4cBjoHMilIXDgGfnUy2xeTTAkLFI72kPxtlhvHjDhI4vliAg+78LAaMK5ZDpZ6guHwGvjllWZcAw6LnY=
X-Received: by 2002:a24:641:: with SMTP id 62-v6mr6602805itv.89.1525804373728; Tue, 08 May 2018 11:32:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Tue, 8 May 2018 11:32:22 -0700 (PDT)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 8 May 2018 12:32:22 -0600
Message-ID: <CA+k3eCSjtPkVicMTz+u5047mRJc+85mm1Ok3-W5MJ+QnVEUFfw@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, IETF Tokbind WG <unbearable@ietf.org>, tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b18229056bb603a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/boDljKULpGcKpOLuEVeJf9CogE8>
Subject: [Unbearable] clarifying Include-Referred-Token-Binding-ID (was Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT))
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: Tue, 08 May 2018 18:33:00 -0000

On Tue, May 8, 2018 at 12:06 AM, Adam Roach <adam@nostrum.com> wrote:

> §5.3:
>
> >  When a client receives the Include-Referred-Token-Binding-ID header,
> >  it includes the referred token binding even if both the Token
> >  Provider and the Token Consumer fall under the same eTLD+1 and the
> >  provided and referred token binding IDs are the same.  Note that the
> >  referred token binding is sent only on the request resulting from the
> >  redirect and not on any subsequent requests to the Token Provider.
>
> I think this needs some clarification about handling of multiple
> redirections of
> the transaction. E.g.: Token Consumer sends a 3xx to redirect the user to a
> Token Provider (using, perhaps, an endpoint that is in the process of being
> migrated), and then the Token Provider sends an additional 3xx to get the
> client to the correct server.  Presumably, the inclusion of the referred
> token
> binding should survive both redirections, but this text might be read as
> preventing that.



To the best of my recollection and understanding the intent of the document
and WG is that that first referred token binding does not in fact survive
multiple redirections.

In the example you have, when the Token Provider sends an additional 3xx to
get the
client to the correct server, if it includes the
Include-Referred-Token-Binding-ID response header, then the resulting
request to that correct server would include a referred token binding but
with the token binding ID used by client with the Token Provider. And if
that additional 3xx did not have the response header, then the resulting
request to that correct server wouldn't include a referred token binding at
all.

The Include-Referred-Token-Binding-ID response header informs the clients
to send the referred token binding only on the request resulting
immediately from the redirect that had the header. That's the complete
scope of its effect. If the next response has a
Include-Referred-Token-Binding-ID response header, then the process repeats
itself but does so independently from any previous requests/responses.

§5.3 in general is meant to specify this behavior. The text you quoted, I
think, is just meant to clarify that both provided and referred are sent
even when they are the same token binding ID because both servers fall
under the same eTLD+1. And that the referred is only sent on that first
request resulting from the 3xx.

It seems there's some ambiguity in the draft around this behavior that
should be clarified. I'm honestly not sure what text or changes to propose
to do that, however, as my rambling above probably demonstrates. Perhaps
the authors can step in here...

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._