(RADIATOR) Re: PEAP-MSCHAPv2 works, but not TTLS-MSCHAPv2

Nacho Paredes iparedes at eurocomercial.es
Mon Apr 10 06:18:22 CDT 2006


As usual you are right.

I've applied the patches and the User-Password attribute is no more. But
still got the problem.
I'm really annoyed with this, I can make work perfectly TTLS-MSCHAP and
PEAP-MSCHAPv2, but not TTLS-MSCHAPv2.
Could this be a supplicant issue? I'm using Funk Odyssey Client 3.03
Could you think another test I could make?

Thanks again.

-----Mensaje original-----
De: Mike McCauley [mailto:mikem at open.com.au] 
Enviado el: lunes, 10 de abril de 2006 13:03
Para: Nacho Paredes
CC: 'Hugh Irvine'; radiator at open.com.au
Asunto: Re: (RADIATOR) Re: PEAP-MSCHAPv2 works, but not TTLS-MSCHAPv2

Hello Nacho,

On Monday 10 April 2006 20:47, Nacho Paredes wrote:
> Retaking this topic.
>
> I've tested it in another platform with perl 5.8 and still got the
problem.
>
> I've seen something that looks strange. Why in the EAP-TTLS-MSCHAP2 
> access request is there an empty User-Password attribute?
> I have tried to get rid of it with StripFromRequest, but doesn't seem 
> to work.

The empty User-Password attribute was an artifact of the code. It was
removed about 1 week, and the fixes are in the latest patch set. 
However, I would be surprised if that is causing your problem.

