On Thu, Mar 5, 2015 at 11:45 AM, Sam Hartman <hartmans@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. - Jouni