3.0.x: user-password length decoding sometimes wrong?

[Stefan Winter]

Hi,

ugh. I just updated to 3.0.x from a few minutes ago to be prepared for
the MS-CHAP key problem and iOS 9.

That seems to work - good. But I have a problem with good old PAP but
only for requests originating from one of the clients - and consistently.

That client is insanely old and has ancient library versions. So it may
well be doing something subtly wrong in the requests it sends; but
still, this worked for a FreeRADIUS server versions since a decade. But
not in current 3.0.x.

What I see coming in (decoded in -X) is:

(137) Received Access-Request Id 89 from 158.64.1.50:8010 to
158.64.2.220:1812 length 80
[...]
(137)   User-Password = "12345678\000\000\000\000\021"

That's an 8 char password (12345678 is the equivalent of correct; i.e.
redacted in this mail but it otherwise fits).

On other clients, the same password comes in as

User-Password = "12345678"

as expected; a tcpdump between for both clients reveals that the
on-the-wire length of User-Password is the same (16 chars net, to
account for padding).

Current 3.0.x then does SSHA password comparison between what it got and
the contents in our DB, and finds that the SSHA hash of the above first
string does not match our stored password hash, while the second one
does. So it's a Accept/Reject difference and our users are not happy.

Now since padded-and-encrypted parsing differences are the exact problem
that was fixed for 3.0.9, I suspect that fixing that had a side-effect
on PAP password length extraction.

It looks like the old client uses \0-then-something-random as padding (I
also saw requests with jsut one \0 and then more garbage) while newer
clients pad with \0\0\0\0 until the attribute ends. And that the latter
works, while the former doesn't :-)

I realise that all \0 is what RFC2865 chapter 5.2 mandates as padding
text. So, yes, our client is at fault.

Still, is there any chance that the server-side parsing could be made a
little more forgiving?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150915/00828903/attachment.sig>