| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Dan, I was just re-reading Annex AD. I have what I hope is not a stupid question, but why do you have both padding and a tweak? I can’t really see the difference. Why do you bother having the padding?
Thanks Graham From: G Smith
Hi Dan, More thinking…I was wrong. Actually your scheme does solve the PASN problem. At the moment, PASN changes the ID every authentication and hence if the same ESS had wanted to provide a permanent device ID
to that STA, it would be lost. If the AP/ESS always provided an opaque ID in PASN, then the STA would be recognized and would retain the permanent device ID. So that is certainly better. Just for the record, I have suggested a scheme where a temporary ID “PASN ID” is used so as not to change the permanent device ID, then an idea would be to include the permanent device ID in PASN msg 3 so
that the ESS knows the STA. Anyhow, to my mind, your scheme would certainly automatically improve PASN (for device ID that is). Having said that, at the moment PASN as is, with device ID, could and should use opaque ID, and to my mind,
it should be so written (unless the PASN ID idea takes hold). So, if your proposal gets accepted then PASN would automatically be solved. So that is another point in its favor.
Thanks Graham From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Graham, On 1/11/24, 1:35 PM, "G Smith" <gsmith@xxxxxxxxxxxxxxxxxxx> wrote: Hi Dan, Interesting proposal. I hope you don’t mind me providing you with my knee jerk comments.
Personally, I don’t think you need the text in 4.5.4.10.
This seems to imply that the non-AP STA encrypts the ID, which it cannot do. The generic description still works, I think. I see what you mean. That language needs to be firmed up. The ID is encrypted freshly for each connection but it is the AP that's doing the encrypting. I assume the idea is that on the first association the AP chooses a device ID (fixed and long term) for that STA, but provides an encrypted version of it to the STA during msg 3 of 4W HS. The STA uses that in the
IE the next association request. The AP then gives the STA a new encrypted ID, which is in fact the same device ID, again in msg 3 of the 4W HS. This then continues.
Bingo! This is certainly a viable scheme and the work is all done by the AP, and in that way is different to IRM where the STA controls. It does mean, however, that computations are required and also that the encrypted
version of the ID is certainly longer than the device ID itself. It also means that the encryption method in Annex AD is made mandatory and I don’t know if there are alternative methods for the encryption which some other ‘security guy’ might bring up. It's different that IRM in that it's not the STA controlling but this brings deviceID up to the utility level of IRM. With IRM, the device can use the MAC address it got on the last connection on a new connection,
at association time, and the AP will recognize the STA by the IRM. But with deviceID, as written, that's not possible. The AP won't actually recognize the STA until the 4way HS is finished and that's way too late. So in a sense, this proposal is making device ID be more like IRM, only AP controlled. To me this is a brand new scheme in that the IE is now included in the Association Request and hence it is not the optional “opaque ID” idea which has always been there. I think it has merits but it is a new scheme
and maybe supporter(s) of the present scheme may object if that is now obsoleted. The optional "opaque ID" was never there. It was never in the associate request except for FILS. It was my intention of the group doing that when I originally came up with the idea of the opaque ID but I was
kind of waiting for someone else to step up and do it and no one has. I'm sure there will be objection to this but right now device ID is pretty useless and those who object should explain themselves. In PASN it looks to be overkill to use the opaque ID. I have a comment on using a simpler “PASN ID” for that case and this would be compatible with your new scheme. Well keep in mind that the device ID used in PASN might actually be used again when the STA tries to associate and it might be nice to not let a 3rd party know that it's the same guy. But I am interested
in seeing your "simpler 'PASN ID'" proposal. One general comment on your text, I think you need to be consistent on what it is called, “opaque device identifier” or “encrypted device ID” etc. It seems to vary. I removed mention of "opaque device identifier" in my submission. Everything should be "encrypted device ID" now. Of course, I might have missed something and if that's the case please let me know. Thanks and best of luck. Unfortunately I will not be there in person in Panama, so I will not be roaming the halls bothering you :>) That is a shame. I always look forward to being bothered by you (really, I do!). Oh well. Maybe next time…. regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius Graham From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hello, I've uploaded 11-24/0068r0 to mentor. It proposes to add deviceID to association frames for other-than-FILS to align it better with the capabilities of IRM. It addresses comments
from LB282. Please take a look and send comments to the list (or find me roaming the halls in Panama).
regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius 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 |