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