GnuTLS 1.2.8 with TLS Inner Application (TLS/IA) support

Simon Josefsson jas at extundo.com
Thu Dec 15 11:47:47 EST 2005


Jouni Malinen <jkmaline at cc.hut.fi> writes:

> On Thu, Dec 15, 2005 at 10:00:05AM +0100, Simon Josefsson wrote:
>
>> I did look at the code, and found this modularization neat.  I did
>> wonder whether the GnuTLS wrapper was complete enough for EAP-TTLSv0
>> to work, so you answered one of my questions here.
>> 
>> Is there anything the GnuTLS wrapper in wpa_supplicant does not
>> support?  I.e., is there ever a need to use OpenSSL?  If feasible,
>> we'd like for distributors of wpa_supplicant (like Debian) to use
>> wpa_supplicant with GnuTLS, so that EAP-TTLSv1 can work.
>
> GnuTLS wrapper is not yet complete. EAP-TTLSv0 and EAP-PEAPv0/1 are
> relatively complete, but I don't think EAP-TLS was working correctly (I
> don't remember for sure, but probably due to client certificate or
> private key not configured correctly). In addition, some details of the
> certificate chain validation are likely either incorrect or missing
> (extra constraints, like verifying server certificate common name,
> etc.). EAP-FAST is also missing (though, even with OpenSSL, it requires
> a patch that is not in OpenSSL distribution). There may also be some
> missing parts for session resumption.

Ok.  Thanks for the info.

> One large missing part is not in the functionality side, but on testing.
> I would assume that tls_gnutls.c has not really been used in any
> production use so far. I haven't promoted the TLS configuration part
> because of not yet having confirmed that all the critical functionality
> is available and works with other than OpenSSL wrapper. I think that the
> next step would be to make sure that the basic functionality is
> available and works. After that, it would be easier to get people
> testing wpa_supplicant with GnuTLS and once that has been going on for
> awhile, it would be much easier to start saying that either OpenSSL or
> GnuTLS can be selected without having unwanted effects for functionality
> or security of the program.

Right, I understand.  I'll see if we can help test this more.

>> Another question: I also see there is a TLS wrapper for Schannel.
>> Does EAP-TTLSv0 in wpa_supplicant work under Windows?  Does it use the
>> Windows SSPI credential store and CA certificates?  In general, how
>> complete is the Windows support in wpa_supplicant?
>
> EAP-TTLSv0 does indeed work under Windows, but not with Schannel. The
> problem here is that I don't think there is any reasonable way of
> fetching master_secret from Schannel and that makes it pretty much
> unsable for EAP-TTLS.

Right.  How you looked at other TLS implementations for Windows?
SecureW2 include one, and even has a EAP-TTLS client:

http://www.securew2.com/uk/index.htm

Perhaps it is possible to re-use some of the code.  I did find a huge
security hole when I looked at it briefly a while ago, so I understand
if you wouldn't want to incorporate that code.

> Schannel can be used for EAP-TLS (which I don't remember whether I
> implemented yet in wpa_supplicant) and EAP-PEAP, but that's about
> it.

IIRC, both EAP-TLS and EAP-PEAP are implemented in Windows.

> When it is used, Schannel does indeed use Windows certificate store
> for all certificates and the private key.

Ok, that is good.

> When used with OpenSSL, Windows support in wpa_supplicant is pretty much
> complete, especially so with 0.5.x development branch that adds registry
> and service support to the Windows version. As far as TLS interface is
> concerned, OpenSSL wrapper has all the same functionality that on Linux
> and in addition, private keys and client certificates can be used
> through the OS certificate store. I haven't yet added support for using
> certificate store for CA certificates, though.

Has wpa-supplicant with GnuTLS been tested under Windows?

Perhaps it would be useful to separate the CAPI stuff in
tls_openssl.c, so that retrieving the certificate and keys from the
Windows store isn't OpenSSL specific.

Thanks for your feedback!

Regards,
Simon



More information about the HostAP mailing list