Multiple Password Prompts

Alan DeKok aland at ox.org
Fri Aug 5 23:30:44 CEST 2005


ragan_davis at 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.

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

> 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'm trying my hardest to fight this, because I'm a big freeradius
> fan.

  Thanks.

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

> 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

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

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

  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.

  Alan DeKok.




More information about the Freeradius-Users mailing list