Radius authentication passphrase length

[buraglio]

I've been running into an issue with the captive portal auth in that some users are unable to authenticate.  The common thread seems to be that they have a passphrase that is greater than 16 characters.  Has anyone else run into this?  I'm happy to try and rectify it myself but I have not found much documentation on the way the captive portal works, if anyone has any insight or pointers I'd be grateful.

Thanks,
nb

[buraglio]

As a data point, I believe the captive portal is all based on this guy's code: http://www.mavetju.org/programming/php.php (according to the header in the file).  I'm investigating changes.

[billm]

Hard to say, I do see a number of '16's in the PECL radius code, but I don't see anything that obviously points to a password length restriction (well..128 chars I think was the max).  OTOH, releng_1 uses the radius code in /usr/local/captiveportal - and that code is really difficult to read :)  There are some debug statements in there, you should be able to easily hand test the RADIUS_AUTHENTICATION() function.

–Bill

[buraglio]

I'm pretty sure it's just clipping the password before it sends it off.  I can't prove it yet.

[buraglio]

Yup, it appears to be clipping at 16 characters (assuming I'm interpreting the debug correctly).

"username is blahblah with len 8 encryptedpassword is ƒ“>˜nÝeA&$Í‡G with len 16 …."

when in reality my passphrase has been set to 25 characters.  Now I just need to figure out where that is happening....

[billm]

@buraglio:

Yup, it appears to be clipping at 16 characters (assuming I'm interpreting the debug correctly).

"username is blahblah with len 8 encryptedpassword is ƒ“>˜nÝeA&$Í‡G with len 16 …."

when in reality my passphrase has been set to 25 characters.  Now I just need to figure out where that is happening....

In Encrypt() (same file):
        for ($i=0;$i<=15;$i++) {

heh…ouch - if you fix it, I'll commit it - this code is different I believe in HEAD (we're using PECL radius now), so you might want to test there also if you get a chance.

--Bill

[buraglio]

Where are you finding this?

[billm]

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

–Bill

[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.

[billm]

@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]

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]

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]

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]

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]

@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]

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]

@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]

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]

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

nb

[billm]

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

–Bill