"Sam Critchley" <[EMAIL PROTECTED]> wrote:
> The RADIUS debug output showed that FreeRADIUS complained about an
> incorrectly configured shared secret, but it only did this for each second
> Access-Request packet received during one authentication attempt - the
> first packet passed the corresponding check.
That's very strange. For EAP, the only reason it knows that the
shared secret is wrong is because the Message-Authenticator fails
validation.
> We then took traces with Ethereal and compared every single parameter of
> the trace taken during authentication against the W2K server with the
> trace taken when authenticating against FreeRADIUS. What we found was a
> difference in the TLS session initialisation between the supplicant and
> the client.
"client" as in "ap"? It doesn't do TLS, so that's probably not what
you meant.
There may also be differences in the SSL/TLS options that FreeRADIUS
passes to the supplicant.
> The only differences between the two authentication attempts are:
> - different certificates (from different CAs) used on the supplicant
> - Access-Point authenticating against a FreeRADIUS server vs. a W2K server
The servers may also be responding with different information.
> In summary, we have two issues with the Linksys:
>
> 1. The weird behaviour with the invalid shared secret for the 2nd
> packet sent from the AP to the FreeRADIUS server.
That's plain wrong, and should be independent of any EAP or TLS
issues, unless the AP is *severely* broken.
> We don't really understand why a supplicant should try to use the SSL
> option against one RADIUS server (FreeRADIUS), and the correct TLS option
> against another (Win2K).
The servers send back TLS options, too. The supplicant may be
getting excited about those, and doing something stupid.
> It's possible that the packet is being modified somewhere in
> transit (although both successful and non-successful APs are one NAT
> segment away from the RADIUS server so we've ruled NAT out as a
> cause), but we can't really understand where this might happen.
I doubt that very much.
> Does anyone have any ideas what could cause this, or has anyone see
> similar behaviour with FreeRADIUS?
I've never heard of it before.
About the only thing I can see that's different between the two
Access-Challenge packets is that one has:
State, Message-Authenticator
and the other (FreeRADIUS) has:
Message-Authenticator, State
One of the Intel AP's was reported as not working with FreeRADIUS,
because it expected to see the attributes in the first order, and
refused to work if it saw them in the second order.
I'd suggest hacking src/lib/radius.c, rad_send() to always make
Message-Authenticator the last attribute in the packet. If that
works, file a bug report both with Linksys && bugs.freeradius.org.
If it *is* the cause of the problem, I'll be *very* annoyed.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
