IGTK keys are a bit weird. Here goes.
In the 802.11 specification they occupy key indexes 4 and 5, but there are
no indexes 4 and 5 available in the 802.11 header! It only has space for
keys 0..3.)
Instead, the IGTK keys are used as part of verifying broadcast management
frames - there's an IE appended to the management/action frames - that
aren't encrypted! - which contains a message integrity check for the
frame contents. In that IE is the IGTK key id to use.
wpa_supplicant / hostapd will use key indexes 4 and 5 for the IGTK
keys when doing MFP, just like the 802.11 specification says to do.
Like WEP/group keys, it's used by all receivers in a BSS (and thus
VAP), but unlike WEP/group keys, they're not used for encryption/decryption
in the normal data path.
Now, to make things more fun, the keyidx fields assigned by the
driver /technically/ start at "whever the driver wants", which
is almost always "after the WEP key indexes 0..3." So some drivers
currently just assume keyidx's of 4 or above are non-group keys.
That's no bueno for IGTK keys when doing MFP.
So for drivers that support hardware encryption, they'll want to
double/triple check that the keys they're being handed are group
keys and ont IGTK keys. For drivers that support MFP (whether
in hardware, software, or both) they will need to know whether
keys are group or IGTK rather than relying on key index values.
Drivers which do straight software encryption almost certainly
don't need to care, unless they use the keyidx stuff for identifying
things like stations - which ath(4) actually used to, to accelerate
the receive path. (Until I turned it off because it turns out it's
actually buggy in some chips. Ha.)
Anyway - this is added as a placeholder so that the current drivers
and the linuxkpi path can be audited for its use of keyidx as a
placeholder for key types and instead have things cleaned up to
use the ieee80211_is_key_{group,unicast,igtk}() functions.