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

["Salowey, Joe" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
> Sent: Tuesday, August 02, 2005 3:07 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/secmech
> 

_______________________________________________
SECMECH mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/secmech