Re[3]: Fwd: Re: Encrypted attribute problems
Dear 3APA3A, (Cc'd to the mailing list for the archives) I confirm that these patches work correctly: freeradius now authenticates MSCHAP-v2 against the rlm_mschap module and as a proxy server against a remote RADIUS server (IAS in my case). Many thanks for your assistance and rapid support in this matter, josh. On Mon, 27 May 2002, 3APA3A wrote: > Dear Josh Howlett, > > Replace dictionary.microsoft in _both_ RADIUS source and installation > (normally /usr/local/etc/raddb) dir, it should help (make sure you have > latest CVS snapshot, older FreeRADIUS incorrectly handles tunnel > encryption). It should be already enough to solve your problem (no > recompilation/reinstallation required) but it will break FreeRADIUS own > MS-CHAPv2 functionality. > > So, I will be very grateful to you if you can also replace rlm_mschap > with one attached, rebuild RADIUS and to test MS-CHAPv2 functionality > via FreeRADIUS itself, because I have no MS-CHAPv2 compliant NAS to > test. > > --Monday, May 27, 2002, 9:01:26 PM, you wrote to [EMAIL PROTECTED]: > > JH> Dear 3APA3A, > > JH> I would be very pleased to test it! > > JH> Many thanks, josh. > > JH> On Mon, 27 May 2002, 3APA3A wrote: > > >> Dear Josh Howlett, > >> > >> As you can see it was forward to [EMAIL PROTECTED], this > >> message was not addressed to you, but to core RADIUS developers. > >> > >> If I'll send you fixed source files can you test it? > >> > >> --Monday, May 27, 2002, 8:53:29 PM, you wrote to >[EMAIL PROTECTED]: > >> > >> JH> On Mon, 27 May 2002, 3APA3A wrote: > >> >> > >> >> Probably the problem is that MS uses for > >> >> MS-MPPE-Send-Key/MS-MPPE-Recv-Key absolutely same encoding schema as for > >> >> Tunnel-Password attributes. Currently I do all encoding inside > >> >> rlm_mschap itself. > >> >> > >> >> I'm not sure how does proxy operates: if proxy rebuilds packet and these > >> >> values are changed I need to rewrite rlm_mschap to not perform encoding > >> >> and to mark MS-MPPE-Send-Key/MS-MPPE-Recv-Key as encrypt=2 in the > >> >> dictionary instead. > >> >> > >> >> Will it work? > >> >> > >> >> BTW: for MS-CHAPv1 Microsoft uses standard rad_pwencode() to encrypt > >> >> MS-CHAP-MPPE-Keys attribute. Currently I call rad_pwencode() from > >> >> rlm_mschap. May be we should process all rad_pwencode'd attributes in > >> >> the way we process Tunnel-Password encryption? That is instead of > >> >> calling rad_pwencode/rad_pwdecode for Password we should mark Password > >> >> and MS-CHAP-MPPE-Keys as encrypt=1 in the dictionary and handle all > >> >> encrypted attributes? > >> > >> JH> Hi 3APA3A, > >> > >> JH> I am not using rlm_mschap at all because I am only proxying. I assumed > >> JH> that the encoding/decoding would be performed automatically as part of > >> JH> the proxying process. > >> > >> JH> What you suggest sounds sensible to me, but I do not know much at all > >> JH> about RADIUS :-(. > >> > >> JH> regards, josh. > >> > >> >> --This is a forwarded message > >> >> From: Josh Howlett <[EMAIL PROTECTED]> > >> >> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > >> >> Date: Monday, May 27, 2002, 7:28:36 PM > >> >> Subject: Encrypted attribute problems > >> >> > >> >> ===8<==Original message text=== > >> >> > Josh Howlett <[EMAIL PROTECTED]> wrote: > >> >> > > What is the status of encrypted attribute support in Freeradius at the > >> >> > > moment? It appears to be broken - has anyone had similar problems? > >> >> > > >> >> > WHICH encrypted attribute? There's more than one, and there are a > >> >> > number of different encryption schemes. > >> >> > >> >> Sorry for the lack of specificity; I am rather new to RADIUS! > >> >> > >> >> My precise problem is this. I have a Microsoft IAS W2K server and a NAS > >> >> with a Freeradius proxy in the middle: > >> >> > >> >> IAS <--> Freeradius <--> NAS > >> >> > >> >> The NAS authenticates clients using MSCHAP-v2 and also provides > >> >> encryption using MPPE. The NAS can authenticate and retrieve the MPPE > >> >> keys via RADIUS from the W2K box without any problems. However, if the > >> >> RADIUS transaction is performed via the Freeradius proxy, the NAS > >> >> reports problems with de-crypting the MPPE attributes: > >> >> > >> >> decrypt_attr_style_1: bogus decrypted length 89 > >> >> decrypt_attr_style_1: bogus decrypted length -37 > >> >> > >> >> Hence, I can authenticate correctly but not retrieve the MPPE keys when > >> >> Freeradius is acting as proxy. > >> >> > >> >> I hope this is clear? > >> >> > >> >> thanks, josh. > >> >> > >> >> > >> >> > >> >> Josh Howlett, Networking & Digital Communications, > >> >> Information Systems & Computing, University of Bristol, U.K. > >> >> 'phone: 0117 928 7850 email: [EMAIL PROTECTED] > >> >>
Re: Fwd: Re: Encrypted attribute problems
3APA3A <[EMAIL PROTECTED]> wrote: > BTW: for MS-CHAPv1 Microsoft uses standard rad_pwencode() to encrypt > MS-CHAP-MPPE-Keys attribute. Currently I call rad_pwencode() from > rlm_mschap. May be we should process all rad_pwencode'd attributes in > the way we process Tunnel-Password encryption? That is instead of > calling rad_pwencode/rad_pwdecode for Password we should mark Password > and MS-CHAP-MPPE-Keys as encrypt=1 in the dictionary and handle all > encrypted attributes? Yes, with one condition. Attributes received FROM a home server (proxy reply) should be marked as "already encrypted". When the server handles them, it should either leave them alone when sending, OR it should decrypt them as it receives them, and encrypt them before sending them out. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Fwd: Re: Encrypted attribute problems
On Mon, 27 May 2002, 3APA3A wrote: > > Probably the problem is that MS uses for > MS-MPPE-Send-Key/MS-MPPE-Recv-Key absolutely same encoding schema as for > Tunnel-Password attributes. Currently I do all encoding inside > rlm_mschap itself. > > I'm not sure how does proxy operates: if proxy rebuilds packet and these > values are changed I need to rewrite rlm_mschap to not perform encoding > and to mark MS-MPPE-Send-Key/MS-MPPE-Recv-Key as encrypt=2 in the > dictionary instead. > > Will it work? > > BTW: for MS-CHAPv1 Microsoft uses standard rad_pwencode() to encrypt > MS-CHAP-MPPE-Keys attribute. Currently I call rad_pwencode() from > rlm_mschap. May be we should process all rad_pwencode'd attributes in > the way we process Tunnel-Password encryption? That is instead of > calling rad_pwencode/rad_pwdecode for Password we should mark Password > and MS-CHAP-MPPE-Keys as encrypt=1 in the dictionary and handle all > encrypted attributes? Hi 3APA3A, I am not using rlm_mschap at all because I am only proxying. I assumed that the encoding/decoding would be performed automatically as part of the proxying process. What you suggest sounds sensible to me, but I do not know much at all about RADIUS :-(. regards, josh. > --This is a forwarded message > From: Josh Howlett <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Date: Monday, May 27, 2002, 7:28:36 PM > Subject: Encrypted attribute problems > > ===8<==Original message text=== > > Josh Howlett <[EMAIL PROTECTED]> wrote: > > > What is the status of encrypted attribute support in Freeradius at the > > > moment? It appears to be broken - has anyone had similar problems? > > > > WHICH encrypted attribute? There's more than one, and there are a > > number of different encryption schemes. > > Sorry for the lack of specificity; I am rather new to RADIUS! > > My precise problem is this. I have a Microsoft IAS W2K server and a NAS > with a Freeradius proxy in the middle: > > IAS <--> Freeradius <--> NAS > > The NAS authenticates clients using MSCHAP-v2 and also provides > encryption using MPPE. The NAS can authenticate and retrieve the MPPE > keys via RADIUS from the W2K box without any problems. However, if the > RADIUS transaction is performed via the Freeradius proxy, the NAS > reports problems with de-crypting the MPPE attributes: > > decrypt_attr_style_1: bogus decrypted length 89 > decrypt_attr_style_1: bogus decrypted length -37 > > Hence, I can authenticate correctly but not retrieve the MPPE keys when > Freeradius is acting as proxy. > > I hope this is clear? > > thanks, josh. > > > > Josh Howlett, Networking & Digital Communications, > Information Systems & Computing, University of Bristol, U.K. > 'phone: 0117 928 7850 email: [EMAIL PROTECTED] > > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > ===8<===End of original message text=== > > > -- > ~/ZARAZA > B p`qwer`u a{k` nxhaj`. (Kel) > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Fwd: Re: Encrypted attribute problems
Probably the problem is that MS uses for MS-MPPE-Send-Key/MS-MPPE-Recv-Key absolutely same encoding schema as for Tunnel-Password attributes. Currently I do all encoding inside rlm_mschap itself. I'm not sure how does proxy operates: if proxy rebuilds packet and these values are changed I need to rewrite rlm_mschap to not perform encoding and to mark MS-MPPE-Send-Key/MS-MPPE-Recv-Key as encrypt=2 in the dictionary instead. Will it work? BTW: for MS-CHAPv1 Microsoft uses standard rad_pwencode() to encrypt MS-CHAP-MPPE-Keys attribute. Currently I call rad_pwencode() from rlm_mschap. May be we should process all rad_pwencode'd attributes in the way we process Tunnel-Password encryption? That is instead of calling rad_pwencode/rad_pwdecode for Password we should mark Password and MS-CHAP-MPPE-Keys as encrypt=1 in the dictionary and handle all encrypted attributes? --This is a forwarded message From: Josh Howlett <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Monday, May 27, 2002, 7:28:36 PM Subject: Encrypted attribute problems ===8<==Original message text=== > Josh Howlett <[EMAIL PROTECTED]> wrote: > > What is the status of encrypted attribute support in Freeradius at the > > moment? It appears to be broken - has anyone had similar problems? > > WHICH encrypted attribute? There's more than one, and there are a > number of different encryption schemes. Sorry for the lack of specificity; I am rather new to RADIUS! My precise problem is this. I have a Microsoft IAS W2K server and a NAS with a Freeradius proxy in the middle: IAS <--> Freeradius <--> NAS The NAS authenticates clients using MSCHAP-v2 and also provides encryption using MPPE. The NAS can authenticate and retrieve the MPPE keys via RADIUS from the W2K box without any problems. However, if the RADIUS transaction is performed via the Freeradius proxy, the NAS reports problems with de-crypting the MPPE attributes: decrypt_attr_style_1: bogus decrypted length 89 decrypt_attr_style_1: bogus decrypted length -37 Hence, I can authenticate correctly but not retrieve the MPPE keys when Freeradius is acting as proxy. I hope this is clear? thanks, josh. Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ===8<===End of original message text=== -- ~/ZARAZA  ðàñ÷åòàõ áûëà îøèáêà. (Ëåì) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html