>>>>> "Alper" == Alper Yegin <alper.ye...@yegin.org> writes:
>> 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
Alper> "Channel binding" is a term that is specific to the network
Alper> access application. For generic applications, we need
Alper> something else. Basically we are talking about "authorization
Alper> parameters." App server has verified that you are Joe, and
Alper> you are allowed to use X, Y, Z apps/resources. This
Alper> "authorization" aspect goes beyond "authentication" (as in
Alper> extensible "authentication" protocol). This aspect may not be
Alper> easy to stick in the EAP.
When I'm speaking of channel binding, I am not speaking of that sort of
authorization.
i'm speaking of giving the peer (not the NAS) confidence that the peer
has connected to the NAS that the peer intended to connect to.
I argue that when you generalize the NAS so that the NAS is a mail
server, web server, or other app server, the question of which
generalized NAS you're talking to is far more important than in the
network access application.
I believe that both RFC 3748 and draft-ietf-emu-chbind define this
problem as channel binding.
At one level, I don't care what we call it: we need to solve it.
Alper> 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.
Alper> Not sure I understand. EAP-based scheme will still appear as
Alper> N+1st method.
I don't understand your comment here.
It may be something better discussed over the phone or something,
although I'm happy to keep e-mailing on this.
>> 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
Alper> Is this document available?
Which document? The proposed applicability statement for EAP? No, I'm
hoping that we can work on that in the WG we charter; would you be
interested in helping with that document? Or are you talking about
draft-howlett-eap-gss? If so, yes, that is in the ID repository? Or
were you talking about the feasability analysis? If so, there is a link
from www.painless-security.com/blog and will soon be a link from
www.project-moonshot.org .
I'd definitely be interested in a discussion with you about these
issues.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
