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 е пример за Керберизирани приложения

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Клиентът изпраща съобщение с ясен текст до спомагателната система, в което иска услуги от името на потребителя.
   Пример за съобщение: "User XYZ would like to request services".
   Забележка: На спомагателната система не се изпращат нито секретният ключ, нито паролата.
2. Спомагателната система проверява дали клиентът е в нейната база данни. Ако е така, спомагателната система изпраща на клиента следните две съобщения:
• Съобщение А: Ключ на сесията на клиента/TGS, криптиран с помощта на секретния ключ на клиента/потребителя.
• Съобщение Б: TGT (който включва идентификатора на клиента, мрежовия адрес на клиента, срока на валидност на билета и ключа на сесията на клиента/ТГС), криптиран с помощта на секретния ключ на ТГС.
3. След като клиентът получи съобщенията A и B, той декриптира съобщението A, за да получи ключа на сесията на клиента и TGS. Този сесиен ключ се използва за по-нататъшна комуникация с TGS. В този момент клиентът разполага с достатъчно информация, за да се удостовери пред TGS.
   Забележка: Клиентът не може да декриптира съобщение B, тъй като то е криптирано с помощта на секретния ключ на TGS.

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

1. При заявяване на услуги клиентът изпраща следните две съобщения до TGS:
• Съобщение В: Състои се от TGT от съобщение В и идентификатора на заявената услуга.
• Съобщение D: автентификатор (който се състои от идентификатора на клиента и времевия печат), криптиран с помощта на ключа на сесията на клиента и TGS.
2. След като получи съобщенията C и D, TGS извлича съобщение B от съобщение C. Тя декриптира съобщение B, като използва секретния ключ на TGS. Така се получава ключът на сесията на клиента/ТНС. Използвайки този ключ, TGS декриптира съобщение D (автентификатор) и изпраща следните две съобщения на клиента:
• Съобщение E: билет от клиент към сървър (който включва идентификатор на клиента, мрежов адрес на клиента, период на валидност и ключ на сесията клиент/сървър), криптиран с помощта на секретния ключ SS.
• Съобщение F: Ключ на сесията на клиента/сървъра, криптиран с ключа на сесията на клиента/TGS.

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

1. При получаване на съобщенията E и F от TGS клиентът разполага с достатъчно информация, за да се удостовери пред SS. Клиентът се свързва с SS и изпраща следните две съобщения:
• Съобщение E: от предишната стъпка (билетът от клиента към сървъра, криптиран с помощта на секретния ключ SS).
• Съобщение G: нов автентификатор, който включва идентификатора на клиента, времевия печат и е криптиран с помощта на ключа на сесията на клиента и сървъра.
2. SS декриптира билета, като използва своя секретен ключ, за да получи ключа на сесията клиент/сървър. Използвайки ключа на сесията, SS декриптира автентификатора и изпраща следното съобщение на клиента, за да потвърди истинската си самоличност и готовността си да обслужва клиента:
• Съобщение H: времевата марка, намерена в автентификатора на клиента, плюс 1, криптирана с помощта на ключа за сесии на клиента/сървъра.
3. Клиентът декриптира потвърждението, като използва ключа на сесията клиент/сървър, и проверява дали времевият печат е правилно актуализиран. Ако това е така, клиентът може да се довери на сървъра и да започне да издава заявки за услуги към сървъра.
4. Сървърът предоставя заявените услуги на клиента.

Недостатъци

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

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

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