Multiple Password Prompts

[ragan_davis at colstate.edu]

----- Original Message -----
From: Alan DeKok <aland at ox.org>
Date: Friday, August 5, 2005 5:30 pm
Subject: Re: Multiple Password Prompts

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

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