rolekerberos

8/8/2019 rolekerberos

1/53

The Role of Kerberos inModern Information Systems

IntroductionAchievingadequatesecurityfortodaysinformationsystemshasproventobeaveryhardproblem.Inmanycases,theproblemsofsecurityhavebeenmadeevenharderbyahistoryoftreatingsecurityasanafterthought.Toooften,insteadoftakinga

comprehensive,

architectural

approach

to

security,

our

field

has

deployed

security

measuresandtechnologiesasindividualboltonsolutionstoverynarrowproblems.Overtime,theresultingmosaicofsecurityrelatedtechnologiesbecomesbrittle,difficulttoextend,timeconsumingtomanage,andnotnecessarilyeffective.

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

abouthow

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)

Kerberosisasecuritytechnologythatismatureandthatisincreasinglydeliveredasan

integralcomponent

of

modern

systems.

As

such,

it

can

be

an

important

element

of

an

overallsecurityframework.However,becausedifferentdevelopercommunitieshaveapproachedKerberosintegrationindifferentways,newchallengesemergewhenusingKerberos,especiallyinthekindofdynamic,openended,mixedplatformenterprisecomputingenvironmentthatistypicaltoday.

Thisdocumentframesthosechallengesinthelargercontextofinformationsecurity.Itbeginswithafocusonaccesscontrolasanoverarchinggoal.Itthendescribesthevarious

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

securityservicesthatcontributetoeffectiveaccesscontrol,anddiscussestheissuesthatariseinprovidingthoseservices.Next,itdescribestheroleofKerberosinprovidingthoseservices,focusingonthewaysinwhichKerberosintegrateswiththeothertechnologiesunderavarietyofscenarios.Itpaysparticularattentiontodirectoryservices,which,whilenotpartofKerberos,areoftenintegratedwithit.Finally,itintroduces

somedetails

about

the

way

Kerberos

is

used

within

specific

operating

system

platforms

suchasMicrosoftActiveDirectory,OpenDirectory,andothers.

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

Access Control Policies

Anaccess

control

policy

incorporates

the

following

factors,

either

explicitly

or

implicitly:

Authorities and Regimes

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

administrativedomain

are

also

encountered.

Since

realm

is

also

used

in

a

technical

sense

byKerberos,anddomainbyWindowsActiveDirectory,thetermregimeislessoverloaded.

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

Resources

Asecurity

policy

must

define

the

resources

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 Classification

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

Access ContextAnaccesscontrolpolicyoftenmakesreferencetothecircumstancesunderwhichaccessisrequestedorthemeansbywhichaccessisprovided.Forexample,duringnormalbusinesshoursfromacompanyownedworkstationinasecureofficemightbeassociatedwithadifferentaccesspolicythanviaanunsecuredInternetconnection.

Allowed 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 PolicyAsanexampleofanaccesscontrolpolicytakenfromafamiliarcontext,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

Authorized parties File owner. Members of group admin

Not members of group guests or other

Authenticity confidence: User has presented password (single-factor)



4/53

Figure 1An example of an access policy; this one governs files on a PC

Thissimpleexamplehelpsillustratesomeimportantpoints.First,establishingwhohasauthorityovertheresourceisvitaltoanyinterpretationofthepolicy.Inanysufficientlycomplexenvironment,therearelikelytobemanydifferentauthorities,eachwithcontroloveradistinctsetofresources.Iftheownerofthecomputerisanemployer,the

employeewho

uses

the

computer

and

its

file

storage

will

only

have

whatever

authority

isdelegatedtothembytheiremployer.Itisalsonecessarytobeclearaboutthespecificresourcecoveredbythepolicyi.e.,afileisaresourcedistinctfromthediskdriveithappenstoresideon,andthefilemaywellexistinmultiplelocations,butstillbegovernedbythesameaccesspolicies.1Whilethisexampleclassifiesthefileresourceasnonsensitiveperhapsbecauseitisjustafilecontaininguserpreferencesitwouldclearlymatterifthefilewasinsteadasensitivedocumentforwhichtheremightbesevereconsequencesifdisclosedtounauthorizedparties.Themeansofaccessisanoftenoverlookedfactor,butitclearlymatterswhetherthefileisbeingaccessedlocally,orisbeingsharedacrossanetwork,orretrievedfromabackuparchive.Inpractice,alloweduseisoftenspecifiedaccordingtothedesignationofauthorizedpartiesinthisexample,

thefile

owner

and

group

have

different

usage

constraints

while

everyone

else

should

havenoaccess.Finally,thedegreeofconfidenceintheauthenticityofpartiesisvitaltoanyassessmentofcompliancewithanaccesspolicyorcharacterizationofrisk.Thelevelofconfidencerequiredinanauthenticationprocessgenerallyrelatesdirectlytoboththemeansofaccessandtheclassificationoftheresource.Forexample,itmightbereasonabletorequireahigherlevelofauthenticationconfidencefromremotepartiesthanfromalocallyloggedinuser.Similarly,greaterauthenticationconfidencemightberequirediftheresourceisclassifiedastopsecretasopposedtorestricted.Orabankmightbewillingtoprocesslowvaluetransactionsbasedontelephoneauthorization,butrequireawitnessed,guaranteedsignatureforhighvaluetransactions.

Access

control

policies

can

be

quite

complex

and

often

specify

many

conditions

that

mustbemetbeforeaccessiseithergrantedordenied.Furthermore,therecanbesignificantrisksfrombothfalsepositivesandfalsenegativesinanysystemthatprovidescontrolledaccesstoresources.Forexample,anaccesscontrolsystemthatfalselydeniesafinancialtraderaccesstotheirtradeexecutionsystemcouldhavesubstantialadversecostimplications.Inreality,accesscontrolsystemscanbeattackedinordertogainunauthorizedaccess,orasameansofdenyingaccesstoauthorizedparties(e.g.,adenialofserviceattack).

1Whilethisexampleillustratesaccesscontroltoafileobject,thefileisjustacontainerforinformation,anditmaywellbethatthegoverningpoliciesapplytothedatacontainedinthefile,andnotthefileobjectperse.



5/53

Figure 2A simple conceptual model of access control

Access Control MechanismsEffectiveaccesscontrolsdependonotheressentialsecurityservicesandassociatedmanagementfacilities.Realworldsolutionsaregenerallybuiltontopofsystemplatforms

that

provide

these

services

and

allow

them

to

be

combined

in

abuilding

