On Apr 7, 2017, at 3:31 PM, Alan DeKok <aland@deployingradius.com> wrote:

On Apr 7, 2017, at 3:17 PM, David Teston <dteston@georgialibraries.org> wrote:

...

Where can I find a protocol compatibility matrix for each OS?

Nowhere in particular. Feel free to update the wiki.

...

I would like to find something like this <http://deployingradius.com/documents/protocols/compatibility.html> for all major OS's.

For example: iOS - PEAP, CHAP Android - PAP

For WifI? Nope. TTLS.

...

Windows 7 - EAP-TLS, MS-CHAP Windows 10 - EAP-GTC, EAP-TLS

Both are PEAP.

...

MacOS - PEAP

and TTLS.

...

Also, can we prioritize the protocols?

Nope. The client chooses the protocol. The server either rejects the request or accepts it.

...

Since PAP is the least secure, I'd like clients to try the other protocols and use PAP as the last option.

There is no way to prioritize protocols in EAP.

Not entirely true, you can at least choose what the initial proposal is, but after that it's up to the client. https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/mods-avail... -Arran

On Fri, Apr 07, 2017 at 07:39:48PM +0000, Brian Julin wrote:

Haven't seen one. Really we need some bored retiree to start a beer money kickstarter to test and maintain giant compatibility tables, not just for this, but for all the nuances of wifi chipsets.

If they started at retiring age they'd be dead before it was even half finished if chipsets are included.

PAP should only be used when confined to unsniffable internal administrative networks... there's no good reason to use it elsewhere as all it will do is expose your user's passwords, which is worse than having no password security at all.

Nowt really wrong with PAP inside EAP/TTLS. At least, no worse than MSCHAPv2. With PAP the password is encrypted inside TTLS, and you can store it securely on the server. With MSCHAPv2 it's the same level of encryption over the wire (as the MSCHAPv2 is easy to break), *and* you have to store easy to break NTLM hashes on the server. i.e. EAP-TTLS/PAP is arguably more secure. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>

On Fri, Apr 07, 2017 at 08:05:09PM +0000, Cappalli, Tim (Aruba Security) wrote:

Not sure I’d agree that an NTLMv2 hash is easier to crack than PAP.

That wasn't what I said... It is easily possible to crack MSCHAPv2. With TTLS, both are in the same level of encrypted tunnel, so essentially equivalent. When the client doesn't properly trust the RADIUS server, both are broken. But with PAP you can store the password on the server in the most secure way possible with $today's technology. With MSCHAPv2 you are limited to NTLM hashes, which are broken.

I’d take PEAPv0/EAP-MSCHAPv2 over EAP-TTLS/PAP any day.

Of course, anyone can choose what they're going to use. A lot of people just permit both, and TBH given that convenience for the end client device generally takes precedence over security the difference between them is probably not worth worrying about. :( Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>

David wrote:

Brian, I agree with you about PAP. We have multi-site organization, so passwords will be transmitted over WAN. Might have to explore Matthew and TIm's suggestions.

Save you the trouble: The cliff notes on 1-factor/built-in-supplicants are: If it's for infrastructure admin access (switches, etc) only bad options are available. Secure your control plane with a fail-closed IPSEC setup first. Hope you bought gateways with good L2L VPN feature sets. If it's for WiFi or wired EAPOL, use EAP-TLS, EAP-PEAP-MSCHAPv2, or EAP-TTLS-something depending on your needs. If it's for IPSEC-RA/IKEv2, don't hit the AAA servers directly from the initial IKEv2 auth phase on Windows clients... use the above protocols for an inner EAP auth and validate the AAA cert... agilevpn does not adequately protect against downgrade attacks by validating the IKE cert unless you do this. That means you'll want to send Linux and OSX to a different IPSEC-RA/IKEv2 instance than Windows because they can validate IKE certs correctly, and OSX doesn't support any good inner auths.