| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.
Now, STA 1 gets to the 4-way handshake, and provides Message 2 with a Device ID KDE.
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 |