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

Re: [STDS-802-11-TGAI] documents 15/164r0 and 15/165r0 uploaded (AEAD-related comments LB204)



Hello Rene,

 

Thanks for these resolutions.  Here are some comments on the spreadsheet

(it looks big, but in fact there is a lot of duplication):

 

CID

Page

Line

Clause

Comment

Proposed Change

Resolution

mgr Notes

6786

122.00

9

11.11.2.4.2

"The plaintext passed to the AEAD encryption algorithm is the data that would follow the FILS session element in an unencrypted frame." -- huh?  That data would be some other element (or perhaps the FCS, if there are no more elements).  What is intended here?

Reword using specifics rather than hypotheticals

Reject. See also CID #6790. The data to be encrypted and authenticated is the data that would be part of the unsecured frame at this stage of outgoing processing and frame formation, i.e., before adding a FCS check, etc. Not sure what is wrong here. Obviously, the FCS is the error detection check sum computed over the frame that would otherwise be ready for sending (i.e., is computed over the frame as final step). Unsecuring an incoming frame is contingent on the frame passing a check on the frame check sequence (FCS field), after which this FCS is further discarded. Similarly, securing an outgoing frame preceeds calculation of the FCS field. In either case, the FCS field is not part of the data to be authenticated and/or secured (and technically cannot be).

Subclause 8.2.1 says that a "frame" consists of a MAC header, a frame body and an FCS.

The cited text says "data that would follow a given element in a frame" is passed to AEAD.

Per the definition just given, this means that the stuff passed to AEAD *does* include an FCS.

Let's ignore this problem for now.  This still leaves the following problem:

The frames in which a FILS Session element appears are Auth and (Re)Assoc Req/Rsp.

For example, in the Assoc Req, the FILS Session element is (potentially) followed by FILS Public Key, FILS Key Confirmation, FILS HLP Container, FILS IP Address Assignment and vendor-specific elements.

Is the cited text saying that all these elements are passed to AEAD if present?  Including the VS elements?

Further consider what happens when in the future some other amendment puts another element after the FILS IP Address Assignment element.

Is the cited text saying that this too will be passed to AEAD?

6678

122.00

60

11.11.2.4.2

"the STA and AP shall irretrievably destroy the temporary keys" -- what are "the temporary keys"

List the keys which are irretrievably obliterated

Revised. Editorial note: Not sure whether we need to list these keys here explicitly, since Clause 11.11.2.3.1 already mentions (Draft D3.1, p. 128, l. 52-53) that the shared keys rMSK and/or ss are to be irretrievably destroyed, as part of key derivation. So, the current phrasing seems to be more a reminder of things already mentioned before. In any event, the term temporal keys refers to all non-persistent secret keying material that is created by executing the key establishment with FILS shared key authentication scheme (11.11.2.2.1) or the key establishment with FILS public key authentication scheme (11.11.2.2.2).

OK, so what changes will be made to the draft to address the comment?

6684

120.00

20

11.11.2.4.1

"If the AEAD cipher mode requires an AEAD counter, the AP implicitly uses the STA's initial AEAD counter of all zeros to decrypt and verify the received frame." -- if you can just use an implicit counter why bother maintaining actual counters?

Clarify

Accept. See also CID #6685. Not sure whether a textual change is required. However, the idea here is that the STA and AP have to instantiate the AEAD cipher, which requires as one of its input parameters a nonce. Here, STA takes nonces starting at the all-zero string, whereas the AP uses nonces starting at the integer 2103, where both increment nonces (by one at a time) in their local state if used more than once. This way, nonces on either end (STA and AP) never clash, since the nonce space is partitioned according to the value of the leftmost bit hereof (set to 0 for STA; set to 1 for AP). Since the AP initially may never have seen the STA, the convention used here is that nonces start at minimum value according to rules indicated above and then simply increment according to local state information, upon reuse.

OK, so what changes will be made to the draft to address the comment?

