*What* RFCness?
Apparently, guessing this is Aaran spending too much absorbing the IETF website, RFC2865 says "though shalt use 'Call-Check' for mac-auth", I have not read it myself.
that seems overkill to you? Cisco switches use PAP instead of CHAP, but other than that whats the problem?
I've never seen a mac-auth implementation sending CHAP requests,
HP Networking equipment does.
which seems like lunacy, so have never considered there might be a need to execute the "authenticate" section, or synthesise a Cleartext-Password.
...but this is what makes HP special :)
The problem is you can't always distinguish between CHAP authentication (e.g. web-auth) and mac-authentication. Both provide a CHAP-Password attribute, and HP Networking gear doesn't provide additional attributes, so someone could enter their mac-address as the user-name and password in a web-auth form and trick the server into performing mac-auth. In newer firmware releases all HP Networking (ProCurve) equipment will send call-check as the Service-Type to indicate Mac-Based authentication, we (ESSW security team) decided that amongst the different options, this was closest to the original intent of the RFC.
http://wiki.freeradius.org/index.php?title=HP#Mac-Based
I agree, is is rather daft, I'm surprised User-Password even appears for a PAP approach.
Its either CHAP or PAP in every Mac-Auth implementation that i've seen either sends the MAC-Address or a predefined passphrase in the CHAP or PAP attribute. I guess the advantage is that it will work with less advanced RADIUS servers that require a password attribute of some kind, and that the shared secret is required to create valid values for User-Password and CHAP-Password.
But even so, I don't see the value in executing a modules .authorize handler in the post-auth section, or having a whole separate Auth-Type value.
Right, this I agree with, I nuke the request in authorize too.
See previous mail.
Shrug. Not a big deal really. To each his own.
Many ways to skin this cat...
Mmm skinned cat. -Arran