Re: Summary of Federated Authentication BOF at IETF 77

>>>>> "Alper" == Alper Yegin <alper.yegin <at> 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