Alan, I checked and the AVP Diameter padding in the last MSCHAPV2 packet is incorrect.
It should be 1 but it is 3 see: Diamter packet: 0000004F -> EAP-Message 1 40000034 0101002C 1A010100 2710CA9F 5BCBDDA2 3929D85D BEC28414 E859746F 6D2E7269 786F6D40 74657374 2E636F6D -> no padding as it is exactly 4 bytes 0000004F -> EAP-Message 2 4000003B 01020033 1A030100 2E533D42 46334143 35433345 33343636 46444342 42374234 39413744 30333744 37413343 38333441 41383600 -> Padding of 1 to fill up to 4 bytes 0000 -> weird bytes As you can see if you split the Diameter message up into sequences of 4 bytes as specified by the RFC the last 2 00 00 are incorrect. Regards, Tom. > -----Original Message----- > From: Tom Rixom > Sent: Monday, March 08, 2004 11:16 AM > To: [EMAIL PROTECTED] > Subject: RE: EAP-TTLS-EAP-* > > > Ok, > > Completely forget all the stuff I just said about the extra 0's as > I am an idiot that forgot about the 4 octect boundary of > Diameter AVPs... > > Tom. > > > -----Original Message----- > > From: Tom Rixom > > Sent: Monday, March 08, 2004 9:26 AM > > To: [EMAIL PROTECTED] > > Subject: RE: EAP-TTLS-EAP-* > > > > > > Small ammendment on the e-mail, I mentioned the Length of > the AVP but > > I meant the AVP code, and it seems FreeRadius handles this correctly > > The AVP code should be 3 bytes and the AVP Flags is 1 byte. > > > > So the 00 00 00 bytes at the end is ok > > > > Regards, > > > > Tom. > > > > > -----Original Message----- > > > From: Tom Rixom > > > Sent: Monday, March 08, 2004 9:23 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: EAP-TTLS-EAP-* > > > > > > > > > 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 = > > > 0x00533d424633414335433345333436364644434242374234394137443033 > > > 37443741334338333441413836 > > > MS-MPPE-Recv-Key = 0x759a726e4985b73a7bd99c9b1e56d215 > > > MS-MPPE-Send-Key = 0x19c1e335bed2de6b215dbbeec4d175ec > > > MS-MPPE-Encryption-Policy = 0x00000001 > > > MS-MPPE-Encryption-Types = 0x00000006 > > > EAP-Message = > > > 0x010200331a0301002e533d42463341433543334533343636464443424237 > > > 423439413744303337443741334338333441413836 > > > 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 = > > > 0x010a00b41580000000aa1703010018d9ebc6a739379802c18e5769d95be6 > > > 399c152413ad8ce9171703010088982d2a091ef7d383e715114af75ec1cecc > > > 6aa03a45a5dbfc28c2e157e908d3fdd5b887c0b6f5daf618ac3b9b23fad8b3 > > > acf4c6e4cf06911bace0aab5cd3dd75327b73cb0abd286aa97cf54c04174f9 > > > 326ffb6268c3dcbf0ec4c3b1c86899a42ff58f104ba34138ef0e727c6859a7 > > > 59cb02e1a944f7e2892c5b454143a742975e6a35e6f2eabb0182 > > > 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 = > > > 0x010200331a0301002e533d42463341433543334533343636464443424237 > > > 423439413744303337443741334338333441413836 > > > > > > 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: > > > 8d9ebc6a739379802c18e5769d95be6399c152413ad8ce9171703010088982 > > > d2a091ef7d383e715114af75ec1cecc6aa03a45a5dbfc28c2e157e908d3fdd > > > 5b887c0b6f5daf618ac3b9b23fad8b3acf4c6e4cf06911bace0aab5cd3dd75 > > > 327b73cb0abd286aa97cf54c04174f9326ffb6268c3dcbf0ec4c3b1c86899a > > > 42ff58f104ba34138ef0e727c6859a759cb02e1a944f7e2892c5b454143a74 > > > 2975e6a35e6f2eabb0182 > > > > > > And this is the EAP-Message: > > > > > > EAP-Message: > > > 0x010a00b41580000000aa1703010018d9ebc6a739379802c18e5769d95be6 > > > 399c152413ad8ce9171703010088982d2a091ef7d383e715114af75ec1cecc > > > 6aa03a45a5dbfc28c2e157e908d3fdd5b887c0b6f5daf618ac3b9b23fad8b3 > > > acf4c6e4cf06911bace0aab5cd3dd75327b73cb0abd286aa97cf54c04174f9 > > > 326ffb6268c3dcbf0ec4c3b1c86899a42ff58f104ba34138ef0e727c6859a7 > > > 59cb02e1a944f7e2892c5b454143a742975e6a35e6f2eabb0182 > > > > > > What I receive on the other end is the following: > > > > > > The EAP-Message :) > > > 0x010a00b41580000000aa1703010018d9ebc6a739379802c18e5769d95be6 > > > 399c152413ad8ce9171703010088982d2a091ef7d383e715114af75ec1cecc > > > 6aa03a45a5dbfc28c2e157e908d3fdd5b887c0b6f5daf618ac3b9b23fad8b3 > > > acf4c6e4cf06911bace0aab5cd3dd75327b73cb0abd286aa97cf54c04174f9 > > > 326ffb6268c3dcbf0ec4c3b1c86899a42ff58f104ba34138ef0e727c6859a7 > > > 59cb02e1a944f7e2892c5b454143a742975e6a35e6f2eabb0182 > > > > > > ------ This is logging from SecureW2 ---------- > > > 8:51:30:871::TLSDecBlock::pbEncBlock(136): > > > 982D2A091EF7D383E715114AF75EC1CECC6AA03A45A5DBFC28C2E157E908D3 > > > FDD5B887C0B6F5DAF618AC3B9B23FAD8B3ACF4C6E4CF06911BACE0AAB5CD3D > > > D75327B73CB0ABD286AA97CF54C04174F9326FFB6268C3DCBF0EC4C3B1C868 > > > 99A42FF58F104BA34138EF0E727C6859A759CB02E1A944F7E2892C5B454143 > > > A742975E6A35E6F2EABB0182 > > > > > > 8:51:30:871::TLSDecBlock::pbDecBlock(136): > > > 0000004F400000340101002C1A0101002710CA9F5BCBDDA23929D85DBEC284 > > > 14E859746F6D2E7269786F6D40746573742E636F6D0000004F4000003B0102 > > > 00331A0301002E533D42463341433543334533343636464443424237423439 > > > 4137443033374437413343383334414138360000005BE6A6D35924F1B695ED > > > 7D04A33B3472FB2D820A0101 > > > > > > 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): > > > 0000004F400000340101002C1A0101002710CA9F5BCBDDA23929D85DBEC284 > > > 14E859746F6D2E7269786F6D40746573742E636F6D0000004F4000003B0102 > > > 00331A0301002E533D42463341433543334533343636464443424237423439 > > > 413744303337443741334338333441413836000000 > > > > > > *** 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): > > > 0101002C1A0101002710CA9F5BCBDDA23929D85DBEC28414E859746F6D2E72 > > > 69786F6D40746573742E636F6D > > > > > > *** This is the EAP-Message from EAP-MSCHAPV2 we want *** > > > 8:51:30:881::TLSParseApplicationDataRecord::Eap-Message(51): > > > 010200331A0301002E533D4246334143354333453334363646444342423742 > > > 3439413744303337443741334338333441413836 > > > > > > 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 > > > > - > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
