[PATCH] rsn_supp: Don't encrypt EAPOL-Key 4/4.

[Andreas Hartmann]

Jouni Malinen schrieb:
> On Sun, Feb 12, 2012 at 09:27:25PM +0100, Nicolas Cavallari wrote:
>> Then ... what do you expect "setprotection(rx)" to actually do,
>> if not instead of not crypting in the tx path ? Considering that the
>> standard does not require supporting more than one PTK per station, and
>> that the linux kernel does not support it either...
> 
> Well, this is not really described in the MLME primitives, or well, not
> really in the standard in general, but the only way to implement this
> correctly seems to require support for two PTKs that can be in use for
> the small amount of time during rekeying. I'm not aware of any
> implementation doing this either.
> 
>> Anyway, it won't solve Andreas' problem : the 4/4 frame is queued behind
>> a handful of data frames, control is resumed to wpa_supplicant, which
>> sets the key just after. When the kernel flush his queue, it already
>> uses the new key, so sends 4/4 encrypted with the new PTK ...   Solving
>> this might require something more than just "setprotection".
> 
> What were those other data frames? If this is during the initial 4-way
> handshake, the port (PAE) should be unauthorized and other data frames
> apart from EAPOL frames should be blocked. Sure, we may not yet support
> PAE in station mode, but in theory, that's the way it is supposed to
> work. As far as rekeying is concerned, this gets quite a bit more
> complex (until the newly defined non-zero key index PTK gets into use).

The problem comes up always during PTK rekeying with parallel payload
(use netperf to force it easily) - a totally normal and trivial daily
use case (streaming, nfs, X11, some internet download, ...), which is
handled by ralink supplicant e.g. without any problem.

I traced the problem on AP side at this point:

I disabled hw encryption and inserted debug output in
net/mac80211/wpa.c (ieee80211_crypto_ccmp_decrypt() - compat-wireless)
to see, where and when the frames are dropped during rekeying with
payload.

The dropping of the frames starts directly after 2/4 has been done and
3/4 has been sent the first time (long before the first 4/4 timeout). I
could see, that the first few frames (mostly data frames I suppose) are
dropped here:

        if (!(status->flag & RX_FLAG_DECRYPTED)) {
                u8 scratch[6 * AES_BLOCK_SIZE];
                /* hardware didn't decrypt/verify MIC */
                ccmp_special_blocks(skb, pn, scratch, 1);

                if (ieee80211_aes_ccm_decrypt(
                            key->u.ccmp.tfm, scratch,
                            skb->data + hdrlen + CCMP_HDR_LEN, data_len,
                            skb->data + skb->len - CCMP_MIC_LEN,
                            skb->data + hdrlen + CCMP_HDR_LEN)) {
                        printk(KERN_INFO "ieee80211_crypto_ccmp_decrypt 10 RX_DROP_UNUSABLE\n");
                        return RX_DROP_UNUSABLE;
                        }
        }

All other frames are even dropped before:

        if (memcmp(pn, key->u.ccmp.rx_pn[queue], CCMP_PN_LEN) <= 0) {
                key->u.ccmp.replays++;
                printk(KERN_INFO "ieee80211_crypto_ccmp_decrypt 9 RX_DROP_UNUSABLE\n");
                return RX_DROP_UNUSABLE;
        }

One of the dropped frame is the 4/4 frame from wpa_supplicant.

If the legacy ralink driver internal supplicant is used, the connection
isn't interrupted, because ralink sends 4/4 unencrypted (the behavior of
the data frames is the same as wrote above, but this is no problem,
as they are just resent after a few millisecs and the connection
doesn't break down).

That's the 4/4 frame as it can be seen traced with an external third
device sent by ralink:

No.     Time        Source                Destination           Protocol Length Info
   1271 142.821706  src                   dst                   EAPOL    163    Key (msg 4/4)

Frame 1271: 163 bytes on wire (1304 bits), 163 bytes captured (1304 bits)
Radiotap Header v0, Length 26
IEEE 802.11 QoS Data, Flags: .......TC
    Type/Subtype: QoS Data (0x28)
    Frame Control: 0x0188 (Normal)
        Version: 0
        Type: Data frame (2)
        Subtype: 8
        Flags: 0x1
            .... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x01)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    Duration: 202
    BSS Id: dst
    Source address: src
    Destination address: dst
    Fragment number: 0
    Sequence number: 3
    Frame check sequence: 0xeda1aa68 [correct]
        [Good: True]
        [Bad: False]
    QoS Control
        TID: 0
        Priority: 0 (Best Effort) (Best Effort)
        ...0 .... = QoS bit 4: Bits 8-15 of QoS Control field are TXOP Duration Requested
        Ack Policy: Normal Ack (0x00)
        Payload Type: MSDU
        TXOP Duration Requested: no TXOP requested (0)
Logical-Link Control
    DSAP: SNAP (0xaa)
    IG Bit: Individual
    SSAP: SNAP (0xaa)
    CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x03)
    Organization Code: Encapsulated Ethernet (0x000000)
    Type: 802.1X Authentication (0x888e)
802.1X Authentication
    Version: 1
    Type: Key (3)
    Length: 95
    Descriptor Type: EAPOL RSN key (2)
    Key Information: 0x030a
        .... .... .... .010 = Key Descriptor Version: HMAC-SHA1 for MIC and AES key wrap for encryption (2)
        .... .... .... 1... = Key Type: Pairwise key
        .... .... ..00 .... = Key Index: 0
        .... .... .0.. .... = Install flag: Not set
        .... .... 0... .... = Key Ack flag: Not set
        .... ...1 .... .... = Key MIC flag: Set
        .... ..1. .... .... = Secure flag: Set
        .... .0.. .... .... = Error flag: Not set
        .... 0... .... .... = Request flag: Not set
        ...0 .... .... .... = Encrypted Key Data flag: Not set
    Key Length: 0
    Replay Counter: 4
    Nonce: 000000000000000000000000000000000000000000000000...
    Key IV: 00000000000000000000000000000000
    WPA Key RSC: 0000000000000000
    WPA Key ID: 0000000000000000
    WPA Key MIC: f7435c2290b845547d14e6deae810b1b
    WPA Key Length: 0


As it is sent unencrypted (the same way as during initial rekeying), I
hope that the sent data is already internally encrypted (or it is just
useless for any attacker, even if he get them unencrypted), so it
shouldn't be a problem, if the frame itself isn't encrypted.

I think, Nicolas analysis of the breakage sounds correctly to me.
That's why even his patch doesn't work.

Why isn't it just possible to send one of thousands of frames
unencrypted? Just tag it with "unencrypted", so the driver knows, that
this frame musn't be encrypted at all - independently if there is a
key for encryption present or not.


Kind regards,
Andreas