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?