[ previous ] [ next ] [ threads ]
 From:  Dinesh Nair <dinesh at alphaque dot com>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Cc:  Peter Curran <peter at closeconsultants dot com>
 Subject:  Re: Captive Portal/Radius
 Date:  Sat, 29 May 2004 14:46:10 +0800 (MYT)
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.

> (2=success, 3=fail).  I am currently playing around with an idea to have
> the server send back a 'time' parameter that would establish the maximum
> time the user could be connected without logging-in again.  The would

this possibly could be done with RADIUS accounting packets being
sent/received between the m0n0wall and the RADIUS host. i'm currently
looking at extending the RADIUS functionality in m0n0wall to include this.
currently, setting the Hard Timeout parameter in m0n0wall will disconnect
the user and force a relogin.

> One unrelated question - where does the /usr/local/bin/verifysig code
> come from?

i believe manuel uses it to verify the signature of firmware uploads. the
public key is stored in /etc/pubkey.pem on the m0n0wall mfsroot image.

Regards,                           /\_/\   "All dogs go to heaven."
dinesh at alphaque dot com                (0 0)    http://www.alphaque.com/
| for a in past present future; do                                        |
|   for b in clients employers associates relatives neighbours pets; do   |
|   echo "The opinions here in no way reflect the opinions of my $a $b."  |
| done; done                                                              |