role kerberos
TRANSCRIPT
-
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 -
7/28/2019 Role Kerberos
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).
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 2 of 53
-
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 3 of 53
-
7/28/2019 Role Kerberos
4/53
-
7/28/2019 Role Kerberos
5/53
-
7/28/2019 Role Kerberos
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).
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 6 of 53
-
7/28/2019 Role Kerberos
7/53
-
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 8 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 9 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 10 of 53
-
7/28/2019 Role Kerberos
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).
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 11 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 12 of 53
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 -
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 13 of 53
-
7/28/2019 Role Kerberos
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].
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 14 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 15 of 53
-
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 16 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 17 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 18 of 53
-
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 19 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 20 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 21 of 53
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 -
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 22 of 53
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 -
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 23 of 53
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 -
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 24 of 53
http://tools.ietf.org/html/rfc5056http://tools.ietf.org/html/rfc5056http://tools.ietf.org/html/rfc5056http://tools.ietf.org/html/rfc5056 -
7/28/2019 Role Kerberos
25/53
-
7/28/2019 Role Kerberos
26/53
-
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 27 of 53
-
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 28 of 53
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 -
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 29 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 30 of 53
-
7/28/2019 Role Kerberos
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.
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 31 of 53
-
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 32 of 53
-
7/28/2019 Role Kerberos
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
Copyright Notice, 2008 by the MIT Kerberos Consortium. Page 33 of 53
-
7/28/2019 Role Kerberos
34/53
confidencethattheassertedprincipalactuallynamesthepartyinvolvedinthecommunication.
Becauseservicesmustmakethistrustdecision,MicrosoftreferstocrossrealmrelationshipsasDomaintrusts.Whilecrossrealmrelationshipsdoinvolvetrustdecisions,theleveloftrustthataservicechoosestoplaceinagivenrealmmaybevery
low.In
aMicrosoft
context,
it
rarely
makes
sense
to
establish
arelationship
with
a
relativelyuntrustedDomain.
Administratorsshouldthinkcarefullyaboutwhatleveloftrustintheauthenticationprocessisappropriatewhentheyplaceaprincipalfromaforeignrealmonanaccesscontrollistorotherwisegrantthatprincipalaccess.Ifanorganizationhasrelativelyliberalpoliciesaboutwhenacrossrealmrelationship