[SECMECH] Continuing my rant about EAP vs GSS-API...

Pasi.Eronen@nokia.com Tue, 02 August 2005 10:07 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztg4-0003rm-Ac; Tue, 02 Aug 2005 06:07:16 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztg3-0003rh-1n for secmech@megatron.ietf.org; Tue, 02 Aug 2005 06:07:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04600 for <secmech@ietf.org>; Tue, 2 Aug 2005 06:07:12 -0400 (EDT)
From: Pasi.Eronen@nokia.com
Received: from mgw-ext04.nokia.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuCV-0006Wp-Ej for secmech@ietf.org; Tue, 02 Aug 2005 06:40:47 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com []) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j72A14hZ032393 for <secmech@ietf.org>; Tue, 2 Aug 2005 13:01:05 +0300
Received: from esebh102.NOE.Nokia.com ([]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 13:07:09 +0300
Received: from esebe105.NOE.Nokia.com ([]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 13:07:09 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 2 Aug 2005 13:07:09 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F24CD2F9A@esebe105.NOE.Nokia.com>
Thread-Topic: Continuing my rant about EAP vs GSS-API...
Thread-Index: AcWXSfE8CSNIJ8A1R7ChkqJp2e5DRw==
To: <secmech@ietf.org>
X-OriginalArrivalTime: 02 Aug 2005 10:07:09.0246 (UTC) FILETIME=[F1A50DE0:01C59749]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: quoted-printable
Subject: [SECMECH] Continuing my rant about EAP vs GSS-API...
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

(Continuing and clarifying my comment in the BoF today...)

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

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.

To make this comparison more accurate, we _have_ to consider the real
"EAP+AAA" framework, instead of claiming that they're totally

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

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?"

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

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.

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.

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. 
Something like ISMS might have a similar situation, authenticating 
the identity of the SNMP manager might be much more important than 
the SNMP manager...

Best regards,

SECMECH mailing list