(I am looking to see something which will explain the apparent inconsistency between maintaining an (incrementing) counter, and being told to always use zero as the value of the counter.)

6685

122.00

19

11.11.2.4.2

"If the AEAD cipher mode requires an AEAD counter, the STA implicitly uses the AP's initial AEAD counter of the value 128 followed by 12 octets of zero to decrypt and verify the received frame." -- if you can just an implicit counter why bother maintaining actual counters?

Clarify

Accept. Not sure whether a textual change is required. However, the idea here is that the STA and AP have to instantiate the AEAD cipher, which requires as one of its input parameters a nonce. Here, STA takes nonces starting at the all-zero string, whereas the AP uses nonces starting at the integer 2103, where both increment nonces (by one at a time) in their local state if used more than once. This way, nonces on either end (STA and AP) never clash, since the nonce space is partitioned according to the value of the leftmost bit hereof (set to 0 for STA; set to 1 for AP). Since the AP initially may never have seen the STA, the convention used here is that nonces start at minimum value according to rules indicated above and then simply increment according to local state information, upon reuse.

OK, so what changes will be made to the draft to address the comment?

(I am looking to see something which will explain the apparent inconsistency between maintaining an (incrementing) counter, and being told to always use 2**103 as the value of the counter.)

6624

 

 

 

There are 16 instances of "AEAD counter", but   Aren't there two, one for sending stuff to the peer, and one for checking stuff received from the peer?  Only two of the 16 instances are "peer's AEAD counter" and the rest are vague

Add some words to indicate which AEAD counter is being used in the 14 vague instances

Reject. It is very hard to act on a comment that seems to be based on a global text string search. It would help if the commenter could give a specific instance where the context of the AEAD counter value is indeed unclear. Right now, it seems that references in the key confirmation section (11.11.2.4) are all unambiguous. Disposition of this comment could change if evidence regarding obvious ambiguities is presented to the group.

The very first instance is "the AEAD counter from the PTKSA".  If there are two counters in the PTKSA, then this is not specific enough, plainly.

Similarly for the second: "FILS requires an additional element: a 13 octet AEAD counter to be part of the newly created PTKSA. The STA shall set the AEAD counter to 13 octets of zero".  No, it does not need a (one) counter, it needs two counters, one initialised to 0 and the other to 2**103.

Etc.  In an email to the reflector a long time ago I attempted to provide fixes, but that email was ignored.  Perhaps it's time to look at it now.

6785

120.00

10

11.11.2.4.1

"The plaintext passed to the AEAD encryption algorithm is the data that would follow the FILS session element in an unencrypted frame." -- huh?  That data would be some other element (or perhaps the FCS, if there are no more elements).  What is intended here?

Reword using specifics rather than hypotheticals

Reject. See also CID #6786. The data to be encrypted and authenticated is the data that would be part of the unsecured frame at this stage of outgoing processing and frame formation, i.e., before adding a FCS check, etc. Not sure what is wrong here. Obviously, the FCS is the error detection check sum computed over the frame that would otherwise be ready for sending (i.e., is computed over the frame as final step). Unsecuring an incoming frame is contingent on the frame passing a check on the frame check sequence (FCS field), after which this FCS is further discarded. Similarly, securing an outgoing frame preceeds calculation of the FCS field. In either case, the FCS field is not part of the data to be authenticated and/or secured (and technically cannot be).

Subclause 8.2.1 says that a "frame" consists of a MAC header, a frame body and an FCS.

The cited text says "data that would follow a given element in a frame" is passed to AEAD.

Per the definition just given, this means that the stuff passed to AEAD *does* include an FCS.

Let's ignore this problem for now.  This still leaves the following problem:

The frames in which a FILS Session element appears are Auth and (Re)Assoc Req/Rsp.

For example, in the Assoc Req, the FILS Session element is (potentially) followed by FILS Public Key, FILS Key Confirmation, FILS HLP Container, FILS IP Address Assignment and vendor-specific elements.

