diameter AVP decoding/creation working correctly?

Tue, 04 Nov 2003 15:34:29 -0800

Hi,

I can't get freeRADIUS to accept any TTLS session that doesn't use PAP as inner auth method.
The client using TTLS to authenticate is MacOS X 10.3 (Panther) supplicant.
I was using todays snapshot and also tried at least three more snaphsots over the last two weeks.

Here is the log when a supplicant attempts to use TTLS with MSCHAPv2:

Tue Nov 4 12:23:34 2003 : Debug: auth: type "EAP"
Tue Nov 4 12:23:34 2003 : Debug: modcall: entering group authenticate for request 23
Tue Nov 4 12:23:34 2003 : Debug: modsingle[authenticate]: calling eap (rlm_eap) for request 23
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap: Request found, released from the list
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap: EAP_TYPE - ttls
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap: processing type ttls
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap_ttls: Authenticate
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap_tls: processing TLS
Tue Nov 4 12:23:34 2003 : Info: rlm_eap_tls: Length Included
Tue Nov 4 12:23:34 2003 : Debug: eaptls_verify returned 11
Tue Nov 4 12:23:34 2003 : Debug: eaptls_process returned 7
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes.
TTLS tunnel data in 0000: 00 00 00 01 00 00 00 14 41 6e 64 72 65 61 73 20
TTLS tunnel data in 0010: 57 6f 6c 66 00 00 00 0b 80 00 00 1c 00 00 01 37
TTLS tunnel data in 0020: b1 99 16 b8 37 30 16 f3 20 57 2e 99 96 7b 26 03
TTLS tunnel data in 0030: 00 00 00 19 80 00 00 3e 00 00 01 37 02 00 70 51
TTLS tunnel data in 0040: 9f 62 47 cf 74 18 2f 28 a6 5d 38 d2 0f 76 00 00
TTLS tunnel data in 0050: 00 00 00 00 00 00 63 7c 09 aa f8 4a 0e 95 0b 22
TTLS tunnel data in 0060: 13 4a f0 2e 1a be b1 a1 85 41 45 7f f9 5c
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap_ttls: Tunneled attribute 0 has invalid length 0
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap: Handler failed in EAP type 21
Tue Nov 4 12:23:34 2003 : Debug: rlm_eap: Failed in EAP select
Tue Nov 4 12:23:34 2003 : Debug: modsingle[authenticate]: returned from eap (rlm_eap) for request 23
Tue Nov 4 12:23:34 2003 : Debug: modcall[authenticate]: module "eap" returns invalid for request 23
Tue Nov 4 12:23:34 2003 : Debug: modcall: group authenticate returns invalid for request 23
Tue Nov 4 12:23:34 2003 : Debug: auth: Failed to validate the user.

Looking at the tunneled data it doesn't appear that the suuplicant is sending tunneled diameter attributes with length 0:

AVP 1 with Length 0x14 (20): 
00 00 00 01 00 00 00 14 41 6e 64 72 65 61 73 20
57 6f 6c 66
AVP 2 with Length 0x1c (28) 
00 00 00 0b 80 00 00 1c 00 00 01 37
b1 99 16 b8 37 30 16 f3 20 57 2e 99 96 7b 26 03
AVP 3 with Length 0x3e (62) 
00 00 00 19 80 00 00 3e 00 00 01 37 02 00 70 51
9f 62 47 cf 74 18 2f 28 a6 5d 38 d2 0f 76 00 00
00 00 00 00 00 00 63 7c 09 aa f8 4a 0e 95 0b 22
13 4a f0 2e 1a be b1 a1 85 41 45 7f f9 5c

and that's all the tunneled data. I debugged it enough to know that it builds all three AVPs correctly but then
it continues with one more attribute and determines that its length is 0 - therefore fails to validate.
I don't know what in the code makes it think there are more attributes (possibly the padding code?).

I changed the code in ttls.c to ignore that condition (ignore AVP with Length =0) and that works for me.
However, it seems if the code would decode the AVPs correctly there wouldn't be any AVPs with length 0.

Any ideas for a fix?

Thanks,
-Andreas





- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to