blockfashion,thoughusuallyinaniterativemanner.Thisallowsaccesscontrolsolutionstobetailoredtocomplywithaccesspoliciesacrossabroadrangeofapplicationsandusagescenarios.Thesecurityservicesessentialtoaccesscontrolinclude:

Integrity:informationonwhichaccesscontroldecisionsarebasedmustbeofknownintegrity,anditmustbepossibletodetectattemptstotamperwiththisinformation.

Confidentiality:informationintendedforaspecificrecipientmustbeprotectedfromeavesdropping.Inparticular,sensitiveinformationusedinaccesscontrol

(e.g.,passwords,

session

keys)

must

be

protected

from

disclosure.

Authentication:beforemakinganaccesscontroldecision,asystemmustdeterminetoanacceptablelevelofconfidencethatthepartyrequestingaccessisauthentic(e.g.,isthelegitimateuserofthenameunderwhichaccessisrequested.)

Authorization:onceapartyhasbeenauthenticated,itisnecessarytodeterminewhetherornotthepartyisauthorizedtogaintherequestedaccess.



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,twostandardsbasedtechnologieshaveemergedaspreferredbuildingblock

services:Kerberos

security

services

and

LDAP

based

directories.

While

Kerberos

is

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



7/53

WhileKerberosisoftenconsideredanauthenticationservice,italsoprovidesfacilitiesformanagingkeys,assuringdataintegrity,authorizinguseofservices,establishingsecuresessions,andprotectingconfidentialityofdataexchanges.Asanauthenticationservice,itprovidesadditionalvaluebysupportingmutualauthenticationofpartiesthatenterintoasecurecommunicationssession.

Issues for Security ServicesTherolesthatKerberosanddirectoriesplayinprovidingcoresecurityserviceswillbeevaluatedingreaterdepthbelow,butbeforedoingso,thereareotherissuesassociatedwiththecoreservicesthatshouldbereviewed:

Mutuality:itisnotenoughthattheserviceauthenticatetheuserpriortograntingaccess;itisalsoimportantthattheuserauthenticatetheservice,soastoavoidprovidingsensitivedatatoamaliciousimpostor.Astheplagueofphishingattacksinrecentyearshasdemonstrated,onewayauthenticationexposeslegitimatepartiestoavarietyofattacks,evenwhenoneofthepartiesisnotaparticipantinthefraudulenttransactione.g.,abanksreputationcanbe

damagedwhen

impostors

purloin

information

from

the

banks

customers.

It

is

nowwidelyrecognizedthatmutualauthenticationisessentialtopreventingsuchattacks.Moregenerally,mutualityextendstoaccesscontrol,thoughusuallyinanasymmetricmanner.Inotherwords,boththeserviceandclientneedtoenforceaccesscontrolsontheother,butfordifferentreasonsandtoaddressdifferentrisks.Forexample,awebsitethatcontrolsaccesssothatonlyauthorizeduserscanaccessinformationorservices,isatthesametimeaccessingtheusersbrowsers,andmayevenbeexecutingcodeonuserssystemsintheformofJavaScriptsorActiveXcontrols.2Theuseofbrowsersidesecurityzonesandscriptblockingpluginstoconstrainwhichsitesareallowedtoexecutescriptsillustratesonewaythataccesscontrolshavebeenintroducedontheclientsidetominimizecertainthreatstousersi.e.,somebrowserusersarenowmaintainingaccess

control

lists

(ACLs)

for

sites

they

visit.

Principals:Inanyapplicationcontext,therearemultipleprincipalsinvolvedincommunicationsandperformingvariousservices.Alloftheseprincipalsneedtobenamed,andappropriatelyauthenticated.Forexample,ahumanuserisanimportantprincipalinmanyapplications,buttheuserisnotthesameprincipalastheirworkstation,noristheuserequivalenttotheclientsoftwarerunningontheirworkstation.Similarly,theclientsoftwareandworkstationaredistinctlydifferentprincipals,eventhoughtheseprincipalsareoftentreatedasthesamething.Inperformingaccesscontrol,itoftenmatterswhichoftheseprincipalshasbeenauthenticatede.g.,isittheuserthatwasauthenticated,theirworkstation,ortheirclientsoftware?Furthermore,itisimportanttoclarifywhichprincipals

haveauthority.

Delegation:Incomplexdistributedsystems,therearemanysituationswhereitmaybenecessaryforauthorizationstobedelegatedtosomesystemoragenttoactonbehalfofaprimaryauthority.Forexample,awebfrontendapplication

2WhilethewisdomofhavingserversexposedtothepublicInternetalsodownloadingcodeontoausersmachineforexecutionwithouttheknowledgeoftheuserisdubiousatbest,thepracticeiswidespread,andillustrateshowotherprioritiescanintroducenewsecuritychallenges.



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.

Each

time

the

system

grants

access

to

a

service,

it

conducts

an

authentication

step,

but

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

WhatKerberosofferstousersistheabilitytoprovetheirauthenticityonceinaperiod,andtocachethefactthatauthenticationwassuccessfulsothatsubsequentauthenticationsconductedbyclientsoftwareonbehalfoftheuserneednotinvolvetheuser.However,accesscontrolpoliciesmayimposeotherrequirementsthatcouldcauseuserstohavetoreauthenticate,orprovideadditionalproofsofauthenticity.For

example,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

provide

acceptable

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

indirect

manner.

A

name

such

as

John

or

the

billing

department

of

Some

Corp.

isone

type

of

an

identifier.

Other

identifiers

can

be

numeric

(employee

237)

or

attributebased(theusercurrentlyloggedinatworkstationF3B288).Relevanttypesofidentifiersincludeuserids,Kerberosprincipals,andX.500DistinguishedNames.

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

namesrequires

the

existence

of

some

registration

process

to

guarantee

that

naming

collisionsdonotoccur.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,additionalconventionsareemployedtonameservicesinaconsistentmannerthroughoutanorganizationoradministrative

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.Examplesofcontextualcluesincludethingslike

IPor

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.Unlikeotherauthenticationschemesinvolvingpresharedsecrets,Kerberosonlyrequiresprincipals

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



16/53

todisclosetheirsecretsonceatthetimeofinitialregistration.Subsequently,authenticationcantakeplacewithoutexchangingthepresharedsecret.

Inthecaseofuserpasswords,someKerberosimplementationsonlyknowakeyderivedfromthepassword,anddonotactuallyknowtheuserspassword.Furthermore,passwordsarenotexchangedbetweenpartiesduringauthentication.Thissubstantially

