"Jouni" == Jouni Malinen <jkmalinen@gmail.com> writes:
Jouni> 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. 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.