(RADIATOR) Possible to Proxy PEAP-EAP-MSCHAP v2 to IAS?
Jon Snyder
jon at pdx.edu
Mon Feb 9 16:23:37 CST 2004
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.
More information about the radiator
mailing list