Is the cited text saying that all these elements are passed to AEAD if present?  Including the VS elements?

Further consider what happens when in the future some other amendment puts another element after the FILS IP Address Assignment element.

Is the cited text saying that this too will be passed to AEAD?

6805

122.00

2

11.11.2.4.2

"GTK rekeying shall be performed as described in 11.6.7 (Group Key Handshake)." -- what about PTK rekeying

Add some information about PTK rekeying under FILS

Reject. FILS does not use the pairwise key hierarchy of 11.6.1.3 directly; if uses a key derivation function to produce the keys TK, KCK, KEK, without first deriving a PTK.

So how is PTK rekeying (by which I mean generating a new TK, the KCK and KEK merely being required steps in establishing a TK) performed when FILS has been used to establish the initial TK?

6787

120.00

13

11.11.2.4.1

"The ciphertext output by the AEAD algorithm becomes the data that follows the FILS session element in the encrypted and authenticated Association Request frame."  Does this mean that the Association Request MMPDU is encrypted, then the AEAD cipher output is spliced into this at the octet position after the FILS session element?  This sounds a bit grotesque.  And what happens to the FCS at the end of the frame (= MPDU)?

Clarify

Reject. See also CID #6788. The data to be encrypted and authenticated is the data that would be part of the unsecured frame at this stage of outgoing processing and frame formation, i.e., before adding a FCS check, etc. Not sure what is wrong here. Obviously, the FCS is the error detection check sum computed over the frame that would otherwise be ready for sending (i.e., is computed over the frame as final step). Unsecuring an incoming frame is contingent on the frame passing a check on the frame check sequence (FCS field), after which this FCS is further discarded. Similarly, securing an outgoing frame preceeds calculation of the FCS field. In either case, the FCS field is not part of the data to be authenticated and/or secured (and technically cannot be).

Subclause 8.2.1 says that a "frame" consists of a MAC header, a frame body and an FCS.

The cited text says "data that follows a given element in a frame" is passed to AEAD.

Per the definition just given, this means that the stuff passed to AEAD *does* include an FCS.

Let's ignore this problem for now.  This still leaves the following problem:

The frames in which a FILS Session element appears are Auth and (Re)Assoc Req/Rsp.

For example, in the Assoc Req, the FILS Session element is (potentially) followed by FILS Public Key, FILS Key Confirmation, FILS HLP Container, FILS IP Address Assignment and vendor-specific elements.

Is the cited text saying that all these elements are passed to AEAD if present?  Including the VS elements?

Further consider what happens when in the future some other amendment puts another element after the FILS IP Address Assignment element.

Is the cited text saying that this too will be passed to AEAD?

6788

122.00

11

11.11.2.4.2

"The ciphertext output by the AEAD algorithm becomes the data that follows the FILS session element in the encrypted and authenticated Association Response frame."  Does this mean that the Association Response MMPDU is encrypted, then the AEAD cipher output is spliced into this at the octet position after the FILS session element?  This sounds a bit grotesque.  And what happens to the FCS at the end of the frame (= MPDU)?

Clarify

Reject. See also CID #6790. The data to be encrypted and authenticated is the data that would be part of the unsecured frame at this stage of outgoing processing and frame formation, i.e., before adding a FCS check, etc. Not sure what is wrong here. Obviously, the FCS is the error detection check sum computed over the frame that would otherwise be ready for sending (i.e., is computed over the frame as final step). Unsecuring an incoming frame is contingent on the frame passing a check on the frame check sequence (FCS field), after which this FCS is further discarded. Similarly, securing an outgoing frame preceeds calculation of the FCS field. In either case, the FCS field is not part of the data to be authenticated and/or secured (and technically cannot be).

Subclause 8.2.1 says that a "frame" consists of a MAC header, a frame body and an FCS.

The cited text says "data that follows a given element in a frame" is passed to AEAD.

Per the definition just given, this means that the stuff passed to AEAD *does* include an FCS.

