RE: [SECMECH] Continuing my rant about EAP vs GSS-API...
"Salowey, Joe" <email@example.com> Wed, 10 August 2005 13:51 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1E2qzM-00040P-RN; Wed, 10 Aug 2005 09:51:24 -0400
Received: from odin.ietf.org ([126.96.36.199] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qzL-0003uk-9h for firstname.lastname@example.org; Wed, 10 Aug 2005 09:51:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [188.8.131.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28610 for <email@example.com>; Wed, 10 Aug 2005 09:51:21 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([184.108.40.206] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2rXR-0007EL-Ik for firstname.lastname@example.org; Wed, 10 Aug 2005 10:26:39 -0400
Received: from sj-core-1.cisco.com (220.127.116.11) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2005 06:51:12 -0700
X-IronPort-AV: i="3.96,96,1122879600"; d="scan'208"; a="330794910:sNHT31907140"
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7ADp90J028707; Wed, 10 Aug 2005 06:51:10 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [SECMECH] Continuing my rant about EAP vs GSS-API...
Date: Wed, 10 Aug 2005 06:55:52 -0700
Thread-Topic: [SECMECH] Continuing my rant about EAP vs GSS-API...
From: "Salowey, Joe" <email@example.com>
To: <Pasi.Eronen@nokia.com>, <firstname.lastname@example.org>
X-Spam-Score: 0.0 (/)
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:firstname.lastname@example.org?subject=subscribe>
Hi Pasi, The current goal of GUAM is not to change the applicability of various frameworks. I believe that you are somewhat correct in that the different frameworks are typically used in different systems. However the all have the same goal within each of there systems and that is authentication and establishment of cryptographic state between two entities. This is just a true for EAP as it is for GSS-API. EAP itself is not a three party protocol even when the EAP Sever is located on a AAA server separate from the EAP authenticator. What is needed to create a mechanism that is usable in each of these frameworks is to adhere to the requirements in each of these frameworks, most of which actually are discussed in the EAP RFC. We are not trying to solve all of ISMS problems in this group and in particular we are not trying to make EAP applicable to ISMS. ISMS is working on solutions to their problems. What we are trying to do is to unify mechanism development. However, an additional work item that may be relevant to this group that you focused on is tighter application integration with AAA. I think there are a possible number of ways to approach this and I'd be open to discuss it. I think the GUAM work is necessary to have tighter application integration into AAA. It sounds like you would like to have the AAA server explicitly involved in some sort of three party exchange. I'm not completely convinced that this is a good idea as systems tend to work as they are today without it and making the system more complex does not necessarily solve a problem. In order to explicitly involve AAA in a n application security protocol one could design an extension to the GSS-API framework which covers both an application client exchange with the AAA server (probably using the EAP interface into AAA) and also covers the exchange between the application client and application server based on the AAA conversation. I think this would go a long way to addressing your concerns. I think it would be useful to define what the actual requirements an benefits of such an integrated system are. Is this something you would like to look at? Joe > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Tuesday, August 02, 2005 3:07 AM > To: email@example.com > Subject: [SECMECH] Continuing my rant about EAP vs GSS-API... > > > (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 separate. > > 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, > Pasi > > _______________________________________________ > SECMECH mailing list > SECMECH@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/secmech > _______________________________________________ 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