Re: [Emu] EAP and authorization

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

Alan DeKok [mailto:aland at deployingradius.com] writes:

> Glen Zorn wrote:
> > Hmm.  Has another way been tried or is it the best way because it's
> the
> > easiest (or only) way we've tried?
> 
>   Authentication decisions have traditionally involved more than just
> username / password checking.  Authentication decisions are also
> commonly based on "pre-authorization" data, such as:
> 
>  * time of day
>  * location
>    * physical
>    * network
>  * account balance
>  * past behavior
>  * machine used to authenticate
> 
>   And so on.

No.  Please don't confuse authentication with authorization.  The parameters
you mention above are policy-related, not related to authentication.

> 
>   An authentication server may use any of that information to return a
> "failed authentication" status to the client, even if the username /
> password is superficially correct.  

What authentication server is that?  Not RADIUS: the semantics of the
Access-Reject message don't distinguish between failed authentication and
failed authorization.

> This is not "authorization",
> because
> the user has not been authenticated.  

A server can tell me that I'm not authorized without knowing who I am?  This
is incredibly cool technology!  Where can I get some of that?  But
seriously, the initial authorization checks made by a RADIUS server for
example are based upon so-called "simple" authentication (as used daily by
billions of humans).  Although this consists of my telling you my name & you
believing me (for the time being anyway), it is authentication all the same.

> But that information is still
> used
> to make authentication decisions.

No, they are authorization decisions.

> 
>   Enabling EAP to carry this information is well within the bounds of
> the protocol.  TLS-based EAP methods can carry information such as time
> of life for a certificate, issuer, etc.

I suppose so, but since all those things are typically in the cert, I don't
know why.  In any case, those things are directly related to authentication.

> 
>   If we restrict EAP to solely "authentication", then I would ask what
> that means.  An authentication protocol that is incapable of
> transporting the data required to make authentication decisions would
> be
> perfectly secure: No one would ever be authenticated.

I have no idea what you're talking about.