>
> Code:       Access-Request
> Identifier: UNDEF
> Authentic:  <173>N<214>z=L?V<154>|T<132><177>eD<248>
> Attributes:
>         User-Name = "testu at wifi"
>         MS-CHAP-Challenge = <132>1q<10>bTM<25><148><193><22>,<227>\<21>f
>         MS-CHAP2-Response =
> <147><0>N<210><127><148>\<245>VB<172><217><250><222><237><158>'@<0><0>
> <0><0
>>
> <0><0><0><0>9<172>o<242><24>_t<254>,<150><190><188><240>u<228><0><153>
> I<202
>> <10>-<209><150>C
>         User-Password = ""
>
> This is taken by this piece of code in AuthGeneric::checkAttributes 
> which rejects the request:
>
> if (   $check_name eq 'Encrypted-Password'
>
> || $check_name eq 'Crypt-Password')
>
> {
> 	# EAP passwords have already been checked
> 	next if defined $p->getAttrByNum($Radius::Radius::EAP_MESSAGE);
> 	return ($main::REJECT, "Bad Encrypted password")
> 	if !&check_password($self, $p, $value, $username, 1); }
>
>
> Any idea why is this happening?
>
> Regards.
>
>
> -----Mensaje original-----
> De: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au] En
> nombre de Mike McCauley
> Enviado el: jueves, 23 de marzo de 2006 0:11
> Para: Nacho Paredes
> CC: 'Hugh Irvine'; radiator at open.com.au
> Asunto: Re: (RADIATOR) Re: PEAP-MSCHAPv2 works, but not TTLS-MSCHAPv2
>
> Hello Nacho,
>
> Thanks for the logs and info on this topic.
> Testing your config here on another platform works OK.
> We are not at present able to test locally on a 64 bit solaris sparc with
> your particular version of Perl.
>
> The version of perl you report is 5.6.1 for sun4-solaris-64int.
> That is quite an early version for that particular OS/processor/integer.
>
> I think the best thing at this stage would be to upgrade your perl to a
> more recent version.
>
> Cheers.
>
> On Wednesday 22 March 2006 18:17, Nacho Paredes wrote:
> > We are using Radiator 3.14 plus latest patches.
> >
> > More SW & HW data:
> >
> > [root at rasca]> uname -a
> > SunOS rasca.fq.dn 5.9 Generic_118558-02 sun4u sparc SUNW,Ultra-80
> >
> > [root at rasca]> uname -X
> > System = SunOS
> > Node = rasca.fq.dn
> > Release = 5.9
> > KernelID = Generic_118558-02
> > Machine = sun4u
> > BusType = <unknown>
> > Serial = <unknown>
> > Users = <unknown>
> > OEM# = 0
> > Origin# = 1
> > NumCPU = 2
> >
> > [root at rasca]> perl -v
> > This is perl, v5.6.1 built for sun4-solaris-64int (with 48 registered
> > patches, see perl -V for more deta
> >
> > If you need more information, please tell me.
> >
> > Thanks on advance
> >
> > -----Mensaje original-----
> > De: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au] En
> > nombre de Hugh Irvine Enviado el: viernes, 17 de marzo de 2006 23:18
> > Para: Nacho Paredes
> > CC: radiator at open.com.au
> > Asunto: (RADIATOR) Re: PEAP-MSCHAPv2 works, but not TTLS-MSCHAPv2
> >
> >
> > Hello Nacho -
> >
> > Can you please tell me what version of Radiator you are running?
> >
> > The latest version is Radiator 3.14 (plus patches).
> >
> > Can you also please tell me what hardware/software platform you are
> > using and what version of Perl?
> >
> > regards
> >
> > Hugh
> >
> > On 18 Mar 2006, at 04:15, Nacho Paredes wrote:
> > > Another try:
> > >
> > > Hello,
> > >
> > > I sent this message some days ago, but seems it didn't arrive to the
> > > list.
> > > Excuse me any inconvenience.
> > >
> > > We have a Radiator system to authenticate wireless 802.1x.
> > > We have tested different configurations and EAP methods and
> > > everything worked fine, except TTLS-MSCHAPv2. We find it a bit weird
> > > because we have no problems with TTLS-MSCHAP or PEAP-MSCHAPv2.
> > >
> > > We don't do any rewrite of the inner User-Name. We configure the
> > > supplicant with exactly the same user name that is stored in the
> > > database (user at wifi).
> > > We use the User-Name anonymous for the outer User-Name. Every
> > > AccessPoint has defined DefaultRealm=wifi, so we can use this handler:
> > >
> > > <Handler Realm=wifi>
> > >         RewriteUsername s/^([^@]+).*/$1/
> > >         AuthBy OuterAuthentication
> > > </Handler>
> > >
> > > Since the rewrite is done over the outer User-Name, I guess it
> > > doesn't affect the MSCHAP-v2 process.
> > >
> > > I enclosed the Radiator configuration and log files for:
> > > PEAP with MSCHAPv2 (accepted)
> > > TTLS with MSCHAP (accepted)
> > > TTLS with MSCHAPv2 (rejected)
> > >
> > > The only change we make to use MSCHAP or MSCHAPv2 is modifying the
> > > EAPTYpe parameter.
> > >
> > > Any help will be appreciated.
> > >
> > > Regards
> > > <LOG-TTLS MSCHAP (accept).txt>
> > > <LOG-TTLS MSCHAPv2 (reject).txt>
> > > <radius-config.txt>
> > > <LOG-PEAP MSCHAPV2 (accept).txt>
> >
> > NB:
> >
> > Have you read the reference manual ("doc/ref.html")?
> > Have you searched the mailing list archive (www.open.com.au/archives/
> > radiator)?
> > Have you had a quick look on Google (www.google.com)?
> > Have you included a copy of your configuration file (no secrets),
> > together with a trace 4 debug showing what is happening?
> >
> > --
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> > -
> > Nets: internetwork inventory and management - graphical, extensible,
> > flexible with hardware, software, platform and database independence.
> > -
> > CATool: Private Certificate Authority for Unix and Unix-like systems.
> >
> >
> > --
> > Archive at http://www.open.com.au/archives/radiator/
> > Announcements on radiator-announce at open.com.au To unsubscribe, email
> > 'majordomo at open.com.au' with 'unsubscribe radiator' in the body of the
> > message.
> >
> >
> > --
> > Archive at http://www.open.com.au/archives/radiator/
> > Announcements on radiator-announce at open.com.au To unsubscribe, email
> > 'majordomo at open.com.au' with 'unsubscribe radiator' in the body of the
> > message.

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list