GnuTLS 1.2.8 with TLS Inner Application (TLS/IA) support
Wed Dec 14 20:19:46 PST 2005
On Wed, Dec 14, 2005 at 02:37:02PM +0100, Simon Josefsson wrote:
> We are pleased to present a customized version of GnuTLS 1.2.8 that
> adds an implementation of the TLS Inner Application (TLS/IA) protocol.
> The goal is to merge this TLS/IA branch with the main development
> branch (1.3.x) and then to investigate how EAP-TTLSv1 can be
> implemented. We invite suggestions and comments on these matters.
This is interesting and welcome development to see in an open source TLS
library. I've considered implementing EAP-TTLSv1, but haven't so far had
enough interest to start working on it; partly because of it involving
changes to the TLS library.
I've implemented EAP-TTLSv0 in wpa_supplicant (EAP peer) and hostapd
(EAP authenticator/authentication server). Both of these programs use an
internal TLS wrapper interface to allow different TLS libraries to be
used. In case of wpa_supplicant, there is enough functionality to run
EAP-TTLSv0 with both OpenSSL and GnuTLS.
One of the things I'm currently going through in the new development
branch is cleanup on various internal interfaces and one of these would
indeed be the TLS wrapper interface. This would be a good point to also
take a look at what kind of functionality would be needed to add support
for using TLS/IA and start extending EAP-TTLS code to support version 1.
I haven't yet looked into details of the TLS/IA changes. However, I have
one thing in my mind from the earlier experience of adding GnuTLS
support. EAP-TLS/TTLS/PEAP/FAST require access to couple of values that
are internal to the TLS handshake, namely, master_secret, client_random,
and server_random. However, I have not found a supported, public API
call for getting these from GnuTLS. These are stored in
security_parameters_st, but that seems to be only used internally
(defined in gnutls_int.h).
My current workaround is to make a copy of this structure and fetch the
parameters with direct read through gnutls_session::security_parameters.
Another option would be to parse the values from debug messages (using
log function callback). Neither option seems very nice since they
are relying on the internal structure not changing and/or debug messages
remaining in the same format. I'm actually keeping a list of tested
GnuTLS versions and only allow tested versions to be used because of
this workaround. Adding a public API call or structure definition for
getting these values would be quite useful for EAP implementations.
Jouni Malinen PGP id EFC895FA
More information about the Hostap