22090216000000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文档格式.docx
《22090216000000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文档格式.docx》由会员分享,可在线阅读,更多相关《22090216000000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文档格式.docx(10页珍藏版)》请在冰豆网上搜索。
![22090216000000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文档格式.docx](https://file1.bdocx.com/fileroot1/2022-12/11/88e58f82-c3b9-4cbc-bc27-e01411886010/88e58f82-c3b9-4cbc-bc27-e014118860101.gif)
Company
Address
Phone
email
ApurvaMody
BAESystems
P.O.Box868,MER15-2350,Nashua,NH03061-0868
603-885-2621
404-819-0314
apurva.mody@,
apurva_mody@
TomKiernan
USArmy(CERDEC)
FtMonmouth,NJ
-
Thomas.kiernan@us.army.mil
RangaReddy
Ft.Monmouth,NJ
Ranga.reddy@us.army.mil
Abstract
ThisdocumentcontainstheproposedresolutionstocommentsrelatedtoSecurityin802.22Draftv2.0
Notice:
ThisdocumenthasbeenpreparedtoassistIEEE802.22.Itisofferedasabasisfordiscussionandisnotbindingonthecontributingindividual(s)ororganization(s).Thematerialinthisdocumentissubjecttochangeinformandcontentafterfurtherstudy.Thecontributor(s)reserve(s)therighttoadd,amendorwithdrawmaterialcontainedherein.
Release:
Thecontributorgrantsafree,irrevocablelicensetotheIEEEtoincorporatematerialcontainedinthiscontribution,andanymodificationsthereof,inthecreationofanIEEEStandardspublication;
tocopyrightintheIEEE’snameanyIEEEStandardspublicationeventhoughitmayincludeportionsofthiscontribution;
andattheIEEE’ssolediscretiontopermitotherstoreproduceinwholeorinparttheresultingIEEEStandardspublication.ThecontributoralsoacknowledgesandacceptsthatthiscontributionmaybemadepublicbyIEEE802.22.
PatentPolicyandProcedures:
ThecontributorisfamiliarwiththeIEEE802PatentPolicyandProcedures
<
http:
//standards.ieee.org/guides/bylaws/sb-bylaws.pdf>
includingthestatement"
IEEEstandardsmayincludetheknownuseofpatent(s),includingpatentapplications,providedtheIEEEreceivesassurancefromthepatentholderorapplicantwithrespecttopatentsessentialforcompliancewithbothmandatoryandoptionalportionsofthestandard."
EarlydisclosuretotheWorkingGroupofpatentinformationthatmightberelevanttothestandardisessentialtoreducethepossibilityfordelaysinthedevelopmentprocessandincreasethelikelihoodthatthedraftpublicationwillbeapprovedforpublication.PleasenotifytheChair<
CarlR.Stevenson>
asearlyaspossible,inwrittenorelectronicform,ifpatentedtechnology(ortechnologyunderpatentapplication)mightbeincorporatedintoadraftstandardbeingdevelopedwithintheIEEE802.22WorkingGroup.Ifyouhavequestions,contacttheIEEEPatentCommitteeAdministratorat<
patcom@ieee.org>
.
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
FromC