Hi Graham,
Thanks for your feedback. Here are some of my insights:
- PASN is a special usage for device ID. Currently, device ID is signaled in PASN frame1 unencrypted, and allocated in PASN frame2 encrypted. This implies that device ID is sent in the clear in PASN frame1. This forces
STA and AP to use device ID only once, therefore, it is recommended to allocate device ID frequently. This “a bit
violates” the idea of device ID being a long-term identifier, however, usage of opaque ID can be helpful (device ID can be long-term and opaque ID can be exchanged frequently) when it comes to implementation.
- For IRM duplication; the IRM allocation happens in,
1) Association Req for FILS
2) Auth Msg3 for PASN
3) 4-way HS Msg4 for other cases
The duplication feedback (referred to as feedback onwards) from AP should ideally come after these frames. So we don’t have a much choice.
For FILS, we can put the feedback in Association Resp, but then, STA will be without IRM for next connection because STA already tried to allocate IRM itself in Association Req (before Assoc Resp) and “failed”. It can
send Association Req again to allocate a new IRM to itself but not sure about this approach. Besides, FILS auth frame does not define any IE encryption so we need to be careful if we want to use that.
[Please correct me if I miss something]
For 4-way HS, as you mentioned, one idea is that IRM allocation happens in 4-way HS Msg2, duplication feedback happens in Msg3, and allocating a new IRM in Msg4 -> this might work.
For PASN, we can only encrypt PASN frame3 for STA and PASN frame2 for AP (it does not seem possible to encrypt frame1), so we have to put IRM in PASN frame3. If so, no response frame comes after frame3.
That is why I proposed using de-auth or de-assoc with reason code so that STA can go back and allocate a new IRM itself for 1), 2), and 3). But seems like we need another approach (e.g. robust action frame)
If we use a robust action frame, it might solve all of these. AP can send the feedback in action frame, and actually, STA can allocate a new IRM to itself with the action frame as well. So two-sided action frame would
be helpful here. We already defined IRM Element, so we can put it in the action frame. Specifically, AP can use the action frame for feedback, STA can use the action frame for new IRM allocation, with the help of (already defined) IRM Element.
All in all, this discussion is of course based on whether we want to address IRM collision. My feeling is that the group is fine with addressing it with a robust action frame.
BR,
Okan
From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: 2023年7月13日
14:13
To: Okan Mutgan (NSB) <okan.mutgan@xxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [External] RE: Duplicate in IRM Status field
|
|
CAUTION:
This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb
for additional information. |
Just a follow up on sending IRM in msg 2 of 4W HS. In the highly unlikely event of a duplicate, then AP can sent “duplicate” in msg 3, and then STA can sent new IRM in msg 4. Voila,
all is good. Actually AP could send either “recognized but duplicate” or “not recognized and duplicate”, we have plenty of bits.
In FILS, I think the opportunity to send a new IRM is not there ? but I may be wrong. Could inform of duplicate but not sure what a STA could do. Can it simply send a new FILS Auth
request before it sends an association request? If it can do that, then we are good. Is that possible? ? any FILS experts?
In PASN if could send (encrypted) IRM in msg 1, then AP could send “duplicate” in msg 2, and STA sends new IRM in msg 3. Not sure if you are able to overcome the non-encrypted IRM
or Device ID in msg 1 yet. Having said that, in PASN I think the numbers are very low, i.e., how many STA IRMs might we expect the APs to handle when using PASN? As I keep saying, saving 100 IRMs, there is a 1 in 14 billion chance of duplicate. Saving 10
is 1 in 1.4 trillion. Hence, maybe not having the duplicate in PASN might be acceptable.
I am still on the fence about using status. If duplicate could be used then I might flip.
What do you think? Also anyone else on Reflector please feel free to chime in.
Graham
From: G Smith
Sent: Thursday, July 13, 2023 6:09 AM
To: Okan Mutgan (NSB) <okan.mutgan@xxxxxxxxxxxxxxx>;
STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: PASN question
Thanks. Yes, I think I now understand it better. Please do work on making it clearer.
One other point is that the Device ID is sent in the clear, so in this case we use the Opaque ID? The underlying Device ID is, however, the same one. So over the air it is a different
ID field, but in fact it is the same ID. Is that right? That may need some explaining. Reason is that from today’s meeting I had push back when I said the Device ID is “longterm” or permanent ? someone pointed out it changes in PASN. But my point is that
it actually does not, the Device ID is the same but the Opaque ID does. That is not easy to explain, but I think that is correct.
Thanks, and best of luck making the text changes.
One last point, the “IRM Duplicate” can’t be in the Status field because the IRM is sent in msg 4, after the Status field in msg 3. Could we change to sending IRM in msg. 2 of 4W HS?
I understand that there is still a problem with PASN (sending IRM in Msg 1 would be in the clear), but maybe we accept that “duplicate” not used in PASN? What would be the effect? Any ideas?
Thanks
Graham
From: Okan Mutgan (NSB) <okan.mutgan@xxxxxxxxxxxxxxx>
Sent: Thursday, July 13, 2023 5:52 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] PASN question
Hi Graham,
Thanks for putting some thoughts and efforts on this.
Let me put the IRM Element/KDE and device ID Element/KDE here for the sake of the discussion. They contain two fields, namely, “IRM/Device ID status” and “IRM/Device ID”. But the usage of these fields varies depending
on the situation.
|
|
|
|
|
|
<Q> I do not see any mention of the AP sending the Status bit. In FIG for example, MAC 2, does AP-2 send devID2
and the status on devID1?
The figure does not show any status field, but the text describes it (please see below). We can modify the picture (adding status field to the picture) if necessary.
Correct that In FIG for example, MAC 2, AP-2 sends devID2
and the status on devID1.
<Q> By the way, what is in the Auth Msg, I assume it’s the Device ID element?
Yes it is (please see Fig 9-788fm). However, in Msg1, only Device ID field is used, and in Msg2, both device ID field (i.e. new device ID) and device ID status field (i.e. status on old device ID) are used.
<Q> Similarly when using IRM, STA sends new IRM in third PASN frame (encrypted?), does AP send the status on the used IRM in Msg 2? It’s not mentioned.
-> Correct that STA sends new IRM in third PASN frame encrypted (encryption is still not defined in details, it is one of the CIDs (CID84) so we will work on it. Note that CID84 talks about encrypting both device ID IE
for Msg2 and IRM IE for Msg3).
-> Currently, status field (recognized or not recognized) is not defined for IRM in PASN (please see the text below it talks about recognition for FILS and non-FILS & non-PASN, but not for PASN), so AP does
not send the status in Msg2 on the used IRM. This is also one of the CIDs (CID113), we will work on it.
Please feel free the drop your comments.
Thanks!
BR,
Okan
From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: 2023年7月13日
12:00
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [External] [STDS-802-11-TGBH] PASN question
|
|
CAUTION: This is an external
email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb
for additional information. |
Hi Okan,
I am reading again the PASN description and FIG 12.0a.
I do not see any mention of the AP sending the Status bit. In FIG for example, MAC 2, does AP-2 send devID2
and the status on devID1? By the way, what is in the Auth Msg, I assume it’s the Device ID element?
Similarly when using IRM, STA sends new IRM in third PASN frame (encrypted?), does AP send the status on the used IRM in Msg 2? It’s not mentioned.
Just trying to get my head around it all, wrt status.
Graham
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