Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04
mrex@sap.com (Martin Rex) Fri, 08 March 2019 01:46 UTC
Return-Path: <mrex@sap.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A5D13120D for <kitten@ietfa.amsl.com>; Thu, 7 Mar 2019 17:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Yg-p7zvI14s8 for <kitten@ietfa.amsl.com>; Thu, 7 Mar 2019 17:46:42 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C03D1311E8 for <kitten@ietf.org>; Thu, 7 Mar 2019 17:46:42 -0800 (PST)
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 44Fr2S2CD5zyQ3; Fri, 8 Mar 2019 02:46:40 +0100 (CET)
X-purgate-ID: 152705::1552009600-00000213-606B97AF/0/0
X-purgate-size: 3675
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail08.wdf.sap.corp (Postfix) with ESMTPS id 44Fr2S0Rqfz30Vl; Fri, 8 Mar 2019 02:46:40 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 073E2404C; Fri, 8 Mar 2019 02:46:40 +0100 (CET)
In-Reply-To: <tslbm38vl8h.fsf@suchdamage.org>
References: <tslbm38vl8h.fsf@suchdamage.org>
To: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 08 Mar 2019 02:46:40 +0100
CC: kitten@ietf.org
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20190308014640.073E2404C@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/iZf4W95HQn9-rvg5Tr93vj-iQKA>
Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 01:46:45 -0000
Just a quick comment, I haven't been following IETF work for months... Sam Hartman <hartmans-ietf@mit.edu> wrote: > > This draft is based on the premis that the GSS-API channel binding > behavior is flawed and that there's a security problem associated with > not knowing if channel bindings are validated. Frankly, the whole idea of channel bindings is thoroughly flawed, and it _can_not_possibly_work_ whenever there are any application level gateways ("proxies") involved in the communication path, something that is pretty common in non-trivial application, and in particular in non-trivial backend servers. If you see someone using channel bindings, you can be pretty sure that they're doing some kind of seriously stupid abuse of technology. Whenever the *ENTIRE* application-level data is properly protected with gss_wrap(conf=TRUE), channel bindings will provide *ZERO* additional value, while creating a whole bunch of problems. > > I've heard this argument over the years, but never been convinced of it, > and unfortunately, this draft is filled with assertions of that fact > without any rationale. I agree, this is extremely disappointing. In particular, because a general need is asserted, although just the opposite is true, for honest and sane usage scenarios, channel bindings are useless bloat that break application level proxy traversal. > > At one level it doesn't matter much. I absolutely agree that a facility > for knowing if channel bindings are validated would be incredibly useful > and would simplify application design. That is what the "ret_flags" could be used for. There are still a few free bits left in the 32-bit output value of the rfc2744 C-bindings. > > As I write this up, I'm realizing that the draft authors seem to be > making an assumption that there are applications in the wild that pass > in channel bindings to the initiator but not the acceptor or vise > versa. The only such application I'm aware of is gss ftp, which passed > IP address channel bindings into the acceptor and optionally initiator. Yes, apparently there are. The application that I am aware of is Microsoft's proprietary Hack rfc4559 HTTP Negotiate when used with Kerberos, where TLS channel bindings are first asserted in Windows Vista (or Win7) ? But rfc4559 is a crystal clear HACK, which misuses a naked rfc1964/rfc4121 two-token Kerberos authentication as an OTP scheme, and by NOT using any of the GSS-API message protection facilities for the application data, there is *NO* binding between the application data in the HTTP request and the AP_REQ in the rfc4559 HTTP Request header, making that approach vulnerable to man-in-the-middle attacks (proxying/relaying). However, if the backend architecture uses a reverse proxy (Load Balancer / "SSL-Accelerator"), while the HTTP-layer rfc4559 processing is performed in the backend host (different machine), it is simply not possible to perform channel binding to the TLS channel (that ended on the reverse proxy). > > It would help me evaluate whether there is a security problem to > understand these applications better. > I note that SASL is not such an application. There is a serious security problem in rfc4559 HTTP negotiate. Use of TLS channel bindings for rfc4559 is a mitigation to pretend that the security problem doesn't exist. > > Regardless of whether this is a security problem, I am very supportive > of a mechanism along these lines. I think that it would simplify > application design over the approaches necessary for the gs2 family of > mechanisms. -Martin
- Re: [kitten] Review of draft-ietf-kitten-channel-… Sam Hartman
- [kitten] Review of draft-ietf-kitten-channel-boun… Sam Hartman
- Re: [kitten] Review of draft-ietf-kitten-channel-… Luke Howard
- Re: [kitten] Review of draft-ietf-kitten-channel-… Greg Hudson
- Re: [kitten] Review of draft-ietf-kitten-channel-… Sam Hartman
- Re: [kitten] Review of draft-ietf-kitten-channel-… Martin Rex
- Re: [kitten] Review of draft-ietf-kitten-channel-… Greg Hudson
- Re: [kitten] Review of draft-ietf-kitten-channel-… Nico Williams
- Re: [kitten] Review of draft-ietf-kitten-channel-… Nico Williams
- Re: [kitten] Review of draft-ietf-kitten-channel-… Greg Hudson
- Re: [kitten] Review of draft-ietf-kitten-channel-… Sam Hartman