sending Challenge + EAP-Notification before Reject?
Hello, recently, RFC4284 was brought to my attention, which speaks of ways to notify EAP peers that there is no service for them - with a displayable message as EAP-Notification in a Access-Challenge before the final EAP-Failure in a Reject. Is this in any way doable with FreeRADIUS? I'm thinking of two scenarios primarily: * FreeRADIUS proxy can't reach home server, so writes "Sorry, your home server is unreachable" in a Challenge+EAP-Notification and after the next Request then crafts Reject. * FreeRADIUS sees the realm, figures that it's not wanted, so writes "We don't serve that realm here." and then after the subsequent Request sends Access-Reject. I could also imagine that it could signal its own module failures as reason; e.g. if an rlm_sql doesn't work, instead of an immediate reject or do_not_reply it could send an extra round with "Unable to authenticate you: rlm_sql failed. Try again later"; and only then the Reject. I have no clue how to configure such a behaviour. Is it possible at all? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Stefan Winter wrote:
recently, RFC4284 was brought to my attention, which speaks of ways to notify EAP peers that there is no service for them - with a displayable message as EAP-Notification in a Access-Challenge before the final EAP-Failure in a Reject.
IIRC, some switches will close the port when they receive an EAP-Notification in an Access-Challenge.
Is this in any way doable with FreeRADIUS?
Yes. Arran was doing this a while ago, which is how he ran into the above problem.
I'm thinking of two scenarios primarily:
* FreeRADIUS proxy can't reach home server, so writes "Sorry, your home server is unreachable" in a Challenge+EAP-Notification and after the next Request then crafts Reject.
* FreeRADIUS sees the realm, figures that it's not wanted, so writes "We don't serve that realm here." and then after the subsequent Request sends Access-Reject.
I thought that the Reply-Message in an Access-Reject could also be turned into an EAP-Notification by the NAS. I can't recall where I saw that, though. But it would make sense.
I could also imagine that it could signal its own module failures as reason; e.g. if an rlm_sql doesn't work, instead of an immediate reject or do_not_reply it could send an extra round with "Unable to authenticate you: rlm_sql failed. Try again later"; and only then the Reject.
I have no clue how to configure such a behaviour. Is it possible at all?
Probably with some magic. But will the supplicants display the notification to the end user? I doubt it. Alan DeKok.
On 18 Feb 2014, at 17:19, Alan DeKok <aland@deployingradius.com> wrote:
Stefan Winter wrote:
recently, RFC4284 was brought to my attention, which speaks of ways to notify EAP peers that there is no service for them - with a displayable message as EAP-Notification in a Access-Challenge before the final EAP-Failure in a Reject.
IIRC, some switches will close the port when they receive an EAP-Notification in an Access-Challenge.
Is this in any way doable with FreeRADIUS?
Yes. Arran was doing this a while ago, which is how he ran into the above problem.
It is doable with FreeRADIUS, but FreeRADIUS wasn't doing when I was playing around with it. The NAS was translating Reply-Message into an EAP-Notification and sending it *after* the EAP-Success or EAP-Failure. This was causing wpa_supplicant to reinitialize it's state machine, and restart authentication, which is how I became aware of it.
I'm thinking of two scenarios primarily:
* FreeRADIUS proxy can't reach home server, so writes "Sorry, your home server is unreachable" in a Challenge+EAP-Notification and after the next Request then crafts Reject.
* FreeRADIUS sees the realm, figures that it's not wanted, so writes "We don't serve that realm here." and then after the subsequent Request sends Access-Reject.
I thought that the Reply-Message in an Access-Reject could also be turned into an EAP-Notification by the NAS. I can't recall where I saw that, though. But it would make sense.
RFC 3579 2.6.5. Displayable Messages The Reply-Message attribute, defined in [RFC2865], Section 5.18, indicates text which may be displayed to the peer. This is similar in concept to EAP Notification, defined in [RFC2284]. When sending a displayable message to a NAS during an EAP conversation, the RADIUS server MUST encapsulate displayable messages within EAP-Message/EAP-Request/Notification attribute(s). Reply-Message attribute(s) MUST NOT be included in any RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet. Unfortunately RFC 3579 was released after HP had completed their 802.1X implementation.
I could also imagine that it could signal its own module failures as reason; e.g. if an rlm_sql doesn't work, instead of an immediate reject or do_not_reply it could send an extra round with "Unable to authenticate you: rlm_sql failed. Try again later"; and only then the Reject.
I have no clue how to configure such a behaviour. Is it possible at all?
Probably with some magic. But will the supplicants display the notification to the end user? I doubt it.
Indeed. - Yes you can send an EAP-Notification, but you should probably test whether any supplicants will actually display it before investigating this much further. Back when I looked at it in 2008, only the OSX supplicant did anything useful with it, and even then it was just writing it out to one of the system log files. You can fake a Challenge with unlang pretty easily for testing and just send it instead of the original EAP-Failure message. Use regex over %{hex:EAP-Message} to extract required ID field value. and to set the response type: update response { Response-Packet-Type := Access-Challenge } You may have to set the Response-Packet-Type immediately after calling EAP, I don't know if setting it in Post-Auth REJECT will work, and you'll also need FreeRADIUS 3.0.1 or higher. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
Is this in any way doable with FreeRADIUS?
Yes. Arran was doing this a while ago, which is how he ran into the above problem.
It is doable with FreeRADIUS, but FreeRADIUS wasn't doing when I was playing around with it.
The NAS was translating Reply-Message into an EAP-Notification and sending it *after* the EAP-Success or EAP-Failure.
This was causing wpa_supplicant to reinitialize it's state machine, and restart authentication, which is how I became aware of it.
This is not what I mean... converting Reply-Message is forbidden for a good reason (as you quote below): the authenticator can't be a pass-through any more if he actively "fiddles" with the EAP conversation on its own. That's why the RFC language is so strong about the MUST about EAP-Notification and MUST NOT of Reply-Message in presence of the EAP-Message attribute.
Yes you can send an EAP-Notification, but you should probably test whether any supplicants will actually display it before investigating this much further.
Back when I looked at it in 2008, only the OSX supplicant did anything useful with it, and even then it was just writing it out to one of the system log files.
You can fake a Challenge with unlang pretty easily for testing and just send it instead of the original EAP-Failure message.
Use regex over %{hex:EAP-Message} to extract required ID field value.
and to set the response type: update response { Response-Packet-Type := Access-Challenge }
You may have to set the Response-Packet-Type immediately after calling EAP, I don't know if setting it in Post-Auth REJECT will work, and you'll also need FreeRADIUS 3.0.1 or higher.
Well, that's better than nothing certainly. Guess what: I'm asking this question because we are currently setting up what we call an "EAP Lab" (working title) where a (Free- and others) RADIUS server can be tuned to behave "non-normal" so that we can test supplicant behaviour in such unusual situations. We were primarily aiming at "what if the server cert's issuing CA suddently changes" and the like, but EAP-Notification is great test vector to include. We'll put your recipe above to the test on that lab and will ask back if in doubt (certainly :-) ) ... The EAP lab website is WIP, but you can always already go here: http://supplicants.net and click around. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On 19 Feb 2014, at 07:04, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
Is this in any way doable with FreeRADIUS?
Yes. Arran was doing this a while ago, which is how he ran into the above problem.
It is doable with FreeRADIUS, but FreeRADIUS wasn't doing when I was playing around with it.
The NAS was translating Reply-Message into an EAP-Notification and sending it *after* the EAP-Success or EAP-Failure.
This was causing wpa_supplicant to reinitialize it's state machine, and restart authentication, which is how I became aware of it.
This is not what I mean... converting Reply-Message is forbidden for a good reason (as you quote below): the authenticator can't be a pass-through any more if he actively "fiddles" with the EAP conversation on its own.
That's why the RFC language is so strong about the MUST about EAP-Notification and MUST NOT of Reply-Message in presence of the EAP-Message attribute.
Yes, i'm aware :)
Yes you can send an EAP-Notification, but you should probably test whether any supplicants will actually display it before investigating this much further.
Back when I looked at it in 2008, only the OSX supplicant did anything useful with it, and even then it was just writing it out to one of the system log files.
You can fake a Challenge with unlang pretty easily for testing and just send it instead of the original EAP-Failure message.
Use regex over %{hex:EAP-Message} to extract required ID field value.
and to set the response type: update response { Response-Packet-Type := Access-Challenge }
You may have to set the Response-Packet-Type immediately after calling EAP, I don't know if setting it in Post-Auth REJECT will work, and you'll also need FreeRADIUS 3.0.1 or higher.
Well, that's better than nothing certainly. Guess what: I'm asking this question because we are currently setting up what we call an "EAP Lab" (working title) where a (Free- and others) RADIUS server can be tuned to behave "non-normal" so that we can test supplicant behaviour in such unusual situations. We were primarily aiming at "what if the server cert's issuing CA suddently changes" and the like, but EAP-Notification is great test vector to include.
That will be extremely useful, even just having an awareness of the steps to fix such issues supplicant side will make 802.1X enabled networks far easier to support.
We'll put your recipe above to the test on that lab and will ask back if in doubt (certainly :-) ) ... The EAP lab website is WIP, but you can always already go here: http://supplicants.net and click around.
Looks like a worthwhile project. Seems like the inverse of what you have planned for supplicants would also be very useful, like standard test suites for the major EAP-Methods to ensure RADIUS servers and vendor equipment behaves correctly. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
My RSA EAP-POTP method implementation can send EAP Notification messages in error situations... and I found that most EAP supplicants ignore them or worse. The RTM Windows 7 EAP client would drop them on the ground and not reply, a violation of protocol. They patched that to match prior behavior, ignore and acknowledge. I made it an option, and I think, turned it off by default in later releases. I've never seen anyone that passed the message up to the user, but they could be out there. Dave. Quoting Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
On 19 Feb 2014, at 07:04, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
Is this in any way doable with FreeRADIUS?
Yes. Arran was doing this a while ago, which is how he ran into the above problem.
It is doable with FreeRADIUS, but FreeRADIUS wasn't doing when I was playing around with it.
The NAS was translating Reply-Message into an EAP-Notification and sending it *after* the EAP-Success or EAP-Failure.
This was causing wpa_supplicant to reinitialize it's state machine, and restart authentication, which is how I became aware of it.
This is not what I mean... converting Reply-Message is forbidden for a good reason (as you quote below): the authenticator can't be a pass-through any more if he actively "fiddles" with the EAP conversation on its own.
That's why the RFC language is so strong about the MUST about EAP-Notification and MUST NOT of Reply-Message in presence of the EAP-Message attribute.
Yes, i'm aware :)
Yes you can send an EAP-Notification, but you should probably test whether any supplicants will actually display it before investigating this much further.
Back when I looked at it in 2008, only the OSX supplicant did anything useful with it, and even then it was just writing it out to one of the system log files.
You can fake a Challenge with unlang pretty easily for testing and just send it instead of the original EAP-Failure message.
Use regex over %{hex:EAP-Message} to extract required ID field value.
and to set the response type: update response { Response-Packet-Type := Access-Challenge }
You may have to set the Response-Packet-Type immediately after calling EAP, I don't know if setting it in Post-Auth REJECT will work, and you'll also need FreeRADIUS 3.0.1 or higher.
Well, that's better than nothing certainly. Guess what: I'm asking this question because we are currently setting up what we call an "EAP Lab" (working title) where a (Free- and others) RADIUS server can be tuned to behave "non-normal" so that we can test supplicant behaviour in such unusual situations. We were primarily aiming at "what if the server cert's issuing CA suddently changes" and the like, but EAP-Notification is great test vector to include.
That will be extremely useful, even just having an awareness of the steps to fix such issues supplicant side will make 802.1X enabled networks far easier to support.
We'll put your recipe above to the test on that lab and will ask back if in doubt (certainly :-) ) ... The EAP lab website is WIP, but you can always already go here: http://supplicants.net and click around.
Looks like a worthwhile project.
Seems like the inverse of what you have planned for supplicants would also be very useful, like standard test suites for the major EAP-Methods to ensure RADIUS servers and vendor equipment behaves correctly.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
David Mitton -
Stefan Winter