[RADIATOR] UNS: Re: TLS v1.3

Mon Oct 24 15:25:39 UTC 2022

Hi Heikki,

We are using the "EAPTLS_Protocols TLSv1.3" currently in all of our
AuthBy's for good measure.  However, the TLS handshake appears to not use
TLSv1.3 outbound for the establishment, and instead tries TLSv1.2 which
fails.
See these two debug lines:
DEBUG: AuthSQL EAP-TTLS TLS handshake: Direction* IN, Version: TLS 1.3*,
Record content: (22) Handshake, message type: (1) ClientHello
DEBUG: AuthSQL EAP-TTLS TLS handshake: Direction *OUT, Version: TLS 1.2*,
Record content: (21) Alert, level: (2) fatal, description: (70) protocol
version

Ideas?

Cassidy

On Mon, Oct 24, 2022 at 3:36 AM Heikki Vatiainen via radiator <
radiator at lists.open.com.au> wrote:

> On 22.10.2022 0.15, Dubravko Penezic via radiator wrote:
>
> > from my experience you have two options :
> > * set system SSL library to work only wit TLS v1.3
> > * set RADIATOR configuration to accept only TLS v1.3 by setting
> > TLS_Protocols to TLSv1.3
>
> I would the latter and put this to Radiator configuration under the
> AuthBy that terminates EAP-TTLS tunnel:
>
> <AuthBy ...>
>     # To support both TLSv1.2 and 1.3
>     #EAPTLS_Protocols TLSv1.2, TLSv1.3
>
>     # To support just TLSv1.3
>     EAPTLS_Protocols TLSv1.3
>
> TLS_Protocols controls RadSec, Diameter and other non-EAP protocols.
> It's a config option, but not for EAP.
>
> > Also be aware that from many recent reports client which declare that
> > work only with TLS v1.3 doesnt do that on correct way or not work at all
> > with v1.3.
>
> EAP-TTLS is currently set in Radiator 4.26-24 and other 4.26-nn versions
> so that session resumption is disabled. The reasons is for this is that
> EAP-TTLS/PAP (and non-EAP CHAP variants) did not work with all EAP-TTLS
> implementations. The reason is how session resumption is done and is one
> example not fully all clients fully working.
>
> For more information see discussion related to document
> draft-ietf-emu-tls-eap-types that has been ongoing this year on the
> IETF's EAP Method Update (EMU) mailing list:
>
> https://www.ietf.org/mailman/listinfo/emu
>
> The next Radiator release supports TLSv1.3 for RadSec and has been
> updated for EAP-TLS, EAP-TTLS and PEAP with TLSv1.3. There could still
> be some work-arounds enabled, such as disabled session resumption, but
> full authentication should work fine for the said EAP methods.
>
> Thanks,
> Heikki
>
>
> > Regards,
> > Dubravko Penezic
> > Srce
> >
> > On 10/21/22 22:54, Cassidy B. Larson via radiator wrote:
> >> More specifically, here's the debug output:
> >>
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL Handling EAP type 1
> >> (Identity), code: 2 (Response), identifier: 191, length: 20
> >> Fri Oct 21 14:52:17 2022: DEBUG: Initialised SSL library: Net::SSLeay
> >> 1.92, OpenSSL 1.1.1o-freebsd  3 May 2022
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x9 (9) for Net::SSLeay
> >> constant ERROR_WANT_ASYNC
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0xa (10) for Net::SSLeay
> >> constant ERROR_WANT_ASYNC_JOB
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0xb (11) for Net::SSLeay
> >> constant ERROR_WANT_CLIENT_HELLO_CB
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0xc (12) for Net::SSLeay
> >> constant ERROR_WANT_RETRY_VERIFY
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x8 (8) for Net::SSLeay
> >> constant SSL2_MT_CLIENT_CERTIFICATE
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x3 (3) for Net::SSLeay
> >> constant SSL2_MT_CLIENT_FINISHED
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x2 (2) for Net::SSLeay
> >> constant SSL2_MT_CLIENT_MASTER_KEY
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x0 (0) for Net::SSLeay
> >> constant SSL2_MT_ERROR
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x6 (6) for Net::SSLeay
> >> constant SSL2_MT_REQUEST_CERTIFICATE
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x6 (6) for Net::SSLeay
> >> constant SSL2_MT_SERVER_FINISHED
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x4 (4) for Net::SSLeay
> >> constant SSL2_MT_SERVER_HELLO
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x5 (5) for Net::SSLeay
> >> constant SSL2_MT_SERVER_VERIFY
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x2 (2) for Net::SSLeay
> >> constant TLSEXT_ERR_ALERT_FATAL
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x1 (1) for Net::SSLeay
> >> constant TLSEXT_ERR_ALERT_WARNING
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x3 (3) for Net::SSLeay
> >> constant TLSEXT_ERR_NOACK
> >> Fri Oct 21 14:52:17 2022: DEBUG: TLS: Using 0x0 (0) for Net::SSLeay
> >> constant TLSEXT_ERR_OK
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL setting TLS protocols to:
> >> TLSv1.3
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL setting EAPTLS_Ciphers to:
> >> DEFAULT:!EXPORT:!LOW at SECLEVEL=1
> >> Fri Oct 21 14:52:17 2022: DEBUG: EAP result: 3, EAP-TTLS Challenge
> >> Fri Oct 21 14:52:17 2022: DEBUG: Radius::AuthGROUP:  result:
> >> CHALLENGE, EAP-TTLS Challenge
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthBy GROUP result: CHALLENGE,
> >> EAP-TTLS Challenge
> >> Fri Oct 21 14:52:17 2022: DEBUG: Access challenged for <....>:
> >> EAP-TTLS Challenge
> >>
> >>
> >> Fri Oct 21 14:52:17 2022: DEBUG: Handling with Radius::AuthGROUP:
> >> Fri Oct 21 14:52:17 2022: DEBUG: Handling with AuthSQL
> >> Fri Oct 21 14:52:17 2022: DEBUG: Handling with Radius::AuthSQL:
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL Handling EAP type 21 (TTLS),
> >> code: 2 (Response), identifier: 192, length: 196
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: before
> >> SSL initialization
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: before
> >> SSL initialization
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: before
> >> SSL initialization
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS handshake:
> >> Direction IN, Version: TLS 1.3, Record content: (22) Handshake,
> >> message type: (1) ClientHello
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS handshake:
> >> Direction OUT, Version: TLS 1.2, Record content: (21) Alert, level:
> >> (2) fatal, description: (70) protocol version
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: error
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS TLS state: error
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP-TTLS SSL_accept result:
> >> -1, reason/error: 'SSL_ERROR_SSL, state: 'error'
> >> Fri Oct 21 14:52:17 2022: ERR: AuthSQL EAP-TTLS TLS Handshake error:
> >> result: -1, reason/error: 'SSL_ERROR_SSL', state: 'error',
> >> error:14209102:SSL
> >> routines:tls_early_post_process_client_hello:unsupported protocol
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthSQL EAP Failure, elapsed time
> >> 0.050957
> >> Fri Oct 21 14:52:17 2022: DEBUG: EAP result: 1, EAP-TTLS TLS Handshake
> >> error: unsupported protocol
> >> Fri Oct 21 14:52:17 2022: DEBUG: Radius::AuthGROUP:  result: REJECT,
> >> EAP-TTLS TLS Handshake error: unsupported protocol
> >> Fri Oct 21 14:52:17 2022: DEBUG: AuthBy GROUP result: REJECT, EAP-TTLS
> >> TLS Handshake error: unsupported protocol
> >> Fri Oct 21 14:52:17 2022: INFO: Access rejected for 888901007406545:
> >> EAP-TTLS TLS Handshake error: unsupported protocol
> >>
> >> We're running OpenSSL 1.1.1o and Net:SSLeay 1.92 as detailed above.
> >>
> >>
> >> On Fri, Oct 21, 2022 at 1:39 PM Cassidy B. Larson <alandaluz at gmail.com
> >> <mailto:alandaluz at gmail.com>> wrote:
> >>
> >>     We're spinning up a new EAP-TTLS source. Installed latest dev of
> >>     4.26-24. When I force EAP_TLS_Protocols to TLSv1.3 alone, I see the
> >>     TLSv1.3 handshake request come in, but outbound handshake is
> >>     TLSv1.2.  Apparently our vendor only allows TLSv1.3 right now.
> >>
> >>     Any ideas how to get outbound handshakes to use TLSv1.3?
> >>
> >>     Fri Oct 21 13:30:12 2022: DEBUG: AuthSQL EAP-TTLS TLS handshake:
> >>     Direction IN, Version: TLS 1.3, Record content: (22) Handshake,
> >>     message type: (1) ClientHello Fri Oct 21 13:30:12 2022: DEBUG:
> >>     AuthSQL EAP-TTLS TLS handshake: Direction OUT, Version: TLS 1.2,
> >>     Record content: (21) Alert, level: (2) fatal, description: (70)
> >>     protocol version
> >>
> >>
> >>     Thanks!
> >>
> >>     -c
> >>
> >>
> >> _______________________________________________
> >> radiator mailing list
> >> radiator at lists.open.com.au
> >> https://lists.open.com.au/mailman/listinfo/radiator
> > _______________________________________________
> > radiator mailing list
> > radiator at lists.open.com.au
> > https://lists.open.com.au/mailman/listinfo/radiator
>
> --
> Heikki Vatiainen
> OSC, makers of Radiator
> Visit radiatorsoftware.com for Radiator AAA server software
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20221024/50d77da3/attachment.html>