What is CHAP-Challenge for?
I am looking into CHAP authentication, and I am having difficulties understanding what the CHAP-Challenge attribute is exactly for. Using the radclient utility that ships with freeradius-server 2.2.0 I can do the following: echo "User-Name = MyName, CHAP-Password = MyPassword, CHAP-Challenge = 0123456789" | ./radclient 192.168.0.2 auth SharedSecret Provided that the RADIUS server at 192.168.0.2 is alive and correctly configured (i.e. username, password and shared all match the values above) everything works fine, in that the CHAP authentication succeeds, as expected. However, if I do echo "User-Name = MyName, CHAP-Password = MyPassword" | ./radclient 192.168.0.2 auth SharedSecret this also succeeds. So, what's the use of the CHAP-Challenge attribute? RFC 2865 says that if its value is 16 bytes long then this value can be that of the Request Authenticator field, thus disposing of CHAP-Challenge altogether. What does therefore CHAP-Challenge do that is not already done by the Request Authenticator field? Are there any sets of circumstances in which using the CHAP-Challenge attribute is advisable? Actually, what's the point of using CHAP-Password at all, when User-Password seems to be at least as, if not more, secure a protocol?
On 2013-02-10, at 8:52 PM, JCA <1.41421@gmail.com> wrote:
I am looking into CHAP authentication, and I am having difficulties understanding what the CHAP-Challenge attribute is exactly for.
Read RFC 2865, section 5.3. It's all explained there.
So, what's the use of the CHAP-Challenge attribute? RFC 2865 says that if its value is 16 bytes long then this value can be that of the Request Authenticator field, thus disposing of CHAP-Challenge altogether.
Which is a bad idea. See RFC 6158 section B.2
What does therefore CHAP-Challenge do that is not already done by the Request Authenticator field?
It's not a hack.
Are there any sets of circumstances in which using the CHAP-Challenge attribute is advisable?
Always. The use of the request authentication is a holdover from 20 years ago, before RADIUS started getting peer review.
Actually, what's the point of using CHAP-Password at all, when User-Password seems to be at least as, if not more, secure a protocol?
Historical practice. Alan DeKok.
On Sun, Feb 10, 2013 at 7:22 PM, Alan DeKok <aland@deployingradius.com> wrote:
On 2013-02-10, at 8:52 PM, JCA <1.41421@gmail.com> wrote:
I am looking into CHAP authentication, and I am having difficulties understanding what the CHAP-Challenge attribute is exactly for.
Read RFC 2865, section 5.3. It's all explained there.
So, what's the use of the CHAP-Challenge attribute? RFC 2865 says that if its value is 16 bytes long then this value can be that of the Request Authenticator field, thus disposing of CHAP-Challenge altogether.
Which is a bad idea. See RFC 6158 section B.2
What does therefore CHAP-Challenge do that is not already done by the Request Authenticator field?
It's not a hack.
Are there any sets of circumstances in which using the CHAP-Challenge attribute is advisable?
Always. The use of the request authentication is a holdover from 20 years ago, before RADIUS started getting peer review.
Actually, what's the point of using CHAP-Password at all, when User-Password seems to be at least as, if not more, secure a protocol?
Historical practice.
Thanks for you clarifications. Now I have noticed that the way in which freeradius-server 2.2.0 encrypts CHAP passwords before casting them to wire format is totally different from its counterpart in freeradius-client 1.1.6. The way in which 2.2.0 does it clearly agrees with the description given in section 2.2 of RFC 2865, whereas the approach followed in 1.1.6 is completely different and, therefore, wrong - which is perhaps why it is not compiled in by default. Would you know why that code in 1.1.6 is there at all?
JCA wrote:
Thanks for you clarifications. Now I have noticed that the way in which freeradius-server 2.2.0 encrypts CHAP passwords before casting them to wire format is totally different from its counterpart in freeradius-client 1.1.6. The way in which 2.2.0 does it clearly agrees with the description given in section 2.2 of RFC 2865, whereas the approach followed in 1.1.6 is completely different and, therefore, wrong - which is perhaps why it is not compiled in by default. Would you know why that code in 1.1.6 is there at all?
No idea. That code is left over from probably 8 years ago. Alan DeKok.
participants (2)
-
Alan DeKok -
JCA