Internal error during EAP-FAST

[Alan DeKok]

On Oct 29, 2020, at 7:47 AM, Sebastian <radius at wehle.dev> wrote:
> 
> Ah, I read that it doesn't support 1.3 (that's why I had 1.2 set) but
> I missed the note about 1.2/1.1. Thanks.
> 
> So now freeradius sends a response, but it still ends up with:
> 
> (2) eap: Calling submodule eap_fast to process data
> (2) eap_fast: Authenticate
> (2) eap_fast: Continuing EAP-TLS
> (2) eap_fast: [eaptls verify] = ok
> (2) eap_fast: Done initial handshake
> (2) eap_fast: (other): before SSL initialization
> (2) eap_fast: TLS_accept: before SSL initialization
> (2) eap_fast: TLS_accept: before SSL initialization
> (2) eap_fast: <<< recv TLS 1.3  [length 005a]

  The other end is trying to negotiate TLS 1.3.  This is wrong.

> cipher_list is set to "ALL:!EXPORT:!eNULL:!SSLv2 at SECLEVEL=0" in fast
> {...} and "ALL:!EXPORT:!eNULL:!SSLv2" in tls-config tls-common { ...}
> as the comments in mods-available/eap suggest.

  Then cipher list is different from the TLS version.

> Does that mean that the access point insists on a newer version of TLS?

  No.  It means that the end user system (laptop, desktop, etc.) is trying to use TLS 1.3

  If the other end says that it wants to use TLS 1.3 and nothing else, then that's it.  All FreeRADIUS can do is stop doing EAP.

  Fix the end user system so that it doesn't ry to negotiate TLS 1.3.  Again, there is *no standard* defined for this.  I've been working with the IETF, hostap, and Microsoft in order to get (a) the standards written, and (b) verified interoperability.

  Once that's done, people will be able to use TLS 1.3.  Until then, don't use it.  And any system which tries to use it is *broken*.

  Alan DeKok.