| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi, Thanks for all comments on SP1154 on 6/23 teleconference. I summarized all comments (not exactly original words, with simplification) I ever received on this SP below, and provided
my responses/analysis.
Response/analysis: It is reasonable to assume most likely a non-AP AMP STA is a very simple device, implementing only one security solution. Security parameters negotiation
is not necessary in this scenario. On the other hand, different non-AP AMP STAs may implement different “one security solution” based on their uses, e, g., CCMP128 for low-cost devices or GCMP256 for government and enterprise devices. So we can define a small
set of security solutions in 11bp, let a non-AP AMP STA choose to implement one security solution based on its uses and indicate the security solution’s parameters in a STASecurityParameters field, and let an AMP AP implement all or as many security solutions
defined in 11bp as possible. As such, the security implementation on non-AP AMP STAs are simple (only one security solution needs to be implemented) and the security protocols are simple (no security parameters negotiation). The cost of requiring an AMP AP
to implement all or many security solutions defined in 11bp is very low, because the AMP AP can implement these solutions using SW, thanks to the very low 11bp data rates.
Response/analysis: it is possible that an AMP AP may not support one or some security solutions implemented by a non-AP AMP STA. For example, this can
happen between an AMP AP implemented based on current 11bp standard and a non-AP AMP STA based on a future 11bp standard revision that defines some new security solutions. In order to assure the security protocol can gracefully work between old and new 11bp
revisions, we can let an AMP AP include an APSecurityParameters field indicating all supported security solutions in the first downlink frame of a secure communication protocol. If a non-AP AMP STA only implements one security solution, it does not need to
look into APSecurityParameters; instead, it simply indicates the security solution’s parameters in STASecurityParameters to the AMP AP. If a non-AP AMP STA implements more than one security solutions, it needs to find a matched security solution based on APSecurityParameters.
If there are multiple matches, the non-AP AMP STA should choose the security solution with the highest security performance. In this case, the non-AP AMP STA should indicate the chosen security solution’s parameters in the STASecurityParamters field to the
AMP AP, with the received APSecurityParameters included in the MIC calculation in the first uplink frame of a secure communication protocol for the AMP AP to verify the non-AP AMP STA has received the correct APSecurityParameters.
Response/analysis: agree, and we should do the following to assure implementation simplicity: (1) keep the number of security solutions (security options)
defined in 11bp as small as possible, such as one CCMP128 solution, one GCMP256 solution, one reserved-for-future solution. (2) keep the security protocol as simple as possible by requiring a non-AP AMP STA implementing only one security solution to simply
indicate the security solution’s parameters in STASecurityParameters without looking into the received APSecurityParameters. Only non-AP AMP STAs implementing more than one security solution need to find a “best matched” security solution based on the received
APSecurityParameters field and include the received APSecurityParameters in MIC calculation. Since we have a deadline on SFD in July meeting, we can agree on the method proposed in SP1154 first, then addressing the actual security solution parameters later
(i.e., . Based on above comments and responses, I edited the SP1154 as follows, Do you agree to add the following text into the 11bp SFD? 802.11bp shall specify a MIC-protected security parameters indication method by including a STASecurityParameters field in the first AMP uplink frame
of all secure AMP communications protocols, such that a non-AP AMP STA can indicate its security solution’s parameters (cipher algorithm, MIC algorithm, key sizes, etc.) to an AMP AP for carrying out the secure communication protocol.
Please kindly let me know if you have any comments before the 6/30 teleconference. It is highly appreciated if you can suggest changed
SP text to address your comments in one shot. Thanks! Hui Luo Infineon Technologies To unsubscribe from the STDS-802-11-TGBP list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBP&A=1 |