| Message ID | 20181111110235.14213-1-alexander@wetzel-home.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Extended Key ID support for linux | expand |
Hi, Sorry for the delay. On Sun, 2018-11-11 at 12:02 +0100, Alexander Wetzel wrote: > IEEE 802.11-2012 added support for Extended Key ID, allowing pairwise > keys to also use keyID 1 and moving group keys to IDs 2 and 3. Where do you read this? I've always been under the impression that individually and group addressed frames use key IDs from different "namespaces", so to speak, where PTK/STK can use 0 (0 or 1 with "Extended Key ID" support) and GTK can use 0-3. In fact, the per-frame pseudocode in 802.11-2016 12.9.2.6 clearly states: if MPDU has individual RA then lookup pairwise key using Key ID from MPDU else lookup group key using Key ID from MPDU endif If it weren't different namespaces, you'd not have to differentiate here. > Support for Extended Key ID is basically completed and confirmed working > with both hwsim and "on the air" with ath9k/iwldvm using software > encryption and those patches here. :) > Prior to propose this patch for merging I would like to get Extended > Key ID working with HW encryption for at least some devices, but after > experimenting with ath9k and to a lesser extend with ath10k it's now > clear that this will be an per-driver effort and it may well turn out to > be impossible without firmware updates. Indeed. I think there might be some support with iwlwifi firmware, at least newer versions? I can check later. > So I've decided to continue working on the HW support for now but also > ask you for feedback for what I got so far. Sounds good. > Any feedback is welcome and I especially like to learn what you think of > the API extensions and what has to be changed to get it merged. I'll look over the individual patches. johannes
> Hi, > > Sorry for the delay. > No problem. That's hardly urgent:-) > On Sun, 2018-11-11 at 12:02 +0100, Alexander Wetzel wrote: >> IEEE 802.11-2012 added support for Extended Key ID, allowing pairwise >> keys to also use keyID 1 and moving group keys to IDs 2 and 3. > > Where do you read this? I've always been under the impression that > individually and group addressed frames use key IDs from different > "namespaces", so to speak, where PTK/STK can use 0 (0 or 1 with > "Extended Key ID" support) and GTK can use 0-3. > > In fact, the per-frame pseudocode in 802.11-2016 12.9.2.6 clearly > states: > > if MPDU has individual RA then > lookup pairwise key using Key ID from MPDU > else > lookup group key using Key ID from MPDU > endif > > If it weren't different namespaces, you'd not have to differentiate > here. > I was indeed struggling to understand what the intend of the standard is here. I may well be wrong, but the note in "12.6.1.1.10 Mesh GTKSA" tipped the scales to assume keyIDs are within one namespace only. "Since Key ID 0 is reserved for individually addressed frame transmission, there are at most three available Key IDs (only two if extended Key IDs for individually addressed frames are in use), and the different MGTKs would contend for the single remaining Key ID upon rollover." I got the impression Extended Key IDs were added without updating all sections which should get updates. But the pattern is suspect, even the igtk numbers fit into the pattern: PTK 0 & 1 GTK 1 & 2 & 3 iGTK 4 & 5 That may well be utterly wrong... Any idea how can we sort that out? >> Support for Extended Key ID is basically completed and confirmed working >> with both hwsim and "on the air" with ath9k/iwldvm using software >> encryption and those patches here. > > :) > >> Prior to propose this patch for merging I would like to get Extended >> Key ID working with HW encryption for at least some devices, but after >> experimenting with ath9k and to a lesser extend with ath10k it's now >> clear that this will be an per-driver effort and it may well turn out to >> be impossible without firmware updates. > > Indeed. I think there might be some support with iwlwifi firmware, at > least newer versions? I can check later. > >> So I've decided to continue working on the HW support for now but also >> ask you for feedback for what I got so far. > > Sounds good. > I think I've solved the HW support issue, it looks like we'll be able to support Extended Key IDs with minimal changes to the drivers in a compatibility mode. It's basically working with iwldvm and ath9k but needs some more work. Alexander
On Wed, Dec 05, 2018 at 08:06:33PM +0100, Alexander Wetzel wrote: > >On Sun, 2018-11-11 at 12:02 +0100, Alexander Wetzel wrote: > >>IEEE 802.11-2012 added support for Extended Key ID, allowing pairwise > >>keys to also use keyID 1 and moving group keys to IDs 2 and 3. > > > >Where do you read this? I've always been under the impression that > >individually and group addressed frames use key IDs from different > >"namespaces", so to speak, where PTK/STK can use 0 (0 or 1 with > >"Extended Key ID" support) and GTK can use 0-3. There is no such requirement to change group key IDs in the IEEE 802.11 standard when taking Extended Key ID mechanism into use. > >In fact, the per-frame pseudocode in 802.11-2016 12.9.2.6 clearly > >states: > > > >if MPDU has individual RA then > > lookup pairwise key using Key ID from MPDU > >else > > lookup group key using Key ID from MPDU > >endif > > > >If it weren't different namespaces, you'd not have to differentiate > >here. > > > > I was indeed struggling to understand what the intend of the standard is > here. I may well be wrong, but the note in "12.6.1.1.10 Mesh GTKSA" tipped > the scales to assume keyIDs are within one namespace only. > > "Since Key ID 0 is reserved for individually addressed frame transmission, > there are at most three available Key IDs (only two if extended Key IDs for > individually addressed frames are in use), and the different MGTKs would > contend for the single remaining Key ID upon rollover." Please note that this is is an informative note and not normative part of the standard. IMHO, that note is not accurate and it looks likely that it was added without full understanding on how the keys are used in the standard.. > I got the impression Extended Key IDs were added without updating all > sections which should get updates. But the pattern is suspect, even the igtk > numbers fit into the pattern: > > PTK 0 & 1 > GTK 1 & 2 & 3 > iGTK 4 & 5 An AP is allowed to do this, but there is no requirement for doing so. The pairwise key (TK, not PTK) is required to use Key ID 0 unless the optional Extended Key ID for Individually Addressed Frames capability is negotiated (and 0 or 1 if that capability is negotiated). Group keys (GTK) are allowed to use Key IDs 0..4. IGTKs are allowed to use Key ID values 4 and 5. There is a long history behind this and some de facto constraints due to that history and possible implementation constraints. However, as far as the protocol itself is concerned, there would be no real need for having IGTK use 4..5; it could have as well been 0..1 or 1..2 or whatever combination the AP would like to use. These three cases have completely independent namespaces for Key IDs as far as RSN is concerned with one exception: "Use group cipher suite" that was added as an option for some AP implementation that did not support individual key mapping. That special case would end up using GTK for both group-addressed and individually-addressed frames. That said, I'm not aware of there having ever been an actually deployed device with this constraint and even if there were, this mode is highly discouraged and should not be used for anything today. Anyway, this exception and similar implementation constraints are likely behind the expectations of TK and GTK having to use different Key ID values. As far as the kernel changes are concerned, cfg80211 and mac80211 should support everything that's allowed by the standard, i.e., use of Key IDs 0..3 for GTK. It is up to the user space implementation on the AP side (e.g., hostapd) to select which Key IDs are actually taken into use.
>> I got the impression Extended Key IDs were added without updating all >> sections which should get updates. But the pattern is suspect, even the igtk >> numbers fit into the pattern: >> >> PTK 0 & 1 >> GTK 1 & 2 & 3 >> iGTK 4 & 5 > > An AP is allowed to do this, but there is no requirement for doing so. > The pairwise key (TK, not PTK) is required to use Key ID 0 unless the > optional Extended Key ID for Individually Addressed Frames capability is > negotiated (and 0 or 1 if that capability is negotiated). Group keys > (GTK) are allowed to use Key IDs 0..4. IGTKs are allowed to use Key ID > values 4 and 5. > > There is a long history behind this and some de facto constraints due to > that history and possible implementation constraints. However, as far as > the protocol itself is concerned, there would be no real need for having > IGTK use 4..5; it could have as well been 0..1 or 1..2 or whatever > combination the AP would like to use. > > These three cases have completely independent namespaces for Key IDs as > far as RSN is concerned with one exception: "Use group cipher suite" > that was added as an option for some AP implementation that did not > support individual key mapping. That special case would end up using GTK > for both group-addressed and individually-addressed frames. That said, > I'm not aware of there having ever been an actually deployed device with > this constraint and even if there were, this mode is highly discouraged > and should not be used for anything today. Anyway, this exception and > similar implementation constraints are likely behind the expectations of > TK and GTK having to use different Key ID values. Thanks for the clarifications! If there really are drivers using "Use group cipher suite" it does not sound like they would be able to support Extended Key ID with APs using key ID 1+2 for GTKs. But sounds not likely anyone would need that... My experimentation with hw accel and Extended Key ID for existing drivers so far are also indicating that it will work using the keyid 1 for both PTK and GTK, so this should be a trivial change in hostapd only. > > As far as the kernel changes are concerned, cfg80211 and mac80211 should > support everything that's allowed by the standard, i.e., use of Key IDs > 0..3 for GTK. It is up to the user space implementation on the AP side > (e.g., hostapd) to select which Key IDs are actually taken into use. > I'm pretty sure that is already the case, but so far I only tested it with GTK shifted to 2+3. I'll make sure to test the next revision with GTK using 1+2 also. I'll test that once I get that working again from end2end. The patch here is getting a bit dated and makes no sense to invest time for that win it. Alexander