Forum

The MS-CHAPv2 authentication protocol can be used in PEAP and PPTP. Lets see if anyone out there knows the difference between how PPTP uses it and PEAPv0 uses it.

:-)

My guess is that in PEAP it is EAP-MS-CHAPv2 (MS-CHAPv2 using EAP messages) rather than straight MS-CHAPv2.

If I am right, I have a counter question (that I don't know the answer to). What is the functional difference (if any) between MS-CHAPv2 and EAP-MS-CHAPv2? Maybe I am just confused on the whole concept.

NICE! That's exactly right Ben!

With EAP-MSCHAPv2, the MSCHAPv2 frames are encapsulated in EAP frames to meet the EAP-in-EAP requirements of PEAP.

Devinator

Thanks, man. But next time, don't make a Mac user go search a Microsoft site for the answer ;).

I still am a bit curious, though. What is the difference between an MS-CHAPv2 message in an EAP frame and a plain ol' MS-CHAPv2 message. I guess what I'm asking is, do I get any additional security using EAP-MS-CHAPv2 (like with PEAP) than I get using MS-CHAPv2 (like with EAP-TTLS)?

Yes it will. You however need to make the choice as to whether the increased security EAP offers is worth the increased bandwidth consuption from additional encapsulation. Your scenario will determine that.

What specifically is the extra security that EAP-MS-CHAPv2 provides compared to MS-CHAPv2? The challenge/response sequence is still the same, no?

Also, how much extra encapsulation overhead is there? I'd have to imagine the effect on throughput is downright minimal. Encryption overhead generally comes from processing, not encapsulation.

Minimal overhead. PEAP requires EAP-in-EAP, and therefore whatever auth protocol is used inside of the 802.1X/EAP framework must be wrapped in EAP.

How about this for a next question...

Inside the TLS tunnel, the EAP-MSCHAPv2 conversation happens between which two entities?

Devinator

I think what I am getting from this is that EAP-MS-CHAPv2 offers no real advantage or disadvantage to MS-CHAPv2. It is simply a protocol used to satisfy the requirements of PEAP.

As far as the PEAPv0 conversation inside the TLS tunnel (or any other conversation inside a TLS tunnel, for that matter, it should happen between the two parties that exchange the public key information of the certificate. In this case, the supplicant and the authentication server.

My question is, how the heck do you configure the RADIUS server to get information (like attributes and VSAs) outside the tunnel so that the authenticator (Access Point or switch) can read it?

With Tunneled EAP types, such as PEAP, TTLS, and FAST, the tunnel must be torn down, and then the RADIUS Access Accept frame must be sent from the Authentication Server to the Authenticator. The attributes are carried in this frame, as is the PMK (encrypted with the RADIUS shared secret of course).

Devinator

Funk must have steered me in the wrong direction then. When I contacted their support team with my problem, they told me the attributes had to be configured to be removed from the tunnel rather than returned in the Access Accept message.