Does freeradius-client library support CHAP protocol?
Hi all, I was trying to figure out whether CHAP protocol is supported by freeradius-client library or not. I am reaching two contradictory conclusions using my own dubious analysis. Hence the request for help. If my understanding is correct, (and I might be totally wrong here), then the PAP protocol sends the user passwords in clear text over the wire. On the other hand, CHAP protocol uses a shared secret between the client and server to encrypt the passwords being sent over the wire. Since I do see the use of shared secret in freeradius-client library configuration file, I assume that the library does support CHAP. However, in the source code of the library, I notice that the section doing the CHAP processing is turned off using the #if 0 directive. Meaning CHAP is not being used. What gives? Also, after wading through the archives of this mailing list, I came across the post of one user who had asked exactly the same question, that is to say, whether CHAP is supported or not. The answer he got was that, "at this stage, better not use CHAP". This is an ambiguous reply as far as I am concerned because it evades a direct answer. Please reply Tarkshya
Tarkshya wrote:
If my understanding is correct, (and I might be totally wrong here), then the PAP protocol sends the user passwords in clear text over the wire.
No. The PAP protocol encrypts the password on the wire.
On the other hand, CHAP protocol uses a shared secret between the client and server to encrypt the passwords being sent over the wire.
No. The CHAP protocol sends a *hash* of thge password.
Since I do see the use of shared secret in freeradius-client library configuration file, I assume that the library does support CHAP.
No. The shared secret is used to sign RADIUS packets, and to encrypt the PAP password.
However, in the source code of the library, I notice that the section doing the CHAP processing is turned off using the #if 0 directive. Meaning CHAP is not being used.
What gives?
The code doesn't support CHAP. CHAP is nearly useless, and not recommended for new configurations.
Also, after wading through the archives of this mailing list, I came across the post of one user who had asked exactly the same question, that is to say, whether CHAP is supported or not. The answer he got was that, "at this stage, better not use CHAP". This is an ambiguous reply as far as I am concerned because it evades a direct answer.
What do you not understand about "better not use CHAP"? It's a fine answer. If you want a *detailed* explanation as to why, please ensure that you understand how the basic protocol works, first. There's no point in giving a technical explanation if you're unfamiliar with the background information. Don't use CHAP. It's useless. You can believe that, or you can spend days (weeks) reading about the protocol, the encryption methods, and the common use cases. After all that effort, you will conclude that CHAP is nearly useless. Alan DeKok
If you want a *detailed* explanation as to why, please ensure that you understand how the basic protocol works, first. There's no point in giving a technical explanation if you're unfamiliar with the background information.
Don't use CHAP. It's useless.
You can believe that, or you can spend days (weeks) reading about the protocol, the encryption methods, and the common use cases. After all that effort, you will conclude that CHAP is nearly useless.
Alan DeKok
OK. I believe you, and just accept that CHAP is useless. Since you have clarified that my dubious analysis of the protocols was indeed all wrong, can you at least point me to some good links on the web that explains the difference between these two protocols in the context of radius authentication. If you have time, that is. Best Tarkshya
Tarkshya wrote:
Since you have clarified that my dubious analysis of the protocols was indeed all wrong, can you at least point me to some good links on the web that explains the difference between these two protocols in the context of radius authentication.
If you have time, that is.
There's no need for sarcasm from someone who couldn't be bothered reading the original specifications. (Or even finding them.) Read RFC 2865, and the documents it references. Everything is explained there. The documents are even included in the FreeRADIUS distribution, *and* on freeradius.org/rfc/ as HTML versions, with cross-links. Alan DeKok.
Hi, I disagree that CHAP is without use. In fact, it could even be one of the most used protocols, at least for hotspot (captive portal) authentication, second to only PAP. I think you want to pick your protocol carefully, depending on the application and other requirements. PAP, for instance, is a bad choice if your shared secret isn't all that secret (like with FON, for instance). In all, I think each protocol has it's place and use. In some situations, protocols might be useless or unavailable. But, in another networks and environments, the same protocol might be very suitable or the only option available. cheers, David On Tue, 2009-03-17 at 19:46 +0100, Alan DeKok wrote:
Tarkshya wrote:
If my understanding is correct, (and I might be totally wrong here), then the PAP protocol sends the user passwords in clear text over the wire.
No. The PAP protocol encrypts the password on the wire.
On the other hand, CHAP protocol uses a shared secret between the client and server to encrypt the passwords being sent over the wire.
No. The CHAP protocol sends a *hash* of thge password.
Since I do see the use of shared secret in freeradius-client library configuration file, I assume that the library does support CHAP.
No. The shared secret is used to sign RADIUS packets, and to encrypt the PAP password.
However, in the source code of the library, I notice that the section doing the CHAP processing is turned off using the #if 0 directive. Meaning CHAP is not being used.
What gives?
The code doesn't support CHAP. CHAP is nearly useless, and not recommended for new configurations.
Also, after wading through the archives of this mailing list, I came across the post of one user who had asked exactly the same question, that is to say, whether CHAP is supported or not. The answer he got was that, "at this stage, better not use CHAP". This is an ambiguous reply as far as I am concerned because it evades a direct answer.
What do you not understand about "better not use CHAP"? It's a fine answer.
If you want a *detailed* explanation as to why, please ensure that you understand how the basic protocol works, first. There's no point in giving a technical explanation if you're unfamiliar with the background information.
Don't use CHAP. It's useless.
You can believe that, or you can spend days (weeks) reading about the protocol, the encryption methods, and the common use cases. After all that effort, you will conclude that CHAP is nearly useless.
Alan DeKok - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
wlanmac wrote:
I disagree that CHAP is without use. In fact, it could even be one of the most used protocols, at least for hotspot (captive portal) authentication, second to only PAP.
It is one of the most used protocols after PAP, especially for hotspot logins. That doesn't make it a good idea. Most captive portals use CHAP because they were designed a long time ago, and CHAP was more widely used then.
I think you want to pick your protocol carefully, depending on the application and other requirements. PAP, for instance, is a bad choice if your shared secret isn't all that secret (like with FON, for instance).
Yes. But that doesn't mean CHAP is the best choice. I've seen switches that do CHAP for wired "captive portals". This is *crazy*, because most companies that can afford $5K for a switch use Active Directory... which is incompatible with CHAP.
In all, I think each protocol has it's place and use. In some situations, protocols might be useless or unavailable. But, in another networks and environments, the same protocol might be very suitable or the only option available.
There are very, very, few places where CHAP is suitable. They mostly are situations like "I want to use CHAP, because I want to use CHAP." Alan DeKok.
It might be good timing then, for CoovaChilli to start expanding beyond PAP and CHAP. To that end, I added some MS-CHAPv2 features into the SVN version. Support for MS-CHAPv2 comes in two flavors: - In the chilli logon URL, it already looks for a 'password' (encoded p/w for PAP) or a 'response' (for CHAP), and now accepts 'ntresponse' (for MS-CHAPv2). This will allow the portal to format a MS-CHAPv2 Response to have chilli send through. - An option 'mschapv2' which will use MS-CHAPv2 instead of PAP for authentication where the logon URL is sent a 'password'. For the additional crypto, started to use OpenSSL (optional during configure) - which might allow for additional features too. Question, comments, or bug reports please reply to chilli's list. cheers, On Wed, 2009-03-18 at 08:12 +0100, Alan DeKok wrote:
wlanmac wrote:
I disagree that CHAP is without use. In fact, it could even be one of the most used protocols, at least for hotspot (captive portal) authentication, second to only PAP.
It is one of the most used protocols after PAP, especially for hotspot logins. That doesn't make it a good idea.
Most captive portals use CHAP because they were designed a long time ago, and CHAP was more widely used then.
I think you want to pick your protocol carefully, depending on the application and other requirements. PAP, for instance, is a bad choice if your shared secret isn't all that secret (like with FON, for instance).
Yes. But that doesn't mean CHAP is the best choice.
I've seen switches that do CHAP for wired "captive portals". This is *crazy*, because most companies that can afford $5K for a switch use Active Directory... which is incompatible with CHAP.
In all, I think each protocol has it's place and use. In some situations, protocols might be useless or unavailable. But, in another networks and environments, the same protocol might be very suitable or the only option available.
There are very, very, few places where CHAP is suitable. They mostly are situations like "I want to use CHAP, because I want to use CHAP."
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi all, I am going to build CHAP support in the freeradius client library. My question is, does freeradius server at least support CHAP? Or do I have to find another radius server to deploy it in CHAP mode? Does anybody know any other radius servers that support CHAP, and possibly MS-CHAP too. Tarkshya On Wed, Mar 18, 2009 at 12:43 PM, wlanmac <wlan@mac.com> wrote:
It might be good timing then, for CoovaChilli to start expanding beyond PAP and CHAP. To that end, I added some MS-CHAPv2 features into the SVN version. Support for MS-CHAPv2 comes in two flavors:
- In the chilli logon URL, it already looks for a 'password' (encoded p/w for PAP) or a 'response' (for CHAP), and now accepts 'ntresponse' (for MS-CHAPv2). This will allow the portal to format a MS-CHAPv2 Response to have chilli send through.
- An option 'mschapv2' which will use MS-CHAPv2 instead of PAP for authentication where the logon URL is sent a 'password'. For the additional crypto, started to use OpenSSL (optional during configure) - which might allow for additional features too.
Question, comments, or bug reports please reply to chilli's list.
cheers,
On Wed, 2009-03-18 at 08:12 +0100, Alan DeKok wrote:
wlanmac wrote:
I disagree that CHAP is without use. In fact, it could even be one of the most used protocols, at least for hotspot (captive portal) authentication, second to only PAP.
It is one of the most used protocols after PAP, especially for hotspot logins. That doesn't make it a good idea.
Most captive portals use CHAP because they were designed a long time ago, and CHAP was more widely used then.
I think you want to pick your protocol carefully, depending on the application and other requirements. PAP, for instance, is a bad choice if your shared secret isn't all that secret (like with FON, for instance).
Yes. But that doesn't mean CHAP is the best choice.
I've seen switches that do CHAP for wired "captive portals". This is *crazy*, because most companies that can afford $5K for a switch use Active Directory... which is incompatible with CHAP.
In all, I think each protocol has it's place and use. In some situations, protocols might be useless or unavailable. But, in another networks and environments, the same protocol might be very suitable or the only option available.
There are very, very, few places where CHAP is suitable. They mostly are situations like "I want to use CHAP, because I want to use CHAP."
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Tarkshya wrote:
I am going to build CHAP support in the freeradius client library. My question is, does freeradius server at least support CHAP?
Yes.
Does anybody know any other radius servers that support CHAP, and possibly MS-CHAP too.
I'd be surprised if any RADIUS server *doesn't* support CHAP and MS-CHAP. Alan DeKok.
Hello all, I tried to enable CHAP protocol support in the freeradius-client library by uncommenting the CHAP code in sendserver.c file. (It is the code which was blocked using #if 0 macro) However, when I send a chap password, the server rejects the request saying that Found Auth-Type = CHAP +- entering group CHAP {...} [chap] rlm_chap: password supplied has wrong length What could be wrong here? Also, apparently the radclient testing tools which comes with freeradius SERVER can successfully authenticate using CHAP passwords. Its only the client tool (radiusclient) that gives problem. I noticed that the logic of encoding CHAP passwords is different in freeradius client and free radius server code. Can somebody give me the exact algorithm for encoding and sending CHAP passwords in radius packets. Regards Tarkshya On Thu, Apr 2, 2009 at 5:17 AM, Alan DeKok <aland@deployingradius.com> wrote:
Tarkshya wrote:
I am going to build CHAP support in the freeradius client library. My question is, does freeradius server at least support CHAP?
Yes.
Does anybody know any other radius servers that support CHAP, and possibly MS-CHAP too.
I'd be surprised if any RADIUS server *doesn't* support CHAP and MS-CHAP.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Tarkshya wrote:
I tried to enable CHAP protocol support in the freeradius-client library by uncommenting the CHAP code in sendserver.c file. (It is the code which was blocked using #if 0 macro) However, when I send a chap password, the server rejects the request saying that
Found Auth-Type = CHAP +- entering group CHAP {...} [chap] rlm_chap: password supplied has wrong length
What could be wrong here?
What part of that message is unclear?
Also, apparently the radclient testing tools which comes with freeradius SERVER can successfully authenticate using CHAP passwords. Its only the client tool (radiusclient) that gives problem. I noticed that the logic of encoding CHAP passwords is different in freeradius client and free radius server code.
Well... that would seem to be the problem.
Can somebody give me the exact algorithm for encoding and sending CHAP passwords in radius packets.
You could read the FreeRADIUS server source code to see what works. The code *is* publicly available. Or, you could read the specification (RFC 2865). That's publicly available, too. Alan DeKok.
participants (3)
-
Alan DeKok -
Tarkshya -
wlanmac