Hi all,
There are a number of new protocols in the proposal/early adoption phases that
will probably require the support of a new public library function in
openssl.
These protocols (more below) are used for authenticating roaming access for
802.1x wireless access. They generally use TLS (tunnelled over the Radius UDP
protocol) to establish a secure channel over which the roaming wireless
client is authenticated by a Radius server.
The issue is that they require access to the master_key, client_random,
server_random and the TLS1 pseudo-random-function (PRF) to check challenge
material and to generate MPPE keys. Unfortunately, none of the functions in
openssl t1_enc.c implement the exact requirements, and the ones that might be
used as building blocks are declared as static
The new protocols I know of now are:
1. EAP-TTLS (draft-ietf-pppext-eap-ttls-01.txt) currently available on Funk
Odyssey wireless clients. To check the challenges from the client, it
requires:
EAP-TTLS_challenge = PRF(SecurityParameters.master_secret,
"ttls challenge",
SecurityParameters.client_random +
SecurityParameters.server_random);
and to generate the MPPE keys, it requires
PRF(SecurityParameters.master_secret,
"ttls keying material",
SecurityParameters.client_random +
SecurityParameters.server_random);
where PRF is the TLS1 pseudo-random-function
(note that the order client + server for the random is the reverse of what TLS
generally uses). Further the PRF is required to deliver various lengths of
key material from 7 to 64 octets in length.
2. PEAP (draft-josefsson-pppext-eap-tls-eap-02.txt) currently under
development by Cisco et al.
It requires:
PRF(master key, "client PEAP encryption", client_random + server_random)
and
PRF("", "client PEAP encryption", client_random + server_random)
In the interests of supporting these protocols, I think there needs to be a
public library function (possibly in t1_enc.c) which can be passed a keying
string and the number of octets required, and which returns
PRF(master_key, string, client_random + server_random) with as many octets as
requested.
Needless to say, exposing a TLS-specific function in t1_enc.c is inconsistent
with the current way that the internals of openssl are encapsulated. Is there
a better way?
Views?
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
