Re: [Unbearable] More thoughts on reverse-proxies

John Bradley <ve7jtb@ve7jtb.com> Thu, 03 August 2017 16:09 UTC

Return-Path: <ve7jtb@ve7jtb.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 79FE01324A1 for <unbearable@ietfa.amsl.com>; Thu, 3 Aug 2017 09:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 HM3flTRAUIKO for <unbearable@ietfa.amsl.com>; Thu, 3 Aug 2017 09:09:11 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 1B1B81324BE for <unbearable@ietf.org>; Thu, 3 Aug 2017 09:09:11 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id t128so8120080lff.2 for <unbearable@ietf.org>; Thu, 03 Aug 2017 09:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8MyVpKoRYADk01ZuoGYyc+Z5DSBUd6E3/9h18qVy46s=; b=KLTYp7QSdc6rUVHpBJyixWrOZiIPDMy4BYJ2XQi5B2QNVHevosrGFMmv95q3F05SnD Hl4r/xesXA63fVfKbSNYx9uVNo7jHPmwhemXm38zFqj0oAS8Ua+4FfhoHYEBRpWZFJPy Ch9m9/5b76N6j43CxMOZQbHssevaRCYFRvDdtXASBIBXWwcz8n6FS4w6m6Q9u7pbyOUR KFqc6ki7HDvnhiykYZDL9XlkasXsZC/kr5PQZ0OqCD2Odw+DS40HlKcEwtIJ63IFyFea NcnwrMvZQrEHcUWZtBZMaVQW3cC3h1wQnx2trutkAw4hfG7BUmCYpcZMcurAo6e+39Jm lThg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8MyVpKoRYADk01ZuoGYyc+Z5DSBUd6E3/9h18qVy46s=; b=l1jIW+deGKotM1iZwd2MB9Tvg43bE18v2erzbz0uVnb0WxHVIbekykELvIxHPKqaBY HK8aSoaZzgMWop69s2U6xSWyGRUDVNTAFMs2jMYLUNv6lkVjHMttirHbCeEn7Wcgui+E 0mGLTsAV1qMeDG2FL/eUlcyvbWQQao7fP3RIBa9M32A2mbOvAanrjAPCfwB/kxZkh/pf XAYpgTvugX+Og/YJSX7vc9AD0c7DTmEMK4R33kZ0oaWxTVUg/zkRUAYSGaadt0uaLrt0 OvJeou45neI2RHwRdhye9KPskDFtNG1HgCdZeUiZ+rEFAfjFhJ1mQvkHwr7C3UOtweeQ T7wg==
X-Gm-Message-State: AIVw113K4r4+QEleUp09MF0Q2oU2wjBl9UKPMlMhj48I/mqJt/AUaNK9 oEdeapdCNfwxK2nJ
X-Received: by 10.46.25.218 with SMTP id 87mr1041003ljz.103.1501776548790; Thu, 03 Aug 2017 09:09:08 -0700 (PDT)
Received: from [192.168.86.103] ([191.115.81.54]) by smtp.gmail.com with ESMTPSA id p76sm6724491lfe.2.2017.08.03.09.09.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 09:09:08 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <06C33AEC-A825-486A-B9A3-86DB31EDF89B@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 3 Aug 2017 12:09:03 -0400
In-Reply-To: <CAH9QtQG_gpeqQD+_6xDMNg6F1RTYOEFXq1nHwnmzMePP4-EKaA@mail.gmail.com>
Cc: Tokbind WG <unbearable@ietf.org>
To: Bill Cox <waywardgeek@google.com>
References: <CAH9QtQG_gpeqQD+_6xDMNg6F1RTYOEFXq1nHwnmzMePP4-EKaA@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1a6394c156f10555db99b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/z6eaj3AawuOwiB5YTkTSKaWBSiI>
Subject: Re: [Unbearable] More thoughts on reverse-proxies
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: Thu, 03 Aug 2017 16:09:13 -0000

The version of the spec passed the EKM to the backend.    The WG asked the author to change it to this method.

Both work and have advantages and disadvantages.   One problem with the EKM approach was the possibility of multiple EKM sizes when the original draft was done.   However a separate decision was made to fix the EKM size for this version to a single value making the EKM approach simpler.   In that case it would be the EKM header that would need sanitizing.

I suspect documenting both methods in a spec will just add to the confusion and delay support in products.

Nothing stops someone from implementing both in a product if they see value.

I think there may be an advantage to the EKM method if new token binding types are added( I think MS may be using some but Tony as not provided any details to the WG yet)

With having the TTP validate the provided and referred token binding ID the TTP has to know a lot more and would need to be updated to validate other types.

With the EKM method the proxy is much simpler and jan just extract the EKM and allow the Sec-Token-Binding header to pass through untouched.

The EKM approach is probably best for more sophisticated deployments as alter apps need to validate the token binding.

The validate in TTP method covers all current documented use cases and could be extended in future.  It is much simpler for apps and may be best to drive adoption.

I do think the NGINX approach has value, but question if it really needs standardization and what value that would have.   It is strictly focused on cookies.  I thought NGINX stripped the over signing before it passed the cookie to the app, so that it was transparent.   The only thing that might see the wrapped cookie is the browser and I don’t know that standardizing the wrapping so that browser JS can inspect it has value.

I could perhaps see it if you hat TTP from multiple vendors that all needed to deal with the same cookie.  That might be a reason if someone wanted to write it up as a ID and submit it to the WG.    I don’t know if people would see value in working on it for what might be considered a edge case.

Thanks for the feed back
John B.

> On Aug 3, 2017, at 11:47 AM, Bill Cox <waywardgeek@google.com> wrote:
> 
> I like the TTRP spec, but there are at least two other modes of operation a reverse proxy might want to use.
> 
> The simplest way for an organization that uses NGINX to enable token binding is to use Piotr's token-binding module <https://github.com/google/ngx_token_binding>.  Piotr did great work on that, but there is room for improvement, such as using a more modern and shorter MAC appended to the cookie.  Would it make sense to have an RFC for this mode of operation?  That way, javascript that manipulates the cookie cleartext would be simpler to write: it would only have to look for one token-bound cookie format.
> 
> The other mode of operation is one I favor for large scale deployments: The proxy could compute the EKG value needed for verification and pass this in a new header to the back-end.  Then, the cookie server could verify cookie TB signatures in the back-end.  This scheme has several advantages:
> 
> 
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable