Alan DeKok [mailto://al...@deployingradius.com] writes:
Alper Yegin wrote:
I’m not against this. But let’s face it, this is venturing into
dealing
with authorization parameters with EAP (EAP layer? EAP method layer?
Etc.) I’m not against that either. In fact, I know there are a lot of
Glen Zorn wrote:
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
Prior to authentication, EAP is the only communications protocol
between a supplicant and *anywhere* on the network. It is therefore
natural to overload it as a general purpose transport protocol.
To transport
Network Endpoint Assessment (NEA) messages can be considered
authorization data. Certainly, they're not authentication.
They convey information about endpoint posture (like whether
anti-virus software is installed and enabled). Yet they are
carried in EAP messages every day, generally in tunnel
Stephen Hanna [mailto:sha...@juniper.net] writes:
Network Endpoint Assessment (NEA) messages can be considered
authorization data.
They can, in the broadest sense of authorization as policy enforcement. It
has almost nothing to do with actual security, but that's OK, I guess.
Certainly,
Stephen Hanna [mailto:sha...@juniper.net] writes:
This discussion started with the statement that channel bindings
are a form of authorization data.
And no one disputed this?
Our charter requires us to
support carrying channel bindings in the tunnel method.
Password change is another form
Glen Zorn wrote:
No. Please don't confuse authentication with authorization. The parameters
you mention above are policy-related, not related to authentication.
You are making arbitrary distinctions between pieces of information.
Ones you like are deemed authentication. Ones you don't like
