Role Kerberos

7/28/2019 Role Kerberos

1/53

The Role of Kerberos inModern Information Systems

IntroductionAchievingadequatesecurityfortodaysinformationsystemshasproventobeaveryhardproblem.Inmanycases,theproblemsofsecurityhavebeenmadeevenharderbyahistoryoftreatingsecurityasanafterthought.Toooften,insteadoftakingacomprehensive,architecturalapproachtosecurity,ourfieldhasdeployedsecurity

measuresand

technologies

as

individual

bolt

on

solutions

to

very

narrow

problems.

Overtime,theresultingmosaicofsecurityrelatedtechnologiesbecomesbrittle,difficulttoextend,timeconsumingtomanage,andnotnecessarilyeffective.

Thisdocumenttakesanarchitecturallookatsecurity,butitisnotareferencemanualforsecurityarchitects.Instead,itfocusesontheroleoftheKerberosauthenticationsystemaspartoftheoverallecosystemofsecuritytechnologies,services,andsoftwarecomponentslikelytobeencounteredinatypicalmoderndistributedsystemsenvironment.Itisintendedforthosewhodesign,build,andmanageenterprisecomputinginfrastructure,aswellasforthosewhodevelopsoftwareintendedtooperateinsuchenvironments.Thisdocumentshouldanswermanyofthequestions

about

how

Kerberos

fits

into

modern

information

systems,

and

how

it

relates

to

other

vitalsystemservices.

Thisdocumentisexplanatoryratherthanprescriptive:itdescribesthecontextinwhichKerberosexists,andprovidessomeguidance,thoughthatisnotitspurpose.Instead,itisintendedasbackgroundfortwootherdocumentsthatdomakerecommendations,onefocusedonsystemsandplatforms,andtheotheronapplications:

RecommendedPracticesforDeployingandUsingKerberosinMixedEnvironments(pdf)

BestPracticesforIntegratingKerberosintoYourApplication(pdf)

Kerberosisasecuritytechnologythatismatureandthatisincreasinglydeliveredasanintegralcomponentofmodernsystems.Assuch,itcanbeanimportantelementofanoverall

security

framework.

However,

because

different

developer

communities

have

approachedKerberosintegrationindifferentways,newchallengesemergewhenusingKerberos,especiallyinthekindofdynamic,openended,mixedplatformenterprisecomputingenvironmentthatistypicaltoday.

Thisdocumentframesthosechallengesinthelargercontextofinformationsecurity.Itbeginswithafocusonaccesscontrolasanoverarchinggoal.Itthendescribesthevarioussecurityservicesthatcontributetoeffectiveaccesscontrol,anddiscussestheissuesthat

Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 1 of 53
http://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/mixenvkerberos.pdf


2/53

ariseinprovidingthoseservices.Next,itdescribestheroleofKerberosinprovidingthoseservices,focusingonthewaysinwhichKerberosintegrateswiththeothertechnologiesunderavarietyofscenarios.Itpaysparticularattentiontodirectoryservices,which,whilenotpartofKerberos,areoftenintegratedwithit.Finally,itintroducessomedetailsaboutthewayKerberosisusedwithinspecificoperatingsystemplatforms

suchas

Microsoft

Active

Directory,

Open

Directory,

and

others.

Access Control as a Primary ObjectiveUltimately,amajorpurposeofinformationsecuritytechnologyistoimplementaccesscontrol:toenableauthorizedaccesstoinformation,resources,andservicesandtopreventunauthorizedaccess.Accesscontrolencompassespoliciesthatindicateunderwhatcircumstancesaccessistobegranted,andmechanismstoimplementthosepolicies.

Access Control Pol icies

Anaccesscontrolpolicyincorporatesthefollowingfactors,eitherexplicitlyor

implicitly:

Author it ies and Regimes

Anauthorityistheentity(person,role,ororganization)responsibleforestablishingtheotherelementsofanaccesscontrolpolicy:definingandclassifyingresources,determiningauthorizations,definingallowedmeansofaccess,specifyingconfidencelevels,etc.Agivenauthorityhasresponsibilityforthepolicyelementsthatgovernaspecificsetofusersandresources,typicallyundercommonadministrativecontrol,forexample,alltheusersandhostsintheaccountingdepartmentofSomeCorporation.Thispaperreferstosuchagroupingasaregime,althoughthetermsadministrativerealmandadministrativedomainarealsoencountered.Sincerealmisalsousedinatechnicalsense

byKerberos,

and

domain

by

Windows

Active

Directory,

the

term

regime

is

less

overloaded.

Regimescanberelatedtoeachotherhierarchically:theSomeCorpAccountingDepartmentispartofthelargerSomeCorp.Theycanalsoberelatedinotherways:thepoliciesforSomeCorpAccountingDepartmentmightgrantaccesstocertainresourcestoemployeesofanoutsidecompanythatprovidescontractaccountingservicestoSomeCorp.Insomecontexts,externalregimes,suchasregulatorsorauditorsmaycontributetopoliciesandimposecertainpractices.

Resources

A

security

policy

must

define

theresources

to

which

it

applies;

examples

of

resources

includecomputers,abstractservices,files,networkconnections,andinformation.Resourcesmaybedefinedviaidentifiers(e.g.,thehostataddress172.24.37.1)orbyattributes(e.g.,allemployeerecordswheredepartmentnumberis47).



3/53

Resource Classif ication

Resourcescanbeclassifiedaccordingtothelevelofrisk,costs,orconsequencesassociatedwithmanagingaccess.Examplesofclassificationincludetopsecret,subscriptionrequired,downloadedfileisanapplication).

Access ContextAnaccesscontrolpolicyoftenmakesreferencetothecircumstancesunderwhichaccessisrequestedorthemeansbywhichaccessisprovided.Forexample,duringnormalbusinesshoursfromacompanyownedworkstationinasecureofficemightbeassociatedwithadifferentaccesspolicythanviaanunsecuredInternetconnection.

Al lowed Use

Examplesofpossibleusesforaresourceincluderead,modify,changeownership,modifyaccesscontrolpolicy,create,delete,etc.

Parties

Justas

an

access

control

policy

identifies

the

resources

to

which

it

applies,

it

also

