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

"Black, David" <david.black@emc.com> Tue, 18 June 2013 14:43 UTC

Return-Path: <david.black@emc.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 3AF5911E80DF; Tue, 18 Jun 2013 07:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 AOw19EIogZJb; Tue, 18 Jun 2013 07:43:42 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 427E321E8053; Tue, 18 Jun 2013 07:43:38 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IEhaPN032387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jun 2013 10:43:37 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 18 Jun 2013 10:43:06 -0400
Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IEh5dK006895; Tue, 18 Jun 2013 10:43:05 -0400
Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Tue, 18 Jun 2013 10:43:05 -0400
From: "Black, David" <david.black@emc.com>
To: Sam Hartman <hartmans@painless-security.com>
Date: Tue, 18 Jun 2013 10:43:03 -0400
Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Thread-Index: Ac5sLtL2MQaEvFULRLupG53n6IyQQgAAT1zw
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129826522D@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <tsl38sfbiyd.fsf@mit.edu>
In-Reply-To: <tsl38sfbiyd.fsf@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
X-Mailman-Approved-At: Tue, 18 Jun 2013 09:00:43 -0700
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:43:47 -0000

Sam,

I was concerned that something along these lines was lurking in here :-(.

I think this is the crucial "running code" consideration to start from:

> Practically speaking, it will be a while before peers implement channel
> binding for network access.

Assuming that network access does not use channel binding, how does one
avoid the proxy attack on network access authentication via application
access authentication when the latter is introduced?

For environments where EAP is used for network access authentication,
the suggestion of a "MUST use" requirement for channel binding with 
application access authentication sounds like the right approach:

> 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.

Is that plausible and reasonable in practice?

This would be in addition to the "MUST implement" requirements for AAA
servers, EAP serves and peers doing application access:

> I know you're correct that AAA servers and EAP servers need to implement
> channel binding for network access in such environments.

Thanks,
--David


> -----Original Message-----
> From: Sam Hartman [mailto:hartmans@painless-security.com]
> Sent: Tuesday, June 18, 2013 10:19 AM
> To: Black, David
> Cc: stefan.winter@restena.lu; jsalowey@cisco.com; General Area Review Team;
> abfab@ietf.org; ietf@ietf.org
> Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
> 
> >>>>> "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