| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Mark,
Thanks for detailed argument. I think we are on the same track. After the meeting today I reworked the resolution along the lines we appeared to getting consensus.
Basically, we do not add a “mismatch” status, and we do not add any detailed description of the ‘mismatch’ occurrence.
We assume that if in any way the AP is confused, it will return status “not recognized”. In the case of a mismatch then we assume the AP will probably set both Device ID and IRM status to “not recognized”.
BUT then I propose to add that if the AP sends Device ID not recognized it may send a new device ID in the same KDE or element. AND if AP sends IRM “not recognized” the STA may send a new IRM in the subsequent KDE or element. The idea being that the STA is re-establishing itself.
Hence, as I understood it, although you set out the ‘mismatch’ condition(s) we do not intend to discuss this condition specifically in the Draft.
Specifically these are the changes I am proposing at this moment: (Maybe find a better word than “confused” in the Note?)
Edit at 31.29
When a non-AP STA receives an AP Identity frame with the Identifier Status equal to “Not Recognized”, it must assume that no shared identity state exists with the AP or ESS (as per the concepts of 12.2.10) and the non-AP STA must (re)establish any desired, shared identity state per the procedures previously described. If an AP sends a Device ID element or Device ID KDE with the Device ID status field set to 1 indicating “Not Recognized”, then the AP may also provide, in that same Device ID element or Device ID KDE, a new device ID.
Note: An AP might send a Device ID status field set to 1 indicating “Not Recognized” for any reason if the AP is confused about the non-AP STA shared identity state
Note: An AP might send a Device ID status field set to 1 indicating “Not Recognized” for any reason if the AP is confused about the non-AP shared identity state.
Edit at 33.8
Note to Editor: The changes are based on the revised text as approved for CIDS 2,3,4,5, 149, 197
When a non-AP STA that advertises support for IRM associates to an AP that advertises support for IRM, the AP shall include an IRM KDE in message 3 of the 4-way handshake or, when using FILS authentication, including an IRM element in the Association Request frame. If the AP recognizes the IRM MAC address, the IRM Status field of the IRM KDE or IRM element is set to 0 to indicate that the AP recognizes the IRM and the IRM field is not present. If the AP does not recognize the IRM MAC address, the IRM Status field of the IRM KDE or IRM element is set to 1 to indicate that AP does not recognize the IRM and the IRM field is not present. The non-AP STA, on receipt of an IRM Status field of value 1, indicating the AP has not recognized the IRM, may either continue to associate to the AP and provide a new IRM in an IRM KDE in message 3 of the 4-way handshake or, when using FILS authentication, including an IRM element in the Association Request frame,
inor disassociateNote: An AP might send an IRM status field set to 1 indicating “Not Recognized” for any reason if the AP is confused about the non-AP STA shared identity state.
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, August 29, 2023 7:24 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] TGbh CIDs 135 and 224 ("Mismatch")
All,
Just to be clear, and also to pull in those who may not have been on today’s call. As I understand the sequence of events that can lead up to the “mismatch” of identifiers, it looks something like this (for the regular association case, not pre-association/PASN, not FILS, etc.), and please correct me if I got something wrong:
Let’s assume an AP (network) has built up state for three client devices, STATE X, STATE Y, and STATE Z. It is storing this information somewhere in/behind the network, and how it identifies these is implementation-dependent. The state might include Layer 2 information, or it might be only “higher-layer” information, or both. As far as 802.11 is concerned, it is just an “implementation-dependent collection of state information”.
The AP (network) also has some sort of “mapping table” that maps a list of expected IRMAs to these state objects. And, similarly, it also maps the last provided device ID to these state objects. In both cases, it is expecting the relevant STAs to provide the appropriate identification whenever they come back to the network.
Along comes a STA with an RCM, let’s call it STA 1. It goes through Probes (optional), Authentication, and Association, all using IRM#1.
- At this point, the AP (network) thinks it knows that STA 1 maps to STATE Z, based on the IRMA that it is using.
Now, STA 1 gets to the 4-way handshake, and provides Message 2 with a Device ID KDE.
- The AP (network) maps the device ID (let’s call it DID#1) in the KDE, and finds that it maps to STATE Y.
At this point, the network knows there is a problem. Either, IRM#1 is not really this device, or DID#1 is not really this device. So, in message 3, does the AP say either of these are recognized? I don’t see the argument that either of them “came first”, or is more to be trusted than the other. So, I am arguing that message 3 should have _both_ the Device ID KDE and IRM KDE and both should say “Not Recognized”.
Q1: Is this agreed, or are there thoughts to do this differently?
I think the proposal is that at this point, the AP also includes a new device ID in the message 3 Device ID KDE, and the non-AP STA includes a new IRMA the message 4 IRM KDE, and those can be used for this device going forward, but all past state is lost and the device is effectively “starting over” (whatever that means to it/to the network) with a new identity. The network starts a new state, STATE A, and maps the new device ID and IRMA to STATE A, and all proceeds as if this were a new device.
Q2: Just checking. That is what we were working toward on the call today, right?
(An aside, but… what if the 4-way handshake also completes such that the network “knows the real identity” of the device – that is, at least the identity for network security purposes, which may or may not have anything to do with the state identity (STATE X, STATE Y or STATE Z) – but this identity turns out to be meaningful and it maps to STATE X? So, now the network has gotten mappings to three different state objects for this single device. Do we care? Do we suggest this check even be done – for example if the device mapped to STATE Z state with both device ID and IRMA, but then the security negotiation concluded it is STATE X? Is this another “mismatch” that we have to deal with?)
Mark
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1