reducesrisks

that

the

authentication

secrets

will

be

disclosed

during

normal

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

ModernKerberossystemsarealsoabletoutilizeotherauthenticationtestsinadditionto,orasalternativesto,passwordsandsharedsecrets.Oneoptionistousepublickey

cryptographic

techniques

in

conjunction

with

digital

certificates

to

avoid

any

necessity

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

Mutual Authentication

Oneof

the

greatest

benefits

to

using

Kerberos

as

an

authentication

service

is

that

it

providesthemeansforbothpartiesinanexchangetoauthenticateeachotheri.e.,mutualauthentication.MutualauthenticationisareadilyavailablefacilitytoanyapplicationthatusesKerberos.Experienceindicatesthatmutualauthenticationshouldalwaysbeused,andisanimportant(necessary)bestpractice.

Ithaslongbeenrecognizedthatmutualauthenticationisnecessaryforanysecuredialog.However,theasymmetricnatureofcommunicationsbetweencomputersandpersonshasbeenfrequentlyusedasanexcuseforallowingonewayauthentication. Ifthereisonelessonlearnedfromattemptstosecuresystemsitisthatanyvulnerabilityallowedtoexistwillbeexploited.Thishascertainlybeenshowntobethecaseforthe

vulnerabilities

associated

with

one

way

authentication,

and

the

surge

of

phishing

attacksinrecentyearsisjustoneillustrationofthisreality.

TheKerberosprotocolsresultinticketsbeingissuedtothepartyrequestingaccesstoaservicethatincludebothauthenticationinformationtheservicecanusetoauthenticatetherequestingparty,aswellasasessionkeythatcanbeusedinrespondingtotherequestingparty.Iftherequestingpartyreceivesbackfromtheservicearesponsebasedonthesessionkey,thentheyhaveconfirmationoftheauthenticityoftheservice.ThisisduetothewaythatKerberosticketsareformedbytheKDCwherethesessionkeyand



17/53

userauthenticationinformationareencryptedwiththeserviceproviderskey.Therefore,whentheservicereturnsaresponsetotherequestingpartythatusesthesessionkey,therequestingpartyknowsthatonlyaservicethatpossessesthesecretkeysharedwiththeKDCcouldhavecorrectlyrespondedhence,mutualauthentication.Afurtherbenefitisthat,bycompletingthisexchange,bothpartiespossessanewshared

sessionkey

known

only

to

them

that

can

be

used

to

authenticate

every

message

passed

betweenthem,andeventoestablishanencryptedsession.8

Source AuthenticationSofar,onlyonetypeofauthenticationhasbeendiscussedtheauthenticationofpeerentities.Anothertypeisknownasdataoriginorsourceauthentication,andinvolvesclaimsofthesort:thisdataisprovidedbyaspecificnamedparty.Kerberosalsoprovidessupportforthissecondtypeofauthentication.

OnemeansofferedbyKerberosforauthenticatingthesourceofinformationisprovidedthroughexchangeofasecretsessionkeybetweenaclientandservice.Ifthesessionkey

is

used

to

encrypt

information

exchanged

between

the

parties,

or

in

producing

keyed

hashesoftheinformation,theneitherpartyknowsthatonlyapartyinpossessionofthesessionkeycouldhaveprovidedtheinformation.Inessence,everymessagecanbesourceauthenticatedthroughuseofthesessionkey.Again,bestpracticescallforbothpartiestoutilizethesessionkeytoauthenticatesubsequentexchangesofinformation.

Ifservicesaredeliveredinadistributedmanner,asingleclientmaybecommunicatingwithmultipleserviceprovidersatthesametime.Kerberossupportsmultiplemechanismsforclientstoestablishdistinctsessionkeyswitheachserviceprovider,whichallowsthesourceororiginofdatatobeauthenticatedineachcase.

SourceauthenticationisalsoprovidedforticketresponsesissuedbyaKerberosKDC,

since

the

requesting

party

(client)

can

determine

that

the

response

was

encrypted

with

a

keyknownonlybytheKDCandclient,andsimilarly,theserviceprovidercandeterminethattheticketwasencryptedwithitssecretkeythatwaspreviouslysharedwiththeKDC.ThisformofsourceauthenticationisaninherentfeatureoftheKerberosprotocols.ItalsomeansthatotherinformationintheticketencryptedwiththepresharedsecretisknowntohaveoriginatedfromtheKDC.Thisallowsticketstobeusedasauthorizations,andtheycanbeusedtocarryadditionalauthorizationinformation(seeKerberossupportforAuthorizationbelow)

Data Integrity and ConfidentialityKerberosalsoprovidesthemeansfordeterminingthatdatacontainedinticketshasnot

beentampered

with

or

altered

since

the

ticket

was

generatedi.e.,

data

integrity

is

assured.Thisisessentialtopreventthirdpartiesfrommanipulatingticketsasameansofunderminingauthenticationprocedures,orchangingauthorizationinformation.Inparticular,aclientrequestingatickettoaccessaservicecannotmanipulatetheportion

8TheoriginalsessionkeyisalsoknowntotheKDC.However,applicationstypicallyestablishanewsessionkeythattheKDCcouldonlylearnbyobservingtheexchangebetweenpartieswhenmutualauthenticationisused.



18/53

oftheticketintendedfortheserviceprovidertoauthenticatetheclient,sincethisportionoftheticketisencryptedwiththesecretkeyknownonlytotheserviceproviderandtheKDC.

Assumingthattheclientandservicecompletetheexchangeofasessionkey,thenthissessionkeycanbeusedtoprovidedataintegrityforsubsequentexchangesbetweenthe

parties.Data

integrity

can

be

provided

by

computing

ahash

of

the

data

that

is

keyed

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

Replay Prevention in KerberosSinceKerberosticketsareexchangedoveruntrustednetworks,attackersmustbepreventedfromreplayingticketstointerposethemselvesasapparentlyauthenticated

parties.

Originally,

Kerberos

tickets

included

the

IP

addresses

of

the

requesting

client

andtheservice,whichprovidessomelimitedprotectionagainstreplayattacks.However,modernKerberosimplementationsemploytimestampstolimitthevalidityintervalofticketstoonlyafewminutes,whichhelpspreventreplayofticketsexceptduringthisnarrowtimewindow.ThisassumesthatallparticipantsinKerberosprotocolexchangeshavesomemeansofmaintainingtimesynchronizationwithinatleastafewminutes.9Inaddition,servicesaresupposedtomaintainacacheofticketsseenwithinthewindowoftimethatticketscanbevalid.Thisallowsaservicetodetectanyreplayattemptswithinthistimewindow.Useofclientspecificsessionkeysisanothereffectivetechniqueforpreventingreplays.BestpracticesrequireallservicesthatrelyonKerberostoimplementcountermeasuresagainstreplayattacks.

