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
> people who’d be happy to see that happen.
Prior to authent
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
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 tra
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 met
Alan DeKok [mailto:al...@deployingradius.com] writes:
> 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
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,
This discussion started with the statement that channel bindings
are a form of authorization data. Our charter requires us to
support carrying channel bindings in the tunnel method.
Password change is another form of non-authentication data
that we need to support. Clearly there are several kinds o
Hi,
Before this discussion escalades any further, I would like to summarize
the open issue(s) that need to be addressed to move the channel binding
draft forward.
Channel binding is a work group item because there was a group consensus
that the lying NAS and lying provider problem are real threat
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-authorizatio
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
Alan DeKok [mailto:al...@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.
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 l
Alan DeKok [mailto:al...@deployingradius.com] writes:
> 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 inform
13 matches
Mail list logo