Let's ignore this problem for now.  This still leaves the following problem:

The frames in which a FILS Session element appears are Auth and (Re)Assoc Req/Rsp.

For example, in the Assoc Req, the FILS Session element is (potentially) followed by FILS Public Key, FILS Key Confirmation, FILS HLP Container, FILS IP Address Assignment and vendor-specific elements.

Is the cited text saying that all these elements are passed to AEAD if present?  Including the VS elements?

Further consider what happens when in the future some other amendment puts another element after the FILS IP Address Assignment element.

Is the cited text saying that this too will be passed to AEAD?

6789

120.00

25

11.11.2.4.1

"the returned plaintext replaces the ciphertext as portion of the frame that follows the FILS session element" -- hm, including the FCS?

Clarify (saying MMPDU rather than frame may help)

Reject. See also CID #6790. Unsecuring an incoming frame is contingent on the frame passing a check on the frame check sequence (FCS field), after which this FCS is further discarded. Similarly, securing an outgoing frame preceeds calculation of the FCS field. In either case, the FCS field is not part of the data to be authenticated and/or secured (and technically cannot be).

Subclause 8.2.1 says that a "frame" consists of a MAC header, a frame body and an FCS.

The cited text says the "portion of the frame that follows a given element" is replaced.

Per the definition just given, this means that FCS is replaced.

As suggested, saying MMPDU rather than frame helps, because an MMPDU does not include an FCS.

6790

122.00

25

11.11.2.4.2

"the output plaintext replaces the ciphertext as portion of the frame that follows the FILS session element" -- hm, including the FCS?

Clarify (saying MMPDU rather than frame may help); also change "output" to "returned" to match the previous subclause

Reject. Unsecuring an incoming frame is contingent on the frame passing a check on the frame check sequence (FCS field), after which this FCS is further discarded. Similarly, securing an outgoing frame preceeds calculation of the FCS field. In either case, the FCS field is not part of the data to be authenticated and/or secured (and technically cannot be).

Subclause 8.2.1 says that a "frame" consists of a MAC header, a frame body and an FCS.

The cited text says the "portion of the frame that follows a given element" is replaced.

Per the definition just given, this means that FCS is replaced.

As suggested, saying MMPDU rather than frame helps, because an MMPDU does not include an FCS.

 

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

 

 

> -----Original Message-----

> From: *** 802.11 TGai - Fast Initial Link Set-Up *** [mailto:STDS-802-11-TGAI@xxxxxxxx] On

> Behalf Of Rene Struik

> Sent: 14 January 2015 15:04

> To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx

> Subject: [STDS-802-11-TGAI] documents 15/164r0 and 15/165r0 uploaded (AEAD-related

> comments LB204)

>

> Dear colleagues:

>

> Please find below the weblinks to my uploaded comment resolutions. With

> the excel sheet, I simply filled the tab labelled with my name.

>

> Accepted comments are indicated in green; rejected comments in yellow

> (Word document), resp. red/purple (Excel sheet). {Color pick depending

> on visibility of text with colored background.}

>

> Success. Everything should be self-explanatory, but in case of questions

> simply ping me.

>

> Best regards, Rene

>

> Weblinks to uploaded documents:

> https://mentor.ieee.org/802.11/dcn/15/11-15-0165-00-00ai-suggested-resolutions-aead-

> security-comments-lb204-xls.xlsx

>

> https://mentor.ieee.org/802.11/dcn/15/11-15-0164-00-00ai-suggested-resolutions-aead-

> security-comments-lb204-text.docx

>

>

> --

> email: rstruik.ext@xxxxxxxxx | Skype: rstruik

> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

>

> _______________________________________________________________________________

>

> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this

> CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

>

> SELF SERVICE OPTION:

> Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and

> then amend your subscription on the form provided.  If you require removal from the

> reflector

> press the LEAVE button.

>

> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html

> _______________________________________________________________________________

_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________