Non-Repudiation Support in KerberosTheexchangeofsessionkeysandtimestampsinKerberosticketsthataregeneratedbythethirdpartyKDCalsoprovidesbasicnonrepudiationprotections.Repudiationisdefinedasonepartydenyingparticipationinallorpartofacommunicationsdialogwithanotherparty.10Inessence,theKDCservesasathirdpartywitnesstotheestablishmentofthesessionbetweenclientandservice.However,thisonlyprotectsservicesfromattemptsbyclientstorepudiatethattheyrequestedaccesstotheservice.ClientscannotrelyontheKDCtovouchforwhetherornotaserviceeverrespondedtoaclientrequest.Furthermore,thislimitedformofnonrepudiationisnotequivalenttotheprotectionsofferedbyelectronicnotaryservicesthataredesignedtodealwith

complexrepudiation

scenarios.

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

Repudiationmightconsistofclaimsbyclientssuchas,Ididnotattempttoaccessthatservice,orIdidnotattempttoaccessthatserviceatthattime.



19/53

Thechiefbenefitofthislimitedformofnonrepudiationprotectionisthatitcanenhancethecredibilityofsystemlogsthatindicatewhichclientsaccessedwhichservicesandapproximatelywhentheaccessattemptsweremade.Thisimprovestheintegrityofauditproceduresandthestrengthofauditcontrols.However,forthistobeeffectiveprotection,boththeKDCandserviceneedtokeeplogrecordsofeveryrequest

fromaclient,

what

service

the

client

requested

access

to,

when

the

request

was

made,

andtheactualticketissued.SincetheticketisencryptedwiththekeysharedbytheKDCandservice,neithercouldchangetheticketwithoutcausingadiscrepancyinthelogrecordskeptbyeach.TheKDCwillalsoneedtokeeplogrecordsofrequestsfromclientsforticketsasencryptedintheTGTsessionkey,aswellaslogrecordsforinitialauthenticationsandTGTticketsissued.ItisstandardpracticeforKDCstologthisinformation.

Ifaclientlatertriestorepudiatethattheyrequestedaccesstoaspecificservice,thentheKDChasproofthattheclientmadearequestforthetickettothatservice.Iftheservicegetstheticket,itcouldhaveonlycomefromtheclientbecausetheclientsauthenticatorwillhavebeenencryptedinthesessionkeyestablishedbytheKDCfortheclientandservice

to

use.

If

the

service

is

able

to

demonstrate

that

its

log

record

of

the

ticket

matcheswhattheKDCloggedfortheticket,thentheservicedidnotgeneratetheticketonitsown.Furthermore,theclientcouldonlyhavemadetherequestforaccesstotheserviceafterthetimeitrequestedtheticketfromtheKDC,whichpartiallypreventsrepudiationclaimsastowhentheclientmadetherequest.

Kerberos support for AuthorizationAlthoughKerberosisprimarilyanauthenticationservice,itdoesprovidebasicauthorizationservicesforprincipalsregisteredwithintheKDCdatabase.Unlesssomeauthority(usuallyahumanbeing)hasregisteredaprincipalbyenteringtheirprincipal

nameinto

the

KDC

database

through

some

administrative

procedure,

the

principal

will

notbeknowntotheKDC,andwillnotbeabletousetheservicesoftheKDCtoauthenticatetootherprincipals.Consequently,onlyauthorizedprincipalsareincludedintheKDCdatabase,andpresumably,authoritieswithadministrativeaccesscanalsoremoveprincipalsfromthedatabasetodeauthorizethem.

Furthermore,KerberossupportsrudimentaryauthorizationserviceswhenissuingTicketGrantingTickets(TGTs)andforsessionestablishmentbetweenclientsandservicesservicesthatareprovidedonlytoauthorizedprincipals.Kerberosalsoprovidesfacilitiesforsecurelypassingauthorizationinformationtoservices.Theseauthorizationservicesaredescribedinthefollowingsubsections.

TGT AuthorizationWhenclientsinitiallyauthenticatewiththeKerberosAuthenticationService(normally,asubsetoftheKDCservices),theyreceivebackTGTsthatareusedasauthorizationstoconductsubsequentrequestsforticketstoaccessotherservices.ThisisthewaythatKerberossupportsSingleSignOn(SSO)sothataclientneedonlyauthenticateonce,andcanthensubsequentlyaccessotherserviceswithouthavingtopresenttheirpasswordorotherauthenticationinformationeachtime.



20/53

TheTGTreturnedbytheKDCtoaclientrequestinginitialauthenticationestablishesasession(seeSessionAuthorizationbelow)betweentheclientandtheTicketGrantingService(TGS)alsotypicallydeployedasasubsetoftheKDC.ThissessionisbasedonanewsecretsessionkeysharedonlybetweentheclientandtheTGS(a.k.a.,theKDC).TheTGTisatimelimitedauthorizationwherenormallythetimelimitisatleastseveral

hours,but

rarely

more

than

aday.

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

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

Session Authorization

Kerberosalsoprovidesbasicauthorizationservicesforestablishingcommunications

sessionsbetween

principals.

In

fact,

Kerberos

tickets

are

secured

authorizations

that

aserviceproviderusestoauthorizeestablishmentofacommunicationssessionwitha

client.TheauthorizingpartyistheKerberosKDCthatissuesticketstoclients.However,thetrueauthorityisthepartyresponsibleforenteringthenamedprincipalintheKerberosKDCdatabaseofauthorizedusersandservicesi.e.,theregistrationauthority.IfapartydoesnothaveaprincipalnameintheKDCdatabase,thatpartyisnotauthorizedforanyservicethatdependsonKerberosforauthentication.

AcommonstatementaboutKerberosisthatitonlyauthenticatesprincipalstoeachother,andthatauthorizationisadecisionmadebytheprincipalsbasedonsomeapplicationcontext.ThisisbecauseKerberosrealmsmayhaveveryliberalpoliciesforwhatprincipalsareregistered.Forexample,arealmmayregisteranyunusedusernamebased

on

arequest

at

awebpage.

Work

is

on

going

to

