> >>>>> "Alper" == Alper Yegin <[email protected]> writes: > > Alper> Was this discussed? Is there a proposal to expand the > Alper> applicability statement of EAP now? Where do we draw the new > Alper> line now? > > I've certainly been thinking about it. > > Quoting http://www.painless-security.com/blog/2010/02/12/moonshot1: > > >Itùs interesting that Iùm advocating EAP for application layer > >authentication. When I was a Security AD, I made a strong statement > >that EAP must only be used for network access.
That's right. > > Iùve been fairly > >consistent about that since then. I think there are two huge problems > >with using EAP for application authentication. The first is that EAP > >only authenticates the home realm; it does not authenticate what > >service youùre going to. So you might try to connect to your > >e-mail and end up giving something access to your stored files and > >pictures instead. That is, EAP has aphishing exposure in the > >federated context. If the only thing you can get by using EAP is > >network access, that exposure is only moderate. However in a fully > >federated environment that is a huge exposure. Moonshot will address > >thisproblem by using EAP channel binding "Channel binding" is a term that is specific to the network access application. For generic applications, we need something else. Basically we are talking about "authorization parameters." App server has verified that you are Joe, and you are allowed to use X, Y, Z apps/resources. This "authorization" aspect goes beyond "authentication" (as in extensible "authentication" protocol). This aspect may not be easy to stick in the EAP. and by doing the necessary > >work to make that a viable solution. The second concern is that > >interoperability is reduced when you have multiple authentication > >approaches for the same problem. If EAP is going to be used for > >application authentication, we need to understand how it relates to > >the rest of the application authentication metasystem. Moonshot > >proposes such a relationship, addressing my objection. Not sure I understand. EAP-based scheme will still appear as N+1st method. > In addition, if you take look at the work proposed for standardization > spelled out in the feasibility analysis,I propose that we need to > revise the applicability statement for EAP. > Quoting draft-howlett-eap-gss-00: > > 8. Applicability Considerations > > Section 1.3 of RFC 3748 provides the applicability statement for > EAP. > Among other constraints, EAP is scoped for use in network access. > This specification anticipates using EAP beyond its current scope. > The assumption is that some other document will discuss the issues > surrounding the use of EAP for application authentication and expand > EAP's applicability. That document will likely enumerate Is this document available? > considerations that a specific use of EAP for application > authentication needs to handle. Examples of such considerations > might include the multi-layer negotiation issue, deciding when EAP > or > some other mechanism should be used, and so forth. This section > serves as a placeholder to discuss any such issues with regard to > the > use of EAP and GSS-API. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
