| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Dan, Thanks for the comments, see my response inline. Thanks Best Regards Jay Yang From: Harkins, Dan <daniel.harkins@xxxxxxx> I don't think I would characterize RRCM as simple. It's got quite a bit of extraneous stuff in it. Like the 128 bit seed which appears to be completely unnecessary. A 256-bit key and an HMAC-based KDF to produce a MAC address? That's
overkill. à<Jay>Agree with you, the equation in the proposed text is to provide a possible solution, not the final one. If you have a better equation, we can accommodate
it into the proposed text. I am sorry that I missed the straw polls on the last call (I was double booked and had to attend the other teleconference) but I definitely would not have voted for either of the RRCM variants. As an AP vendor I certainly would not like
to be told to generate and store umpteen MAC addresses for each of the multitude of STAs that are associated to me. No thanks. à<Jay> In my mind, there are two approaches for the MAC address generated, one is the statically generated—all the MAC addresses are generated and stored
in the 4HS. Another is the dynamically generated, as you suggest in the previous offline discussion. In order to make it simple, we adopt statically solution in current proposed text. We can switch to dynamically solution in next round, in which both sides
only keep two MAC addresses in the memory, e.g. Once the MAC address is used, generate a new one and drop the old one. Based on the above two possible refining direction, there will be
NO parameter except the KDE header delivered in RRCM approach in the 4-way handshake. I've been questioning the attraction of any 11bh solution for a STA vendor (and I still feel that way) but if RRCM is the 11bh solution then I would also question the attraction for AP vendors as well. We would likely produce a standard
that no one wants to implement. à<Jay> I admit the current proposed text provides a roughly solution, and we can refine it in next around. hope the above explanation can address you
concern. 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 On 2/15/23, 5:27 PM, "Zhijie Yang (NSB)" <zhijie.yang@xxxxxxxxxxxxxxx> wrote: 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?”
·
IRMA - 6
·
RRCM - 13
·
e-RRCM - 14 I propose that we either:
1)
Run one more Straw Poll, between RRCM and e-RRCM OR
2)
Request the authors of two contributions (RRCM and e-RRCM) to choose one to bring forward and/or combine them into one. (There is obviously a lot of overlap/similarity between the two.) 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 |