allow

anonymous

Kerberos

authenticationwithoutregistrationinanyKDCdatabase.Similarly,somerealmshaveveryliberalpoliciesaboutwhatservicesareregistered.Asaresult,application

11TheclientalwaysauthenticatestheKDCinthefirstexchange.TheKDCcanuseafacilitycalled

preauthenticationtoauthenticatetheclientbeforeissuingtheticket,ortheKDCcanwaituntiltheclientfirstusesthetickettoknowthatitwasabletosuccessfullydecrypttheticket.Currentbestpracticeistousepreauthentication.



21/53

designerscannotmakeanyassumptionsaboutauthorizationsimpliedbyregistrationinaparticularrealm;potentiallyanyentitythatrequestedsuchregistrationmaybeabletoobtainitinsomerealms.

Ontheotherhand,settingpoliciesforwhatprincipalsareregisteredinarealmisapowerfulaccesscontroltoolforITadministrators.Whenaclientpresentsatickettoa

service,the

service

is

presented

with

information

that

not

only

authenticates

the

named

principal,italsoindicatesthattheclientprincipalisregisteredintheKDCdatabase.Theservicereceivingaticketfromarequestingclientmustdecidewhetherornottoestablishcommunicationswiththeclientbasedontheticketcontents,andanyotherinformationtheservicemayhaveathand(e.g.,alistofprincipalsauthorizedtousetheservice).However,thisdecisionwillbebasedinpartontheticketthatisissuedbytheKDC,whichis,infact,anauthorizationissuedbytheKDCstatingthattheprincipalisanauthorizedpartywithintheKDCdatabase.

Section1.4ofRFC4120advisesthatApplicationsshouldnotacceptthemereissuanceofaserviceticketbytheKerberosserver(evenbyamodifiedKerberosserver)asgrantingauthority

touse

the

service.

This

is

sound

advice,

since

authorizationto

establish

asession

is

not

the

samethingasauthorizationtousetheservice.Onlywithinaspecificapplicationandpolicycontextcanrationaldecisionsbemaderegardingappropriateauthorizations.Atthesametime,effectiveaccesscontroloftendependsonmultiplelevelsofauthorization,andsessionauthorizationisausefulfirststepinanaccesscontrolstrategy.Insomespecificcases,suchasremoteaccesstoanetwork,itmayevenbesufficient.ApplicationdesignersshouldprovidetoolsthatmakeiteasyforITadministratorstotakeadvantageofthislevelofauthorization;forexample,insomecasesitmaybedesirabletograntaccesstoallprincipalsinarealm.

Authorization Information passed by Kerberos

Kerberoscan

also

play

asupporting

role

in

access

control

decisions

by

passing

authorizationinformationsecurelytoaservicewithinaticketusedtoauthenticateaclientrequestingaccesstotheservice.TheKerberosprotocolspecificationsprovidefortwoclassesofauthorizationinformation.ClientsorKDCscanaddrestrictionstoticketsrestrictingthecontextinwhichtheticketisvalidortheaccessthatshouldbegrantedtoapartyauthenticatingwiththisticket.Inaddition,KDCscanaddauthorizationinformationgrantingadditionalprivilegesordescribingauthorizationattributesoftheentitythattheclientprincipalnames.Facilitiesareprovidedsothatclientscannotcreatethesecondtypeofauthorizationinformation.WhiletheKerberosprotocolspecificationsdonotindicatehowthisauthorizationinformationistobeused,orevenallthedetailsofhowtheinformationisstructured,thisoptioncanbeusedtoextendthe

utilityof

Kerberos

services

in

managing

access

control.

Since

the

ticket

is

encrypted

withthepresharedsecretkeyknownonlytotheserviceandtheKDC,theserviceisabletotrusttheinformationinthisticket,bothtoauthenticatetheclientandtheauthorizationgrantedtotheclient.

Forexample,whenaclientrequestsaserviceticket,iftheKDCincludesalistofgroupsthisclientprincipalbelongstointheauthorizationdatafieldoftheticket,thentheservicewillbeabledeterminewhatresourcestheclientisallowedtoaccessbasedon

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

groupmemberships.ThisveryschemeiswidelydeployedbyMicrosoftaspartofitsWindowsServerplatforms.Otherexamplesofauthorizationdatathatcouldbepassedwithinaticketincludetimeofdayrestrictions,subscriptioninformation,transactionlimits,orusagequotas.

MicrosoftsuseofKerberosasameanstopassgroupmembershipsandotheraccount

informationin

service

tickets

is

the

most

widely

deployed

example

of

extending

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

Oneconcernwithtrustingauthorizationdatainticketsisthataservicecouldgenerateticketstoitself.ThisisbecausethekeyssharedbetweenservicesandKDCsaresymmetricencryptionkeys,whichalloweithersidetoencryptthedata.Thisallowsthe

service

to

trust

a

ticket

received

from

a

KDC,

since

only

the

KDC

should

know

the

secretkey.However,aservicecouldgenerateitsownticketusingitskey.WhilethisdoesnotundermineKerberosauthentication,theabilitytogeneratenewticketscouldbeusedtoelevateprivilegesifauthorizationinformationintheticketistrustedbyapartyotherthantheserviceforwhomtheticketisissued.Toavoidthispotentialexposure,softwaresuchasthelocaloperatingsystemthatwishestouseauthorizationinformationfromaticketissuedtoanotherserviceshouldconfirmauthorizationinformationwithatrustedsourcebeforemakingaccesscontroldecisionsbasedonthisinformation.Forexample,MicrosoftaddressesthisproblembyhavingtheLocalSecurityAuthorityconfirmPACsreceivedbyunprivilegedserviceswiththeDomainControllerviaanindependentsecurechannelestablishedusingtheirNetlogonfacility.

Integrating Kerberos into ApplicationsTheprocessofintegratingKerberosintoanapplicationiscolloquiallyreferredtoasKerberizinganapplication.Thecompaniondocument,BestPracticesforIntegratingKerberosintoYourApplication(pdf),providesacomprehensiveguidetoapplicationintegrationissues.However,abriefreviewofintegrationoptionsisprovidedheretohelpclarifytherolethatKerberosplaysinothersystemapplications,especiallydirectoryservices,whichwillbediscussedingreaterdepthinTheRoleofDirectoryServicessectionbelow.

The GSS-API and Kerberos

TheGenericSecurityServicesApplicationProgramInterface,

or

GSSAPI,

was

developed

as

