IETF Logo Mail Archive

Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

John Bradley <ve7jtb@ve7jtb.com> Thu, 09 February 2017 18:40 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 6A4C712958C for <unbearable@ietfa.amsl.com>; Thu, 9 Feb 2017 10:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 JJVqNGvsYHFv for <unbearable@ietfa.amsl.com>; Thu, 9 Feb 2017 10:40:43 -0800 (PST)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 2EF71129583 for <unbearable@ietf.org>; Thu, 9 Feb 2017 10:40:43 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id w20so12631605qtb.1 for <unbearable@ietf.org>; Thu, 09 Feb 2017 10:40:43 -0800 (PST)
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=P9aY3icpjdjhnUDD64WJ5+n6seLd1Jrk4r+OkJ+2AhE=; b=XtmUI0LQcC6f8IPsxPzVsy2ZX0EDqvgiUDKe3MoZJQ4xNiBoYRiLtQpYRwMnittbDh GrF3A8AZcdH15JUStDW4sMtBWDKNvxxAnP/74uKb/eyfeG4N8kP06AS5LcxxFUHPW2ux IRi1GFads4PBCd0ZciTZo25Ps3Ds95Jkzhy+Nc4RoWPvWCGMEG2BP+YSqPOR9rFbpUmo 2N9s89Z4bdlbgXjkI3uBZfFgbVCosi5MN0QocNClyyuMz8Ehb7VrQZQ9Zy8mlQ2Pv3T9 kYeKJWNjOqHwTDPtCFxPhzix0EfoGT0ChSUZSHIO8QRkGmvdSkvi+E5I9nHwKmFAbVtm Vazw==
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=P9aY3icpjdjhnUDD64WJ5+n6seLd1Jrk4r+OkJ+2AhE=; b=Ks4xqH0R817/peEw4F/BMUHd2zlOpa9SzqD6hdteAKUqvNgdjkIxofzG1LVlYuDS87 M4dSrvgSABtPmcSZxba8yQzzdl9j/87zPY3dkkKTCff6hvOl4q47dV0qTEPiRgVJWHss 7O02Z+zGFwaARJEsKZ9WZtSMgitwEIZra7wpwiXPXW8G0tfs2fjoZykgf/h/FH4WpCaw hNsHUAe42WYItpCc6NWzMfER31MWdNjhdoQo3ubceO773NHbb9jXFH16BFK/Lot59EVn xHztKyMwNzBlkdiQgVDV3L2Xxdh1gQnDWqaO7QN6WnLBUnMxDrzkX2p9Vge748PIkWkG VlHw==
X-Gm-Message-State: AMke39mEh5EZarDs3xNKbCc2+ioWJa4/O5aWkxEub8AULzRzjAsVPHWXhTqubVLvlq3wIXTq
X-Received: by 10.200.37.199 with SMTP id f7mr4443203qtf.186.1486665642039; Thu, 09 Feb 2017 10:40:42 -0800 (PST)
Received: from [192.168.8.100] ([181.201.209.140]) by smtp.gmail.com with ESMTPSA id f126sm9837963qkc.47.2017.02.09.10.40.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 10:40:41 -0800 (PST)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <C9D5F321-CA4F-4359-96E8-AC436E5B2A13@ve7jtb.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_56366F2F-30DF-4916-A28E-FFB6EC9F62CC"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 09 Feb 2017 15:40:37 -0300
In-Reply-To: <CY1PR0301MB084223E0274288D9B330D16D8C450@CY1PR0301MB0842.namprd03.prod.outlook.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
References: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> <CA+k3eCSwvcKyN6t+9cTLSAJu9+5Uz27Db5NW_zy9W7Bx71gG4Q@mail.gmail.com> <CY1PR0301MB084223E0274288D9B330D16D8C450@CY1PR0301MB0842.namprd03.prod.outlook.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/JyxtFcQKG4a3w_TLjPH1E1ynTTs>
Cc: IETF TokBind WG <unbearable@ietf.org>, Brian Campbell <bcampbell@pingidentity.com>, =JeffH Hodges <Jeff.Hodges@kingsmountain.com>
Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.17
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, 09 Feb 2017 18:40:45 -0000

That may be the rub.

From a header perspective we are talking about any proxy forward and reverse.

I dont know that a proxy that doesn’t understand token binding should forward the header especially in the forward case.

What if the forward proxy is negotiating it’s own token binding  to the server?  (should a forward proxy proxy do that is perhaps another question)

I understand the desire to pass the header on in the reverse proxy case as it may make server code easier.

However I take Jeff’s point that token binding is by its nature hop by hop and if we mess with that we may get some unintended side effects.

If Brian had proposed sticking everything in one or two  new headers and removing the existing one then this would be much less controversial.

I always thought that we could use the same header on the inside of the proxy, but can see why that might mess up some other expectations.

So is token binding hop by hop?

John B.

> On Feb 9, 2017, at 3:25 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> 
> Exactly, I agree with Brian. The proxy/terminator is better positioned to know how/where TB headers are handled in a particular datacenter. And a proxy/terminator that knows nothing about TB headers should forward them on.
>  
> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Brian Campbell
> Sent: Thursday, February 9, 2017 8:38 AM
> To: =JeffH <Jeff.Hodges@kingsmountain.com>
> Cc: IETF TokBind WG <unbearable@ietf.org>
> Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?
>  
>  
>  
> On Thu, Feb 9, 2017 at 9:55 AM, =JeffH <Jeff.Hodges@kingsmountain.com <mailto:Jeff.Hodges@kingsmountain.com>> wrote:
> 
> I agree with this for security considerations reasons -- we want the Sec-Token-Binding header to be hop-by-hop in sync with the underlying TLS connection and not be "leaked" downstream unless it is a conscious decision, e.g., in the tls terminating reverse proxy (TTRP) case.
> 
>  
> But the client is only making a connection to a server and client does not know whether it makes sense for that server to forward or not. And it shouldn't know that.  Sec-Token-Binding shouldn't be listed in Connection header field by a client. 
>  
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable

v2.30.2 | Report a Bug | By Email | System Status