(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