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

Re: [STDS-802-11-TGM] 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



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
As an update on this proposal, I wanted to summarize the open discussion topics based on the email discussion on this contribution (below):

1.     Issue with the use of the terminology related to the phrase “direct hashing to element”. In particular the use of terms “password element” and “finite field element”

2.     The text describing the “Auth type” for Suite selector value “8”. In particular, the removal of “with SHA-256” from the table for that value. From the email “I think something is needed for …8 to restrict the PMKSA caching case to SAE contexts.”

3.     Clarification on the behavior of peer STAs with respect to the setting of “SAE hash-to-element” in the RSN extended capabilities the setting of SAE_HASH_TO_ELEMENT for all possible use cases.

4.     The use of x1 and x2 in the descriptive text while x1 and x2 are used in equations later in the document.

5.     The use of the statement “All operations shall be done in constant time.” and how it applies to the algorithm in the sub-clause.

6.     Issues with the statement “The probability of PT taking the value 1 is negligible.”

7.     Interpretation of “When both SAE Commit messages indicated a status code of SAE_HASH_TO_ELEMENT a salt is passed to the KDF…”

8.  Confusion on the specified length of the KCK as stated in “When used with AKMs 00:0F:AC-8 or 00:0F:AC-9 and the direct hashing technique of PWE generation (see 12.4.4.2.3 and 12.4.4.3.3), the KCK shall be the length of the digest generated by H() and the PMK shall be 256 bits in length.”    


Furthermore, I'd like to confirm that there are 3 implementations based on this contribution and the test vectors in the Annex have been verified.


Cheers,

Mike


On Wed, Sep 11, 2019 at 6:10 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
Yet another update from a conversation off the reflector. 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Date: Tuesday, September 10, 2019 at 4:00 PM
To: "Harkins, Daniel" <daniel.harkins@xxxxxxx>, 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

 

Hello,

 

  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.

 

OK, then FFE sounds as if it's the right term after all.  "FFE" is not just

the name of a field, it's also an abbreviation for finite field element,

per Subclause 3.4.

 

  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.

 

If the wording is "SAE authentication or using PMKSA caching" then there will

be an ambiguity.  Specifically, if I want to use PMKSA caching with a KDF

using SHA-256, will I use …5 or will I use …8:

 

OUI

Suite Type

Auth type

Key mgmt type

Key derivn type

Auth alg num

00-0F-AC

5

Authentication

negotiated over IEEE

Std 802.1X or using

PMKSA caching as

defined in 12.6.10.3

(Cached PMKSAs and

RSNA key

management)

RSNA key management

as defined in 12.7 (Keys

and key distribution) or

using PMKSA caching

as defined in 12.6.10.3

(Cached PMKSAs and

RSNA key

management)

Defined in

12.7.1.6.2 (Key

derivation

function (KDF))

using SHA-256

0 (open)

00-0F-AC

8

SAE authentication

or using

PMKSA caching as

defined in 12.6.10.3

(Cached PMKSAs and

RSNA key

management)

RSNA key management

as defined in 12.7 (Keys

and key distribution),

PMKSA caching as

defined in 12.6.10.3

(Cached PMKSAs and

RSNA key

management) or

authenticated mesh

peering exchange as

defined in 14.5

(Authenticated mesh

peering exchange

(AMPE))

Defined in

12.7.1.6.2 (Key

derivation

function (KDF))

using SHA-256

3 (SAE) for SAE

Authentication

0 (open) for

PMKSA caching

 

The two will become indistinguishable, no?

 

I think something is needed for …8 to restrict the PMKSA caching case to SAE contexts.

 

  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.

 

The context is "data to octet string conversion functions".  So the "and back"s are irrelevant.

Are you saying the D2OS functions in the context of the CN function can be passed

either an integer or an FFE?  Is that what commit-scalar and COMMIT-ELEMENT

are, respectively?

 

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().

 

OK, thanks.

 

  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.

 

OK, so what if the AP sets the SAE hash-to-element bit in the Extended RSN Capabilities

field ("can do this") but then uses status code 0 (i.e. not SAE_HASH_TO_ELEMENT,

i.e. not "using SAE hash-to-element").  Shouldn't the STA too ignore the AP's

capability and focus on the fact that the AP doesn't want to actually use this

capability in this particular exchange?

 

BTW, additional nit: presumably this bit is reserved when transmitted by a non-AP STA

(since the description is "The AP…")?  This needs to be stated.

 

  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?

 

I can't, no (don't have the tools).  If the people who confirmed the annex info

can't confirm this table, I suggest it be deleted, since anyway people can use

the algorithm given to determine z for themselves, i.e. it's just duplication.

 

  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.

 

I don't mind whether the subscripts are desubscripted or the non-subscripts

are subscripted, but it needs to be consistent.

 

  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).

 

I don't follow this.  Are you drawing a distinction between an "operation"

and a "function"?  What do the last two sentences mean?

 

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.

 

OK, then we need belts and braces everywhere, with the additions shown:

 

  • p, a, and b are all defined in the domain parameter set for the curve.
  • z is a curve-specific parameter from Table 12-xyz
  • inverse(x) is calculated in constant time as x(p-2) modulo p
  • x is a quadratic residue if x((p-1)/2) modulo p is zero or one; this is determined in constant time
  • LSB(x) returns the least-significant-bit of x in constant time
  • 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.
  • +, -, *, /, modulo, sqrt, pow operate in constant time

 

  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.

 

Infinitesimal is more than just really really small.  It's infinitely small.

 

But how about saying "is to be neglected" rather than "is negligible"?

I'd like something to say what you should do rather than what you might do.

 

  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.

 

How does adding "that is a concatenation of the rejected groups" clarify

the matter?!

 

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.

 

I see.

 

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.

 

So why does the "default" salt have to be more than 2 octets long?

 

  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.

 

You said "the KCK will be Q which is the length of the digest produced by the hash function that

instantiates H()".  Jouni is saying that if we add a new AKM for SAE it will need

to cover changes in the KCK, i.e. it's not just equal to the length of digest.

 

  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=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