Questions on using EAP-AKA

[Jouni Malinen]

On Mon, Dec 30, 2013 at 11:04:13AM -0800, Ben Greear wrote:
> Ok, I am not sure the SQN handling is working properly or not, but
> it appears the main failure at this point is that I am using gnutls
> and it does not support a method called by eap_sim_derive_keys:
> 
> 
> int fips186_2_prf(const u8 *seed, size_t seed_len, u8 *x, size_t xlen)
> {
> 	/* FIX: how to do this with libgcrypt? */
> 	return -1;
> }

Ah, yes. I haven't looked at this recently, but at least in the past,
GnuTLS would have required full reimplementation of SHA-1 for this PRF.
That could obviously be done (e.g, fips_prf_internal.c and the internal
SHA-1 implementation option), but in practice, GnuTLS with
wpa_supplicant is not really supported even remotely as well as OpenSSL;
nor would I really recommend this combination for most cases.

> I see another note in the supplicant config file that openssl does
> not support all of EAP-FAST unless patched.

That's an old note that has not been updated after OpenSSL 1.0 was
released with the changes needed for EAP-FAST.

> So, question is, what SSL should I use for fullest functionality?

OpenSSL 1.0 or newer

> I will add some extra logging to print big errors if eap_sim_derive_keys
> fails, as it appears that can only happen when the SSL implementation
> is deficient.
> 
> Maybe it should even be a build error to compile in AKA while using gnutls?

Yes, that would make more sense. I guess I was planning on implementing
fips186_2_prf() for GnuTLS (or well, libgcrypt), but never got that far.
I guess I (or someone else) could take a newer look at how easily this
could be done with the current version and if that does not go through,
just remove fips_prf_gnutls.c.

-- 
Jouni Malinen                                            PGP id EFC895FA