Re: [STDS-802-11-TGAI] documents 15/164r0 and 15/165r0 uploaded (AEAD-related comments LB204)
On 1/14/15 8:38 PM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
>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?
>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?
Grotesque is in the eye of the beholder. This CID is somewhat grotesque.
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.
>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?
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.
>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.
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.
>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.
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.
Dan.
>
>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-resolu
>>tions-aead-
>><https://mentor.ieee.org/802.11/dcn/15/11-15-0165-00-00ai-suggested-resol
>>utions-aead-security-comments-lb204-xls.xlsx>
>> security-comments-lb204-xls.xlsx
>><https://mentor.ieee.org/802.11/dcn/15/11-15-0165-00-00ai-suggested-resol
>>utions-aead-security-comments-lb204-xls.xlsx>
>>
>>
>>https://mentor.ieee.org/802.11/dcn/15/11-15-0164-00-00ai-suggested-resolu
>>tions-aead-
>><https://mentor.ieee.org/802.11/dcn/15/11-15-0164-00-00ai-suggested-resol
>>utions-aead-security-comments-lb204-text.docx>
>> security-comments-lb204-text.docx
>><https://mentor.ieee.org/802.11/dcn/15/11-15-0164-00-00ai-suggested-resol
>>utions-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
><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
><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
_______________________________________________________________________________