Re: CHAP auth failure

[Alan DeKok]

Strong, Mark wrote:
> Problem is sorted.  Telco changed their AAA-SC

  Which begs the question of just what the heck RADIUS server they were
using.

> Thanks Alan, that section of the RFC helped the Telco sort the problem.

  i.e. they wrote a "telco-grade" RADIUS server without reading the specs.

  What a great idea.

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

RE: CHAP auth failure

[Strong, Mark]

>[chap] login attempt by "xx" with CHAP password [chap] Using
>clear text password "password" for user xx authentication.
>[chap] Password check failed
> 
> (a) the "clear text" password is wrong
> 
> (b) the client isn't doing CHAP correctly.
> 
> There are no other choices.

Problem is sorted.  Telco changed their AAA-SC

>   RFC 2865 Section 5.3 says that the CHAP-Challenge doesn't need to exist.  If
> it doesn't exist, the 16-byte authentication vector from the Access-Request
> is used instead.
> 
> 
>   Alan DeKok.
Thanks Alan, that section of the RFC helped the Telco sort the problem.


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

Re: CHAP auth failure

[Alan DeKok]

Strong, Mark wrote:
> I get this in the debug
> 
> [chap] login attempt by "xx" with CHAP password
> [chap] Using clear text password "password" for user xx 
> authentication.
> [chap] Password check failed

  (a) the "clear text" password is wrong

  (b) the client isn't doing CHAP correctly.

  There are no other choices.

> I've tried with radtest using type chap, and it works fine,

  Because FreeRADIUS correctly implements CHAP, and has done so for
nearly 14 years.

  Other people seem to have major issues with the simplest parts of the
RADIUS protocol.

> I'm thinking there's a problem with the access-request (but I don't control 
> that end, it's a large Telco in AU).

  Their system is broken.

> What I want to know is, do I have enough attributes in this access-request 
> for CHAP to work?

  Yes.  In theory.

...
> I don't see one of these "CHAP-Challenge" from the NAS

  And that's likely the problem.  But not for the reason you may think.

  RFC 2865 Section 5.3 says that the CHAP-Challenge doesn't need to
exist.  If it doesn't exist, the 16-byte authentication vector from the
Access-Request is used instead.

> I'm not sure what pieces freeradius needs to munge together to come up with 
> the same password hash that rolls in from the Telco.

  FreeRADIUS needs either the CHAP-Challenge, or the *original*
authentication vector.  And that gives you the problem.  When a packet
is proxied, the authentication vector for the proxied packet is
*completely* different from the input packet.

  When FreeRADIUS proxies a packet with CHAP-Password, it copies the
original authentication vector into a CHAP-Challenge attribute.  So the
home server has everything it needs in order to do CHAP.

  RFC 2865, item (1) at the top of Page 10 says to do this, and
FreeRADIUS is RFC compliant.

  The "large Australian telco" doesn't do that.  It's broken.

> I didn't post the full debug just so I didn't have to redact so much.  If 
> this access request turns out to be ok, I can post the full debug.

  That's fine.  You posted enough.

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