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 of non-authentication data
> that we need to support.
Please explain how passwords are unrelated to authentication.
> Clearly there are several kinds of
> non-authentication data that we must support carrying in EAP.
> They are in our charter. I see no harm in also supporting
> carrying NEA assessments in the tunnel method.
You are entitled to your opinion.
>
> The only bizarre engineering here is Glen's suggestion
> that because the A in EAP stands for Authentication, it
> should not be allowed to carry anything other than
> authentication protocols. By that logic, RADIUS should
> be prohibited from carrying VLAN assignments and anything
> other than authentication information. After all, the A
> in RADIUS also stands for authentication. And RADIUS
> should be restricted to Dial In access since that's
> what the D and I stand for!
I really appreciate your putting two separate messages from me into your
magic blender. Unsurprisingly, what came out was only vaguely related to
what I actually wrote, but that was the point, wasn't it? What I actually
said (in a message you didn't quote) was:
Except for that whole pesky name & purpose thing -- you know,
Extensible _Authentication_ Protocol.
-------
The Abstract of RFC 3748 says "This document defines the Extensible
Authentication Protocol (EAP), an authentication framework which supports
multiple authentication methods.", a sentence that is repeated in virtually
every EAP-related RFC. For some reason it _doesn't_ say "an authentication
and authorization framework" or "an authentication and configuration
management framework", which is apparently what you want it to be (it's so
convenient!). WRT to RADIUS, the Abstract of RFC 2865 says "This document
describes a protocol for carrying authentication, authorization, and
configuration information between a Network Access Server which desires to
authenticate its links and a shared Authentication Server." This seems to
sum up the purpose of RADIUS pretty well, as the abstract from RFC 3748 sums
up the purpose of EAP.
>
> Glen, if you don't have any substantive arguments to
> make, don't try to impress us with bluster.
OK, I'd appreciate the same from you (along with accurate, rather than
misleading, quoting). BTW, while you may consider your personal opinion to
be a "substantive argument" ("I see no harm in also supporting carrying NEA
assessments in the tunnel method"), others might not.
...
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
