RADIUS with MS-CHAPv2 Explanation

Question

Can't find any flowcharts on how communication works between peers. I know how it works in Radius with PAP enabled, but it appears that with MS-Chapv2 there's a whole lot of work to be developed.

I'm trying to develop a RADIUS server to receive and authenticate user requests. Please help me in the form of Information not code.

Answer 1

"is typically performed within another EAP method such as EAP-TLS, EAP-TTLS or PEAP."

Well... RADIUS win2008 server here, configured to NO EAP, only MS-CHAPv2 encryption, to replace the PAP.

This is why alot of what you said and what i said wasn't adding up... I'm not MITM, i'm the AS, and my NAS(the one who knocks) is the RADIUS_Client/Authenticator.

When the user enters UN&PW a random encryption, which i'm now on the look for, is created with MS-CHAPv2 and all of the above is irrelevant.

With the items received from the Authenticator which again are: - Username, MS-CHAP-Challenge, MS-CHAP2-Response

The AS performs a magical ceremony to come up with the following: -Access-Accept

-MPPE-Send-Key

-MPPE-Recv-Key

-MS-CHAP2-Sucess

-MS-CHAP-DOMAIN

This is from a working scenario, where i have a RADIUS server, a radius client and a user.

A NOT working scenario, is the one where i am the RADIUS Server(AS), cause that's my goal, building a RADIUS server, not MITM. So all i got left is finding out what decryption algorithem needed for those and how.

Answer 2

Unfortunately i can't add anymore comments, the demand is for me to have 50 reputation.

To your request: My lab enviorment is of SSL-VPN used with AS of RADIUS. Constructed with the following 3 items:

1. End-User -> there's no 'client' installed, the connection starts through a web portal. client = web browser

2. NAS -> This is the machine that provides the web-portal(the place the End-User enters the Username & Password) AND acts as a RADIUS CLient, transfering requests to the AS.

3. AS(RADIUS) -> This is me. I receive the access-requests and validate the username & password.

So in accordance with that, what i receive in the Access-Request is:

MS-CHAP2-Response: 7d00995134e04768014856243ebad1136e3f00000000000000005a7d2e6888dd31963e220fa0b700b71e07644437bd9c9e09

MS-CHAP-Challenge: 838577fcbd20e293d7b06029f8b1cd0b

According to RFC2548:

• MS-CHAP-Challenge This Attribute contains the challenge sent by a NAS to a Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) user. It MAY be used in both Access-Request and Access-Challenge packets.

• MS-CHAP2-Response This Attribute contains the response value provided by an MS- CHAP-V2 peer in response to the challenge. It is only used in Access-Request packets.

If i understand correctly, and please be calm this is all very new to me, based on your flowchart the AS is also the Authenticator who inits the LCP. And in my case, the LCP is initiated by the NAS, So my life made simple and i only get the Access-Request without needing to create the tunnel.

My question now is, how do i decrypt the password? I understood there's a random challenge 16-byte key but that is held by the NAS.

From my recollection, i only need to know the shared secret and decrypt the whole thing using the algorithem described in your thesis.

But the algorithem is huge, i've tried different sites to see which part of it the AS supposed to use and failed in each attempt to decrypt. Since i can't ask for help anymore in this thread, i can only say this little textbox cannot fill the amount of gratitude i have for your help, truely lucky to have you see my thread.

Do email me, my contact info are in my profile. Also, for some reason i can't mark your answer as a solution.

Answer 3

MSCHAPv2 is pretty complicated and is typically performed within another EAP method such as EAP-TLS, EAP-TTLS or PEAP. These outer methods encrypt the MSCHAPv2 exchange using TLS. The figure below for example, shows a PEAP flowchart where a client or supplicant establishes a TLS tunnel with the RADIUS server (the Authentication Server) and performs the MSCHAPv2 exchange.

The MSCHAPv2 exchange itself can be summarized as follows:

• The AS starts by generating a 16-byte random server challenge and sends it to the Supplicant.
• The Supplicant also generates a random 16-byte peer challenge. Then the challenge response is calculated based on the user's password. This challenge response is transmitted back to the AS, along with the peer challenge.
• The AS checks the challenge response.
• The AS calculates a peer challenge response based on the password and peer challenge.
• The Supplicant checks the peer challenge response, completing the MSCHAPv2 authentication.

If you'd like to learn about the details and precise calculations involved, feel free to check out my thesis here. Sections 4.5.4 and 4.5.3 should contain all information you need in order to implement a RADIUS server capable of performing an MSCHAP exchange.

As you can see in the figure, many different keys are derived and used. This document provides a very untuitive insight into their functionality. However, the CSK is not explained in this document. This key is optionally used for "cryptobinding", i.e. in order to prove to the AS that both the TLS tunnel and MSCHAPv2 exchange were performed by the same peer. It is possible to derive the MSK from only the TLS master secret, but then you will be vulnerable to a relay attack (the thesis also contains a research paper which gives an example of such an attack).

Finally, the asleap readme gives another good and general step by step description of the MSCHAPv2 protocol, which might help you further.