Return-Path: 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 AD1C0129465 for ; Wed, 29 Mar 2017 15:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 QTWCgEd-qbhr for ; Wed, 29 Mar 2017 15:35:48 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 CA2F8129573 for ; Wed, 29 Mar 2017 15:35:47 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id x125so20203583pgb.0 for ; Wed, 29 Mar 2017 15:35:47 -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=xEdn+pd3TVd1bLAkqlFQED6ZiFqOwqeMKeeenxRUFZc=; b=ayCOo7qnRObxMcUieYDXLYCJvkT47NBFtVPrAbnYY1RxH6MAN8aOwXz1zRt2FFNVCe BZfs4lRYYDTImdkwJ2o2aznamDmQOdoCSkALjCT58MRC8fX4KMJhnK5EcKbbtd21vfZZ ktp/VTW4dXBWHLhjIs2pPhEFXXDjpHX8mg65A= 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=xEdn+pd3TVd1bLAkqlFQED6ZiFqOwqeMKeeenxRUFZc=; b=GrUbrufmKqIjT4EybeNhsLrPe+WPNmx8iMKHAE/VScedAizsVzbK2uLRVdqTOMopbi FgCXlUfRxg2zrVY9cG64Vs5hxyV6oMZRN+yMjgTD0iPUtjN6OwIj76NoUB+QiIIkioDR SgIvCbbzRDfSOpgy4esRrsPFycOiJ8aSWkgiGmlhEMT1W9Q5XapGbt97JwANdET5f2Lp 85c0NC2rXsmMkFQhpt4YL+mKPZxW73HQHlFmKUMYfMiyFl82xpoaM1IhugYWvz2RHUG5 UIwRHPYA4ANFbNeGvzJYRwmzTHuS/NRuoSnM/zrpxHMw19dlT27JhgQgnAxLbPEdZaxA ok4w== X-Gm-Message-State: AFeK/H3bKr15X8luJH2XiX/BsoRKzglFWxevk7uHMrUEDfu5FNgcbbHWVkb4vKlPFpmG93+iAai3xNRYC6AJWsNq X-Received: by 10.99.121.77 with SMTP id u74mr2880236pgc.200.1490826947298; Wed, 29 Mar 2017 15:35:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.170.138 with HTTP; Wed, 29 Mar 2017 15:35:16 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 29 Mar 2017 17:35:16 -0500 Message-ID: To: Piotr Sikora Cc: Tokbind WG Content-Type: multipart/alternative; boundary=94eb2c19beb09da2ef054be632d2 Archived-At: Subject: Re: [Unbearable] Comments on draft-campbell-tokbind-tls-term 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 22:35:51 -0000 --94eb2c19beb09da2ef054be632d2 Content-Type: text/plain; charset=UTF-8 Hi Piotr, Thanks for the review and comments/questions. Attempted replies are inline below. I hope to discuss much of this stuff in more detail tomorrow from 9am-10am in Lugano during the ad hoc meeting I requested/announced on the list at https://www.ietf.org/mail-archive/web/unbearable/current/msg01338.html. Feel free to join the discussion, if you are still in Chicago and available. On Mon, Mar 27, 2017 at 2:36 PM, Piotr Sikora wrote: > Hey, > I'm a bit late to the party, so apologies if this was already discussed. > > > A backend server that receives a request from a trusted reverse proxy > > containing the "Token-Binding-Context" and "Sec-Token-Binding" > > headers decodes the Token Binding Context Message and uses its > > content to validate the encoded Token Binding Message as described in > > Section 2 of Token Binding over HTTP [I-D.ietf-tokbind-https] in > > place of information that otherwise would have come from the TLS > > connection. > > What's the value of sending both to the backend server instead of > validating the Token Binding Message at the reverse proxy and passing > only Token Binding ID (in one form or another) to the backend server? > The intended value of this approach is to keep the reverse proxy as light as possible. I got the sense that that was a desirable property from what seemed like a majority of the room during the last meeting in Seoul. If we stay with the approach, I'll add some explanation of the rational to the document. But this might not be the 'right' approach or the preferred one. I'm hoping to get more input and a better sense of the goals and preferences of people tomorrow. > Especially, since the Token Binding Message must (should?) be > validated by the TLS terminating reverse proxy anyway. > The server as a logical entity must validate the Token Binding Message. But that doesn't mean the front end necessarily has to do it. The approach in this -00 document enables a back end component of the server as a whole to do the Token Binding Message validation. But the server as a logical entity is still validating the TB message. > > Also, re-using "Sec-Token-Binding" header doesn't allow Token Binding > to be established between reverse proxy and backend server... > That's true. But I think it is okay because establishing Token Binding between infrastructure components under the same operational control doesn't really add much value. Token Binding is good for the logical endpoints of the client and server in a connection. > Actually, it doesn't allow TLS between reverse proxy and backend > server, since backend server should reject such connection, if Token > Binding protocol wasn't negotiated during TLS handshake. > Treating the different components of the server as a single logical entity with respect to Token Binding does allow LS between reverse proxy and backend server. > > > The Token Binding Context Message is a byte sequence that contains > > the concatenation of the negotiated Token Binding Protocol Version > > and Key Parameters as well as the exported keying material (EKM) from > > the TLS connection between the client and reverse proxy. The first > > two bytes are the ProtocolVersion, as defined in Section 2 of > > [I-D.ietf-tokbind-negotiation], that the reverse proxy negotiated > > with the client. The third byte is the negotiated > > TokenBindingKeyParameters (also defined in Section 2 of > > [I-D.ietf-tokbind-negotiation]). The remaining 32 or more bytes are > > the EKM from the TLS connection between the client and the reverse > > proxy, as defined in Section 3.3 of [I-D.ietf-tokbind-protocol]. > > Following from the previous comment, why all this information needs to > be passed to the backend server? Wouldn't base64url-encoded Token > Binding ID (or SHA256 hash of it) be good enough? > Something along those lines is an alternative approach at a solution. > Best regards, > Piotr Sikora > --94eb2c19beb09da2ef054be632d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Piotr,

