[ previous ] [ next ] [ threads ]
 
 From:  Peter Curran <peter at closeconsultants dot com>
 To:  Dinesh Nair <dinesh at alphaque dot com>, m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Re: Captive Portal/Radius
 Date:  Sat, 29 May 2004 11:47:22 +0100
Dinesh

Thanks for your info.  It made me go and read (re-read) the documentation etc. 
and appreciate that the problem I was having is a side-effect of my test 
environment.  Pretty obvious really, but if you store passwords in plaintext 
in the database then you need to compare with plaintext (duh!).

On the CHAP issue.  I am certainly not advocating this for use, merely 
observing that many existing radius sites use CHAP and that it might be an 
attractive feature.

On this PAP vs CHAP question I would observe that it is widespread lore that:
PAP == BAD (password sent across network)
CHAP == GOOD (password not sent across network) 

As you have explained the PAP password is protected by a reasonable scheme, 
whereas the CHAP system requires storing plaintext passwords.  However, the 
MS-CHAPv2 scheme tries to offer the best of both worlds by using CHAP and a 
password stored as a hash.  I am not advocating support for MS-CHAP.

Peter

On Saturday 29 May 2004 07:46, Dinesh Nair wrote:
> On Fri, 28 May 2004 14:49:36 +0100, Peter Curran wrote:
> > server (in my case in an SQL database).  FreeRADIUS offers a variety of
> > storage mechanisms (such as the classic UNIX crypt-style, MD5, etc).  I
>
> i used freeradius as well for the testing/development of the captive
> portal RADIUS auth, and the authentication on the RADIUS server was done
> using crypt against the /etc/passwd on the server itself. you do not need
> to be restricted to using clear text, as this is a config option on
> freeradius, not on the m0n0wall.  see snippet from my radiusd.conf below:
>
>         # PAP module to authenticate users based on their stored password
>         #
>         #  Supports multiple encryption schemes
>         #  clear: Clear text
>         #  crypt: Unix crypt
>         #    md5: MD5 ecnryption
>         #   sha1: SHA1 encryption.
>         #  DEFAULT: crypt
>         pap {
>                 encryption_scheme = crypt
>         }
>
> > would like to see an option to specify that the passwords should be
> > hashed with md5 or similar before transmission.
>
> the RADIUS protocol requires that passwords are encrypted with a simple
> XOR of the user entered password together with a md5 hash of the shared
> secret key concatenated with a unique Request Authenticator which is
> randomly generated. thus, user passwords are not transmitted in the clear
> over the network between the m0n0wall and the RADIUS server.
>
> RFC2138 calls the protocol to hide the user password, "a method based on
> the RSA Message Digest Algorithm MD5"
>
> > Likewise, many people like to use CHAP, so perhaps a CHAP option will be
> > good as well.
>
> from RFC2138:
>
> "For example, CHAP requires that the user's password be available in
> cleartext to the server so that it can encrypt the CHAP challenge and
> compare that to the CHAP response.  If the password is not available in
> cleartext to the RADIUS server then the server MUST send an Access-Reject
> to the client."
>
> thus using CHAP would bring up the very issue you're concerned about,
> storing cleartext passwords on the server, hence the usage of PAP in most
> implementations of RADIUS. i wouldnt recommend using CHAP either.
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.