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

"Black, David" <david.black@emc.com> Tue, 18 June 2013 17:28 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 A1C5811E80E3; Tue, 18 Jun 2013 10:28:44 -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=[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 hFsFab+5vvBv; Tue, 18 Jun 2013 10:28:39 -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 4725111E80E6; Tue, 18 Jun 2013 10:28:38 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IHSaXR016150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jun 2013 13:28:37 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 18 Jun 2013 13:28:19 -0400
Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IHSIKd002504; Tue, 18 Jun 2013 13:28:18 -0400
Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 18 Jun 2013 13:28:17 -0400
From: "Black, David" <david.black@emc.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Date: Tue, 18 Jun 2013 13:28:17 -0400
Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgAYb7oMABB0QQAAClxl4A==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <tsl38sfbiyd.fsf@mit.edu> <A95B4818FD85874D8F16607F1AC7C628CF9E35@xmb-rcd-x09.cisco.com>
In-Reply-To: <A95B4818FD85874D8F16607F1AC7C628CF9E35@xmb-rcd-x09.cisco.com>
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
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 17:28:44 -0000

> [Joe]  I'm trying to get a handle on the attack mechanism here.   In this
> attack a valid network service is trying to spoof an application service?
> Since it knows the MSK it can do this if the channel-binding of the lower-
> layer into the EAP conversation is not enforced.  If the AAA server always
> enforces channel bindings for applications then it will catch the spoofing
> attempt.   The reverse case may also be an issue where an application service
> is trying to spoof a network service.

While both cases appear to be relevant, my concern started from the reverse
case - here's the draft's text describing the attack:

   One
   potentially serious attack exists when channel binding is not
   required and EAP authentication is introduced into an existing non-
   network service.  A device can be created that impersonates a Network
   Access Service to peers, but actually proxies the authentication to
   the new application service that accepts EAP authentications.  This
   may decrease the security of this service even for users who
   previously used non-EAP means of authentication to the service.

> In this case, if the AAA server
> validates that the application channel binding is not present then it can
> prevent the spoofing.  However the server MUST understand channel bindings
> even if the peers do not.   I think the document did try to capture this in
> the following sentence:
> 
> "If the EAP server is aware that authentication is
>    for something other than a network service, it too MUST default to
>    requiring channel binding."
> 
> I think we could state this a bit better as something like:
> 
> "In environments where EAP is used for applications authentication and network
> access authentication all EAP servers MUST understand channel bindings and
> require that application bindings MUST be present in application
> authentication and that application bindings MUST be absent in network
> authentication.   All network access EAP peer implementations SHOULD support
> channel binding to explicitly identify the reason for authentication.  Any new
> usage of EAP MUST support channel bindings to prevent confusion with network
> access usage. "

That text is an improvement, and it's headed in the same direction as Sam's
comment - "application bindings MUST be present in application authentication"
is a "MUST use" requirement, not just a "MUST implement" requirement.

OTOH, I'm not clear on what "application bindings" means, as that term's not
in the current draft.  Specifically, I'm a bit unclear on "application bindings
MUST be absent in network authentication" - does that mean that channel
binding must be absent, or that channel binding is optional, but if channel
binding is present, it MUST NOT be an "application binding", whatever that is?

Thanks,
--David

> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
> Sent: Tuesday, June 18, 2013 1:10 PM
> To: Sam Hartman
> Cc: Black, David; stefan.winter@restena.lu; General Area Review Team;
> abfab@ietf.org; ietf@ietf.org
> Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
> 
> 
> On Jun 18, 2013, at 7:18 AM, Sam Hartman <hartmans@painless-security.com>
>  wrote:
> 
> >>>>>> "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.
> 
> [Joe]  I'm trying to get a handle on the attack mechanism here.   In this
> attack a valid network service is trying to spoof an application service?
> Since it knows the MSK it can do this if the channel-binding of the lower-
> layer into the EAP conversation is not enforced.  If the AAA server always
> enforces channel bindings for applications then it will catch the spoofing
> attempt.   The reverse case may also be an issue where an application service
> is trying to spoof a network service.   In this case, if the AAA server
> validates that the application channel binding is not present then it can
> prevent the spoofing.  However the server MUST understand channel bindings
> even if the peers do not.   I think the document did try to capture this in
> the following sentence:
> 
> "If the EAP server is aware that authentication is
>    for something other than a network service, it too MUST default to
>    requiring channel binding."
> 
> I think we could state this a bit better as something like:
> 
> "In environments where EAP is used for applications authentication and network
> access authentication all EAP servers MUST understand channel bindings and
> require that application bindings MUST be present in application
> authentication and that application bindings MUST be absent in network
> authentication.   All network access EAP peer implementations SHOULD support
> channel binding to explicitly identify the reason for authentication.  Any new
> usage of EAP MUST support channel bindings to prevent confusion with network
> access usage. "
> 
> 
> 
> > 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
>