(RADIATOR) Possible to Proxy PEAP-EAP-MSCHAP v2 to IAS?
Steve Caporossi
capoross at musc.edu
Mon Feb 9 11:35:42 CST 2004
See Below...
Terry Simons wrote:
> I'm just curious as to the reason for wanting to use PEAP.
Not really *wanting* to but looking for low cost solutions. Our
customers want to know why they have to pay for something that the OS
supports.
>
> Is it because TLS and PEAP are the only natively supported EAP types in
> Windows, and people don't want to install extra software just to gain
> 802.1x functionality, or is it because people don't want to *pay* for
> extra software to gain functionality that is "present" in Windows?
Yes & yes. One more piece of software to support and, in times of
budget cutbacks, free is a big plus :-)
>
> For what it's worth, there is a *free* TTLS->PAP plugin for Windows that
> plugs right in to WIndows XP Zero Config which works quite nicely, so
> for those that don't want to spend the extra cash, this might be an option.
I looked at it a year or so ago...and was not happy with it...I'll look
at it again.
>
> We're using TTLS->PAP at the University of Utah because we feel that
> PEAP is too much of a security risk (since it requires plain-text or
> reversibly encrypted passwords be stored on the server).
We have the some of the same concerns and are also using TTLS->PAP,
currently with the Odyssey Client. Being able to pre-configure the
client is a big plus.
>
> TTLS->PAP is also natively supported by Linux (with xsupplicant) and Mac
> OS X (10.3.x).
I have used the instructions on your site to setup a mac for
testing...Good Job!
>
> I just thought I'd mention the option for people that might be
> interested in using it.
>
> The plugin for Windows is called "SecureW2" and is available from the
> following URL:
>
> http://www.alfa-ariss.com/
>
> You'll need to click on "[EN]" at the bottom of the page to get the
> English version.
>
> - Terry
>
> On Feb 9, 2004, at 6:27 AM, Steve Caporossi wrote:
>
>> FYI...We would be interested in this enhancement as well. Would solve
>> lots of issues here :-)
>>
>> Steve
>>
>> Mike McCauley wrote:
>>
>>> 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.
>>
>>
>> ===
>> 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.
More information about the radiator
mailing list