Interesting EAP-TLS condition, any insights?
This is a neat one. EAP-TLS is working just fine between an XP supplicant, a Cisco AP1200 WAP running 12.3(4)JA, and FreeRADIUS 1.0.1 (plus a patch to allow multiple root CAs for EAP-TLS trust). Client certificates are on smartcards, and the AP has a reauthentication timer set, with the intent that clients will be kicked off the WLAN (eventually) when the card is removed (since without the card reauthentication can't complete). Only it doesn't seem to work that way. What appears to happen is this: The authentication starts but never completes, since the client can't complete the TLS handshake without the smartcard inserted (and PIN entered). FreeRADIUS blocks at the "Requiring client certificate" step, as I would expect. However, the AP holds the authentication pending but *leaves the client fully connected*. This means that as long as an incomplete reauthentication is pending, a previously-authenticated client remains online. Not the effect I was looking for. The Cisco AP has an optional setting for RADIUS timeout, but this only seems to apply for the initial packet; since the RADIUS server responded to the initial access-request, that timeout doesn't apply. I tried ramping down max_request_time and setting delete_blocked_requests to yes, but it didn't have any effect; FreeRADIUS never sends an access-reject. There appear to be no controls on XP to force a complete deauthentication after a timeout that I can find. Will porting forward to current rev address this, or does anyone else have an insight? -- Tim
"Timothy J. Miller" <tmiller@mitre.org> wrote:
However, the AP holds the authentication pending but *leaves the client fully connected*. This means that as long as an incomplete reauthentication is pending, a previously-authenticated client remains online. Not the effect I was looking for.
That would appear to be a bug in the AP. I'd be curious to know how many AP's have that bug. If so, it would be a very, very, serious problem. I'm not sure how to fix that, to be honest. There's little you can do on the RADIUS server to make the AP work. My only suggestion is to try another AP. If that works, mail Cisco, and tell them about the bug. Alan DeKok.
I'm very curious about the outcome of this as well. The AP is *supposed* to block all traffic except for EAP traffic pending the required EAP-Success from the Authentication Server. If the AP is allowing non-EAP traffic through, and, given that the client->AP traffic occurs unencrypted until the EAPoL Keys are sent, that could allow a total bypass of security on those APs. Ick. I hope this doesn't turn out to be true for any other vendors... I'm pretty sure that it doesn't work that way for Proxim APs since I've seen the EAPoL exchange hang on those guys before and the client gives up and tries to communicate anyway to no avail... --Mike Alan DeKok wrote:
"Timothy J. Miller" <tmiller@mitre.org> wrote:
However, the AP holds the authentication pending but *leaves the client fully connected*. This means that as long as an incomplete reauthentication is pending, a previously-authenticated client remains online. Not the effect I was looking for.
That would appear to be a bug in the AP. I'd be curious to know how many AP's have that bug. If so, it would be a very, very, serious problem.
I'm not sure how to fix that, to be honest. There's little you can do on the RADIUS server to make the AP work.
My only suggestion is to try another AP. If that works, mail Cisco, and tell them about the bug.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Michael Griego wrote:
I'm very curious about the outcome of this as well. The AP is *supposed* to block all traffic except for EAP traffic pending the required EAP-Success from the Authentication Server. If the AP is allowing non-EAP traffic through, and, given that the client->AP traffic occurs unencrypted until the EAPoL Keys are sent, that could allow a total bypass of security on those APs.
It only occurs during a session reauthentication forced by the AP; initial authentication works as expected. The traffic remains encrypted during the pending authentication, so I'm assuming that the previous session keys are still being used. And it only happens with XP as a client. It's at the least a partial bypass of security because part of the point of the forced reauthentication is to get new keys.
Ick. I hope this doesn't turn out to be true for any other vendors... I'm pretty sure that it doesn't work that way for Proxim APs since I've seen the EAPoL exchange hang on those guys before and the client gives up and tries to communicate anyway to no avail...
Unfortunately I don't have another AP to test at the moment. -- Tim
Alan DeKok wrote:
That would appear to be a bug in the AP. I'd be curious to know how many AP's have that bug. If so, it would be a very, very, serious problem.
Which is why it startled me.
I'm not sure how to fix that, to be honest. There's little you can do on the RADIUS server to make the AP work.
An abort followed by Access-Reject in rlm_eap_tls might work.
My only suggestion is to try another AP. If that works, mail Cisco, and tell them about the bug.
Already in the plan. -- Tim
"Timothy J. Miller" <tmiller@mitre.org> wrote:
I'm not sure how to fix that, to be honest. There's little you can do on the RADIUS server to make the AP work.
An abort followed by Access-Reject in rlm_eap_tls might work.
Only if you do it *before* the supplicant stops responding. Alan DeKok.
Alan DeKok wrote:
Only if you do it *before* the supplicant stops responding.
FYI, I think I've figured out what's happening. On my Mac, the 802.1x supplicant will abandon the EAP-TLS authentication after the Server Hello Done message if it doesn't have a proper certificate and private key to continue the TLS exchange, as would happen when the user's smartcard is removed. When it does this, it sends an eapLogoff message which sends the AP 802.1x state machine back to DISCONNECTED and unauthorizes the station's port. (IMHO, the Mac supplicant should send a TLS Fatal Handshake message, followed by an eapLogoff, because this would be friendlier to resources on the RADIUS server. But since the station is kicked off the network, it doesn't really matter that much. I may log a bug on this.) On XP, however, the supplicant simply leaves the authentication pending. It never sends a TLS Fatal Handshake or an eapLogoff message. I think this is because of how CAPI handles smartcards; basically, CAPI *always* believes that the smartcard keys are present, even when the card is absent. It's up to the CSP to notify CAPI when keys are unavailable. Since this doesn't appear to be happening, the supplicant blocks waiting for keys so it can send the TLS Client Certificate message. Back on the AP, this seems to tickle an 802.1x state machine bug. The state machine enters a loop, either in the CONNECTING state itself or in a loop from CONNECTING, AUTHENTICATING, ABORTING and back to CONNECTING. This loop should end when a counter (reAuthCounter, which is incremented each time the machine enters the CONNECTING state), exceeds the reAuthMax value, sending the machine back to the DISCONNECTED state. Either reAuthMax is set absurdly high by default on the AP (but it's supposed to be 2 according to IEEE 802.1x-2001), or the counter is not getting incremented in this pathway. Note that a port can only become unauthorized by entering the DISCONNECTED, HELD or FORCE_UNAUTH states. Since the AP state machine never gets to any of these once looping begins with an XP supplicant, the station remains connected to the network. Thus the symptoms I'm seeing. I'll be writing this up to send to both MS and Cisco. I'll likely submit it to BUGTRAQ and Full-Disclosure as well. -- Tim
participants (3)
-
Alan DeKok -
Michael Griego -
Timothy J. Miller