Kerberos

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

MIT разработал Kerberos для защиты сетевых услуг, предоставляемых проектом Athena. Протокол был назван в честь греческого мифологического персонажа Kerberos (или Cerberus), известного в греческой мифологии как чудовищный трехголовый сторожевой пёс Аида. Существует несколько версий протокола; версии 1-3 использовались только внутри MIT.

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

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

Несколько компаний использовали Kerberos версии 5 в коммерческом программном обеспечении, в том числе:

·         Microsoft Windows 2000 и более поздние версии используют Kerberos в качестве метода аутентификации по умолчанию.
Некоторые дополнения Microsoft к набору протоколов Kerberos описаны в RFC 3244 "Microsoft Windows 2000 Kerberos изменяет пароль и устанавливает протоколы паролей".
RFC 4757 документирует использование шифра RC4
компанией Microsoft.
Хотя Microsoft использует протокол Kerberos, она не использует программное обеспечение MIT.[1].

·         Apple Mac OS X также использует Kerberos как в клиентской, так и в серверной версиях.

·         Red Hat Linux версии 4 и более поздней версии использует Kerberos как в клиентской, так и в серверной версиях.

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

·         "Спецификации шифрования и контрольной суммы" (RFC 3961),

·         "Расширенныйстандартшифрования (AES) для Kerberos 5" (RFC 3962),

·         Новая редакция спецификации Kerberos Version 5 "Служба сетевой аутентификации Kerberos Network Authentication Service (V5)" (RFC 4120). Эта версия устаревает RFC 1510, уточняет аспекты протокола и предполагаемого использования в более подробном и понятном объяснении,

·         Новая редакция спецификации GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API)" Механизм: Версия 2". (RFC 4121).

В 2007 году MIT создал Консорциум "Керберос" для продолжения развития.

Протокол

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

База данных Kerberos: Центр распределения ключей (KDC) поддерживает базу данных секретных ключей; каждая сущность в сети - будь то клиент или сервер - делится секретным ключом, известным только себе и KDC. Знание этого ключа служит для подтверждения личности каждого субъекта. Для связи между двумя организациями KDC генерирует ключ сеанса, который они могут использовать для защиты своих коммуникаций.

Термин "сервер Kerberos" обычно относится к KDC. В целях обеспечения надежности можно иметь резервные KDC. Их называют "вторичные серверы Kerberos". Все ведомые устройства синхронизируют свои базы данных с главного сервера Kerberos.

Термин "Керберизованный сервер приложений" обычно относится к Керберизованным программам, с которыми клиенты взаимодействуют, используя билеты Kerberos для аутентификации. Например, телнет-сервер Kerberos является примером Керберизованного сервера приложений . Хотя термин "Kerberized applications" используется для обозначения клиентской стороны сервера приложений Kerberized, например, телнет-клиент Kerberos является примером Kerberized application

Безопасность протокола во многом зависит от него:

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

Упрощенное описание протокола

Будут использоваться следующие сокращения:

·         AS = Сервер аутентификации

·         TGS = сервер выдачи билетов

·         SS или Сервер = Сервер обслуживания (пользователь сервера, запрашивающий свою услугу, например, сервер печати, файловый сервер и т.д...).

·         TGT = Предоставление билета (билет на TGS на керберос. Готовится AS, затем используется для разговора с TGS).

Вкратце, клиент аутентифицируется в АО, используя долгосрочный общий секрет, и получает от АО билет. Позже клиент может использовать этот тикет, чтобы получить дополнительные тикеты на SS, используя тот же общий секрет. Эти билеты можно использовать, чтобы доказать подлинность СС.

Протокол более подробно

Шаги входа в систему на основе клиента:

1. Пользователь вводит имя пользователя и пароль на компьютере клиента.
2. Клиент выполняет одностороннюю функцию (в основном хэш-функцию) по введенному паролю, и это становится секретным ключом клиента/пользователя.

Шаги аутентификации клиента:

1. Клиент от имени пользователя посылает АП чистое текстовое сообщение с запросом на услуги.
   Образец сообщения: "Пользователь XYZ хотел бы запросить услуги".
   Примечание: AS не отправляет ни секретный ключ, ни пароль.
2. AS проверяет, находится ли клиент в своей базе данных. Если это так, то AS отправляет клиенту следующие два сообщения:
• Сообщение А: Ключ сеанса Client/TGS зашифрован с помощью секретного ключа клиента/пользователя.
• Сообщение B: TGT (которое включает в себя идентификатор клиента, сетевой адрес клиента, срок действия билета и Client/TGS Session Key), зашифрованное с помощью секретного ключа TGS.
3. Как только клиент получает сообщения A и B, он расшифровывает сообщение A для получения ключа сеанса Client/TGS. Этот сеансовый ключ используется для дальнейших коммуникаций с TGS. На данный момент клиент имеет достаточно информации для аутентификации в TGS.
   Примечание: Клиент не может расшифровать сообщение B, поскольку оно зашифровано с помощью секретного ключа TGS.

Шаги авторизации обслуживания клиентов:

1. При запросе услуг клиент отправляет следующие два сообщения в TGS:
• Сообщение C: состоит из TGT из сообщения B и идентификатора запрашиваемой услуги.
• Сообщение D: Аутентификатор (который состоит из идентификатора клиента и метки времени), зашифрованный с помощью Client/TGS Session Key.
2. При получении сообщений C и D TGS извлекает сообщение B из сообщения C. Он расшифровывает сообщение B с помощью секретного ключа TGS. Это дает ему ключ сеанса клиент/Т"". Используя этот ключ, TGS расшифровывает сообщение D (Authenticator) и отправляет следующие два сообщения клиенту:
• Сообщение E: Тикет "клиент-сервер" (включающий в себя идентификатор клиента, сетевой адрес клиента, срок действия и сеансовый ключ "клиент-сервер"), зашифрованный с помощью секретного ключа SS.
• Сообщение F: Ключ сеанса клиент/сервер, зашифрованный с помощью ключа сеанса клиент/сервер.

Шаги запроса клиентского сервиса:

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

Недостатки

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

Связанные страницы

• Управление идентификацией
• Защищенный протокол удаленного ввода пароля (SRP)
• Общий программный интерфейс прикладных программ служб безопасности (GSS-API)