awaytodecoupleapplicationsfromunderlyingsecurityservices,especiallyauthenticationmethods.KerberosandGSSAPIarecloselyrelated,eventhoughtheGSSAPI(ref.RFC2743)isdesignedtoallowanyauthenticationtechnologytobeusedbyanapplication.ItjusthappensthatKerberosisthedominantauthenticationtechnologyusedwithGSSAPI.Furthermore,theGSSAPIhasbecomethestandardizedAPIforKerberos(ref.RFC4121),sincetheKerberosprotocolspecificationsdonot

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/rfc4121http://tools.ietf.org/html/rfc4121http://tools.ietf.org/html/rfc4121http://tools.ietf.org/html/rfc4121http://tools.ietf.org/html/rfc2743http://www.kerberos.org/software/appskerberos.pdfhttp://www.kerberos.org/software/appskerberos.pdf


23/53

defineanyAPIs,andvariousKerberosimplementationsutilizeincompatibleprograminterfaces.

TheGSSAPI,whenusedwithKerberos,actuallydefineswirelevelprotocolsthatareexchangedbetweenpartiesusingGSSAPIsothatdataconfidentialityandintegrityassurancecanbeprovidedinadditiontoauthentication.Inthissense,itismorethan

justan

API.

An

important

implication

is

that

applications

could

be

built

that

are

compatiblewiththewirelevelGSSAPIKerberosprotocols,butthatdonotactuallyusetheapplicationprogramminginterfacedefinedbytheGSSAPIe.g.,MicrosoftsSecuritySupportProviderInterface,orSSPI.12EventhoughtheprogramminginterfacesprovidedbytheGSSAPIandMicrosoftsSSPIarequitedifferent,itisstillrelativelystraightforwardtobuildapplicationsusingoneAPIthatwillinteroperatewithapplicationsusingtheotherAPI.However,duetofundamentaldifferencesinapproach,itisalsopossibletobuildGSSAPIapplicationsthatcannotbemadetointeroperatewithSSPIapplications,andviceversa.

TheSimpleandProtectedNegotiation,orSPNEGO,mechanism(ref.RFC4178)canbe

used

to

extend

GSS

API

and

is

also

used

with

Microsofts

SSPI.

SPNEGO

is

actually

a

pseudomechanism(orpseudoservice)thatallowspartiestonegotiatewhatsecurityservicestheycanbothsupport.Inotherwords,SPNEGOusesthesecurityservicesofanunderlyingmechanism,suchasKerberos,toprovidethesecurityserviceofprotectednegotiationtoanapplication.Theapplicationselectsthedesiredunderlyingsecurityservicewhileminimizingthepossibilitythatanattackercandisruptthenegotiation.Animportantbenefitofusingthisformofnegotiationisthatithelpseasethetransitionfromlesssecureauthenticationservicestowardmoresecureservices,suchasKerberos.Consequently,inanenvironmentwhereapplicationsbasedontheGSSAPIhavebeendeployed,newauthenticationservicescanbeintroducedinsuchawaythatstrongerservicesarepreferredandolder,lesssecureauthenticationservicescanbephasedoutin

agraceful

manner.

SASL and Kerberos

TheSimpleAuthenticationandSecurityLayer,orSASL,frameworkwasintroducedasawaytofurtherinsulateapplicationsfromunderlyingauthenticationandothersecurityservices(ref.RFC4422).SASLprovidesanapplicationframework(morethanjustanAPI)thatsimplifiesbuildingsecureapplicationsthatonlyneedasimple,bidirectionalstreamorientedcommunicationsfacilitybetweenpeers.Itisparticularlyeffectiveatallowingapplicationstosimultaneouslysupportvariousauthenticationmechanismswithoptionalconfidentialityandintegrityassuranceservices.SASLusestheGSSAPIforKerberosauthenticationsupport,andoptionallyfordataconfidentialityand

integrity.It

is

also

common

for

SASL

applications

to

support

TLS

(SSL)

as

an

alternative

meansforprovidingdataconfidentialityandintegrityprotection.

12MicrosofttendstodescribeapplicationsthatarecompatiblewithGSSAPIwirelevelprotocolsas

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

http://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/rfc4178


24/53

SomepopularInternetapplicationsthatareavailableinSASLbasedversionsinclude:

BEEP:BlockExtensibleExchangeProtocol,whichisitselfaframeworkforapplicationsthatneedtoexchangeblockorientedmessagesandmanagequeriesandresponses

IMAP:InternetMessageAccessProtocol,whichisapopularprotocolforemail

clients

to

interact

with

email

servers,

including

Microsoft

Exchange

servers

LDAP:LightweightDirectoryAccessProtocol,whichisthefoundationformostofthemoderndirectoryservices,includingMicrosoftsActiveDirectory

POP3:ThewidelyusedPostOfficeProtocol(version3)usedbyemailclientstodownloademailfromservers

SMTP:SimpleMailTransferProtocol,thepushprotocolusedtosend(andreceive)emailfromclientstoserversandtoexchangeemailbetweenservers

XMPP:eXtensibleMessagingandPresenceProtocol,aninstantmessagingprotocolusedinJabberandotherIMapplications,suchasPidgin

KerberosiswidelyusedbySASLversionsoftheemailprotocolsandLDAPdirectoryservices,aswellassomeapplicationsbasedonXMPP.

Channel Binding

AmorerecentapproachtoallowingauthenticationmethodstobeusedinconjunctionwithothersecurityprotocolsistermedchannelbindingandisdescribedinRFC5056.Channelbindingallowsamutualauthenticationexchangetoauthenticateasecurechannelbetweenthepartiesaswellasthepartiestoeachother.Thisisusefulwhereapplicationsmayhaveaccesstosecureprotocolservices,orchannels,suchasTLSorIPsecthatcanbeusedforcommunicationsbetweenparties.Theproblemis:howdo

applicationsknow

that

the

party

they

have

authenticated

is

also

the

party

on

the

other

endofthesecurechannel?Ifthechannelcanbeuniquelyreferenced,andsomechannelidentifiercanbeincludedintheauthenticationexchange,thenitispossibletobindthechanneltothemutuallyauthenticatedsessionbetweentheparties.Inotherwords,theywillknowthatthepartytheyhaveauthenticatedisalsothepartyontheotherendofthesecurechannel.

