Authenticating Client to fake WPA AP without valid PMK?

Question

So I've been looking through the WPA and 4-way handshake mechanisms trying to brainstorm the possibilities for creating a fake AP with WPA encryption, an option which seems to be missing from airbase-ng. Here are my thoughts so far: I create a fake AP with WPA-PSK encryption flag and set its ESSID to the target AP's ESSID. By de-authenticating the clients connected to the target AP, the normal reaction would be searching for their AP in the WiFi list. They would attempt to connect to the fake AP using the password I'm trying to retrieve.

According to this Wikipedia demonstration of the 4-way handshake: https://en.wikipedia.org/wiki/IEEE_802.11i-2004#Protocol_operation The PTK is never shared on the fly between the AP and the station (client); instead, MIC's are compared. In packet 2/4, the station sends its SNonce signed with an MIC. After receiving this packet, the fake AP would skip constructing a PTK and would just send packet 3/4 with a randomly assigned GTK and an MIC (I'm not sure whether this MIC is verified by the client).

So my questions are: Does the client verify the MIC from the 3rd packet of the handshake? If it doesn't, does that mean that the client has been successfully authenticated and connected to the AP?

Further thoughts: In the absence of an AP-sided PTK, can I just send raw un-encrypted data packets to the client for the purpose of DNS spoofing? In the case that raw data packets aren't accepted by the client, could the Hole196 vulnerability (documented here: http://www.airtightnetworks.com/WPA2-Hole196) be utilized for DNS spoofing, given that the GTK is known by the fake AP?

I hope you're caught up with my question; if you need any further clarification, I'll be glad to reply.

Answer 1

Okay so I've read through the IEEE Std 802.11-2012 documentation, and came to the conclusion that my concept is invalid and not feasible due to the following:
In section 11.6.2 of the IEEE Std, at the bottom of page 1249, the following statement appears:

If the GroupKey or SMK KDE is included in the Key Data field, but the Key Data field is not encrypted, the EAPOL-Key frames shall be ignored.

This rules out the option of sending an unencrypted GTK to the supplicant (client), knowing that sending an encrypted GTK to the supplicant is not possible as well due to the fact that the fake AP can't generate the actual (client-sided) PTK required for the encryption of the Key Data (including the GTK) in the 3rd EAPOL message of the four-way handshake.
The encryption of the Key Data field in WPA2 CCMP is usually achieved through the NIST AES key wrap algorithm documented in IEFT RFC 3394.

My assumption that the GTK could be sent to the supplicant unencrypted (before I arrived to that section of the IEEE Std) also ended up with a complete failure; it's further explained in section 11.6.6.4 of the IEEE Std 802.11-2012 on page 1259:

On reception of Message 3, ..., the supplicant also:
...
b) Verifies the Message 3 MIC. If the calculated MIC does not match the MIC that the Authenticator included in the EAPOL-Key frame, the Supplicant silently discards Message 3.

Again, since the fake AP can't generate a valid PTK, it can't calculate the valid MIC for Message 3, which results in a discarding of the message and failure of the operation.