Reply-Message and Eap
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. What I'd like to do is send back a packet with no EAP message and a Reply-Message. Will that break things? would it be reasonable to update policy to prefer keeping Reply-Message over replacing Reply-Message with an EAP failure in the case where we're handling a reject that currently has no EAP message at all? I.E. we rejected before eap got called in authorize/authenticate, or unlang removed Eap-Message. --Sam
On Mar 4, 2015, at 8:09 AM, 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.
In theory it shouldn’t be a problem. But...
I'm a bit confused why it's desirable to insert an EAP failure into a packet in an access reject case.
So the failure gets back to the supplicant. An explicit failure indication is better than having the supplicant wonder why the NAS stopped talking to it.
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.
That would be very nice.
However it would be really nice to get a text string back too.
What I'd like to do is send back a packet with no EAP message and a Reply-Message. Will that break things?
Maybe. Some “helpful” (i.e. idiotic) NAS vendors turn Reply-Message into EAP-Notification. The “helpful” (i.e. idiotic) supplicants go OMFG I don’t understand that… and drop the connection. That issue is less of a problem on Access-Reject, of course.
would it be reasonable to update policy to prefer keeping Reply-Message over replacing Reply-Message with an EAP failure in the case where we're handling a reject that currently has no EAP message at all? I.E. we rejected before eap got called in authorize/authenticate, or unlang removed Eap-Message.
Probably. Maybe. It all depends on what the NAS and supplicants do. After ~20 years of doing this, I’m not going to guess what kind of crazy thing people do. All I can say is try it, and see if it works. Alan DeKok.
"Alan" == Alan DeKok <aland@deployingradius.com> writes:
>> would it be reasonable to update policy to prefer keeping >> Reply-Message over replacing Reply-Message with an EAP failure in >> the case where we're handling a reject that currently has no EAP >> message at all? I.E. we rejected before eap got called in >> authorize/authenticate, or unlang removed Eap-Message. Alan> Probably. Maybe. Alan> It all depends on what the NAS and supplicants do. After Alan> ~20 years of doing this, I’m not going to guess what kind of Alan> crazy thing people do. Alan> All I can say is try it, and see if it works. I know what my code will do:-) The behaviors seem reasonable. If we get an access reject our NAS will always generate a protocol error of some kind to our supplicant at the lower layer. So, it sounds like doing this for ABFAb would be OK especially if I have confidence that ABFAB NASes and supplicants won't suck, but a global change wouldn't be so good of an idea unless I had some way to survey the behavior of some huge fraction of the market. In that case I'll confine patches to the sample abfab policy. --Sam
On Mar 4, 2015, at 8:19 AM, Sam Hartman <hartmans@mit.edu> wrote:
So, it sounds like doing this for ABFAb would be OK especially if I have confidence that ABFAB NASes and supplicants won't suck, but a global change wouldn't be so good of an idea unless I had some way to survey the behavior of some huge fraction of the market.
Exactly.
In that case I'll confine patches to the sample abfab policy.
Thanks. Alan DeKok.
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.
To which device? EAP peer? EAP-Notification round before EAP-Failure could potentially be used for that (not that most peers would do much with that info).
What I'd like to do is send back a packet with no EAP message and a Reply-Message. Will that break things?
I'm not sure what it would do with some deployed NAS devices, but at least this seems to be in direct conflict with a MUST NOT requirement in RFC 3579, 2.6.5. In practice, it may be fine for some use cases, but maybe not that good of an idea to do for an IEEE 802.1X NAS.
would it be reasonable to update policy to prefer keeping Reply-Message over replacing Reply-Message with an EAP failure in the case where we're handling a reject that currently has no EAP message at all? I.E. we rejected before eap got called in authorize/authenticate, or unlang removed Eap-Message.
RFC 3579 does not seem to disallow that, but it is not a recommended option (see that same location mentioned above for more discussion). - Jouni
"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.
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
"Jouni" == Jouni Malinen <jkmalinen@gmail.com> writes:
Jouni> 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. Jouni> OK. As long as the NAS knows how to generate EAP-Failure from Jouni> a Access-Reject without EAP-Message, that should work fine by Jouni> adding the Reply-Message attribute instead. At least the NAS Jouni> implementation I'm familiar with would indeed do that and Jouni> would not have issues with EAP-Message being replaced with Jouni> Reply-Message. The NAS currently generates a very hard lower-layer failure ( a hard fail error token; I think section 7.5 of RFC 7055) which requires the supplicant to drop this authentication attempt. 3579 actually mandates against synthesizing an EAP failure (or at least gives you a SHOULD NOT for that; can't remember which) I'm kind of unconvinced of the value of EAP failure for lower layers that have their own signaling. You're never guaranteed to get an EAP failure if the NAS doesn't synthesize one. You might have a non-EAP-aware proxy that decided to reject as an example. --Sam
participants (3)
-
Alan DeKok -
Jouni Malinen -
Sam Hartman