ChannelbindingprovidesamoregeneralapproachthanwhatisprovidedbytheSASLframeworkwhereitisdesirabletouseKerberoswithothersecurityservices,suchasTLSorIPsec.Whilenotwidelydeployedyet,thisapproachislikelytobecomeabestpracticefordeployingsecureapplicationsthatneedflexibleapproachesfordecoupling

authentication

from

other

security

services.

Pluggable Authentication Modules (PAM)

ThePluggableAuthenticationModules(PAM)frameworkwasoriginallyproposedbySunasamechanismtodecoupleauthenticationfromloginapplications.PAMwasoriginallyproposedaspartoftheCommonDesktopEnvironment.Sincethen,PAMhasgainedacceptanceonmostLinuxandUNIXplatforms.

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


25/53

PAMprovidessystemadministratorswithaconfigurationfileallowingthemtospecifywhatPAMmodules(andthuswhatauthenticationmechanisms)areused.ApplicationssuchastheGnomeorKDEloginscreencallintoPAMwithauseridandpassword.PAMrunsthrougheachoftheconfiguredmodulesinseries,allowingthemtointeractwiththeauthenticationprocess.Modulescanaskforadditionalinformation(e.g.,aone

timepassword

challenge)

from

the

user.

Modules

can

indicate

that

authentication

has

failedorindicatethatthecurrentmodulehassucceeded.Typically,ifallmodulessucceed,thenauthenticationissuccessful.PAMalsoprovidessomefacilitiesforsessionmanagementandauthorization.

MostLinuxdistributionsandSolarisincludeaPAMKerberosmodule.ThismoduleperformsKerberosinitialauthenticationandobtainsKerberosticketsfortheuser.Oftenthesemodulesareusedtoauthenticateausertothelocalmachine:iftheuserisabletoobtainKerberostickets,thenthemachinerunningthePAMmodulehasconfidencethattheKerberosprincipalisanamefortheuser.Togainthisconfidence,thePAMmodulemusttaketheresultingKerberosTGTandusethistickettoauthenticatetosomeservice(e.g.,thehostprincipalorcomputeraccount)onthelocalcomputer.Thisisbecausetheinitial

Kerberos

exchange

authenticates

the

user

and

KDC

to

each

other

but

does

not

authenticatethelocalmachinetoeither.Consequently,inordertohaveconfidencethattheuseriswhotheyclaimtobe,thelocalmachinemustberegisteredasaKerberosservice.

PAMservestworolesinKerberosenvironments.First,itservestheroledescribedabove:authenticatinglocalusersofLinuxandUNIXenvironments.However,PAMcanalsobeusedwithnetworkapplicationstoallowuserstouseKerberosprincipalsandthecorrespondingpasswordtoauthenticateoverthenetwork.ThisisverydifferentfromthewayGSSAPIorSASLuseKerberos.GSSAPIdoesnotsendthelongtermsharedsecretoverthenetwork;insteadtheKerberosapplicationauthenticationexchangeisusedtoproveknowledgeofthesessionkeyassociatedwithaticket.Consequently,

GSSAPI

requires

support

in

the

client

application.

When

PAM

is

used

for

authenticationwiththenetworkapplication,theserverreceivesthelongtermpasswordandKerberosexchangesareperformedontheserverinordertoconfirmthatthesuppliedpasswordiscorrect.UnliketheGSSAPIcase,thePAMapplicationneedstobetrustedwiththeuserslongtermsecret.Inaddition,thesecretislikelytobeinterceptedasitistransmittedoverthenetwork.Clearly,usingPAMwithnetworkapplicationsdoesnotprovidethesecurityadvantagestypicalofKerberos.However,itdoesallowtheKerberosinfrastructuretobeusedevenwhenclientsdonotdirectlysupportit.BestpracticeistopreferclientsidesupportforKerberostotheuseofPAMfornetworkapplications.

PAMmodulesarealsoavailabletomovefromotherauthenticationsystemstoKerberos.

These

migration

modules

will

take

asupplied

userid

and

password

that

has

alreadybeenverifiedbyaPAMmodulefortheexistingauthenticationinfrastructureandregistertheprincipalintheKDCdatabase.ThemigrationmoduleneedstobetrustedtoregisterprincipalsintheKerberosdatabase.Typically,thistrustislimitedbyallowingthemoduletocreatenewprincipalsbutnottomodifyexistingprincipals.

Unfortunately,whilePAMisavailableonmanyplatforms,therearesignificantdifferencesinhowPAMworksoneachplatform.Multipleattemptshavebeenmadeto



26/53

standardizePAM,buttheimplementationsinusetodaydonotmatcheachotherorthestandards.Asaresult,systemadministratorsandapplicationdevelopersshouldbecarefultoconsultthedocumentationforPAMontheirplatform.

Kerberos and Public Key Cryptography

Kerberoswas

developed

before

asymmetric

(a.k.a.,

publickey)

cryptography

was

aviable

technologyfordeploymentincommerciallyavailablesystems.Consequently,Kerberosauthenticationisbasedonuseofsymmetriccryptography.Theimplicationisthatsymmetricencryptionkeysmustbeexchangedbetweenpartiesasaprerequisitetobeingabletoperformauthentication.Forhumanusers,passwordsareusedtoderivesymmetricencryptionkeysforauthenticationandexchangeofsubsequentsessionkeys.

Inpractice,everyuserandserviceprincipalmustgothroughaninitialsetupprocesswherepasswordsorsymmetricencryptionkeysareexchangedwithaKDC.Whilethiscanbedonesecurelywithproperprocedures,itisstillanadministrativeheadache.Furthermore,thesharedsecretkeycanbecompromisedbyeitherparty.Changing

passwords

and

keys

can

also

be

a

burden

for

users

and

system

administrators.

Theappealofasymmetriccryptographyisthattherearetwokeys,whereanythingencryptedwithonekeycanonlybedecryptedwiththeoneandonlycorrespondingkey.Whenasymmetrickeypairsaregenerated,itiscommonpracticetotreatoneasapublickeythatcanbefreelysharedwithotherpartieswhiletheotherkeyinthepairiskeptasaprivatekeythatshouldnotbesharedwithanyotherparties.Thisgreatlysimplifieskeysharing,sincethepublickeycanbefreelyexchangedbetweenpartiesprovidedtheprivatekeyisnotdisclosed.

Theprimaryconcernwithdistributingpublickeysisdeterminingwhetherornotapublickeyreallybelongstoaspecificparty.Thisisgenerallysolvedthroughuseof

public

key

certificates

(ref.

RFC

5280),

which

include

the

name

of

the

party

(subject)

and

