Role Kerberos

The Role of Kerberos in Modern Information Systems
Introduction
Achievingadequatesecurityfortodaysinformationsystemshasproventobeavery hardproblem.Inmanycases,theproblemsofsecurityhavebeenmadeevenharderby ahistoryoftreatingsecurityasanafterthought.Toooften,insteadoftakinga comprehensive,architecturalapproachtosecurity,ourfieldhasdeployedsecurity measuresandtechnologiesasindividualboltonsolutionstoverynarrowproblems. Overtime,theresultingmosaicofsecurityrelatedtechnologiesbecomesbrittle,difficult toextend,timeconsumingtomanage,andnotnecessarilyeffective. Thisdocumenttakesanarchitecturallookatsecurity,butitisnotareferencemanualfor securityarchitects.Instead,itfocusesontheroleoftheKerberosauthenticationsystem aspartoftheoverallecosystemofsecuritytechnologies,services,andsoftware componentslikelytobeencounteredinatypicalmoderndistributedsystems environment.Itisintendedforthosewhodesign,build,andmanageenterprise computinginfrastructure,aswellasforthosewhodevelopsoftwareintendedto operateinsuchenvironments.Thisdocumentshouldanswermanyofthequestions abouthowKerberosfitsintomoderninformationsystems,andhowitrelatestoother vitalsystemservices. Thisdocumentisexplanatoryratherthanprescriptive:itdescribesthecontextinwhich Kerberosexists,andprovidessomeguidance,thoughthatisnotitspurpose.Instead,it isintendedasbackgroundfortwootherdocumentsthatdomakerecommendations, onefocusedonsystemsandplatforms,andtheotheronapplications: RecommendedPracticesforDeployingandUsingKerberosinMixedEnvironments(pdf) BestPracticesforIntegratingKerberosintoYourApplication(pdf) Kerberosisasecuritytechnologythatismatureandthatisincreasinglydeliveredasan integralcomponentofmodernsystems.Assuch,itcanbeanimportantelementofan overallsecurityframework.However,becausedifferentdevelopercommunitieshave approachedKerberosintegrationindifferentways,newchallengesemergewhenusing Kerberos,especiallyinthekindofdynamic,openended,mixedplatformenterprise computingenvironmentthatistypicaltoday. Thisdocumentframesthosechallengesinthelargercontextofinformationsecurity.It beginswithafocusonaccesscontrolasanoverarchinggoal.Itthendescribesthevarious securityservicesthatcontributetoeffectiveaccesscontrol,anddiscussestheissuesthat
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 1 of 53
ariseinprovidingthoseservices.Next,itdescribestheroleofKerberosinproviding thoseservices,focusingonthewaysinwhichKerberosintegrateswiththeother technologiesunderavarietyofscenarios.Itpaysparticularattentiontodirectoryservices, which,whilenotpartofKerberos,areoftenintegratedwithit.Finally,itintroduces somedetailsaboutthewayKerberosisusedwithinspecificoperatingsystemplatforms suchasMicrosoftActiveDirectory,OpenDirectory,andothers.
Access Control as a Primary Objective

Ultimately,amajorpurposeofinformationsecuritytechnologyistoimplementaccess control:toenableauthorizedaccesstoinformation,resources,andservicesandto preventunauthorizedaccess.Accesscontrolencompassespoliciesthatindicateunder whatcircumstancesaccessistobegranted,andmechanismstoimplementthosepolicies.
Access Control Policies