identifiesthepartiesforwhomaccessisauthorized.Partiescanbereferredtoeitherbyidentifier(e.g.user#6718)orbyattribute(e.g.,allusersingroupAdministrators).Apartymaybeahumanuser,oritmaybeanabstractentity(e.g.,themaildeliveryprocessformailaddressedtoaddressesinsomecorp.com)

Confidence in Authenticity

Anaccesscontrolpolicymayhavedifferentrulesforaccessdependinguponthesystemsconfidenceintheauthenticityofaparty.Forexample,thisrequestcamefromaworkstationwhereJoeloggedin6hoursagousingapasswordandhasnotyetloggedoutsomewhatweaklyauthenticatestherequestascomingfromJoe.Ahigherconfidence

authentication

might

be:

thisrequest

includes

cryptographic

evidence,

less

than

2minutes

old,

thattherequestorpossessedasecuritytokenregisteredtoJoeatthetimetherequestwasmade.

An Example Access Control Policy

Asanexampleofanaccesscontrolpolicytakenfromafamiliarcontext,considerthepolicygoverningafilelocatedonsomeonesPC:

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



4/53


5/53


6/53

Theseessentialservicesaresupportedbyadditionalsystemservices,including:

Directoryservices:typically,informationaboutresources,policies,andvariousattributesofnamedpartiesisstoredindatabases;itmustbepossibletoretrieveuptodateinformationfromthesedatabasestosupportauthenticationandauthorizationdecisions,withtheaddedrequirementsthatthisinformationneeds

tobe

replicated

and

synchronized

throughout

adistributed

system

environment,

andthatthedatabasesthemselvesmustbeprotected.

Managementservices:itmustbepossibletomonitoroperations,detectfaults,configuresystemcomponents,initializeandupdateinformation,andauditbehavior

Figure 3Access control depends on other essential security services, but generally inan iterative manner that interweaves security services in complex patterns. Accesscontrol is itself often applied in an iterative manner.

Whiletherearemanysystemcomponentsthatcanbeusedtoprovidethesecoreservices,twostandardsbasedtechnologieshaveemergedaspreferredbuildingblockservices:

Kerberos

security

services

and

LDAP

based

directories.

While

Kerberos

is

stronglyassociatedwithauthenticationanddirectoryservicesareperceivedofasmanagingauthorizationandpolicydata,thedistinctionsaresomewhatblurredsinceKerberosalsoprovidesrudimentaryauthorizationfacilities,anddirectoryservicescanprovidesomeauthenticationmechanisms.Inpractice,Kerberosanddirectoryservicesarecomplementaryinnature,andmostsystemplatformsthatprovideaccesscontrolfacilitiesintegratetheseservicestoatleastsomedegree(e.g.,MicrosoftsActiveDirectoryincorporatesKerberosandLDAP,tightlyintegratedwitheachother).



7/53


8/53

mayneedtoretrieveinformationfromabackenddatabaseonbehalfofarequestinguser.Usersalsodelegateauthorizationstootherindividualsbysimplysharingpasswordsorotherauthenticationmethods.UsersevendelegateauthorizationstosoftwareagentstomanageadditionaldelegationbygivingtheseagentsuseridsandpasswordstoprovidetoothersystemsUnfortunately,manypolicyregimesdonotadequatelyaddressdelegationwithinstatedpolicies,

or

take

the

nave

position

that

delegation

is

not

allowed.

In

general,

it

is

besttodefinerationalpoliciesforappropriatedelegationofauthority,andprovidecontrolsforassuringthatdelegationissupportedincompliantways.

NetworkInfrastructure:Todaysnetworkinfrastructuredoesnotprovidesecurityservices,relyingonotherpartsofthesystemtoprovidetheseoftenvitalservices.Consequently,everyaspectofthenetworkevenaprivatenetworkmustbeconsidereduntrusted.Thisincludestheaddressesclaimedbynetworknodes,theDNSsystemthatmapsnamestoaddresses,DHCPservicesthatassignaddressestodevices,networktimeservicesthatareusedtosynchronizeclocks,servicediscoveryprotocols,andeachandeverypacketsentorreceived.Inparticular,ManintheMiddle(MitM)attacksarefeasible,andincreasingly

common.The

untrusted

nature

of

networks

substantially

complicates

access

control,andrequirescarefulplanninganddeploymentofrobustsecurityinfrastructuretoachievepolicycompliance.Ofcourse,therearemanyexampleswherepeoplechoosetotrustsystemsreachedoveruntrustednetworkswheretherisksareacceptable,suchasusingthepublicInternetforaccesstonewsandothercontent.Therecanalsobetightlycontrolledsubnetsthataretrustable,evenforhighrisktransactions.Intheend,itsallaboutacceptablerisks.

Registration:Proceduresareneededtoregisterorenrollusers,systemsandresourceswithinanaccesscontrolcontext,yetproblemsorvulnerabilitiesintheseprocedureshavethepotentialtocompletelyundermineanentireaccesscontrolsystem.Forexample,ifanimpostorisabletoenrollasanauthorizeduser

in

a

system

by

exploiting

some

vulnerability

in

the

enrollment

procedure,

then

it

doesnotmatterhowstrongorrobusttheaccesscontrolsystemis,sincetheimpostorwillbegrantedaccess.Notethatprivilegeescalationisanotherpotentialvulnerabilityinregistration/enrollmentproceduresifalegitimatepartyisabletoacquiremoreauthorizationsthanallowedbypolicies.Furthermore,registrationproblemsexistforbothhumanusersandmachines.Asthevarietiesandcapabilitiesofnetworkattachedmachines(e.g.,servers,applicationservices,printers,networkappliances)continuetoevolve,registrationproblemswithmachineryresultinneworincreasedthreats.

RevocationsandAuthorizationUpdates:Proceduresmustalsobeinplacetomodifytheauthorizationsgrantedtoparties.Inparticular,itisusuallynecessarytobeabletorevokesomeorallofapartysauthorizationsifthepartyisfoundinviolation

of

policies,

or

if

authentication

credentials

are

compromised.

Conversely,apartymayalsobegrantednewauthorizationsthatallowupgradedaccesstoresources.Anothercommonscenarioisthatapartysrolechanges,whichnecessitatesaddingsomenewauthorizationsandsimultaneouslyrescindingotherauthorizations.Animportantconsiderationwiththeseproceduresistheabilitytopropagatesuchchangesthroughoutanentireaccesscontrolenvironment.Forexample,ifausersaccessprivilegesmustberevoked,itcouldrepresentasignificantexposure(i.e.,risk)iftherevocationwillnotbe



9/53

recognizeduntilsometimelater.Similarly,ifauserisgrantednewprivileges,itcouldbecounterproductiveiftheyencounteraprolongeddelaybeforetheycanmakeuseoftheirnewprivileges.

KeyManagement:Thesecretsusedtoauthenticatepartiesincludingpasswordsmustbeprotectedfromdisclosureandwillneedtobereplaced

periodically,including

whenever

there

is

any

potential

that

such

secrets

have

beenexposedorcompromised.Theproceduresforhandlingreplacementofsecretpasswordsandkeysrepresentpotentialexposuresthatcouldleadtosubstantialrisksifexploited.Secretsalsoneedtobeprotectedfrominadvertentdisclosures,astheyrepresentattractivetargets.Passwordsusedbypeoplehavelongbeenrecognizedasfundamentallyweakariskthathasonlygrowninrecentyearsasmanymoreattackshavebeendevelopedtofoolusersintodisclosingtheirpasswords.However,secretkeysusedbyapplicationsandserversarealsobeingtargetedbyadversariesusinghighlysophisticatedattacks.Therealityisthattodaysaccesscontrolsystemsareonlyasstrongasthemanagementproceduresusedtomaintainsecretkeysandpasswords.

Liveness:It

is

common

for

policies

to

mandate

that

access

be

provided

only

to

authorizedhuman

users,

and

not

to

machines

or

software

agents.

However,

it

is

quitedifficultforanautomatedaccesscontrolsystemtodetermineifaremotepartyistrulyalivehumanbeing(thereverseTuringtest).Whilevarioushardwareandsoftwaretechniqueshavebeendevisedtoprovidelivenesstests,theefficacyofmanytestsisbeingunderminedbysmartermachines.Ingeneral,livenesstestingnowrequiressomesortofhardwaredeviceotherthanakeyboardonacomputerthatrequireshumanactivationoruse.Forexample,aonetimepassworddonglethatrequirestheusertotranscribeacodedisplayedonthedongleintoadataentryfieldontheircomputerscreenprovidesreasonableconfidencethatalivehumanisintheloop.

Scalability:Asinformationservicescontinuetoscaleupintermsofinformation

contentscope,

geographical

distribution,

and

number

of

users,

modern

access

controlsystemsfaceescalatingchallengesofscale.Unfortunately,themultidimensionalnatureofaccesscontrolsystemsusuallyleadstoatleastpolynomialscaling.Forexample,anorganizationthathaslineargrowthininformationbeingaccessedandalsoinitsuserpopulationislikelytofindaccesscontrolchallengesincreasinginproportiontotheproductofthesetwolineargrowthtrends.Notonlydoesscalechallengeaccesscontrolsystemsinthefamiliarareasofperformanceandmaintainability,scalealsoincreasestheattacksurfaceinwaysthatcanbedifficulttofullyassessandadequatelyaddress.

FederatedEnvironments:Manyorganizationstodayarefarflungenterprisesthatworkcloselywithbusinesspartners,outsourcedserviceproviders,andeven

customers.Therefore,

access

control

often

extends

beyond

traditional

organizationalboundaries(and,accordingly,acrosspolicyregimes),andnewfederatedmodelshaveemergedforextendingaccessauthorizationsacrosssuchboundaries.Consequently,accesscontrolsystemshavehadtoevolvetosupportfederatedinteractionsaswellasaccessfromnontraditionalentities.Federationalsoleadstonewpoliciesandnewchallengesinassuringcompliancewithbothnewandexistingpolicies.



10/53

Auditability:Accesscontrolsformoderninformationsystemsgeneratepotentiallysignificanteventsatenormousrates.Eventsmayrelatetoaccessgrantedordenied,authenticationofparties,authorizationsissued,changestodirectories,replications,changesinsecretsorkeys,revocations,managementoperations,configurationupdates,andmyriadotherstatetransitions.Evenassumingthatalloftheseeventsarelogged,effectiveauditpracticesrequiretheability

to

analyze

logs

for

patterns

of

aberrant

behavior

or

trends

that

portend

potentialproblems.Furthermore,theabilitytopreventpartiesfromrepudiatingeventsthatarerecordedinlogsmaybenecessarytoinsurecredibilityoflogrecords.Insomecases,auditrequirementsmightextendtoaccountingforaccessinsupportofvariousbusinessmodels.

UserConvenience:Securityservicesmustfunctionwithoutimposingundueburdenonendusers.Userswhoarerequiredtoestablishandmemorizelargenumbersofdifferentpasswordsfordifferentservices,whoarerequiredtoreauthenticaterepeatedlyduringthecourseofasession,orwhoarewronglydeniedaccess,willregardsecurityasexcessive,intrusive,andcounterproductive,andwill,insomecases,findwaystoworkaroundsecurity

protectionsthat

often

leave

the

system

worse

off

than

it

would

have

been

withoutthesecuritymeasures.Foroneexample,userswhoarerequiredtousecomplex,difficulttomemorizepasswordsoftenrespondbypostingtheirpasswordsontheirofficewallsnexttotheirworkstations.

Kerberos,especiallywhenintegratedwithrobust,enterpriseleveldirectoryservices,providesasolidfoundationforaddressingmanyoftheissuessummarizedabove.However,theeffectivenessofanysecuritytoolsetisdirectlyrelatedtothepracticesemployedinmanagingtheoverallinformationsystemsenvironment.Furthermore,noonetoolsetissufficientintodaysthreatcontext,andappropriatecombinationswillbeneededtoachieveadequatelevelsofsecurity.

NamingEvery

user,

host,

and

service

(collectively,

every

principalhasauniquename.

Authentication Itispossibletodeterminethatthepartyusinganameisitslegitimateowner

DirectoryAccess Itispossibletolookupattributesforanyname,e.g.,groupmembership,entitlements.

Authorization Itispossibletolookuptheapplicableaccesscontrolpolicyanddeterminewhetherornottheproposedaccessisauthorized.

ConfidentialityEavesdroppers

cannot

steal

the

content

of

messages.

Integrity Themessagethatapartyreceivesisthemessagethattheotherpartysent,hasnotbeencorrupted(deliberatelyoraccidentally)enroute.



11/53

Management Itmustbepossibletoaddandremoveprincipals,changeattributedata,editaccesscontrolpolicies,changesecrets(passwords)andotherwisemanagethedataonwhichthesystemdepends.

Audit Thesystemmustrecordeachofitsactions.

Single Sign-On (SSO)

Theabilityforuserstosignon(loginorauthenticate)oncepersession,andgetaccesstoalltheinformationresourcestheyneedwithoutsubsequentlybeingbotheredtoauthenticateagain,isanimportantuserconvenienceandamuchsoughtaftercapability.Kerberoshas,fromitsinception,providedaSingleSignOn(SSO)facilityforusers,whichitimplementsbycachingtimestamped,limitedusecredentialsandpresentingthemonbehalfoftheuserwhentheuserrequestsaccesstoresourcesandservices.

SingleSignOndoesnotchangeanyaspectoftheoverallaccesscontrolframework.

Eachtime

the

system

grants

access

to

aservice,

it

conducts

an

authentication

step,

but

withSSOtheauthenticationstepisbasedonretrievingcachedcredentialsratherthanuponaskingtheusertoenterapasswordagain.SoftwareclientsandservicesusingKerberosalwaysauthenticatewitheachnewinteraction,andmayusesessionkeystoauthenticateeachmessagetheyexchange.Withoutsuchprocedures,accesscontrolswouldnotbeeffective,andSSOwouldbeoflittleutility.

WhatKerberosofferstousersistheabilitytoprovetheirauthenticityonceinaperiod,andtocachethefactthatauthenticationwassuccessfulsothatsubsequentauthenticationsconductedbyclientsoftwareonbehalfoftheuserneednotinvolvetheuser.However,accesscontrolpoliciesmayimposeotherrequirementsthatcouldcauseuserstohavetoreauthenticate,orprovideadditionalproofsofauthenticity.Forexample,

if

auser

originally

signed

in

using

apassword,

and

is

now

attempting

to

accessaresourcewhosepolicyrequiresahigherdegreeofconfidence(forexample,useofasmartcardorotherphysicaltoken),theuserwillneedtoauthenticateagain.Or,anaccesspolicyforsomeservicesmightallowauthenticationviacachedcredentialsuptoeighthoursold,whileanothermightrequirethattheuserhasauthenticatedwithinthepast2minutes,orhasspecificallyauthenticatedthecurrentrequest.

ThereareotherrealworldpolicyconstraintsonthescopeofSSO.Forexample,auserthatauthenticatedunderonepolicyregimemaynotberecognizedinanotherpolicyregimeunlessatrustrelationshiphasbeenestablished.Sinceaccesscontrolsalsodependonauthorization, ausersignedoninonepolicyregimemightnotbeableto

provideacceptable

authorizations

in

another

policy

regime,

even

if

the

two

regimes

agreeonauthenticationofusers.

Consequently,whileitisreasonablethatusersshouldonlyneedtosignononce,itisoftenimpracticaltoofferuniversalaccesstoservicesthroughoutanextendedenterprise,andgenerallynotacrossmajorpolicyboundaries,suchasbetweenenterprisesoracrossnationalpoliticalborders(thoughnationalbordersdosometimesgetblurredinlarge,multinationalenterprises).



12/53

The Role of KerberosKerberosisafoundationalserviceonwhichapplicationsandothersecurityservicescanbebuilt.Atitscore,itprovidesthemeanstoauthenticateclientstoservers,andviceversa.Furthermore,italsoprovidesanarrayofotherservicesthathaveprovenboth

usefuland

vital

to

achieving

security

objectives

within

todays

information

systems.

The

capabilitiesofKerberoswillbeexploredbelowwiththeobjectiveofimprovingunderstandingoftherolethatKerberosplays,andhowitsrolecanbefurtherleveraged.NotethatthereaderisassumedtohaveabasicunderstandingofhowKerberosprotocolsworkandthemeansbywhichclientsandserversinteractwithKDCsandassociatedAuthenticationServicesandTicketGrantingServices.TutorialsonhowKerberosworksareavailablefromtheMITKerberosConsortium.

KerberosProtocolTutorial(html)

TheMITKerberosAdministratorsHowtoGuide(pdf)(Chapter1isabrieftutorial)

Naming in the Kerberos ContextAcommonterminologyprobleminsecuritydiscussionsisconfusionaboutthemeaningofnames,andhowtorelatenamestothethingsbeingnamed.Inparticular,thereisanunfortunatetendencytoconfuseidentifiersandidentities.

Strictlyspeaking,anidentityisanabstractionthat whichdistinguishesanentityfromallotherentitiesintheuniverse.Inotherwords,theessenceoruniquenessofanentity.Anidentityisnotsomethingthatcanbepointedto,writtendown,orstoredinadatabase.

Anidentifierontheotherhand,isthatwhichreferstoanidentity.Identifiersaremerelyhandlesthatcanbeusedtoconvenientlyreferencesomeentity,ofteninan

indirectmanner.

A

name

such

as

John

or

the

billing

department

of

Some

Corp.

isonetypeofanidentifier.Otheridentifierscanbenumeric(employee237)orattributebased(theusercurrentlyloggedinatworkstationF3B288).Relevanttypesofidentifiersincludeuserids,Kerberosprincipals,andX.500DistinguishedNames.

Identifiersmaybeuniquebutneednotbe.Johnreferstomanypeople.Someidentifiersaredeliberatelyconstructedsoastobeunique,eithergloballyorwithinaspecificcontext.Forexample,anIPaddressisconceptuallyauniqueidentifier,butRFC1918IPaddresses(socalledprivateIPaddresses)areonlyuniquewithinthecontextofaspecificphysicalnetwork.Furthermore,thereisnothingthatguaranteesuniquenessofIPaddresses,eitherlocallyorglobally,andspecifichostscanhave

dynamically

assigned

IP

addresses

that

change

over

time.

In

general,

uniqueness

of

namesrequirestheexistenceofsomeregistrationprocesstoguaranteethatnamingcollisionsdonotoccur.Forexample,domainnamesareusuallygloballyuniqueduetotheregistrationprocessadministeredbyICANN.Anothertechniqueusedtoapproximateuniquenesswithoutrequiringaregistraristoconcatenatemultiplenamesusedtoreferenceanentity.Forexample,apersonsfullnamecombinedwiththeirbirthdateandcityofbirthisusuallyunique.DNSnamesandnamesusedbyKerberosarealsoconcatenatedsequencesofsimplernames.

http://www.kerberos.org/software/tutorial.htmlhttp://www.kerberos.org/software/tutorial.htmlhttp://www.kerberos.org/software/tutorial.htmlhttp://www.kerberos.org/software/tutorial.htmlhttp://www.kerberos.org/software/tutorial.htmlhttp://www.kerberos.org/software/tutorial.htmlhttp://www.kerberos.org/software/tutorial.htmlhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/adminkerberos.pdfhttp://www.kerberos.org/software/tutorial.html


13/53

Thesameentitymaybereferencedbymanynamesoraliases.Forexample,apersonisknownbytheirgivenname,surname,birthdate,residentialaddress,telephonenumber(s),socialsecuritynumber,passportnumber,driverslicensenumber,andnumerousaccountnumbersanduserids.AliasesarecommonlyusedforentitiesauthenticatedbyKerberos.

Thesame

name

may

refer

to

different

entities

in

different

contexts.

For

example,

manyprogramsrunningaspartoftheoperatingsystemarelooselyreferredtoassimply,rootanexampleofanamethathasmeaningonlywithinaspecificcontext,andismoreaccuratelythenameofarole.Rootmayrefertodifferententitiesondifferentmachineswithinthesameenvironment.Virtualizationisarecenttechnicaltrendthatisgreatlycomplicatingthenamingofcomputersystems,aswellastheattributesassociatedwithcomputers,sinceasinglecomputersystemcanbesimultaneouslyrunningmultipleOSs,eachwithitsownnamingconventions.

Someidentifiersareassociatedwithattributes,orareencodedtoindicateattributes.Forexample,modelnumbersandsomeserialnumbersindicateattributesoftheassociatedequipment,andmightevenrelatetothingslikedateofmanufacture.

Other

names

are

addresses

that

can

be

used

to

locate

an

entity

in

some

space,

or

to

establishcommunications

with

the

entity.

Fortunately,Kerberosisfairlyconsistentinwhatitnamesandhownamesarestructured,thoughtherearedifferencesinnamingconventionsbetweencurrentversionsofKerberosandwithearlierversions.TherearealsosomedifferencesinnamingconventionsusedinMicrosoftenvironmentsversusotherenvironments.

TheentitiesnamedbyKerberosaretermedprincipalsandrealms.Aprincipalreferstoanentitysuchasauser,machine,orservice;arealmreferstoapolicyregime:anorganizationorspecificnetwork.

PrincipalsinKerberoscanbeeitherusersorsoftwareapplications(a.k.a.,services,

servers,computers,

applications,

nodes,

PCs).

User

principals,

or

often

just

principals,

arenormallyassociatedwithpersons,butmightbeassociatedwithrolesfulfilledbypersons,orevenagentsactingonbehalfofrealpersonsinsomecases.Hostorserviceprincipalscanrepresentasinglephysicalcomputer,oraservicerunningononeormorecomputers.Asinglephysicalcomputermighthostmultipleservices,eachgivenitsownKerberosprincipalname.Itisalsopossibleforasinglenamedserviceprincipaltobehostedacrossmultiplephysicalcomputers.Aprincipalnameincludesatextstringsuchasjoe,systemadministrator,ormailtransportdaemonandtherealmnameinwhichtheprincipalisdefined.

ThemostcommonformofarealmnameisderiveddirectlyfromaDNSdomainnamesuchasaccounting.somecorp.com.DNSdomainnamesaregloballyuniquetotheextentthat

they

are

registered

through

official

domain

name

registrars.3

By

convention,

Kerberosrealmnamesareusuallypresentedinuppercase:therealmassociatedwithaccounting.somecorp.comwouldbeACCOUNTING.SOMECORP.COM.Note,though,thatunlikeDNSdomainnames,Kerberosrealmnamesare,inreality,casesensitive.Thisprovidesanopportunityformisconfiguration:ifarealmisreferredtoinoneplaceas

3Actually,domainnameregistrationprocessesdonotguaranteeuniquenessofdomainnames;theyjustmakeduplicateslesslikely,andmoreeasilydetectable.



14/53

ACCOUNTING.SOMECORP.COMandinanotherasAccounting.SomeCorp.comthetwowillnotmatch.

AcompleteKerberosprincipalnametakestheformoftheprincipalname,followedbyan@character,followedbytherealmname,e.g.joe@SALES.SOMECORP.COM.Althoughthislookssyntacticallylikeanemailaddress,ithasnothingtodowiththe

deliveryof

email.

Simple

principal

names

(conceptually

similar

to

what

Microsoft

referstoasUserPrincipalNamesorUPNs)compriseauseridoraccountnamethatisuniquewithintherealm.Anotherformofuserprincipalcomprisesauseridconcatenatedwitharolename(e.g.,admin).4Thisconventionallowsasingleusertohavemultipleprincipalnamesthattheycanusedependingonwhatroletheyareperforming.5Principalnamesforservices(referredtoasServicePrincipalNames,orSPNs,inMicrosoftterminology)alwaysconcatenateoneormorecomponents;typically,oneofthesecomponentsistheFullyQualifiedDomainName(FQDN)ofthehost.Thisallowsmultipleservicestobeuniquelyreferenced,eventhoughtheyarehostedonasinglecomputerwithoneFQDN.6Inmostsituations,additionalconventionsareemployedtonameservicesinaconsistentmannerthroughoutanenterpriseoradministrative

realm.

Theimportanceofnamingconventionscannotbeoverstated,asnearlyeverythingelseintheoverallsecuritycontextdependsontheabilitytoreferenceentitiesbyconsistentnames,andtofurtherbeabletoassociateattributeswiththesenames.Namingissuesareofparticularconcerninmixedenvironmentswheredifferencesinnamingconventionscanleadtoseriousinteroperabilityproblems.SomepointsworthnotingaboutKerberosanditsnamingconventionsaresummarizedbelow:

KerberosKDCsalsoserveasregistrarsthatguaranteeuniquenessofprincipalnameswithinagivenrealm.Notethatcomponentnamesusedtoconstructaprincipalarenotrequiredtobeuniquewithinarealm,butanygivensequenceof

componentnames

used

to

construct

aprincipal

name

must

be

unique

within

the

realm.Failuretoassureuniquenessofprincipalnamescanleadtooperationalproblems,andisoneofthesourcesofproblemsinmixedenvironments.

IfarealmnameisthesameasapubliclyregisteredDNSname,thentherealmnamecanbeassumedgloballyunique,andbyinference,allKerberosprincipalnamesincorporatingthatrealmnamewillbegloballyuniqueaswell.

KerberoshasevolvedwithcertaindependenciesonDNSservicestobeabletoconfirmFQDNsorperformreverselookupsonIPaddressestomatchrequestsagainstFQDNs.WhilerelianceonDNSisusefulinanadministrativecontext,theinherentinsecurityofDNSmeansthatDNSlookupsshouldnotbeconsideredauthoritativetoanysignificantdegree.

4Concatenatedcomponentsofprincipalnamesuseforwardslashes(/)asseparatorsbetweencomponentnamesinthecurrentKerberosversion5.5AnexampleofaprincipalnameforthepersonRobertSmith,[email protected],andthissamepersonmighthaveanotherprincipalnameofrsmith/[email protected] forwhentheyareactingasaKerberosadministrator.6AnexampleofprincipalnamesforemailandfileservicesonahostnamedAtlasatGalacticIndustriesInc.mightbesmtp/[email protected] andhost/[email protected].



15/53

ThesyntacticalandsemanticsimplicityofprincipalnamesinKerberosisanadvantage.ThismakesitpossibleforallothersystemstoeasilyrecognizeandparseKerberosprincipalnames.

Whileitistheoreticallypossibletoencodevariousattributesaboutprincipalsbyconcatenatingcomponentnamesthatrepresentattributes,doingsois

overloadingthe

semantics

of

Kerberos

names,

and

is

not

considered

agood

practice.Principalnamesshouldonlycompriseasmanycomponentsasnecessarytoassureuniqueness.Inparticular,itwouldbeamistaketousecomponentnamesasameansforprovidingauthorizationinformation,primarilybecausenamingisnotsufficientlyflexibletoaccommodateauthorizationattributes,whichmayneedtochangeonamorefrequentbasisthannames.

KerberosKDCdatabasescomprisesimpledirectoriesthatmapprincipalnamestoauthenticationinformation(e.g.,sharedsecrets).However,theneedtokeepKDCoperationsefficientandsecurehasbeenastrongargumentforkeepingtheKDCdatabasesimple.

Kerberos AuthenticationAuthenticationisessentiallyaprocessthatdeterminestheauthenticityofaclaimtosomedegreeofconfidence.Usually,claimsareexpressedas,Iamthepartyknownbythisname.7Inordertoconfirmtheauthenticityofaclaim,anauthenticationsystemwillconductoneormoretestsinvolvingtheclaimantorothercontextassociatedwiththeirclaim.Forexample,aclassictestofaclaiminvolvesthechallenge,ifyourethepartythatgoesbythatname,thenproveitbypresentingthepasswordwepreviouslyshared.However,manyothertestscanbeused,includingothersocalledauthenticationfactors,suchasproofofpossessionofsomething(e.g.,asecuritytoken)ordemonstrationofuniqueattributes(e.g.,biometricparameters).Contextualcluescanalsobeusedthatmightnotinvolvepresentingachallengetotheclaimant.ExamplesofcontextualcluesincludethingslikeIP

or

MAC

addresses,

reverse

DNS

lookups,

or

past

patterns

of

behavior.

Effectiveauthenticationinvolvesbothpositiveandnegativetests.Challengeresponseinteractionsareexamplesofpositivetestssince,iftheresponseiscorrect,thenthereispositiveinformationsupportingtheclaim.AnexampleofanegativetestmightinvolvecheckingtheIPaddressusedbytheclaimant.IftheIPaddressispartofthesubnetassociatedwiththeclaimant,thenthereisnorealpositiveconfirmation,sinceanymemberofthesubnetcouldeasilyspoofanyIPaddressinthatsubnet.However,iftheIPaddressisfromasubnetwheretheclaimantshouldnotbelocated,thenevidenceisathandindicatingtheclaimislikelytobefalse.

Traditionally,Kerberosutilizespresharedsecretstoauthenticateparties.Inthecaseof

userprincipals,

the

pre

shared

secret

is

derived

from

ausers

password.

Service

or

host

principalsareauthenticatedthroughpresharedencryptionkeys.Unlikeother

7Notethatauthenticationisnotgenerallyidentification.Onlywhentheclaimisthatapartyisaspecificindividualorthingdoesitbecomereasonabletotreatauthenticationasidentification.Normally,identificationishardforcomputers(andforpeoplewherecomputersareinvolved).Consequently,identificationisonlyemployedwhenapartyinitiallyregisters,andsubsequentlyonlysimplerauthenticationproceduresareusedforefficiencyssake.



16/53

authenticationschemesinvolvingpresharedsecrets,Kerberosonlyrequiresprincipalstodisclosetheirsecretsonceatthetimeofinitialregistration.Subsequently,authenticationcantakeplacewithoutexchangingthepresharedsecret.

Inthecaseofuserpasswords,someKerberosimplementationsonlyknowakeyderivedfromthepassword,anddonotactuallyknowtheuserspassword.Furthermore,

passwordsare

not

exchanged

between

parties

during

authentication.

This

substantially

reducesrisksthattheauthenticationsecretswillbedisclosedduringnormalauthenticationoperations.However,ifthesepresharedsecretsareusedbynonKerberosauthenticationmechanisms,thentheriskofexposuremightbemuchgreater.Forexample,therearesystemswhereauserspasswordmightbeusedinanothermethodofauthenticationthatinvolvespassingthepasswordbetweentheuserandtheauthenticatingpartywitheveryauthenticationoperation.Clearly,bestpracticesavoidsituationswhereausersKerberospasswordisalsousedbylesssecureauthenticationmethods.

ModernKerberossystemsarealsoabletoutilizeotherauthenticationtestsinaddition

to,

or

as

alternatives

to,

passwords

and

shared

secrets.

One

option

is

to

use

public

key

cryptographictechniquesinconjunctionwithdigitalcertificatestoavoidanynecessitytopresharesecretkeysorpasswords.Inthiscontext,onlypublickeysaredisclosed,andtheirdisclosuretootherpartiesdoesnotrepresentariskunlessthecorrespondingprivatekeyissomehowdisclosed.Privatekeyscanbeprotectedbyusingvarioushardwareschemes(e.g.,smartcards),includingsomehardwaredevicesthatarenowcommonlybuiltintocomputers(e.g.,TPMchips).OtherauthenticationoptionsthatcanbeusedwithKerberosincludeOneTimePassword(OTP)dongles,scratchcards,andbiometricscanners.AnimportantimplicationisthatasystembuiltusingKerberoscaneasilyaddnewauthenticationmethodswithouthavingtoreengineerthesystem.

Mutual AuthenticationOneofthegreatestbenefitstousingKerberosasanauthenticationserviceisthatitprovidesthemeansforbothpartiesinanexchangetoauthenticateeachotheri.e.,mutualauthentication.MutualauthenticationisareadilyavailablefacilitytoanyapplicationthatusesKerberos.Experienceindicatesthatmutualauthenticationshouldalwaysbeused,andisanimportant(necessary)bestpractice.

Ithaslongbeenrecognizedthatmutualauthenticationisnecessaryforanysecuredialog.However,theasymmetricnatureofcommunicationsbetweencomputersandpersonshasbeenfrequentlyusedasanexcuseforallowingonewayauthentication. Ifthereisonelessonlearnedfromattemptstosecuresystemsitisthatanyvulnerability

allowedto

exist

will

be

exploited.

This

has

certainly

been

shown

to

be

the

case

for

the

vulnerabilitiesassociatedwithonewayauthentication,andthesurgeofphishingattacksinrecentyearsisjustoneillustrationofthisreality.

TheKerberosprotocolsresultinticketsbeingissuedtothepartyrequestingaccesstoaservicethatincludebothauthenticationinformationtheservicecanusetoauthenticatetherequestingparty,aswellasasessionkeythatcanbeusedinrespondingtotherequestingparty.Iftherequestingpartyreceivesbackfromtheservicearesponsebased



17/53

onthesessionkey,thentheyhaveconfirmationoftheauthenticityoftheservice.ThisisduetothewaythatKerberosticketsareformedbytheKDCwherethesessionkeyanduserauthenticationinformationareencryptedwiththeserviceproviderskey.Therefore,whentheservicereturnsaresponsetotherequestingpartythatusesthesessionkey,therequestingpartyknowsthatonlyaservicethatpossessesthesecretkey

sharedwith

the

KDC

could

have

correctly

respondedhence,

mutual

authentication.

A

furtherbenefitisthat,bycompletingthisexchange,bothpartiespossessanewsharedsessionkeyknownonlytothemthatcanbeusedtoauthenticateeverymessagepassedbetweenthem,andeventoestablishanencryptedsession.8

Source Authentication

Sofar,onlyonetypeofauthenticationhasbeendiscussedtheauthenticationofpeerentities.Anothertypeisknownasdataoriginorsourceauthentication,andinvolvesclaimsofthesort:thisdataisprovidedbyaspecificnamedparty.Kerberosalsoprovidessupportforthissecondtypeofauthentication.

Onemeans

offered

by

Kerberos

for

authenticating

the

source

of

information

is

provided

throughexchangeofasecretsessionkeybetweenaclientandservice.Ifthesessionkeyisusedtoencryptinformationexchangedbetweentheparties,orinproducingkeyedhashesoftheinformation,theneitherpartyknowsthatonlyapartyinpossessionofthesessionkeycouldhaveprovidedtheinformation.Inessence,everymessagecanbesourceauthenticatedthroughuseofthesessionkey.Again,bestpracticescallforbothpartiestoutilizethesessionkeytoauthenticatesubsequentexchangesofinformation.

Ifservicesaredeliveredinadistributedmanner,asingleclientmaybecommunicatingwithmultipleserviceprovidersatthesametime.Kerberossupportsmultiplemechanismsforclientstoestablishdistinctsessionkeyswitheachserviceprovider,whichallowsthesourceororiginofdatatobeauthenticatedineachcase.

SourceauthenticationisalsoprovidedforticketresponsesissuedbyaKerberosKDC,sincetherequestingparty(client)candeterminethattheresponsewasencryptedwithakeyknownonlybytheKDCandclient,andsimilarly,theserviceprovidercandeterminethattheticketwasencryptedwithitssecretkeythatwaspreviouslysharedwiththeKDC.ThisformofsourceauthenticationisaninherentfeatureoftheKerberosprotocols.ItalsomeansthatotherinformationintheticketencryptedwiththepresharedsecretisknowntohaveoriginatedfromtheKDC.Thisallowsticketstobeusedasauthorizations,andtheycanbeusedtocarryadditionalauthorizationinformation(seeKerberossupportforAuthorizationbelow)

Data Integrity and ConfidentialityKerberosalsoprovidesthemeansfordeterminingthatdatacontainedinticketshasnotbeentamperedwithoralteredsincetheticketwasgeneratedi.e.,dataintegrityisassured.Thisisessentialtopreventthirdpartiesfrommanipulatingticketsasameans

8TheoriginalsessionkeyisalsoknowntotheKDC.However,applicationstypicallyestablishanewsessionkeythattheKDCcouldonlylearnbyobservingtheexchangebetweenpartieswhenmutualauthenticationisused.



18/53

ofunderminingauthenticationprocedures,orchangingauthorizationinformation.Inparticular,aclientrequestingatickettoaccessaservicecannotmanipulatetheportionoftheticketintendedfortheserviceprovidertoauthenticatetheclient,sincethisportionoftheticketisencryptedwiththesecretkeyknownonlytotheserviceproviderandtheKDC.

Assumingthat

the

client

and

service

complete

the

exchange

of

asession

key,

then

this

sessionkeycanbeusedtoprovidedataintegrityforsubsequentexchangesbetweentheparties.Dataintegritycanbeprovidedbycomputingahashofthedatathatiskeyedusingthesessionkey(e.g.,useofanHMACfunction).Thisisthesamemechanismusedtoassuresourceauthentication. Ifthesessionkeyisinsteadusedtoencryptdatasentbetweentheclientandservice,thenconfidentiality,dataintegrity,andsourceauthenticationareallprovidedasabyproductofencryptingwithasecretknownonlytothetwoparties.

Replay Prevention in Kerberos

SinceKerberos

tickets

are

exchanged

over

untrusted

networks,

attackers

must

be

preventedfromreplayingticketstointerposethemselvesasapparentlyauthenticatedparties.Originally,KerberosticketsincludedtheIPaddressesoftherequestingclientandtheservice,whichprovidessomelimitedprotectionagainstreplayattacks.However,modernKerberosimplementationsemploytimestampstolimitthevalidityintervalofticketstoonlyafewminutes,whichhelpspreventreplayofticketsexceptduringthisnarrowtimewindow.ThisassumesthatallparticipantsinKerberosprotocolexchangeshavesomemeansofmaintainingtimesynchronizationwithinatleastafewminutes.9Inaddition,servicesaresupposedtomaintainacacheofticketsseenwithinthewindowoftimethatticketscanbevalid.Thisallowsaservicetodetectanyreplayattemptswithinthistimewindow.Useofclientspecificsessionkeysis

anothereffective

technique

for

preventing

replays.

Best

practices

require

all

services

thatrelyonKerberostoimplementcountermeasuresagainstreplayattacks.

Non-Repudiation Support in Kerberos

TheexchangeofsessionkeysandtimestampsinKerberosticketsthataregeneratedbythethirdpartyKDCalsoprovidesbasicnonrepudiationprotections.Repudiationisdefinedasonepartydenyingparticipationinallorpartofacommunicationsdialogwithanotherparty.10Inessence,theKDCservesasathirdpartywitnesstotheestablishmentofthesessionbetweenclientandservice.However,thisonlyprotectsservicesfromattemptsbyclientstorepudiatethattheyrequestedaccesstotheservice.

Clients

cannot

rely

on

the

KDC

to

vouch

for

whether

or

not

a

service

ever

responded

to

9UseofNTPservicesisacommonmeansforachievingtimesynchronization,butcaremustbetakentopreventattacksthatforceasystemtoupdateitsclocktoanearliertimewhenreplayedticketswouldstillbevalid.Inpractice,systemsthatrelyonNTPshouldavoidresettingtheirlocalclocksbackwardsintimetosynchronizewithanNTPserver.UseofNTPsecurityoptionsisalsoarecommendedpractice.10

Repudiationmightconsistofclaimsbyclientssuchas,Ididnotattempttoaccessthatservice,orIdidnotattempttoaccessthatserviceatthattime.



19/53

aclientrequest.Furthermore,thislimitedformofnonrepudiationisnotequivalenttotheprotectionsofferedbyelectronicnotaryservicesthataredesignedtodealwithcomplexrepudiationscenarios.

Thechiefbenefitofthislimitedformofnonrepudiationprotectionisthatitcanenhancethecredibilityofsystemlogsthatindicatewhichclientsaccessedwhich

servicesand

approximately

when

the

access

attempts

were

made.

This

improves

the

integrityofauditproceduresandthestrengthofauditcontrols.However,forthistobeeffectiveprotection,boththeKDCandserviceneedtokeeplogrecordsofeveryrequestfromaclient,whatservicetheclientrequestedaccessto,whentherequestwasmade,andtheactualticketissued.SincetheticketisencryptedwiththekeysharedbytheKDCandservice,neithercouldchangetheticketwithoutcausingadiscrepancyinthelogrecordskeptbyeach.TheKDCwillalsoneedtokeeplogrecordsofrequestsfromclientsforticketsasencryptedintheTGTsessionkey,aswellaslogrecordsforinitialauthenticationsandTGTticketsissued.ItisstandardpracticeforKDCstologthisinformation.

If

a

client

later

tries

to

repudiate

that

they

requested

access

to

a

specific

service,

then

the

KDChasproofthattheclientmadearequestforthetickettothatservice.Iftheservicegetstheticket,itcouldhaveonlycomefromtheclientbecausetheclientsauthenticatorwillhavebeenencryptedinthesessionkeyestablishedbytheKDCfortheclientandservicetouse.IftheserviceisabletodemonstratethatitslogrecordoftheticketmatcheswhattheKDCloggedfortheticket,thentheservicedidnotgeneratetheticketonitsown.Furthermore,theclientcouldonlyhavemadetherequestforaccesstotheserviceafterthetimeitrequestedtheticketfromtheKDC,whichpartiallypreventsrepudiationclaimsastowhentheclientmadetherequest.

Kerberos support for Authorization

AlthoughKerberos

is

primarily

an

authentication

service,

it

does

provide

basic

authorizationservicesforprincipalsregisteredwithintheKDCdatabase.Unlesssomeauthority(usuallyahumanbeing)hasregisteredaprincipalbyenteringtheirprincipalnameintotheKDCdatabasethroughsomeadministrativeprocedure,theprincipalwillnotbeknowntotheKDC,andwillnotbeabletousetheservicesoftheKDCtoauthenticatetootherprincipals.Consequently,onlyauthorizedprincipalsareincludedintheKDCdatabase,andpresumably,authoritieswithadministrativeaccesscanalsoremoveprincipalsfromthedatabasetodeauthorizethem.

Furthermore,KerberossupportsrudimentaryauthorizationserviceswhenissuingTicketGrantingTickets(TGTs)andforsessionestablishmentbetweenclientsandservices

servicesthat

are

provided

only

to

authorized

principals.

Kerberos

also

provides

facilities

forsecurelypassingauthorizationinformationtoservices.Theseauthorizationservicesaredescribedinthefollowingsubsections.

TGT Author ization

WhenclientsinitiallyauthenticatewiththeKerberosAuthenticationService(normally,asubsetoftheKDCservices),theyreceivebackTGTsthatareusedasauthorizationstoconductsubsequentrequestsforticketstoaccessotherservices.Thisisthewaythat



20/53

KerberossupportsSingleSignOn(SSO)sothataclientneedonlyauthenticateonce,andcanthensubsequentlyaccessotherserviceswithouthavingtopresenttheirpasswordorotherauthenticationinformationeachtime.

TheTGTreturnedbytheKDCtoaclientrequestinginitialauthenticationestablishesasession(seeSessionAuthorizationbelow)betweentheclientandtheTicketGranting

Service(TGS)also

typically

deployed

as

asubset

of

the

KDC.

This

session

is

based

on

anewsecretsessionkeysharedonlybetweentheclientandtheTGS(a.k.a.,theKDC).TheTGTisatimelimitedauthorizationwherenormallythetimelimitisatleastseveralhours,butrarelymorethanaday.

MutualauthenticationbetweentheclientandKDCistypicallyestablishedaspartofobtainingtheTGT.11Thisexchangeassuresbothpartiesthattheotherpartyknowsthepreviouslysharedsecret(e.g.,theclientpassword).Furthermore,byestablishinganewsecretsessionkeybetweentheclientandKDC,theclientneedonlyexposeitscopyofthepresharedsecretjustlongenoughtodecrypttheTGTreceivedbackfromtheKDCaspartoftheinitialauthenticationexchange.Inaddition,dataintegrityisassuredsince

all

subsequent

requests

from

a

client

to

the

KDC

for

service

tickets

and

responses

from

theKDCbacktotheclientwillbeencryptedwiththeTGTsessionkey.Replayprotectionisprovidedbyrequiringclientstoprovidetimestampedauthenticatorsineachrequestforanewserviceticketthatmakeeverysuchrequestunique.

WhenaclientwantstoaccessaserviceinanotherKerberosrealm(seeCrossRealmAuthenticationbelow),itobtainsfromtheKDCintheclientsrealmaTGTitmayusewiththeKDCintheservicesrealmtothenrequestaticketfortheservice.ThiseffectivelyextendsauthorizationfromtheclientsKDCtotheremoteKDCrealmandallowstheclienttoestablishanauthorizedsessionwiththeremoteKDCforrequestingtickets.Notethatthisdescriptionofcrossrealmaccessissimplistic,buttheconceptsholdinscenariosthataremorecomplex.

Session Authorization

Kerberosalsoprovidesbasicauthorizationservicesforestablishingcommunicationssessionsbetweenprincipals.Infact,Kerberosticketsaresecuredauthorizationsthataserviceproviderusestoauthorizeestablishmentofacommunicationssessionwithaclient.TheauthorizingpartyistheKerberosKDCthatissuesticketstoclients.However,thetrueauthorityisthepartyresponsibleforenteringthenamedprincipalintheKerberosKDCdatabaseofauthorizedusersandservicesi.e.,theregistrationauthority.IfapartydoesnothaveaprincipalnameintheKDCdatabase,thatpartyisnotauthorizedforanyservicethatdependsonKerberosforauthentication.

Acommon

statement

about

Kerberos

is

that

it

only

authenticates

principals

to

each

other,andthatauthorizationisadecisionmadebytheprincipalsbasedonsomeapplicationcontext.ThisisbecauseKerberosrealmsmayhaveveryliberalpoliciesfor

11TheclientalwaysauthenticatestheKDCinthefirstexchange.TheKDCcanuseafacilitycalled

preauthenticationtoauthenticatetheclientbeforeissuingtheticket,ortheKDCcanwaituntiltheclientfirstusesthetickettoknowthatitwasabletosuccessfullydecrypttheticket.Currentbestpracticeistousepreauthentication.



21/53

whatprincipalsareregistered.Forexample,arealmmayregisteranyunusedusernamebasedonarequestatawebpage.WorkisongoingtoallowanonymousKerberosauthenticationwithoutregistrationinanyKDCdatabase.Similarly,somerealmshaveveryliberalpoliciesaboutwhatservicesareregistered.Asaresult,applicationdesignerscannotmakeanyassumptionsaboutauthorizationsimpliedbyregistrationin

aparticular

realm;

potentially

any

entity

that

requested

such

registration

may

be

able

to

obtainitinsomerealms.

Ontheotherhand,settingpoliciesforwhatprincipalsareregisteredinarealmisapowerfulaccesscontroltoolforITadministrators.Whenaclientpresentsatickettoaservice,theserviceispresentedwithinformationthatnotonlyauthenticatesthenamedprincipal,italsoindicatesthattheclientprincipalisregisteredintheKDCdatabase.Theservicereceivingaticketfromarequestingclientmustdecidewhetherornottoestablishcommunicationswiththeclientbasedontheticketcontents,andanyotherinformationtheservicemayhaveathand(e.g.,alistofprincipalsauthorizedtousetheservice).However,thisdecisionwillbebasedinpartontheticketthatisissuedbytheKDC,whichis,infact,anauthorizationissuedbytheKDCstatingthattheprincipalisan

authorized

party

within

the

KDC

database.

Section1.4ofRFC4120advisesthatApplicationsshouldnotacceptthemereissuanceofaserviceticketbytheKerberosserver(evenbyamodifiedKerberosserver)asgrantingauthoritytousetheservice.Thisissoundadvice,sinceauthorizationtoestablishasessionisnotthesamethingasauthorizationtousetheservice.Onlywithinaspecificapplicationandpolicycontextcanrationaldecisionsbemaderegardingappropriateauthorizations.Atthesametime,effectiveaccesscontroloftendependsonmultiplelevelsofauthorization,andsessionauthorizationisausefulfirststepinanaccesscontrolstrategy.Insomespecificcases,suchasremoteaccesstoanetwork,itmayevenbesufficient.ApplicationdesignersshouldprovidetoolsthatmakeiteasyforIT

administratorsto

take

advantage

of

this

level

of

authorization;

for

example,

in

some

casesitmaybedesirabletograntaccesstoallprincipalsinarealm.

Author ization Information passed by Kerberos

Kerberoscanalsoplayasupportingroleinaccesscontroldecisionsbypassingauthorizationinformationsecurelytoaservicewithinaticketusedtoauthenticateaclientrequestingaccesstotheservice.TheKerberosprotocolspecificationsprovidefortwoclassesofauthorizationinformation.ClientsorKDCscanaddrestrictionstoticketsrestrictingthecontextinwhichtheticketisvalidortheaccessthatshouldbegrantedtoapartyauthenticatingwiththisticket.Inaddition,KDCscanaddauthorizationinformationgrantingadditionalprivilegesordescribingauthorizationattributesofthe

entitythat

the

client

principal

names.

Facilities

are

provided

so

that

clients

cannot

create

thesecondtypeofauthorizationinformation.WhiletheKerberosprotocolspecificationsdonotindicatehowthisauthorizationinformationistobeused,orevenallthedetailsofhowtheinformationisstructured,thisoptioncanbeusedtoextendtheutilityofKerberosservicesinmanagingaccesscontrol.SincetheticketisencryptedwiththepresharedsecretkeyknownonlytotheserviceandtheKDC,theserviceisabletotrusttheinformationinthisticket,bothtoauthenticatetheclientandtheauthorizationgrantedtotheclient.

http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4http://tools.ietf.org/html/rfc4120#section-1.4


22/53

Forexample,whenaclientrequestsaserviceticket,iftheKDCincludesalistofgroupsthisclientprincipalbelongstointheauthorizationdatafieldoftheticket,thentheservicewillbeabledeterminewhatresourcestheclientisallowedtoaccessbasedongroupmemberships.ThisveryschemeiswidelydeployedbyMicrosoftaspartofitsWindowsServerplatforms.Otherexamplesofauthorizationdatathatcouldbepassed

withinaticket

include

time

of

day

restrictions,

subscription

information,

transaction

limits,orusagequotas.

MicrosoftsuseofKerberosasameanstopassgroupmembershipsandotheraccountinformationinserviceticketsisthemostwidelydeployedexampleofextendingKerberosinthismanner.TheauthorizationdataispackagedintoastructureknownasaPrivilegeAttributeCertificate,orPAC(refertothesectionKerberosandtheMicrosoftPrivilegeAttributeCertificate(PAC)below).InaMicrosoftservercontext,theKDCisasubsetofaDomainController,andsinceDomainControllersmaintainaccountsforallusersandsystemsoperatingwithintheDomain,itisfeasibleforthePACtobeinsertedinserviceticketswhenclientsrequestaccesstoservices.

One

concern

with

trusting

authorization

data

in

tickets

is

that

a

service

could

generate

ticketstoitself.ThisisbecausethekeyssharedbetweenservicesandKDCsaresymmetricencryptionkeys,whichalloweithersidetoencryptthedata.ThisallowstheservicetotrustaticketreceivedfromaKDC,sinceonlytheKDCshouldknowthesecretkey.However,aservicecouldgenerateitsownticketusingitskey.WhilethisdoesnotundermineKerberosauthentication,theabilitytogeneratenewticketscouldbeusedtoelevateprivilegesifauthorizationinformationintheticketistrustedbyapartyotherthantheserviceforwhomtheticketisissued.Toavoidthispotentialexposure,softwaresuchasthelocaloperatingsystemthatwishestouseauthorizationinformationfromaticketissuedtoanotherserviceshouldconfirmauthorizationinformationwithatrustedsourcebeforemakingaccesscontroldecisionsbasedonthis

information.For

example,

Microsoft

addresses

this

problem

by

having

the

Local

SecurityAuthorityconfirmPACsreceivedbyunprivilegedserviceswiththeDomainControllerviaanindependentsecurechannelestablishedusingtheirNetlogonfacility.

Integrating Kerberos into Applications

TheprocessofintegratingKerberosintoanapplicationiscolloquiallyreferredtoasKerberizinganapplication.Thecompaniondocument,BestPracticesforIntegratingKerberosintoYourApplication(pdf),providesacomprehensiveguidetoapplicationintegrationissues.However,abriefreviewofintegrationoptionsisprovidedheretohelpclarifytherolethatKerberosplaysinothersystemapplications,especiallydirectoryservices,whichwillbediscussedingreaterdepthinTheRoleofDirectoryServicessectionbelow.

The GSS-API and Kerberos

TheGenericSecurityServicesApplicationProgramInterface,orGSSAPI,wasdevelopedasawaytodecoupleapplicationsfromunderlyingsecurityservices,especiallyauthenticationmethods.KerberosandGSSAPIarecloselyrelated,eventhoughtheGSSAPI(ref.RFC2743)isdesignedtoallowanyauthenticationtechnologytobeused

http://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdfhttp://tools.ietf.org/html/rfc2743http://tools.ietf.org/html/rfc2743http://tools.ietf.org/html/rfc2743http://tools.ietf.org/html/rfc2743http://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdf


23/53

byanapplication.ItjusthappensthatKerberosisthedominantauthenticationtechnologyusedwithGSSAPI.Furthermore,theGSSAPIhasbecomethestandardizedAPIforKerberos(ref.RFC4121),sincetheKerberosprotocolspecificationsdonotdefineanyAPIs,andvariousKerberosimplementationsutilizeincompatibleprograminterfaces.

TheGSS

API,

when

used

with

Kerberos,

actually

defines

wire

level

protocols

that

are

exchangedbetweenpartiesusingGSSAPIsothatdataconfidentialityandintegrityassurancecanbeprovidedinadditiontoauthentication.Inthissense,itismorethanjustanAPI.AnimportantimplicationisthatapplicationscouldbebuiltthatarecompatiblewiththewirelevelGSSAPIKerberosprotocols,butthatdonotactuallyusetheapplicationprogramminginterfacedefinedbytheGSSAPIe.g.,MicrosoftsSecuritySupportProviderInterface,orSSPI.12EventhoughtheprogramminginterfacesprovidedbytheGSSAPIandMicrosoftsSSPIarequitedifferent,itisstillrelativelystraightforwardtobuildapplicationsusingoneAPIthatwillinteroperatewithapplicationsusingtheotherAPI.However,duetofundamentaldifferencesinapproach,itisalsopossibletobuildGSSAPIapplicationsthatcannotbemadetointeroperatewith

SSPI

applications,

and

vice

versa.

TheSimpleandProtectedNegotiation,orSPNEGO,mechanism(ref.RFC4178)canbeusedtoextendGSSAPIandisalsousedwithMicrosoftsSSPI.SPNEGOisactuallyapseudomechanism(orpseudoservice)thatallowspartiestonegotiatewhatsecurityservicestheycanbothsupport.Inotherwords,SPNEGOusesthesecurityservicesofanunderlyingmechanism,suchasKerberos,toprovidethesecurityserviceofprotectednegotiationtoanapplication.Theapplicationselectsthedesiredunderlyingsecurityservicewhileminimizingthepossibilitythatanattackercandisruptthenegotiation.Animportantbenefitofusingthisformofnegotiationisthatithelpseasethetransitionfromlesssecureauthenticationservicestowardmoresecureservices,suchasKerberos.

Consequently,in

an

environment

where

applications

based

on

the

GSS

API

have

been

deployed,newauthenticationservicescanbeintroducedinsuchawaythatstrongerservicesarepreferredandolder,lesssecureauthenticationservicescanbephasedoutinagracefulmanner.

SASL and Kerberos

TheSimpleAuthenticationandSecurityLayer,orSASL,frameworkwasintroducedasawaytofurtherinsulateapplicationsfromunderlyingauthenticationandothersecurityservices(ref.RFC4422).SASLprovidesanapplicationframework(morethanjustanAPI)thatsimplifiesbuildingsecureapplicationsthatonlyneedasimple,bidirectionalstreamorientedcommunicationsfacilitybetweenpeers.Itisparticularlyeffectiveat

allowingapplications

to

simultaneously

support

various

authentication

mechanisms

withoptionalconfidentialityandintegrityassuranceservices.SASLusestheGSSAPIforKerberosauthenticationsupport,andoptionallyfordataconfidentialityand

12MicrosofttendstodescribeapplicationsthatarecompatiblewithGSSAPIwirelevelprotocolsas

GSSAwareapplications.TheSSPIinterfaceisaproprietaryMicrosoftspecificationdescribedinthisdocument:http://msdn.microsoft.com/en us/library/aa380493.aspx

http://tools.ietf.org/html/rfc4121http://tools.ietf.org/html/rfc4121http://tools.ietf.org/html/rfc4121http://tools.ietf.org/html/rfc4178http://tools.ietf.org/html/rfc4178http://tools.ietf.org/html/rfc4178http://tools.ietf.org/html/rfc4422http://tools.ietf.org/html/rfc4422http://tools.ietf.org/html/rfc4422http://tools.ietf.org/html/rfc4422http://tools.ietf.org/html/rfc4178http://tools.ietf.org/html/rfc4121


24/53

integrity.ItisalsocommonforSASLapplicationstosupportTLS(SSL)asanalternativemeansforprovidingdataconfidentialityandintegrityprotection.

SomepopularInternetapplicationsthatareavailableinSASLbasedversionsinclude:

BEEP:BlockExtensibleExchangeProtocol,whichisitselfaframeworkforapplicationsthatneedtoexchangeblockorientedmessagesandmanagequeries

and

responses

IMAP:InternetMessageAccessProtocol,whichisapopularprotocolforemailclientstointeractwithemailservers,includingMicrosoftExchangeservers

LDAP:LightweightDirectoryAccessProtocol,whichisthefoundationformostofthemoderndirectoryservices,includingMicrosoftsActiveDirectory

POP3:ThewidelyusedPostOfficeProtocol(version3)usedbyemailclientstodownloademailfromservers

SMTP:SimpleMailTransferProtocol,thepushprotocolusedtosend(and

receive)

email

from

clients

to

servers

and

to

exchange

email

between

servers

XMPP:eXtensibleMessagingandPresenceProtocol,aninstantmessagingprotocolusedinJabberandotherIMapplications,suchasPidgin

KerberosiswidelyusedbySASLversionsoftheemailprotocolsandLDAPdirectoryservices,aswellassomeapplicationsbasedonXMPP.

Channel Binding

AmorerecentapproachtoallowingauthenticationmethodstobeusedinconjunctionwithothersecurityprotocolsistermedchannelbindingandisdescribedinRFC5056.Channelbindingallowsamutualauthenticationexchangetoauthenticateasecure

channel

between

the

parties

as

well

as

the

parties

to

each

other.

This

is

useful

where

applicationsmayhaveaccesstosecureprotocolservices,orchannels,suchasTLSorIPsecthatcanbeusedforcommunicationsbetweenparties.Theproblemis:howdoapplicationsknowthatthepartytheyhaveauthenticatedisalsothepartyontheotherendofthesecurechannel?Ifthechannelcanbeuniquelyreferenced,andsomechannelidentifiercanbeincludedintheauthenticationexchange,thenitispossibletobindthechanneltothemutuallyauthenticatedsessionbetweentheparties.Inotherwords,theywillknowthatthepartytheyhaveauthenticatedisalsothepartyontheotherendofthesecurechannel.

ChannelbindingprovidesamoregeneralapproachthanwhatisprovidedbytheSASLframeworkwhereitisdesirabletouseKerberoswithothersecurityservices,suchas

TLSor

IPsec.

While

not

widely

deployed

yet,

this

approach

is

likely

to

become

abest

practicefordeployingsecureapplicationsthatneedflexibleapproachesfordecouplingauthenticationfromothersecurityservices.

Pluggable Authentication Modules (PAM)

ThePluggableAuthenticationModules(PAM)frameworkwasoriginallyproposedbySunasamechanismtodecoupleauthenticationfromloginapplications.PAMwas

http://tools.ietf.org/html/rfc5056http://tools.ietf.org/html/rfc5056http://tools.ietf.org/html/rfc5056http://tools.ietf.org/html/rfc5056


25/53


26/53


27/53

clientscontinuetoreceiveTicketGrantingTickets(TGTs)thatwillbeusedtosubsequentlyrequestticketsforservices,andservicescontinuetoauthenticateusersviaticketsissuedbyKDCs.Aservicehasnoneedtosupportpublickeycryptography,orevenknowhowtheclientinitiallyauthenticatedtotheKDC.Fromanapplicationperspective,clientandserviceinteractionsareexactlyasbefore.

Animportant

consequence

of

using

PKINIT

is

that

users

can

more

easily

be

given

an

accountinarealmtheyhavenevervisitedbefore.Ifanemployeeorcontractorwithatrustedcertificatemovestoanewpartofanorganization,theiraccountcanbewaitingforthemwithnoneedtoregisteranewpassword.Furthermore,useofpublickeycertificateshelpsmitigateriskswithweakuserpasswords,sincetheusersprivatekeyisusedduringinitialauthenticationinsteadofapassword.Ausermaystillenterapassword,butonlyontheirlocalworkstationordevicetounlocktheprivatekey.Passwordchangestendtobehandledattheuserdevicelevel,anddonothavetobecoordinatedwithothersystems.

Atleasttheoretically,usingPKINIT,userprincipalsnolongerneedtoberegisteredin

the

KDC

database

before

initial

authentication,

since

the

KDC

does

not

need

to

look

up

thecorrespondingsharedsecretforauserwithacertificate.ServiceprincipalsmuststillberegisteredintheKDCdatabasealongwithasharedsymmetricencryptionkey.AKDCdatabasecouldbemuchsmaller,sincetheretendtobemoreuserprincipalsthanserviceprincipals.However,inpractice,usersstillneedtoberegisteredtostorepolicyandotherinformation.Alsoasdiscussedbelow,entitlementinformationandotherattributesaboutauseraretypicallystoredinsomedirectory.PKINITdoesnotreducetheneedforthisinformation.WithPKINIT,theadministrativeoverheadformaintainingtheKDCdatabaseshouldbereduced,anduserpasswordchangeswouldnolongerneedtobesupportedforuserswithcertificates.Fororganizationsthatalreadyissuecertificatestousers,itispossibletoallowuserstoauthenticatewiththeir

certificateacross

multiple

authentication

systems,

including

systems

that

use

TLS/SSL

andvariousVPNtechnologiesinadditiontoKerberos.Atthesametime,applicationsbasedonKerberosdonotneedtobechanged.

Anotherbenefitisthatcertificatescanbeassociatedwithhardwarecryptographictokens,includingsmartcardsandUSBdeviceswithembeddedsmartchips.Somebiometricauthenticationdevicescanalsobeusedwithcertificates,butwherethebiometricdeviceisusedtounlockaccesstotheusersprivatekey.

Ofcourse,thesebenefitscomeattheexpenseofdeployingaPublicKeyInfrastructure(PKI)thatincludesCertificationAuthorities(CAs),certificaterequestandissuingservices,certificaterevocationprocedures,statuscheckingservices,anddirectoriesfor

retrieving

certificates

for

specific

users

or

other

principals.

However,

PKI

has

become

an

integralpartofseveralvendorplatforms,anditiswidelyavailable.Inmanyenvironments,theadvantagesofpublickeycryptographyandcertificatesmorethanjustifytheaddedburdenofdeployingandmaintainingaPKI.Alternatively,PKINITcanbeusedwithoutaPKI.TheKDCdatabasecanstoreselfissuedcertificatesassociatedwithuserprincipals.ThisavoidsrelianceonaCA,sincetheKDCcantrustapublickeyinitsdatabase,andnopasswordsecretisneededfortheuser.However,other



28/53

advantagessuchaseasymigrationbetweenrealmsandsupportforapplicationsbeyondKerberostendtorequireaPKI.

Oneconcernwithcertificatesusedinauthenticationisthattheytendtohaverelativelylonglifetimesontheorderofmonthstoevenacoupleofyears.Thisleadstogreaterexposureswhenprivatekeysarecompromised,orauserscertificateneedstobe

revokedfor

some

cause.

This

means

that

aKDC

might

allow

auser

with

arevoked

certificatetoauthenticate,andsubsequentlyaccessapplicationservices.Therearetwoapproachesformitigatingthisrisk,(1)distributionofCertificateRevocationLists(CRLs)and(2)useofOnlineCertificateStatusProtocol(OCSP)services(ref.RFC2560).UseofOCSPservicesisparticularlyattractive,asitallowscertificatestatustobecheckedinrealtimeaspartoftheinitialauthenticationprocess.RFC4557specifieshowPKINITcanbefurtherextendedtointegrateOCSPchecksduringKerberosinitialauthentication.

Support for Multiple Kerberos Realms

AKerberos

realm

must

be

administered

as

asingle

database

of

principals

and

associatedkeys.Foreachrealm,thereissomeregistrationprocessthatenrollsprincipalsintotherealmsdatabase,andonlytheseenrolledprincipalsareabletoauthenticateeachother.Althoughanenterprisemaychoosetohaveonlyasinglerealm,practicalconsiderationsoftenresultinmultiplerealmsbeingestablishedunderdifferentadministrativeregimes.Whilehavingseparaterealmsfordifferentadministrativeregimessolvessomeproblems,italsoleadstoadditionalcomplexityandnewproblems.

Beforediscussingsupportformultiplerealms,itisworthrestatingthatasinglerealmcanbesupportedbymultipleKDCs.ThismaybedonetoimproveavailabilitybyhavingredundantKDCsorKDCsthataredistributedclosertousersandservices.Insome

cases,

it

may

also

help

improve

performance

by

having

the

workload

distributed

acrossmultipleKDCs.However,allKDCswithinarealmusethesameKDCdatabase,whichmustbereplicatedfromamasterKDCtoallotherKDCsintherealm.ThereasonforemphasizingthispointisthatotherdeploymentstrategiesduplicaterealmsalongwithKDCs.Inparticular,aMicrosoftActiveDirectorydeploymentwilltendtodistributeDomainControllersinmuchthesamewaythatKDCsmightbedistributed.However,whileaDomainControllerisalsoaKDC,eachDomainisalsoaseparateKerberosrealmwithitsownsubsetofprincipalsthatareallowedtoauthenticatetotheDomain.

Cross-Realm Authentication

Whenmultiplerealmsareusedtosupportasharedpopulationofusersandservices,theobviousproblemthatemergesishowaclientinonerealmcanauthenticatetoaserviceinanotherrealm,andviceversa?KerberossolvesthisinadirectmannerbymakingtheTicketGrantingService(TGS)ofonerealm,aprincipalintheotherrealm.Then,whenaclientwantstoaccessaserviceinanotherrealm,itfirstasksaKDCinitsrealmforatickettotheTGSoftherealmwheretheserviceresides.Technically,clientsmakethisrequesttotheTicketGrantingServiceassociatedwiththeirKDC,butsince

http://tools.ietf.org/html/rfc2560http://tools.ietf.org/html/rfc2560http://tools.ietf.org/html/rfc2560http://tools.ietf.org/html/rfc4557http://tools.ietf.org/html/rfc4557http://tools.ietf.org/html/rfc4557http://tools.ietf.org/html/rfc4557http://tools.ietf.org/html/rfc2560


29/53

theTGSisessentiallyalwayspartoftheKDC,itiscommontouseKDCsynonymouslywithTGS,eventhoughthisisnotstrictlycorrectterminology.

SincetheclientsrealmhasaprincipalregisteredinitsKDCdatabasefortheremoterealmsKDC(TGS),itisabletoauthenticatetheclientandremoteKDCtoeachotherinthesamewayasforanyotherservicelocatedwithintheclientsrealm,andtheclient

getsback

from

its

KDC

aticket

to

the

remote

KDC

(TGS).

In

this

case,

the

ticket

is

actuallyaTicketGrantingTicket(TGT)fortheremoteKDCrealm.TheclientcanthenaccesstheremoteKDC,andusetheTGTithasreceivedtorequestaticketforanyserviceintheremoterealm.ThisisillustratedinFigure4below.

Figure 4: A client in one realm can authenticate to a service in another. This is done byrequesting n a ticket from the local KDC for the TGS of the destination realms KDC. Theclient is then able to request o a service ticket from the destination realm.Thesalientpointsregardingcrossrealmauthenticationare:

Beforeanythingelse,theclientmustinitiallyauthenticatetotheAuthenticationService(AS)foritslocalKDCandreceivebackaTGT.

Theclientmustknowtherealmoftheserviceitintendstoaccess,andbeabletorecognizewhenaserviceisinadifferentrealmfromitsown.Inlarge,distributedenvironments,thiscanbeamoredifficultproblemthanitfirstappears.

Theremote

KDCs

TGS

must

be

aregistered

principal

in

the

clients

realm.

The

principalnamefortheremoteKDCwillbe:krbtgt/REMOTEREALM@LOCALREALM

wherenormallytheremoteandlocalrealmnameswillbeuppercasedversionsofthecorrespondingDNSnames.ThisconventionmakesitpossibleforaclientthatknowsitsownrealmandtheremoterealmnametobeabletorequestaticketfromthecorrectTGSservice.



30/53

TheclientmustaskitsKDCforatickettotheKDC(TGS)intheremoterealm.FromthelocalKDCperspective,thisisthesameasanyotherrequestforaserviceticket,exceptthattheticketprovidedtotheclientisaTGTfortheremoterealm.

TheclientmustusethenewTGTitreceivestorequestthattheremoteKDCgrant

itaservice

ticket

for

the

actual

service

it

wants

to

access.

From

the

clients

perspective,thisisthesameasrequestingaserviceticketfromitslocalKDC.FromtheremoteKDCsperspective,theclientissimilartoanyotherclientthatwaslocallyauthenticatedandgivenaTGT.

Whentheclientreceivesaticketfortheserviceitwantstoaccessintheremoterealm,itpresentsthetickettotheactualserviceinthesamewayitwouldaservicethatwaslocatedinthesamerealm.

Aservicereceivingaticketfromaclientinaremoterealmcanprocesstheticketinthesamewayitwouldaticketreceivedfromanyclientinitsrealm.However,theserviceisabletoexaminethetickettodeterminethattheclientisfromanotherrealm,andtomakeaccesscontroldecisionsbasedontheclientsrealm.

Thisdirect

cross

realm

authentication

process

provides

an

elegant

solution

to

the

problemofauthenticatingacrossrealms.Inpractice,ifclientsandservicesfromtworealmsneedtobeabletointeractwitheachother,theneachrealmmustregistertheotherrealmsKDC(TGS)asaserviceprincipal.Thisimpliestwosharedsecretkeyswillbeneededbetweentherealmstoestablishabidirectionalcrossrealmrelationshipbetweentherealms.13Iftherearemorethantworealms,theneveryrealmwillneedtoestablishacrossrealmrelationshipwithallotherrealmsbyregisteringasaserviceineveryotherrealm,andalsoregisteringeveryotherrealmsKDCasaservicewithinitsrealm.Thisisafullmeshtopologywithbidirectionalsetuprequiredwhere,fornrealms,therewillneedtoben(n1)crossrealmregistrationsforthebidirectionalrelationships.Ifthereare

more

than

a

few

realms,

the

management

of

the

cross

realm

registrations

can

become

an

administrativechallenge.

Transitivity and Scaling Cross-Realm Relationships

Theapproximatensquaredgrowthincrossrealmrelationshipsfornrealmspresentsascalabilitychallenge.Severalapproacheshavebeendefinedformanagingscaleinmultirealmsituations,asoutlinedbelow:

ConfigurableAuthenticationPaths

HierarchicalrelationshipsbasedonmappingofrealmnamestoaDNSnamehierarchy

Automatedconfiguration

tools

UseofclientpublickeycertificatesandPKINIT

13Kerberosalsosupportsunidirectionalcrossrealmrelationships,whereclientscanauthenticateto

servicesinaremoterealm,butnotviceversa.Thismightmakesenseifarealmisdefinedwhereservicesarelocatedthatwillbeaccessedfromotherrealms,butnoclientsthatneedtoaccessservicesoutsidetherealm.



31/53

Configurable Authentication Paths

Thefirstapproachdependsontheideathatcrossrealmrelationshipscanbeextendedtobetransitiverelationships.Authenticationflowsalonganauthenticationpathfromthelocalrealm,throughoneormoreintermediaterealms,totheremoterealm.Inatypicalexample,somecentralrealmmightsetupbidirectionalrelationshipswithall

otherrealms.

The

client

would

obtain

aTGT

for

the

central

realm

from

the

local

KDC

andusethatTGTtoobtainaTGTfortheremoterealmfromthecentralrealmsKDC.ThentheclientcouldcontacttheremoteKDCandobtainaticketfortheservice.

Figure 5: Example of hierarchically organized cross-realm relationships

Thefirstapproachpermitsconfigurationofauthenticationpaths.Theseconfigurableauthenticationpaths(capaths)specifythesetofintermediaterealmsthatneedtobetraversedtogetfromalocalrealmtoaremoterealm.Thetermcapathisnotbasedontheconceptofapublickeycertificationauthorityortheconceptofacertificatevalidationpath;itisanabbreviationforconfigurableauthenticationpath.

Acomplexitywithcapathsisthateveryclientneedstoknowtheavailablepathways.14Thisconfigurationmatrixhastobebuiltandinstalledoneverysystemthatwilloperate

across

the

extended

network

of

realms.

Furthermore,

to

avoid

problems

with

inappropriatecapaths,serviceticketsareissuedwiththelistofintermediaterealmsincluded,andservicesorKDCsmustcheckthepathintheticketagainsttheirlocalconfigurationofacceptablepaths.Thisrequirementtodistributeandmaintaincapath

14EithertheserviceortheKDCalsoneedstobeabletovalidatethepathusedbytheclient.

Ultimatelytheserviceisresponsiblefordecidingwhetherthepathisacceptableandwhetherauthorizationshouldberestrictedbecauseofthepathused.HoweverKDCsprovideafacilityforcheckingtransitedpathpolicythatservicesshouldrelyon.



32/53

informationpresentsitsownscalabilitychallenges.However,ifclientsandKDCssupportrealmreferralsasdiscussedinSupportforKerberosReferralsbelow,thenonlyKDCsneedtobeconfiguredwithcapaths.Forsomeenvironments,suchasActiveDirectoryDomains,thisscaleswell.

Clientcansubsequentlyrequest

paTGT(3)fortheTGSinsome

otherchildrealm,e.g.,

EU.GII.COM

WithTGT(3)fromEU.GII.COM

realm,clientcangetaticketfor

ServiceB

ClientinrealmASIA.GII.COMis

abletorequestnaTGT(1)for

accessingservicesinitsrealm

Clientcanalsorequestoa

TGT(2)fromtheTGSassociated

withtheparentofitsrealm

Figure 6Example of hierarchical transitivity

Hierarchical Transitivity

Avariationontheinterrealmpathconceptisastrictlyhierarchicalpaththatleveragesconsistenthierarchicalrealmnamingconventionstoallowauthenticationpathstobeimplicitlyknown.Generally,thenaminghierarchyisbasedonDNSnames.Forexample,ifGalacticIndustriesInc.hastheDNSdomainnameofgii.com,andthereare

threeregions

in

Asia,

Europe,

and

the

United

States

with

the

corresponding

domain

namesofasia.gii.com,eu.gii.com,andus.gii.com,thenahierarchywithfourrealmscanbeestablishedwithAsia,EuropeandtheU.S.alltransitinganintermediaterealmnamedGII.COM(seeFigure5above).Sincethepathisimpliedbythenaming,theneedtoexplicitlyconfigurecapathsinclientsandservicescanbeavoided.Arbitraryhierarchiescanbeestablished,providedtheyfollowstricthierarchicalnamingconventions.However,notallorganizationalstructureswillfitastricthierarchy,orwillbeableto



33/53

useonehierarchicalnamingscheme.Figure6belowillustrateshowaclientinonerealmcanusehierarchicaltransitivitytoaccessservicesinotherrealms.

Configuration Tools

AnotherwaytomanagerelationshipsamongstKerberosrealmsistobuildan

administrative

tool

that

can

automate

establishing

cross

realm

KDC

registrations,

and

thatmightevenhandledeployingcapathmatricestoclientsandservices.Assumingthatadatabaseofrealmsanddesiredrelationshipsisbuiltandmaintainedwithinatool,thetoolcanuseconfigurationrulesandpoliciestoautomaticallygenerateallrequiredconfigurationsandsetups.Inpractice,directoryserviceshavebecomepreferredtoolsforcentrallymanaginginformationrequiredtodeployandoperatecomplexdistributedsystems.Consequently,practicalsolutionstoautomatingconfigurationofcrossrealmrelationshipshavebeenbuiltbasedondirectories.Forexample,MicrosoftusesActiveDirectorytomaintaincrossrealmrelationshipsthroughoutanarbitrarilycomplexorganizationalstructure.

PKINIT for Client Authentication

AdistinctlydifferentapproachleveragesthePKINITKerberosextensionsasdescribedaboveinthesectiononPKINITPublicKeyCryptographyforInitialAuthenticationinKerberos.InsteadofclientsusingtheirownKDCtogetticketsforservicesinaremoterealm,aclientwithapublickeycertificatecouldcontactaPKINITcapableKDCdirectlyintheremoterealm.SincetheclientdoesnothavetobepreviouslyregisteredintheremoterealmtogetaTGTfromtheKDC,thereisessentiallynocrossrealmpathtobefollowed.Inessence,trustrelationshipsareestablishedandmaintainedwithinthePublicKeyInfrastructure(PKI)usedtoissueandmanagecertificates.ThesetrustrelationshipsareusedtofacilitateKerberosauthentication.

Hybridapproachescanalsobepursued.Forexample,thehierarchicalapproachcould

beused

with

capaths,

but

where

the

capaths

are

only

used

by

asubset

of

clients

and

services.Thismightallowfordirectcrossrealmrelationshipsinadditiontohierarchicalrelationships.AnotherhybridstrategymightusePKINITwithhierarchicalrelationshipstosupportbothtraditionalclients,andclientsabletoauthenticateusingpublickeycertificates.

Cross Realm Relationships and Trust

RealmsmayhavesignificantlydifferentpoliciesforwhatprincipalsareregisteredintheKDCdatabase.SomerealmsmayallowanyonetoobtainaprincipalandmayhaveloosecontroloverthesecurityoftheKDC.OtherrealmshavestrictpoliciesonwhatproceduresarefollowedbeforeregisteringaprincipalandtightlycontrolKDCs.Consequently,itisreasonableforservicestohavesignificantlydifferentconfidenceintheauthenticationofprincipalsfromonerealmthanprincipalsfromanotherrealm.Clientsalsoneedtoevaluatetheirconfidenceintheauthenticationoftheservice.Ofcourse,confidenceinauthenticationshouldbelimitedtotheweakestrealmthatisinvolvedintheauthenticationprocess.Servicesandusersthendecidewhethertotrusttheauthenticationinthecontextoftheiraccesscontrolpoliciesbasedontheir



34/53

confidencethattheassertedprincipalactuallynamesthepartyinvolvedinthecommunication.

Becauseservicesmustmakethistrustdecision,MicrosoftreferstocrossrealmrelationshipsasDomaintrusts.Whilecrossrealmrelationshipsdoinvolvetrustdecisions,theleveloftrustthataservicechoosestoplaceinagivenrealmmaybevery

low.In

aMicrosoft

context,

it

rarely

makes

sense

to

establish

arelationship

with

a

relativelyuntrustedDomain.

Administratorsshouldthinkcarefullyaboutwhatleveloftrustintheauthenticationprocessisappropriatewhentheyplaceaprincipalfromaforeignrealmonanaccesscontrollistorotherwisegrantthatprincipalaccess.Ifanorganizationhasrelativelyliberalpoliciesaboutwhenacrossrealmrelationship

Documents

Role Kerberos