//standards.ieee.org/guides/bylaws/sb-bylaws.pdf>,includingthestatement"IEEEstandardsmayincludetheknownuseofpatent（s）,includingpatentapplications,providedtheIEEEreceivesassurancefromthepatentholderorapplicantwithrespecttopatentsessentialforcompliancewithbothmandatoryandoptionalportionsofthestandard."EarlydisclosuretotheWorkingGroupofpatentinformationthatmightberelevanttothestandardisessentialtoreducethepossibilityfordelaysinthedevelopmentprocessandincreasethelikelihoodthatthedraftpublicationwillbeapprovedforpublication.PleasenotifytheChairasearlyaspossible,inwrittenorelectronicform,ifpatentedtechnology（ortechnologyunderpatentapplication）mightbeincorporatedintoadraftstandardbeingdevelopedwithintheIEEE802.22WorkingGroup.Ifyouhavequestions,contacttheIEEEPatentCommitteeAdministratorat.
Remainingsecuritycommentsthatneedtoberesolved:
298,356,361,1346,403,404,407,473,474,505,506,508,509
Comments298,356,361,1346,403,404,407wereassignedtotheSecurityad-hocbytheMACad-hoc.Comments473,474,505,506,508,509,511,512,523arerelatedtosecurityissues,andshouldbehandledbytheSecurityad-hocaswell.
Comments674,717,719,725,726,731,732arecommentsdeferredduringSecurityad-hoccalls.Discussiononthosecommentsareprovidedhere
Comment298–GeraldChouinard
Comment:
WhyaretheCBPbursttobeprotected.Aren'ttheybroadcastpacketsbydefinitionforinter-cellcoexistenceamongdifferentWRANcells.Ifthesecellsbelongtothesamenetworkthatneedsprotection,everythingcouldbedoneoverthebackhaul.
SuggestedRemedy:
ReconsidertheneedforsecurityontheCBPburstssinceanyWRANoperatorwillneedtoknowhowtodecodeittoactuponitandthereforewillbeabletomesswithitandchangethetextaccordingly.
Resolution（ascurrentlydiscussed）:
ProblemisfrommalicioususerscreatingfalseCBPbursts.SinceanyWRANoperatorwillneedtoknowhowtodecodetheseCBPburststoactuponit,theywillthereforebeableto'messwithit'.WhatistheneedforsecuringtheseCBPburststhen?
Also,theburstsgivingidentityaspertheFCCR&Owouldneedtobeintheclear.Assignedtothesecurityad-hocgroupforresolution.
InitialFeedbackfromSecurityAdhoc:
CurrentlytheCBPburstsaretransmittedintheclear.TheycontainasignatureattheendofthemessagetoensurethattheCBPburstisauthentic–thatis,ithasnotbeenmodified.Currently,theCBPburstauthentication（protection）isoptional.
ThedesiretoprotecttheCBPistokeepmalicioususers/operatorsfrompreventinglegitimateusers/operatorsfromusingavailablechannelandengagingincoexistenceoperations.Thecurrentprocedure（insummary）usesapublickeytosigntheCBPburst,thesignatureisthenaddedtotheCBPburstwhentransmitted.Uponreceptionoftheburst,thereceivingBSwouldusethekeyofthetransmittingBStoverifythesignature（e.g.authenticatethesignature）.Ifverificationfails,thentheCBPwouldhavetobedropped.
Signingofthedataburstinvolvesprocessingtheburstthroughsomemathematicalfunction,whosebehavioris“modulated”byaninputkey.Theburstdataitselfisnotmodifiedinanyway.So,usingsignaturesdoesn’thidethedata,likeencryptiondoes.ThismeansthattheburstisstillreadablebythereceivingBS.NowifthereceivingBSdoesn’thavethepublickeyofthetransmittingBSordoesn’tsupporttheCBPauthenticationviasignature,itobviouslycannotverifythesignature.Inthiscase,thereceivingBScanchoosetoeitherignorethesignatureandgoontoprocesstheCBP,orpossiblyexecuteacertificateexchangetogetthetransmittingBS’scertificatesoitcanproperlyverifyCBPburstsinthefuture.
Havingdescribedtheprocedurethatiscurrentlyimplemented,letusdescribesomeoftheotherwaysthaterrorscanbedetectedinpackettransmissionsandprovidesomereasoningastowhythesecurityad-hocchoseits’currentapproach:
1.CyclicRedundancyCheck（CRC）isanon-securemethodtocreateanerror-detectioncode,wherebythedataisdividedbyaknownpolynomial,itgeneratesaCRCvaluethatwouldbeappendedtoapacketduringtransmission.Uponreception,thereceivingnodere-calculatestheCRCvalue,andifthereisadifference,it’sassumedthereissomekindoferror,andthepacketwouldthenbediscarded.Theproblemis,thatdependingonthelength/typeofCRCpolynomial,itispossibletogeneratethedatainsuchawaythatwhentheCRCiscalculated,theCRCoutputwillbethesameasfortheunmodifieddatastream.IEEE802.3usesaspecificpolynomialthatis32bitslongandCRCvaluesthat32bits（4octets）long.
2.HashingalgorithmslikeMD5andSHA-1areusedtoprovidethesamecapabilityasaCRC,butthemathematicalformulaissupposedtobemoresecurethatasimpleCRC.Unfortunately,ithasbeenrecentlydiscovered,thatMD5andSHA-1stillhavea‘collision’vulnerability.Thismeansitispossibletohavetwodatasets/packetsthatgeneratethesameMD5/SHA-1hashvalue.Becauseofthis,NISTisdeprecatinguseofSHA-1,andsuggestingmovingontoSHA-2（SHAwith224,256,384,or512bitsignature/hash）foranyhash/signaturecalculations.SHA-2hashescanrangein28,32,48,64octets.
3.EvenifyouspecifySHA-2,usingahashalgorithmwithout‘modulating’withsomekeyisnotagoodapproach.ThatiswhatHMACisfor.HMACrequiresthatakeybeappliedtothehashingalgorithmtomakeitmoresecure.Butthisthenrequiresakeytobedistributed?
KnowingthatasimpleCRCorearlier-generationhashalgorithmwouldn’tbesufficient,thesecurityad-hocwentlookingforprotocolsthatwouldavoidsometheissuesthathavebeendescribed.ThatiswhytheTG1approachhasbeenadopted.Thesecurityad-hocdecidedthatitwouldbeagoodideatopursuethecurrentmethod,becausefromtheTG1perspective,thebasestandardwouldhavetoincludeECCcertificateidentificationcapabilitytoverifyTG1beaconstobecompatiblewiththeTG1standard.Ifthiswasthecase,thenwhynotadapttheTG1approach?
ThisapproachuseskeysfromanECCimplicitcertificatetosignTG1beacons.Itisascompactaspossible,whileprovidinganadequateamountofsecurity.Wehavemadesomeadaptationstothisprocess.WedonotusetheECCcertificatekeytosigntheCBPburstdirectlytosignthemessage,insteadweuseittoderiveakeytosigntheCBPburstwithGMAC（whichistheAES-GCMversionofHMAC）.Thesignatureofthisoutputisonly8octets,muchsmallerthanthesmallestSHA-2outputandsmallerthantheTG1beaconsignatureoutput.
Wefeelthecertificateexchangeprocessshouldbekeptinthe802.22standard.Ifitisutilized,itwouldbedonesoinfrequently,sotheimpactofusingitwouldbeminimal.
Incase,thewirelessmicindustrydoesn’twanttomakeuseofTG1beacons.AlsotheFCCR&O’streatmentofmicrophonebeaconsmaychange.Ifthisiscase,thentheuseoftheatallTG1beaconisputintoquestionandjustificationofouruseoftheECCmethodinthebasestandard,becauseTG1isusingit,willhavetobere-evaluated.
Also,CBPprotectionmechanismisoptional.Wedefineitinthebasestandardtoallowforoperatorstoimplementastheyseefit.
Also,ifBS’s,andCPEsforthatmatter,requiretheirowncredentials,thenquitepossiblytheinfrastructureforgeneratinganddistributingthecertificatesmaybeinplace,sotheimpacttotheoperatorshouldbeminimized.
FinalResolution
Securityad-hocsuggestswekeepthecurrentauthenticationmechanismforCBPasithasbeenspecifiedandre-reviewituntilaferwehaveaclearerpictureregardingtherequirementsasstatedintheDatabaseR&O.SothecurrentCommentshouldbeRejected.
Comment356,361,473,474,505,506,508,509（ThiswasdiscussedintheMACad-hocandWendongwouldliketobringthistothesystemsgroup）
Comment:
FromCID356:
“TransmittingCPEMACaddressinR
升级会员 