CID Page Line Comment Proposed Change Resolution Status clause # 101 9a.3.2 40 It is better to specify that Specify that the Revised the padding octets in the padding octets in subframes and HCS for the subframes and See the proposed the frame header are not HCS for the frame change in included in the GCM header are not input for clarity. included in the GCM input CID r01-81: Proposed Text (based on 802.15.3e D05) Change 9a.3.2 of 802.15.3e D05 as follows: 9a.3.2 Symmetric cryptographic operations…. …. (Page 101, line 40) The data input to GCM for each subframe shall be taken in the order it is received in the frame, omitting the FCS Integrity Code in the subframe. CID r01-82 CID Page Line Comment Proposed Change Resolution Status # 101 9a.3.2 65 Since multi-protocol data Add description on Revised frame is used in 15.3e, it GCM input for is better to add secure See the proposed description on GCM data frame change in input for multi-protocol in this sub-clause. data frame for clarity. CID r01-82: Proposed Text (based on 802.15.3e D05) Add followings at the end of 9a.3.2 of 802.15.3e D05: 9a.3.2 Symmetric cryptographic operations…. …. (add at the end of the clause) Figure 9a-x specifies the length information and data to the GCM operation for Secure Multi-Protocol Data frames. The GCM operation is applied to each subframe in the data frame separately. For the first subframe, the Auth Data Length 1, which is the Auth Data Length for the first subframe, shall be set to 22 which is the l1(a), length of the Frame Header, SECID, SFC, and the MAC Subheader of the first subframe, and the Enc Data Length 1, which is the Enc Data Length for the first subframe, shall be set to the sum of the lengths of the Data ID l1 (p), field, Data Header field, and Data Payload field in the first subframe.
CID Page Line # Comment Proposed Change Resolution Status 101 9a.3.2 40 It is better to specify that the padding octets in the subframes and HCS for the frame header are not included in the GCM input for clarity. Specify that the padding octets in the subframes and HCS for the frame header are not included in the GCM input Revised See the proposed change in CID r01-81: Proposed Text (based on 802.15.3e D05) Change 9a.3.2 of 802.15.3e D05 as follows: 9a.3.2 Symmetric cryptographic operations…. …. (Page 101, line 40) The data input to GCM for each subframe shall be taken in the order it is received in the frame, omitting the FCS Integrity Code in the subframe. CID r01-82 CID Page Line # Comment Proposed Change Resolution Status 101 9a.3.2 65 Since multi-protocol data frame is used in 15.3e, it is better to add description on GCM input for multi-protocol data frame for clarity. Add description on GCM input for secure data frame in this sub-clause. Revised See the proposed change in CID r01-82: Proposed Text (based on 802.15.3e D05) Add followings at the end of clause 9a.3.2 of 802.15.3e D05: 9a.3.2 Symmetric cryptographic operations…. …. (add at the end of the clause) Figure 9a-x specifies the length information and data to the GCM operation for Secure Multi-Protocol Data frames. The GCM operation is applied to each subframe in the data frame separately. For the first subframe, the Auth Data Length 1, l1(a), which is the Auth Data Length for the first subframe, shall be set to 22 which is the length of the Frame Header, SECID, SFC, and the MAC Subheader of the first subframe, and the Enc Data Length 1, l1 (p), which is the Enc Data Length for the first subframe, shall be set to the sum of the lengths of the Data ID field, Data Header field, and Data Payload field in the first subframe.
15-16-0734-01-003e-sb-comment-resolution-on-security-in-clause-6-and-9.docx