Reply-Message and Eap

[Jouni Malinen]

On Wed, Mar 4, 2015 at 3:09 PM, Sam Hartman <hartmans at 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