(RADIATOR) Possible to Proxy PEAP-EAP-MSCHAP v2 to IAS?
Tom Rixom
tom.rixom at alfa-ariss.com
Tue Feb 10 04:59:50 CST 2004
Hi Mike,
> -----Original Message-----
> From: Mike McCauley [mailto:mikem at open.com.au]
> Sent: Tuesday, February 10, 2004 11:28 AM
> To: Tom Rixom; Jon Snyder; radiator at open.com.au
> Subject: Re: (RADIATOR) Possible to Proxy PEAP-EAP-MSCHAP v2 to IAS?
>
>
> Hi Tom,
>
>
> On Tue, 10 Feb 2004 09:03 pm, Tom Rixom wrote:
> > 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.
>
> Thats interesting.
>
I guessed that would get your attention ;).
> >
> > 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? ;)
>
> With the EAPAnonymous paramter you can set the User-Name of
> the inner auth to
> anything you like. It just defaults to anonymous. For example
> %0 is replaced
> by the EAP identity from the outer auth. Any other special
> chars can be used
> too.
Is their a way to use the EAP identitity of the inner authentication?
Regards,
Tom
>
> Cheers.
>
>
> >
> > 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.
>
> --
> 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.
More information about the radiator
mailing list