22090216030000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文件下载.docx
《22090216030000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文件下载.docx》由会员分享,可在线阅读,更多相关《22090216030000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文件下载.docx(11页珍藏版)》请在冰豆网上搜索。
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–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)
FromCID356:
“TransmittingCPEMACaddressinR