Kerberos autentiseringssystem, som ingår i MIT:s projekt Athena, har antagits av andra organisationer. Trots Kerberos många styrkor, har det en numbe r begränsningar och vissa svagheter. Vissa beror på specifika av MIT-miljön; andra representerar brister i protokollets utformning. Vi diskuterar ett antal sådana problem och presenterar lösningar på några av dem. Vi visar också hur speciell kryptografisk hårdvara kan behövas i som e fall. Kerberos autentiseringssystem [steiss, Mi1187, Brya88] infördes av MIT för att möta behoven hos Projec t Athena. Det har sedan dess antagits av ett antal andra organisationer för deras egna ändamål, och diskuteras som en möjlig standard. Vi anser att båda dessa beslut kan vara förhastade. Kerberos har ett antal begränsningar och svagheter; ett beslut om att anta eller förkasta det kan inte fattas ordentligt med tanke på dessa frågor. (En begränsning är en funktion som inte är så allmän som man kanske vill, medan en svaghet kan utnyttjas av en angripare för att besegra autentiseringsmekanismen.) Vissa förbättringar kan vara galna e inom den nuvarande designen. Stöd för frivilliga mekanismer skulle utvidga Kerberos tillämplighet t o miljöer som radikalt skiljer sig från MIT. Dessa problem kan delas in i flera kategorier. Vissa härrör från projektet Athena miljö. Kerberos var utformad för den miljön; om de grundläggande antagandena skiljer sig, autentiseringssystemet kan behöva b e ändras också. Andra problem är helt enkelt brister i protokollets utformning. Några av dessa är korrekta d i den föreslagna Version 5 av Kerberos, FKohls9] men inte alla. Även de lösta problemen förtjänar att diskuteras, eftersom koden för version 4 har spridits i stor utsträckning. Slutligen, vissa problem med Kerberos är ingen t lösbar utan att använda specialutrustning, oavsett utformningen av protokollet. Vi anser att vart och ett av dessa områden i sin tur. Vi vill betona att vi inte antyder att Kerberos är värdelös. Tvärtom - en angripare som kan utföra någon av de attacker som listas här kan penetrera ett typiskt nätverk av UNix ® system mycket lättare. Att lägga till Kerberos i ett nätverk kommer under praktiskt taget alla omständigheter att avsevärt öka dess säkerhet; vår kritik fokuserar på i vilken utsträckning säkerheten förbättras. Vidare rekommenderar vi ändring s till protokollen som avsevärt ökar säkerheten. Utöver dess specifika verktyg i produktionen, Kerberos tjänar en stor funktion genom att fokusera intresset på practica l lösningar till nätverket autentisering problem. Den eleganta protokolldesignen och den breda tillgängligheten av e e-koden har galvaniserat en bred publik. Långt ifrån ett fördömande är vår kritik avsedd att bidra till en förståelse av Kerberos egenskaper och att påverka dess utveckling till ett verktyg för större makt och nytta. Flera av de problem som vi påpekar nämns i den ursprungliga Kerberos-tidningen eller någon annanstans. [Davi90] Fo r några av dessa, presenterar vi protokoll förbättringar som löser, eller åtminstone förbättra, problemet ; för andra, * Författarens adress : Steven M. Bellovin, Room 3C-536B, AT&T Bell Laboratories, 600 Mountain Avenue, Murray Hill, New Jersey 07974, f Författarens adress : Michael Merritt, Room 3D-458, AT&T Bell Laboratories, 600 Mountain Avenue, Murray Hill, New Jersey 07974. -119-vi placerar dem fyrkantigt i samband med den avsedda Kerberos miljön. Kerberos är ett säkerhetssystem; alltså, även om vi tar itu med frågor om funktionalitet och effektivitet, vår primära y betoning är på säkerheten i Kerberos i en allmän miljö. Detta innebär att säkerhetskritiska antaganden måste vara få till antalet och tydligt anges. För det bredaste verktyget, måste nätverket b e anses vara helt öppet. Specifikt, protokollen bör vara säkra även om nätverket är under e fullständig kontroll av en motståndare. ) Detta innebär att besegra protokollet bör kräva motståndaren t o invert krypteringsalgoritmen eller att subvertera en princip som särskilt antas vara pålitlig. Endast en sådan stark design mål kan motivera kostnaden för kryptering. (Inga "ståldörrar i pappersväggar") Vi tror att Kerberos kan uppfylla detta ambitiösa mål med endast mindre ändringar, behålla sin väsentliga karaktär. Några av våra förslag bär en prestanda straff ; andra komplicera utformningen av föreslagna förbättringar. Som fler organisationer använder sig av Kerberos, tryck för att förbättra eller öka dess funktionalitet och effektivitet kommer att öka. Säkerhet har verkliga kostnader, och fördelarna är immateriella. Det måste finnas en fortsatt och uttrycklig betoning på säkerhet som det övergripande kravet. Det är inte tillräckligt att utforma och genomföra ett säkerhetssystem. Sådana system, även om de uppenbarligen är tillräckliga när de är utformade, kan ha allvarliga brister. Följaktligen måste system utsättas för den starkaste scrutin y möjligt. En följd av detta är att de måste utformas och genomföras på ett sätt som underlättar en sådan granskning. Kerberos har också ett antal problem på detta område. Innan du diskuterar specifika problemområden, är det bra att granska Kerberos Version 4. Kerberos är ett autentiseringssystem; det ger bevis på en huvudansvarigs identitet. En huvudansvarig är i allmänhet antingen en användare o r en viss tjänst på någon maskin. En huvudansvarig består av tre-tupl e <primärnamn, exempel, rike>. Om huvudmannen är en användare - en äkta person - är huvudnamnet inloggningsidentifieraren, och instansen är antingen ogiltig eller representerar särskilda attribut för användaren, dvs root. För en tjänst används servicenamnet som primärnamn och maskinnamnet används som exempel, dvs. rlogin.myhost. Riket används för att skilja mellan olika behörighetsdomäner; därför behöver det inte finnas en jätte -an d universellt betrodd -Kerberos databas som betjänar ett helt företag. Kerberos huvudmän kan få biljetter för tjänster från en särskild server som kallas biljett-beviljande server, eller TGS. En biljett innehåller diverse information som identifierar huvudmannen, krypterad i den privata nyckeln till e-tjänst. (Notationen sammanfattas i tabell 1.) {Tc, S}Ks=s, c, adder, timestamp, livstid, K c Eftersom endast Kerberos och tjänsten delar den privata nyckeln K s, biljetten är känd för att vara autentisk. Ticka t innehåller en ny privat session nyckel, K c, s, känd för klienten också ; denna nyckel kan användas för att komplettera t transaktioner under sessionen. 2 För att skydda mot replay attacker, alla biljetter presenteras åtföljs av en autentiserare : 1. Projektet Athena Technical Plan] Mft8l, sect10n 2] beskriver en enklare hotmiljö, där tjuvlyssnande och host imitation är av största vikt. Även om detta kan vara lämpligt för MIT, är det på intet sätt generellt sant. Betrakta, för r exempel, en situation där general-purpose värdar också fungerar som routers, och paketmodifiering eller radering blir betydande t oro. 2. Utgångspunkten är följande: Tekniskt sett är K,, en flersessionsnyckel, eftersom den används för alla kontakter med den servern under biljettens livstid. -120- Detta är en kort sträng krypterad i sessionsnyckeln och innehåller en tidsstämpel ; Om tiden inte matchar th e nuvarande tid inom (förbestämda) klocka skew gränser, anses begäran vara bedräglig. För tjänster där kunden behöver dubbelriktad autentisering, servern kan svara wit h Detta visar att servern kunde läsa tidsstämpel från autentiseraren, och därmed att det kne w K c,s ; att i sin tur är endast tillgänglig i biljetten, som är krypterad i serverns privata nyckel. Med andra ord används en vanlig biljett/autenticator par; biljetten är känd som biljett-beviljande biljett. TGS svarar med en biljett för server s och en kopia av K,, s, alla krypterade med en privat nyckel delad b y TGS och huvudmannen : sessionsnyckeln K,,s är en nyligen vald slumpmässig nyckel. Nyckeln K c, tgs och biljett-beviljande biljetten i sig, erhålls vid session-start. Kunden skickar ett meddelande till Kerberos med ett huvudnamn; Kerberos svarar wit h {K c,tgs,{T c,tgs}Ke gs}K c Klientnyckeln K c är härledd från en icke-inverterbar omvandling av användarens skrivna lösenord. Således, al l privilegier beror slutligen på denna en nyckel. Observera att servrar måste ha egna privata nycklar för att kunna dekryptera biljetter. Dessa nycklar lagras på en säker plats på serverns maskin. Projekt Athena computing miljö består av ett stort antal mer eller mindre anonymous arbetsstationer, och ett mindre antal stora autonoma servermaskiner. Servrarna ger flyktig fillagring, utskrift spooling, brevlådor, och kanske vissa datorkraft; arbetsstationer används för Mos t interaktion och dator. Generellt har de lokala diskar, men dessa diskar är effektivt läsbara; de innehåller inga långsiktiga användardata. Dessutom är de inte fysiskt säkra; någon så lutande kunde ta bort, läsa eller ändra någon del av disken utan hinder. I denna miljö är det primära behovet för autentisering från användare till server. Det vill säga, när en användare sitter dow n på en arbetsstation, den personen behöver tillgång till privata filer som är bosatta på en server. Arbetsstationen själv har n o sådana filer, och har därför inget behov av att kontakta servern eller ens att identifiera sig själv. -121-Detta är i tydlig kontrast till ett typiskt UNIX systems syn på världen. Sådana system har en identitet, och de har egna filer. Olika nätverksdemoner överför filer i bakgrunden, klockdemoner perfor m förvaltning funktioner, e-post och nyheter anländer, etc. Om en sådan maskin förlitade sig på servrar för att lagra sina filer, skulle den behöva hävda, och möjligen bevisa, en identitet när man talar med dessa servrar. De Projec t Athena arbetsstationer är varken kapabla eller i behov av sådana; de fungerar i själva verket som mycket smart terminal s med betydande lokal datorkraft, snarare än som full datorsystem. 3 Vad innebär detta för Kerberos? Helt enkelt detta : Kerberos är utformad för att autentisera slutanvändaren - th e människa sitter vid tangentbordet - till ett antal servrar. Det är inte ett peer-to-peer-system; det är inte avsett att användas av en dators daemons när man kontaktar en annan dator. Att försöka använda Kerberos i ett sådant läge kan orsaka problem. 4 Vi gör detta uttalande av flera skäl. Först och främst, typiska datorsystem inte har en säker nyckel lagringsområde. I Kerberos måste en klartextnyckel användas i den inledande dialogrutan för att få en biljettutfärdande biljett. Men lagring av klartext nycklar i en maskin är allmänt känt som en dålig idé; [Morr79] om en Kerberos nyckel som en maskin använder för sig själv äventyras, inkräktaren kan sannolikt imitera någon användare o n att datorn, genom att imitera förfrågningar som går i god för av den maskinen (dvs., fil monterar eller cron jobb).5 Dessutom kan session nycklar returneras av TGS inte lagras säkert; av nödvändighet, de lagras i något område som är tillgängligt för root. Således, om inkräktaren kan knäcka skyddsmekanismen på loca l dator - eller kanske mer till punkt, arbeta runt det för vissa begränsade ändamål - alla nuvarande sessio n nycklar kan stjälas. Detta är mindre allvarligt än ett brott mot den primära Kerberos nyckel, naturligtvis, eftersom sessio n nycklar är begränsade i livslängd och omfattning; ändå, man inte önskar dessa nycklar exponeras. Detta pekar på en andra brist när fleranvändardatorer använder Kerberos, antingen för egen räkning eller för sina användare: de cached nycklar är tillgängliga för angripare inloggade samtidigt. I en arbetsplats miljö, bara den nuvarande användaren har tillgång till systemresurser; det finns lite eller inget behov av enabl e fjärrinloggning till den arbetsstationen. Det finns många skäl till detta ; en konsekvens, dock, är att e inkräktare helt enkelt inte kan närma sig den säkra dörren för att försöka plocka sitt lås. 6 Endast när den legitima användaren lämnar kan angriparen försöka hitta nycklarna. Men nycklarna är inte längre tillgängliga ; Kerberos försöker wip e ut gamla nycklar vid loggoff tid, lämnar angriparen att sålla igenom skräpet. Med en fleranvändardator, å andra sidan, en angripare har samtidig tillgång till nycklarna om det finns brister i värdens säkerhet. Det finns två andra mindre brister i Kerberos som direkt kan hänföras till miljön. Först finns det som e fråga om var nycklar ska cachas. Eftersom alla Project Athena maskiner har lokala diskar, den ursprungliga koden används /tmp. Men detta är mycket osäker på disklösa arbetsstationer, där /tmp finns på en fil e-server; följaktligen gjordes en ändring för att lagra nycklar i delat minne. Det finns dock ingen garanti för att delat minne inte sidas; om detta innebär nätverkstrafik, en inkräktare kan fånga dessa nycklar. Slutligen, Kerberos protokollet binder biljetter till IP-adresser. Sådan användning är problematisk på multi-homed värdar (dvs.., värdar med mer än en IP-adress). Eftersom arbetsstationer sällan har flera adresser, denna funktion -avsedd att öka säkerheten - var inte ett problem vid MIT. Flera användare värdar ofta har e flera adresser, dock, och kan inte leva med denna begränsning. Detta problem har rättats i version 5. 3. Vad är det som händer? Vi betraktar detta som en funktion, inte en bugg. 4. Vad är det som händer? Mer exakt, Kerberos är inte ett värd-till-värd-protokoll. I version 5 har den utökats till att stödja användar-till-använd r 5. Kom ihåg att vi antar här att maskinen - och därmed dess superanvändare - behöver en egen identitet. 6. Vad är det som händer? På Project Athena maskiner är fjärråtkomst till de flesta arbetsstationer faktiskt inaktiverad. -122- Kerberos-protokollet är inte så motståndskraftigt mot penetration som det borde vara. Ett antal svagheter är uppenbara; den allvarligaste är dess användning av en autentiserator för att förhindra replay attacker. Autentiseraren förlitar sig på att använda en tidsstämpel för att skydda mot återanvändning. Detta är problematiskt av flera skäl. Påståendet görs att inga replays är sannolikt inom livstiden för autentiseraren (vanligtvis fem minuter). Detta förstärks av närvaron av IP-adressen i både biljetten och autentiseraren. Vi övertygas inte av denna logik. En inkräktare skulle inte börja med att fånga en biljett och autentisera, och sedan utveckla programvaran för att använda dem; snarare, allt skulle vara på plats innan biljetten-fånga wa s försök. Låt oss se på två exempel. För några år sedan beskrev Morris en attack baserad på den långsamma ökningshastigheten av den initiala sekvensnummerräknaren i vissa TCP-implementationer. iM°r r85] Han visade att det var möjligt, under certai n omständigheter, att spoof en halv av en förautenticerad TCP-anslutning utan att någonsin se någon respons s från den riktade värd. I en Kerberos miljö, hans attack skulle fortfarande fungera om åtföljs av en stulen n levande autentiserare, men inte om en utmaning / svar protokoll användes. Alternativt, en inkräktare kan förenkla y titta på för en "postkontroll" session, där en användare loggar in kort, läser några meddelanden, och loggar ut. Ett antal värdefulla biljetter skulle avslöjas av en sådan session, särskilt den som används för att montera användarens hemkatalog. Observera att livstiden för autentiserare -5 minuter -bidrar avsevärt till denna attack. Vidare, den föreslagna version 5 av Kerberos förutser alternativa kommunikationsprotokoll där suc h replays kan vara trivialt att genomföra. Om Kerberos ska betraktas som ett allmänt ändamål verktyg, det mus t göra få säkerhetskritiska antaganden om det underliggande nätverket, och dessa måste vara explicit. Det har föreslagits att rätt försvar är för servern att lagra alla levande autentiker; således, en attem t att återanvända en kan upptäckas. tstelss] I själva verket, den ursprungliga utformningen av Kerberos krävde sådan caching, thoug h detta aldrig genomfördes. (Även om det är ett inslag i genomförandet snarare än i själva protokollet, en säkerhetsfunktion är inte mycket användbar om det är för svårt att genomföra. ) Av flera skäl tror vi inte att caching löser problemet. Först, på UNrx system är det svårt för TCP-baserade [POstst] servrar att lagra autentiserare. Servers fungerar i allmänhet genom att förfalska en separat process s för att hantera varje inkommande begäran. Barnprocesserna delar inte något minne med föräldern processen, en d har därför inget bekvämt sätt att informera det - och därmed alla andra barnservrar - om värdet av e autentiserator som används. Det finns ett antal uppenbara lösningar -pipor, autentisera servrar, delade memor y segment och liknande - men alla är besvärliga, och vissa även höja autentisering frågor av egen. Hittills känner vi till ingen multi-trådad server implementation som cache autentiserar. UDP-baserade [P°s tSO] frågeservrar kan lagra autentiserare lättare, som en enda process generall y hanterar alla inkommande förfrågningar; men, de kan ha problem med legitima vidaresändningar av th e klientens begäran om svaret gick förlorat. (UDP ger inte garanterad leverans; alltså, alla vidaresändning s hända från applikationsnivå, och är synliga för ansökan.) Berättigade förfrågningar kan avslås, en d ett säkerhetslarm upp på ett olämpligt sätt. En möjlig lösning skulle vara för ansökan att generera en ne w autentisera vid återutskick av en begäran; om det inte för de andra svagheterna i autentisera systemet, detta skulle vara godtagbart. Som noterats, autentiker förlitar sig på maskiners klockor ungefär synkroniseras. Om en värd kan vilseledas abou t rätt tid, kan en gammal autentiserare spelas upp utan några problem alls. Eftersom vissa Tim e synkronisering protokoll är oautenticated, tpostSS, 1'4 E11' 8 ] och värdar fortfarande använder dessa protokoll despit e förekomsten av bättre, [Mm89] sådana attacker är inte svårt. Designfilosofin att bygga en autentiseringstjänst ovanpå en säker tidsservice är själv tveksam. Det vill säga, det kanske inte är meningsfullt att bygga ett autentiseringssystem förutsatt att ett redan autenticerat underliggande system. Dessutom, medan spoofing en unautenticated time service kan vara en svår programmering uppgift, det är inte kryptografiskt svårt. Att använda tidsbaserade protokoll i en säker -123-fashion innebär att tänka igenom alla dessa frågor noggrant och göra lämplig synkronisering till en explicit del av protokollet. Som Kerberos föreslås för mer varierande miljöer, dess beroende av en säker tidsservice blir mer problematisk och måste betonas. Som ett alternativ föreslår vi att man använder en mekanism för autentisering av utmaningar/svar. Som görs idag, klienten skulle presentera en biljett, men utan en autentiserare. Servern skulle svara med en nonc e-identifierare krypterad med sessionsnyckeln K c,s ; klienten skulle svara med någon funktion av den identifieraren, vilket bevisar att den har sessionsnyckeln. Ett sådant genomförande är naturligtvis inte utan kostnader. Ett extra par meddelanden måste bytas d varje gång en biljett används, vilket utesluter möjligheten att autentiserade datagram. Mer allvarligt, al l servrar måste sedan behålla tillstånd för att slutföra autentiseringsprocessen. Även om inte ett problem för TCP-baserade servrar, kan detta kräva betydande ändring av UDP-baserade frågeservrar. (Komplexiteten i managin g utestående utmaningar kan vara jämförbar med den som behövs för att cache levande autentiker--t avvägningen är inte mellan ett statligt och ett statslöst protokoll, men att hantera två typer av stat.) Det finns dock en tydlig filosofisk skillnad mellan de två teknikerna. I den nuvarande Kerberos genomförande, med sina antaganden om nätverksmiljön, behålls tillstånd är endast nödvändigt t o öka säkerheten. Utmanings- och responssystemet, å andra sidan, garanterar säkerhet i en mer genera l miljö, men kräver bibehållet tillstånd för att fungera över huvud taget. I stället för att ersätta hela utmaningen/responsen är en möjlig kompromiss att förlänga protokollet med ett alternativ för utmaning/respons. Detta alternativ kan till exempel användas för att autentisera användaren i initia l biljettutfärdande biljett utbyte och för att få tillgång till en tidsservice. 8 Efterföljande klient-server interaktioner kan vi e den aktuella tidsbaserade protokollet. Men synkronisering servrarna är fortfarande ett problem; inte synkronisera m kommer att leda till överbelastning, och om de får tillgång till tidstjänsten som en klient, de måste på något sätt få en d lagra en biljett och nyckel för att autentisera det. (Se ovan om lagring av nycklar i servrar.) Med tanke på dessa komplexa och möjliga svagheter förefaller det rimligt att låta alla tjänster insistera på utmaningen/ansvaret för e-alternativet. Sammanfattning, vi betonar att säkerheten i Kerberos beror kritiskt på synkroniserade klockor. I n essens, Kerberos protokoll innebär ömsesidigt förtroende mellan fyra parter: klienten, servern, autentico n server och tidsserver. .3 Password-Gissa attacker
Ett brott mot ett systems autentiseringsserver kommer att resultera i exponering av alla användarkonton på grund av centraliseringen av autentiseringshantering REF.
Limitations of the Kerberos authentication system
{'venue': 'CCRV', 'journal': None, 'mag_field_of_study': ['Computer Science']}