From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200508120821.j7C8Lqq14607@zamenhof.cs.utwente.nl>
To: 9fans@cse.psu.edu
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 12 Aug 2005 10:21:52 +0200
Subject: [9fans] libsec tls extension: computation of session key?
Topicbox-Message-UUID: 76b75dd2-ead0-11e9-9d60-3106f5b1d025

the standard that describes the 802.1x eap-ttls method
discusses the computation of some 'keying material'
as result of the auth handshake.

this material is computed as:
   tls->sec->prf(resultBuf, resultLen,
                 tls->sec->sec, MasterSecretSize,
                 labelString,
                 tls->sec->crandom, RandomSize,
                 tls->sec->srandom, RandomSize );

where labelString is a string prescribed by the protocol,
and resultBuf is the buffer to be holding the result of resultLen.

Either we can expose all details necessary for the computation,
or we can just do the computation and only expose the result.
I have done the latter, by adding resultBuf, resultLen, and
labelString to the TLSconn struct, and doing above computation
(and only doing it if the resultbuf pointer is non-nil)
near the end of the tlsClient function.

Is this a reasonable way of doing this?
If so, should I just submit a patch? (for tlshand.c and libsec.h)

on a related note: there is a minor decoding error in tlshand.c,
in the HCertificateRequest; I'll submit a separate patch.
our universities's server seems to computing some lenth field
of the HCertificateRequest erroneously, I could work around 
that by slightly relaxing size checking of HCertificateRequest;
I'll submit a separate patch for that, I guess...

Axel.