Authentication issues from Apple devices

[Phil Mayers]

On 05/14/2011 10:08 AM, stentofon wrote:
> The users connect through a chillispot captive portal, via HTTP.  HTTPS
> causes too many problems with certificates, and the access point is
> unencripted anyway, so security is not the issue.
>
> I initally thought that the hotspot clients were simply making mistakes, but
> i've been testing it all day with the iphone v blackberry and Windows 7 and
> i'm fairly certain the password is going in ok.  I set the username and
> password to be sandra : sandra for simplicity, as the autocorrect should
> leave it alone.  I also set up an account as 1234 : 1234 and this also
> failed only on the iphone.
>
> For it to only affect Apple products, i had hoped that the debug message was
> going to show some rubbish in the username to prove that there was some

No; the packet is well-formed.

The problem is that, in your failing case, the CHAP-Password is not 
valid for the given CHAP-Challenge and your plaintext password "sandra".

That is, the client (Chilli) is sending invalid auth to FreeRADIUS.

> issue with the input, but i can't see the issue when the debug message is
> confirming that the correct username and password were supplied.

That's not what the debug message says. I assume you're referring to 
this line:

[chap] login attempt by "sandra" with CHAP password
[chap] Using clear text password "sandra" for user sandra authentication.

...which means "I'm trying a login for 'sandra'. My (server-side) value 
for their clear text password is 'sandra'". It doesn't refer to anything 
the client sent (well, the username I guess).

CHAP is a challenge-response method. The NAS (Chilli) never sends the 
password to FreeRADIUS. Instead, it sends:

CHAP-Challenge = 16 random bytes
CHAP-Password = 1 byte ID + md5(ID + password + challenge)

The radius server then extracts the plaintext password from the SQL 
database, and the ID & challenge from the packet, computes it's own copy 
of CHAP-Password, and compares it to the packet.

In your failing case, they don't match, so authentication is denied 
(I've confirmed this by doing the MD5 manually in python - it's 
definitely invalid. I tried a few trivial variations of the password 
too, so see if I could figure out what the client was using - no dice)

I think the problem must be at the Chillispot end - it's breaking the 
CHAP somehow for iOS clients.

Since you're not using HTTPS, you could try getting a packet capture of 
a working and failing login HTTP session, and compare the two in detail 
- I'd be looking for the POSTed form data, and any HTTP headers that 
might affect the interpretation e.g. character encodings.

But this isn't really a FreeRADIUS problem I'm afraid.