EAP-TLS and PEAP redundancy options

[John Paul]

> John Paul wrote:
>> The issue is that if a machine is authenticated and the server that
>> did the authentication is down, the switch will contact the other server
>> and the EAP conversation will fail, causing authentication to fail.
>> Research indicates that this is because the client and server have
>> agreed upon session specific symmetric keys that the new server does not
>> know about.
> 
>   I don't think it's because of the establishment of symmetric session
> keys.  Once a user has been authenticated, the *next* authentication
> session is completely independent.
>
>   I think it's that if fail-over happens in the *middle* of an EAP
> authentication, the new server won't have been participating in the TLS
> setup.  Therefore, it doesn't know about the EAP conversation, and it
> rejects the session.
>

It's not happening in the middle of the conversation. Server 1 will send an "Access-Accept" packet and the switch enables the port. Then if server 1 goes down and you attempt to reauthenticate the port, the switch tries server 2. That is when it fails.

When I tested this the first time, authentications to server 1 worked and to server 2 did not. When I couldn't figure it out, I turned the test machines off and left for the day. The next day I had server 1 turned off - I turned the test machines on and authentications to server 2 worked fine, but would not work on server 1 once I powered it on. The common denominator here was that authentications work against the first server it tries but not any others. That's why I postulated that there must be some sort of session resumption going on.
 
>> Is there a way to tell FreeRadius to tear down the session
>> once the user has been authenticated so that the next authentication
>> will work if using a different server? If not, is anyone working on a
>> patch or other change to enable this? I'll be happy to write the patch
>> but am unfamiliar with the code. Can you tell me roughly where to look?
> 
>   Please check first that the server isn't establishing session keys.
> Since FreeRADIUS doesn't do fast session resumption, I have no idea how
> "session specific symmetric keys" could affect anything.

Was a shot in the dark based on some googling I had done awhile back. I assumed FreeRadius and Windows were agreeing on some sort of "fast session resumption" that would include symmetric encryption keys.


>   i.e. authentication one user via EAP.  Stop ALL other authentications.
>  Turn off one RADIUS server, so it fails over to the other.  Try to
> re-authenticate that one user.
> 
>   The user *should* be authenticated.

That's how I've been testing it and it's not working, see above description.

If I run the servers in debug mode (radiusd -X) the output starts to get different at line 420 of the middle of the conversation. The working server waits 6 seconds and then continues processing the next Access-Request packet:

(Note that these servers are in a test environment, so there are no additional access-request packets reaching the servers, just the packets from the testing machine)

Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 172.22.30.170:1812, id=29, length=171
	NAS-IP-Address = 172.22.30.170
	NAS-Port = 50016
	NAS-Port-Type = Ethernet
......

while the non-working server cleans up the request, then receives an Access-Request packet:

Sending Access-Challenge of id 37 to 172.22.30.170 port 1812
	EAP-Message = 0x011300061920
	Message-Authenticator = 0x00000000000000000000000000000000
	State = 0x466470a3816b19a56b24e71b7dff8089
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 37 with timestamp 47556860
Nothing to do.  Sleeping until we see a request.
rad_recv: Access-Request packet from host 172.22.30.170:1812, id=38, length=171
	NAS-IP-Address = 172.22.30.170
	NAS-Port = 50016
	NAS-Port-Type = Ethernet
.....

I can send the debugs in their entirety if you would like but thought I'd keep them off the list for now. What else could be going on here? 

Thanks for looking at this, if I can send you anything else please let me know.