eap-mschapv2

[Josh Howlett]

> auth: type "EAP"
> +- entering group authenticate
>   rlm_eap: Request found, released from the list
>   rlm_eap: EAP/mschapv2
>   rlm_eap: processing type mschapv2
> +- entering group MS-CHAP
>   rlm_mschap: Told to do MS-CHAPv2 for user with NT-Password
> rlm_mschap: adding MS-CHAPv2 MPPE keys
> ++[mschap] returns ok
> MSCHAP Success
> ++[eap] returns handled
> Sending Access-Challenge of id 3 to x.x.x.x port 1812
>         MS-CHAP2-Success = 
> 0x01533d463936353246454443333542423338354535333743303338333739
> 41393735313330363134413336
>         EAP-Message = 
> 0x010200331a0301002e533d46393635324645444333354242333835453533
> 374330333833373941393735313330363134413336
>         Message-Authenticator = 0x00000000000000000000000000000000
>         State = 0xabe2000baae01ac677bcdaf79192ae6c
> Finished request 1.

That looks like a bug to me. It's a violation of RFC2548:

2.3.3.  MS-CHAP2-Success

   Description

      This Attribute contains a 42-octet authenticator response string.
      This string MUST be included in the Message field of the MS-CHAP-
      V2 Success packet sent from the NAS to the peer.  This Attribute
      is only used in Access-Accept packets.

It might be worth checking the logic in the eap-mschap module; it should
be pretty obvious to see where it is going wrong.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG