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

Brian Campbell <bcampbell@pingidentity.com> Thu, 07 June 2018 22:23 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 C8E96131138 for <unbearable@ietfa.amsl.com>; Thu, 7 Jun 2018 15:23:15 -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 YYMx26sPDhgr for <unbearable@ietfa.amsl.com>; Thu, 7 Jun 2018 15:23:11 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 D226F130DD8 for <unbearable@ietf.org>; Thu, 7 Jun 2018 15:23:10 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id a3-v6so26161itd.0 for <unbearable@ietf.org>; Thu, 07 Jun 2018 15:23:10 -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=B2Z3sutyXUcOCB9hR+JPYPNs3Ftran5L/zJCzP1p5W8=; b=bWBW3qFP6kq5kVwz288pruTLGAoX/Bf3Ju0tubu6o2j2S2Ee1X/CHZXTQubtou9Pif 3syzl114pxm6YF5OUBoLEUY5N8x3rM1s1h9wghScTB+3T0Ou9EYo7Xvbzuk38FwTHVWs QaepAjHub0l/aPCNBHKkUFSATwqk5qDvODiyo=
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=B2Z3sutyXUcOCB9hR+JPYPNs3Ftran5L/zJCzP1p5W8=; b=mVCYFgrhDE3PZgmU/UN/koV9mq1CX9+mqWFKS0SA22rNipjeBhd38xAImlA6TsK797 CVCfeykclbBAI1MuKWZh9QWZToHQepLxPNIgJ3Oju6yrwPLl0gbfVPvnagu9h/G4QYvP aML2PjOMjYZeMBvzmUVmBc9JImrst9vekN2jXCVw0uxKXpZrvPd6OdMVuggTiF4yD83z msCpb4hxUoF4mF8aroZyqmq1g8I/blKd43kHbmODP2Lkmv707RKgIoOOeXFhqBeL4U2R mDx1PNHPMNyQi+p9I5P90r7mYMtTr1vRCaOtBGwdP6xbFIeAwGHvqYBn3vkmyQHY7KQz qh2A==
X-Gm-Message-State: APt69E3KZNxZvg7X/ej9gnq7RXeQ1+i50ljsSypjzllCK+T0dHKIze0Y QstN4RSr5MGqWdVkV7OZ0NXIoHq36YtjpCh6hvJ/qV33WtBdcP99X9xhwihUnB4w4W0E3iAEjuu Zo9XAHuTlrZ5J4rMl/Bky
X-Google-Smtp-Source: ADUXVKIGEWzPLUjLpxIu9AGITj+WsOqQIoiApWUaxhXn8cRJrw9ahB5dd+cSsggCzJrRMa+VzJH2dDKNF9au6R/MAjE=
X-Received: by 2002:a24:ed4a:: with SMTP id r71-v6mr3683663ith.53.1528410189877; Thu, 07 Jun 2018 15:23:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 15:22:39 -0700 (PDT)
In-Reply-To: <DM5PR21MB0507D809A381912B03CDEB3C8C640@DM5PR21MB0507.namprd21.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> <DM5PR21MB050756924C75D2A4CB31826C8C650@DM5PR21MB0507.namprd21.prod.outlook.com> <CA+k3eCS-vU_cCqgJ-fkoDyyvkqHgJp8yd_c7vLWJJa=Xw_hmOQ@mail.gmail.com> <DM5PR21MB0507D809A381912B03CDEB3C8C640@DM5PR21MB0507.namprd21.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 7 Jun 2018 16:22:39 -0600
Message-ID: <CA+k3eCQZ0TNN+axTb6FH+v7wYufhSYBLceJ6=oaa359H-vu6og@mail.gmail.com>
To: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>
Cc: Leif Johansson <leifj@mnt.se>, IETF Tokbind WG <unbearable@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007074e0056e14baac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/8UyFIuycwbbKfHkQpj-ihOwNuZ8>
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: Thu, 07 Jun 2018 22:23:16 -0000

Yeah, that's pretty much the thinking. Hopefully, TTRP is supportable with
TB X. Or the drivers for TB X can be accommodated in a way that continue to
work with TTRP unchanged. But if not, TTRPnext will be the new way with the
new TB X. And that likely will mean some new headers.

On Thu, Jun 7, 2018 at 3:58 PM, Andrei Popov <
Andrei.Popov=40microsoft.com@dmarc.ietf.org> wrote:

