[RADIATOR] (P)EAP flow

[Garry Shtern]

Actually, I was thinking perhaps if the Radiator is getting unexpected packet from the supplicant to challenge the supplicant to restart the negotiation.  If that is possible, then the reject would only be sent if Radiator got all the packets during the exchange but OpenSSL rejected this because of certificate, negotiation or handshake errors.

As for minimizing of unexpected messages, I am definitely with you on this one.

-----Original Message-----
From: Heikki Vatiainen [mailto:hvn at open.com.au] 
Sent: Wednesday, February 19, 2014 9:35 AM
To: Garry Shtern; 'radiator at open.com.au'
Subject: Re: [RADIATOR] (P)EAP flow

On 02/17/2014 05:16 PM, Garry Shtern wrote:

> Would it make sense not modify Radiator behavior to only send reject 
> if the OpenSSL returns mismatch rather than unexpected record?

Then there would need to be a correct request coming in later that allows the authentication to continue? That is, if the request is not rejected and can not be challenged, then the option would be to wait for the real request?

> This way if
> there is a packet loss or intermittent client issues, the client 
> doesn't get kicked off the net.

I would say it might be a better idea to see how to minimise the number of unexpected messages. Would that be an option to explore?

Thanks,
Heikki

> Thanks.
> 
> 
> 
> Sent with Good (www.good.com)
> 
> 
> -----Original Message-----
> *From: *Heikki Vatiainen [hvn at open.com.au <mailto:hvn at open.com.au>]
> *Sent: *Monday, February 17, 2014 02:22 PM Coordinated Universal Time
> *To: *radiator at open.com.au
> *Subject: *Re: [RADIATOR] (P)EAP flow
> 
> On 02/14/2014 07:17 PM, Garry Shtern wrote:
>> I have noticed that if Radiator receives a midstream EAP exchange 
>> message, it responds back with a CHALLENGE.
> 
> I would expect something like this with PEAP.
> 
> ERR: EAP TLS error: -1, 1, 8465,  13062: 1 - error:140940F5:SSL 
> routines:SSL3_READ_BYTES:unexpected record
> 
> Then an Access-Reject is sent back to the client.
> 
>> I am trying to understand
>> what exactly happens at this point.  Does the Supplicant respond to 
>> the challenge with a brand new exchange or just retransmits whatever 
>> packet it sent before?  If it’s the latter, is there any way to force 
>> a supplicant to re-start the negotiation, perhaps with a crafted CHALLENGE?
> 
> The supplicant probably restarts, but that's only because it got an 
> unexpected response. I most cases I would expect that a midstream EAP 
> message results as a some sort of error on Radiator side.
> 
> Thanks,
> Heikki
> 
> --
> Heikki Vatiainen <hvn at open.com.au>
> 
> Radiator: the most portable, flexible and configurable RADIUS server 
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, 
> TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, 
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, 
> NetWare etc.
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
> 


--
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.