On Wed, Mar 4, 2015 at 3:09 PM, Sam Hartman <hartmans@mit.edu> wrote:
so, I understand why it would be confusing to have both a Reply-Message and an Eap-Message in the same packet.
I'm a bit confused why it's desirable to insert an EAP failure into a packet in an access reject case. We'd like to do a better job of error reporting back to ABFAB clients than "Uh, it failed." for some things we can use Error-Cause as we discussed previously.
However it would be really nice to get a text string back too.
To which device? EAP peer? EAP-Notification round before EAP-Failure could potentially be used for that (not that most peers would do much with that info).
What I'd like to do is send back a packet with no EAP message and a Reply-Message. Will that break things?
I'm not sure what it would do with some deployed NAS devices, but at least this seems to be in direct conflict with a MUST NOT requirement in RFC 3579, 2.6.5. In practice, it may be fine for some use cases, but maybe not that good of an idea to do for an IEEE 802.1X NAS.
would it be reasonable to update policy to prefer keeping Reply-Message over replacing Reply-Message with an EAP failure in the case where we're handling a reject that currently has no EAP message at all? I.E. we rejected before eap got called in authorize/authenticate, or unlang removed Eap-Message.
RFC 3579 does not seem to disallow that, but it is not a recommended option (see that same location mentioned above for more discussion). - Jouni