22090216030000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文件下载.docx

1、CompanyAddressPhoneemailApurva ModyBAE SystemsP.O. Box 868, MER 15-2350, Nashua, NH 03061-0868603-885-2621404-819-0314apurva.mody, apurva_modyTom KiernanUS Army （CERDEC）Ft Monmouth, NJ-Thomas.kiernanus.army.milRanga ReddyFt. Monmouth, NJRanga.reddyus.army.milAbstractThis document contains the propos

2、ed resolutions to comments related to Security in 802.22 Draft v2.0 Notice: This document has been prepared to assist IEEE 802.22. It is offered as a basis for discussion and is not binding on the contributing individual（s） or organization（s）. The material in this document is subject to change in fo

3、rm and content after further study. The contributor（s） reserve（s） the right to add, amend or withdraw material contained herein.Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creati

4、on of an IEEE Standards publication; to copyright in the IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor al

5、so acknowledges and accepts that this contribution may be made public by IEEE 802.22.Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , including the statement IEEE standards may include the known use of patent（s）, including patent applications

6、, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard. Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to re

7、duce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology （or technology under patent application） might be in

8、corporated into a draft standard being developed within the IEEE 802.22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .Remaining security comments that need to be resolved:298, 356, 361, 1346, 403, 404, 407, 473, 474, 505, 506, 508, 509Comments 298, 356, 36

9、1, 1346, 403, 404, 407 were assigned to the Security ad-hoc by the MAC ad-hoc. Comments 473, 474, 505, 506, 508, 509, 511, 512, 523 are related to security issues, and should be handled by the Security ad-hoc as well.Comments 674, 717, 719, 725, 726, 731, 732 are comments deferred during Security ad

10、-hoc calls. Discussion on those comments are provided hereComment 298 Gerald ChouinardComment:Why are the CBP burst to be protected. Arent they broadcast packets by definition for inter-cell coexistence among different WRAN cells. If these cells belong to the same network that needs protection, ever

11、ything could be done over the backhaul.Suggested Remedy:Reconsider the need for security on the CBP bursts since any WRAN operator will need to know how to decode it to act upon it and therefore will be able to mess with it and change the text accordingly.Resolution （as currently discussed）:Problem

12、is from malicious users creating false CBP bursts. Since any WRAN operator will need to know how to decode these CBP bursts to act upon it, they will therefore be able to mess with it. What is the need for securing these CBP bursts then? Also, the bursts giving identity as per the FCC R&O would need

13、 to be in the clear. Assigned to the security ad-hoc group for resolution.Initial Feedback from Security Adhoc:Currently the CBP bursts are transmitted in the clear. They contain a signature at the end of the message to ensure that the CBP burst is authentic that is, it has not been modified. Curren

14、tly, the CBP burst authentication （protection） is optional. The desire to protect the CBP is to keep malicious users/operators from preventing legitimate users/operators from using available channel and engaging in coexistence operations. The current procedure （in summary） uses a public key to sign

15、the CBP burst, the signature is then added to the CBP burst when transmitted. Upon reception of the burst, the receiving BS would use the key of the transmitting BS to verify the signature （e.g. authenticate the signature）. If verification fails, then the CBP would have to be dropped. Signing of the

16、 data burst involves processing the burst through some mathematical function, whose behavior is “modulated” by an input key. The burst data itself is not modified in anyway. So, using signatures doesnt hide the data, like encryption does. This means that the burst is still readable by the receiving

17、BS. Now if the receiving BS doesnt have the public key of the transmitting BS or doesnt support the CBP authentication via signature, it obviously cannot verify the signature. In this case, the receiving BS can choose to either ignore the signature and go on to process the CBP, or possibly execute a

18、 certificate exchange to get the transmitting BSs certificate so it can properly verify CBP bursts in the future.Having described the procedure that is currently implemented, let us describe some of the other ways that errors can be detected in packet transmissions and provide some reasoning as to w

19、hy the security ad-hoc chose its current approach:1. Cyclic Redundancy Check （CRC） is a non-secure method to create an error-detection code, whereby the data is divided by a known polynomial, it generates a CRC value that would be appended to a packet during transmission. Upon reception, the receivi

20、ng node re-calculates the CRC value, and if there is a difference, its assumed there is some kind of error, and the packet would then be discarded. The problem is, that depending on the length/type of CRC polynomial, it is possible to generate the data in such a way that when the CRC is calculated,

21、the CRC output will be the same as for the unmodified data stream. IEEE 802.3 uses a specific polynomial that is 32 bits long and CRC values that 32bits （4 octets） long.2. Hashing algorithms like MD5 and SHA-1 are used to provide the same capability as a CRC, but the mathematical formula is supposed

22、 to be more secure that a simple CRC. Unfortunately, it has been recently discovered, that MD5 and SHA-1 still have a collision vulnerability. This means it is possible to have two data sets/packets that generate the same MD5/SHA-1 hash value. Because of this, NIST is deprecating use of SHA-1, and s

23、uggesting moving onto SHA-2 （SHA with 224, 256, 384, or 512 bit signature/hash） for any hash/signature calculations. SHA-2 hashes can range in 28, 32, 48, 64 octets.3. Even if you specify SHA-2, using a hash algorithm without modulating with some key is not a good approach. That is what HMAC is for.

24、 HMAC requires that a key be applied to the hashing algorithm to make it more secure. But this then requires a key to be distributed?Knowing that a simple CRC or earlier-generation hash algorithm wouldnt be sufficient, the security ad-hoc went looking for protocols that would avoid some the issues t

25、hat have been described. That is why the TG1 approach has been adopted. The security ad-hoc decided that it would be a good idea to pursue the current method, because from the TG1 perspective, the base standard would have to include ECC certificate identification capability to verify TG1 beacons to

26、be compatible with the TG1 standard. If this was the case, then why not adapt the TG1 approach?This approach uses keys from an ECC implicit certificate to sign TG1 beacons. It is as compact as possible, while providing an adequate amount of security. We have made some adaptations to this process. We

27、 do not use the ECC certificate key to sign the CBP burst directly to sign the message, instead we use it to derive a key to sign the CBP burst with GMAC （which is the AES-GCM version of HMAC）. The signature of this output is only 8 octets, much smaller than the smallest SHA-2 output and smaller tha

28、n the TG1 beacon signature output. We feel the certificate exchange process should be kept in the 802.22 standard. If it is utilized, it would be done so infrequently, so the impact of using it would be minimal. In case, the wireless mic industry doesnt want to make use of TG1 beacons. Also the FCC

29、R&Os treatment of microphone beacons may change. If this is case, then the use of the at all TG1 beacon is put into question and justification of our use of the ECC method in the base standard, because TG1 is using it, will have to be re-evaluated. Also, CBP protection mechanism is optional. We defi

30、ne it in the base standard to allow for operators to implement as they see fit. Also, if BSs, and CPEs for that matter, require their own credentials, then quite possibly the infrastructure for generating and distributing the certificates may be in place, so the impact to the operator should be mini

31、mized.Final ResolutionSecurity ad-hoc suggests we keep the current authentication mechanism for CBP as it has been specified and re-review it until afer we have a clearer picture regarding the requirements as stated in the Database R&O. So the current Comment should be Rejected. Comment 356, 361, 473, 474, 505, 506, 508, 509 （This was discussed in the MAC ad-hoc and Wendong would like to bring this to the systems group）From CID 356: “Transmitting CPE MAC address in R