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]
-
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
JH
JH Josh Howlett, Networking Digital
Encrypted attribute problems
Hi, What is the status of encrypted attribute support in Freeradius at the moment? It appears to be broken - has anyone had similar problems? 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
Re: Encrypted attribute problems
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. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Encrypted attribute problems
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
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
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
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
