Re: [STDS-802-11-TGBH] Next steps for TGbh (Feb 21 and Feb 28 calls)

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi,

Thanks for the feedback. Here are my comments:

I think “simple” is the idea behind the RRCM solution: STA and AP generate the same RMA(s) (instead of sending the actual RMA(s) between each other). It can be generating one RMA or multiple RMAs.
This idea is like generating PMKID, where STA and AP generate the same PMKID (instead of sending the actual PMKID between each other).

- In RRCM, STA and AP use this formula to generate RMA(s):

RMAn = KDF-Hash-48(RMAK, "Next RMAs", seed || n),

Where

Seed (16 octets)- some random numbers for math purposes

n (2 octets) ? tells how many RMA(s) you want to generate, i.e. n=10 -> 10 RMA(s)

RMAK ? is a locally generated key at STA and AP

- In PMKID, STA and AP use this formula (depending on AKM) to generate PMKID:

PMKID = Truncate-128(HMAC-SHA-1/256/384 (PMK, “PMK Name” || AA || SPA)).

I do not seed any 68 octecs KDE, 256 bit hash (Tag), 128 bit hash for every MAC address.
All I see is sending seed (16 octets) and n (2 octets) between STA and AP so that STA and AP can generate one RMA (if n=1 is signaled) or multiple RMAs (if n!=1).
To be honest, we can even omit sending seed, and be left with just sending n (2 octets). Seed is just there for STA to control the RMA generation.
In other words, just sending n(2 octets), STA and AP can generate 2^16 RMA(s) locally. These generated RMA(s) can be stored and used freely between STA and AP.
Depending on the implementation, STA and AP may generate different RMAs (same procedure) or not (if all previous RMAs are not utilized) in each association.
e-RRCM’s core idea is the same as RRCM, i.e. STA and AP generate the same RMA(s) for STA. Only difference is that e-RRCM sends an additional IE in some management frames (e.g. auth & assoc) for verification/identification purposes. This adds complexity (another key generation, MIC generation etc.) a bit but more guarantees the security perspective (replay attack, fake AP/STA etc). Here, one side validates the other side (i.e. STA validates AP, AP validates STA) because IE is sent in request and response frames.
If bh does not want to address these security issues, it’s fine. But I guess people who want to implement these stuff might want to see these improvements too. This would increase the attractiveness of the solution.
One drawback might be the storage problem, because both schemes (RRCM/e-RRCM) rely on storing RMA(s) at STA and AP side. However, considering that MAC address is just 48 bits, even though one side (e.g.) stores 100 RMA(s) for an ESS, it is just 48*100=4800 bits. For 10 ESS, it is 4800*10 = 48kbits, which is really low considering today’s high storage capacities.

We can clarify some of these open points in further meetings if necessary.

Thanks!

BR,

Okan

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: 2023年2月16日 22:27
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Next steps for TGbh (Feb 21 and Feb 28 calls)

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>
Sent: Thursday, February 16, 2023 10:55 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Next steps for TGbh (Feb 21 and Feb 28 calls)

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>
Sent: Wednesday, February 15, 2023 6:27 PM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx; Okan Mutgan (NSB) <okan.mutgan@xxxxxxxxxxxxxxx>
Subject: RE: Next steps for TGbh (next call, Feb 21)

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>
Sent: 2023年2月16日 6:43
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx; Okan Mutgan (NSB) <okan.mutgan@xxxxxxxxxxxxxxx>; Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>
Subject: Next steps for TGbh (next call, Feb 21)

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:

Run one more Straw Poll, between RRCM and e-RRCM

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