| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mark, Comments in line From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Graham, I’d like to be a bit more explicit, and see if we are aligned, or not, below. Mark From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Hmm… my comments below are not correct. I was only considering the case when the AP has both valid IRM and device ID stored, but for different STAs. Just to be clear, if a STA provides an IRM and a device ID:
[[MAH]] Given that the STA must have provided a device ID, but it is wrong, I would say in this case that the STA is broken/confused and cannot be trusted. So, while I’m fine with the negotiation of new identities (as you say), I
would also say that the network should respond “not recognized” to both identities, and it should _not_ associate the new identities with the old state information it had for this IRM. (These last points are what I wasn’t sure about in your email.) GS – But what if AP had simply deleted the device ID? We have had many such comments on “how long does the AP have to store these? However, the AP can always do what it wants, so it coud return a “IRM not recognized”
if it so wishes, but that could confuse the STA. If the AP recognizes the IRM but not the device ID it should tell the STA exactly that. Then both know the situation.
[[MAH]] Similarly, something is wrong, and the network should say “not recognized” on both, and start over with new identities (both) and new state information.
GS – same answer. AP could simply have been re-booted or whatever, and lost the IRM. Again up to the AP. But more important is that both STA and AP know something is up, and exactly what it is, but only if
the AP tells the STA exactly what it sees. Then STA knows what might result.
If recognizes IRM and device ID, i.e., has them ‘stored’, but against different STAs, then AP says “device Id not recognized” AND “IRM not recognized”. AP provides a new ID and STA provides a new IRM. [[MAH]] Agreed, and the network does not associate these new identities with any/either of the existing state information – it really completely “starts over”. All this is covered by the text I proposed. I don’t think we need more. [[MAH]] The above could be inferred from your text, but I don’t think it’s clear. I would suggest being clear that if anything is wrong/not recognized with either or both identity, then either or both identities (which ever the devices
jointly signal they support) are “start over”, including assigning new ids and also starting new state information. GS – I think that we simply need to leave it up to the AP. Both AP and STA are completely aware of the situation as to the IRM and/or device ID being recognized. I can add some text to what I have (in rev 15)
if necessary. Graham From: G Smith Hi Mark, Antonio, My comment that the IRM comes first was not meant to imply that the IRM has precedence in any way. Simply that the AP can ‘know’ the STA from the TA, before it knows it from the device ID. But none of that matters. I’m pretty sure we
are on the same wavelength in that by msg 3 the AP either is happy or not. If not, it uses “Not recognized”. Note that, in the case that the STA uses IRM and device ID, then AP
cannot respond “IRM not recognized” AND “device ID recognized” (and vice versa) – they are either both recognized, or neither (maybe I should add a sentence to that effect?). In all cases, if the AP responds device ID “not recognized” then the AP includes a new device ID in the same KDE or element. In all cases, if the AP responds IRM “not recognized” or “recognized” then the STA includes a new IRM in the net KDE or element (e.g., msg 4).
Graham From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
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 |