Re: [STDS-802-11-TGAI] documents 15/164r0 and 15/165r0 uploaded (AEAD-related comments LB204)
On 1/15/15 8:29 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
>Hello Rene,
>
>Two points:
>
>1) "frame"
>
>>
>I do not understand how there could be unclarity re whether the FCS field
>is input to the crypto engine
>
>Because the wording says that it
>is, which is clearly wrong. Again, here it is:
>
>
>
>Note "in a [Š] frame". And here is what a "frame" is:
>
>
>
It's one thing to take a paragraph out of context. It's worse to take a
sentence out of context. It is even worse to take a a few words of a
sentence
out of context. But you're picking and choosing words from the sentence
(note
the ellipsis) and that is about as bad as it gets.
The comment is nonsense when the paragraph is read in full and it was
rightfully rejected.
>
>
>
>
>
>As you can see, like it or not, a "frame" includes an FCS at the end,
>and hence "data that would follow the FILS Session element in an
>unencrypted frame" includes an FCS.
>
>2) extent of AEAD processing
>
>>
>There is no inspection as to whether this is a vendor element, etc.,
>since the structure of the data strings is irrelevant from a crypto
>processing perspective.
>
>I agree. This is a different issue, specifically: why are all the
>elements
>after the FILS Session element -- including elements which are not related
>to FILS, such as vendor-specific elements -- included in the AEAD
>processing,
>while the elements before it are not included?
>
>I would have expected either all of the management frame body to be
>included
>in the AEAD processing, i.e. the bit shown as Frame Body in Figure 8-1,
>or only the FILS part, e.g. for Association Requests only this part and
>nothing after (or before):
What you would have expected is therefore incorrect.
Dan.
>
>
>
>Regards,
>
>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: Rene Struik [mailto:rstruik.ext@xxxxxxxxx]
>
>Sent: 15 January 2015 10:15
>To: Mark Rison; 'STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx'
>Subject: Re: [STDS-802-11-TGAI] documents 15/164r0 and 15/165r0 uploaded
>(AEAD-related comments LB204)
>
>
>
>Hi Mark:
>
>Some brief feedback on your comment CID #6786 (re what is input to AEAD
>processing for an outgoing frame). I don't think the suggested resolution
>requires changing. However, I thought it to be useful to provide some
>more detail here, in case this helps.
>
>One already has verbiage regarding AEAD ciphers used for ordinary frame
>processing in 802.11-2012 (see, e.g., Fig. 11-16 (frame lay-out), Fig.
>11-17 (CCM processing flow chart). Also there, I could not find any
>special mention re the FCS field. Moreover, the
> AEAD construct takes as input two data strings (data to be authenticated
>only, data to be authenticated and encrypted), where these can be any
>string. There is no inspection as to whether this is a vendor element,
>etc., since the structure of the data strings
> is irrelevant from a crypto processing perspective. The structure may be
>important *after* incoming crypto processing, but that is simply the same
>as if a frame was received unsecured.
>
>Once again, I do not understand how there could be unclarity re whether
>the FCS field is input to the crypto engine with outgoing processing.
>Suppose it were: then one has two possible scenarios:
>a) stick the same FCS field back in the now secured frame. In that case,
>FCS checks on a received frame will almost surely fail, so the frame will
>be dropped (success rate ~ 2^{-32} for 32-bit FCS field, assuming the
>ideal cipher model for AES).
>b) FCS is somehow computed prior to outgoing security processing (not
>sure how, since out of order), followed by recomputing the FCS field, but
>now over the secured frame, resulting in frame (a || {m || FCS0
>||MACtag}), where FCS0 is the original FCS0 field
> and where curly brackets indicate scrambling according to AEAD cipher.
>In that case, FCS checks on a received frame will succeed (in noise free
>channel), but now AEAD processing on receiving side will first run
>counter mode, yielding (a || m || FCS || MACtag),
> then authentication check will yield (a || m || FCS0), after which one
>now is stuck with the FCS0 field again (so would require stripping this
>after an additional FCS check perhaps?
>
>In either case, this seems to violate the order of outgoing processing
>(where FCS computation occurs last) and incoming processing (where FCS
>checking occurs first).
>
>Best regards, Rene
>
>
>On 1/14/2015 11:38 PM, Mark Rison 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.
>
>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 <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
><mailto: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
>>
>>_________________________________________________________________________
>>______
>
>
>
>
>
>
>-- email: rstruik.ext@xxxxxxxxx | Skype: rstruikcell: +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
><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
_______________________________________________________________________________