Reply-Message and Eap
hartmans at mit.edu
Thu Mar 5 10:45:14 CET 2015
>>>>> "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
>> 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.
More information about the Freeradius-Devel