Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03

Sam Hartman <hartmans@painless-security.com> Tue, 18 June 2013 14:19 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5177C21F9F12; Tue, 18 Jun 2013 07:19:16 -0700 (PDT)
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=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWb5-QCOOfSL; Tue, 18 Jun 2013 07:19:10 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6240121F9EE1; Tue, 18 Jun 2013 07:19:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id BC2032013A; Tue, 18 Jun 2013 10:15:09 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd8b3jpw8fH3; Tue, 18 Jun 2013 10:15:08 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 18 Jun 2013 10:15:08 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 525ED80046; Tue, 18 Jun 2013 10:18:50 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: "Black, David" <david.black@emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com>
Date: Tue, 18 Jun 2013 10:18:50 -0400
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> (David Black's message of "Mon, 17 Jun 2013 22:39:28 -0400")
Message-ID: <tsl38sfbiyd.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: General Area Review Team <gen-art@ietf.org>, "abfab@ietf.org" <abfab@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 14:19:16 -0000

>>>>> "Black," == Black, David <david.black@emc.com> writes:

    Black,> The next to last paragraph on p.3 begins with this sentence:

    Black,>    For these reasons, channel binding MUST be implemented by
    Black,> peers, EAP servers and AAA servers in environments where EAP
    Black,> authentication is used to access application layer services.

    Black,> It appear that this "MUST" requirement applies to all uses
    Black,> of EAP, including network access authentication, not just
    Black,> application layer access authentication.  If so, that's not
    Black,> immediately obvious from the text, and an additional
    Black,> sentence should be added to make this clearer.  If not, the
    Black,> above sentence needs to exclude network access
    Black,> authentication from that requirement.


I know you're correct that AAA servers and EAP servers need to implement
channel binding for network access in such environments.
I'm not sure whether peers only doing network access SHOULD implement
channel binding or MUST implement channel binding.

Practically speaking, it will be a while before peers implement channel
binding for network access.
The sorts of attacks that result without channel binding are attacks
where a peer thinks it is doing network access authentication but what
it's really doing is helping an attacker access an application.
If all the application access peers support channel binding, then you
could potentially require the eap-lower-layer attribute or similar for
application authentication and work securely in environments where peers
for network access have not been updated yet.
It's also kind of tempting to stick our head in the sand and just add
the clarification that "yes, we mean network access too."

--Sam