//standards.ieee.org/guides/bylaws/sb-bylaws.pdf>,includingthestatement"IEEEstandardsmayincludetheknownuseofpatent（s）,includingpatentapplications,providedtheIEEEreceivesassurancefromthepatentholderorapplicantwithrespecttopatentsessentialforcompliancewithbothmandatoryandoptionalportionsofthestandard."EarlydisclosuretotheWorkingGroupofpatentinformationthatmightberelevanttothestandardisessentialtoreducethepossibilityfordelaysinthedevelopmentprocessandincreasethelikelihoodthatthedraftpublicationwillbeapprovedforpublication.PleasenotifytheChairasearlyaspossible,inwrittenorelectronicform,ifpatentedtechnology（ortechnologyunderpatentapplication）mightbeincorporatedintoadraftstandardbeingdevelopedwithintheIEEE802.22WorkingGroup.Ifyouhavequestions,contacttheIEEEPatentCommitteeAdministratorat.
SystemsIssuesRelatedtoSecurityin802.22
Comments673and674–ApurvaModyandThomasKiernan
Comment:
802.22shouldn'tmandatefactory-installedprivate/publickeypairs.Operatorsshouldbeabletoself-signtheirowncertificatesandinstallthemforCPEauthorization.
SuggestedRemedy:
Fortextline13-18onpg270,replaceallreferencesto"factory-installed"to"pre-installed".Addthefollowingsentencetotheendoftheparagraph:
"Pre-installedcertificatescouldbegenerated/installedbythemanufacturerortheycouldbe（self-signed）certificatescreatedbytheoperator."
Resolution（ascurrentlydiscussed）:
ThiswoulddependontheneedforthedatabaseservicetohaveclearcredentialsforeachCPE.ThedatabaseservicemaynotallowmodificationoftheCPEcredentials.
InitialFeedbackfromSecurityAdhoc:
Securityad-hochastoresolvecomment（s）regardingintroductionofEAPasthemeansforauthentication.EAPisaframeworkthatsupportsvariousEAPmethods.SomeEAPmethodsallowtheoperatortospecifytheirowncredential.Inthiscase,ifanoperatorwantedtousetheirowncredential,theycould.However,thedatabaseservicecouldforceuponoperators,theuseofaspecifictypeofcredentialfordatabaseaccess.
DowewanttohavetosupportmultiplecredentialsonaCPE,onefornetworkauthenticationandonefordatabaseaccessauthentication?
Ideally,theanswerwouldbeaNO,becausehavingtosupporttwocredentialsoverlycomplicatesthestandard.
WecouldusethecredentialthedatabaseserviceaccessrequiresforourownBStoCPEandCPEtoBSnetworkauthentication.Thiswouldsaveustheheadacheofhavingtomaintaintwocredentials.
Withrespecttothecomment,we（inthesecurityad-hoc）feelthatchanging“factory-installed”to“pre-installed”doesn’tchangeanythingorputsusintoapositiontoviolatethenewFCCrulingandthedatabaseinterfacerequirements.Theterm“pre”coversthescopeof“factory”,inbothcasesacredential（iecertificate）isinstalledintheCPEpriortooperation.Shouldthingschange,weshouldmarkissueforreviewduringthesponsorballotphase.
FinalResolution
DecidedduringtheNovember2009FacetoFaceMeeting
Securityad-hocrecommendstheparagraphinSection7.1.3.1shouldreadasfollows–
“AllCPEsusingRSAauthorizationshallhavepre-installedRSAprivate/publickeypairsorprovideamechanismtoinstallsuchkeys.PriortoAKexchange,aCPEshallhaveinstalledRSAkeys,asdescribedin7.2.3.2.AllCPEswithpre-installedRSAkeypairsshallalsohavepre-installedX.509certificates.”
Comment356,361,473,474,505,506,508,509（ThiswasdiscussedintheMACad-hocandWendongwouldliketobringthistothesystemsgroup）
Comment:
FromCID356:
“TransmittingCPEMACaddressinRNG-REQviolatestheuser'sprivacyandcanallowmaclicioususerstotrack/monitorandindividual'stransmissions.”
SuggestedRemedy:
Adoptrecommenndationsin22-09-0114-00-0000-privacy-concerns.doc
Resolution（ascurrentlydiscussed）:
MalicioususeofMACaddressinRNG-REQmessage.
InitialFeedbackfromSecurityAdhoc:
Generallythesecomments（356,361,473,474,505,506,508,509,687,688,710,712）dealwithasystemprivacyissuethathasbeendiscussedinthesecurityad-hoc.Doc#22-09/0114（orlatestrevision）proposestwoapproachesfortheensuringCPEprivacy.Thead-hocreviewedthisdocumentinthecontextofCID’s687,688,710,and712.Thead-hocdecidedthatApproach1in22-09/0114wasthebetterwaytogo.
Implementationofthecommentresolutionrequiresthefollowing:
1.additionofasectiontoClause7todescribeapproach1from22-09/0114
2.modificationofcertificateprofileinSection7.5toreplaceMACaddressincertificatedefinitionwithFCCIDandSerial#
3.ModificationstoIEsforRNG-REQ/RSP
4.Updatingsometextwithregardtonetworkentryprocedure
CommentStatus:
Securityad-hocthatacountertothosecommentsshouldbemadeandallofthemshouldbesupercededbytheresolutiontoeither687/688or710/712.
Deferthiscommentanddiscussfurtherinthetelecons.Invitealltheinterestedparties（e.g.IvanReede）
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,andifthere
升级会员 