Thanks for the review an= d comments/questions. Attempted replies are inline below.

I ho= pe to discuss much of this stuff in more detail tomorrow from 9am-10am in L= ugano during the ad hoc meeting I requested/announced on the list at https://www.ietf.org/mail-archive/web/unbearable/current/msg01338.html. Feel free to join the discussion, if you are still in Chicago and availa= ble.


= On Mon, Mar 27, 2017 at 2:36 PM, Piotr Sikora <piotrsikora@google.com= > wrote:
Hey,
I'm a bit late to the party, so apologies if this was already discussed= .

>=C2=A0 =C2=A0A backend server that receives a request from a trusted re= verse proxy
>=C2=A0 =C2=A0containing the "Token-Binding-Context" and "= ;Sec-Token-Binding"
>=C2=A0 =C2=A0headers decodes the Token Binding Context Message and uses= its
>=C2=A0 =C2=A0content to validate the encoded Token Binding Message as d= escribed in
>=C2=A0 =C2=A0Section 2 of Token Binding over HTTP [I-D.ietf-tokbind-htt= ps] in
>=C2=A0 =C2=A0place of information that otherwise would have come from t= he TLS
>=C2=A0 =C2=A0connection.

What's the value of sending both to the backend server instead of
validating the Token Binding Message at the reverse proxy and passing
only Token Binding ID (in one form or another) to the backend server?

The intended value of this approach is to ke= ep the reverse proxy as light as possible. I got the sense that that was a = desirable property from what seemed like a majority of the room during the = last meeting in Seoul. If we stay with the approach, I'll add some expl= anation of the rational to the document. But this might not be the 'rig= ht' approach or the preferred one. I'm hoping to get more input and= a better sense of the goals and preferences of people tomorrow.=C2=A0
=
=C2=A0

Also, re-using "Sec-Token-Binding" header doesn't allow Token= Binding
to be established between reverse proxy and backend server...

That's true. But I think it is okay because esta= blishing Token Binding between infrastructure components under the same ope= rational control doesn't really add much value. Token Binding is good f= or the logical endpoints of the client and server in a connection.
=C2=A0
Actually, it doesn't allow TLS between reverse proxy and backend
server, since backend server should reject such connection, if Token
Binding protocol wasn't negotiated during TLS handshake.

Treating the different components of the server as a = single logical entity with respect to Token Binding does allow LS between r= everse proxy and backend
server.
=C2=A0

>=C2=A0 =C2=A0The Token Binding Context Message is a byte sequence that = contains
>=C2=A0 =C2=A0the concatenation of the negotiated Token Binding Protocol= Version
>=C2=A0 =C2=A0and Key Parameters as well as the exported keying material= (EKM) from
>=C2=A0 =C2=A0the TLS connection between the client and reverse proxy.= =C2=A0 The first
>=C2=A0 =C2=A0two bytes are the ProtocolVersion, as defined in Section 2= of
>=C2=A0 =C2=A0[I-D.ietf-tokbind-negotiation], that the reverse prox= y negotiated
>=C2=A0 =C2=A0with the client.=C2=A0 The third byte is the negotiated >=C2=A0 =C2=A0TokenBindingKeyParameters (also defined in Section 2 of >=C2=A0 =C2=A0[I-D.ietf-tokbind-negotiation]).=C2=A0 The remaining = 32 or more bytes are
>=C2=A0 =C2=A0the EKM from the TLS connection between the client and the= reverse
>=C2=A0 =C2=A0proxy, as defined in Section 3.3 of [I-D.ietf-tokbind-prot= ocol].

Following from the previous comment, why all this information needs to
be passed to the backend server? Wouldn't base64url-encoded Token
Binding ID (or SHA256 hash of it) be good enough?

Something along those lines is an alternative approach at a solution.= =C2=A0

=C2=A0
Best regards,
Piotr Sikora

--94eb2c19beb09da2ef054be632d2--