| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
From: "Harkins, Daniel" <daniel.harkins@xxxxxxx>
Date: Tuesday, September 10, 2019 at 9:13 AM
To: Mark Rison <m.rison@xxxxxxxxxxx>, Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>, 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
Howdy,
On 9/10/19, 3:23 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
Hello,
Thanks for the prompt review.
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.
How about saying PWE rather than element, then?
Because we’re hashing to PT, which is an element in a finite field. The thing is, these terms are used in such
different ways I really don’t think, in practice, this causes confusion. Yes, it’s overloaded, yes that’s unfortunate.
MR8: yes that’s what’s intended. This AKM is for doing SAE or PMKSA caching.
But not any kind of PMKSA caching. Only the PMKSA caching with SAE, right?
Other AKMs are used for other forms of PMKSA caching:
…1 is for Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3
…3 is for FT authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3
…5 is for Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3
…9 is for FT authentication over SAE or using PMKSA caching as defined in 12.6.10.3
…10 is for APPeerKey Authentication with SHA-256 or using PMKSA caching as defined in 12.6.10.3
…11 is for Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3 using a Suite B compliant EAP method supporting SHA-256
…12 is for Authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3 using a Suite B compliant EAP method supporting SHA-384
…13 is for FT authentication negotiated over IEEE Std 802.1X or using PMKSA caching as defined in 12.6.10.3
…14 is for Key management over FILS using SHA-256 and AES-SIV-256, PMKSA caching, or authentication negotiated over IEEE Std 802.1X(#114)
…15 is for Key management over FILS using SHA-384 and AES-SIV-512, PMKSA caching, or authentication negotiated over IEEE Std 802.1X(#114)
…16 is for FT authentication over FILS with SHA-256 and AES-SIV-256, PMKSA caching, or authentication negotiated over IEEE Std 802.1X(#114)
…17 is for FT authentication over FILS with SHA-384 and AES-SIV-512, PMKSA caching, or authentication negotiated over IEEE Std 802.1X(#114)
So it seems to me that the wording for 8 needs to be something like
SAE authentication with SHA or using PMKSA caching as defined in 12.6.10.3 (Cached PMKSAs and RSNA key management)
to cover all the cases but not more.
Actually I think that would be comment bait. “Where is the definition of SHA?” being the obvious one. And just
saying “SHA” is actually ambiguous because it does cover more cases, like the case of what we started calling
“SHA1” that we used to just call “SHA”. There is nothing added to the sentence by saying “with SHA”, it only
conforms to an unwritten rule that all of these things say what hash algorithm they’re using. But that isn’t
really a rule and this particular AKM is now different, so it’s saying things differently.
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.
MR19: I can only see one data-to-octet-string conversion function in 12.4.7.2
(specifically in 12.4.7.2.2). Where is the other?
Well there’s integer-to-octet string and back and then there’s (here we go again!) element-to-octet string
and back.
MR20: Ah, is "Each invocation of CN() specifies the format of the counter." referring to
The send-confirm counter shall be encoded according to subclause 9.2.2 (Conventions). in 12.4.5.5
and The peer-send-confirm shall be encoded according to subclause 9.2.2 (Conventions). in 12.4.5.6?
Yes, those are the counters for CN().
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.
But what if it's signalled as "capable" but not "use/required"? Presumably
then it shouldn't be used, even though it is "signalled".
Of course it would be used. If the AP is saying “I can do this if you want” and the STA can do it then it does it
If the AP is saying “I insist on doing this” then the STA does it. If the STA can’t do it then it doesn’t connect.
MR34 and MR35: I’m assuming that PT should be italicized as well.
Yes, I guess so. The Editors can probably clarify what the rules are for
what gets italicised.
MR42: yes, that’s what it means.
OK. Has there been independent verification (as was done for the annex)
that the z values shown are correct?
I don’t know. But it would be nice to confirm them, I guess. Can you do that please?
MR45: I’m not sure what x<sub>1</sub> you are referring to. These are distinct variable names.
The ones here:
The SSWU method produces two values, x1, and x2, at least one of which will represent an abscissa of a point on the curve. If x1 is the abscissa then x1 becomes the x-coordinate otherwise x2 becomes the x-coordinate. The equation of the curve with the x-coordinate produces the square of the y-coordinate which is recovered by taking the square root. The two possible results of the square root are discriminated by checking its least significant bit with the least significant bit of u. The result is a point on the curve.
These are not the same x1 as in
gx1 = (x13 + a * x1 + b) modulo p
?
Ahh, OK. That’s from the discussion text. I’d rather get rid of the subs in the discussion and leave the
x1, x2 stuff in the standard. But I’m not sure whether that warrants a rev of the submission.
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.
Right, so every function needs to be implemented in constant time,
as stated in:
All operatioins shall be done in constant time.
so why do the following need to be called out?
· CSEL(x,y,z) operates in constant time and returns y if x is true and z otherwise.
· CEQ(x,y) operates in constant time and returns true if x equals y and false otherwise.
Because we’re specifying a bunch of operations. Those have to be done in constant time. As part of
those operations we’re specifying there are 2 new functions that have to be used and those, too,
need to be implemented in constant time. But the “All operations shall be done in constant time”
doesn’t bleed out to anything else. It doesn’t apply to anything outside of itself (and CSEL() and
CEQ() are not really part of itself).
It would be a failure of the standard if someone implemented the specified options in constant time
but used a CSEL() or CEQ() that was not. “But I’m technically following the letter of the standard!”
That’s what I want to ensure does not happen. Consider it the belt-and-suspenders approach to
normative language.
MR51: because it’s not similar. The text is just wrong.
Ah, OK!
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.
I see. How about "infinitesimal" instead of "negligible"?
Some things can be infinitesimal (really really small) but not be negligible (not worth considering). The
important thing here is that we are deciding not to consider that case.
MR67: because the KCK will be Q which is the length of the digest produced by the hash function that
instantiates H()
Ah, OK.
and the length of the salt is specified at the end of the paragraph.
Ah, I see. It's a bit confusing because "When both SAE Commit messages indicated a status code of SAE_HASH_TO_ELEMENT a salt is passed to the KDF"
suggests there is no salt if the status code was not that.
That’s because you lopped off the clarifying text from the rest of that sentence. It says that when both
Commit messages indicate SAE_HASH_TO_ELEMENT a salt is passed to the KDF that is a concatenation
of the rejected groups.
But what about other AKMs not with the direct hashing technique?
There aren’t any. And if we define some we will define their parameters. Or not. Maybe we’ll say new
AKMs must use direct hashing. This is not wrong, it works technically, and it is sufficiently extensible so
we’re not painting ourselves into a corner.
The original sentence "Use of other AKMs will require definition of the lengths of the salt, the KCK, and the PMK"
covered them, but the new one does not.
We’re covering the salt and KCK with this new way.
BTW, is it "safe" for the salt to be very short (e.g. just two octets,
being a single rejected group from one of the STAs)? I'm wondering
why the "default" salt has to have the length of the digest of the hash
function, if so.
Yes, it’s safe because it’s going to get hashed to the length of the digest before it gets used.
I will be posting an r15 shortly that includes all these changes. Please take a look to make sure I have
accurately incorporated everything.
If you could address the above first, that would be helpful.
Too late! But if you are satisfied with my explanations maybe we don’t need an r16.
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.
OK.
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).
OK.
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).
Hm, that's not what Dan is saying, I think (e.g. KCK is always length
of digest).
Yes, that is what I’m saying. This KCK is going to be used with CN() to generate an SAE Confirm frame. CN()
is instantiated with the hash algorithm from Table 12-abc. But for the 4way handshake, Table 12-8 still applies
for AKMs 00-08-AC:8,9 and that KCK is going to be used with AES-128-CMAC and it will be 128 bits.
Regards,
Dan.
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: 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 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 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 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=
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