Re: [SECMECH] Continuing my rant about EAP vs GSS-API...
Nicolas Williams <Nicolas.Williams@sun.com> Tue, 09 August 2005 06:53 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NzJ-0007qX-8I; Tue, 09 Aug 2005 02:53:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NzG-0007nu-VB for secmech@megatron.ietf.org; Tue, 09 Aug 2005 02:53:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15475 for <secmech@ietf.org>; Tue, 9 Aug 2005 02:53:19 -0400 (EDT)
Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2OX4-0004Q2-Jc for secmech@ietf.org; Tue, 09 Aug 2005 03:28:20 -0400
Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j796rHvU015793 for <secmech@ietf.org>; Tue, 9 Aug 2005 00:53:17 -0600 (MDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j796rGLE006531 for <secmech@ietf.org>; Tue, 9 Aug 2005 00:53:17 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j796rGfv019229; Tue, 9 Aug 2005 01:53:16 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j796rFTS019228; Tue, 9 Aug 2005 01:53:15 -0500 (CDT)
Date: Tue, 09 Aug 2005 01:53:15 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Pasi.Eronen@nokia.com
Subject: Re: [SECMECH] Continuing my rant about EAP vs GSS-API...
Message-ID: <20050809065315.GR18081@binky.Central.Sun.COM>
References: <B356D8F434D20B40A8CEDAEC305A1F24CD2F9A@esebe105.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F24CD2F9A@esebe105.NOE.Nokia.com>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: secmech@ietf.org
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org
On Tue, Aug 02, 2005 at 01:07:09PM +0300, Pasi.Eronen@nokia.com wrote: > (Continuing and clarifying my comment in the BoF today...) Thanks! > GSS-API establishes a "security context" between a client and a > server. Depending on the GSS-API mechanism, establishing the security > context may use the help of a "trusted third party", either off-line > (like CA) or on-line (Kerberos KDC). The following is an aside. The meat of my reply is further below, though I can summarize it thusly: we're in violent agreement. The GSS-API is, or, rather, has been strictly a two-party framework. But the extensions to the GSS-API being pursued at the KITTEN WG seem to allow for modelling the typical three-party EAP situation. Joe and I have discussed this many a time, here is an outline: - The EAP peer is as to the GSS initiator - Depending on the mechanism the GSS acceptor may be as to the EAP server or as to a NAS, with the GSS mechanism being required to bridge the gap when the GSS acceptor is as to a NAS - Either way there is a third party that can be named and bound into the exchange using GSS naming extensions - EAP key derivation is as to the KITTEN GSS_Pseudo_random() extension - ... > EAP includes only the communication between the client and "trusted > third party" (EAP server), but it does not establish a security > context between the client and the service. But that's exactly what > people interested in using a security framework (like ISMS or 802.11) > would like to do! So just EAP alone is not really a framework you can > compare with GSS-API. I believe that some EAP methods can provide enough facilities to build GSS mechanisms out of them, much like Kerberos V. See below. > To make this comparison more accurate, we _have_ to consider the real > "EAP+AAA" framework, instead of claiming that they're totally ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > separate. ^^^^^^^^ Which neither Joe nor I claim. > Of course, it's still possible to e.g. analyze an EAP mechanism > without considering AAA. The result of this analysis could be e.g. > that the mechanism has certain security properties. But from the > point of view of applications, what really matters is the security > properties of the whole framework (or this EAP mechanism when used > within this framework). These don't trivially follow from properties > of the building blocks (just like AES being secure doesn't make all > EAP methods that use AES secure). Just to be clear, neither Joe nor I nor anyone else (to my knowledge) have put forward any concrete proposal for GUAM that haphazardly mixes off-the-shelf components and claims to have properties that are the sum of the such components. > In particular, an application like ISMS is really concerned with > "ok, I have this security context that I'll use for protecting my > application-specific communication. What properties does this context > have? Who is the other party I'm sharing this context (and keys > contained in it) with?" Right. This makes the GSS-API, SASL, TLS, all good matches for ISMS. The GSS-API and DTLS are better matches if datagram-type transports are desired for ISMS. Unfortunately the GSS-API and [D]TLS have disjoint sets of mechanisms available, thus ISMS' quandary, thus GUAM, thus SECMECH. While we're at fixing the multi-framework mechanism set disjointness problem we notice that EAP mechanisms (decent ones anyways) have fundamental properties that are also required of GSS-API and SASL mechanisms (see below). Thus the GUAM proposal encompasses EAP as well as the GSS-API. > An analysis of an EAP mechanism, like EAP-TLS, can answer the question > "who is the other party I'm sharing the EAP-SA with" (just look at the > TLS server certificate). But EAP alone cannot answer the > application's real question "who is the other party I'm sharing this > context with". Neither can the GSS-API! This is the mechanisms' duty. The GSS-API does come with, well, an API, and this API does allow for such questions to be asked and answered, but note that the answer is allowed to be "dunno," as in GSS_C_NT_ANONYMOUS. Presumably EAP methods can provide mutual authentication, user<->server, user->server + server->NAS + EAP channel binding, ... > Or in other words, GSS-API mechanisms (that do mutual authentication) > do mutual authentication (and set up a security context/association) > between the client and the service (application endpoint). EAP > mechanisms do mutual authentication between the client and the > EAP server; and that doesn't automatically mean mutual authentication > between the client and the service/application endpoint. You've missed the point... Just as EAP consumers can use EAP to establish keys shared between EAP peers and NASes so can GSS mechanisms made from EAP ones establish keys and authentication between GSS initiators and acceptors, even when the GSS acceptor is as to a NAS. You seem to be arguing that the GSS-API and EAP are fundamentally incompatible in ways similar to the GSS-API vis-a-vis Kerberos V. And indeed they are. Yet we have a Kerberos V mechanism for the GSS-API; it doesn't provide certain features that some Kerberos V applications might need, but it does provide a two-party mechanism. > This difference is IMHO not an insignificant minor detail, and > needs to be taken into account when talking about "bridging" > EAP and GSS-API mechanisms, or designing mechanisms that can > be used in both frameworks, etc. So we're in violent agreement :) > I'm not saying this deficiency in the EAP+AAA framework is serious > problem in all cases. In some environments the authentication > requirements in different directions are quite different. > > For instance, in 802.11 network access the client's/user's identity > is usually much more important; for the access point/network side, it > may be enough to verify that "this is someone the TTP (EAP server) > trusts". This is essentially what EAP+AAA framework today does. But surely the NAS wants to authenticate the EAP server -- otherwise one may impersonate EAP servers to NASes. Between authentication of users to EAP+AAA servers (possibly mutual), authentication of EAP servers to NASes, EAP channel bindings and EAP keying there's enough to build GSS mechanisms (names, mutual authentication and shared keys with which to key per-message tokens and the new GSS PRF for established security contexts). Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech
- [SECMECH] Continuing my rant about EAP vs GSS-API… Pasi.Eronen
- Re: [SECMECH] Continuing my rant about EAP vs GSS… Nicolas Williams
- RE: [SECMECH] Continuing my rant about EAP vs GSS… Salowey, Joe