In the recently published paper on PPTPv2 (http://www.counterpane.com/pptpv2-paper.html), you state "5 Analysis of MS-CHAPv2 We do not know why Microsoft chose such a complicated protocol, since this is not stronger than the following: The Server sends the Client an 8-byte challenge. The Client encrypts the 16-byte local password hash with an 8-byte challenge and sends the Server the 24-byte response, an 8-byte challenge of its own, and the username. The Server sends a pass/fail packet with a 24-byte response to the Client's challenge, which is the user's password-hash-hash encrypted with the Client's 8-byte challenge." In fact, the above protocol is considerably weaker than MSCHAPv2. 1. It is subject to a chosen plaintext attack by the server, or by an active attacker. A rogue server can always use a constant challenge (or the active attacker can modify the server's challenge), and precompute a table of responses for any list of passwords it chooses, making finding the user's password a mere table lookup. That's because, in this protocol, the response is independent of the username and the client, and depends only on the password and the server's challenge. In contrast, MSCHAPv2 creates a challenge by hashing a nonce chosen by the client with one chosen by the server -- thus neither gets to control what the challenge is. (Does this clarify your confusion in section 3.1?) 2. Any eavesdopper can recover the local password hash, since it is encrypted with the server's 8 byte challenge, which was sent in the clear. This means it can masquerade as the user. 3. Any eavesdropper can recover the user's password-hash-hash, since it is encrypted with the client's 8 byte challenge, which was sent in the clear. Once the eavesdropper has the user's password-hash-hash, it can "mutually authenticate" to that user. [OK, let's assume that you got steps 2 & 3 reversed -- you meant to say that the challenge was encrypted by the hash (or hash-hash).] 4. It is subject to a chosen plaintext attack by an active attacker on the mutual authentication step, leading to a precomputed table lookup attack on the password-hash-hash. The MSCHAPv2 mutual authentication step, by incorporating the client's response (which is a function of both client's and server's nonce), does not let the client control the server's response, which otherwise would only depend on the password. Paul
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:51:47 PDT