About Shared secret from DH key exchange

[Jouni Malinen]

On Thu, Apr 03, 2008 at 03:42:37PM +0800, Jack Yip wrote:

> In fact, the msg "*Mar  8 06:02:30.466: RADSRV EAP-FAST: DH public number generation failed" is not a problem.As I have tried your supplicant (with internal TLS instead of OPENSSL)compiled in MS visual studio , and there will be the same msg coming out ,but the program can have successfull authenciation with the CISCO server with EAP-FAST.

OK. That's useful to know.

> The main reason for the failure in my porting is the msg"*Mar  8 06:02:41.409: RADSRV EAP-FAST: invalid tunnel MIC" during the Cisco Server was calculating Master secret.

The key derived from TLS is used in MIC calculation, so the zero-length
shared secret is most likely causing this.

> I have also diff the output msg from your supplicant in Windows XP and in my porting PALM device. I feel very strange that the Shared secret from DH key exchange has 0 length which that will not appear in windows XP. 

> I have attached the full debug log from the porting device.

It looks like something goes wrong with the second modexp operation in
DH. This is quite odd since the first one (derivation of the client
public value) is using the exact same function and that results in
correct value. The second call to crypto_mod_exp() (derivation of shared
secret) returns with zero-length result. This indicates that something
went wrong here.

Unfortunately, 0.5.x versions of wpa_supplicant do not have any kind of
error validation for DH operations in the internal TLS implementation.
The current 0.6.x version would provide more information here. Anyway, I
would suggest debugging crypto_mod_exp() function in crypto_internal.c.
I would assume that one of the operations in it fails when the function
is being called for the second time. Either use a debugger (if
available) or add some wpa_printf() calls to report which one of the
function calls fails (goto error).

-- 
Jouni Malinen                                            PGP id EFC895FA