| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
“RRCM is a simple solution” Hmm…that’s quite a statement. I’m not sure everyone understands what it actually entails. Let me summarize it: Each time a STA associates it sends a
68 octet (yes, 68 octets!) in a KDE in msg 2/4. To generate these 68 octets, the STA needs to carry out 256 bit KDF calculations plus a 256 bit hash (Tag), plus a 128 bit hash for every MAC address it wants to generate (claim to fame is that can generate
a number of MAC addresses) The AP then uses the 68 octets to calculate the 256 hash (Tag) plus a 128 bit hash to determine each MAC address indicated. It then stores these derived MAC addresses for the next
time. Hopefully both STA and AP now have the same MAC addresses stored for next time. Next time a STA appears it uses one of these stored MAC Addresses. The AP looks down its list to see if it has this MAC address stored, and then it can recognized the STA. So
the STA associates and again needs to do all the calculations to generate a new set of MAC addresses and send the 68 octet KDE so the AP can again generate the same addresses to store for the next time. Is this efficient – NO, 68 octets in a KDE is not trivial. Note for example, that IRM does exactly the same thing using just 6 octets. Why give ‘instructions’ to the AP so it
can calculate the MAC addresses, when it is just as secure to simply send the address? Is this any more private – NO. Idea is that by generating more than one MAC address it could use them for probing. But TG has all but disregarded this as being needed (also MAAD
and IRM can simply generate 3 addresses for only 18 octets). Does this require significant work - YES, 3+ hash calculations on the STA and 2+ on the AP every time. “RCCM is a simple solution”? depends I guess on what you think “simple” means. Still I must be wrong as RRCM was clear ‘favorite’ in the Straw Polls, I just hope those supporters actually know how it works. Graham From: Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Mark, all, RRCM is a simple solution, while e-RRCM is a completely solution that can address all security concerns.
I can present 1079r8 including both RRCM and e-RRCM solution in next call, and then we make the final decision between them based on the group’s feedback. Thanks Best Regards Jay Yang From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
All, Since the last meeting ran right up to the end time, we left things with this last Straw Poll result: “Which of the following can you support in concept (perhaps after some technical clean-up) for inclusion into TGbh?”
I propose that we either:
OR
Then, I will claim that we have completed the down-select process, as it was defined at the start, (“Stop when there’s one left, or when a few (2-3?) have 75% support”). So, the next step is to see if there are any specific technical comments/clean-up needed on the [e-]RRCM proposal, and prepare to hold a motion to add it to the current draft. @Mutgan, Okan (NSB - CN/Shanghai), Jay
@Yang, Zhijie (NSB - CN/Shanghai): Would you please suggest which of the options above you would like to advance? @All, does anyone have specific technical comments ready/in mind for this/these proposals? How much time do we need to get this ready for inclusion into the Draft? Thanks. 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 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 |