[kitten] Review of draft-ietf-kitten-channel-bound-flag-04
Sam Hartman <hartmans-ietf@mit.edu> Mon, 18 February 2019 21:29 UTC
Return-Path: <hartmans-ietf@mit.edu>
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 A240D13103B for <kitten@ietfa.amsl.com>; Mon, 18 Feb 2019 13:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.253
X-Spam-Level:
X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] autolearn=no 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 a2sWETkf2i-T for <kitten@ietfa.amsl.com>; Mon, 18 Feb 2019 13:29:43 -0800 (PST)
Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1C6131010 for <kitten@ietf.org>; Mon, 18 Feb 2019 13:29:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id 3C1E52168A for <kitten@ietf.org>; Mon, 18 Feb 2019 16:29:42 -0500 (EST)
Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXQN8FJuemb3 for <kitten@ietf.org>; Mon, 18 Feb 2019 16:29:41 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (c-24-91-242-186.hsd1.nh.comcast.net [24.91.242.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA for <kitten@ietf.org>; Mon, 18 Feb 2019 16:29:41 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4CB3FC0944; Mon, 18 Feb 2019 16:29:40 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: kitten@ietf.org
Date: Mon, 18 Feb 2019 16:29:34 -0500
Message-ID: <tslbm38vl8h.fsf@suchdamage.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/D84ASPLwb3j-PY4KuPNmXoqChFs>
Subject: [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: Mon, 18 Feb 2019 21:29:46 -0000
I've reviewed this document at the request of one of the authors, and here are my comments: 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. 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. 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. However, by jumping to the conclusion that we're fixing a flaw, I think we approach interoperability and operational aspects with inadequate thought. I think we discard some of the options too early. My past experience is that when we take short cuts like that, we find ourselves frustrated later when we discover things we overlooked. 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. 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. 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. I think the current draft has several shortcomings: * I think that it inaccurately describes what RFC 2743 says and so it does not call out backward incompatible changes. * I think that it inaccurately describes what current implementations do. * I think that more consideration needs to be given to situations where one side supports the channel bound flag and the other does not and what if any signaling changes are required. * I think it does not consider behavior when mutual authentication is not requested. * I'm concerned that in thinking about channel binding we have not given adequate thought to how channel binding interacts with proxies, reverse proxies and the like. I'm concerned that this draft makes that situation worse, and so I'd recommend exploring that at least enough to understand whether I'm right. * Please get review from multiple implementors before standardizing the create_context stuff. In particular, do you want to take inputs like a credential and/or a flag indicating the context is for initiation or acceptor. If yo,u've gotten review including from folks like Luke and they are happy, then this is great. It seems good for API users at least. Here are my specific comments: >Note that it would be useless to allow security context > establishment to succeed when the initiator does not provide channel > bindings but the acceptor does, at least as long as there's no > outward indication of whether channel binding was used! An exclamation in an IETF document is a good sign that you're letting your emotions get ahead of your technical content and perhaps you should take a step back. I think the above quote is a good example. You don't get MITM protection if the initiator provides channel binding and the acceptor does, but it can be useful none-the-less. Assuming that an attacker cannot convert a context token that has channel bindings into one that does not, and initiators know acceptors are providing channel bindings, then initiators know that if they provide channel bindings then the channel bindings are validated. That can provide you defense in depth, for example, binding channels to a TLS channel binding in applications where you also validate the PKI and have good trust anchors. It cannot be sufficient alone to provide MITM defense. However, additional layers of defense (provided they do not trigger false negatives) are valuable in security. Please rephrase to focus on the characteristics of the system rather than judgments of those characteristics. > o Whenever both the initiator and acceptor have provided > input_channel_bindings to GSS_Init/Accept_sec_context() and the > channel bindings do not match, then the mechanism MUST fail to > establish a security context token. (This is a restatement of an > existing requirement in the base specification.) Actually, as best I can tell, RFC 2743section 1.1.6 disagrees with this. It looks in RFC 2743 like channel bindings are optional for a mechanism to use. I think it's reasonable that if a mechanism supports channel bindings, then if both the initiator and acceptor provide channel bindings they must validate for context establishment to succeed. > o Whenever the acceptor application has a) provided channel bindings > to GSS_Accept_sec_context(), and b) not indicated support for the > ret_channel_bound_flag flag, then the mechanism MUST fail to > establish a security context if the initiator did not provide > channel bindings data. This requirement is critical for security > purposes, to make applications predating this document secure, and > this requirement reflects actual implementations as deployed. Actually, this behavior is inconsistent with RFC 7055 section 5.6.2 and with the Moonshot implementation of the ABFAB GSS-API mechanism. In that mechanism, if the initiator provides null channel bindings, the acceptor channel bindings are always ignored. I'm not seeing the security issue here. If you are using channel bindings as a MITM defense rather than as an additional layer of security, you need to do something like SASL does and have a plus and minus varient of your protocol and always pass in channel bindings. There's also what I think is a real operational issue here. You may not be able to know what your channel bindings are on an acceptor. Depending on whether you are behind a TLS accelerator, reverse proxy or the like, it may affect your ability to know your channel bindings. I > o Whenever the application has a) provided channel bindings to > GSS_Init_sec_context() or GSS_Accept_sec_context(), and b) > indicated support for the ret_channel_bound_flag flag, then the > mechanism SHOULD NOT fail to establish a security context just > because the peer did not provide channel bindings data. The > mechanism MUST output the ret_channel_bound_flag if both peers > provided the same input_channel_bindings to GSS_Init_sec_context() > and GSS_Accept_sec_context(). The mechanism MUST NOT output the > ret_channel_bound_flag if either (or both) peer did not provide > input_channel_bindings to GSS_Init/Accept_sec_context(). This > requirement restores the original base GSS-API specified behavior, > with the addition of the ret_channel_bound_flag flag. I think we need to consider the transition period here. What happens when you have a new initiator talking to an old acceptor or vice versa.Are you planning on introducing new over-the-wire signaling so that an acceptor can say something like "I'm setting up your context, but your channel binding didn't verify?" For example in RFC 7055, the channel binding data is sent as a checksum from initiator to acceptor. The acceptor either sends back a final token or sends back an error depending on whether it accepts the bindings. How, without protocol changes would we meet this requirement. Similarly, I think Kerberos works the same way in the mutual authentication case. In the non mutual authentication case, I don't think the initiator even learns whether the acceptor validated the channel bindings.
- 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