>
>    - Gauging WG consensus isn't particularity easy in this WG at this
>    stage but in my mind consensus is there.
>
> Our awesome Chairs can probably help confirm one way or the other.
>
>
>
>    - Nothing is future proof.
>    - Saying TTRP will work only with a specific version may or may not
>    prove true.
>
> Sure. Just trying to understand what the thinking is: if TTRP is not
> supportable with TB X, we’ll just say “don’t use TTRP with TB X, use
> TTRPbis instead”?
>
> And TTRPbis will probably define some new headers?
>
>
>
> *From:* Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
> *Sent:* Thursday, June 7, 2018 12:09 PM
> *To:* Andrei Popov <Andrei.Popov@microsoft.com>
> *Cc:* Leif Johansson <leifj@mnt.se>se>; IETF Tokbind WG <unbearable@ietf.org>
>
> *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for
> IETF 102
>
>
>
> Thanks for the review, Andrei.
>
>
>
> I'll incorporate the editorial suggestions.
>
>
>
> The design choice of having distinct Sec-Provided and Sec-Referred headers
> was intentional and aimed at making the most common cases simple at the
> application layer dealing with HTTP. The vast majority of the time there's
> going to be only the Provided and a single header that carries that value
> unadorned makes accessing that very straightforward.  Referred is the other
> defined type with defined usage in HTTPSTB so TTRP has Sec-Referred for
> that. Then there are 254 other undefined types and there was a request from
> the WG (or a portion thereof) to allow for them somehow. A separate header
> for every one of them seemed prohibitive to say the least. That's where the
> Sec-Other catch-all comes from. There are trade-offs any design choice and
> this is a bit of a hybrid but I feel it strikes a good balance of
> simplicity for the common defined cases while still accommodating others.
> Gauging WG consensus isn't particularity easy in this WG at this stage but
> in my mind consensus is there. This would, of course, be a good time for
> the WG to speak up to indicate otherwise, if that's not the case.
>
>
>
> Nothing is future proof. TTRP is intended to facilitate deployments of
> HTTPSTB. HTTPSTB isn't future proof or versioned and would need to change
> to allow for more than one referred TB ID. Saying TTRP will work only with
> a specific version may or may not prove true. And passing along the
> negotiated TB protocol version may or may not accommodate future changes.
> Future TB protocol versions may or may not even happen.
>
>
>
> The single HTTP header field-valued text was largely put in there with the
> hope/expectation that it would ease the registration process (after Jeff
> suggested something similar for the Sec-Token-Binding header, IIRC). But
> also because it was inline with the "exactly one" restriction in HTTPSTB.
> But that text could easily be removed, I think.
>
>
>
>
>
>
>
> On Wed, Jun 6, 2018 at 12:51 PM, Andrei Popov <
> Andrei.Popov=40microsoft.com@dmarc.ietf.org> wrote:
>
> The document is well-written and clear, overall. I have a few editorial
> comments and some design comments:
>
>
>
>   “Token Binding over HTTP [I-D.ietf-tokbind-https] provides a mechanism
>
>    that enables HTTP servers to cryptographically bind cookies and other
>
>    security tokens to a key held by the browser or other HTTP client,
>
>    possession of which is proven on the TLS [RFC5246] connections over
>
>    which the tokens are used.”
>
>
>
> Editorial suggestion: “…to a key generated by the client.” Whether the
> browser, HTTP client, or underlying platform hold the TB key is
> implementation-specific and probably unnecessary detail here. Proof of
> possession is discussed in the next sentence.
>
>
>
>   “The usage of the headers, both the reverse proxy adding _*it*_ and the
>
>    application server using _*them*_ to bind cookies or other tokens, are
> to
>
>    be configuration options of the respective systems as they will not
>
>    always be applicable.”
>
>
>
> Editorial: this sentence confuses me, esp. around “it” and “them”; perhaps
> it’s possible to simplify.
>
>
>
> Section 2.2: Having three separate headers: Sec-Provided, Sec-Referred and
> Sec-Other catch-all would not be my design choice. I’d suggest either one
> header with a list of all TB IDs, or a separate header for each TB ID. Of
> course, if WG consensus exists on the current design, then that’s what it
> is.
>
>
>
>    “Both "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-Binding-
>
>    ID" are single HTTP header field-valued…”
>
>
>
> Somewhat related to the previous comment: this seems to be saying that
> there cannot be more than one referred TB ID, which is fine now, but not
> necessarily future proof.
>
> TTRP seems to not be versioned; if, say, TB 2.0 uses multiple referred
> bindings per request, will we need TTRP 2.0 with all new headers?
>
>
>
> It seems that TTRP needs to be either TB version-specific, i.e. explicitly
> say “this is for TB 1.0 only, and future TB versions will require new TTRP
> specs”, or be designed as a pipeline, passing whatever bindings the proxy
> was able to verify, possibly along with the negotiated TB protocol version.
>
>
>
> Security and IANA considerations look good to me.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable <unbearable-bounces@ietf.org> *On Behalf Of *Brian
> Campbell
> *Sent:* Friday, June 1, 2018 9: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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tokbind-ttrp-03&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cbe9b45e5942241330d0908d5c7d9bbd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636634660334123449&sdata=mfl4DReC846OoQSdyJvXQ0UjMYY9zeT8Hnp2jbXviis%3D&reserved=0>
>
>
>
> 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.*
>

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