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

[Terry Simons]

I'm just curious as to the reason for wanting to use PEAP.

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?

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.

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).

TTLS->PAP is also natively supported by Linux (with xsupplicant) and 
Mac OS X (10.3.x).

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.