Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

Brian Campbell <bcampbell@pingidentity.com> Tue, 05 June 2018 18:05 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 7600F126F72 for <unbearable@ietfa.amsl.com>; Tue, 5 Jun 2018 11:05:23 -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=ham 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 LHP9x36o1MiO for <unbearable@ietfa.amsl.com>; Tue, 5 Jun 2018 11:05:21 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 14D79128CF3 for <unbearable@ietf.org>; Tue, 5 Jun 2018 11:05:21 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id d22-v6so4430737iof.13 for <unbearable@ietf.org>; Tue, 05 Jun 2018 11:05:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jwd5S+3+zfEUsDp6K2xm8cqJ8Z51usG4p1c5+2Ocvvo=; b=AC44+T8g0wdQiO+W3Y92RMoYzplRKuxFOQHNobIXAwkGJrtWKH2JPSaEN75H6YqYor 49Ir/acsvzIsoqOIlyIc3dDIQQtCrcWzCXz41QX5eBDwwkTpASn72U4liyX3IB8ocG7l uY+vE5mw0vcEsWd+H7otc/cIrjK8EPwoUH3JQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jwd5S+3+zfEUsDp6K2xm8cqJ8Z51usG4p1c5+2Ocvvo=; b=XJJI/Wne+cuiGFcdaVWl34uZCpgkzUdv41V6R2XV/ISUyAYVTuOE5XO6rY1GdKq8t5 NwyQJxP+q2bZ2TmdWfp535Jxc1091QfCOICke7bZQmvh4Wka7Xa5ZBPnlTXpsuuWVquY H2pd5Ac16nXtJ+OFlHcw+4CTknie5JZbw7akYA+X1rWlEZEsfrMXC0nOwgTNvbnbwUDP VNSOE3DSfFftNs4Aty05FRFUdPCl7hxyOToC4bJBmy0kXpiZRtOqkrqk/6Yv6bY+OAHV /w/bpHK0y47mSF/wbakPWerc+7ncgCEtJ+lCFF6Rr9K7GMUzj6mPQy3UJMx75T9KWo9t 6YQQ==
X-Gm-Message-State: APt69E1VWvYFocKMbmauPhTVC1bUgnALbgJqSgzFPorqY8URTJEp80M7 XqMpuZ0/Ni3vFYThxzmXXBUhGna1xTnMn/cGWA8kue+ccMrVWBW95uxosA5emI5gLx7xT8kbVZ2 4V/n8imQ7PeMcMlztLRlR
X-Google-Smtp-Source: ADUXVKLRRdnbTXam2CzgcRJAi0JdGX4oqBibusvSoAJH9XRO88HISuCEjFlvb+j7LGPUC8zqETKxPVxIDbUvVKB7+gQ=
X-Received: by 2002:a6b:588:: with SMTP id 130-v6mr19166878iof.282.1528221920279; Tue, 05 Jun 2018 11:05:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 11:04:49 -0700 (PDT)
In-Reply-To: <SYBPR01MB3546DA27767E7E13FBC28FEAE5660@SYBPR01MB3546.ausprd01.prod.outlook.com>
References: <152774743559.22620.13488651600482711493.idtracker@ietfa.amsl.com> <5ab325d2-4227-5ef0-747b-94a556f0acb5@mnt.se> <CA+k3eCSwmO=6gYKg=LBH5KxYgzwuobJRMrKiCiP4kuvVO3wJhQ@mail.gmail.com> <c8f83d1a-ca5a-a7b1-aefd-a86944bb58e5@mnt.se> <CA+k3eCQkwKbAgDB7Wd7Dt0ztdccnU6kkvEQkFcQzZr3+SGm37w@mail.gmail.com> <SYBPR01MB3546DA27767E7E13FBC28FEAE5660@SYBPR01MB3546.ausprd01.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 05 Jun 2018 12:04:49 -0600
Message-ID: <CA+k3eCQweJNvm-Nt9OivaPP3P9vxN38wxvY4vW_X5+BcdRpDKQ@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Cc: Leif Johansson <leifj@mnt.se>, IETF Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b26050056de8e487"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/PVgb267dBdzC0cUQ_PkfNlQg33U>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.26
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, 05 Jun 2018 18:05:24 -0000

Thanks for the review, James. Replies to the individual comments are inline
below.


On Mon, Jun 4, 2018 at 6:34 PM, Manger, James <James.H.Manger@team.telstra.c
om> wrote:

> draft-ietf-tokbind-ttrp-03 looks ok.
>

Thanks, that is high praise indeed!


There is nothing to distinguish between Token Binding being offered by the
> TTRP but not accepted by the client vs not being offered at all. I’m not
> sure if that matters. Perhaps it only makes sense for a server to look for
> these headers if it is sure all the reverse proxies that serve it support
> Token Binding and are configured to insert these headers.
>

Yeah, there is nothing provided to the back-end server to distinguish
between those two cases. But I can't think of a reason that the back-end
would do anything meaningful with that distinction.  The client and TTRP
are doing token binding or they are not and that is what gets conveyed
(along with the TB ID, of course).



>
> Minor typos:
>
> There is no example of Sec-Other-Token-Binding.
>

I was somewhat hesitant about adding support at all for conveying token
binding types other than provided and referred. That and a touch of
laziness led me to not do an example for Sec-Other-Token-Binding in the
last draft revision. But it is somewhat incomplete or inconsistent without
it. I'll add such an example in the next draft.



>
>
> 2.1.2 ABNF for EncodedTokenBindingType doesn’t strictly need "A" / "a" as
> “ABNF strings are case insensitive” [RFC5234 section 2.3
> <https://tools.ietf.org/html/rfc5234#section-2.3>] so just "A" would do.
> Having both does reinforce that upper and lower case can be used. Re-using
> the HEXDIG core ABNF rule would be slightly better, with a case-insensitive
> mention in the text.
>

I'd chosen not to reuse HEXDIG so as to allow upper and lower case.
However, I'd overlooked the case insensitive nature of ABNF strings you
referenced there. I think you're right that using the HEXDIG core ABNF rule
along with with a case-insensitive mention in the text is somewhat better.
I'll update accordingly.



>
> Typo: section 3: “… they are **a** single logical server”
>

Will fix.


Thanks!





>
> --
>
> James Manger
>
>
>
> *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Saturday, 2 June 2018 2:07 AM
> *To:* Leif Johansson <leifj@mnt.se>
> *Cc:* IETF Tokbind WG <unbearable@ietf.org>
> *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for
> IETF 102
>
>
>
> It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-03
>
>
>
> On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <leifj@mnt.se> wrote:
>
>
>
> On 2018-06-01 00:49, Brian Campbell wrote:
> > I'd like to request some agenda time to cover the TTRP draft, which will
> > likely consist of an overview and status update (with some gratuitous
> > photos of recent IETF meeting locations) and a plea to move towards
> > WGLC. Thanks!
>
> In order to facilitate that... could we get some folks to review
> the TTRP draft before 102?
>
> Maybe... please... ??
>
>         Cheers Leif
>
>
>
>
> *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.*
>

-- 
_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._