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.
There is no "frame" yet which is why it says "the data that would follow
the FILS session
element in an unencrypted frame". Since there is no frame there is no 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?
The cited text is saying that stuff that would follow the FILS session
element
in an unencrypted frame is passed to the AEAD algorithm. If this stuff
you're
bringing up would follow the FILS session element in an unencrypted frame
then
it would be passed to the AEAD algorithm; if it wouldn't then it isn't.
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.)
I am excited to see this.
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?
There is no "frame" yet which is why it says "the data that would follow
the FILS session
element in an unencrypted frame". Since there is no frame there is no FCS.
The cited text is saying that stuff that would follow the FILS session
element
in an unencrypted frame is passed to the AEAD algorithm. If this stuff
you're
bringing up would follow the FILS session element in an unencrypted frame
then
it would be passed to the AEAD algorithm; if it wouldn't then it isn't.
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?