Re: [Emu] EAP and authorization

["Glen Zorn" <glenzorn at comcast.net>]

Dan Harkins [mailto://dharkins at lounge.org] writes:

...

> An EAP server asks "who are you?" and then
> proceeds to prove the identity it is told using a method of its choice.
> If the EAP method derives keys the keys have to be bound to a
> consistent
> view of the identities involved in the communication (including the NAS
> identity). If the EAP server is successful in proving that the peer
> really
> is the identity it claimed (and the key is successfully bound to a
> consistent view of all identities) there can still be other,
> supplementary,
> things to consider before deciding to grant access or not-- time-of-
> day,
> location, up-to-date anti-virus software, etc. But those other,
> supplementary, things are not EAP, which is why you're mentioning a
> "AAA
> server" and not an "EAP server".
> 
>   We might want to make them part of EAP since EAP is the only protocol
> allowed prior to the access decision being made 

Yes, it is, but it doesn't have to be.  In IEEE 802.1X-2004, for example,
the transition from the "Authenticating" state to the "Authenticated" state
in the PAE machine is triggered by the reception of an Accept message from
the Back-end authentication server, not by EAP-Success.  In fact, great
pains are taken to ensure that the "correct" EAP message (Success or
Failure) is sent to the supplicant, the correctness being based not on the
actual result of the EAP authentication but on the decision of the AAA
server.

> and it's attractive to
> pass arbitrary data encapsulated in EAP. 

Actually, the only thing that's attractive about it (IMHO) is the fact that
it is there.  There are huge disadvantages to using EAP in this way that
could be removed were a new protocol be designed for this purpose.

...