[RADIATOR] Apple iOS 9 and OS X El Capitan

[Heikki Vatiainen]

On 07/30/2015 08:57 PM, Nick Lowe wrote:
> Agreed: "Added support for SSL_export_keying_material where present
> (ie in OpenSSL 1.0.1 and later)."

Support for this Net::SSLeay function was added in Radiator 4.11
patches. In other words, Radiator 4.12 and later will use it if it's
available.

https://www.open.com.au/radiator/history.html

> Not tested, but I suspect that we will find that 1.53 is the version
> at which this starts to work and, if so, it should become the minimum
> version that should be used.

That's quite likely. I'm currently travelling so I don't have a good
opportunity to test this yet. What it looks like is that Net::SSLeay
1.53 + OpenSSL 1.0.1 are the minimum requirement for TLSv1.2 support for
TLS based EAP methods. The former for correct MPPE key calculation and
the latter for TLSv1.2 (and TLSv1.1).

I previously mentioned Net::SSLeay 1.46, but it seems to be missing
SSL_export_keying_material, altough it provides constants
Net::SSLeay::OP_NO_TLSv1_1 and Net::SSLeay::OP_NO_TLSv1_2 which allow
setting the desired TLS versions.

Another thing to consider is the change introduced in Radiator 4.13
patches: Radiator 4.13 + patches, 4.14 and 4.15 allow TLSv1.0, 1.1 and
1.2 for TLS based EAP methods. Previously only TLSv1.0 was allowed.

What Klara reported is one example where this can cause problems even
when EAPTLS_Protocols is not set: TLSv1.2 tunnel is successfully
negotiated but the MPPE keys are not calculated correctly because of an
old Net::SSLeay. The fix could be to upgrade Net::SSLeay or allow only
TLS 1.0 and 1.1. However, if Net::SSLeay is too old, for example
RHEL/CentOS 6, then the missing constants do not allow this and the only
option that remains is to upgrade Net:SSLeay.

For the above reason this might be a good default:
- Revert back to TLSv1.0 by default (when EAPTLS_Protocols is not defined)
- When EAPTLS_Protocols is defined, check the Net::SSLeay version and
complain if it is older than 1.53 and OpenSSL version indicates that
TLSv1.1 and TLSv1.2 are not supported

I'd say the above should not cause problems when TLSv1.2 (and 1.1)
clients become more widely used because the server would default to
choosing TLSv1.0. On the server side this has worked for ages and quite
likely the TLSv1.2 supporting clients do not refuse TLSv1.0 by default,
at least yet.

When TLSv1.1 and TLSv1.2 server side support is required, it can be
turned on with EAPTLS_Protocols. If there are problems, the rollback can
be done by commenting out EAPTLS_Protocols and going back to TLSv1.0.

Any comments on this?

The above changes would probably mean a release to make the change
easier for everyone. The changes would go to patches first for those who
are interested in testing the new defaults and behaviour.

Thanks for your comments, everyone!
Heikki

> On Thu, Jul 30, 2015 at 6:49 PM, Christopher Bongaarts <cab at umn.edu> wrote:
>> On 7/30/2015 12:43 PM, Nick Lowe wrote:
>>>
>>> 1.46 doesn't work.
>>
>>
>> Quickly looking through the release notes, 1.53 has a change that seems
>> relevant.

-- 
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.