iOS mysterious issues on Freeradius 3.0.14

[A.L.M.Buxey at lboro.ac.uk]

Hi,

> With the exception of Android, which may eventually get its act together, If you are
> going to go through the trouble of installing a local CA on all your clients, you can
> just as well set up the SSIDs to properly demand that a particular CA root is used,
> and the DN is checked.  Once  you've made the commitment to touch all clients in
> this manner it is a sunk cost.

1) you cant set the SSID up to demand that clients are comfigured in a certain way.... the server
doesnt not know if the client has things checked

2) if you have no control of all clients - eg common in HE, BYOD etc - and anyone can come along, connect
their iPad to the SSID and put in user/pass - you have no control over their security. 

a public CA will let part 2 be a nightmare...a private CA means they cannot connect until private CA
installed (become known/trusted)

> c) all the Apple devices pin the cert after first use... which is great until it needs to be replaced.

if user just clicks SSID and clicks okay then the server cert is pinned. if the configuration is
pushed via profile, then so long as the CA is the same and the server CN/SAN is the same  its silently accepted.

> "FreePublicWiFi" rather than your institutional SSID.  Some institutions cannot practically
> police their RF environment *at all*, so merely using confusable characters in look-like
> SSIDs can bypass all your efforts and yield a password dialogue into which users will
> gladly type their creds, regardless of which kind of CA you run.

the historic issue used to be that getting a local CA onto client devices was a pain.....that is no longer true -
with deployment tools - free ones like eduroamCAT or commercial ones like XpressConnect, Clearpass etc - and
you really want to use those sorts of tools to ensure your clients are properly configured ANYWAY - so you may
as well do the local CA at the same time for more security. 

> Anyway, "convenience" is the whole reason SSO systems are implemented.

and SSO brngs with it the 'you are using the same password for everything - your password is then
very high value indeed'.  in these places, use the SSO to GET the required token - EAP-TLS certificate.
dont use user/pass for auth - use EAP-TLS, then the MiTM is no possibility (with local CA still too! ;-) )

> Addressing that slide presentation about TLS: until it gets a *live* password mechanism in
> addition to the PKI, it doesn't serve some important security needs.   Having either TLS evolve
> in that direction or PEAP supplicants evolve towards accommodating client certs is probably
> the point at which I can get management to buy into maintaining our own CA, and if I had
> to guess which would reach the built-in supplicant base first, it would not be an extended
> TLS.

PEAP already does client certs - OS support may vary ;-)

> I think the constant badmouthing of password-based methods both in the EAP and SSH realms

its 2017 and we're still using passwords - enough said  ;-)

alan