(RADIATOR) Possible to Proxy PEAP-EAP-MSCHAP v2 to IAS?

Tue Feb 10 04:03:15 CST 2004

Hello,

It is possible to configure the IAS server into supporting EAP-MSCHAPV2
as an authentication method. We are still testing the method at this moment
as this is not documented.

The reason for this is that we are experimenting with the new SecureW2 
Client 2.0 which supports inner EAP. So what you get is TTLS-EAP-MSCHAPV2.

It all works quite well but..... (of course their is a but)

One problem is that Radiator sends the user attribute "User-Name: Anonymous" 
in all the inner requests which off course is rejected by the IAS. I was 
already planning on asking Mike for help on this so I might as wel do it 
know.... Mike? ;)

Regards,

Tom Rixom
SecureW2
Alfa & Ariss

> -----Original Message-----
> From: Jon Snyder [mailto:jon at pdx.edu]
> Sent: Monday, February 09, 2004 11:24 PM
> To: 'Mike McCauley'; radiator at open.com.au
> Subject: RE: (RADIATOR) Possible to Proxy PEAP-EAP-MSCHAP v2 to IAS?
> 
> 
> Sounds like the same conclusion I came to, so at least we're 
> on the same
> page.
> 
> As to some of the other questions on this thread, we haven't done much
> testing with the Alfa-Ariss client yet, but we find it 
> generally easier and
> less painful to have people configure something that's 
> already there than
> add a new piece of software.
> 
> Anybody have any general pointers on what it would take to 
> turn EAP-MSCHAP
> into plain RADIUS-MSCHAP?  If I suddenly get some extra time, 
> perhaps I can
> work on adding that functionality.  That would be the 
> cleanest fit with our
> model.  Not sure I can convince the Windows guys to let me 
> install Perl and
> Radiator on their servers :) 
> 
> ----------
> Jon Snyder
> Computing and Network Services
> Portland State University
> (503) 725-9565
> 
> -----Original Message-----
> From: Mike McCauley [mailto:mikem at open.com.au] 
> Sent: Monday, February 09, 2004 2:04 AM
> To: Jon Snyder; radiator at open.com.au
> Subject: Re: (RADIATOR) Possible to Proxy PEAP-EAP-MSCHAP v2 to IAS?
> 
> Hello Jon,
> 
> 
> On Mon, 9 Feb 2004 07:09 pm, Jon Snyder wrote:
> > Hi all,
> >
> > We're trying to configure EAP for 802.1x wireless 
> authentication with the
> > general rule that Radiator will authenticate everything it 
> can locally,
> and
> > proxy the authentication types it can't.  Our Radiator 
> instance is running
> > on Solaris with passwords in NIS, so we can't for example 
> authenticate
> > MS-CHAP v2 requests.
> >
> > What I would like to do is proxy PEAP-EAP-MSCHAP v2 (from 
> the Windows XP
> > SP1 PEAP client) to an IAS server running on Windows 2003, which can
> > authenticate the MS-CHAP v2 request.  But, if the request 
> is TTLS with PAP
> > or some other form that can be authenticated locally on the 
> unix host, do
> > so there.  The problem I think I'm running into is that Radiator is
> > properly proxying the inner EAP-MSCHAP v2 on to the IAS 
> server, but IAS
> > can't handle EAP-MSCHAP v2 as it receives it; it wants 
> either PEAP with
> > MSCHAP v2 inside, or a regular MSCHAP v2 challenge in the 
> radius packet
> (no
> > EAP).
> 
> Its true that IAS cannot handle bare EAP-MSCHAPV2, only when 
> it is tunnelled
> 
> inside PEAP, so you would have to forward the entire PEAP 
> conversation to
> the 
> IAS server.
> 
> The problem is that is is not possible to distinguish between 
> EAP types when
> 
> trying to figure out where to proxy something. Mainly this is 
> beacause the 
> EAP type is not negotated until several packets have been 
> exchanged, so you 
> have a chicken-egg problem when trying to figure out where to 
> send the 
> requests. The uphot is that you need some other cue when trying to
> determnine 
> where to send requests. Most commonly this is the realm in 
> the users name,
> of 
> course.
> 
> 
> >
> > Is it possible to accomplish what I'm trying to do?  It 
> seems like if I
> > could "extract" the MSCHAP v2 and send it over to IAS 
> without it being
> > EAP-MSCHAP v2 it might work.  I know it's possible with 
> TTLS to have one
> > server take the EAP-TTLS requests, and proxy the actual 
> authentication to
> > another server that knows nothing about EAP (as demonstrated in the
> goodies
> > configs).  Can the same be done with PEAP?
> 
> I think it might be technically possible for an EAP-MSCHAPV2 
> authenticator
> to 
> turn the requests into plain RADIUS-MSCHAPV2 and then forward 
> them. However 
> it would require some new code and we dont see muchg demand 
> for this feature
> 
> (yet).
> 
> 
> >
> > I have this working if I use an AuthBy FILE for handling the inner
> > authentication, so I know it's not a general issue with my system or
> > configuration for PEAP.  But with the AuthBy RADIUS below, no go.
> 
> This config would prob work if only IAS could understand EAP-MSCHAPV2
> outside 
> a PEAP tunnel. 
> 
> Actually Radiator understands bare EAP-MSCHAPV2 and when it 
> runs on Windows,
> 
> it can be configured to authenticate EAP-MSCHAPV2 against AD, LSA etc.
> 
> MAybe the right answer is to run your Radiator on Windows and 
> configure to 
> auth the inner EAP-MSCHAPV2 with AuthBy LSA?
> 
> Cheers.
> 
> 
> >
> > Thanks in advance!
> >
> > Here's what I'm doing in the Radiator config (this isn't 
> the whole config,
> > but should be all the relevant portions):
> >
> > <Handler TunnelledByPEAP=1,EAPType=MSCHAP-V2>
> >         <Log FILE>
> >                 Filename %L/PEAPInside.log
> >                 Trace 4
> >         </Log>
> >
> >        <AuthBy RADIUS>
> >                NoDefault
> >                EAPType MSCHAP-V2
> >                <Host win2k3.ias.box>
> >                        Secret secret
> >                        AuthPort 1812
> >                        AcctPort 1813
> >                </Host>
> >        </AuthBy>
> > </Handler>
> >
> > <Handler TunnelledByPEAP=1>
> >         <AuthBy SYSTEM>
> >                 NoDefault
> >         </AuthBy>
> > </Handler>
> >
> > <Handler TunnelledByTTLS=1>
> >         <AuthBy SYSTEM>
> >                 NoDefault
> >         </AuthBy>
> > </Handler>
> >
> > <Handler Client-Identifier=wiAPs>
> >         <Log FILE>
> >                 Filename %L/PEAPOutside.log
> >         </Log>
> >         <AuthBy FILE>
> >                 Filename %D/users
> >                 EAPType PEAP,TTLS
> >
> >                 EAPTLS_CAFile 
> %D/certificates/thawte/ThawteServerCA.txt
> >                 EAPTLS_CertificateFile
> > %D/certificates/radius-server.cert.pem
> >                 EAPTLS_CertificateType PEM
> >                 EAPTLS_PrivateKeyFile
> %D/certificates/radius-server.key.pem
> >                 EAPTLS_PrivateKeyPassword whatever
> >                 EAPTLS_MaxFragmentSize 1000
> >
> >                 AutoMPPEKeys
> >         </AuthBy>
> > </Handler>
> >
> > ----------
> > Jon Snyder
> > Computing & Network Services
> > Portland State University
> >
> > ===
> > 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 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.
===
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.