peap-mschapv2 on web authentication

[procurvenewbee]

How does peap-mschapv2 work on an endpoint via web browser for web authentication to switch?

Traditionally we will need to set up supplicant / client to use an authentication protocol to forward / hash / encapsulate credentials to the authenticator in switch. In this case, there is nothing set up, so how will client (in this case internet explorer) knows that it has to use machapv2 as inside protocol and peap as outside tunnel as this is not the case of 802.1x configured supplicant.

Yes the switch in this case will send a challenge to client, when client tries to open a browser and present a window on a webpage to supply the credentials, but still the sent credentials will need to be in mschapv2 format ( both way authentication).

Doing a reserch on google does not come up with anything (other than a couple procurve references) on use of mschapv2 or peap-mschapv2 for web page authentication. Procurve documentation is not helpful as it does not explain how is a browser client supposed to use peap-mschapv2.

Any feedback will be appreciated.

Thanks

[Matt Hobbs]

I thought the manual was quite good.

http://cdn.procurve.com/training/Manuals/3500-5400-6200-8200-ASG-Jan08-4-WebMacAuth.pdf

Basically, your web browser can use either unencrypted HTTP, or encrypted HTTPS between the client and the switch.

The peap-mschapv2 part is for the connection between the switch and the RADIUS server.

[procurvenewbee]

Thanks Matt. I did figure out this after further thinking more about this, but still could not understand the use of PEAP between NAS and the Radius server. MSChapv2 to enable against clear text transfer of credentials but what will be the use of Peap here.

[Matt Hobbs]

The main advantage with using peap-mschapv2 for web-auth is that you don't have to enable reversible encryption on all your user accounts (which is what you previously needed to do when only CHAP was an option).

[procurvenewbee]

Really?

I thought CHAP or any variation of CHAP (mschap v2) will still require radius to retrieve password from say AD (which will normally store password as one way hashed MD5/ irrersible and that will fail for chap as it requires clear or reversible encryption storage) to be able to hash it with challenge received from NAS/Switch and then compared two hashes. How does mschap with peap tunneling get away with requirement of not requiring passwords to be stored on AD with reversible encryption?

Thanks

[Matt Hobbs]

It's PEAP!