Kerberos — протокол за удостоверяване и софтуер на MIT: как работи

Kerberos (произнася се /ˈkɜrbərəs/ "kur-ber-uhs") е протокол за удостоверяване в компютърната мрежа, който позволява на участниците, комуникиращи по [защитена мрежа, да докажат самоличността си — например Mohammed Hasan, потребител на Gmail — по сигурен начин. Това е и пакет от безплатен софтуер, публикуван от Масачузетския технологичен институт (MIT), който реализира този протокол. Неговите създатели са се насочили предимно към модела клиент-сървър; Kerberos поддържа взаимно удостоверяване, при което както Mohammed Hasan, така и сървърът могат да проверят самоличността си. Съобщенията на протокола Kerberos са защитени срещу шпионски атаки и атаки за преиграване.

Kerberos извършва удостоверяване като услуга, предоставяна от доверена трета страна, и използва криптографска споделена тайна. Проектиран е при предположението, че съобщенията, пътуващи по несигурната мрежа, могат да бъдат прочетени, модифицирани или повторени от нападател. Kerberos се основава основно на криптография със симетричен ключ и изисква център за разпределение на ключове (KDC). Разширенията на Kerberos позволяват използването на криптография с публичен ключ по време на определени фази на удостоверяване, например за първоначално установяване на доверие без споделен таен ключ.

Основни компоненти

KDC (Key Distribution Center) — централен сървър, който съдържа два логически компонента: Authentication Server (AS) и Ticket Granting Server (TGS). KDC е доверената трета страна, която издава тикети и сесийни ключове.
Клиент — потребител или процес, който иска достъп до услуга в мрежата.
Сървър на услугата — ресурсът, към който клиентът иска достъп; приема тикети от клиентите, за да провери техния произход.
Тикет (ticket) — криптирано съобщение, издавано от TGS и предназначено за сървъра на услугата; съдържа ключ за сесия и идентификационни данни, валидни за определено време.
Authenticator — допълнителен доказателствен елемент, генериран от клиента и съдържащ например времеви печат, който предотвратява повторното използване на тикети (replay).

Как работи (стъпка по стъпка)

Клиентът иска удостоверяване от AS, като посочва своя идентификатор и идентификатора на TGS.
AS проверява идентичността (на база споделена тайна, обикновено парола) и издава Ticket Granting Ticket (TGT), криптиран с ключа на TGS. Част от отговора е криптирана и с ключ, получен от паролата на клиента, за да може той да я разшифрова.
Клиентът разшифрова полученото и използва TGT, за да поиска конкретен сервизен тикет от TGS.
TGS издава сервизен тикет за желания ресурс; този тикет е криптиран за сървъра на услугата и съдържа сесионен ключ.
Клиентът представя сервизния тикет на сървъра заедно с authenticator; сървърът проверява тикета и може да отговори с доказателство за валидност (позволявайки взаимно удостоверяване).
След успешна проверка клиентът има краткотраен сесионен ключ и може да използва защитена комуникация със сървъра.

Защита и свойства

Използват се криптирани тикети и авторизации, за да се предотврати подслушване и фалшифициране.
Таймстамповете и кратката валидност на тикетите предпазват от атаки за преиграване.
Kerberos работи предимно със симетрични ключове, но може да се комбинира с публично-ключова криптография за първоначално удостоверяване или обмен на ключове.
Поддържа трансфер на доверие между различни административни домейни (cross-realm authentication).

Ограничения и рискове

KDC е критичен компонент и представлява единна точка на отказ и цел за атаки; защитата и наличността на KDC са от съществено значение.
Kerberos изисква синхронизирани часовници между участниците (часово отклонение), за да проверява времевите печати.
Атаки върху пароли (brute-force) могат да компрометират ключове, ако паролите са слаби; внедряване на допълнителни мерки (многофакторна автентикация) е препоръчително.
Някои реализации и конфигурации могат да имат уязвимости — поддържането на софтуера актуален е важно.

Практически приложения и реализации

MIT Kerberos е оригиналната и едната от най-разпространените реализации; има и други реализации като Heimdal и вградената поддръжка в Microsoft Active Directory (където Kerberos е основният механизъм за удостоверяване в домейн среда). Kerberos (въведен в RFC 4120 като Kerberos version 5) се използва широко в корпоративни мрежи, системи за единично влизане (SSO) и други среди, където е необходимо централизирано и защитено управление на удостоверяването.

Разширения

Съвременните разширения позволяват интеграция с публично-ключови инфраструктури, делегиране на права (forwardable tickets), подновяване и продължаване на сесии, както и адаптиране към различни протоколи на приложения (например HTTP, SSH, SMB и др.).

Kerberos остава широко използван и развит стандарт за удостоверяване, който осигурява баланс между сигурност и ефективност, но неговата правилна конфигурация и поддръжка са ключови за надеждна работа.

История и развитие

MIT разработи Kerberos за защита на мрежовите услуги, предоставяни от проекта Athena. Протоколът е кръстен на гръцкия митологичен герой Керберос (или Цербер), известен в гръцката митология като чудовищното триглаво куче пазач на Хадес. Съществуват няколко версии на протокола; версии 1-3 се използват само вътрешно в MIT.

Стив Милър и Клифърд Нойман, основните разработчици на версия 4 на Kerberos (която използва алгоритъма за криптиране DES с 56-битови ключове), публикуват тази версия през 1989 г., въпреки че са я насочили предимно към проекта Athena.

Версия 5, разработена от Джон Кол и Клифърд Нойман, се появява като RFC 1510 през 1993 г. (остаряла от RFC 4120 през 2005 г.), с цел да се преодолеят ограниченията и проблемите със сигурността на версия 4. MIT предоставя свободен достъп до имплементация на Kerberos версия 5 под софтуерен лиценз, подобен на този, използван от BSD лиценза.

Няколко компании използваха Kerberos версия 5 в търговски софтуер, включително:

· Windows 2000 и по-новите версии на Microsoft използват Kerberos като метод за удостоверяване по подразбиране.
Някои допълнения на Microsoft към пакета протоколи Kerberos са документирани в RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols".
RFC 4757 документира използването от Microsoft на шифъра RC4.
Въпреки че Microsoft използва протокола Kerberos, той не използва софтуера на MIT[1].

· Mac OS X на Apple също използва Kerberos както в клиентската, така и в сървърната си версия.

· Red Hat Linux версия 4 и по-нови версии използват Kerberos както в клиентската, така и в сървърната версия.

През 2005 г. работната група на IETF Kerberos представи нова актуализирана спецификация за Kerberos версия 5 [2].Актуализациите включват:

· "Спецификации за криптиране и контролни суми" (RFC 3961),

· "Шифроване по стандартаAdvanced EncryptionStandard (AES) за Kerberos 5" (RFC 3962),

· Ново издание на спецификацията на Kerberos версия 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Тази версия отменя RFC 1510, изяснява аспектите на протокола и предназначението му в по-подробно ясно обяснение,

· Ново издание на спецификацията на GSS-API "Механизмът на приложния програмен интерфейс на общата услуга за сигурност Kerberos версия 5 (GSS-API): Версия 2." (RFC 4121).

През 2007 г. Масачузетският технологичен институт (MIT) създаде Консорциума Kerberos за продължаване на разработката.

Протокол

Kerberos използва за основа протокола Needham-Schroeder. Той използва удостоверяване от доверена трета страна, известно като "център за разпределение на ключове (KDC)", който се състои от две логически отделни части: сървър за удостоверяване (AS) и сървър за предоставяне на билети (TGS). Kerberos работи на базата на "билети" (наречени Kerberos tickets), които служат за доказване на самоличността на потребителите.

База данни Kerberos: Всеки субект в мрежата - независимо дали е клиент или сървър - споделя секретен ключ, който е известен само на него и на KDC. Познаването на този ключ служи за доказване на самоличността на всеки субект. За комуникация между две организации KDC генерира ключ на сесията, който те могат да използват, за да защитят комуникацията си.

Терминът "Kerberos сървър" обикновено се отнася за KDC. За целите на надеждността е възможно да се използват резервни KDC. Те се наричат "подчинени сървъри на Kerberos". Всички подчинени сървъри синхронизират своите бази данни от главния Kerberos сървър.

Терминът "Керберизиран сървър за приложения" обикновено се отнася за Керберизирани програми, с които клиентите комуникират, използвайки билети Kerberos за удостоверяване. Например, Kerberos telnet сървърът е пример за Kerberized application server . Докато терминът "Керберизирани приложения" се използва за препратка към клиентската страна на Керберизиран сървър за приложения , Например клиентът Kerberos telnet е пример за Керберизирани приложения

Сигурността на протокола зависи до голяма степен от:

Участниците поддържат слабо синхронизирано време.
Краткотрайна декларация за автентичност: билетите на Kerberos.

Опростено описание на протокола

Ще се използват следните съкращения:

· AS = Сървър за удостоверяване

· TGS = Сървър за издаване на билети

· SS или Server = Сървър за услуги (Потребител на сървър, който изисква услугата му, например сървър за печат, файлов сървър и т.н.)

· TGT = Ticket Granting Ticket (билет на Kerberos за TGS. Подготвя се от спомагателната система, след което се използва за разговор с TGS).

Накратко, клиентът се удостоверява пред спомагателната система, като използва дългосрочна споделена тайна, и получава билет от спомагателната система. По-късно клиентът може да използва този билет, за да получи допълнителни билети за SS, като използва същата споделена тайна. Тези билети могат да се използват за доказване на автентичността на SS.

По-подробно за протокола

Стъпки за влизане в системата, базирани на потребителския клиент:

Потребителят въвежда потребителско име и парола на клиентската машина.
Клиентът извършва еднопосочна функция (най-често хеш функция) върху въведената парола и тя се превръща в тайния ключ на клиента/потребителя.

Стъпки за удостоверяване на клиента:

Клиентът изпраща съобщение с ясен текст до спомагателната система, в което иска услуги от името на потребителя.
Пример за съобщение: "User XYZ would like to request services".
Забележка: На спомагателната система не се изпращат нито секретният ключ, нито паролата.
Спомагателната система проверява дали клиентът е в нейната база данни. Ако е така, спомагателната система изпраща на клиента следните две съобщения:

Съобщение А: Ключ на сесията на клиента/TGS, криптиран с помощта на секретния ключ на клиента/потребителя.
Съобщение Б: TGT (който включва идентификатора на клиента, мрежовия адрес на клиента, срока на валидност на билета и ключа на сесията на клиента/ТГС), криптиран с помощта на секретния ключ на ТГС.

След като клиентът получи съобщенията A и B, той декриптира съобщението A, за да получи ключа на сесията на клиента и TGS. Този сесиен ключ се използва за по-нататъшна комуникация с TGS. В този момент клиентът разполага с достатъчно информация, за да се удостовери пред TGS.
Забележка: Клиентът не може да декриптира съобщение B, тъй като то е криптирано с помощта на секретния ключ на TGS.

Стъпки за оторизация на услугата за клиенти:

При заявяване на услуги клиентът изпраща следните две съобщения до TGS:

Съобщение В: Състои се от TGT от съобщение В и идентификатора на заявената услуга.
Съобщение D: автентификатор (който се състои от идентификатора на клиента и времевия печат), криптиран с помощта на ключа на сесията на клиента и TGS.

След като получи съобщенията C и D, TGS извлича съобщение B от съобщение C. Тя декриптира съобщение B, като използва секретния ключ на TGS. Така се получава ключът на сесията на клиента/ТНС. Използвайки този ключ, TGS декриптира съобщение D (автентификатор) и изпраща следните две съобщения на клиента:

Съобщение E: билет от клиент към сървър (който включва идентификатор на клиента, мрежов адрес на клиента, период на валидност и ключ на сесията клиент/сървър), криптиран с помощта на секретния ключ SS.
Съобщение F: Ключ на сесията на клиента/сървъра, криптиран с ключа на сесията на клиента/TGS.

Стъпки за заявка за обслужване на клиенти:

При получаване на съобщенията E и F от TGS клиентът разполага с достатъчно информация, за да се удостовери пред SS. Клиентът се свързва с SS и изпраща следните две съобщения:

Съобщение E: от предишната стъпка (билетът от клиента към сървъра, криптиран с помощта на секретния ключ SS).
Съобщение G: нов автентификатор, който включва идентификатора на клиента, времевия печат и е криптиран с помощта на ключа на сесията на клиента и сървъра.

SS декриптира билета, като използва своя секретен ключ, за да получи ключа на сесията клиент/сървър. Използвайки ключа на сесията, SS декриптира автентификатора и изпраща следното съобщение на клиента, за да потвърди истинската си самоличност и готовността си да обслужва клиента:

Съобщение H: времевата марка, намерена в автентификатора на клиента, плюс 1, криптирана с помощта на ключа за сесии на клиента/сървъра.

Клиентът декриптира потвърждението, като използва ключа на сесията клиент/сървър, и проверява дали времевият печат е правилно актуализиран. Ако това е така, клиентът може да се довери на сървъра и да започне да издава заявки за услуги към сървъра.
Сървърът предоставя заявените услуги на клиента.

Недостатъци

Единична точка на отказ: Изисква непрекъсната наличност на централен сървър. Когато сървърът на Kerberos не работи, никой не може да влезе в системата. Този проблем може да бъде решен чрез използване на няколко Kerberos сървъра и механизми за аварийно удостоверяване.
Kerberos изисква часовниците на всички участващи хостове да бъдат синхронизирани. Билетите имат период на наличност и ако часовникът на хоста не е синхронизиран с часовника на Kerberos сървъра, удостоверяването ще се провали. Конфигурацията по подразбиране изисква часовете на часовниците да са с разлика не повече от 10 минути. На практика обикновено се използва протоколът за мрежово време (NTP), за да се синхронизират всички хостове.
Протоколът за администриране не е стандартизиран и се различава в различните реализации на сървъра. Промените в паролите са описани в RFC 3244.
Тъй като тайните ключове на всички потребители се съхраняват на централния сървър, компрометирането на този сървър ще доведе до компрометиране на тайните ключове на всички потребители.
Компрометиран клиент ще компрометира паролата на потребителя.

Свързани страници

Управление на идентичността
Протокол за защитена отдалечена парола (SRP)
Интерфейс на приложната програма за общи услуги за сигурност (GSS-API)

Въпроси и отговори

В: Какво представлява Kerberos?

О: Kerberos е протокол за удостоверяване в компютърна мрежа, който позволява на хората, общуващи в несигурна мрежа, да докажат по сигурен начин самоличността си един на друг.

В: Кой е създал Kerberos?

О: Създателите на Kerberos са се стремили основно към модел клиент-сървър и са били от Масачузетския технологичен институт (MIT).

Въпрос: Как Kerberos осигурява взаимна автентификация?

О.: Чрез използването на криптографски споделени тайни, както потребителят, така и сървърът могат да проверяват самоличността си.

Въпрос: Как Kerberos се защитава от шпионски атаки и атаки за преиграване?

О: Чрез криптиране на съобщенията, изпращани между потребителите, той предотвратява тяхното четене или модифициране от трети страни.

В: Какъв тип криптография използва Kerberos?

О: Той използва криптография със симетричен ключ, която изисква център за разпределение на ключове.

В: Поддържа ли Kerberos криптография с публичен ключ?

О: Да, разширенията на протокола могат да осигурят използването ѝ по време на определени фази на удостоверяване.