Anaccesscontrolpolicyincorporatesthefollowingfactors,eitherexplicitlyor implicitly: Authorities and Regimes Anauthorityistheentity(person,role,ororganization)responsibleforestablishingthe otherelementsofanaccesscontrolpolicy:definingandclassifyingresources, determiningauthorizations,definingallowedmeansofaccess,specifyingconfidence levels,etc.Agivenauthorityhasresponsibilityforthepolicyelementsthatgoverna specificsetofusersandresources,typicallyundercommonadministrativecontrol,for example,alltheusersandhostsintheaccountingdepartmentofSomeCorporation.This paperreferstosuchagroupingasaregime,althoughthetermsadministrativerealmand administrativedomainarealsoencountered.Sincerealmisalsousedinatechnicalsense byKerberos,anddomainbyWindowsActiveDirectory,thetermregimeisless overloaded. Regimescanberelatedtoeachotherhierarchically:theSomeCorpAccounting DepartmentispartofthelargerSomeCorp.Theycanalsoberelatedinotherways:the policiesforSomeCorpAccountingDepartmentmightgrantaccesstocertainresourcesto employeesofanoutsidecompanythatprovidescontractaccountingservicesto SomeCorp.Insomecontexts,externalregimes,suchasregulatorsorauditorsmay contributetopoliciesandimposecertainpractices. Resources Asecuritypolicymustdefinetheresourcestowhichitapplies;examplesofresources includecomputers,abstractservices,files,networkconnections,andinformation. Resourcesmaybedefinedviaidentifiers(e.g.,thehostataddress172.24.37.1)orby attributes(e.g.,allemployeerecordswheredepartmentnumberis47).
Copyright Notice, 2008 by the MIT Kerberos Consortium.
Page 2 of 53
Resource Classification Resourcescanbeclassifiedaccordingtothelevelofrisk,costs,orconsequences associatedwithmanagingaccess.Examplesofclassificationincludetopsecret, subscriptionrequired,downloadedfileisanapplication). Access Context Anaccesscontrolpolicyoftenmakesreferencetothecircumstancesunderwhichaccess isrequestedorthemeansbywhichaccessisprovided.Forexample,duringnormal businesshoursfromacompanyownedworkstationinasecureofficemightbe associatedwithadifferentaccesspolicythanviaanunsecuredInternetconnection. Allowed Use Examplesofpossibleusesforaresourceincluderead,modify,changeownership,modify accesscontrolpolicy,create,delete,etc. Parties Justasanaccesscontrolpolicyidentifiestheresourcestowhichitapplies,italso identifiesthepartiesforwhomaccessisauthorized.Partiescanbereferredtoeitherby identifier(e.g.user#6718)orbyattribute(e.g.,allusersingroupAdministrators).A partymaybeahumanuser,oritmaybeanabstractentity(e.g.,themaildelivery processformailaddressedtoaddressesinsomecorp.com) Confidence in Authenticity Anaccesscontrolpolicymayhavedifferentrulesforaccessdependinguponthe systemsconfidenceintheauthenticityofaparty.Forexample,thisrequestcamefroma workstationwhereJoeloggedin6hoursagousingapasswordandhasnotyetloggedout somewhatweaklyauthenticatestherequestascomingfromJoe.Ahigherconfidence authenticationmightbe:thisrequestincludescryptographicevidence,lessthan2minutesold, thattherequestorpossessedasecuritytokenregisteredtoJoeatthetimetherequestwasmade.
An Example Access Control Policy

Asanexampleofanaccesscontrolpolicytakenfromafamiliarcontext,considerthe policygoverningafilelocatedonsomeonesPC:
Authority Owner of the computer Resource File stored on directly-attached disk drive Classification Non-sensitive Access Context Locally logged-in user Allowed use Owner: read/write; Group: read; Others: no access. No execute
Page 3 of 53
Authorized parties File owner. Members of group admin Not members of group guests or other Authenticity confidence: User has presented password (single-factor) Figure 1An example of an access policy; this one governs files on a PC
Thissimpleexamplehelpsillustratesomeimportantpoints.First,establishingwhohas authorityovertheresourceisvitaltoanyinterpretationofthepolicy.Inanysufficiently complexenvironment,therearelikelytobemanydifferentauthorities,eachwith controloveradistinctsetofresources.Iftheownerofthecomputerisanemployer,the employeewhousesthecomputeranditsfilestoragewillonlyhavewhateverauthority isdelegatedtothembytheiremployer.Itisalsonecessarytobeclearaboutthespecific resourcecoveredbythepolicyi.e.,afileisaresourcedistinctfromthediskdriveit happenstoresideon,andthefilemaywellexistinmultiplelocations,butstillbe governedbythesameaccesspolicies. 1 Whilethisexampleclassifiesthefileresourceas nonsensitiveperhapsbecauseitisjustafilecontaininguserpreferencesitwould clearlymatterifthefilewasinsteadasensitivedocumentforwhichtheremightbe severeconsequencesifdisclosedtounauthorizedparties.Themeansofaccessisanoften overlookedfactor,butitclearlymatterswhetherthefileisbeingaccessedlocally,oris beingsharedacrossanetwork,orretrievedfromabackuparchive.Inpractice,allowed useisoftenspecifiedaccordingtothedesignationofauthorizedpartiesinthisexample, thefileownerandgrouphavedifferentusageconstraintswhileeveryoneelseshould havenoaccess.Finally,thedegreeofconfidenceintheauthenticityofpartiesisvitaltoany assessmentofcompliancewithanaccesspolicyorcharacterizationofrisk.Thelevelof confidencerequiredinanauthenticationprocessgenerallyrelatesdirectlytoboththe meansofaccessandtheclassificationoftheresource.Forexample,itmightbereasonable torequireahigherlevelofauthenticationconfidencefromremotepartiesthanfroma locallyloggedinuser.Similarly,greaterauthenticationconfidencemightberequiredif theresourceisclassifiedastopsecretasopposedtorestricted.Orabankmightbe willingtoprocesslowvaluetransactionsbasedontelephoneauthorization,butrequire awitnessed,guaranteedsignatureforhighvaluetransactions. Accesscontrolpoliciescanbequitecomplexandoftenspecifymanyconditionsthat mustbemetbeforeaccessiseithergrantedordenied.Furthermore,therecanbe significantrisksfrombothfalsepositivesandfalsenegativesinanysystemthatprovides controlledaccesstoresources.Forexample,anaccesscontrolsystemthatfalselydenies afinancialtraderaccesstotheirtradeexecutionsystemcouldhavesubstantialadverse costimplications.Inreality,accesscontrolsystemscanbeattackedinordertogain unauthorizedaccess,orasameansofdenyingaccesstoauthorizedparties(e.g.,a denialofserviceattack).
Whilethisexampleillustratesaccesscontroltoafileobject,thefileisjustacontainerfor information,anditmaywellbethatthegoverningpoliciesapplytothedatacontainedinthefile, andnotthefileobjectperse.

1

Figure 2A simple conceptual model of access control
Access Control Mechanisms

Effectiveaccesscontrolsdependonotheressentialsecurityservicesandassociated managementfacilities.Realworldsolutionsaregenerallybuiltontopofsystem platformsthatprovidetheseservicesandallowthemtobecombinedinabuilding blockfashion,thoughusuallyinaniterativemanner.Thisallowsaccesscontrol solutionstobetailoredtocomplywithaccesspoliciesacrossabroadrangeof applicationsandusagescenarios.Thesecurityservicesessentialtoaccesscontrol include: Integrity:informationonwhichaccesscontroldecisionsarebasedmustbeof knownintegrity,anditmustbepossibletodetectattemptstotamperwiththis information. Confidentiality:informationintendedforaspecificrecipientmustbeprotected fromeavesdropping.Inparticular,sensitiveinformationusedinaccesscontrol (e.g.,passwords,sessionkeys)mustbeprotectedfromdisclosure. Authentication:beforemakinganaccesscontroldecision,asystemmust determinetoanacceptablelevelofconfidencethatthepartyrequestingaccessis authentic(e.g.,isthelegitimateuserofthenameunderwhichaccessis requested.) Authorization:onceapartyhasbeenauthenticated,itisnecessarytodetermine whetherornotthepartyisauthorizedtogaintherequestedaccess.
Page 5 of 53
Theseessentialservicesaresupportedbyadditionalsystemservices,including: Directoryservices:typically,informationaboutresources,policies,andvarious attributesofnamedpartiesisstoredindatabases;itmustbepossibletoretrieve uptodateinformationfromthesedatabasestosupportauthenticationand authorizationdecisions,withtheaddedrequirementsthatthisinformationneeds tobereplicatedandsynchronizedthroughoutadistributedsystemenvironment, andthatthedatabasesthemselvesmustbeprotected. Managementservices:itmustbepossibletomonitoroperations,detectfaults, configuresystemcomponents,initializeandupdateinformation,andaudit behavior
Figure 3Access control depends on other essential security services, but generally in an iterative manner that interweaves security services in complex patterns. Access control is itself often applied in an iterative manner.
Whiletherearemanysystemcomponentsthatcanbeusedtoprovidethesecore services,twostandardsbasedtechnologieshaveemergedaspreferredbuildingblock services:KerberossecurityservicesandLDAPbaseddirectories.WhileKerberosis stronglyassociatedwithauthenticationanddirectoryservicesareperceivedofas managingauthorizationandpolicydata,thedistinctionsaresomewhatblurredsince Kerberosalsoprovidesrudimentaryauthorizationfacilities,anddirectoryservicescan providesomeauthenticationmechanisms.Inpractice,Kerberosanddirectoryservices arecomplementaryinnature,andmostsystemplatformsthatprovideaccesscontrol facilitiesintegratetheseservicestoatleastsomedegree(e.g.,MicrosoftsActive DirectoryincorporatesKerberosandLDAP,tightlyintegratedwitheachother).
WhileKerberosisoftenconsideredanauthenticationservice,italsoprovidesfacilitiesfor managingkeys,assuringdataintegrity,authorizinguseofservices,establishingsecure sessions,andprotectingconfidentialityofdataexchanges.Asanauthenticationservice, itprovidesadditionalvaluebysupportingmutualauthenticationofpartiesthatenter intoasecurecommunicationssession.
Issues for Security Services

TherolesthatKerberosanddirectoriesplayinprovidingcoresecurityserviceswillbe evaluatedingreaterdepthbelow,butbeforedoingso,thereareotherissuesassociated withthecoreservicesthatshouldbereviewed: Mutuality:itisnotenoughthattheserviceauthenticatetheuserpriorto grantingaccess;itisalsoimportantthattheuserauthenticatetheservice,soasto avoidprovidingsensitivedatatoamaliciousimpostor.Astheplagueofphishing attacksinrecentyearshasdemonstrated,onewayauthenticationexposes legitimatepartiestoavarietyofattacks,evenwhenoneofthepartiesisnota participantinthefraudulenttransactione.g.,abanksreputationcanbe damagedwhenimpostorspurloininformationfromthebankscustomers.Itis nowwidelyrecognizedthatmutualauthenticationisessentialtopreventingsuch attacks.Moregenerally,mutualityextendstoaccesscontrol,thoughusuallyinan asymmetricmanner.Inotherwords,boththeserviceandclientneedtoenforce accesscontrolsontheother,butfordifferentreasonsandtoaddressdifferent risks.Forexample,awebsitethatcontrolsaccesssothatonlyauthorizedusers canaccessinformationorservices,isatthesametimeaccessingtheusers browsers,andmayevenbeexecutingcodeonuserssystemsintheformof JavaScriptsorActiveXcontrols. 2 Theuseofbrowsersidesecurityzonesand scriptblockingpluginstoconstrainwhichsitesareallowedtoexecutescripts illustratesonewaythataccesscontrolshavebeenintroducedontheclientsideto minimizecertainthreatstousersi.e.,somebrowserusersarenowmaintaining accesscontrollists(ACLs)forsitestheyvisit. Principals:Inanyapplicationcontext,therearemultipleprincipalsinvolvedin communicationsandperformingvariousservices.Alloftheseprincipalsneedto benamed,andappropriatelyauthenticated.Forexample,ahumanuserisan importantprincipalinmanyapplications,buttheuserisnotthesameprincipal astheirworkstation,noristheuserequivalenttotheclientsoftwarerunningon theirworkstation.Similarly,theclientsoftwareandworkstationaredistinctly differentprincipals,eventhoughtheseprincipalsareoftentreatedasthesame thing.Inperformingaccesscontrol,itoftenmatterswhichoftheseprincipalshas beenauthenticatede.g.,isittheuserthatwasauthenticated,theirworkstation, ortheirclientsoftware?Furthermore,itisimportanttoclarifywhichprincipals haveauthority.
Delegation:Incomplexdistributedsystems,therearemanysituationswhereit maybenecessaryforauthorizationstobedelegatedtosomesystemoragentto actonbehalfofaprimaryauthority.Forexample,awebfrontendapplication

WhilethewisdomofhavingserversexposedtothepublicInternetalsodownloadingcodeontoa usersmachineforexecutionwithouttheknowledgeoftheuserisdubiousatbest,thepracticeis widespread,andillustrateshowotherprioritiescanintroducenewsecuritychallenges.
2
mayneedtoretrieveinformationfromabackenddatabaseonbehalfofa requestinguser.Usersalsodelegateauthorizationstootherindividualsby simplysharingpasswordsorotherauthenticationmethods.Usersevendelegate authorizationstosoftwareagentstomanageadditionaldelegationbygiving theseagentsuseridsandpasswordstoprovidetoothersystemsUnfortunately, manypolicyregimesdonotadequatelyaddressdelegationwithinstated policies,ortakethenavepositionthatdelegationisnotallowed.Ingeneral,itis besttodefinerationalpoliciesforappropriatedelegationofauthority,and providecontrolsforassuringthatdelegationissupportedincompliantways. NetworkInfrastructure:Todaysnetworkinfrastructuredoesnotprovide securityservices,relyingonotherpartsofthesystemtoprovidetheseoftenvital services.Consequently,everyaspectofthenetworkevenaprivatenetwork mustbeconsidereduntrusted.Thisincludestheaddressesclaimedbynetwork nodes,theDNSsystemthatmapsnamestoaddresses,DHCPservicesthatassign addressestodevices,networktimeservicesthatareusedtosynchronizeclocks, servicediscoveryprotocols,andeachandeverypacketsentorreceived.In particular,ManintheMiddle(MitM)attacksarefeasible,andincreasingly common.Theuntrustednatureofnetworkssubstantiallycomplicatesaccess control,andrequirescarefulplanninganddeploymentofrobustsecurity infrastructuretoachievepolicycompliance.Ofcourse,therearemanyexamples wherepeoplechoosetotrustsystemsreachedoveruntrustednetworkswhere therisksareacceptable,suchasusingthepublicInternetforaccesstonewsand othercontent.Therecanalsobetightlycontrolledsubnetsthataretrustable,even forhighrisktransactions.Intheend,itsallaboutacceptablerisks. Registration:Proceduresareneededtoregisterorenrollusers,systemsand resourceswithinanaccesscontrolcontext,yetproblemsorvulnerabilitiesin theseprocedureshavethepotentialtocompletelyundermineanentireaccess controlsystem.Forexample,ifanimpostorisabletoenrollasanauthorizeduser inasystembyexploitingsomevulnerabilityintheenrollmentprocedure,thenit doesnotmatterhowstrongorrobusttheaccesscontrolsystemis,sincethe impostorwillbegrantedaccess.Notethatprivilegeescalationisanother potentialvulnerabilityinregistration/enrollmentproceduresifalegitimateparty isabletoacquiremoreauthorizationsthanallowedbypolicies.Furthermore, registrationproblemsexistforbothhumanusersandmachines.Asthevarieties andcapabilitiesofnetworkattachedmachines(e.g.,servers,applicationservices, printers,networkappliances)continuetoevolve,registrationproblemswith machineryresultinneworincreasedthreats. RevocationsandAuthorizationUpdates:Proceduresmustalsobeinplaceto modifytheauthorizationsgrantedtoparties.Inparticular,itisusuallynecessary tobeabletorevokesomeorallofapartysauthorizationsifthepartyisfoundin violationofpolicies,orifauthenticationcredentialsarecompromised. Conversely,apartymayalsobegrantednewauthorizationsthatallowupgraded accesstoresources.Anothercommonscenarioisthatapartysrolechanges, whichnecessitatesaddingsomenewauthorizationsandsimultaneously rescindingotherauthorizations.Animportantconsiderationwiththese proceduresistheabilitytopropagatesuchchangesthroughoutanentireaccess controlenvironment.Forexample,ifausersaccessprivilegesmustberevoked, itcouldrepresentasignificantexposure(i.e.,risk)iftherevocationwillnotbe
Page 8 of 53
recognizeduntilsometimelater.Similarly,ifauserisgrantednewprivileges,it couldbecounterproductiveiftheyencounteraprolongeddelaybeforetheycan makeuseoftheirnewprivileges. KeyManagement:Thesecretsusedtoauthenticatepartiesincluding passwordsmustbeprotectedfromdisclosureandwillneedtobereplaced periodically,includingwheneverthereisanypotentialthatsuchsecretshave beenexposedorcompromised.Theproceduresforhandlingreplacementof secretpasswordsandkeysrepresentpotentialexposuresthatcouldleadto substantialrisksifexploited.Secretsalsoneedtobeprotectedfrominadvertent disclosures,astheyrepresentattractivetargets.Passwordsusedbypeoplehave longbeenrecognizedasfundamentallyweakariskthathasonlygrownin recentyearsasmanymoreattackshavebeendevelopedtofoolusersinto disclosingtheirpasswords.However,secretkeysusedbyapplicationsand serversarealsobeingtargetedbyadversariesusinghighlysophisticatedattacks. Therealityisthattodaysaccesscontrolsystemsareonlyasstrongasthe managementproceduresusedtomaintainsecretkeysandpasswords. Liveness:Itiscommonforpoliciestomandatethataccessbeprovidedonlyto authorizedhumanusers,andnottomachinesorsoftwareagents.However,itis quitedifficultforanautomatedaccesscontrolsystemtodetermineifaremote partyistrulyalivehumanbeing(thereverseTuringtest).Whilevarious hardwareandsoftwaretechniqueshavebeendevisedtoprovidelivenesstests, theefficacyofmanytestsisbeingunderminedbysmartermachines.In general,livenesstestingnowrequiressomesortofhardwaredeviceotherthan akeyboardonacomputerthatrequireshumanactivationoruse.Forexample, aonetimepassworddonglethatrequirestheusertotranscribeacodedisplayed onthedongleintoadataentryfieldontheircomputerscreenprovides reasonableconfidencethatalivehumanisintheloop. Scalability:Asinformationservicescontinuetoscaleupintermsofinformation contentscope,geographicaldistribution,andnumberofusers,modernaccess controlsystemsfaceescalatingchallengesofscale.Unfortunately,themulti dimensionalnatureofaccesscontrolsystemsusuallyleadstoatleastpolynomial scaling.Forexample,anorganizationthathaslineargrowthininformationbeing accessedandalsoinitsuserpopulationislikelytofindaccesscontrolchallenges increasinginproportiontotheproductofthesetwolineargrowthtrends.Not onlydoesscalechallengeaccesscontrolsystemsinthefamiliarareasof performanceandmaintainability,scalealsoincreasestheattacksurfacein waysthatcanbedifficulttofullyassessandadequatelyaddress. FederatedEnvironments:Manyorganizationstodayarefarflungenterprises thatworkcloselywithbusinesspartners,outsourcedserviceproviders,andeven customers.Therefore,accesscontroloftenextendsbeyondtraditional organizationalboundaries(and,accordingly,acrosspolicyregimes),andnew federatedmodelshaveemergedforextendingaccessauthorizationsacrosssuch boundaries.Consequently,accesscontrolsystemshavehadtoevolvetosupport federatedinteractionsaswellasaccessfromnontraditionalentities.Federation alsoleadstonewpoliciesandnewchallengesinassuringcompliancewithboth newandexistingpolicies.
Page 9 of 53
Auditability:Accesscontrolsformoderninformationsystemsgenerate potentiallysignificanteventsatenormousrates.Eventsmayrelatetoaccess grantedordenied,authenticationofparties,authorizationsissued,changesto directories,replications,changesinsecretsorkeys,revocations,management operations,configurationupdates,andmyriadotherstatetransitions.Even assumingthatalloftheseeventsarelogged,effectiveauditpracticesrequirethe abilitytoanalyzelogsforpatternsofaberrantbehaviorortrendsthatportend potentialproblems.Furthermore,theabilitytopreventpartiesfromrepudiating eventsthatarerecordedinlogsmaybenecessarytoinsurecredibilityoflog records.Insomecases,auditrequirementsmightextendtoaccountingforaccessin supportofvariousbusinessmodels. UserConvenience:Securityservicesmustfunctionwithoutimposingundue burdenonendusers.Userswhoarerequiredtoestablishandmemorizelarge numbersofdifferentpasswordsfordifferentservices,whoarerequiredtore authenticaterepeatedlyduringthecourseofasession,orwhoarewrongly deniedaccess,willregardsecurityasexcessive,intrusive,andcounter productive,andwill,insomecases,findwaystoworkaroundsecurity protectionsthatoftenleavethesystemworseoffthanitwouldhavebeen withoutthesecuritymeasures.Foroneexample,userswhoarerequiredtouse complex,difficulttomemorizepasswordsoftenrespondbypostingtheir passwordsontheirofficewallsnexttotheirworkstations.
Kerberos,especiallywhenintegratedwithrobust,enterpriseleveldirectoryservices, providesasolidfoundationforaddressingmanyoftheissuessummarizedabove. However,theeffectivenessofanysecuritytoolsetisdirectlyrelatedtothepractices employedinmanagingtheoverallinformationsystemsenvironment.Furthermore,no onetoolsetissufficientintodaysthreatcontext,andappropriatecombinationswillbe neededtoachieveadequatelevelsofsecurity. Naming Everyuser,host,andservice(collectively,every principalhasauniquename. Authentication Itispossibletodeterminethatthepartyusinganame isitslegitimateowner DirectoryAccess Itispossibletolookupattributesforanyname,e.g., groupmembership,entitlements. Authorization Itispossibletolookuptheapplicableaccesscontrol policyanddeterminewhetherornottheproposed accessisauthorized. Confidentiality Eavesdropperscannotstealthecontentofmessages. Integrity Themessagethatapartyreceivesisthemessagethat theotherpartysent,hasnotbeencorrupted (deliberatelyoraccidentally)enroute.
Page 10 of 53
Management Itmustbepossibletoaddandremoveprincipals, changeattributedata,editaccesscontrolpolicies, changesecrets(passwords)andotherwisemanage thedataonwhichthesystemdepends. Audit Thesystemmustrecordeachofitsactions.
Single Sign-On (SSO)

Theabilityforuserstosignon(loginorauthenticate)oncepersession,andgetaccessto alltheinformationresourcestheyneedwithoutsubsequentlybeingbotheredtoauthen ticateagain,isanimportantuserconvenienceandamuchsoughtaftercapability. Kerberoshas,fromitsinception,providedaSingleSignOn(SSO)facilityforusers, whichitimplementsbycachingtimestamped,limitedusecredentialsandpresenting themonbehalfoftheuserwhentheuserrequestsaccesstoresourcesandservices. SingleSignOndoesnotchangeanyaspectoftheoverallaccesscontrolframework. Eachtimethesystemgrantsaccesstoaservice,itconductsanauthenticationstep,but withSSOtheauthenticationstepisbasedonretrievingcachedcredentialsratherthan uponaskingtheusertoenterapasswordagain.Softwareclientsandservicesusing Kerberosalwaysauthenticatewitheachnewinteraction,andmayusesessionkeysto authenticateeachmessagetheyexchange.Withoutsuchprocedures,accesscontrols wouldnotbeeffective,andSSOwouldbeoflittleutility. WhatKerberosofferstousersistheabilitytoprovetheirauthenticityonceinaperiod, andtocachethefactthatauthenticationwassuccessfulsothatsubsequent authenticationsconductedbyclientsoftwareonbehalfoftheuserneednotinvolvethe user.However,accesscontrolpoliciesmayimposeotherrequirementsthatcouldcause userstohavetoreauthenticate,orprovideadditionalproofsofauthenticity.For example,ifauseroriginallysignedinusingapassword,andisnowattemptingto accessaresourcewhosepolicyrequiresahigherdegreeofconfidence(forexample,use ofasmartcardorotherphysicaltoken),theuserwillneedtoauthenticateagain.Or,an accesspolicyforsomeservicesmightallowauthenticationviacachedcredentialsupto eighthoursold,whileanothermightrequirethattheuserhasauthenticatedwithinthe past2minutes,orhasspecificallyauthenticatedthecurrentrequest. ThereareotherrealworldpolicyconstraintsonthescopeofSSO.Forexample,auser thatauthenticatedunderonepolicyregimemaynotberecognizedinanotherpolicy regimeunlessatrustrelationshiphasbeenestablished.Sinceaccesscontrolsalso dependonauthorization,ausersignedoninonepolicyregimemightnotbeableto provideacceptableauthorizationsinanotherpolicyregime,evenifthetworegimes agreeonauthenticationofusers. Consequently,whileitisreasonablethatusersshouldonlyneedtosignononce,itis oftenimpracticaltoofferuniversalaccesstoservicesthroughoutanextended enterprise,andgenerallynotacrossmajorpolicyboundaries,suchasbetween enterprisesoracrossnationalpoliticalborders(thoughnationalbordersdosometimes getblurredinlarge,multinationalenterprises).
Page 11 of 53
The Role of Kerberos

Kerberosisafoundationalserviceonwhichapplicationsandothersecurityservicescan bebuilt.Atitscore,itprovidesthemeanstoauthenticateclientstoservers,andvice versa.Furthermore,italsoprovidesanarrayofotherservicesthathaveprovenboth usefulandvitaltoachievingsecurityobjectiveswithintodaysinformationsystems.The capabilitiesofKerberoswillbeexploredbelowwiththeobjectiveofimproving understandingoftherolethatKerberosplays,andhowitsrolecanbefurther leveraged.Notethatthereaderisassumedtohaveabasicunderstandingofhow Kerberosprotocolsworkandthemeansbywhichclientsandserversinteractwith KDCsandassociatedAuthenticationServicesandTicketGrantingServices.Tutorialson howKerberosworksareavailablefromtheMITKerberosConsortium. KerberosProtocolTutorial(html) TheMITKerberosAdministratorsHowtoGuide(pdf)(Chapter1isabrieftutorial)
Naming in the Kerberos Context

Acommonterminologyprobleminsecuritydiscussionsisconfusionaboutthemeaning ofnames,andhowtorelatenamestothethingsbeingnamed.Inparticular,thereisan unfortunatetendencytoconfuseidentifiersandidentities. Strictlyspeaking,anidentityisanabstractionthatwhichdistinguishesanentity fromallotherentitiesintheuniverse.Inotherwords,theessenceoruniquenessof anentity.Anidentityisnotsomethingthatcanbepointedto,writtendown,or storedinadatabase. Anidentifierontheotherhand,isthatwhichreferstoanidentity.Identifiersare merelyhandlesthatcanbeusedtoconvenientlyreferencesomeentity,ofteninan indirectmanner.AnamesuchasJohnorthebillingdepartmentofSomeCorp. isonetypeofanidentifier.Otheridentifierscanbenumeric(employee237)or attributebased(theusercurrentlyloggedinatworkstationF3B288).Relevant typesofidentifiersincludeuserids,Kerberosprincipals,andX.500Distinguished Names. Identifiersmaybeuniquebutneednotbe.Johnreferstomanypeople.Some identifiersaredeliberatelyconstructedsoastobeunique,eithergloballyorwithina specificcontext.Forexample,anIPaddressisconceptuallyauniqueidentifier,but RFC1918IPaddresses(socalledprivateIPaddresses)areonlyuniquewithinthe contextofaspecificphysicalnetwork.Furthermore,thereisnothingthatguarantees uniquenessofIPaddresses,eitherlocallyorglobally,andspecifichostscanhave dynamicallyassignedIPaddressesthatchangeovertime.Ingeneral,uniquenessof namesrequirestheexistenceofsomeregistrationprocesstoguaranteethatnaming collisionsdonotoccur.Forexample,domainnamesareusuallygloballyuniquedue totheregistrationprocessadministeredbyICANN.Anothertechniqueusedto approximateuniquenesswithoutrequiringaregistraristoconcatenatemultiple namesusedtoreferenceanentity.Forexample,apersonsfullnamecombinedwith theirbirthdateandcityofbirthisusuallyunique.DNSnamesandnamesusedby Kerberosarealsoconcatenatedsequencesofsimplernames.
Page 12 of 53
Thesameentitymaybereferencedbymanynamesoraliases.Forexample,aperson isknownbytheirgivenname,surname,birthdate,residentialaddress,telephone number(s),socialsecuritynumber,passportnumber,driverslicensenumber,and numerousaccountnumbersanduserids.Aliasesarecommonlyusedforentities authenticatedbyKerberos. Thesamenamemayrefertodifferententitiesindifferentcontexts.Forexample, manyprogramsrunningaspartoftheoperatingsystemarelooselyreferredtoas simply,rootanexampleofanamethathasmeaningonlywithinaspecific context,andismoreaccuratelythenameofarole.Rootmayrefertodifferent entitiesondifferentmachineswithinthesameenvironment.Virtualizationisa recenttechnicaltrendthatisgreatlycomplicatingthenamingofcomputersystems, aswellastheattributesassociatedwithcomputers,sinceasinglecomputersystem canbesimultaneouslyrunningmultipleOSs,eachwithitsownnamingconventions. Someidentifiersareassociatedwithattributes,orareencodedtoindicateattributes. Forexample,modelnumbersandsomeserialnumbersindicateattributesofthe associatedequipment,andmightevenrelatetothingslikedateofmanufacture. Othernamesareaddressesthatcanbeusedtolocateanentityinsomespace,orto establishcommunicationswiththeentity.
Fortunately,Kerberosisfairlyconsistentinwhatitnamesandhownamesare structured,thoughtherearedifferencesinnamingconventionsbetweencurrent versionsofKerberosandwithearlierversions.Therearealsosomedifferencesin namingconventionsusedinMicrosoftenvironmentsversusotherenvironments. TheentitiesnamedbyKerberosaretermedprincipalsandrealms.Aprincipalreferstoan entitysuchasauser,machine,orservice;arealmreferstoapolicyregime:an organizationorspecificnetwork. PrincipalsinKerberoscanbeeitherusersorsoftwareapplications(a.k.a.,services, servers,computers,applications,nodes,PCs).Userprincipals,oroftenjustprincipals, arenormallyassociatedwithpersons,butmightbeassociatedwithrolesfulfilledby persons,orevenagentsactingonbehalfofrealpersonsinsomecases.Hostorservice principalscanrepresentasinglephysicalcomputer,oraservicerunningononeormore computers.Asinglephysicalcomputermighthostmultipleservices,eachgivenitsown Kerberosprincipalname.Itisalsopossibleforasinglenamedserviceprincipaltobe hostedacrossmultiplephysicalcomputers.Aprincipalnameincludesatextstringsuch asjoe,systemadministrator,ormailtransportdaemonandtherealmnameinwhichthe principalisdefined. ThemostcommonformofarealmnameisderiveddirectlyfromaDNSdomainname suchasaccounting.somecorp.com.DNSdomainnamesaregloballyuniquetotheextent thattheyareregisteredthroughofficialdomainnameregistrars. 3 Byconvention, Kerberosrealmnamesareusuallypresentedinuppercase:therealmassociatedwith accounting.somecorp.comwouldbeACCOUNTING.SOMECORP.COM.Note,though, thatunlikeDNSdomainnames,Kerberosrealmnamesare,inreality,casesensitive.This providesanopportunityformisconfiguration:ifarealmisreferredtoinoneplaceas
3Actually,domainnameregistrationprocessesdonotguaranteeuniquenessofdomainnames;they justmakeduplicateslesslikely,andmoreeasilydetectable.
Page 13 of 53
ACCOUNTING.SOMECORP.COMandinanotherasAccounting.SomeCorp.comthetwo willnotmatch. AcompleteKerberosprincipalnametakestheformoftheprincipalname,followedby an@character,followedbytherealmname,e.g.joe@SALES.SOMECORP.COM. Althoughthislookssyntacticallylikeanemailaddress,ithasnothingtodowiththe deliveryofemail.Simpleprincipalnames(conceptuallysimilartowhatMicrosoft referstoasUserPrincipalNamesorUPNs)compriseauseridoraccountnamethatis uniquewithintherealm.Anotherformofuserprincipalcomprisesauserid concatenatedwitharolename(e.g.,admin). 4 Thisconventionallowsasingleuserto havemultipleprincipalnamesthattheycanusedependingonwhatroletheyare performing. 5 Principalnamesforservices(referredtoasServicePrincipalNames,or SPNs,inMicrosoftterminology)alwaysconcatenateoneormorecomponents;typically, oneofthesecomponentsistheFullyQualifiedDomainName(FQDN)ofthehost.This allowsmultipleservicestobeuniquelyreferenced,eventhoughtheyarehostedona singlecomputerwithoneFQDN. 6 Inmostsituations,additionalconventionsare employedtonameservicesinaconsistentmannerthroughoutanenterpriseor administrativerealm. Theimportanceofnamingconventionscannotbeoverstated,asnearlyeverythingelse intheoverallsecuritycontextdependsontheabilitytoreferenceentitiesbyconsistent names,andtofurtherbeabletoassociateattributeswiththesenames.Namingissues areofparticularconcerninmixedenvironmentswheredifferencesinnaming conventionscanleadtoseriousinteroperabilityproblems.Somepointsworthnoting aboutKerberosanditsnamingconventionsaresummarizedbelow: KerberosKDCsalsoserveasregistrarsthatguaranteeuniquenessofprincipal nameswithinagivenrealm.Notethatcomponentnamesusedtoconstructa principalarenotrequiredtobeuniquewithinarealm,butanygivensequenceof componentnamesusedtoconstructaprincipalnamemustbeuniquewithinthe realm.Failuretoassureuniquenessofprincipalnamescanleadtooperational problems,andisoneofthesourcesofproblemsinmixedenvironments. IfarealmnameisthesameasapubliclyregisteredDNSname,thentherealm namecanbeassumedgloballyunique,andbyinference,allKerberosprincipal namesincorporatingthatrealmnamewillbegloballyuniqueaswell. KerberoshasevolvedwithcertaindependenciesonDNSservicestobeableto confirmFQDNsorperformreverselookupsonIPaddressestomatchrequests againstFQDNs.WhilerelianceonDNSisusefulinanadministrativecontext,the inherentinsecurityofDNSmeansthatDNSlookupsshouldnotbeconsidered authoritativetoanysignificantdegree.
Concatenatedcomponentsofprincipalnamesuseforwardslashes(/)asseparatorsbetween componentnamesinthecurrentKerberosversion5. 5AnexampleofaprincipalnameforthepersonRobertSmith,anemployeeofGalacticIndustries Inc.mightbersmith@GII.COM,andthissamepersonmighthaveanotherprincipalnameof rsmith/admin@GII.COMforwhentheyareactingasaKerberosadministrator. 6AnexampleofprincipalnamesforemailandfileservicesonahostnamedAtlasatGalactic IndustriesInc.mightbesmtp/atlas.gii.com@GII.COMandhost/atlas.gii.com@GII.COM.

4
ThesyntacticalandsemanticsimplicityofprincipalnamesinKerberosisan advantage.Thismakesitpossibleforallothersystemstoeasilyrecognizeand parseKerberosprincipalnames. Whileitistheoreticallypossibletoencodevariousattributesaboutprincipalsby concatenatingcomponentnamesthatrepresentattributes,doingsois overloadingthesemanticsofKerberosnames,andisnotconsideredagood practice.Principalnamesshouldonlycompriseasmanycomponentsas necessarytoassureuniqueness.Inparticular,itwouldbeamistaketouse componentnamesasameansforprovidingauthorizationinformation,primarily becausenamingisnotsufficientlyflexibletoaccommodateauthorization attributes,whichmayneedtochangeonamorefrequentbasisthannames. KerberosKDCdatabasescomprisesimpledirectoriesthatmapprincipalnames toauthenticationinformation(e.g.,sharedsecrets).However,theneedtokeep KDCoperationsefficientandsecurehasbeenastrongargumentforkeepingthe KDCdatabasesimple.
Kerberos Authentication
Authenticationisessentiallyaprocessthatdeterminestheauthenticityofaclaimtosome degreeofconfidence.Usually,claimsareexpressedas,Iamthepartyknownbythisname. 7 Inordertoconfirmtheauthenticityofaclaim,anauthenticationsystemwillconduct oneormoretestsinvolvingtheclaimantorothercontextassociatedwiththeirclaim. Forexample,aclassictestofaclaiminvolvesthechallenge,ifyourethepartythatgoes bythatname,thenproveitbypresentingthepasswordwepreviouslyshared.However,many othertestscanbeused,includingothersocalledauthenticationfactors,suchasproofof possessionofsomething(e.g.,asecuritytoken)ordemonstrationofuniqueattributes (e.g.,biometricparameters).Contextualcluescanalsobeusedthatmightnotinvolve presentingachallengetotheclaimant.Examplesofcontextualcluesincludethingslike IPorMACaddresses,reverseDNSlookups,orpastpatternsofbehavior. Effectiveauthenticationinvolvesbothpositiveandnegativetests.Challengeresponse interactionsareexamplesofpositivetestssince,iftheresponseiscorrect,thenthereis positiveinformationsupportingtheclaim.Anexampleofanegativetestmightinvolve checkingtheIPaddressusedbytheclaimant.IftheIPaddressispartofthesubnet associatedwiththeclaimant,thenthereisnorealpositiveconfirmation,sinceany memberofthesubnetcouldeasilyspoofanyIPaddressinthatsubnet.However,ifthe IPaddressisfromasubnetwheretheclaimantshouldnotbelocated,thenevidenceis athandindicatingtheclaimislikelytobefalse. Traditionally,Kerberosutilizespresharedsecretstoauthenticateparties.Inthecaseof userprincipals,thepresharedsecretisderivedfromauserspassword.Serviceorhost principalsareauthenticatedthroughpresharedencryptionkeys.Unlikeother
7Notethatauthenticationisnotgenerallyidentification.Onlywhentheclaimisthatapartyisaspecific individualorthingdoesitbecomereasonabletotreatauthenticationasidentification.Normally, identificationishardforcomputers(andforpeoplewherecomputersareinvolved).Consequently, identificationisonlyemployedwhenapartyinitiallyregisters,andsubsequentlyonlysimpler authenticationproceduresareusedforefficiencyssake.
Page 15 of 53
authenticationschemesinvolvingpresharedsecrets,Kerberosonlyrequiresprincipals todisclosetheirsecretsonceatthetimeofinitialregistration.Subsequently, authenticationcantakeplacewithoutexchangingthepresharedsecret. Inthecaseofuserpasswords,someKerberosimplementationsonlyknowakeyderived fromthepassword,anddonotactuallyknowtheuserspassword.Furthermore, passwordsarenotexchangedbetweenpartiesduringauthentication.Thissubstantially reducesrisksthattheauthenticationsecretswillbedisclosedduringnormal authenticationoperations.However,ifthesepresharedsecretsareusedbynon Kerberosauthenticationmechanisms,thentheriskofexposuremightbemuchgreater. Forexample,therearesystemswhereauserspasswordmightbeusedinanother methodofauthenticationthatinvolvespassingthepasswordbetweentheuserandthe authenticatingpartywitheveryauthenticationoperation.Clearly,bestpracticesavoid situationswhereausersKerberospasswordisalsousedbylesssecureauthentication methods. ModernKerberossystemsarealsoabletoutilizeotherauthenticationtestsinaddition to,orasalternativesto,passwordsandsharedsecrets.Oneoptionistousepublickey cryptographictechniquesinconjunctionwithdigitalcertificatestoavoidanynecessity topresharesecretkeysorpasswords.Inthiscontext,onlypublickeysaredisclosed, andtheirdisclosuretootherpartiesdoesnotrepresentariskunlessthecorresponding privatekeyissomehowdisclosed.Privatekeyscanbeprotectedbyusingvarious hardwareschemes(e.g.,smartcards),includingsomehardwaredevicesthatarenow commonlybuiltintocomputers(e.g.,TPMchips).Otherauthenticationoptionsthatcan beusedwithKerberosincludeOneTimePassword(OTP)dongles,scratchcards,and biometricscanners.AnimportantimplicationisthatasystembuiltusingKerberoscan easilyaddnewauthenticationmethodswithouthavingtoreengineerthesystem.
Mutual Authentication
OneofthegreatestbenefitstousingKerberosasanauthenticationserviceisthatit providesthemeansforbothpartiesinanexchangetoauthenticateeachotheri.e., mutualauthentication.Mutualauthenticationisareadilyavailablefacilitytoany applicationthatusesKerberos.Experienceindicatesthatmutualauthenticationshould alwaysbeused,andisanimportant(necessary)bestpractice. Ithaslongbeenrecognizedthatmutualauthenticationisnecessaryforanysecure dialog.However,theasymmetricnatureofcommunicationsbetweencomputersand personshasbeenfrequentlyusedasanexcuseforallowingonewayauthentication.If thereisonelessonlearnedfromattemptstosecuresystemsitisthatanyvulnerability allowedtoexistwillbeexploited.Thishascertainlybeenshowntobethecaseforthe vulnerabilitiesassociatedwithonewayauthentication,andthesurgeofphishing attacksinrecentyearsisjustoneillustrationofthisreality. TheKerberosprotocolsresultinticketsbeingissuedtothepartyrequestingaccesstoa servicethatincludebothauthenticationinformationtheservicecanusetoauthenticate therequestingparty,aswellasasessionkeythatcanbeusedinrespondingtothe requestingparty.Iftherequestingpartyreceivesbackfromtheservicearesponsebased
Page 16 of 53
onthesessionkey,thentheyhaveconfirmationoftheauthenticityoftheservice.Thisis duetothewaythatKerberosticketsareformedbytheKDCwherethesessionkeyand userauthenticationinformationareencryptedwiththeserviceproviderskey. Therefore,whentheservicereturnsaresponsetotherequestingpartythatusesthe sessionkey,therequestingpartyknowsthatonlyaservicethatpossessesthesecretkey sharedwiththeKDCcouldhavecorrectlyrespondedhence,mutualauthentication.A furtherbenefitisthat,bycompletingthisexchange,bothpartiespossessanewshared sessionkeyknownonlytothemthatcanbeusedtoauthenticateeverymessagepassed betweenthem,andeventoestablishanencryptedsession. 8
Source Authentication
Sofar,onlyonetypeofauthenticationhasbeendiscussedtheauthenticationofpeer entities.Anothertypeisknownasdataoriginorsourceauthentication,andinvolves claimsofthesort:thisdataisprovidedbyaspecificnamedparty.Kerberosalsoprovides supportforthissecondtypeofauthentication. OnemeansofferedbyKerberosforauthenticatingthesourceofinformationisprovided throughexchangeofasecretsessionkeybetweenaclientandservice.Ifthesessionkey isusedtoencryptinformationexchangedbetweentheparties,orinproducingkeyed hashesoftheinformation,theneitherpartyknowsthatonlyapartyinpossessionofthe sessionkeycouldhaveprovidedtheinformation.Inessence,everymessagecanbe sourceauthenticatedthroughuseofthesessionkey.Again,bestpracticescallforboth partiestoutilizethesessionkeytoauthenticatesubsequentexchangesofinformation. Ifservicesaredeliveredinadistributedmanner,asingleclientmaybecommunicating withmultipleserviceprovidersatthesametime.Kerberossupportsmultiple mechanismsforclientstoestablishdistinctsessionkeyswitheachserviceprovider, whichallowsthesourceororiginofdatatobeauthenticatedineachcase. SourceauthenticationisalsoprovidedforticketresponsesissuedbyaKerberosKDC, sincetherequestingparty(client)candeterminethattheresponsewasencryptedwitha keyknownonlybytheKDCandclient,andsimilarly,theserviceprovidercan determinethattheticketwasencryptedwithitssecretkeythatwaspreviouslyshared withtheKDC.ThisformofsourceauthenticationisaninherentfeatureoftheKerberos protocols.Italsomeansthatotherinformationintheticketencryptedwiththepre sharedsecretisknowntohaveoriginatedfromtheKDC.Thisallowsticketstobeused asauthorizations,andtheycanbeusedtocarryadditionalauthorizationinformation (seeKerberossupportforAuthorizationbelow)
Data Integrity and Confidentiality

Kerberosalsoprovidesthemeansfordeterminingthatdatacontainedinticketshasnot beentamperedwithoralteredsincetheticketwasgeneratedi.e.,dataintegrityis assured.Thisisessentialtopreventthirdpartiesfrommanipulatingticketsasameans
TheoriginalsessionkeyisalsoknowntotheKDC.However,applicationstypicallyestablishanew sessionkeythattheKDCcouldonlylearnbyobservingtheexchangebetweenpartieswhenmutual authenticationisused.
8
ofunderminingauthenticationprocedures,orchangingauthorizationinformation.In particular,aclientrequestingatickettoaccessaservicecannotmanipulatetheportion oftheticketintendedfortheserviceprovidertoauthenticatetheclient,sincethis portionoftheticketisencryptedwiththesecretkeyknownonlytotheserviceprovider andtheKDC. Assumingthattheclientandservicecompletetheexchangeofasessionkey,thenthis sessionkeycanbeusedtoprovidedataintegrityforsubsequentexchangesbetweenthe parties.Dataintegritycanbeprovidedbycomputingahashofthedatathatiskeyed usingthesessionkey(e.g.,useofanHMACfunction).Thisisthesamemechanismused toassuresourceauthentication.Ifthesessionkeyisinsteadusedtoencryptdatasent betweentheclientandservice,thenconfidentiality,dataintegrity,andsource authenticationareallprovidedasabyproductofencryptingwithasecretknownonly tothetwoparties.
Replay Prevention in Kerberos

SinceKerberosticketsareexchangedoveruntrustednetworks,attackersmustbe preventedfromreplayingticketstointerposethemselvesasapparentlyauthenticated parties.Originally,KerberosticketsincludedtheIPaddressesoftherequestingclient andtheservice,whichprovidessomelimitedprotectionagainstreplayattacks. However,modernKerberosimplementationsemploytimestampstolimitthevalidity intervalofticketstoonlyafewminutes,whichhelpspreventreplayofticketsexcept duringthisnarrowtimewindow.ThisassumesthatallparticipantsinKerberos protocolexchangeshavesomemeansofmaintainingtimesynchronizationwithinat leastafewminutes. 9 Inaddition,servicesaresupposedtomaintainacacheoftickets seenwithinthewindowoftimethatticketscanbevalid.Thisallowsaservicetodetect anyreplayattemptswithinthistimewindow.Useofclientspecificsessionkeysis anothereffectivetechniqueforpreventingreplays.Bestpracticesrequireallservices thatrelyonKerberostoimplementcountermeasuresagainstreplayattacks.
Non-Repudiation Support in Kerberos

TheexchangeofsessionkeysandtimestampsinKerberosticketsthataregeneratedby thethirdpartyKDCalsoprovidesbasicnonrepudiationprotections.Repudiationis definedasonepartydenyingparticipationinallorpartofacommunicationsdialog withanotherparty. 10 Inessence,theKDCservesasathirdpartywitnesstothe establishmentofthesessionbetweenclientandservice.However,thisonlyprotects servicesfromattemptsbyclientstorepudiatethattheyrequestedaccesstotheservice. ClientscannotrelyontheKDCtovouchforwhetherornotaserviceeverrespondedto
9UseofNTPservicesisacommonmeansforachievingtimesynchronization,butcaremustbe takentopreventattacksthatforceasystemtoupdateitsclocktoanearliertimewhenreplayed ticketswouldstillbevalid.Inpractice,systemsthatrelyonNTPshouldavoidresettingtheirlocal clocksbackwardsintimetosynchronizewithanNTPserver.UseofNTPsecurityoptionsisalsoa recommendedpractice. 10Repudiationmightconsistofclaimsbyclientssuchas,Ididnotattempttoaccessthatservice,orI didnotattempttoaccessthatserviceatthattime.
Page 18 of 53
aclientrequest.Furthermore,thislimitedformofnonrepudiationisnotequivalentto theprotectionsofferedbyelectronicnotaryservicesthataredesignedtodealwith complexrepudiationscenarios. Thechiefbenefitofthislimitedformofnonrepudiationprotectionisthatitcan enhancethecredibilityofsystemlogsthatindicatewhichclientsaccessedwhich servicesandapproximatelywhentheaccessattemptsweremade.Thisimprovesthe integrityofauditproceduresandthestrengthofauditcontrols.However,forthistobe effectiveprotection,boththeKDCandserviceneedtokeeplogrecordsofeveryrequest fromaclient,whatservicetheclientrequestedaccessto,whentherequestwasmade, andtheactualticketissued.Sincetheticketisencryptedwiththekeysharedbythe KDCandservice,neithercouldchangetheticketwithoutcausingadiscrepancyinthe logrecordskeptbyeach.TheKDCwillalsoneedtokeeplogrecordsofrequestsfrom clientsforticketsasencryptedintheTGTsessionkey,aswellaslogrecordsforinitial authenticationsandTGTticketsissued.ItisstandardpracticeforKDCstologthis information. Ifaclientlatertriestorepudiatethattheyrequestedaccesstoaspecificservice,thenthe KDChasproofthattheclientmadearequestforthetickettothatservice.Iftheservice getstheticket,itcouldhaveonlycomefromtheclientbecausetheclientsauthenticator willhavebeenencryptedinthesessionkeyestablishedbytheKDCfortheclientand servicetouse.Iftheserviceisabletodemonstratethatitslogrecordoftheticket matcheswhattheKDCloggedfortheticket,thentheservicedidnotgeneratetheticket onitsown.Furthermore,theclientcouldonlyhavemadetherequestforaccesstothe serviceafterthetimeitrequestedtheticketfromtheKDC,whichpartiallyprevents repudiationclaimsastowhentheclientmadetherequest.
Kerberos support for Authorization

AlthoughKerberosisprimarilyanauthenticationservice,itdoesprovidebasic authorizationservicesforprincipalsregisteredwithintheKDCdatabase.Unlesssome authority(usuallyahumanbeing)hasregisteredaprincipalbyenteringtheirprincipal nameintotheKDCdatabasethroughsomeadministrativeprocedure,theprincipalwill notbeknowntotheKDC,andwillnotbeabletousetheservicesoftheKDCto authenticatetootherprincipals.Consequently,onlyauthorizedprincipalsareincludedin theKDCdatabase,andpresumably,authoritieswithadministrativeaccesscanalso removeprincipalsfromthedatabasetodeauthorizethem. Furthermore,KerberossupportsrudimentaryauthorizationserviceswhenissuingTicket GrantingTickets(TGTs)andforsessionestablishmentbetweenclientsandservices servicesthatareprovidedonlytoauthorizedprincipals.Kerberosalsoprovidesfacilities forsecurelypassingauthorizationinformationtoservices.Theseauthorizationservices aredescribedinthefollowingsubsections.
TGT Authorization
WhenclientsinitiallyauthenticatewiththeKerberosAuthenticationService(normally,a subsetoftheKDCservices),theyreceivebackTGTsthatareusedasauthorizationsto conductsubsequentrequestsforticketstoaccessotherservices.Thisisthewaythat
KerberossupportsSingleSignOn(SSO)sothataclientneedonlyauthenticateonce, andcanthensubsequentlyaccessotherserviceswithouthavingtopresenttheir passwordorotherauthenticationinformationeachtime. TheTGTreturnedbytheKDCtoaclientrequestinginitialauthenticationestablishesa session(seeSessionAuthorizationbelow)betweentheclientandtheTicketGranting Service(TGS)alsotypicallydeployedasasubsetoftheKDC.Thissessionisbasedon anewsecretsessionkeysharedonlybetweentheclientandtheTGS(a.k.a.,theKDC). TheTGTisatimelimitedauthorizationwherenormallythetimelimitisatleastseveral hours,butrarelymorethanaday. MutualauthenticationbetweentheclientandKDCistypicallyestablishedaspartof obtainingtheTGT. 11 Thisexchangeassuresbothpartiesthattheotherpartyknowsthe previouslysharedsecret(e.g.,theclientpassword).Furthermore,byestablishinganew secretsessionkeybetweentheclientandKDC,theclientneedonlyexposeitscopyof thepresharedsecretjustlongenoughtodecrypttheTGTreceivedbackfromtheKDC aspartoftheinitialauthenticationexchange.Inaddition,dataintegrityisassuredsince allsubsequentrequestsfromaclienttotheKDCforserviceticketsandresponsesfrom theKDCbacktotheclientwillbeencryptedwiththeTGTsessionkey.Replay protectionisprovidedbyrequiringclientstoprovidetimestampedauthenticatorsin eachrequestforanewserviceticketthatmakeeverysuchrequestunique. WhenaclientwantstoaccessaserviceinanotherKerberosrealm(seeCrossRealm Authenticationbelow),itobtainsfromtheKDCintheclientsrealmaTGTitmayuse withtheKDCintheservicesrealmtothenrequestaticketfortheservice.This effectivelyextendsauthorizationfromtheclientsKDCtotheremoteKDCrealmand allowstheclienttoestablishanauthorizedsessionwiththeremoteKDCforrequesting tickets.Notethatthisdescriptionofcrossrealmaccessissimplistic,buttheconcepts holdinscenariosthataremorecomplex.
Session Authorization
Kerberosalsoprovidesbasicauthorizationservicesforestablishingcommunications sessionsbetweenprincipals.Infact,Kerberosticketsaresecuredauthorizationsthata serviceproviderusestoauthorizeestablishmentofacommunicationssessionwitha client.TheauthorizingpartyistheKerberosKDCthatissuesticketstoclients.However, thetrueauthorityisthepartyresponsibleforenteringthenamedprincipalinthe KerberosKDCdatabaseofauthorizedusersandservicesi.e.,theregistrationauthority.If apartydoesnothaveaprincipalnameintheKDCdatabase,thatpartyisnot authorizedforanyservicethatdependsonKerberosforauthentication. AcommonstatementaboutKerberosisthatitonlyauthenticatesprincipalstoeach other,andthatauthorizationisadecisionmadebytheprincipalsbasedonsome applicationcontext.ThisisbecauseKerberosrealmsmayhaveveryliberalpoliciesfor
TheclientalwaysauthenticatestheKDCinthefirstexchange.TheKDCcanuseafacilitycalled preauthenticationtoauthenticatetheclientbeforeissuingtheticket,ortheKDCcanwaituntilthe clientfirstusesthetickettoknowthatitwasabletosuccessfullydecrypttheticket.Currentbest practiceistousepreauthentication.
11
whatprincipalsareregistered.Forexample,arealmmayregisteranyunusedusername basedonarequestatawebpage.WorkisongoingtoallowanonymousKerberos authenticationwithoutregistrationinanyKDCdatabase.Similarly,somerealmshave veryliberalpoliciesaboutwhatservicesareregistered.Asaresult,application designerscannotmakeanyassumptionsaboutauthorizationsimpliedbyregistrationin aparticularrealm;potentiallyanyentitythatrequestedsuchregistrationmaybeableto obtainitinsomerealms. Ontheotherhand,settingpoliciesforwhatprincipalsareregisteredinarealmisa powerfulaccesscontroltoolforITadministrators.Whenaclientpresentsatickettoa service,theserviceispresentedwithinformationthatnotonlyauthenticatesthenamed principal,italsoindicatesthattheclientprincipalisregisteredintheKDCdatabase. Theservicereceivingaticketfromarequestingclientmustdecidewhetherornotto establishcommunicationswiththeclientbasedontheticketcontents,andanyother informationtheservicemayhaveathand(e.g.,alistofprincipalsauthorizedtousethe service).However,thisdecisionwillbebasedinpartontheticketthatisissuedbythe KDC,whichis,infact,anauthorizationissuedbytheKDCstatingthattheprincipalis anauthorizedpartywithintheKDCdatabase. Section1.4ofRFC4120advisesthatApplicationsshouldnotacceptthemereissuanceofa serviceticketbytheKerberosserver(evenbyamodifiedKerberosserver)asgrantingauthority tousetheservice.Thisissoundadvice,sinceauthorizationtoestablishasessionisnotthe samethingasauthorizationtousetheservice.Onlywithinaspecificapplicationand policycontextcanrationaldecisionsbemaderegardingappropriateauthorizations.At thesametime,effectiveaccesscontroloftendependsonmultiplelevelsof authorization,andsessionauthorizationisausefulfirststepinanaccesscontrol strategy.Insomespecificcases,suchasremoteaccesstoanetwork,itmayevenbe sufficient.ApplicationdesignersshouldprovidetoolsthatmakeiteasyforIT administratorstotakeadvantageofthislevelofauthorization;forexample,insome casesitmaybedesirabletograntaccesstoallprincipalsinarealm.
Authorization Information passed by Kerberos

Kerberoscanalsoplayasupportingroleinaccesscontroldecisionsbypassing authorizationinformationsecurelytoaservicewithinaticketusedtoauthenticateaclient requestingaccesstotheservice.TheKerberosprotocolspecificationsprovidefortwo classesofauthorizationinformation.ClientsorKDCscanaddrestrictionstotickets restrictingthecontextinwhichtheticketisvalidortheaccessthatshouldbegrantedto apartyauthenticatingwiththisticket.Inaddition,KDCscanaddauthorization informationgrantingadditionalprivilegesordescribingauthorizationattributesofthe entitythattheclientprincipalnames.Facilitiesareprovidedsothatclientscannotcreate thesecondtypeofauthorizationinformation.WhiletheKerberosprotocol specificationsdonotindicatehowthisauthorizationinformationistobeused,oreven allthedetailsofhowtheinformationisstructured,thisoptioncanbeusedtoextendthe utilityofKerberosservicesinmanagingaccesscontrol.Sincetheticketisencrypted withthepresharedsecretkeyknownonlytotheserviceandtheKDC,theserviceis abletotrusttheinformationinthisticket,bothtoauthenticatetheclientandthe authorizationgrantedtotheclient.
Forexample,whenaclientrequestsaserviceticket,iftheKDCincludesalistofgroups thisclientprincipalbelongstointheauthorizationdatafieldoftheticket,thenthe servicewillbeabledeterminewhatresourcestheclientisallowedtoaccessbasedon groupmemberships.ThisveryschemeiswidelydeployedbyMicrosoftaspartofits WindowsServerplatforms.Otherexamplesofauthorizationdatathatcouldbepassed withinaticketincludetimeofdayrestrictions,subscriptioninformation,transaction limits,orusagequotas. MicrosoftsuseofKerberosasameanstopassgroupmembershipsandotheraccount informationinserviceticketsisthemostwidelydeployedexampleofextending Kerberosinthismanner.Theauthorizationdataispackagedintoastructureknownasa PrivilegeAttributeCertificate,orPAC(refertothesectionKerberosandtheMicrosoft PrivilegeAttributeCertificate(PAC)below).InaMicrosoftservercontext,theKDCisa subsetofaDomainController,andsinceDomainControllersmaintainaccountsforall usersandsystemsoperatingwithintheDomain,itisfeasibleforthePACtobeinserted inserviceticketswhenclientsrequestaccesstoservices. Oneconcernwithtrustingauthorizationdatainticketsisthataservicecouldgenerate ticketstoitself.ThisisbecausethekeyssharedbetweenservicesandKDCsare symmetricencryptionkeys,whichalloweithersidetoencryptthedata.Thisallowsthe servicetotrustaticketreceivedfromaKDC,sinceonlytheKDCshouldknowthe secretkey.However,aservicecouldgenerateitsownticketusingitskey.Whilethis doesnotundermineKerberosauthentication,theabilitytogeneratenewticketscould beusedtoelevateprivilegesifauthorizationinformationintheticketistrustedbya partyotherthantheserviceforwhomtheticketisissued.Toavoidthispotential exposure,softwaresuchasthelocaloperatingsystemthatwishestouseauthorization informationfromaticketissuedtoanotherserviceshouldconfirmauthorization informationwithatrustedsourcebeforemakingaccesscontroldecisionsbasedonthis information.Forexample,MicrosoftaddressesthisproblembyhavingtheLocal SecurityAuthorityconfirmPACsreceivedbyunprivilegedserviceswiththeDomain ControllerviaanindependentsecurechannelestablishedusingtheirNetlogonfacility.
Integrating Kerberos into Applications

TheprocessofintegratingKerberosintoanapplicationiscolloquiallyreferredtoas Kerberizinganapplication.Thecompaniondocument,BestPracticesforIntegrating KerberosintoYourApplication(pdf),providesacomprehensiveguidetoapplication integrationissues.However,abriefreviewofintegrationoptionsisprovidedhereto helpclarifytherolethatKerberosplaysinothersystemapplications,especially directoryservices,whichwillbediscussedingreaterdepthinTheRoleofDirectory Servicessectionbelow.
The GSS-API and Kerberos

TheGenericSecurityServicesApplicationProgramInterface,orGSSAPI,wasdevelopedas awaytodecoupleapplicationsfromunderlyingsecurityservices,especially authenticationmethods.KerberosandGSSAPIarecloselyrelated,eventhoughthe GSSAPI(ref.RFC2743)isdesignedtoallowanyauthenticationtechnologytobeused
byanapplication.ItjusthappensthatKerberosisthedominantauthentication technologyusedwithGSSAPI.Furthermore,theGSSAPIhasbecomethestandardized APIforKerberos(ref.RFC4121),sincetheKerberosprotocolspecificationsdonot defineanyAPIs,andvariousKerberosimplementationsutilizeincompatibleprogram interfaces. TheGSSAPI,whenusedwithKerberos,actuallydefineswirelevelprotocolsthatare exchangedbetweenpartiesusingGSSAPIsothatdataconfidentialityandintegrity assurancecanbeprovidedinadditiontoauthentication.Inthissense,itismorethan justanAPI.Animportantimplicationisthatapplicationscouldbebuiltthatare compatiblewiththewirelevelGSSAPIKerberosprotocols,butthatdonotactuallyuse theapplicationprogramminginterfacedefinedbytheGSSAPIe.g.,Microsofts SecuritySupportProviderInterface,orSSPI. 12 Eventhoughtheprogramminginterfaces providedbytheGSSAPIandMicrosoftsSSPIarequitedifferent,itisstillrelatively straightforwardtobuildapplicationsusingoneAPIthatwillinteroperatewith applicationsusingtheotherAPI.However,duetofundamentaldifferencesinapproach, itisalsopossibletobuildGSSAPIapplicationsthatcannotbemadetointeroperate withSSPIapplications,andviceversa. TheSimpleandProtectedNegotiation,orSPNEGO,mechanism(ref.RFC4178)canbe usedtoextendGSSAPIandisalsousedwithMicrosoftsSSPI.SPNEGOisactuallya pseudomechanism(orpseudoservice)thatallowspartiestonegotiatewhatsecurity servicestheycanbothsupport.Inotherwords,SPNEGOusesthesecurityservicesofan underlyingmechanism,suchasKerberos,toprovidethesecurityserviceofprotected negotiationtoanapplication.Theapplicationselectsthedesiredunderlyingsecurity servicewhileminimizingthepossibilitythatanattackercandisruptthenegotiation.An importantbenefitofusingthisformofnegotiationisthatithelpseasethetransition fromlesssecureauthenticationservicestowardmoresecureservices,suchasKerberos. Consequently,inanenvironmentwhereapplicationsbasedontheGSSAPIhavebeen deployed,newauthenticationservicescanbeintroducedinsuchawaythatstronger servicesarepreferredandolder,lesssecureauthenticationservicescanbephasedoutin agracefulmanner.
SASL and Kerberos

TheSimpleAuthenticationandSecurityLayer,orSASL,frameworkwasintroducedasa waytofurtherinsulateapplicationsfromunderlyingauthenticationandothersecurity services(ref.RFC4422).SASLprovidesanapplicationframework(morethanjustan API)thatsimplifiesbuildingsecureapplicationsthatonlyneedasimple,bidirectional streamorientedcommunicationsfacilitybetweenpeers.Itisparticularlyeffectiveat allowingapplicationstosimultaneouslysupportvariousauthenticationmechanisms withoptionalconfidentialityandintegrityassuranceservices.SASLusestheGSSAPI forKerberosauthenticationsupport,andoptionallyfordataconfidentialityand
MicrosofttendstodescribeapplicationsthatarecompatiblewithGSSAPIwirelevelprotocolsas GSSAwareapplications.TheSSPIinterfaceisaproprietaryMicrosoftspecificationdescribedin thisdocument:http://msdn.microsoft.com/enus/library/aa380493.aspx
12
integrity.ItisalsocommonforSASLapplicationstosupportTLS(SSL)asanalternative meansforprovidingdataconfidentialityandintegrityprotection. SomepopularInternetapplicationsthatareavailableinSASLbasedversionsinclude: BEEP:BlockExtensibleExchangeProtocol,whichisitselfaframeworkfor applicationsthatneedtoexchangeblockorientedmessagesandmanage queriesandresponses IMAP:InternetMessageAccessProtocol,whichisapopularprotocolfor emailclientstointeractwithemailservers,includingMicrosoftExchange servers LDAP:LightweightDirectoryAccessProtocol,whichisthefoundationfor mostofthemoderndirectoryservices,includingMicrosoftsActiveDirectory POP3:ThewidelyusedPostOfficeProtocol(version3)usedbyemailclients todownloademailfromservers SMTP:SimpleMailTransferProtocol,thepushprotocolusedtosend(and receive)emailfromclientstoserversandtoexchangeemailbetweenservers XMPP:eXtensibleMessagingandPresenceProtocol,aninstantmessaging protocolusedinJabberandotherIMapplications,suchasPidgin
KerberosiswidelyusedbySASLversionsoftheemailprotocolsandLDAPdirectory services,aswellassomeapplicationsbasedonXMPP.
Channel Binding
Amorerecentapproachtoallowingauthenticationmethodstobeusedinconjunction withothersecurityprotocolsistermedchannelbindingandisdescribedinRFC5056. Channelbindingallowsamutualauthenticationexchangetoauthenticateasecure channelbetweenthepartiesaswellasthepartiestoeachother.Thisisusefulwhere applicationsmayhaveaccesstosecureprotocolservices,orchannels,suchasTLSor IPsecthatcanbeusedforcommunicationsbetweenparties.Theproblemis:howdo applicationsknowthatthepartytheyhaveauthenticatedisalsothepartyontheother endofthesecurechannel?Ifthechannelcanbeuniquelyreferenced,andsomechannel identifiercanbeincludedintheauthenticationexchange,thenitispossibletobind thechanneltothemutuallyauthenticatedsessionbetweentheparties.Inotherwords, theywillknowthatthepartytheyhaveauthenticatedisalsothepartyontheotherend ofthesecurechannel. ChannelbindingprovidesamoregeneralapproachthanwhatisprovidedbytheSASL frameworkwhereitisdesirabletouseKerberoswithothersecurityservices,suchas TLSorIPsec.Whilenotwidelydeployedyet,thisapproachislikelytobecomeabest practicefordeployingsecureapplicationsthatneedflexibleapproachesfordecoupling authenticationfromothersecurityservices.
Pluggable Authentication Modules (PAM)

ThePluggableAuthenticationModules(PAM)frameworkwasoriginallyproposedby Sunasamechanismtodecoupleauthenticationfromloginapplications.PAMwas
originallyproposedaspartoftheCommonDesktopEnvironment.Sincethen,PAMhas gainedacceptanceonmostLinuxandUNIXplatforms. PAMprovidessystemadministratorswithaconfigurationfileallowingthemtospecify whatPAMmodules(andthuswhatauthenticationmechanisms)areused.Applications suchastheGnomeorKDEloginscreencallintoPAMwithauseridandpassword. PAMrunsthrougheachoftheconfiguredmodulesinseries,allowingthemtointeract withtheauthenticationprocess.Modulescanaskforadditionalinformation(e.g.,aone timepasswordchallenge)fromtheuser.Modulescanindicatethatauthenticationhas failedorindicatethatthecurrentmodulehassucceeded.Typically,ifallmodules succeed,thenauthenticationissuccessful.PAMalsoprovidessomefacilitiesforsession managementandauthorization. MostLinuxdistributionsandSolarisincludeaPAMKerberosmodule.Thismodule performsKerberosinitialauthenticationandobtainsKerberosticketsfortheuser.Often thesemodulesareusedtoauthenticateausertothelocalmachine:iftheuserisableto obtainKerberostickets,thenthemachinerunningthePAMmodulehasconfidencethat theKerberosprincipalisanamefortheuser.Togainthisconfidence,thePAMmodule musttaketheresultingKerberosTGTandusethistickettoauthenticatetosomeservice (e.g.,thehostprincipalorcomputeraccount)onthelocalcomputer.Thisisbecausethe initialKerberosexchangeauthenticatestheuserandKDCtoeachotherbutdoesnot authenticatethelocalmachinetoeither.Consequently,inordertohaveconfidencethatthe useriswhotheyclaimtobe,thelocalmachinemustberegisteredasaKerberosservice. PAMservestworolesinKerberosenvironments.First,itservestheroledescribed above:authenticatinglocalusersofLinuxandUNIXenvironments.However,PAMcan alsobeusedwithnetworkapplicationstoallowuserstouseKerberosprincipalsand thecorrespondingpasswordtoauthenticateoverthenetwork.Thisisverydifferentfrom thewayGSSAPIorSASLuseKerberos.GSSAPIdoesnotsendthelongtermshared secretoverthenetwork;insteadtheKerberosapplicationauthenticationexchangeis usedtoproveknowledgeofthesessionkeyassociatedwithaticket.Consequently, GSSAPIrequiressupportintheclientapplication.WhenPAMisusedfor authenticationwiththenetworkapplication,theserverreceivesthelongtermpassword andKerberosexchangesareperformedontheserverinordertoconfirmthatthe suppliedpasswordiscorrect.UnliketheGSSAPIcase,thePAMapplicationneedstobe trustedwiththeuserslongtermsecret.Inaddition,thesecretislikelytobeintercepted asitistransmittedoverthenetwork.Clearly,usingPAMwithnetworkapplications doesnotprovidethesecurityadvantagestypicalofKerberos.However,itdoesallow theKerberosinfrastructuretobeusedevenwhenclientsdonotdirectlysupportit.Best practiceistopreferclientsidesupportforKerberostotheuseofPAMfornetwork applications. PAMmodulesarealsoavailabletomovefromotherauthenticationsystemsto Kerberos.Thesemigrationmoduleswilltakeasupplieduseridandpasswordthathas alreadybeenverifiedbyaPAMmodulefortheexistingauthenticationinfrastructure andregistertheprincipalintheKDCdatabase.Themigrationmoduleneedstobe trustedtoregisterprincipalsintheKerberosdatabase.Typically,thistrustislimitedby allowingthemoduletocreatenewprincipalsbutnottomodifyexistingprincipals.
Unfortunately,whilePAMisavailableonmanyplatforms,therearesignificant differencesinhowPAMworksoneachplatform.Multipleattemptshavebeenmadeto standardizePAM,buttheimplementationsinusetodaydonotmatcheachotherorthe standards.Asaresult,systemadministratorsandapplicationdevelopersshouldbe carefultoconsultthedocumentationforPAMontheirplatform.
Kerberos and Public Key Cryptography

Kerberoswasdevelopedbeforeasymmetric(a.k.a.,publickey)cryptographywasaviable technologyfordeploymentincommerciallyavailablesystems.Consequently,Kerberos authenticationisbasedonuseofsymmetriccryptography.Theimplicationisthat symmetricencryptionkeysmustbeexchangedbetweenpartiesasaprerequisiteto beingabletoperformauthentication.Forhumanusers,passwordsareusedtoderive symmetricencryptionkeysforauthenticationandexchangeofsubsequentsessionkeys. Inpractice,everyuserandserviceprincipalmustgothroughaninitialsetupprocess wherepasswordsorsymmetricencryptionkeysareexchangedwithaKDC.Whilethis canbedonesecurelywithproperprocedures,itisstillanadministrativeheadache. Furthermore,thesharedsecretkeycanbecompromisedbyeitherparty.Changing passwordsandkeyscanalsobeaburdenforusersandsystemadministrators. Theappealofasymmetriccryptographyisthattherearetwokeys,whereanything encryptedwithonekeycanonlybedecryptedwiththeoneandonlycorresponding key.Whenasymmetrickeypairsaregenerated,itiscommonpracticetotreatoneasa publickeythatcanbefreelysharedwithotherpartieswhiletheotherkeyinthepair iskeptasaprivatekeythatshouldnotbesharedwithanyotherparties.Thisgreatly simplifieskeysharing,sincethepublickeycanbefreelyexchangedbetweenparties providedtheprivatekeyisnotdisclosed. Theprimaryconcernwithdistributingpublickeysisdeterminingwhetherornota publickeyreallybelongstoaspecificparty.Thisisgenerallysolvedthroughuseof publickeycertificates(ref.RFC5280),whichincludethenameoftheparty(subject)and theirpublickeyinadocumentthatisdigitallysignedbysomeCertificationAuthority orCA.AnypartythatreceivesacertificatecanvalidatetheCAssignaturetoconfirm thatthepublickeyreallybelongstothesubjectnamedinthecertificatepresuming,of course,thattheCAthatissuedthecertificateisconsideredtrustworthy. Overthepastdecade,asymmetriccryptographyandpublickeycertificateshave becomewidelysupportedtechnologiesthatarenowbuiltintomostcomputing platforms.Furthermore,Kerberoshasbeenextendedtotakeadvantageofthese technologies,primarilyforinitialauthenticationofusersrequestingTGTs,thoughother extensionshavebeenproposedforincludingpublickeycertificatesinKerberostickets.
PKINITPublic Key Cryptography for Initial Authentication in Kerberos

RFC4556(PKINIT)specifiesextensionstoKDCAuthenticationServicesthatallow clients(users)tobeinitiallyauthenticatedbypresentingtheirpublickeycertificates insteadofusingpreviouslysharedsecretpasswords.Onlytheinitialauthentication procedureischanged;allotherKerberosinteractionsremainthesame.Inparticular,
clientscontinuetoreceiveTicketGrantingTickets(TGTs)thatwillbeusedto subsequentlyrequestticketsforservices,andservicescontinuetoauthenticateusersvia ticketsissuedbyKDCs.Aservicehasnoneedtosupportpublickeycryptography,or evenknowhowtheclientinitiallyauthenticatedtotheKDC.Fromanapplication perspective,clientandserviceinteractionsareexactlyasbefore. AnimportantconsequenceofusingPKINITisthatuserscanmoreeasilybegivenan accountinarealmtheyhavenevervisitedbefore.Ifanemployeeorcontractorwitha trustedcertificatemovestoanewpartofanorganization,theiraccountcanbewaiting forthemwithnoneedtoregisteranewpassword.Furthermore,useofpublickey certificateshelpsmitigateriskswithweakuserpasswords,sincetheusersprivatekeyis usedduringinitialauthenticationinsteadofapassword.Ausermaystillentera password,butonlyontheirlocalworkstationordevicetounlocktheprivatekey. Passwordchangestendtobehandledattheuserdevicelevel,anddonothavetobe coordinatedwithothersystems. Atleasttheoretically,usingPKINIT,userprincipalsnolongerneedtoberegisteredin theKDCdatabasebeforeinitialauthentication,sincetheKDCdoesnotneedtolookup thecorrespondingsharedsecretforauserwithacertificate.Serviceprincipalsmuststill beregisteredintheKDCdatabasealongwithasharedsymmetricencryptionkey.A KDCdatabasecouldbemuchsmaller,sincetheretendtobemoreuserprincipalsthan serviceprincipals.However,inpractice,usersstillneedtoberegisteredtostorepolicy andotherinformation.Alsoasdiscussedbelow,entitlementinformationandother attributesaboutauseraretypicallystoredinsomedirectory.PKINITdoesnotreduce theneedforthisinformation.WithPKINIT,theadministrativeoverheadfor maintainingtheKDCdatabaseshouldbereduced,anduserpasswordchangeswould nolongerneedtobesupportedforuserswithcertificates.Fororganizationsthat alreadyissuecertificatestousers,itispossibletoallowuserstoauthenticatewiththeir certificateacrossmultipleauthenticationsystems,includingsystemsthatuseTLS/SSL andvariousVPNtechnologiesinadditiontoKerberos.Atthesametime,applications basedonKerberosdonotneedtobechanged. Anotherbenefitisthatcertificatescanbeassociatedwithhardwarecryptographic tokens,includingsmartcardsandUSBdeviceswithembeddedsmartchips.Some biometricauthenticationdevicescanalsobeusedwithcertificates,butwherethe biometricdeviceisusedtounlockaccesstotheusersprivatekey. Ofcourse,thesebenefitscomeattheexpenseofdeployingaPublicKeyInfrastructure (PKI)thatincludesCertificationAuthorities(CAs),certificaterequestandissuing services,certificaterevocationprocedures,statuscheckingservices,anddirectoriesfor retrievingcertificatesforspecificusersorotherprincipals.However,PKIhasbecomean integralpartofseveralvendorplatforms,anditiswidelyavailable.Inmany environments,theadvantagesofpublickeycryptographyandcertificatesmorethan justifytheaddedburdenofdeployingandmaintainingaPKI.Alternatively,PKINITcan beusedwithoutaPKI.TheKDCdatabasecanstoreselfissuedcertificatesassociated withuserprincipals.ThisavoidsrelianceonaCA,sincetheKDCcantrustapublickey initsdatabase,andnopasswordsecretisneededfortheuser.However,other
Page 27 of 53
advantagessuchaseasymigrationbetweenrealmsandsupportforapplicationsbeyond KerberostendtorequireaPKI. Oneconcernwithcertificatesusedinauthenticationisthattheytendtohaverelatively longlifetimesontheorderofmonthstoevenacoupleofyears.Thisleadstogreater exposureswhenprivatekeysarecompromised,orauserscertificateneedstobe revokedforsomecause.ThismeansthataKDCmightallowauserwitharevoked certificatetoauthenticate,andsubsequentlyaccessapplicationservices.Therearetwo approachesformitigatingthisrisk,(1)distributionofCertificateRevocationLists (CRLs)and(2)useofOnlineCertificateStatusProtocol(OCSP)services(ref.RFC2560). UseofOCSPservicesisparticularlyattractive,asitallowscertificatestatustobe checkedinrealtimeaspartoftheinitialauthenticationprocess.RFC4557specifieshow PKINITcanbefurtherextendedtointegrateOCSPchecksduringKerberosinitial authentication.
Support for Multiple Kerberos Realms

AKerberosrealmmustbeadministeredasasingledatabaseofprincipalsand associatedkeys.Foreachrealm,thereissomeregistrationprocessthatenrolls principalsintotherealmsdatabase,andonlytheseenrolledprincipalsareableto authenticateeachother.Althoughanenterprisemaychoosetohaveonlyasinglerealm, practicalconsiderationsoftenresultinmultiplerealmsbeingestablishedunder differentadministrativeregimes.Whilehavingseparaterealmsfordifferent administrativeregimessolvessomeproblems,italsoleadstoadditionalcomplexityand newproblems. Beforediscussingsupportformultiplerealms,itisworthrestatingthatasinglerealm canbesupportedbymultipleKDCs.Thismaybedonetoimproveavailabilityby havingredundantKDCsorKDCsthataredistributedclosertousersandservices.In somecases,itmayalsohelpimproveperformancebyhavingtheworkloaddistributed acrossmultipleKDCs.However,allKDCswithinarealmusethesameKDCdatabase, whichmustbereplicatedfromamasterKDCtoallotherKDCsintherealm.Thereason foremphasizingthispointisthatotherdeploymentstrategiesduplicaterealmsalong withKDCs.Inparticular,aMicrosoftActiveDirectorydeploymentwilltendto distributeDomainControllersinmuchthesamewaythatKDCsmightbedistributed. However,whileaDomainControllerisalsoaKDC,eachDomainisalsoaseparate Kerberosrealmwithitsownsubsetofprincipalsthatareallowedtoauthenticatetothe Domain.
Cross-Realm Authentication
Whenmultiplerealmsareusedtosupportasharedpopulationofusersandservices, theobviousproblemthatemergesishowaclientinonerealmcanauthenticatetoa serviceinanotherrealm,andviceversa?Kerberossolvesthisinadirectmannerby makingtheTicketGrantingService(TGS)ofonerealm,aprincipalintheotherrealm. Then,whenaclientwantstoaccessaserviceinanotherrealm,itfirstasksaKDCinits realmforatickettotheTGSoftherealmwheretheserviceresides.Technically,clients makethisrequesttotheTicketGrantingServiceassociatedwiththeirKDC,butsince
theTGSisessentiallyalwayspartoftheKDC,itiscommontouseKDC synonymouslywithTGS,eventhoughthisisnotstrictlycorrectterminology. SincetheclientsrealmhasaprincipalregisteredinitsKDCdatabasefortheremote realmsKDC(TGS),itisabletoauthenticatetheclientandremoteKDCtoeachotherin thesamewayasforanyotherservicelocatedwithintheclientsrealm,andtheclient getsbackfromitsKDCatickettotheremoteKDC(TGS).Inthiscase,theticketis actuallyaTicketGrantingTicket(TGT)fortheremoteKDCrealm.Theclientcanthen accesstheremoteKDC,andusetheTGTithasreceivedtorequestaticketforany serviceintheremoterealm.ThisisillustratedinFigure4below.
Figure 4: A client in one realm can authenticate to a service in another. This is done by requesting n a ticket from the local KDC for the TGS of the destination realms KDC. The client is then able to request o a service ticket from the destination realm.
Thesalientpointsregardingcrossrealmauthenticationare: Beforeanythingelse,theclientmustinitiallyauthenticatetotheAuthentication Service(AS)foritslocalKDCandreceivebackaTGT. Theclientmustknowtherealmoftheserviceitintendstoaccess,andbeableto recognizewhenaserviceisinadifferentrealmfromitsown.Inlarge,distri butedenvironments,thiscanbeamoredifficultproblemthanitfirstappears. TheremoteKDCsTGSmustbearegisteredprincipalintheclientsrealm.The principalnamefortheremoteKDCwillbe: krbtgt/REMOTEREALM@LOCALREALM wherenormallytheremoteandlocalrealmnameswillbeuppercasedversionsof thecorrespondingDNSnames.Thisconventionmakesitpossibleforaclientthat knowsitsownrealmandtheremoterealmnametobeabletorequestaticket fromthecorrectTGSservice.
Page 29 of 53
TheclientmustaskitsKDCforatickettotheKDC(TGS)intheremoterealm. FromthelocalKDCperspective,thisisthesameasanyotherrequestfora serviceticket,exceptthattheticketprovidedtotheclientisaTGTfortheremote realm. TheclientmustusethenewTGTitreceivestorequestthattheremoteKDCgrant itaserviceticketfortheactualserviceitwantstoaccess.Fromtheclients perspective,thisisthesameasrequestingaserviceticketfromitslocalKDC. FromtheremoteKDCsperspective,theclientissimilartoanyotherclientthat waslocallyauthenticatedandgivenaTGT. Whentheclientreceivesaticketfortheserviceitwantstoaccessintheremote realm,itpresentsthetickettotheactualserviceinthesamewayitwoulda servicethatwaslocatedinthesamerealm. Aservicereceivingaticketfromaclientinaremoterealmcanprocesstheticket inthesamewayitwouldaticketreceivedfromanyclientinitsrealm.However, theserviceisabletoexaminethetickettodeterminethattheclientisfrom anotherrealm,andtomakeaccesscontroldecisionsbasedontheclientsrealm.
Thisdirectcrossrealmauthenticationprocessprovidesanelegantsolutiontothe problemofauthenticatingacrossrealms.Inpractice,ifclientsandservicesfromtwo realmsneedtobeabletointeractwitheachother,theneachrealmmustregisterthe otherrealmsKDC(TGS)asaserviceprincipal.Thisimpliestwosharedsecretkeyswill beneededbetweentherealmstoestablishabidirectionalcrossrealmrelationshipbetween therealms. 13 Iftherearemorethantworealms,theneveryrealmwillneedtoestablisha crossrealmrelationshipwithallotherrealmsbyregisteringasaserviceineveryother realm,andalsoregisteringeveryotherrealmsKDCasaservicewithinitsrealm.Thisis afullmeshtopologywithbidirectionalsetuprequiredwhere,fornrealms,therewill needtoben(n1)crossrealmregistrationsforthebidirectionalrelationships.Ifthereare morethanafewrealms,themanagementofthecrossrealmregistrationscanbecomean administrativechallenge.
Transitivity and Scaling Cross-Realm Relationships

Theapproximatensquaredgrowthincrossrealmrelationshipsfornrealmspresentsa scalabilitychallenge.Severalapproacheshavebeendefinedformanagingscalein multirealmsituations,asoutlinedbelow: ConfigurableAuthenticationPaths HierarchicalrelationshipsbasedonmappingofrealmnamestoaDNSname hierarchy Automatedconfigurationtools UseofclientpublickeycertificatesandPKINIT
Kerberosalsosupportsunidirectionalcrossrealmrelationships,whereclientscanauthenticateto servicesinaremoterealm,butnotviceversa.Thismightmakesenseifarealmisdefinedwhere servicesarelocatedthatwillbeaccessedfromotherrealms,butnoclientsthatneedtoaccess servicesoutsidetherealm.

13
Configurable Authentication Paths Thefirstapproachdependsontheideathatcrossrealmrelationshipscanbeextended tobetransitiverelationships.Authenticationflowsalonganauthenticationpathfrom thelocalrealm,throughoneormoreintermediaterealms,totheremoterealm.Ina typicalexample,somecentralrealmmightsetupbidirectionalrelationshipswithall otherrealms.TheclientwouldobtainaTGTforthecentralrealmfromthelocalKDC andusethatTGTtoobtainaTGTfortheremoterealmfromthecentralrealmsKDC. ThentheclientcouldcontacttheremoteKDCandobtainaticketfortheservice.
Figure 5: Example of hierarchically organized cross-realm relationships
Thefirstapproachpermitsconfigurationofauthenticationpaths.Theseconfigurable authenticationpaths(capaths)specifythesetofintermediaterealmsthatneedtobe traversedtogetfromalocalrealmtoaremoterealm.Thetermcapathisnotbasedon theconceptofapublickeycertificationauthorityortheconceptofacertificate validationpath;itisanabbreviationforconfigurableauthenticationpath. Acomplexitywithcapathsisthateveryclientneedstoknowtheavailablepathways. 14 Thisconfigurationmatrixhastobebuiltandinstalledoneverysystemthatwilloperate acrosstheextendednetworkofrealms.Furthermore,toavoidproblemswith inappropriatecapaths,serviceticketsareissuedwiththelistofintermediaterealms included,andservicesorKDCsmustcheckthepathintheticketagainsttheirlocal configurationofacceptablepaths.Thisrequirementtodistributeandmaintaincapath
EithertheserviceortheKDCalsoneedstobeabletovalidatethepathusedbytheclient. Ultimatelytheserviceisresponsiblefordecidingwhetherthepathisacceptableandwhether authorizationshouldberestrictedbecauseofthepathused.HoweverKDCsprovideafacilityfor checkingtransitedpathpolicythatservicesshouldrelyon.
14
informationpresentsitsownscalabilitychallenges.However,ifclientsandKDCs supportrealmreferralsasdiscussedinSupportforKerberosReferralsbelow,thenonly KDCsneedtobeconfiguredwithcapaths.Forsomeenvironments,suchasActive DirectoryDomains,thisscaleswell.

ClientinrealmASIA.GII.COMis abletorequestnaTGT(1)for accessingservicesinitsrealm Clientcanalsorequestoa TGT(2)fromtheTGSassociated withtheparentofitsrealm Clientcansubsequentlyrequest paTGT(3)fortheTGSinsome otherchildrealm,e.g., EU.GII.COM WithTGT(3)fromEU.GII.COM realm,clientcangetaticketfor ServiceB
Figure 6Example of hierarchical transitivity
Hierarchical Transitivity Avariationontheinterrealmpathconceptisastrictlyhierarchicalpaththatleverages consistenthierarchicalrealmnamingconventionstoallowauthenticationpathstobe implicitlyknown.Generally,thenaminghierarchyisbasedonDNSnames.For example,ifGalacticIndustriesInc.hastheDNSdomainnameofgii.com,andthereare threeregionsinAsia,Europe,andtheUnitedStateswiththecorrespondingdomain namesofasia.gii.com,eu.gii.com,andus.gii.com,thenahierarchywithfourrealmscanbe establishedwithAsia,EuropeandtheU.S.alltransitinganintermediaterealmnamed GII.COM(seeFigure5above).Sincethepathisimpliedbythenaming,theneedto explicitlyconfigurecapathsinclientsandservicescanbeavoided.Arbitraryhierarchies canbeestablished,providedtheyfollowstricthierarchicalnamingconventions. However,notallorganizationalstructureswillfitastricthierarchy,orwillbeableto
Page 32 of 53
useonehierarchicalnamingscheme.Figure6belowillustrateshowaclientinone realmcanusehierarchicaltransitivitytoaccessservicesinotherrealms. Configuration Tools AnotherwaytomanagerelationshipsamongstKerberosrealmsistobuildan administrativetoolthatcanautomateestablishingcrossrealmKDCregistrations,and thatmightevenhandledeployingcapathmatricestoclientsandservices.Assuming thatadatabaseofrealmsanddesiredrelationshipsisbuiltandmaintainedwithina tool,thetoolcanuseconfigurationrulesandpoliciestoautomaticallygenerateall requiredconfigurationsandsetups.Inpractice,directoryserviceshavebecome preferredtoolsforcentrallymanaginginformationrequiredtodeployandoperate complexdistributedsystems.Consequently,practicalsolutionstoautomating configurationofcrossrealmrelationshipshavebeenbuiltbasedondirectories.For example,MicrosoftusesActiveDirectorytomaintaincrossrealmrelationships throughoutanarbitrarilycomplexorganizationalstructure. PKINIT for Client Authentication AdistinctlydifferentapproachleveragesthePKINITKerberosextensionsasdescribed aboveinthesectiononPKINITPublicKeyCryptographyforInitialAuthenticationin Kerberos.InsteadofclientsusingtheirownKDCtogetticketsforservicesinaremote realm,aclientwithapublickeycertificatecouldcontactaPKINITcapableKDC directlyintheremoterealm.Sincetheclientdoesnothavetobepreviouslyregistered intheremoterealmtogetaTGTfromtheKDC,thereisessentiallynocrossrealmpath tobefollowed.Inessence,trustrelationshipsareestablishedandmaintainedwithinthe PublicKeyInfrastructure(PKI)usedtoissueandmanagecertificates.Thesetrust relationshipsareusedtofacilitateKerberosauthentication. Hybridapproachescanalsobepursued.Forexample,thehierarchicalapproachcould beusedwithcapaths,butwherethecapathsareonlyusedbyasubsetofclientsand services.Thismightallowfordirectcrossrealmrelationshipsinadditiontohierarchical relationships.AnotherhybridstrategymightusePKINITwithhierarchicalrelationships tosupportbothtraditionalclients,andclientsabletoauthenticateusingpublickey certificates.
Cross Realm Relationships and Trust

Realmsmayhavesignificantlydifferentpoliciesforwhatprincipalsareregisteredinthe KDCdatabase.Somerealmsmayallowanyonetoobtainaprincipalandmayhave loosecontroloverthesecurityoftheKDC.Otherrealmshavestrictpoliciesonwhat proceduresarefollowedbeforeregisteringaprincipalandtightlycontrolKDCs. Consequently,itisreasonableforservicestohavesignificantlydifferentconfidencein theauthenticationofprincipalsfromonerealmthanprincipalsfromanotherrealm. Clientsalsoneedtoevaluatetheirconfidenceintheauthenticationoftheservice.Of course,confidenceinauthenticationshouldbelimitedtotheweakestrealmthatis involvedintheauthenticationprocess.Servicesandusersthendecidewhethertotrust theauthenticationinthecontextoftheiraccesscontrolpoliciesbasedontheir
Page 33 of 53
confidencethattheassertedprincipalactuallynamesthepartyinvolvedinthe communication. Becauseservicesmustmakethistrustdecision,Microsoftreferstocrossrealm relationshipsasDomaintrusts.Whilecrossrealmrelationshipsdoinvolvetrust decisions,theleveloftrustthataservicechoosestoplaceinagivenrealmmaybevery low.InaMicrosoftcontext,itrarelymakessensetoestablisharelationshipwitha relativelyuntrustedDomain. Administratorsshouldthinkcarefullyaboutwhatleveloftrustintheauthentication processisappropriatewhentheyplaceaprincipalfromaforeignrealmonanaccess controllistorotherwisegrantthatprincipalaccess.Ifanorganizationhasrelatively liberalpoliciesaboutwhenacrossrealmrelationshipisestablished,itiseasierto establishcrossorganizationalcollaboration.Thosegrantingaccesstoforeignprincipals canevaluatewhethertheforeignpracticesaresufficient.However,auditingwhether thesedecisionstograntaccessarejustifiedmaybedifficult.Ifthisisproblematic,an organizationmayestablishminimumrequirementsforcrossrealmrelationships. Applicationauthorsshouldendeavortomakeiteasiertoauditaccesscontroldecisions withanopencrossrealmpolicybyprovidingmechanismstoestablishrealmlevel policiesregardingwhataccessisappropriate.
Managing Multiple Kerberos Realms

Inadditiontothechallengesoffindingtheauthenticationpath,describedabove,there areotherproblemsorissuesthatneedtobeaddressedinrealworlddeployments involvingmultiplerealms,especiallyinmixedenvironments.Perhapsthemost significantissueishowclientsfindthecorrectnameforservicesinotherrealms,and howtheydeterminewhatrealmnametousefortheservicetheywanttoaccess.One approachtodealingwiththischallengeistoleverageDNSnamesforservicestomapto realmnames.ThisapproachisdiscussedfurtherbelowinthesectiononIssueswith RelyingonDNS.Anothercommonapproachistoprovideadirectoryservicethatcan beusedtodiscoverservicesandassociatedrealmnames. Anotherconcernwithestablishingcrossrealmrelationshipsisthemeansusedtoshare secretkeysbetweenKDCs.ToavoiddisclosureofsecretkeysusedbyKDCs,eachnew relationshipwillrequireseparatesecretkeysusedforeachdirection.SinceKDCsare specializedservices,theprocessofestablishingthesesharedsecretkeyscanvaryfrom implementationtoimplementation.Thisresultsinaddedcomplexitywhenmultiple realmsareusedwithdifferentimplementations.Often,theonlyapproachavailableisto setuppasswordsassharedsecrets.Obviously,suchpasswordsmustbeimmuneto passwordguessingattacks,andshouldbegeneratedastruerandomstrings.Another potentialproblemisdeterminingwhatencryptionalgorithmwillbeused,since strongeralgorithmsareclearlypreferred,butmaynotbethedefault.Particularcareis neededtomakesurethatDESisnotusedastheencryptionalgorithm,givenits weaknesses.WhenregisteringaKDC(TGS)inanotherrealm,especiallywhena differentKDCimplementationisinvolved,itisvitaltocheckrelevantdocumentation anddetermineanapproachthatwillprovidethegreatestprotectionagainstattackson thesecrets.
Asnotedabove,policiesmaynotbeconsistentacrossrealms.Forexample,onerealm mayplacestringentrestrictionsonwhatprincipalsareregisteredintherealm,while anotherrealmmighttakeamorerelaxedapproachtoregisteringprincipals.Such discrepanciesinpoliciesmayresultinunintendedweakeningofarealmspolicies,ora generaltendencytodevolvetopoliciesthatreflectthelowestcommondenominator. Kerberos,byitself,doesnotprovideadequatemeansforexpressingpoliciesacross realms.Consequently,thisisamatterofagreementsbetweenadministrativeregimes andmayrequireexternalmethodsforexpressingacceptablepoliciesacrossrealms. Auditcontrolsarealsomorecomplexinamultirealmenvironment,especiallywhen appliedinconsistentlyacrossrealms.Forexample,ifaserviceinonerealmexpectsthe KDCtoprovideanaudittrail(systemlog)ofallclientauthenticationsandticket requests,butsomeclientsareinitiallyauthenticatedbyaKDCinanotherrealm,then auditpracticeswillbeweakenedifitisnotpossibletoaccesstheremoterealmsaudit records.
The Role of Directory Services

Allmoderninformationservicesrelytosomedegreeontablesorfilesthatcanmap namestoothernamesorattributes.However,whenthisinformationisbuiltinto individualapplicationsorconfiguredintoeveryinstanceofanapplication,thenitcan becomeawkwardtomaintainthisinformationthroughoutanevolvingsystem. Furthermore,thereisusuallyconsiderableduplicationofinformation,andoftenthere arecriticalrequirementstokeepthisinformationuptodateandsynchronizedacross distinctsystementities.Consequently,variousserviceshaveevolvedthatmaintain directoriesofinformationthatcanbeusedacrossapplicationsasawaytoreduce administrativeburdens.Forexample,whileitwasonceacceptableforeveryInternet hosttohaveahostsfileusedtomaphostnamestoIPaddresses,theimpracticalityof thisapproachastheInternetgrewledtotheDNSserviceprovidingacommon directoryservicethateveryhostcanusetolookupotherhoststhroughouttheglobal Internet. Inanyaccesscontrolcontext,directoriesarevitalservicesfornamemapping, associatingnamedentitieswithattributes,andformaintaininginformation relationshipsnecessarytoenforcingpolicyrules.Thesedirectoriesmayresidein applications,suchasuserid/passwordlookupfilesoraccesscontrollists(ACLs). Alternatively,directoryservicesmaybeusedtomaintainsuchinformationthroughout anenterprise. Directoryservicesareoftenassociatedwithauthorization,sincetheycangreatly simplifykeepingtrackofattributesusedinauthorizationdecisionswhencontrolling accesstoinformationorotherresources.Forexample,directoriescanmaintaingroup membershipsorACLsthatcanbesharedacrossmanyapplicationsthatneedtomake authorizationdecisions.However,directoriesarealsousedtomaintaininformation usedinauthenticationortosharepublickeysusedtoprovideconfidentialityordata integrity.
Page 35 of 53
KerberosreliesontheKDCdatabaseatypeofdirectoryformaintaininginformation usedinauthenticationandticketgrantingdecisions.KerberosalsoreliesonDNS servicesandisincreasinglyassociatedwithLDAPdirectoryservices.Thefollowing sectionsexploretheroleoftheKerberosdatabase(KDB)andotherKerberos dependenciesonexternaldirectoryservices.
The KDC Database (Directory)

InthesectiononNamingintheKerberosContext,theconceptofprincipalnameswas introducedasthemeansforassociatinganauthorizedpartywithacontextuallyunique name.Inpractice,apartyisauthorizedifithasaprincipalnamewithintheKDC database,orKDB.Putdifferently,nopartycanauthenticateviaKerberosunlesstheir principalnamehasbeenenteredintotheKDB,andsuchunregisteredpartiesare implicitlynotauthorized.Apartyauthenticatestotheiruniqueprincipalnamevia KerberosprotocolsbasedonsecretsknownonlytothevalidpartyandtheKDC,orvia othertestsusinginformationsharedbetweenthepartyandKerberosservice. TheKDCdatabaseexiststomapprincipalnamestoassociatedsecretkeys,alongwith administrativeinformationsuchaslastmodifieddateandpolicyinformation,suchas maximumticketlife.Inotherwords,theKDCdatabase 15 isasimpledirectoryusedto lookupkeysandattributesforaspecifiedprincipalname.However,this database/directoryexistsonlytosupporttheoperationsofKDCsandadministrationof aKerberosrealm.Itisnotofferedasaservicetootherparties.Theonlyexposed interfacesareforadministrativefunctions. Administrativefunctionssuchasenteringnewprincipalnames(i.e.,registration), changingsecrets(e.g.,passwords),ormodifyingpolicyparameterswhilenecessaryfor anyfunctionalKerberossystem,arenotprovidedinthesamemanneronallplatforms. WhiletheKerberosprotocolsarewellstandardizedandinteroperateinmixed environments,administrativefunctionsarenotwellstandardized,andinteroperability hasproventobeachallengeforsystemadministrators.Typically,administrative functionsaresecuredusingtheaccesscontrolfacilitiesofthehostonwhichKDC servicesoperate,orKerberosisitselfusedtoprovideaccesscontrolbyusingspecial adminprincipalsandconfigurationfilesthatdeterminewhichprincipalsare authorizedtoperformadministrativefunctions. SinceKDCscanbedistributedwithinanetworktoprovideredundancyandimproved accessibilityinlargenetworks,theKDCdatabaseneedstobereplicatedontoeachKDC instance.However,KDCdatabasereplicationtendstobesimplistic,andlacksthe flexibilityandscalabilitynormallyassociatedwithdirectoryreplication.Traditionally,a KDCdatabaseiskeptonamasterKDCandpushedenmassetoallotherKDCsona periodicbasis.Recently,someKerberosimplementationshavebeguntointroduce replicationschemesthatoperateincrementally,pushingoutonlychangedrecords, insteadoftheentiredatabase.AnotherapproachtomaintainingKDCdatabasesisto utilizeamorerobustdirectoryserviceforbuilding,administeringanddistributingthe
15TheKDCdatabaseissometimescalledtheaccountdatabaseoraccountdirectory,especially inMicrosofttechnicalliterature.
Page 36 of 53
informationrequiredbyKDCs.CurrentKerberosimplementationsdirectlysupportuse ofstandarddirectoryservicesasanalternativetoastandaloneKDCdatabase.This approachisdiscussedfurtherinIntegratingKerberoswithDirectoryServicesbelow. TherearetwoprimaryadvantagestothesimpleKDCdatabasemodel.First,separating theKDCdatabasefromotherdirectoriesreducesthesizeofthemostsensitivesecurity data.KDCdatabasebackupsmustbekeptconfidential,andchangestotheKDC databaseneedtobecarefullyaudited.Ifthissensitiveinformationiscombinedwith anotherdirectory,thentheentiredirectorywillneedtobetreatedwiththislevelofcare. Secondly,thesimpleKDCdatabaseallowsrelativelyefficientoperation.Asaresult,a singleKDCrealmcansupporttensofthousandsofprincipalswithadequate performance.Similarly,inacampussetting,asingleKDCcanhandlerequestsfrom userpopulationsthatexceedtenthousandusers.However,moderndirectoryservices alsoscalewell,sothatevenlargerpopulationscanbesupportedusingKerberos integratedwithdirectoryservices.Forlargerpopulations,theadministrative advantagesofdirectoriesargueforusingintegratedapproaches.WhenKerberosis combinedwithanefficient,welladministered,distributeddirectoryservice,itis feasibletoscaletoglobalpopulations.
DNS and Kerberos

InadditiontotheKDCdatabase,Kerberosuseslocalconfiguration(e.g.,configuration filesorregistryentries)toestablishoperationalparametersandmappingsforrealms andKDCs.Inparticular,amappingbetweenrealmnamesandcorrespondingDNS domainnamesisnecessary,plusalookuptableofKDCswithineachrealm.Itmayalso benecessarytoprovidelookupfacilitiesforKerberosadministrationservicesand passwordchangingservices.Sinceatleastasubsetofthisinformationisneededby everyKerberosclient,thereisascalabilitychallengeinmaintainingtheseconfiguration filesacrossanentirepopulationofKerberosusers.Everytimeanewrealmisadded,or anewKDCaddedtoarealm,theconfigurationfileswillneedtobeupdatedformany, ifnotall,clients. SinceDNSisaubiquitousserviceinpracticallyeveryinternetwork(privateorpublic), KerberoshasevolvedtorelyonDNSasameansforcentrallymanagingrequired mappings.ByaddingSRVrecordstothelocalDNSservice,itispossibletoenable KerberosclientstodiscoverKDCs,realms,andrelatedKerberosadminandpassword changingservices.Inaddition,theSRVrecordsprovideinformationaboutpriority orderinwhichtoaccessKDCsorotherKerberosservices,aswellasweighting informationthatcanbeusedinloadbalancingbetweenKDCsatthesameprioritylevel. ThismakesitrelativelyeasytoaddorchangeKerberosKDCsandserviceswithina realm,andtoimplementeitherredundancyorloadbalancing,orbothallwithout havingtomodifytheconfigurationfilesofclientsandserversthatuseKerberos. RealmtodomainnamemappingscanalsobemaintainedwithinaDNSserviceby usingTXTrecordsthatsimplyregisteradomainnamewithanassociatedKerberos realmname.Notethatiftherealmnameisnotatrivialtransformationofthedomain name,thennewDNSzoneswillhavetobecreatedforeachKerberosrealm,andany SRVrecordswillneedtoresideintheDNSzonethatcorrespondstotherealmname.
DNSisalsoasimpledirectoryservicewithbuiltinreplicationmechanismsfor extendingknowledgeaboutdomainnamemappingsthroughoutanenterprise,across multipleenterprises,andacrosstheglobalInternet.Applicationsingeneral,and Kerberosspecifically,dependonDNStoprovidemappingsfordomainnamesoutside ofthelocaldomainorrealm.WithoutDNSreplication,Kerberoswouldnotbeableto provideauthenticationbetweenclientsandserviceslocatedindifferentrealmsi.e., crossrealmauthenticationrequiresworkingDNSservices.
Issues with Relying on DNS

WhileuseofDNScangreatlysimplifyadministrationofKerberosrealmsand associatedclientsandservers,italsointroducessomeconstraintsandvariousproblems, includingsecurityvulnerabilities. OnenotableconstraintintroducedbyrelianceonDNSisthatcasesensitiverealm namesmustnotbeequivalentiftransformed(orfolded)intocaseinsensitivedomain names.Toillustratebyexample,iftherearetworealmsnamedKERBEROS.ORGand Kerberos.orgwherecasesensitivityisrequiredtodistinguishbetweenthem,then suchrealmnamescannotbeusedwithDNS,sincedomainnamesarecaseinsensitive, andthereisnowaytoestablishDNSmappingsforSRVrecordsthatwoulddifferentiate betweensuchnames.Inpractice,thisisrarelyaproblem,sinceKerberosrealmnames areseldomdifferentiatedbycasealone.Suchrealmnamesareforbiddenbythe Kerberosspecification.Theestablishedconventionofusingtheallcapsversionofa domainnameastherealmnameavoidsthisproblemwithDNS,andisrecommended formostsituations,andevenrequiredbysomeimplementations. AnotherconstraintwithusingDNSisthatKerberosprincipalsmustbeabletoaccess theDNSserviceinordertoperformKerberosauthentications.Inparticular,useof KerberosfacilitieswillgenerateDNStrafficinadditiontotheKerberosprotocol exchanges.Thisaddscomplexitythatmustbehandledproperlywithinapplications, especiallywithregardtohandlingofDNSerrorconditionsortheinabilitytoaccess DNSservices.Forexample,convertingaloginproceduretofirsttryKerberos authenticationmayresultinfailuresorlongtimeoutsrelatedtoDNSqueriesevenif otherauthenticationoptionsareavailable. EarlierKerberosspecificationsandimplementationsalsomadeuseofDNStohelp discoverthenameoftheservicebeingrequested.Forexample,theIPaddressofa requestedpartywouldbepresentedtoDNSasareverselookuptogetbackthehost nameassociatedwiththeIPaddress,whichwouldthenbeusedtoconstructthe principalnameorusedtodiscoverrealmnames.WhilesuchuseofDNSqueriesis discouragedincurrentKerberosstandards,itisstillquitecommoninwidelydeployed Kerberosimplementations.Consequently,itisusuallyrequiredthatifhostsoffering KerberizedserviceshaveDNSentriesthatcanberesolvedviaareverselookup,the resultinghostnameistheoneregisteredinKerberos.Inenvironmentswherehostsare assigneddynamicIPaddresses,thiscanbeaproblemunlessadynamicDNSserviceis availabletoautomaticallyupdateIPaddresstohostnamemappings.DNScanalsobe coupledtoaDHCPserviceinsuchawaythatashostsareassignedIPaddressesbythe DHCPservice,theyarealsoregisteredwiththatIPaddressinthelocalDNSservice.
AnotherconcernwithusingDNSistheinherentinsecurityofthebasicDNSservice. 16 Inparticular,itiseasyforattackerstoimposetheirownreplacementDNSservices,or tocauselocalDNSservicestoprovideinvalidresponsestoqueries(e.g.,bypoisoning thecachesoflocalDNSservers).SinceDNSresponsesarenotsecuredinanymanner,it isnotreasonabletoplaceevenmodesttrustinDNSservices.Inparticular,itisnot possibletotrust: DNShostnametoIPaddressmappings DNSreverselookups Kerberoshostnametorealmnamemappings(ifused)
AsaresultoftheseDNSvulnerabilities,anattackercanoftenmountadenialofservice attack,preventingaccesstoresources.Fortunately,mostofKerberossusesofDNSdo notdependontheintegrityofDNSdata.Inparticular,theSRVbaseddiscovery mechanismforKDCsandadminservers,andtheuseofDNStotranslatenamestoIP addressesarenotcriticaltothesecurityofKerberos.Afterinformationisretrievedfrom DNS,Kerberosauthenticationisusedtoconfirmthattherightpartyiscontacted.Ifthe DNSinformationismodified,thismodificationwillbedetected. TheuseofDNSandDNSreverseresolutiontodeterminethenameoftheserviceto contactismuchmoreproblematic.Unfortunately,therearenoviablesolutionsforthe DNSvulnerabilitiesinthiscontext,andthelatestKerberosstandards(ref.RFC4120) statethatKerberosimplementationsmustnotuseDNSqueriestomaponenameto anothertodeterminethehostpartoftheprincipalname.Theconcernisthataclient thatgetsanerroneousmappingtoahostnamefromtheDNSservicemaywindup authenticatingtothewrongservice.However,thisservicewouldstillhavetobe registeredintheKDCdatabaseofsomerealm,soforapplicationsthatrequire successfulKerberosauthentication,theexposureislimitedtoattacksthatcorruptDNS toreplaceoneservicewithanother.Asapracticalmatter,currentKerberos implementationsdorelyonDNSservices,whichimpliesthatsystemadministrators musttakereasonablecareinprotectingDNSagainstattacks,oratleasttobeableto quicklydetectattacksthataffectDNSservices.Inpractice,theproblemswithDNS insecuritiescanbemitigatedthrougheffectiveadministrativepracticesforbothDNS andKerberosservices.Inparticular,restrictingwhichhostsandservicesareregistered intheKDCdatabasewillreducepotentialexposures. MicrosofthasalreadyadoptedextensionstotheKDCdatabasetoavoiddependenceon DNSformappinghostnamestoprincipals.Thebestlongtermpracticeforavoidingthe problemsofDNSisforotherimplementationstoadoptsimilarstrategies.
Directories and Kerberos

WhileDNSandKerberosbothutilizesimpleinternaldirectories,andDNSevenoffersa simpledistributeddirectoryservice,neitherprovidessufficientlyrobustorsecure directoryfacilitiestomeetthecomplexchallengesofcontrollingaccesstomodern
16WhileasecureDNSservice(knownasDNSSEC)doesexist,ithasseenonlyscantadoption,and isnotviableinthevastmajorityofsystemdeploymentstoday.Thismaychangeinthefuture.
Page 39 of 53
informationsystems.Consequently,acommonstrategyhasemergedoverthepast decadetoleveragesecure,robustdirectoryservicesalongsideofDNSandKerberos. ThedirectoryservicesthatarecommonlydeployedtodayarebasedontheLightweight DirectoryAccessProtocol,orLDAP, 17 whichisinturnbasedonX.500directory standards. 18 However,directoriesarebeingdeployedformanyreasonsbesidessupportingaccess controlrequirements;someimportantsystembenefitsinclude: Updateonceaccesseverywheredatamodelwhereinformationisenteredor updatedoncebyanyauthorizedsourceandbecomesavailablethroughoutan enterprise,orevenglobally. Reduceduplicationofinformationacrossdiverseapplicationsoperatingwithina distributedcontext. Commonadministrativeproceduresandtoolscanbeusedtomaintain informationthroughoutanenterprise,includingreplicationofinformation. Applicationsnolongerrequiretheirowninternaldirectoriesorevensome configurationfiles,andcanalsomakeuseofnewinformationobjectswith minimaldevelopmenteffort. Centralizedcontrolofaccesstodirectoryinformationsimplifiessecurity measures,whichalsoimpliesthatinformationretrievedfromdirectoriesismore reliableandtrustworthy.
Additionalfeaturesandcapabilitiesofdistributeddirectoryservicesthatarerelevant fromasecurityperspectiveinclude: Manytypesofnamesandaddressescanbemappedtoeachothere.g.,associate apersonsnamewiththeiruserid,Kerberosprincipalname,organization, department,office,telephonenumber,emailaddress,employeenumber, distinguishedname. Globallyuniqueidentifierscanbeestablishedthatallowentitiesinadirectoryto bemovedandrenamedwithoutlosingtrackofwhoorwhatisbeingreferenced. Groupings(a.k.a.,containers)canbemaintainedthatlistentitieswithinthe directorythatsharesomecommonattributes,purpose,orrolee.g.,a departmentgroupthatlistsallthemembersofadepartmentwithinalarger organization. Eachdirectoryentrycanbeassociatedwithvariousattributese.g.,roles,group memberships,status,privileges,entitlements,quotas,rank,security classification,subscriptions.
LDAPv3standardsarelistedonthearchivedIETFWorkingGrouppageat: http://www.ietf.org/html.charters/OLD/ldapbischarter.htmlwithadditionalinformation maintainedat:http://www.openldap.org/ 18TheX.500seriesofstandardsdocumentscanbedownloadedfromtheITUTwebsiteat: http://www.itu.int/rec/TRECX/eandfurtherreferencescanbefoundat: http://www.x500standard.com/

17
Commonattributescanbedefinedandusedconsistentlyacrossmany applications. Directoriescanserveasrepositoriesforspecializedinformationobjects,suchas digitalcertificatesorprotectedkeys.
Theabilitytoretrieveattributesassociatedwithaprincipal(e.g.,userorservice)from adirectorygreatlyfacilitatesauthorizationswithinadistributedapplications environment.InsteadofeachapplicationhavingitsownAccessControlLists(ACLs)or maintaininginternalgroupmemberships,anapplicationcanqueryacentraldirectory forattributesassociatedwithapartytodeterminewhatauthorizations(e.g.,privileges, permissions)thepartyisentitledto. Ofcourse,applicationsmustbeabletotrustresponsestheyreceivefromqueriesmade toadirectoryserviceforauthorizationinformation.Thisimpliesthatthedirectory applicationitselfmustbesecured.
Securing Directory Services with Kerberos

ModernLDAPbaseddirectoryservicesarethemselvessophisticatedapplicationsthat areusedthroughoutanenterprisebymanytypesofusersandservices.Inmany enterprises,everyuserisentitledtoaccessatleastasubsetoftheinformationcontained withintheenterprisesdirectoryservice,andeveryusermayevenhavepermissionsto modifycertaindatafieldsinasubsetofdirectoryentries.Forexample,oneuseofthe directoryservicemaybeasasimplewhitepagesforfindingnames,telephone numbersandaddresses.Individualusersmightbeallowedtomodifycertainfields associatedwiththeirowndirectoryentry,suchasahometelephonenumberoraddress. However,muchoftheinformationinadirectorymustbetightlycontrolledintermsof whocanaccessormodifyinformation,aswellaswhatentriesorattributescanbereador modified.Inotherwords,accesscontrolisessentialtodirectorymanagementanduse, especiallyifdirectoriesaregoingtobeusedtostoreanddistributeauthorization informationorothersecurityresources,suchasdigitalcertificates. Whilevarioustechnologiesareusedtosecureaccesstodirectoryservices,Kerberosis oftenapreferredmeansforsecuringdirectories.Othertechnologiesusedeitherwith,or asanalternativeto,KerberosincludeTLS(SSL),MicrosoftsNTLMandNetlogon,one timepasswordsystems,variouschallengeresponseschemes,andevensimple userid/passwordauthentication.Fordirectoryservicesthatplayavitalroleinthe overallsecurityinfrastructureofanenterprise,KerberosandTLSarepreferredsecurity technologies,andarefrequentlydeployedincombination. AdvantagesofferedbyKerberosinsecuringdirectoryservicesincludesinglesignon forusers,authenticationofclientsandservices,mutualauthenticationbetweenclients andthedirectoryservice,securesessionestablishmentthatprovidesdataintegrity betweenadirectoryserviceandusers,crossrealmauthenticationthatfacilitatesaccess throughoutanextendedenterprise,andsupportfordelegationtoproxyservices. WhilevariousapproachesareusedforbuildingdirectoryservicestoutilizeKerberos,a popularapproachistobuilddirectoryapplicationsusingtheSimpleAuthentication andSecurityLayer(SASL)framework,whichdecouplestheapplicationfromtheactual
authenticationmethodsusedaswellasthemeansforsecuringsessions.SASL,inturn, utilizesKerberosviatheGSSAPIasonesupportedauthenticationmethod.SinceSASL canalsobeusedwithTLSforsecuringsessionsbetweenparties,thisapproachprovides robustsecuritythatcanbeflexiblyconfiguredaccordingtotheneedsofaparticular enterprise.Whilesmallenterprisesmightusesimplepasswordbasedauthenticationfor theirdirectoryservices,largerenterprisestypicallyusesomecombinationofKerberos withSASLandTLStosecuretheirdirectoryservices.
Integrating Kerberos with Directory Services

Asnotedabove,abenefitofusingadirectoryserviceisthatitcentralizesmanagement ofinformationandreducestheneedforapplicationstomaintaintheirownlocal directories.Kerberosisanexampleofanapplicationthathasaninternaldirectorythat duplicatesinformationthatmustbekeptandmaintainedinotherplaces.Consequently, thereareadvantagestointegratingdirectoryservicesintoKerberostoreplaceor augmenttheKDCdirectory. NotonlydoesthiseliminatesomeoftheadministrativeoverheadforKerberosina systemsenvironment,italsoprovidesrobustmethodsforreplicatingdirectoriesacross multipleKDCsi.e.,KDCsnolongerneedtodealwithreplicationorpropagationof theirdatabases.Furthermore,administrationofsomeKDCinformationcanbe performedusingstandardizedtoolsthathaveevolvedwithdirectoryservices.For example,passwordchangescanbehandledusingdirectoryapplicationsthatallow userstochangeonlytheirownpasswords(writeonly),whilerestrictingpasswordread accessonlytoKDCs. 19 However,accountcreationandmanipulationofKDCpolicy informationrequiresspecializedknowledgeabouttheparticularKerberosimplementa tion.Ifstandarddirectoryapplicationsareusedforthesetasks,theapplicationsneedto beexpandedtounderstandKerberosandthespecificKDCimplementation. TherearetwoobviousapproachestointegratingdirectoryserviceswithKerberos:(1) synchronizingtheKDCdatabasewiththedirectory,or(2)replacingtheKDCdatabase withdirectuseofthedirectory.ThefirstapproachminimizeschangestoexistingKDC implementations,sinceperiodicextractsfromthedirectorycanbeusedtoreplacethe KDCdatabasewithafreshcopy,buttheKDCstillusesthesameinternaldatabase.One potentialbenefitisthatifthedirectoryservicebecomesunavailable,Kerberos operationswouldbeabletocontinue.Thesecondapproachrequiresnew implementationsofKDCservices,buthastheadvantageofenablingexpanded Kerberosservices.Inreality,mostKDCimplementationsalreadyincludeoptionstobe builtusingstandardLDAPdirectoryservices.Microsoftchosetoreimplement KerberosasanintegralcomponentofitsActiveDirectoryservices. Theabilityofdirectoriestostorepublickeycertificatesforusersandservicesprovides newoptionsforimprovinginitialauthenticationtoKerberosthroughuseofpublickeys insteadof,orinadditionto,passwords.Thisfacilitatesuseofsmartcardsorother cryptographictokensforinitialauthentication.Similarly,directoryservicescanfacilitate
19Ofcourse,passwordsarehashedandnotuseddirectlybyKDCs.However,administratorsmay needtorecoveractualuserpasswords,whichmightbehandledthroughasecuredirectory.
Page 42 of 53
useofonetimepassworddonglesforinitialuserauthentication.Thenetresultisthat enterprisescanmorefreelydecidewhichinitialauthenticationmethodstheyprefer,or eventousedifferentmethodsfordifferenttypesofusersorforspecificapplications. Sincedirectoriescanassociateauthorizationattributeswithprincipals,combining Kerberoswithdirectoryservicesenablesnewoptionsforstreamliningauthentication andauthorizationforapplications.Forinstance,Kerberoscanauthenticateaclientand servicetoeachother,andprovidetheservicewithanauthenticatedprincipalnamethat canbeusedinasubsequentdirectoryquerytopullauthorizationinformationforthe client.AnotheroptionwouldbeforKerberostopullauthorizationinformationfromthe directoryserviceandincludethisinformationintheticketprovidedtotheapplication. ThislattertechniqueisusedbyMicrosofttoembedPrivilegeAttributeCertificates (PACs)fortheclientwithinKerberosticketsthataresenttoservices. ItisalsopossibletointegrateDNSwithdirectoryservicestofurtherreducesystem administrationburdens.
Kerberos Role in Directory Trust Relationships

Whileadirectoryservicecanbedeployedasasingleapplicationonasinglehost,itis moretypicaltodeploydistributeddirectoryservicesthatemploymultipleapplications ondistincthosts.Notonlydoesthisdistributedmodelhelpimprovereliabilityand accessibility;itisalsoessentialtodeployingdirectoryservicesthatspanmultiple organizationalboundaries. Atypicalexampleofadistributeddirectorymightbewheredirectoryservicesare deployedatthedepartmentorsitelevel,andthenjoinedtoformadirectoryservicefor abusinessunitorregion.Foranentireenterprise,directoriescouldbejoinedacross businessunitsorsites.Alargemultinationalenterprisemightfurtherextendthemodel tospanmultiplecountriesorregions.Theresultingdistributeddirectorysystemis describedasaDirectoryInformationTree(DIT),withclientsabletoqueryalocal directoryserviceatthedepartmentorlocalsiteleveltogetinformationaboutentries, notonlyfromtheirownlocalenvironment,butfromanyotherorganizationalunit withintheextendedenterprise. Arequirementforthismodeltobeusefulisthateveryindividualdirectoryapplication mustbeabletocommunicatesecurelywithpeerapplicationsrunningonotherhosts thatresideonothernetworks.Mutualauthenticationbetweendirectorypeersis essentialtoinsuringtrustworthyoperationofadistributeddirectoryservice,asareall oftheothersecurityservicesnecessarytoassuringadequateaccesscontrol.Kerberosis oftenusedasthemeansforestablishingsecure,mutuallyauthenticated communicationssessionsbetweenindividualdirectoryapplications.Onereasonthat Kerberosisparticularlyeffectiveinadistributeddirectoryenvironmentisthatit providesacommonauthenticationandsessionestablishmentfacilitythatcanbeused forclientaccesstodirectoryservices,foradministratoraccess,andforpeerinteractions betweendirectoryapplications. Directoriescanalsobeextendedbetweendiscreteenterprisesusingwhatisfrequently referredtoasafederatedmodel.Buildingfederatedsystemsisacomplexandchallenging
Page 43 of 53
problemthatinvolvesmanyissuesbesidesjustdirectoryintegration.Furthermore, directoryintegrationisusuallyconstrainedtoonlysubsetsofthedirectoriesindifferent enterprises.Forexampleifanequipmentmanufacturerestablishesfederated relationshipswithitspartssuppliers,itwouldnotmakesensetoexposetheentire directoryofeachenterprisetotheothers,andtherelationshipsbetweentheparts suppliersandeachotherarequitedifferentfromtherelationshipspartssuppliershave withthemanufacturer.Consequently,itmightmakesenseforapartssuppliertohave accesstoportionsofthemanufacturersdirectorythatrelatetopurchasingand inventorymanagement,butnottootherdepartmentsorbusinessunits. Kerberosiscommonlyusedtosecuredirectoryintegrationbetweenfederatedparties, especiallywithinMicrosoftActiveDirectoryfederatedscenarios.Specifictrust relationshipscanbeestablishedbetweenjusttheinternalorganizationalunitsinone partythatneedtointeractwithcounterpartsintheotherpartyusingKerberosmutual authenticationandcrossrealmmechanisms.Inthesesituations,Kerberosinitial authenticationcanutilizecertificatesandpublickeycryptographytofurtherstrengthen securityacrossorganizationalboundaries.
Specific Implementations
Microsofts Active Directory and Kerberos
In1993,MicrosoftdecidedtoadoptKerberosasaprimaryauthenticationmechanism withinitsproducts,andin1999releasedafullyintegratedversionofKerberoswith WindowsServer2000.Inthesametimeframe,MicrosoftadoptedtheLDAPapproach foritsActiveDirectoryservices,whichwerealsointroducedwithWindowsServer 2000.ActiveDirectoryismorethanadirectoryservice,asitintegratestheKerberos KDCfunctions,DNSservices,andrelatedservices,suchasDHCP.Italsosupports standardLDAPdirectoryinterfaces.ThisisillustratedinFigure7below. MicrosofthasincorporatedKerberosintoitsActiveDirectoryservicesasacomponent insupportofalargerstrategy.Someoftheirstrategicobjectivesinclude: Providecomprehensiveaccesscontrolfacilitiesthatintegrateallsecurity mechanismswithinaconsistentframeworkforestablishingandmanagingpolicy controls. Allowcentraladministrationofallaccesscontrolfacilitiesthroughacommonsetof administrativetoolsthatautomateconfigurationofspecificunderlyingmechanisms (e.g.,Kerberos). Supportmultipleauthenticationoptionsasawaytoallowusersandapplicationsto choosethemostappropriateauthenticationmechanisms,andalsoasawayto facilitatetransitionfromolderauthenticationmechanismstonewerones. Insulateapplicationsfromunderlyingsecuritytechnologiesandevenfrombeing awareofwhatspecificsecuritytechnologiesareactuallyinuse.
Insupportofthesestrategicobjectives,ActiveDirectoryhasbeenpositionedatthecore ofMicrosoftsentirefamilyofWindowsServerproducts,andservesasthefoundation forbuildingdistributedsystemsonWindowsplatforms,includingthe.NET

framework.ActiveDirectoryistheaccountdatabaseusedbyallusersandcomputers tomanageresourcesandprovidesecuritycontrolsinWindowsServerenvironments.It supportsaconsistentaccountmodelandpolicycontrolsthatcanbeappliedacrossan entire,extendedenterprise,andevenbetweenenterprises.Theimplicationisthat,if policiesallow,auserinonepartofanenterprisecanaccessservicesorresources anywhereelseintheenterprise.
Figure 7: Active Directory is hosted on Domain Controllers, and provides service interfaces for Kerberos, DNS, LDAP, and others not shown, such as DHCP. Collectively, the workstations, servers, Domain Controller(s) and local network comprise a Domain, with Active Directory managing Domain accounts, and integrating the Domain into an enterprise-wide directory tree or forest.
TheKerberosKDCservicesaretightlyintegratedwithActiveDirectory,andall KerberosauthenticationrequestsareprocessedusinginformationprovidedbyActive Directoryi.e.,thereisnodistinctKDCdatabase(a.k.a.,KDB).Windowsandnon WindowssystemsareabletointeroperatewithActiveDirectoryKDCservicesusing standardKerberosprotocols,includingGSSAPIKerberoswirelevelprotocols.Atthe sametime,otherauthenticationmechanismsaresupported,includingtheabilityfor applicationstonegotiatewhichauthenticationmechanismtouse.

Relevant Microsoft Terminology and Naming Conventions

InMicrosoftsterminology,anaccountisasecurityprincipal,whichcanbeauser,a computer,oragroup.Groupsarelistsofaccountsincludingothergroupsthatshare commonpermissionstouseinformationobjectsandresources.Thereisalsotheconcept ofanAccountDomain,whichistheissuingauthorityresponsibleforestablishing accounts.ALocalDomainisconstrainedtoissuingaccountsforasinglecomputer, whereasaRemoteDomainissuesaccountsforasetofnetworkedcomputersandusers. ADomainController(DC)isaWindowsServerthatmanagesaccountsforacollection ofcomputersandusersonasharednetworkthroughActiveDirectoryfacilities.Itis commontorefercollectivelytothecomputersandusersservedbyasingleDCasa Domain.KerberosrealmsmapdirectlytoDomains,butaDomainismorethanarealm. LikeKerberosrealmnames,namesforDomainsareusuallyderivedfromDNSnames. 20 However,sinceallnamesareadministeredthroughActiveDirectory,itispreferableto thinkintermsofnamesbeingestablishedfirstinActiveDirectory,andtheninstantiated withinDNSandKerberos.Likeotherdirectories,ActiveDirectoryisdeployedinatree likestructure,wherenodesonthetreeareDomains. 21 Thetoplevel,orroot,Domainis normallygiventhenamecorrespondingtotheenterprisesregisteredDNSdomain. Toillustratewithanexample,thecompany,GalacticIndustriesInc.mighthave registeredthedomainnamegii.com,andtherootDomainwouldthereforebenamed gii.comaswell. 22 AssumingthatthiscompanyhasoperationsintheUnitedStates, Europe,andAsia,threeadditionalDomainscouldbedefinedasus.gii.com,eu.gii.com, andasia.gii.com.IftherewereoperationsontheeastandwestcoastsintheUS,then therecouldbetwoadditionalDomainsnamedeast.us.gii.comandwest.us.gii.com.Once anActiveDirectoryisconfiguredforthewest.us.gii.comDomain,aKerberosrealmwill beestablishedwiththerealmname,WEST.US.GII.COM,thoughinMicrosofts terminology,thisisoftenreferredtoastheprincipalnamesuffix.TheresultingDomain TreeisillustratedinFigure8below.
20Terminologycollisionscanleadtosomeconfusion.AMicrosoftDomainisconceptuallysimilarto aKerberosrealm,thoughMicrosoftrarelyusesthetermrealm.However,aDNSdomainnameisnot thesameasthenameofaMicrosoftDomain,andisthereforereferredtoasaDNSnameinMicrosoft terminology.Furthermore,theDNacronymreferstoanX.500DistinguishedNameandnotaDNS domainname.Ofcourse,allofthesetermsoverlaptosomedegree,andusesimilarnaming conventions.Inparticular,itisusuallypossibletodirectlyconvertaDNSnametobotharealm nameandMicrosoftDomainname,whichareoftenthesame.ADistinguishedNameincorporates thesameelementsasinDNSnames,thoughusuallywithadditionalnamingconstructs. 21InActiveDirectory,thetreestructureisreferredtoasaDomaintree,whichisessentiallyequivalent toaDirectoryInformationTreeorDITinLDAPandX.500terminology. 22Actually,ActiveDirectorynamesfollowtheX.500directorynamingconventions,sothisexample namewouldbeexpressedasdc=gii,dc=com.Similarly,thewestcoastoperationwouldbenamed dc=west,dc=us,dc=gii,dc=com.
Page 46 of 53

Figure 8Active Directory "Domain Tree" example showing hierarchical naming convention, Domain Controllers (DCs), Active Directory realms, and Trusts
Giventhisdescriptionandexample,itseemsthatDomaintreesfollowthetraditional DNSnamingconventions,andtheyusuallydo.However,thisisnotarequirement,and othernamingconventionscanbeused.AfulldiscussionofActiveDirectorynaming strategiesisbeyondthescopeofthisdocument,however,itshouldbenotedthatActive DirectorycanalsocombinemultipleDomaintreesintowhatistermedaDomainforest. ThisisillustratedinFigure9belowwheretwoDomaintreesarecombinedintoaforest. Aforestdoesnothaveahierarchicalrootinthetraditionalsense,butusesaspecialAD trustrelationshipcalledaforesttrusttointegratemultipledisjointtreesintoan enterprisewideActiveDirectory.Forestsareusedwherethetreesaremanagedby autonomousadministrativeregimes,suchaswhenacompanyhasmultiple independentsubsidiaries. WhenuseraccountsarecreatedinActiveDirectory,theyincludeUserPrincipalNames, orUPNs,whichareusedforlogonaccessandauthenticationviaKerberosonother mechanisms.TheUPNistheusersuseridfollowedbyan@followedbytheUPNsuffix. Normally,theUPNsuffixistheDomainname,butitcanalsobeashortenedversion configuredintheActiveDirectory.Usingtheaboveexample,auser,Bob,intheGalactic IndustrieswestcoastoperationcouldhavetheUPNofbob@west.us.gii.com,butifthe westcoastDomainadministratorconfiguresthesuffixofgiiwest,thenthisuser wouldhavetheUPNofbob@giiwest(seediscussionbelowonSupportforKerberos Referralsforfurtherinformationonhowuserscanaccessservicesthroughoutan enterprise).Eitherway,theUPNistheusersKerberosprincipalname.Notethat Microsoftdoesnotuseroleextensionsforuserprincipalnames.
Page 47 of 53

Figure 9Example of a Domain Forest with two Domain Trees
ComputeraccountsareassignedServicePrincipalNames,orSPNs.Inthedefaultcase, theSPNisconstructedfromtheDNSnameofthehost,buttherearevariousother optionsdependingonhowthelocalActiveDirectoryDomainhasbeenconfigured.In practice,MicrosoftSPNsarecreatedinamannerconsistentwithKerberosprincipal namesforservices. SinceActiveDirectoryistightlyintegratedwithDNSandKDCservices,thereisgreater flexibilityinassigningprincipalnamesandothernamesusedwithintheDomain.Put anotherway,whatevernamesaredefinedwithinActiveDirectoryarereflectedintothe DNSandKDCservices,sincebotharesubsetsoftheActiveDirectoryservice.Thistight integrationprovidesgreaterflexibilityinconfiguringandusingnameswithinan enterprise.Itmayalsoleadtointeroperabilityproblemsinmixedenvironmentswhere otherKerberosimplementationsmightbemoreconstrainedinhowprincipalsare named.
Microsofts Kerberos Support

MicrosoftsimplementationofKerberosisconsistentwiththeprotocolsspecifiedin RFC4120,andtheGSSAPIKerberoswirelevelprotocolsdefinedinRFC4121. However,tosupportitsoverallstrategy,Microsofthasintroducedseveralextensionsin itsKerberosimplementation,andtherearesomebehavioraldifferencesthatcanimpact interoperabilitywithnonWindowssystems.Microsofthaspublishedadocument, MSKILE,thatdescribestheiruseof,andextensionsto,theKerberosprotocols.Other MicrosoftdocumentsthathelpexplaintheoverallroleofKerberosinMicrosofts productsincludetheSecurityOverviewMSSECOandProtocolOverviewMSPROTO.
Basic Kerberos Support in Windows Server AMicrosoftDomainController(DC)supportsthestandardKDCfunctionsspecifiedin RFC4120,includinganAuthenticationServerforinitialauthenticationandissuing TGTs,aswellasaTicketGrantingServicethatclientsusetogetticketsforconnectingto services.MostKerberosclientsorservicesshouldbeabletointeractwiththeKDC servicesofferedbyaDC,withthecaveatthatticketsmaybemuchlargerthantypical (becauseofinclusionofPACs,seebelow)andTCPmayberequiredtointeractwiththe KDCtoreliablyexchangelargertickets.Therearealsoafewfeaturesnotsupportedin Microsoftsimplementation,thoughthesearenotwidelyused.TheMSKILEdocument detailsthecapabilitiesofMicrosoftsKerberossupport. MicrosoftalsosupportsGSSAPIwithKerberosincompliancewithRFC4121forwire levelprotocolexchanges(ref.TheGSSAPIandKerberosabove).However,thisis differentthanprovidingGSSAPIsupportwithintheWindowsplatforms.For applicationsbuiltonWindowsplatforms,MicrosoftprovidestheSecuritySupport ProviderInterface(SSPI)asthenativeWindowsAPIforauthenticationandother securityoperations.WhileitispossibleforapplicationsbasedonSSPItointeroperate withapplicationsbasedonGSSAPI,itisgenerallypossibleonlyforKerberos authenticationandsecuresessions.Inparticular,SSPIsupportsvariousMicrosoft proprietarycapabilitiesthatarenotsupportedbyGSSAPI,whereasGSSAPIsupports capabilitiesnotavailablewithSSPI.Microsoftreferstoapplicationsthatarecompatible withwirelevelGSSAPIasGSSaware. OneareawhereSSPIprovidesuniquecapabilitiesisitssupportforimpersonation(ref. MSSECOsection5).Conceptually,impersonationallowsaservicetotakeonthefull privileges(authorizations)oftheclientaccount,evenwhendoingsoelevatesthe privilegesoftheservicesownaccount.Thisisdifferentthandelegation,whereaservice isallowedtosubsequentlyauthenticatetoanotherserviceastheclient.Delegationis supportedbyKerberos,butimpersonationinvolvesauthorizations,andmustbe supportedbytheplatformOS.Mostotheroperatingsystemsdonotallowanyaccount totakeonelevatedprivileges,andrecentversionsofWindowsnowrestrict impersonationtoonlyalimitedsetofserviceaccounts. MicrosoftalsosupportsSPNEGO(ref.RFC4178,RFC4559,andMSSPNG)for negotiatingwhichauthenticationmechanismscanbesupportedbetweenaclientand service.SPNEGOisapseudomechanismthatworkswithintheGSSframeworkto allowGSSawareapplicationstouseSPNEGOinsteadofaspecificauthentication mechanism.SPNEGOthenhandlesnegotiationbetweenthepartiestoselectanactual mechanismthatcanbeusedforauthentication,butwithintherestrictionsofdefined policies.Forexample,theremightbeasystemwidepolicytorequiremutual authentication,inwhichcaseSPNEGOwouldpreventuseofonewayauthentication mechanismse.g.,NTLANManagerauthenticationprotocol,orNTLM. OnereasonforintroducingSPNEGOwastoprovideoptionsfortransitioningtonew authenticationmechanismsinthefuture,shouldbetteroptionsemerge.Anotherreason, though,wastoeasethetransitionawayfromolder,lesssecureauthentication mechanisms.MicrosoftsimplementationofSPNEGOessentiallyestablishesKerberosas thedefaultauthenticationmechanisminaWindowsServerenvironmentandtreatsthe
olderWindowsNTLMauthenticationmechanismasasecondaryoptiontobeusedonly ifKerberosisnotsupportedandpoliciesallow. Kerberos and the Microsoft Privilege Attribute Certificate (PAC) ThemostsignificantextensiontoKerberosintroducedbyMicrosoftistheinclusionof thePrivilegeAttributeCertificate(PAC)intheauthorizationdatafieldofKerberos ticketsasspecifiedinMSPAC.UseofthePACiscentraltoMicrosoftsstrategyto providecomprehensiveaccesscontrols,sinceitallowsauthenticationandauthorization tobeconductedinanintegratedmanner.ThePACdeliversinformationaboutaclients authorization(privileges)toaservice.ByincludingitintheKerberosticket,theservice receivesbothauthenticationoftheclientandauthorizationinformationinatrusted manner. 23 AlthoughticketsaregeneratedbyKDCs,intheMicrosoftcontext,theKDCis reallyanintegralpartoftheActiveDirectoryservice,soitisreallyActiveDirectorythat providesticketswithauthenticationandauthorizationinformation,andKerberosisjust theprotocolforrequestinganddeliveringtickets. Conceptually,aPACisalistingofallActiveDirectorygroupaccountsthattheclientisa memberof.Grouppolicyrulescanbeusedtodetermineauthorizationwithinthe application.SincethePACisprovidedonthefly,applicationsneedonlyknowtheir grouppolicyrules;theydonothavetomaintaingroupmembershiplistsorAccess ControlLists. WhileinclusionofPACsinticketsisconsistentwiththeKerberosspecifications(ref. RFC4120,section5.2.6), 24 ithassomeimportantimplications.First,aservicethatdoes notknowhowtointerpretaPACshouldignoreitifencounteredinaticket.Itisalso possibleforclientstospecifywhetherornotaPACshouldbeincludedwhentheyissue arequestforatickettouseaservice. OneconsequenceofincludingPACsisthatKerberosticketsaremuchlargerthan normal,whichcanleadtorequirementstoutilizeTCPinsteadofUDPforcarrying Kerberosmessages.MicrosoftsKerberossupportwilldefaulttousingUPD,but frequentlyrequiresuseofTCPtosupportlargermessages.SomeoldernonMicrosoft applicationsbasedonKerberosdidnothandleKerberosexchangesusingTCP,orcould notacceptlargeticketswithPACs,whichledtosomeinteroperabilityproblems.These problemsarefading,though,asmostapplicationstodayfullysupportKerberosover TCPandproperlyhandlelargerticketsizes. Support for Kerberos Referrals InmostWindowsServerenvironments,therewillbemultipleDomains,eachwithits ownDomainController(s).EachDomainControllerprovidesActiveDirectoryservices withintheDomain,andactsasaKDCforanycomputersorusersoperatingwithinthe Domain.SinceaDomainisalsoaKerberosrealm,theretendstobemultiple(many) Domains/realmswithinasingleenterprisesWindowsserverenvironment.Bycontrast,
23MicrosoftalsointroducesPACsintoclientserverdialogswhereTLS(SSL)isusedfor authenticationandsecurecommunications. 24IntheKerberosprotocolspecifications,ADstandsforAuthorizationData,andshouldnotbe confusedwithActiveDirectory.
Page 50 of 53
nonWindowsKerberosdeploymentsaremorelikelytouseasingleKerberosrealmfor anentireenterprise.Theexistenceofmanyrealmswithinanenterpriseleadstotwo challenges: 1. Userswouldliketobeabletouseonenamethroughoutanextended enterprise.Usersdonotwanttochangethenametheyusewhenthey(and theiraccount)movefromonedomaintoanotherintheenterprise.In enterpriseswithcomplexorganizations,userswouldratherusesome principallikeuser@somecorp.comthatisindependentofwhatdomaintheir accountislocatedin. 2. Users(clients)mustknowtheDomainnameforeachapplicationservicethey wanttoaccess.ThisisbecausetheclientwillneedtogetaTGTfromthe DomainKDCwheretheserviceresides. Inordertodealwiththesechallenges,Microsoftrequiresfullsupportforcrossrealm operationsasspecifiedinRFC4120plusextendedreferralsasdefinedinthe IETFDraftKerberosReferralsdocument.Microsoftsupportsextendedreferrals,as specifiedinsections3.1.5.8and3.3.5.3.1ofMSKILE. Atypicalapproachtodealingwiththefirstofthetwochallengesaboveistoallowusers tohavealiasnamesthatare,forexample,theiremailaddress.Toillustrateusingthe exampleofGalacticIndustriesInc,supposethatAliceisanemployeebasedintheEast CoastofficewithaDomainnameofeast.us.gii.comwhileBobisanotheremployee basedintheWestCoastofficewheretheDomainnameiswest.us.gii.com.However, bothAliceandBobhaveregularemailaddresses(RFC822)oftheformalice@gii.com andbob@gii.comrespectively.InsteadofusingtheirtraditionalKerberosprincipal nameswhenrequestinganinitialauthentication,theyusetheiremailnames.Sincethe requestistoaKDCthatisintegratedwithActiveDirectory,theusersnamecanbe mappedviathedirectoryservicetotheirhomeDomain.Therefore,ifAlicerequests initialauthenticationfromhereast.us.gii.comDomain,thenshewillgetbackaTGTas normal.However,ifAlicevisitstheWestCoastoffice,thenshemightmakeaninitial authenticationrequesttothelocalwest.us.gii.comDomain,shewillgetanerror responseindicatingwrongrealm,withabetterrealmnameprovided,whichmightbe east.us.gii.com,us.gii.com,orevenjustgii.com.Alicewouldthensendanother authenticationrequesttotheindicatedrealmKDC,andwouldgetbackeitheraTGT,or anotherwrongrealmresponsepointingtothenextrealmalongapaththatwill eventuallygethertothecorrectrealm.Normally,ActiveDirectorywillbeabletolook uptheuserscorrectDomain/realm,andprovidetheactualrealminthefirstwrong realmresponse. Thesecondchallengeisaddressedbyallowingclientstorequestaticketforaservice viatheircurrentlocalKDC,butwithoutspecifyingtherealm.InsteadofusingDNS nameservicestofindtheDomain/realmwheretheserviceactuallyresides,theKDC leveragesActiveDirectoryservicestomapthenameoftheservicerequestedbythe clienttothecorrectrealm,ortoatleastanintermediaterealmthatisclosertothe correctdestinationrealm.Insteadofgettingaserviceticketback,theclientgetsarealm referralresponsethatprovidesaTGTfortheactualdestinationrealm,orforan intermediaterealm.TheclientthenusestheTGTandindicatedrealmnametorequesta
Page 51 of 53
ticketfromthecorrespondingKDC.Iftheclientwasreferredtoanintermediaterealm, thentheywillhavetorepeatthisprocessuntiltheygettothefinalrealm.Onepoint worthnotingisthat,inActiveDirectory,servicesmayhavemultiplealiasnamesto makeiteasyforusersindifferentDomainstofindservices. Public Key Initial Authentication (PKINIT) TheWindowsServerplatformincludesacomprehensivePublicKeyInfrastructure (PKI)thatincludessupportforissuingpublickeycertificatestoalluserandmachine accounts,andlifecyclesupportforaccountcertificates.Consequently,Microsoftfully supportsPKINIT(ref.RFC4556)toallowclientstorequestinitialauthenticationbased ontheircertificateinsteadofusingapresharedsecretkey(password).Microsofts specificationsforusingPKINITareprovidedinMSPKCA. Thisisanoptionalservice,andrequiresthatanenterprisesetupPKIsupportfor issuingandmanagingcertificates.However,thisisbecomingincreasinglycommon,and providesallofthebenefitsnotedinPKINITPublicKeyCryptographyforInitial AuthenticationinKerberosabove.Inaddition,useofPKINITisanotherwaytoaddress thechallengeofhavingusersroamingbetweenDomains/realms.Itmayalsobeuseful incrossrealmauthentication,especiallywherenoActiveDirectorytrustshavebeen configured. ActiveDirectoryalsorespondstorequestsforcertificatesforspecificusersandother typesofaccounts,whichprovidesfurtheroptionsforauthenticatingclients,services, andevenKDCsorestablishingsecuredialogsbasedoncertificates. Other Microsoft Kerberos Extensions MicrosoftmakesuseofotherextensionstoKerberos.TwoworthnotingaretheService forUserextensionsasdescribedinMSSFUandaparticularstyleofUsertoUser KerberosinvolvingextensionstotheGSSAPIprotocolsdescribedinIETFDraftSwift win2kkrbuser2user,anowobsoleteIETFdraft.
Support for Kerberos from other Vendors

Kerberossupportprovidedbyothervendorstendstobeconsistent,andnormally followstheUnixmodelforimplementationsanddeployments.Mostimplementations arebasedoneithertheMITorHeimdalversions.However,asvendorsintegrate Kerberosmorecloselywithintheirplatforms,orwithotherservices,innovationsare beingintroducedthatmaysetnewdirectionsforKerberosuseinthefuture. Afutureupdatetothisdocumentmaybedevelopedtoprovidemorecomprehensive coverageoftheroleKerberosplaysinothervendorsplatformsandservices.
Page 52 of 53
Copyright Notice, 2008 by the MIT Kerberos Consortium Export of software employing encryption from the United States of America may require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting. WITHIN THAT CONSTRAINT, permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of MIT not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Furthermore if you modify this software you must label your software as modified software and not distribute it in such a fashion that it might be confused with the original MIT software. MIT makes no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty.
Page 53 of 53

Role Kerberos

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Role Kerberos

Hochgeladen von

Copyright:

Verfügbare Formate

The Role of Kerberos in Modern Information Systems

Access Control as a Primary Objective

Access Control Policies

Copyright Notice, 2008 by the MIT Kerberos Consortium.

An Example Access Control Policy

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Whilethisexampleillustratesaccesscontroltoafileobject,thefileisjustacontainerfor information,anditmaywellbethatthegoverningpoliciesapplytothedatacontainedinthefile, andnotthefileobjectperse.

Access Control Mechanisms

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Issues for Security Services

Delegation:Incomplexdistributedsystems,therearemanysituationswhereit maybenecessaryforauthorizationstobedelegatedtosomesystemoragentto actonbehalfofaprimaryauthority.Forexample,awebfrontendapplication

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Management Itmustbepossibletoaddandremoveprincipals, changeattributedata,editaccesscontrolpolicies, changesecrets(passwords)andotherwisemanage thedataonwhichthesystemdepends. Audit Thesystemmustrecordeachofitsactions.

Single Sign-On (SSO)

Copyright Notice, 2008 by the MIT Kerberos Consortium.

The Role of Kerberos

Naming in the Kerberos Context

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Data Integrity and Confidentiality

Replay Prevention in Kerberos

Non-Repudiation Support in Kerberos

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Kerberos support for Authorization

Authorization Information passed by Kerberos

Integrating Kerberos into Applications

The GSS-API and Kerberos

SASL and Kerberos

Pluggable Authentication Modules (PAM)

Kerberos and Public Key Cryptography

PKINITPublic Key Cryptography for Initial Authentication in Kerberos

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Support for Multiple Kerberos Realms

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Transitivity and Scaling Cross-Realm Relationships

Kerberosalsosupportsunidirectionalcrossrealmrelationships,whereclientscanauthenticateto servicesinaremoterealm,butnotviceversa.Thismightmakesenseifarealmisdefinedwhere servicesarelocatedthatwillbeaccessedfromotherrealms,butnoclientsthatneedtoaccess servicesoutsidetherealm.

Figure 5: Example of hierarchically organized cross-realm relationships

informationpresentsitsownscalabilitychallenges.However,ifclientsandKDCs supportrealmreferralsasdiscussedinSupportforKerberosReferralsbelow,thenonly KDCsneedtobeconfiguredwithcapaths.Forsomeenvironments,suchasActive DirectoryDomains,thisscaleswell.

Figure 6Example of hierarchical transitivity

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Cross Realm Relationships and Trust

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Managing Multiple Kerberos Realms

The Role of Directory Services

Copyright Notice, 2008 by the MIT Kerberos Consortium.

The KDC Database (Directory)

Copyright Notice, 2008 by the MIT Kerberos Consortium.

DNS and Kerberos

Issues with Relying on DNS

Directories and Kerberos

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Commonattributescanbedefinedandusedconsistentlyacrossmany applications. Directoriescanserveasrepositoriesforspecializedinformationobjects,suchas digitalcertificatesorprotectedkeys.

Securing Directory Services with Kerberos

Integrating Kerberos with Directory Services

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Kerberos Role in Directory Trust Relationships

Copyright Notice, 2008 by the MIT Kerberos Consortium.

Insupportofthesestrategicobjectives,ActiveDirectoryhasbeenpositionedatthecore ofMicrosoftsentirefamilyofWindowsServerproducts,andservesasthefoundation forbuildingdistributedsystemsonWindowsplatforms,includingthe.NET

Relevant Microsoft Terminology and Naming Conventions