Hi Alan,
I got EAP-TLS-EAP-MSCHAPV2 working but I had to tweak SecureW2 a bit for FreeRadius.
I had a closer look and this is what I came up with (With help of the -Xxx ;)):
this is the log file of FreeRadius:
Mon Mar 8 08:51:30 2004 : Debug: modcall: group authenticate returns handled for
request 15
TTLS: Got tunneled reply RADIUS code 11
MS-CHAP2-Success =
0x00533d42463341433543334533343636464443424237423439413744303337443741334338333441413836
MS-MPPE-Recv-Key = 0x759a726e4985b73a7bd99c9b1e56d215
MS-MPPE-Send-Key = 0x19c1e335bed2de6b215dbbeec4d175ec
MS-MPPE-Encryption-Policy = 0x00000001
MS-MPPE-Encryption-Types = 0x00000006
EAP-Message =
0x010200331a0301002e533d42463341433543334533343636464443424237423439413744303337443741334338333441413836
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x5bef466393edf2ac59626d5581d57a6c
Mon Mar 8 08:51:30 2004 : Debug: TTLS::process_reply
Mon Mar 8 08:51:30 2004 : Debug: TTLS: Got tunneled Access-Challenge
TTLS tunnel data out 0000: 00 00 00 4f 40 00 00 3b 01 02 00 33 1a 03 01 00
TTLS tunnel data out 0010: 2e 53 3d 42 46 33 41 43 35 43 33 45 33 34 36 36
TTLS tunnel data out 0020: 46 44 43 42 42 37 42 34 39 41 37 44 30 33 37 44
TTLS tunnel data out 0030: 37 41 33 43 38 33 34 41 41 38 36 00 00 00
Mon Mar 8 08:51:30 2004 : Debug: TTLS: handled Access-Challenge
Mon Mar 8 08:51:30 2004 : Debug: TTLS::process_reply returning: 11
Mon Mar 8 08:51:30 2004 : Debug: RLM_MODULE_REJECT: 0
Mon Mar 8 08:51:30 2004 : Debug: RLM_MODULE_HANDLED: 3
Mon Mar 8 08:51:30 2004 : Debug: RLM_MODULE_UPDATED: 8
Mon Mar 8 08:51:30 2004 : Debug: eapttls_process: returning 11
Mon Mar 8 08:51:30 2004 : Debug: rlm_eap_ttls::eapttls_authenticate:
eapttls_process returned 11
Mon Mar 8 08:51:30 2004 : Debug: modsingle[authenticate]: returned from eap
(rlm_eap) for request 15
Mon Mar 8 08:51:30 2004 : Debug: modcall[authenticate]: module "eap" returns
handled for request 15
Mon Mar 8 08:51:30 2004 : Debug: modcall: group authenticate returns handled for
request 15
Sending Access-Challenge of id 183 to 192.168.0.104:32778
EAP-Message =
0x010a00b41580000000aa1703010018d9ebc6a739379802c18e5769d95be6399c152413ad8ce9171703010088982d2a091ef7d383e715114af75ec1cecc6aa03a45a5dbfc28c2e157e908d3fdd5b887c0b6f5daf618ac3b9b23fad8b3acf4c6e4cf06911bace0aab5cd3dd75327b73cb0abd286aa97cf54c04174f9326ffb6268c3dcbf0ec4c3b1c86899a42ff58f104ba34138ef0e727c6859a759cb02e1a944f7e2892c5b454143a742975e6a35e6f2eabb0182
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x8ed06f90e771f7fd1aa6806076a375b2
Mon Mar 8 08:51:30 2004 : Debug: Finished request 15
Mon Mar 8 08:51:30 2004 : Debug: Going to the next request
Mon Mar 8 08:51:30 2004 : Debug: Waking up in 5 seconds...
As you can see everything looks okay, the EAP-Message is added to an AVP:
EAP-Message =
0x010200331a0301002e533d42463341433543334533343636464443424237423439413744303337443741334338333441413836
is set to:
TTLS tunnel data out 0000: 00 00 00 4f 40 00 00 3b 01 02 00 33 1a 03 01 00
TTLS tunnel data out 0010: 2e 53 3d 42 46 33 41 43 35 43 33 45 33 34 36 36
TTLS tunnel data out 0020: 46 44 43 42 42 37 42 34 39 41 37 44 30 33 37 44
TTLS tunnel data out 0030: 37 41 33 43 38 33 34 41 41 38 36 00 00 00
*** What are the last 00 00 00 on the end??? That doesn't seem right. If it were for
example
an empty packet it should be 00 00 00 00 as the length is 4 bytes in Diameter AVPs (Or
am I wrong?) ***
The stuff I can't see in the log is:
Add AVP to a TLS application data blob and encrypt.
the encrypted blob however is shown:
8d9ebc6a739379802c18e5769d95be6399c152413ad8ce9171703010088982d2a091ef7d383e715114af75ec1cecc6aa03a45a5dbfc28c2e157e908d3fdd5b887c0b6f5daf618ac3b9b23fad8b3acf4c6e4cf06911bace0aab5cd3dd75327b73cb0abd286aa97cf54c04174f9326ffb6268c3dcbf0ec4c3b1c86899a42ff58f104ba34138ef0e727c6859a759cb02e1a944f7e2892c5b454143a742975e6a35e6f2eabb0182
And this is the EAP-Message:
EAP-Message:
0x010a00b41580000000aa1703010018d9ebc6a739379802c18e5769d95be6399c152413ad8ce9171703010088982d2a091ef7d383e715114af75ec1cecc6aa03a45a5dbfc28c2e157e908d3fdd5b887c0b6f5daf618ac3b9b23fad8b3acf4c6e4cf06911bace0aab5cd3dd75327b73cb0abd286aa97cf54c04174f9326ffb6268c3dcbf0ec4c3b1c86899a42ff58f104ba34138ef0e727c6859a759cb02e1a944f7e2892c5b454143a742975e6a35e6f2eabb0182
What I receive on the other end is the following:
The EAP-Message :)
0x010a00b41580000000aa1703010018d9ebc6a739379802c18e5769d95be6399c152413ad8ce9171703010088982d2a091ef7d383e715114af75ec1cecc6aa03a45a5dbfc28c2e157e908d3fdd5b887c0b6f5daf618ac3b9b23fad8b3acf4c6e4cf06911bace0aab5cd3dd75327b73cb0abd286aa97cf54c04174f9326ffb6268c3dcbf0ec4c3b1c86899a42ff58f104ba34138ef0e727c6859a759cb02e1a944f7e2892c5b454143a742975e6a35e6f2eabb0182
------ This is logging from SecureW2 ----------
8:51:30:871::TLSDecBlock::pbEncBlock(136):
982D2A091EF7D383E715114AF75EC1CECC6AA03A45A5DBFC28C2E157E908D3FDD5B887C0B6F5DAF618AC3B9B23FAD8B3ACF4C6E4CF06911BACE0AAB5CD3DD75327B73CB0ABD286AA97CF54C04174F9326FFB6268C3DCBF0EC4C3B1C86899A42FF58F104BA34138EF0E727C6859A759CB02E1A944F7E2892C5B454143A742975E6A35E6F2EABB0182
8:51:30:871::TLSDecBlock::pbDecBlock(136):
0000004F400000340101002C1A0101002710CA9F5BCBDDA23929D85DBEC28414E859746F6D2E7269786F6D40746573742E636F6D0000004F4000003B010200331A0301002E533D424633414335433345333436364644434242374234394137443033374437413343383334414138360000005BE6A6D35924F1B695ED7D04A33B3472FB2D820A0101
8:51:30:871::TLSDecBlock::padding: 1
*** As you can see the decryption when ok and the padding and MAC is correct so this
is the exact data
received from Freeradius ***
8:51:30:881::TLSParseServerPacket::application data (114):
0000004F400000340101002C1A0101002710CA9F5BCBDDA23929D85DBEC28414E859746F6D2E7269786F6D40746573742E636F6D0000004F4000003B010200331A0301002E533D42463341433543334533343636464443424237423439413744303337443741334338333441413836000000
*** This is a weird EAP-Message which is luckily ignored as SecureW2 only uses the
last read EAP-Message
but I checked and it is the previous EAP-Message sendt by FreeRadius which was a
response to my
EAP-Identity... ***
8:51:30:881::TLSParseApplicationDataRecord::Eap-Message(44):
0101002C1A0101002710CA9F5BCBDDA23929D85DBEC28414E859746F6D2E7269786F6D40746573742E636F6D
*** This is the EAP-Message from EAP-MSCHAPV2 we want ***
8:51:30:881::TLSParseApplicationDataRecord::Eap-Message(51):
010200331A0301002E533D42463341433543334533343636464443424237423439413744303337443741334338333441413836
The last message, as this is a screwy Length is ignored... but let me check the TLS
protocol to see
if the 00 00 00 bytes at the end mean anything.
Regards,
Tom Rixom.
> -----Original Message-----
> From: Alan DeKok [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 07, 2004 1:16 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EAP-TTLS-EAP-*
>
>
> "Tom Rixom" <[EMAIL PROTECTED]> wrote:
> > Thanks! Did you change the RLM_MODULE_HANDLED to PW_CHALLENGE in
> > rlm_eap_ttls.c?
>
> A little more than that, but pretty much.
>
> > Are you familiar with the TLS protocol?
>
> Unfortunately, yes.
>
> > Because as that did the trick for EAP-MD5, EAP-MSCHAPV2 still screws
> > up as FreeRadius sends me two EAP-messages in the TLS
> application data
> > followed by a corrupt message.
>
> I don't think I've tried EAP-MSCHAPV2 with TTLS.
>
> Try running the server with '-Xxx'. It will print out what data
> comes into, and out of, the TLS tunnel.
>
> > I will debug freeradius a bit more and tell you what I find out.
>
> Thanks.
>
> Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
