The original MS-CHAPv2 protocol (based on MS-CHAP and CHAP) is challenge-response. In other words, the server sends a ‘challenge’, the client encrypts the user’s password with the challenge, and sends back a response, then the server checks that the response matches the client’s password. This is done so that the user’s cleartext password never travels over the wire, such as in PAP.
However, with EAP-TTLS/MS-CHAPv2, you never see a challenge from the server. The client sends both a challenge and response to the server. This seems wierd, as you lose protection against replay attacks if the client generates both the challenge and the response. The client should never be allowed to generate the challenge.
On reading RFC 5281, it becomes clear. The client generates the challenge using an algorithm, based on the earlier TTLS key data, which is unique to the session. It then sends this challenge to the server, which checks that the challenge was generated correctly, and then proceeds to handle the standard authentication.
It’s a neat way of removing one round trip from the authentication process, although slightly odd trying to understand it at first sight.