Reply-Message and Eap
jkmalinen at gmail.com
Thu Mar 5 13:32:04 CET 2015
On Thu, Mar 5, 2015 at 11:45 AM, Sam Hartman <hartmans at mit.edu> wrote:
> No, I'm actually more interested in getting a text string to the NAS
> than the peer.
OK. As long as the NAS knows how to generate EAP-Failure from a
Access-Reject without EAP-Message, that should work fine by adding the
Reply-Message attribute instead. At least the NAS implementation I'm
familiar with would indeed do that and would not have issues with
EAP-Message being replaced with Reply-Message.
> 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.
Hmm.. I think I somehow misread your earlier email and I was looking
at the earlier part of it where both attributes were to be included
and this in RFC 3579:
"Reply-Message attribute(s) MUST NOT be included in any RADIUS message
containing an EAP-Message attribute."
However, this question was actually for the "no EAP message and a
Reply-Message".. So yes, I agree with your interpretation on that just
not following a SHOULD.
More information about the Freeradius-Devel