Reply-Message and Eap

[Sam Hartman]

>>>>> "Jouni" == Jouni Malinen <jkmalinen at gmail.com> writes:

    Jouni> 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.

    Jouni> To which device? EAP peer? EAP-Notification round before
    Jouni> EAP-Failure could potentially be used for that (not that most
    Jouni> peers would do much with that info).

No, I'm actually more interested in getting a text string to the NAS
than the peer.

    >> What I'd like to do is send back a packet with no EAP message and
    >> a Reply-Message.  Will that break things?

    Jouni> I'm not sure what it would do with some deployed NAS devices,
    Jouni> but at least this seems to be in direct conflict with a MUST
    Jouni> NOT requirement in RFC 3579, 2.6.5. In practice, it may be
    Jouni> fine for some use cases, but maybe not that good of an idea
    Jouni> to do for an IEEE 802.1X NAS.

So, as Alan and I have discussed, this is limited to the RFC 7055 lower
layer.  However, we read section 2.6.5 differently.  I see a MUST not
include reply-message along with EAP-Message.  It violates a SHOULD NOT
earlier in the spec, saying that the RADIUS server SHOULD include an EAP
failure in the access reject.
However I don't see any MUST level requirement that we're violating.
If there is such a requirement in 2.6.5 please let me know what the
specific text is; the section has a few paragraphs.