[c-nsp] 802.1x - clients that go to sleep

[Aaron Riemer]

Hi Phil,

Thanks for your response.

Essentially I don't want to see a bunch of spurious dot1x failures in my log
as it makes life hard when you are trying to troubleshoot real dot1x failed
authentication attempts. I would prefer that the switch didn't send the
authorization attempts and rather be more passive and only forward
supplicant EAP START messages. Setting the reauth timer might work so long
as the supplicants do actually send an EAP START message when they wake up
(haven't tested this yet).

I could use a logging discriminator of some kind but then that would get rid
of logs that I might actually need to look at :)


Cheers,

Aaron.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Mayers
Sent: Tuesday, 7 February 2012 9:19 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 802.1x - clients that go to sleep

On 07/02/12 11:54, Aaron Riemer wrote:
> Hey guys,
>
>
>
> Has anyone out there come across a condition where switch ports secured
with
> 802.1x have issues with clients/supplicants that go into hibernate / sleep
> mode?

Well, such a machine will stop authenticating.

> We have some clients that are hibernating and as a result the switch is
> filling the logs with failed 802.1x authorization attempts. The switch
looks
> to be trying to authenticate the supplicant but the supplicant is not
> responding due to the hibernation status.

So what's the issue? The cosmetic filling-of-logs (which is annoying) or 
something else?

> Is there any way around this other than configuring a hardware supplicant

Around what?

If you mean "filling of logs" then ESM (Embedded Syslog Manager) and log 
content filters might help. Or use a syslog server with filtering, and 
throw the re-auth messages away / into a separate file.

"Hardware supplicant" sounds nebulous to me. I guess in theory you could 
run an 802.1x module inside AMT/vPro-enabled chipsets that works while 
the host is down, but I don't know if one actually exists.

> that is not reliant on the client OS? Doing some reading around I haven't
> much info other than the allowing of magic packets out the switch port for
> the purpose of WOL.

It's not very secure, but you could set the reauth time really, really high.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/