//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
Comment:
WhyaretheCBPbursttobeprotected.Aren'ttheybroadcastpacketsbydefinitionforinter-cellcoexistenceamongdifferentWRANcells.Ifthesecellsbelongtothesamenetworkthatneedsprotection,everythingcouldbedoneoverthebackhaul.
SuggestedRemedy:
ReconsidertheneedforsecurityontheCBPburstssinceanyWRANoperatorwillneedtoknowhowtodecodeittoactuponitandthereforewillbeabletomesswithitandchangethetextaccordingly.
Resolution(ascurrentlydiscussed):
ProblemisfrommalicioususerscreatingfalseCBPbursts.SinceanyWRANoperatorwillneedtoknowhowtodecodetheseCBPburststoactuponit,theywillthereforebeableto'messwithit'.WhatistheneedforsecuringtheseCBPburststhen?
Also,theburstsgivingidentityaspertheFCCR&Owouldneedtobeintheclear.Assignedtothesecurityad-hocgroupforresolution.
InitialFeedbackfromSecurityAdhoc:
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.
Now,havingdescribedtheprocedurethatiscurrentlyimplemented,letusdescribesomeoftheotherwaysthaterrorscanbedetectedinpackettransmissionsandprovidesomereasoningastowhythesecurityad-hocchoseits’currentapproach:
1.CyclicRedundancyCheck(CRC)isanon-securemethodtocreateanerror-detectingcode,wherebythedataisdividedbyaknownpolynomial,generatesaCRCvaluethatwouldbeappendedtoapacketduringtransmission.Uponreception,thereceivingnodere-calculatestheCRCvalue,andifthereisadifference,it’sassumedthereissomekindoferror,andthepacketwouldthenbediscarded.Theproblemis,thatdependingonthelength/typeofCRCpolynomial,itispossibletohackthedatainsuchawaythatwhentheCRCiscalculated,theCRCoutputwillbethesameasfortheunmodifieddatastream.IEEE802.3usesaspecificpolynomialthatis32bitslongandCRCvaluesthat32bits(4octets)long.
2.HashingalgorithmslikeMD5andSHA-1areusedtoprovidethesamecapabilityasaCRC,butthemathematicalformulaissupposedtobemoresecurethatasimpleCRC.Unfortunately,ithasbeenrecentlydiscovered,thatMD5andSHA-1stillhavea‘collision’vulnerability.Thismeansitispossibletohavetwodatasets/packetsthatgeneratethesameMD5/SHA-1hashvalue.Becauseofthis,NISTisdeprecatinguseofSHA-1inanyfederal(US)standards,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.
Wefeelthecertificateexchangeprocessshouldbekeptinthestandard.Ifitisengaged,itwouldbeonlybedonesoinfrequently,sotheimpactofusingitwouldbeminimal.Therearesomehigher-layerandnetworkissues(whicharehighlightedinSection7.6.8ofP802.22/D2)withusingthisapproachwhenanoperatorissettingupthisnetwork.TheseissueswouldhavetoeitherbeaddressedinTG2orwithinanindustryforum.
Nowhavingsaidallofthis,intheyearorso,sinceourmethodwasdeveloped,lotsofthingshavechanged.Thewirelessmicindustrydoesn’twanttomakeuseofTG1beacons.AlsotheFCCR&O’streatmentofmicrophonebeaconsmaychange.Ifthisiscase,thentheuseoftheatallTG1beaconisputintoquestionandjustificationofouruseoftheECCmethodinthebasestandard,becauseTG1isusingit,willhavetobere-evaluated.
Also,remember,useofCBPprotectionmechanismisoptional.Wedefineitinthebasestandardtoallowforoperatorstoimplementastheyseefit.
Andletusnotforgettherequirementsforaccessingthedatabase.IfBS’s,andCPEsforthatmatter,requiretheirowncredentials,thenquitepossiblytheinfrastructureforgeneratinganddistributingthecertificatesmaybeinplace,sotheimpacttotheoperatorshouldbeminimized.
CommentStatus:
Securityad-hocsuggeststhatmembershipshouldre-reviewtheCBPprotectionmechanismforsecurityissues,anddeferthiscommentuntilwehaveaclearerpictureregardingtherequirementsasstatedintheR&O.
Comment356,361,473,474,505,506,508,509
Comment:
FromC