22090216010000proposedresolutionstocommentsrelatedtosecurityin80222draftv20.docx
- 文档编号:10565577
- 上传时间:2023-02-21
- 格式:DOCX
- 页数:14
- 大小:37KB
22090216010000proposedresolutionstocommentsrelatedtosecurityin80222draftv20.docx
《22090216010000proposedresolutionstocommentsrelatedtosecurityin80222draftv20.docx》由会员分享,可在线阅读,更多相关《22090216010000proposedresolutionstocommentsrelatedtosecurityin80222draftv20.docx(14页珍藏版)》请在冰豆网上搜索。
22090216010000proposedresolutionstocommentsrelatedtosecurityin80222draftv20
IEEEP802.22
WirelessRANs
ProposedResolutionstoCommentsRelatedtoSecurityin802.22Draftv2.0
Date:
2009-11-13
Author(s):
Name
Company
Address
Phone
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
USArmy(CERDEC)
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
//standards.ieee.org/guides/bylaws/sb-bylaws.pdf>,includingthestatement"IEEEstandardsmayincludetheknownuseofpatent(s),includingpatentapplications,providedtheIEEEreceivesassurancefromthepatentholderorapplicantwithrespecttopatentsessentialforcompliancewithbothmandatoryandoptionalportionsofthestandard."EarlydisclosuretotheWorkingGroupofpatentinformationthatmightberelevanttothestandardisessentialtoreducethepossibilityfordelaysinthedevelopmentprocessandincreasethelikelihoodthatthedraftpublicationwillbeapprovedforpublication.PleasenotifytheChair 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 Comment: FromCID356: “TransmittingCPEMACaddressinRNG-REQviolatestheuser'sprivacyandcanallowmaclicioususerstotrack/monitorandindividua
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 22090216010000 proposedresolutionstocommentsrelatedtosecurityin80222draftv20
链接地址:https://www.bdocx.com/doc/10565577.html