anagentanditsplatformiftheplatformistoprovidesecurecommunicationsservicestotheagentFinallyweconcludeandpointoutfutureworkinsectionVIIITheFIPAcommunicationmodelFigure1showstheFIPAmessagetransportre ID: 849581
Download Pdf The PPT/PDF document "SecuringFIPAagentcommunicationNiklasBors..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1 SecuringFIPAagentcommunicationNiklasBors
SecuringFIPAagentcommunicationNiklasBorseliusandChrisJ.MitchellInformationSecurityGroupRoyalHolloway,UniversityofLondonEgham,Surrey,TW200EX,UKfNiklas.Borselius,C.Mitchellg@rhul.ac.ukAbstract|Theagentparadigmhasbeenthesubjectofmuchresearchduringthelastdecade.Recently,securityofmulti-agentsystemshasgainedincreasedatten-tion.InthispaperweconsidertheFIPAagentcommunicationspeci cationsfromasecurityperspective,andoutlinehowsecu-rityfunctionalitycanbeadded.Keywords|security,multi-agentsystem,communication,FIPA.I.IntroductionFIPA1isanon-pro torganisationpromot-ingtheuseanddevelopmentofintelligentagentsbyopenlydevelopingspeci cationssupportinginteroperabilityamongagentsandagent-basedapplications.FIPA'sspeci ca-tionforagentcommunicationhasbecomeadefactostandard.SecurityhasnotbeenadrivingforceforresearchanddevelopmentofMulti-AgentSystems(MASs)andthere-forehasonlyreceivedlimitedattentionfromtheagentresearchcommunity.Although,anearlier,todayobsolete,FIPAspeci ca-tiondidconsidersecurityforagentcommu-nication[1],securityisnotfullycoveredinthecurrentspeci cations[2].ItappearsthattheFIPAspeci cationsandthegeneralstateofagentresearcharenowmatureenoughtorequiresecurityservicesforagentcommuni-cation.FIPAhasrecognisedtheneedforimprovedsecurityandinitiatedworkinthearea2.InthispaperwewillevaluatetheFIPAspeci cationsfromasecuritypointofview1FoundationforIntelligentPhysicalAgents,seehttp://www.fipa.org2Seehttp://www2.elec.qmul.ac.uk/~stefan/fipa-securityforthestateandprogressofthiswork.andproposeextensionstothespeci cationsinordertoprovidesecurityservicesforagentcommunication.Wewilladdressthefollowingsecurityservicesforagentmessagecommuni-cation:Integrity,protectsagainstimpropermod-i cationofamessage;Originauthentication,thecorroborationthatthesourceofdatareceivedisasclaimed;Con dentiality,guaranteesthatunautho-risedpartiescannotaccessinformationintransit.Nonrepudiation,whichcanbeconsideredastrongerversionoforiginauthentication,willnotbefurtheraddressedinthispaper.Nonrepudiation(ofdataoriginanddatare-ception)canbeachievedusingauthenticationmechanismsincombinationwithtimestampsandathirdpartytosettledisputes.Forthepurposeofthispaperweareas-sumingamulti-agentsysteminanopenen-vironment,thatis,asystemwherenosingleauthorityisincontrolofthesystem,whichmeansthatagents(andotherentities)cannotbeassumedtoactinaperfectlyhonestman-ner.WearealsoassumingasupportingPublicKeyInfrastructure(PKI)formanagementofcerti edcryptographicpublickeys.Thepre-ciserequirementsforaPKIforanopenmulti-agentsystemisaresearchtopiconitsown.Thepaperisstructuredasfollows.Inthenexttwosectionswebrie\rydescribetheFIPAagentcommunicationspeci cations, rstthecommunicationmodelandthenthemessagestructure.Se
2 ctionIVdescribestheOpenPGPmessageformata
ctionIVdescribestheOpenPGPmessageformatandhowthiscanbeap-pliedtoagentcommunication.InsectionVweconsidertherequiredinteractionbetween anagentanditsplatformiftheplatformistoprovidesecurecommunicationsservicestotheagent.Finally,weconcludeandpointoutfutureworkinsectionVI.II.TheFIPAcommunicationmodelFigure1showstheFIPAmessagetransportreferencemodel[2].Agent Platform\rMessage Transport\rService\rAgent\rAgent Platform\rMessage Transport\rService\rAgent\rMessage Transport Protocol\rFig.1.FIPAmessagetransportmodelThemessagetransportserviceisaservicetypicallyprovidedbytheagentplatformonwhichanagentisexecuting.Howevertheagentandthemessagetransportservicedonothavetobelocatedonthesamehost.Themessagetransportationservicesupportsthetransportationofmessagesbetweenagentsonanygivenagentplatformandbetweenagentsondi erentplatformsthroughtheprovisionofanAgentCommunicationChannel(ACC).FIPArecognisesthreeoptionsforanagentwhensendingamessagetoanotheragentre-sidingonaremoteplatform(illustratedin g-ure2).1.AgentAsendsthemessagetoitslocalACCusingaproprietaryorstandardinterface.TheACCthentakescareofthetransmissionofthemessagetothecorrectremoteACC.TheremoteACCwilltheneventuallydeliverthemessage.AgentAsendsthemessagedirectlytotheACContheremoteagentplatformonwhichBresides.ThisremoteACCthendeliversthemessagetoB.3.AgentAsendsthemessagedirectlytoagentB,usingadirectcommunicationmecha-nism.Themessagetransfer,includingbu er-ingofmessagesandanyerrormessages,mustbehandledbythesendingandreceivingagents.(Nofurtherspeci cationforthiscom-municationmodeiscoveredbyFIPA.)Agent Platform\rACC\rAgent A\rAgent Platform\rACC\rAgent B\r 3\r 1\r \r \r \r \r \r \r \r \r \r2\r1 & 2\r1\rFig.2.Methodsofcommunicationbetweenagentsondi erentplatformsIII.FIPAMessagestructureInthissectionwewilldescribethestructureofaFIPAmessage[2]andthenconsiderhowsecurityisaddressed.Amessageismadeupofamessageenve-lope,containingtransportinformation,andamessagebodycomprisingoftheagentcom-municationdataorACL(AgentCommunica-tionLanguage)message.TableIshowsthestructureofthemessageenvelope.AnACCshoulddeliverthewholemessage,includingthemessageenvelope,tothereceivingagent.However,itispossibleforagentplatformstoprovidemiddlewarelayerstofreeagentsfromthetaskofprocessingtheenvelope[2].Theenvelopeparametercalledencryptedisoptional,andifusedindicatesthatthemes-sageisencryptedasde nedinRFC822[3].Thesyntaxfortheparameteristwowords.The rstwordindicatesthesoftwareusedtoencryptthebody,andthesecond,optional,wordisintendedtoaidtherecipientinse-lectingtheproperdecryptionkey.However,currentFIPAplatformsbasedonJADE(JavaAgentDEvelopmentFramework)[4],FIPA-OS[5],etc.,donotsupportRFC822.TableIIshowsthestructureofanACLmes-sage.Theperfor
3 mativeelementistheonlymandatoryelementof
mativeelementistheonlymandatoryelementofanACLmessage;allotherelementsareoptional.TheACLmes-sagestructuredoesnotincludeanysecurityspeci celements. ParameterDescriptiontoNamesofprimaryrecipientsofthemessage,mandatory.fromNameoftheagentwhosentthemessage,mandatory.commentsOptionalcomment.acl-representationNameofthesyntaxrepresentationofthemessagebody,mandatory.payload-lengthThelengthofthemessagebody,optional.payload-encodingThelanguageencodingofthemessagebody,optional.dateMessagecreationdateandtime,addedbytheagent,mandatory.encryptedIndicationhowthemessagebodyhasbeenencrypted,op-tional.intended-receiverThenameoftheagenttowhomthisinstanceofamessageistobedelivered,optional.receivedTimereceivedbyanACC,optional.transport-behaviourTransportrequirementsofthemessage,optional.TABLEIMessageenvelopedescriptionA.SecurityevaluationTheonlyprovisionforsecurityintheFIPAmessagestructureistheenvelopeprimitive:encrypted.Thisallowsforadditionalsoft-waretobeusedtoo ermessagecon den-tialitythroughencryption.Originauthenti-cationandmessageintegrityarenotprovidedfor.Furthermore,theencrypted eldintheenvelopeisintendedfortheACC,nottheagentitself,whichmeansthattheencryptionwouldbeunderthecontroloftheACC,nottheagent.IV.OpenPGPInthissectionwewillbrie\rydescribetheOpenPGPmessagestructureinordertobeabletoevaluateitsappropriatenessforFIPAmessages.OpenPGP[6]isanon-proprietaryprotocolforprotectingemailusingpublickeycryptog-raphy.ItisbasedonPGPasoriginallyde-velopedbyPhilZimmermann[7].TheOpenPGPprotocolde nesstandardformatsforencryptedmessages,signatures,andcerti -catesforexchangingpublickeys.Overthepastdecade,PGP,andmorerecentlyOpenPGP,havebecomewelluseddefactostan-dardsforencryptedemail.BybecominganIETFstandard[6],OpenPGPmaybeimple-mentedfreely.PGPmessagesareconstructedfromanum-berofrecordsreferredtoaspackets.Apacketisapieceofdatathathasatagspecifyingitsmeaning.APGPmessageconsistsofanumberofpackets.Someofthosepacketsmaythemselvescontainotherpackets.Eachpacketconsistsofapacketheader,followedbythepacketbody.Thepacketheaderhasatagwhichdenoteswhattypeofpacketsthebodyholds.TableIIIshowsthede nedtags.AscanbeseenfromTableIII,PGPsup-portsthesecuremessageservicesdescribedinsectionI,includingmessagecon dentiality,throughtheuseofsymmetricandasymmetricencryptionalgorithms,andmessageintegrityandoriginauthentication,throughtheuseofdigitalsignatures.SomeofthePGPpacketslistedintheta-Tagno.Description0Reserved-apackettagmustnothavethisvalue1Public-KeyEncryptedSessionKeyPacket2SignaturePacket3Symmetric-KeyEncryptedSessionKeyPacket4One-PassSignaturePacket5SecretKeyPacket6PublicKeyPacket7SecretSubkeyPacket8CompressedDataPacket9SymmetricallyEncryptedDataPacket10MarkerPacket11LiteralDataPacket1
4 2TrustPacketTABLEIIIOpen-PGPpackettypes
2TrustPacketTABLEIIIOpen-PGPpackettypes ElementDescriptionperformativeThetypeofcommunicativeactofthemessage.senderNameoftheagentwhosentthemessage,mandatory.receiverNamesofprimaryrecipientsofthemessage,mandatory.reply-toIndicatesthatsubsequentmessagesinthisconversationaretobedirectedtotheagentnamedinthiselement.contentDenotesthecontentofthemessage.languageDenotesthelanguageinwhichthecontentelementisex-pressed.encodingDenotesthespeci cencodingofthecontentlanguageex-pression.ontologyDenotestheontologyusedtogiveameaningtothesymbolsinthecontentexpression.protocolDenotestheinteractionprotocolthatthesendingagentisemployingwiththismessage.conversation-idUsedtoidentifytheongoingsequenceofcommunicativeactsthattogetherformaconversation.reply-withIntroducesanexpressionthatwillbeusedbytherespondingagenttoidentifythismessage.in-reply-toDenotesanexpressionthatreferencesanearlieractiontowhichthismessageisareply.reply-byDenotesatimewhichindicatesthelatesttimebywhichthesendingagentwouldliketohavethereply.TABLEIIACLmessageelementsblearedesignedforkeymanagement.Thisisfunctionalitywehavenotconsidered,butwhichiscrucialfordeploymentofcryptogra-phyonalargescale.PGPisnottheonlystandardfordescribingcryptographicallyprotectedmessagecontent.AnotherexampleisCryptographicMessageSyntax(CMS)(RFC3369)[8].CMSisusedbyS/MIME(Secure/MultipurposeInternetMailExtensions)[9]andspeci essyntaxforrepresentingdigitallysigned,hashed,authen-ticated,orencryptedarbitrarymessagecon-tent(CMSisbasedonPKCS#7[10]).Sim-ilarfunctionalitytothatdescribedforOpenPGPisavailableinCMS.A.UsingPGPforFIPAmessagesWewillnowconsiderhowthePGPmessagestructurescanbeusedwithFIPAmessages.PGPcanbeusedtoencryptandsigntheentireACLmessagewithoutmakinganychangestothemessageenvelope.ThiswouldleavetheencodinganddecodingofPGPstructuredmessagesfortheagenttotakecareof.ThiswouldnotrequireanychangestotheFIPAspeci cations,assumingtheagentisabletodetermineifamessageisPGPencodedornot(thismight,forexample,beachievedbyusingtheencoding eld).Iftherearereasonsfortreatingtheele-mentswithintheACLdi erently,forexam-pletoonlyencryptorsigncertainelements,additionalinformationwouldneedtobepro-videdtotheagenttoindicatehowthemessageshouldbeprocessed.IftheACCserviceistoperformencryp-tion/decryptionandprocesssignatures`seam-lessly',additionalinformationneedstobepro-videdinthemessageenvelope.Theadvantagewithusinganexistingstan-dardisedprotocolsuchOpenPGPorCMSisthatitisalreadyde ned,therebyavoid-ingduplicationofwork.Thedrawbackmightbethatthealreadystandardisedprotocolhasfeaturesunnecessaryforourpurpose,possiblyaddingunnecessarypayloadsand,perhaps,confusion.Tosummarise,itisratherstraightforward tomakeuseoftheOpenPGPmessagestruc-tureforFIPAage
5 ntcommunication.How-ever,inordertoallowf
ntcommunication.How-ever,inordertoallowforallthecommu-nicationmodesdescribedinsectionII,aswellasforcryptographicallyprotectedmes-sages,thespeci cationsshouldallowencryp-tion/decryptionandsignatureprocessingtobecarriedoutbytheACCserviceaswellasbytheagent.Thiswouldrequireadditionalinformationtobeaddedinthemessageen-velope.Forfull\rexibility,theACLmessageshouldalsocarryinformationdescribingthesecuritymechanismsappliedtothemessage.TheinformationexchangebetweenanagentandACCserviceisfurtherdescribedinthenextsection.V.Agent|platforminteractionInthissectionweconsiderfurtherwherethecommunicationsecuritymechanisms tintheFIPAarchitecture.Wewillalsohighlightar-chitecturalissuesnotcoveredintheprevioussections,namelykeymanagementandsecu-ritypolicies.Leavingthecompletecodingandencodingofencryptedorsignedmessagestotheagentmaynotalwaysbedesirable.Tokeepagentssimpleandsmall,itcanbemoreecienttolettheexecutinghostdealwiththispotentiallycomplextask.Thiscanbedoneindi erentways,asdescribedinthenexttwoparagraphs.Asshownin gure3,onewayistolettheagentreceivethemessageasusual,andwhentheagenthasdeterminedthatitisanen-cryptedorsignedmessageitforwardsthemes-sagetotheappropriateservicetodecryptitortovalidatethesignature.Theagentwouldthenbereturnedthedecryptedmessageoranindicationoftheoutcomeofthesignaturever-i cation.Similarlywhentheagentwantstosendanencryptedmessageorasignedmes-sageitwouldsendthemessagetotheappro-priateserviceandbereturnedtheprocessedmessage,whichnowcanbesentasusual.Asecondoption,depictedin gure4,wouldbetolettheACCinterceptthecommunica-tionando erthesecurityservicesinamoretransparentwaytotheagent.Thiswouldre-Agent Platform\rACC\rAgent\rAgent Security\rServices\r1\r3\r4\r2\rFig.3.SecurityservicesseparatedfromACCquiretheACCtobeabletodetermineifanin-comingcommunicationisencryptedorsigned,aswellasgettinganindicationfromtheagentwhetherencryptionorsigningshouldbedonebeforesendingthemessage.Agent Platform\rACC\rAgent\rAgent Security\rServices\r1\r4\r2\r3\rFig.4.Securecommunicationserviceso ered`transparently'totheagentBothmodesofoperationshouldbepro-videdtoensurethatthecommunicationmodesdescribedinsectionIIarefullysup-ported.Therearetwoimportant,andnon-trivial,issueswehavenotyetcovered.Oneiskeymanagement.Whenencryptionisusedtheencryption/decryptionkeysneedtobeman-aged.ForasymmetriccryptographyaPKIistypicallyusedtofacilitatecertainaspectsofthekeymanagement.Inamulti-agentsys-temvariouskeymanagementissuesariseduetothefactthattheagentexecutesonahostwhichintheoryhasfullcontrolovertheagent,evenmoresoiftheagentdependsonthehosttocarryoutprocessinginvolvingthecrypto-graphickeys.Thefollowingquestionsneedtobeconsidered:Istheagentincontrolofitsownkey,oristhiscomplete
6 ly/partlydelegatedtotheplat-formwherethe
ly/partlydelegatedtotheplat-formwheretheagentisexecuting?Doestheagentneeditsownkeys,orcanagentsonthesamehostusethesamecrypto- graphickeys?Sinceapplicationswillhavedi erentre-quirementswebelievethatagentsshouldhavethefreedomtodecideontheseissuesthem-selves,ratherthenonlysupportingoneap-proach.Thesecondimportantthingwehavenotyetdiscussedisthatofsecuritypolicies.Ifanagentdependsonthehosttoperformcryp-tographictasks,theagentneedstocommu-nicateitsrequirementstothehost.Likewisethehostneedstolettheagentknowcertaininformationaboutitsprocessing.WhilePGPmightbesucientforthecar-ryingofencryptedandsignedmessages,fur-therspeci cationsneedtobedevelopedforacompletesolution.Communicationsbetweentheagentandtheexecutinghostneedtobestandardisedtocoverthetransferofkeyman-agementandsecuritypolicydata.Inthere-mainingofthissectionweconsidertheinfor-mationthatneedtobeexchangedbetweenanagentandtheACCservice,whichweassumeisresidingontheplatformwheretheagentisexecuting.Foroutgoingcommunication(communica-tionoriginatingfromtheagent)theagentneedstobeabletosupply(explicitlyorim-plicitly)theplatformwiththefollowinginfor-mation:requestmessageencryption;supplyanencryptionkeyorindicatethattheplatform'sencryptionkeyshouldbeused;choiceofencryptionalgorithm(andotherpossiblealgorithmrelatedoptions,includingkeylength,padding,etc.);requestmessagesigning;supplyasignaturekeyorindicatethattheplatform'ssignaturekeyshouldbeused;choiceofsignaturealgorithm(andpossi-blealgorithmrelatedoptions,includingkeylength,padding,etc.).Ifanagentrequestsencryptionorsigning,theplatformwouldtypicallyapplysomede-faultvaluesforparametersnotspeci edbytheagent.Forincomingcommunication(communica-tiondestinedfortheagent)theplatformneedstobeabletoinformtheagentregardingthefollowing:Ifthemessagewasprotectedthroughen-cryptionduringtransit;ifso,indicatemethodofencryptionthatwasappliedtothemessage(e.g.encryptionalgo-rithmandkeylength);ifthemessagecarriedadigitalsignature;ifso,towhatextentthesignaturehasbeenveri ed.Theplatformmightneedcertaininformationfromtheagentinordertodecryptamessageorverifyasignatureincludingthefollowing:decryptionkey;trustedCerti cationAuthorities(CAs)andagents;signatureveri cationrequirements(e.g.veri cationagainstrevocationlistsandmaxlengthofcerti cationchains).Theaboveinformationcanbeexchangedbetweentheagentandplatforminvariousways.Themoststraightforwardwayappearstobetolettheagentsupplymessagespe-ci cinformationwitheverymessagethatispassedtotheACCservice.Anotheroption,whichmaybemoreecient,isfortheagenttohaveacompletesecuritypolicydescriptionthatcanbepassedtotheACCservicepriortoanyothercommunicationtakingplace.Suchapolicyshouldbeallowedtobeascomplexasmightberequired.Di
7 erentrequirementsmight,forexample,applyd
erentrequirementsmight,forexample,applydependingonthedestinationofamessage.Athirdoptionistocombinetheothertwooptions.Anagentcanthencarry,andsupplytotheplatform,acompletecommunicationsecuritypolicy,butcanalsorequesttohaveaparticularmessagetreateddi erentlybysupplyingspeci cinfor-mationwiththemessage.VI.ConclusionsandfutureworkTheFIPAagentcommunicationspeci ca-tionsarelackingsucientfunctionalitytoprovidesecurecommunication.ByusinganexistingmessagestructuresuchastheOpenPGPmessageformat,sucientprotectioncanbeachievedforthecommunication.Wehaveconsideredwheresecurityservicescan beappliedtoagentcommunicationwithintheFIPAarchitecture,anddescribedtheinforma-tionexchangerequiredbetweenanagentandtheACCsecurityservices.Furtherdetailedanalysisandspeci cationishoweverrequiredforacompletesolution.Anotherwaytoachievesecureagentcom-municationappearstobetheXML(Exten-sibleMarkupLanguage)speci cations.ADocumentTypeDe nition(DTD)tocarryanACLmessagehasbeende nedbyFIPA.Variouse ortsareinprogressforspecifyinghowcryptographicservicescanbeappliedtoXML.Thesearealsolikelytoprovidethesecurityservicesrequiredforagentmessagecommunication.AcknowledgmentsTheworkreportedinthispaperhasformedpartoftheSoftwareBasedSystemsareaoftheCore2ResearchProgrammeoftheVirtualCentreofExcellenceinMobile&PersonalCommunications,MobileVCE,www.mobilevce.com,whosefundingsupport,includingthatoftheEPSRC,isgratefullyac-knowledged.MoredetailedtechnicalreportsonthisresearchareavailabletoIndustrialMembersofMobileVCE.References[1]FIPA98Speci cationPart10,Version1.0,AgentSecurityManagement,Geneva,Switzerland,Oc-tober1998,Obsolete.[2]FIPAAgentMessageTransportServiceSpeci ca-tion,Documentno.XC00067D,Geneva,Switzer-land,August2001.[3]DavidH.Crocker,StandardfortheformatofARPAInternettextmessages,IETFRFC822,IETF,August1982.[4]FabioBellifemine,AgostinoPoggi,andGiovanniRimassa,\JADE:aFIPA2000compliantagentdevelopmentenvironment,"inProceedingsoftheFifthInternationalConferenceonAutonomousAgents,JorgP.Muller,ElisabethAndre,SandipSen,andClaudeFrasson,Eds.2001,pp.216{217,ACMPress.[5]S.Posland,P.Buckle,andR.Hadingham,\TheFIPAOSagentplatform:Opensourceforopenstandards,"inProceedingsofthe5thInterna-tionalConferenceandExhibitiononthePracti-calApplicationofIntelligentAgentsandMulti-Agents,Je reyBradshawandGeo Arnold,Eds.,UK,2000,pp.355{368.[6]J.Callas,L.Donnerhacke,H.Finney,andR.Thayer,OpenPGPMessageFormat,IETFRFC2440,IETF,November1998.[7]PhilipR.Zimmermann,TheOcialPGPUser'sGuide,MITPress,Boston,1995.[8]R.Housley,CryptographicMessageSyntax,IETFRFC3369,IETF,August2002.[9]B.Ramsdell,S/MIMEVersion3MessageSpeci- cation,IETFRFC2633,IETF,June1999.[10]RSALaboratories,PKCS#7:CryptographicMessageSyntaxStandard,1993,versi