Radius authentication passphrase length

billm · May 17, 2006, 7:59 PM

radius_authentication.inc: unmodified: line 120 of 129. That file exists in /usr/local/captiveportal

–Bill

buraglio · May 17, 2006, 8:03 PM

@billm:

radius_authentication.inc: unmodified: line 120 of 129. That file exists in /usr/local/captiveportal

–Bill

I've been looking at this too long. Mine is a little different (I'm running BETA2) but it was right there.

billm · May 17, 2006, 8:41 PM

@buraglio:

@billm:

radius_authentication.inc: unmodified: line 120 of 129. That file exists in /usr/local/captiveportal

–Bill

I've been looking at this too long. Mine is a little different (I'm running BETA2) but it was right there.

This is just a wild ass guess, but try changing that line from:
for ($i=0;$i<=15;$i++) {
to:
for ($i=0;$i<=strlen($md5checksum)/2; $i++) {

**edit:**nm, this won't do anything
–Bill

billm · May 17, 2006, 8:24 PM

A quick test of md5() shows that it outputs 32 hex characters.

bash-2.05b$ php t.php
abeac07d3c28c1bef9e730002c753ed4
2c9728a2138b2f25e9f89f99bdccf8db
bash-2.05b$ cat t.php
echo md5('1234567890123456') . "\n";
echo md5('12345678901234567') . "\n";
?>

And it doesn't seem to care whether you enter 16 or 17 characters, it really does calculate the hash based on ALL of what's input.

That Encrypt() function is screwed though…
if ($i>strlen($keyRA)) $k=0; else $k=ord(substr($keyRA,$i,1));
does nothing...heh...barf

--Bill

buraglio · May 17, 2006, 8:46 PM

Cool, that jives with what I'm seeing. Messing around with that number grabs more of the input but only the first 15 characters are encrypted. With that change it appears to cut off at 17 characters for the password.

billm · May 17, 2006, 9:22 PM

OK, here's my comments on the Encrypt() function


        // Loop 16 times (md5() output / 2)
        // This limits the effective password to 16 characters - is this really in the radius spec???
        for ($i=0;$i<=15;$i++) {
            // Convert md5 hex output to decimal
            if (2*$i>strlen($md5checksum)) $m=0; else $m=hexdec(substr($md5checksum,2*$i,2));
            // Do nothing????
            if ($i>strlen($keyRA)) $k=0; else $k=ord(substr($keyRA,$i,1));
            // get the decimal character value for this character in the password
            if ($i>strlen($password)) $p=0; else $p=ord(substr($password,$i,1));
            // xor the md5 character with the password character
            $c=$m^$p;
            // Convert back to 8-bit output
            $output.=chr($c);
        }

In reading the PECL code, I think what it's doing is XORing only the first 16 chars and leaving the rest alone

for (i = 0; i < 16; i++)
h->request[h->pass_pos + pos + i] =
md5 _^= h->pass[pos + i];

Gut feel is that this also is wrong, but try adding:
$outstr = substr_replace($password, $output, 0);
right before the return in Encrypt() and return $outstr instead of $output

The answer is in the PECL code I'm sure, I just don't have the time to do all the research on this one.

–Bill_

buraglio · May 17, 2006, 9:43 PM

In reading the RFC (http://www.faqs.org/rfcs/rfc2865.html Section 5.2), it sounds like it's skipping the second step to me:

If the password is longer than 16 characters, a second one-way MD5
hash is calculated over a stream of octets consisting of the
shared secret followed by the result of the first xor. That hash
is XORed with the second 16 octet segment of the password and
placed in the second 16 octets of the String field of the User-
Password Attribute.

If necessary, this operation is repeated, with each xor result
being used along with the shared secret to generate the next hash
to xor the next segment of the password, to no more than 128
characters.

This isn't really my core competency so I may be wrong.

sullrich · May 17, 2006, 9:58 PM

@buraglio:

In reading the RFC (http://www.faqs.org/rfcs/rfc2865.html Section 5.2), it sounds like it's skipping the second step to me:

If the password is longer than 16 characters, a second one-way MD5
hash is calculated over a stream of octets consisting of the
shared secret followed by the result of the first xor. That hash
is XORed with the second 16 octet segment of the password and
placed in the second 16 octets of the String field of the User-
Password Attribute.

If necessary, this operation is repeated, with each xor result
being used along with the shared secret to generate the next hash
to xor the next segment of the password, to no more than 128
characters.

This isn't really my core competency so I may be wrong.

Heh. We'll definately want to get these fixes back to m0n0wall once this is settled.

buraglio · May 17, 2006, 10:04 PM

I'm going to do more reading on it. Do you believe that the asumption that it is skipping the second step (as referenced above) is correct?

sullrich · May 17, 2006, 10:05 PM

@buraglio:

I'm going to do more reading on it. Do you believe that the asumption that it is skipping the second step (as referenced above) is correct?

Yep.

billm · May 17, 2006, 10:46 PM

OK, I have something for you to test - it's not complete, but it'll allow you (hopefully) to test passwords up to 32 chars. If it works, I'll clean it up a bit and make it support the full 128 chars we should.

http://www.pfsense.org/~billm/radius_auth.diff

–Bill

buraglio · May 17, 2006, 11:06 PM

Excellent, I'll patch and have some results for you by early tomorrow.

nb

billm · May 17, 2006, 11:11 PM

Just updated the patch - should work up to 128 chars now. I'll run some quick tests through it myself.

–Bill

buraglio · May 18, 2006, 3:27 PM

What version are you patching this against? I'm running BETA2 (BETA4 has issues booting on my dell 2850's) and had some errors with redirection after applying the patch. I updated to the /usr/local/captiveportal in CVS (as well as added the authLDAP.inc that it requires) but still have some errors. I'd like to mirror what you have been testing on if possible to rule out any version issues.

billm · May 18, 2006, 3:33 PM

@buraglio:

What version are you patching this against? I'm running BETA2 (BETA4 has issues booting on my dell 2850's) and had some errors with redirection after applying the patch. I updated to the /usr/local/captiveportal in CVS (as well as added the authLDAP.inc that it requires) but still have some errors. I'd like to mirror what you have been testing on if possible to rule out any version issues.

I don't have the box in front of my now that I'm at work, but it should apply cleanly against revision 1.12.2.1 of radius_authentication.inc:
http://pfsense.com/cgi-bin/cvsweb.cgi/pfSense/usr/local/captiveportal/radius_authentication.inc?rev=1.12.2.1;content-type=text%2Fplain

Here's the patched Encrypt() function (all I changed)


/*
 * $password = users password
 * $key = shared secret
 * $RA = Request Authenticator (random value it seems like)
 */
function Encrypt($password,$key,$RA) {
        global $debug;

        if ($debug)
            echo "
key: $key
password: $password

* * *

\n";

        $output="";
        $passlen = strlen($password);
        /* figure out the number of xor rounds we need to run through */
        for ($i=16; $i <= 128; $i += 16) {
                if ($len <= $i) {
                        $rounds = $i/16;
                        break;
                }
        }

        $z = 0; // How many chars have we xor'd
        for ($x=1; $x<=$rounds; $x++) {
                $keyRA=$key.$RA;
                $md5checksum=md5($keyRA);

                // Loop 16 times (md5() output / 2)
                // This limits the effective password to 16 characters - is this really in the radius spec???
                for ($i=0;$i<=15;$i++) {
                        // Convert md5 hex output to decimal (md5 lengths are 32 chars)
                        if (2*$i>32) $m=0; else $m=hexdec(substr($md5checksum,2*$i,2));
                        // get the decimal character value for this character in the password
                        if ($z>$passlen-1) $p=0; else $p=ord(substr($password,$z,1));
                        // xor the md5 character with the password character
                        $c=$m^$p;
                        // Convert back to 8-bit output
                        $output.=chr($c);
                        $z++;
                }
                $RA=$output;
        }

        return $output;
}

–Bill

buraglio · May 18, 2006, 4:40 PM

OK, I got it all cleaned up and patched it. It is yielding the same error from the debug info. From the debug output it looks liek it's grabbing 16 characters.

"username is blahblah with len 8 encryptedpassword is …........with len 16 ........"

billm · May 18, 2006, 5:29 PM

Any debug from the Encrypt() function? I tested it with 15-17 character passwords and it seemed to do the right thing there. I don't have a way to test against RADIUS, but the function looks good now :-/

–Bill

buraglio · May 18, 2006, 7:08 PM

No real debug info from the Encrypt() function. I can dig a little deeper. I can also give you access to the box if you'd like.

buraglio · May 18, 2006, 8:04 PM

So it does allow for shorter paswords but generates some errors:


radius-port: 1812
radius-host: 10.10.102.2
username: blahblah

key: TestRadiusKey
password: testpasswd
username is blahblah with len 8 encryptedpassword is šJ»[à6%¤2ÍÇƒhÄ with len 10 nasHostname is portal-a.lab.local with len 18 
writing 95 bytes

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/captiveportal/radius_authentication.inc:48) in /usr/local/captiveportal/index.php on line 335 
radius-port: 1813
radius-host: 10.10.2.25
username: blahblah

username is blahblah with len 8 nasHostname is portal-a.lab.local with len 18 
writing 113 bytes
[/code]

The errors on the RADIUS server for a >16 char passphrase are as i'd expect for an incorrect passphrase.

billm · May 18, 2006, 8:38 PM

@buraglio:

No real debug info from the Encrypt() function. I can dig a little deeper. I can also give you access to the box if you'd like.

It'd be helpful to be able to point at a radius server with an account that has a 17 (or larger) character password. I've got no way of testing that I'm following the RFC correctly - 16 and under still work with the new code I assume?

–Bill