| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Graham, I continue to be confused by the idea that “the IRM comes first”. For sake of discussion, let’s stick with the normal association process (not FILS, not PASN). I think those others work the same way in the end, but it is too confusing to try to cover them all in the same logic flow. I agree, the IRM hits the air first, in the TA of some messages. But, I don’t think that’s important useful. The way it really lays out, as I understand it, is that an associating client device will use some (local) address for authentication/association messages – this may or may not even be an IRM. The network will know if this is meant to be an IRM only at the Association exchange (from the RSNXE). But, it doesn’t communicate anything to the client device about what it thinks it knows, until Message 3 of the 4-way. Thus, things really happen only in the 4-way handshake. In Message 2 the non-AP STA sends its Device ID. And, now, in Message 3 the AP can say what it thinks of both the IRM and the Device ID. At this point, the AP has received both, and should have done the mapping to the stored state objects that it has. That mapping could turn out to be any of: neither match anything, one matches and the other doesn’t, both match to the same state object, or both match but to two different state objects. Also, at this point, the AP might know who the client device is from a security perspective, depending on the security mode being used. And, the AP might have a connection between the client device’s security identity and it’s TGbh identity, or it might not. If it does has such a connection, it could tell if either/both/neither of the TGbh identities match the security identity. A bunch of “maybes” in this aspect of the process. Anyway, at the point of sending Message 3, when the AP can really say anything useful back to the client, it has all that information all at once. I don’t see that the IRM, nor the Device ID, are particularly “first” anymore. The AP says what it thinks the status is, based on all the possible conditions I mentioned above, all in parallel (same time). My opinion is that if the AP doesn’t recognize either of the identifications, or if the identifications don’t match each other (map to the same state object), or if the AP happens to be able to tell if the security identity matches the TGbh identity(ies) and those don’t match, then it should say “Not recognized” to everything, and make the non-AP STA start over. I think that’s what you said in the end, but I got confused by your comments along the logical path (like saying IRM comes first, and I wasn’t clear about the handling of all the other matching cases). My takeaway is that the AP should refuse to accept anything from a non-AP STA that provides “bad” information, where bad is claiming to have a TGbh identity, but that identity either doesn’t match anything on the AP, or the identify has any sort of mismatch with other information the AP has. Are we saying the same thing? And, did that answer Antonio’s question – which I think is that in response to his question, “The new one will be coupled to the "stored state" the IRM is coupled to?” the answer is “No, something went wrong, and everything must start over.” In all these cases, either the problem is because either the AP has “timed out” its state information, in which case there is nothing left to re-connect to anyway, or the non-AP STA is broken or lying (an attacker?) with its information, in which case the AP should refuse to make any connection to prior state. Mark From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> Hi Antonio, The IRM comes first as that is the TA that the STA is using to associate/authenticate. The basic idea is that if, for any reason, the AP has a problem with the recognizing the IRM, i.e., not already stored, then the AP returns “IRM not recognized”. This is the also the case for a first time association, so the STA sends a new IRM and now the STA is “registered” via the IRM with the AP. Similarly, if the STA sends a device ID, and the AP does not have that already stored, then AP returns “Device ID not recognized”. In this case, there is something wrong but I am proposing that the AP “starts again” and provides a new device ID and now the STA is “registered” via the device ID with the AP. So now for the “mismatch” condition. The AP will send the IRM status and the device ID status in the same frame, e.g., msg 3 of 4w HS. If, it has a problem with matching the IRMand device ID to the stored information, then it simply treats both IRM and Device ID as “not recognized”. This gives us a clean way ahead, “if in doubt, start again”. Hope this helps. Graham From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx> Hi Graham, regarding the sending of the new DID in case it is not recognized, but when the IRM is recognized. The new one will be coupled to the "stored state" the IRM is coupled to? So basically, if IRM is recognized, the AP knows the "stored state" of the STA and bounds a new DID to it, is this the intention? Thanks Antonio El mié, 30 ago 2023 a las 23:05, G Smith (<gsmith@xxxxxxxxxxxxxxxxxxx>) escribió:
-- Antonio de la Oliva Associate Professor 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 |