Hi Alan,

Thanks very much for your detailed response, please see mine in line:

On Tue, 22 Jun 2004 15:51:41 -0400, Alan DeKok <[EMAIL PROTECTED]> wrote:

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

Right.


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.

No, you're right, but this gets passed on from the RADIUS server to the supplicant - apologies.



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.

We couldn't see any other differences as far as I know but will consult with the other folk working on this and get back to the list.



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.

Well, we also tried the same thing with a D-Link DWL-AP2000+ straight out of the box. This is also a "WPA certified" AP, and we got the same behaviour. Works with Win2K RADIUS, doesn't work with (at least our version of) FreeRADIUS using EAP-TLS.



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.

Well, it's the standard WinXP stack supplicant, maybe there's someone on the list who knows how it's put together?



 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.

Yeah, that's what we thought too. We had a couple of suspected problems with segmentation, but they turned out to be a red herring.



Does anyone have any ideas what could cause this, or has anyone see
similar behaviour with FreeRADIUS?

I've never heard of it before.

Okay, good to know in either case.



  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.

We will see if we can try this - will get back to the list with the results once we've got something.



If it *is* the cause of the problem, I'll be *very* annoyed.

;-) Well, we've spent several weeks testing and puzzling as well... has slowed our project (authentication scheme for a wireless-equipped village in the Netherlands plus some other applications) down a lot.


Thanks,


Sam


Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html



-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to