theirpublickeyinadocumentthatisdigitallysignedbysomeCertificationAuthorityorCA.AnypartythatreceivesacertificatecanvalidatetheCAssignaturetoconfirmthatthepublickeyreallybelongstothesubjectnamedinthecertificatepresuming,ofcourse,thattheCAthatissuedthecertificateisconsideredtrustworthy.

Overthepastdecade,asymmetriccryptographyandpublickeycertificateshavebecomewidelysupportedtechnologiesthatarenowbuiltintomostcomputingplatforms.Furthermore,Kerberoshasbeenextendedtotakeadvantageofthesetechnologies,primarilyforinitialauthenticationofusersrequestingTGTs,thoughotherextensionshavebeenproposedforincludingpublickeycertificatesinKerberostickets.

PKINITPublic Key Cryptography for Initial Authentication in KerberosRFC4556(PKINIT)specifiesextensionstoKDCAuthenticationServicesthatallowclients(users)tobeinitiallyauthenticatedbypresentingtheirpublickeycertificatesinsteadofusingpreviouslysharedsecretpasswords.Onlytheinitialauthenticationprocedureischanged;allotherKerberosinteractionsremainthesame.Inparticular,clientscontinuetoreceiveTicketGrantingTickets(TGTs)thatwillbeusedtosubsequentlyrequestticketsforservices,andservicescontinuetoauthenticateusersviaticketsissuedbyKDCs.Aservicehasnoneedtosupportpublickeycryptography,or

http://tools.ietf.org/html/rfc5280http://tools.ietf.org/html/rfc5280http://tools.ietf.org/html/rfc5280http://tools.ietf.org/html/rfc4556http://tools.ietf.org/html/rfc4556http://tools.ietf.org/html/rfc4556http://tools.ietf.org/html/rfc4556http://tools.ietf.org/html/rfc5280


27/53

evenknowhowtheclientinitiallyauthenticatedtotheKDC.Fromanapplicationperspective,clientandserviceinteractionsareexactlyasbefore.

AnimportantconsequenceofusingPKINITisthatuserscanmoreeasilybegivenanaccountinarealmtheyhavenevervisitedbefore.Ifanemployeeorcontractorwithatrustedcertificatemovestoanewpartofanorganization,theiraccountcanbewaiting

forthem

with

no

need

to

register

anew

password.

Furthermore,

use

of

public

key

certificateshelpsmitigateriskswithweakuserpasswords,sincetheusersprivatekeyisusedduringinitialauthenticationinsteadofapassword.Ausermaystillenterapassword,butonlyontheirlocalworkstationordevicetounlocktheprivatekey.Passwordchangestendtobehandledattheuserdevicelevel,anddonothavetobecoordinatedwithothersystems.

Atleasttheoretically,usingPKINIT,userprincipalsnolongerneedtoberegisteredintheKDCdatabasebeforeinitialauthentication,sincetheKDCdoesnotneedtolookupthecorrespondingsharedsecretforauserwithacertificate.ServiceprincipalsmuststillberegisteredintheKDCdatabasealongwithasharedsymmetricencryptionkey.A

KDC

database

could

be

much

smaller,

since

there

tend

to

be

more

user

principals

than

serviceprincipals.However,inpractice,usersstillneedtoberegisteredtostorepolicyandotherinformation.Alsoasdiscussedbelow,entitlementinformationandotherattributesaboutauseraretypicallystoredinsomedirectory.PKINITdoesnotreducetheneedforthisinformation.WithPKINIT,theadministrativeoverheadformaintainingtheKDCdatabaseshouldbereduced,anduserpasswordchangeswouldnolongerneedtobesupportedforuserswithcertificates.Fororganizationsthatalreadyissuecertificatestousers,itispossibletoallowuserstoauthenticatewiththeircertificateacrossmultipleauthenticationsystems,includingsystemsthatuseTLS/SSLandvariousVPNtechnologiesinadditiontoKerberos.Atthesametime,applicationsbasedonKerberosdonotneedtobechanged.

Anotherbenefit

is

that

certificates

can

be

associated

with

hardware

cryptographic

tokens,includingsmartcardsandUSBdeviceswithembeddedsmartchips.Somebiometricauthenticationdevicescanalsobeusedwithcertificates,butwherethebiometricdeviceisusedtounlockaccesstotheusersprivatekey.

Ofcourse,thesebenefitscomeattheexpenseofdeployingaPublicKeyInfrastructure(PKI)thatincludesCertificationAuthorities(CAs),certificaterequestandissuingservices,certificaterevocationprocedures,statuscheckingservices,anddirectoriesforretrievingcertificatesforspecificusersorotherprincipals.However,PKIhasbecomeanintegralpartofseveralvendorplatforms,anditiswidelyavailable.Inmanyenvironments,theadvantagesofpublickeycryptographyandcertificatesmorethan

justify

the

added

burden

of

deploying

and

maintaining

a

PKI.

Alternatively,

PKINIT

can

beusedwithoutaPKI.TheKDCdatabasecanstoreselfissuedcertificatesassociatedwithuserprincipals.ThisavoidsrelianceonaCA,sincetheKDCcantrustapublickeyinitsdatabase,andnopasswordsecretisneededfortheuser.However,otheradvantagessuchaseasymigrationbetweenrealmsandsupportforapplicationsbeyondKerberostendtorequireaPKI.

Oneconcernwithcertificatesusedinauthenticationisthattheytendtohaverelativelylonglifetimesontheorderofmonthstoevenacoupleofyears.Thisleadstogreater



28/53

exposureswhenprivatekeysarecompromised,orauserscertificateneedstoberevokedforsomecause.ThismeansthataKDCmightallowauserwitharevokedcertificatetoauthenticate,andsubsequentlyaccessapplicationservices.Therearetwoapproachesformitigatingthisrisk,(1)distributionofCertificateRevocationLists(CRLs)and(2)useofOnlineCertificateStatusProtocol(OCSP)services(ref.RFC2560).

Useof

OCSP

services

is

particularly

attractive,

as

it

allows

certificate

status

to

be

checkedinrealtimeaspartoftheinitialauthenticationprocess.RFC4557specifieshowPKINITcanbefurtherextendedtointegrateOCSPchecksduringKerberosinitialauthentication.

Support for Multiple Kerberos RealmsAKerberosrealmmustbeadminist

Date post:	10-Apr-2018
Category:	Documents
Upload:	kmkiran9092
View:	213 times
Download:	0 times

rolekerberos

Documents