AW: EAP-TLS Failed in handler question

[Phil Mayers]

On 21/11/12 12:00, PENZ Robert wrote:

> With first packet I meant first packet the radius server saw in some time ... the switch forces a reauthentification every 2h

A re-auth is a fresh EAP session. So even on a re-auth, the first packet 
would not have a "State" attribute, absent software bugs.

>> It *could* be that the client just got stuck and is responding (very)
>> late. But I'm quite surprised the NAS didn't timeout the EAP auth before
>> that.
>
> We're running Extreme Networks Switches with following timers set:
>
> configure netlogin dot1x timers quiet-period 30
> configure netlogin dot1x timers reauth-period 7200

We run SummitX edge, and when I've tested dot1x netlogin in the past, I 
haven't seen this issue. We've never widely deployed it, however, so 
it's possible there's an XOS bug where a small percentage of re-auths 
erroneously re-use the "State". You'd need to get a packet capture to be 
sure.

> but reject means the switch sets the port to the guest vlan, and therefor the PC loses the connections ... is there a way to request a new full eap/tls handshake from the client?

You're not understanding, or I'm not making myself clear.

Suggestion: fire up wireshark, and take a careful look at a normal EAP 
authentication. You'll see that the first packet is an EAP-Identity 
without a "State" attribute, which the server responds to with an 
Access-Challenge containing the default eap type "start" payload, and a 
"State" attribute.

Are you *absolutely sure* that these packets are really the first RADIUS 
packet in the auth/re-auth?

If you're sure, your problem seems to be that the correct first packet 
isn't being sent; the switch is just jumping straight in with the EAP 
payload *and* a "State" attribute. I am curious to know where it's 
getting that "State" attribute.

The server source code assumes that a "State" attribute will be valid. 
There's no setting to "just accept it".

Interestingly, I see the RADIUS RFC does actually allow clients to send 
a previous "State" if you send an Access-Accept with:

  Termination-Action = RADIUS-request

You're not doing that, are you?

>
>>> Is this a client problem or a misconfiguration on my part?
>> It's probably a client or NAS problem, unless you've set timer_expire
>> too low.
>
>> However: I guess this could also happen right after the server is
>> restarted. Could that be it - is a cron job restarting it maybe?
>
> no the server is running for > 10 days
>
> but if I would restart the server I would reject all clients to the guest vlan on reauthentication after that ... that can't be the designed way.

No. As above, re-auths start new EAP sessions. You would only reject any 
EAP sessions that were in the *middle* of performing an auth, as the 
"state" would be lost across restarts. But this is a very narrow window.