----- Original Message ----- From: Alan DeKok <aland@ox.org> Date: Friday, August 5, 2005 5:30 pm Subject: Re: Multiple Password Prompts
ragan_davis@colstate.edu wrote:
If the server get's an incomplete reply to it's challenge, or no reply,> will it resend it's challenge?
No. RADIUS is entirely driven by the clients.
Gotcha
Or, will the client sense that the server didn't respond to it's challenge response and start a new session.
The client *does* see the Access-Challenge, but it decides for some reason to stop talking to the server.
Yep...that's sort of weird.
Of course, because each vendor has their own radius server and 802.1x client solution, they want to blame freeradius so that I'll buy their product.
FreeRADIUs is interoperable with pretty much everything out there. Novell is dumping their proprietary server for FreeRADIUS. Zyxel is selling a $500 FreeRADIUS box (with some question of possible GPL violations), and I know of 2 other companies using FreeRADIUs as part of their RADIUS server solutions.
I agree. In their argument, they even pointed me to a security web site that supposedly listed 42 freeradius vulnerabilities, most of which had still not been addressed (according to them). I visited the site, read the material, followed the links, and apparently they just typed "freeradius" and clicked "search", and didn't actually read the results, because half of the results were totally unrelated and the rest were describing things that were fixed in version 0.4 or something.
I'm trying my hardest to fight this, because I'm a big freeradius fan.
Thanks.
No prob. Just keep it up.
The debug on the Odyssey Client shows that it believes it sent the response to the challenge. The debug on the WLAN switch shows that it forwards both the challenge from freeradius and the challenge response> from the client. Freeradius debug appears to get the response from the client, sees the outer credentials (anonymous, etc.), but doesn't process the tunneled information for some reason.
Hmm... I do know that the odyssey client does some very weird things. In some cases, it's interoperable *only* with Funk's server, which is a nice way for them to say "other servers are broken", rather than "our client is broken".
Yep, I'm beginning to suspect as much.
So, does this mean that I should interpret the above enum to have elements 0-13, or 1-14, and match the numbers 7 and 13 with it's position in the enum?
0-13
thanks
I'm curious why we can see the TLS stuff during the first try (13), but not the second try (7). What is the difference?
The client is behaving differently the second time around.
FreeRADIUS treats the two TLS sessions as being 100% unique. It responds in the same way to the same input every time. So if one session fails and the other succeeds, it's because the client is doing something different.
Gotcha.
I performed a packet capture using ethereal, listening on the interface> that freeradius is running on. Did this on the box, not inline. I would rather not post it to the list, but I'd be glad to send it to you if you'd be willing to look at it. Let me know.
Put it on a web page and mail me the link.
Will do. I'll shoot for tomorrow (08/06).
On a plus, the latest version of Ethereal appears to have stolen the FreeRADIUS dictionary files, so the radius packets it decodes should make a lot more sense.
Yeh...I noticed that. Very nice.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html