| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Jay, My point is that if the STA is using a unique MAC address that it previously shared with the AP, using a secure KDE, why does it need to further verify itself?
If further ID is required, then also send the Device ID in the 4w HS. We have not considered “spoof STA” as a case needed to be solved in TGbh and have also rejected “spoof AP’ as needing to be solved. Graham From: Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Graham, Thanks for the comments. You know, in the previous call, some members brought up all kinds of security concern for pre-association schemes, but there is no such security concern on Device ID approach, in which the STA and AP can verify each other based on the MIC
carried in EAPOL-2 and EAPOL-3 frame, and the Device ID is encrypted in the KDE field. The purpose of e-RRCM solution is to provide the same security level as Device ID has. E.g. AP and STA can verify/authenticate each other based on the MIC in VIE element,
and the pairwise key is the identifier which inherits the spirit of RMK approach, while the generated MAC address as the key index is to help both side to find the pairwise key.
Hope the above explanation can address you concern, and welcome the further comments. Thanks Best Regards Jay Yang From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
e-RRCM is a scheme for the AP to validate the STA. The STA adds an IE (VIE) to its association request, for example, and the AP validates the VIE. The cases we have mostly talked about are spoof
APs not spoof STAs, i.e., the other way round, in that the STA wants to verify that the AP really is who he says he is. We did have a presentation on that (22/1219) but it was decided that TGbh should not be concerned with that scenario and it should be considered
within TGbi. I would maintain that similarly this “validation of the STA to an AP” also is a TGbi area. Having said that, why we need extra validation in addition to the identifiable MAC address is not obvious, but it is pretty clear that it is not TGbh
area. I would urge the RRCM contingent, to remove e-RRCM for TGbhh. Graham From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Thanks, Jay. My apologies if you feel I mischaracterized the RRCM vs e-RRCM difference. I will review the materials again, off-line, and make sure I fully understand. I take your comment to say that you suggest we do the final down-select Straw Poll, between the RRCM and e-RRCM proposals. OK, thanks. In the interest of fairness, per the comments last time about expanding on any of the proposal(s) description before running the follow-on Straw Polls to the initial one(s) last week, I would like
to be consistent in our Straw Polls, and continue our process without any further presentations/clarifications. So, I propose that we go straight back into the Straw Polls at the start of next call. (I’ll give a quick summary of what happened earlier this
week, for those on next week’s call that missed this week’s call, but nothing further in terms of background.) After the Straw Poll, we can then review 22/1079 (some rev), or 22/0888, whichever is felt to be most appropriate depending on the result of the Straw Poll, as part of the next step of
specific technical comments/clean-up on the proposal that will be motioned for inclusion in the Draft.
@All, I therefore propose that we plan for a motion on the Feb 28 teleconference, to pull in the material for either RRCM or e-RRCM into the Draft. I would like to have this motion
ahead of the F2F, so we can resolve our discussion about what to include in D1.0 before the F2F, and we can use the F2F to finalize D1.0 and get it ready for WG letter ballot. (There is other work we need to do, like the CAD, MIB, any definitions in clause
3, etc., to be ready for WG LB. We’ll need some time to finish up the draft.) Thanks. Mark 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 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 |