[STDS-802-11-TGM] Fwd: FW: [STDS-802-11] Now it's r13, was Re: [STDS-802

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

Adding the 802.11m reflector.

We've discussed this contribution multiple times during TGm sessions and I wanted to send the following to give an update on the latest changes. My intention is to present the latest version on behalf of Jouni and Dan in Hanoi and motion the text changes into the next version of the REVmd draft.

Cheers,

Mike

From: "Harkins, Daniel" <daniel.harkins@xxxxxxx>
Date: Monday, September 9, 2019 at 2:08 PM
To: Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>, "m.rison@xxxxxxxxxxx" <m.rison@xxxxxxxxxxx>, Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>
Cc: "Dorothy Stanley <dstanley1389@xxxxxxxxx> (dstanley1389@xxxxxxxxx)" <dstanley1389@xxxxxxxxx>, "mark.hamilton2152@xxxxxxxxx" <mark.hamilton2152@xxxxxxxxx>
Subject: Re: [STDS-802-11] Now it's r13, was Re: [STDS-802-11] Now it's r11, was: Re: [STDS-802-11] 11-19/1173r9-- mitigating side channel and timing attacks

Hi Mark,

First of all, thanks for your comments. The submission is better off as a result.

Jouni has touched on MR9 and I hope that explains the issue. The following comments deserve

discussion. If I’m not discussing that means it was accepted (and just because I’m discussing these

does not mean I didn’t accept them—see MR34 and MR35 for instance).

MR7 suggests making the phrase “direct hashing to element” refer to the FFE, but that’s not right.

The FFE is a field in a frame. The thing that’s hashed to, which is an element in a finite field, is never

transmitted in a frame. It’s the PWE, the PassWord Element. So I’m going to decline to incorporate

your suggested change. I know you feel that the overloaded term causes confusion but I’m hoping

that the way the term is used here is unlikely to cause (more) confusion.

MR8: yes that’s what’s intended. This AKM is for doing SAE or PMKSA caching.

MR19 and MR20: this is existing text in the standard, I’m just moving it. Yes, there are multiple string

conversion functions. Check out 12.4.7.2.

MR26 and MR50: it doesn’t matter. If it’s not signaled then you do this. If it’s signaled then it doesn’t matter

whether the signal says this feature is capable or mandatory.

MR34 and MR35: I’m assuming that PT should be italicized as well.

MR42: yes, that’s what it means.

MR45: I’m not sure what x<sub>1</sub> you are referring to. These are distinct variable names.

MR49: because those are functions that have to be implemented in constant time. The operations in this

function, which call those other functions, also have to be implemented in constant time.

MR51: because it’s not similar. The text is just wrong.

MR56: then the exchange will fail. But we’re talking about numbers that are larger than the number of

atoms in the universe. What if the atom selected at random from all the hundred thousand quadrillion

vigintillian atoms in the universe happens to be the one single special atom in the entire universe? We

don’t care because it’s not going to happen.

MR67: because the KCK will be Q which is the length of the digest produced by the hash function that

instantiates H() and the length of the salt is specified at the end of the paragraph.

I will be posting an r15 shortly that includes all these changes. Please take a look to make sure I have

accurately incorporated everything.

Regards,

Dan.

On 9/9/19, 4:19 AM, "Jouni Malinen" <jouni@xxxxxxxxxxxxxxxx> wrote:

Thanks. I leave it for Dan to merge in the editorials that he feels fine with (I went through them quickly and most looked okay to me). As far as the couple of technical items are concerned, the current contribution looked correct to me.

The changes to the Table 9-133 to remove hardcoded SHA-256 from one, but not the other column is correct (the new SAE design uses different hash algorithms internally, but that particular AKM 00-0F-AC:8 derives the PTK in the same manner using SHA-256-based KDF regardless of the hash algorithms used within SAE authentication.

The Rejected Groups element (9.4.2.244) uses same byte order as any other IEEE 802.11 element (i.e., little endian). There is a pending change to the current rev to explicitly state these are 16-bit integers (that and the byte order were already covered in another subclause, but the size should be in Clause 9). The “security being opposite” part applies really mainly (only?) to EAPOL frames (i.e., 802.1X) and EAP (i.e., IETF).

12.4.5.4 definition of KCK/salt length covers all the AKMs that use SAE. If a new AKM for SAE were to be added in the future, that AKM definition would need to cover changes to KCK/salt (and likely PMK/PTK for that matter).

- Jouni

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: 08 September 2019 18:37
To: Harkins, Daniel <daniel.harkins@xxxxxxx>; Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>; Michael Montemurro (mmontemurro@xxxxxxxxxxxxxx) (mmontemurro@xxxxxxxxxxxxxx) <mmontemurro@xxxxxxxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx> (dstanley1389@xxxxxxxxx) <dstanley1389@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: RE: [STDS-802-11] Now it's r13, was Re: [STDS-802-11] Now it's r11, was: Re: [STDS-802-11] 11-19/1173r9-- mitigating side channel and timing attacks

Hello,

I attach some comments, mostly editorial but some technical.

Thanks,

Mark

Mark RISON, Standards Architect, WLAN English/Esperanto/Français

Samsung Cambridge Solution Centre Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601

ROYAUME UNI WWW: http://www.samsung.com/uk

From: Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: 3 September 2019 20:46
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] Now it's r13, was Re: [STDS-802-11] Now it's r11, was: Re: [STDS-802-11] 11-19/1173r9-- mitigating side channel and timing attacks

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hello,

I have uploaded what I hope is the final version of 11-19/1173, now at r13. This includes a fix for

how “val” is generated to produce PWE from the PT element, some crypto-agility to make stronger

groups use stronger hash functions to do the calculations, and fixes to the test vectors. The test

vectors have now been validated by 2 independent implementations so counting mine that generated

them in the first place that means we have 3 independent implementations of this. A very nice

showing!

As usual, comments/concerns/etc please post them to the list.

Regards,

Dan.

On 8/20/19, 9:16 PM, "Harkins, Daniel" <daniel.harkins@xxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---

OK, make that r11. I received comments on r9 and r10 and have addressed them in r11. This

is the version I will be presenting tomorrow in the teleconference of the TGm ad hoc.

regards,

Dan.

On 8/17/19, 9:16 AM, "Harkins, Daniel" <daniel.harkins@xxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hello,

I received a couple comments regarding typos in 11-19/1173r9 and have not gotten any more

comments so I have uploaded r10 which only differs from r9 by corrected typos, the content is

exactly the same.

regards,

Dan.

On 8/2/19, 11:02 AM, "Harkins, Daniel" <daniel.harkins@xxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hello,

I have updated 11-19/1173 to do the "Simplified SWU" method of hashing to a curve. This supports

all the curves possible with SAE and is more efficient that the previous version. It can be implemented

in constant time which will mitigate the side channel and timing attacks described in the recent

"Dragonblood" paper. In addition, it mitigates a group downgrade attack (also described in that paper).

https://mentor.ieee.org/802.11/dcn/19/11-19-1173-09-000m-pwe-in-constant-time.docx

Please take a look. I have implemented this so I know it works. The question is, though, is this

specified in a clear enough way for others to implement.

regards,

Dan.

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1

[STDS-802-11-TGM] Fwd: FW: [STDS-802-11] Now it's r13, was Re: [STDS-802-11] Now it's r11, was: Re: [STDS-802-11] 11-19/1173r9-- mitigating side channel and timing attacks