Kerberos (протокол) - Kerberos (protocol)

Эта статья о протоколе. Для использования в других целях см. Kerberos.
Kerberos
Стабильный выпуск
krb5-1.18.2 / 21 мая 2020 г.; 6 месяцев назад (2020-05-21)
Написано вC
Операционная системакросс-платформенный
Интернет сайтсеть.mit.edu/ kerberos/

Kerberos (/ˈkɜːrбərɒs/) это компьютерная сеть аутентификация протокол что работает на основе Билеты позволять узлы обмениваться данными по незащищенной сети, чтобы безопасно подтвердить свою личность друг другу. Протокол был назван в честь персонажа Kerberos (или же Цербер ) из Греческая мифология, свирепый трехголовый сторожевой пес Аид. Его дизайнеры ориентировали его прежде всего на клиент – сервер модель и она обеспечивает взаимная аутентификация - и пользователь, и сервер проверяют личность друг друга. Сообщения протокола Kerberos защищены от подслушивание и повторные атаки.

Kerberos основан на криптография с симметричным ключом и требует доверенная третья сторона, и при желании может использовать криптография с открытым ключом на определенных этапах аутентификации.[1] Kerberos по умолчанию использует UDP-порт 88.

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

Массачусетский Институт Технологий (MIT) разработал протокол Kerberos для защиты сетевых служб, предоставляемых Проект Афина.[2][3] Протокол основан на более раннем Протокол симметричного ключа Нидхема – Шредера. Существует несколько версий протокола; версии 1–3 возникли только внутри MIT.

Kerberos версии 4 был первоначально разработан Стив Миллер и Клиффорд Ньюман.[4] Версия 4, опубликованная в конце 1980-х, также была нацелена на Проект Афина.

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

Власти в Соединенные Штаты классифицировал Kerberos как «Вспомогательное военное оборудование» в Списке боеприпасов США и запретил его экспорт потому что он использовал Стандарт шифрования данных (DES) алгоритм шифрования (с 56-битными ключами). Реализация Kerberos 4, разработанная в Королевский технологический институт в Швеция под названием KTH-KRB (переименованный в Heimdal в версии 5) сделал систему доступной за пределами США до того, как США изменили ее экспорт криптографии нормативно-правовые акты (около 2000). Шведская реализация была основана на ограниченной версии под названием eBones. eBones был основан на экспортированной версии MIT Bones (лишенной как функций шифрования, так и вызовов к ним) на основе версии Kerberos 4 patch-level 9.

В 2005 г. Инженерная группа Интернета (IETF) Рабочая группа Kerberos обновила спецификации. Обновления включены:

MIT делает реализацию Kerberos бесплатно доступной с разрешениями авторских прав, аналогичными тем, которые используются для BSD. В 2007 году Массачусетский технологический институт сформировал консорциум Kerberos, чтобы способствовать дальнейшему развитию. Спонсоры-учредители включают таких поставщиков, как Oracle, Apple Inc., Google, Microsoft, Centrify Corporation и TeamF1 Inc., и академические учреждения, такие как Королевский технологический институт в Швеции - Стэнфордский университет, Массачусетский технологический институт и такие поставщики, как CyberSafe, предлагают коммерчески поддерживаемые версии.

Майкрософт Виндоус

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

Kerberos используется в качестве предпочтительного метода аутентификации: как правило, присоединение клиента к домену Windows означает включение Kerberos в качестве протокола по умолчанию для аутентификации от этого клиента к службам в домене Windows и во всех доменах с доверительными отношениями с этим доменом.[5]

Напротив, когда клиент или сервер или оба не присоединены к домену (или не являются частью той же среды доверенного домена), Windows вместо этого будет использовать NTLM для аутентификации между клиентом и сервером.[5]

Веб-приложения интрасети могут применять Kerberos в качестве метода проверки подлинности для клиентов, присоединенных к домену, с помощью API-интерфейсов, предоставляемых в соответствии с SSPI.

Unix и другие операционные системы

Многие Unix-подобные операционные системы, включая FreeBSD, OpenBSD, Apple macOS, Red Hat Enterprise Linux, Oracle с Солярис, IBM AIX, HP-UX и другие, включают программное обеспечение для проверки подлинности Kerberos пользователей или служб. Разнообразие операционных систем, отличных от Unix, таких как z / OS, IBM i и OpenVMS также имеют поддержку Kerberos. Встроенная реализация протокола аутентификации Kerberos V для клиентских агентов и сетевых служб, работающих на встроенных платформах, также доступна у компаний.

Протокол

Описание

Клиент аутентифицируется на Сервер аутентификации (AS) который перенаправляет имя пользователя на центр распределения ключей (KDC). KDC выпускает билет для выдачи билетов (TGT), который имеет отметку времени и шифрует его с помощью билетная касса (TGS) секретный ключ и возвращает зашифрованный результат на рабочую станцию ​​пользователя. Это делается нечасто, обычно при входе пользователя в систему; Срок действия TGT истекает в какой-то момент, хотя он может быть прозрачно обновлен менеджером сеансов пользователя, когда они вошли в систему.

Когда клиенту необходимо связаться со службой на другом узле («принципал» на языке Kerberos), клиент отправляет TGT в TGS, который обычно использует тот же хост, что и KDC. Сервис должен быть уже зарегистрирован в TGS с Имя участника службы (SPN). Клиент использует SPN для запроса доступа к этой службе. После проверки того, что TGT действителен и что пользователю разрешен доступ к запрошенной службе, TGS выдает клиенту билет и ключи сеанса. Затем клиент отправляет билет в сервисный сервер (SS) вместе с запросом на обслуживание.

Kerberos переговоры

Протокол подробно описан ниже.

Пользовательский вход на основе клиента

  1. Пользователь вводит имя пользователя и пароль на клиентские машины. Другие механизмы доступа, такие как pkinit (RFC 4556 ) позволяют использовать открытые ключи вместо пароля.
  2. Клиент преобразует пароль в ключ симметричного шифра. При этом используется либо встроенное планирование клавиш, либо односторонний хеш, в зависимости от используемого набора шифров.

Проверка подлинности клиента

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

Авторизация клиентского сервиса

  1. При запросе услуг клиент отправляет в TGS следующие сообщения:
    • Сообщение C: состоит из сообщения B (зашифрованный TGT с использованием секретного ключа TGS) и идентификатора запрошенной услуги.
    • Сообщение D: аутентификатор (который состоит из идентификатора клиента и отметки времени), зашифрованный с использованием Ключ сеанса клиента / TGS.
  2. После получения сообщений C и D TGS извлекает сообщение B из сообщения C. Он расшифровывает сообщение B, используя секретный ключ TGS. Это дает ему «ключ сеанса клиента / TGS» и идентификатор клиента (оба находятся в TGT). Используя этот «ключ сеанса клиента / TGS», TGS расшифровывает сообщение D (аутентификатор) и сравнивает идентификаторы клиентов из сообщений B и D; если они совпадают, сервер отправляет клиенту следующие два сообщения:
    • Сообщение E: Билет клиент-сервер (который включает идентификатор клиента, сетевой адрес клиента, срок действия и Ключ сеанса клиент / сервер) зашифрованы с помощью секретного ключа сервиса.
    • Сообщение F: Ключ сеанса клиент / сервер зашифрован с помощью Ключ сеанса клиента / TGS.

Запрос на обслуживание клиентов

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

Недостатки и ограничения

  • Kerberos предъявляет строгие требования ко времени, что означает, что часы задействованных хостов должны быть синхронизированы в установленных пределах. У билетов есть период доступности, и если часы хоста не синхронизированы с часами сервера Kerberos, аутентификация не удастся. Конфигурация по умолчанию разрешать требует, чтобы время на часах было не более пяти минут. На практике Сетевой протокол времени Демоны обычно используются для синхронизации часов хоста. Обратите внимание, что некоторые серверы (реализация Microsoft является одним из них) могут возвращать результат KRB_AP_ERR_SKEW, содержащий зашифрованное время сервера, в случае, если оба тактовых генератора имеют смещение, превышающее настроенное максимальное значение. В этом случае клиент может повторить попытку, вычислив время, используя предоставленное серверное время, чтобы найти смещение. Это поведение задокументировано в RFC 4430.
  • Протокол администрирования не стандартизирован и различается в зависимости от реализации сервера. Изменения пароля описаны в RFC 3244.
  • В случае внедрения симметричной криптографии (Kerberos может работать с использованием симметричной или асимметричной (с открытым ключом) криптографии), поскольку все проверки подлинности контролируются централизованным центр распределения ключей (KDC), компрометация этой инфраструктуры аутентификации позволит злоумышленнику выдать себя за любого пользователя.
  • Каждой сетевой службе, для которой требуется другое имя хоста, потребуется собственный набор ключей Kerberos. Это усложняет виртуальный хостинг и кластеры.
  • Kerberos требует, чтобы учетные записи пользователей и службы имели доверительные отношения с сервером токенов Kerberos.
  • Требуемое доверие клиентов затрудняет создание поэтапных сред (например, отдельных доменов для тестовой среды, предпроизводственной среды и производственной среды): необходимо создать либо доверительные отношения между доменами, которые предотвращают строгое разделение доменов среды, либо дополнительные клиенты-клиенты предусмотрены для каждой среды.

Уязвимости

В Стандарт шифрования данных Шифр (DES) можно использовать в сочетании с Kerberos, но он больше не является стандартом Интернета, потому что он слаб.[8] Уязвимости безопасности существуют во многих устаревших продуктах, которые реализуют Kerberos, поскольку они не были обновлены для использования более новых шифров, таких как AES вместо DES.

В ноябре 2014 года Microsoft выпустила исправление (MS14-068) для исправления уязвимости, которую можно использовать в реализации Windows Центра распространения ключей Kerberos (KDC).[9] Уязвимость якобы позволяет пользователям «повышать» (и злоупотреблять) своими привилегиями до уровня домена.

Смотрите также

Рекомендации

  1. ^ RFC 4556, Абстрактные
  2. ^ Дженнифер Г. Штайнер; Дэниел Э. Гир-младший (21 июля 1988 г.). «Сетевые службы в среде Афины». Материалы зимней конференции Usenix 1988 г.. CiteSeerX  10.1.1.31.8727.
  3. ^ Элизабет Д. Цвикки; Саймон Купер; Д. Брент (26 июня 2000 г.). Создание Интернет-брандмауэров: Интернет и веб-безопасность. О'Рейли.
  4. ^ Дженнифер Г. Штайнер; Клиффорд Нойман; Джеффри И. Шиллер. «Kerberos: служба аутентификации для открытых сетевых систем."" (PDF). S2CID  222257682. Архивировано из оригинал (PDF) на 2019-05-07. Получено 2019-05-07. Цитировать журнал требует | журнал = (помощь)
  5. ^ а б c "Что такое проверка подлинности Kerberos?". Microsoft TechNet. В архиве из оригинала от 20.12.2016.
  6. ^ C., Neuman; J., Kohl. «Служба сетевой аутентификации Kerberos (V5)». В архиве из оригинала от 21.08.2016.
  7. ^ Клиффорд, Нойман; Сэм, Хартман; Том, Ю; Кеннет, Реберн. «Служба сетевой аутентификации Kerberos (V5)». В архиве из оригинала от 21.08.2016.
  8. ^ Том, Ю; С любовью, Астранд. «Отказ от поддержки DES, RC4-HMAC-EXP и других слабых криптографических алгоритмов в Kerberos». В архиве из оригинала от 27.10.2015.
  9. ^ Зельцер, Ларри. «Появляются подробности об уязвимости Windows Kerberos - ZDNet». В архиве из оригинала 21.11.2014.
Общий
RFC
  • RFC 1510 Служба сетевой аутентификации Kerberos (V5) [Устарело]
  • RFC 1964 Механизм GSS-API Kerberos версии 5
  • RFC 3961 Спецификации шифрования и контрольной суммы для Kerberos 5
  • RFC 3962 Шифрование Advanced Encryption Standard (AES) для Kerberos 5
  • RFC 4120 Служба сетевой аутентификации Kerberos (V5) [Текущая]
  • RFC 4121 Механизм прикладного программного интерфейса Generic Security Service (GSS-API) Kerberos версии 5: версия 2
  • RFC 4537 Расширение согласования криптосистемы Kerberos
  • RFC 4556 Криптография с открытым ключом для начальной аутентификации в Kerberos (PKINIT)
  • RFC 4557 Протокол состояния онлайн-сертификатов (OCSP) Поддержка криптографии с открытым ключом для начальной аутентификации в Kerberos (PKINIT)
  • RFC 4757 Типы шифрования RC4-HMAC Kerberos, используемые Microsoft Windows [Устарело]
  • RFC 5021 Центр распространения ключей (KDC) с расширенным протоколом Kerberos версии 5 по TCP
  • RFC 5349 Поддержка криптографии на эллиптических кривых (ECC) для криптографии с открытым ключом для начальной аутентификации в Kerberos (PKINIT)
  • RFC 5868 Постановка проблемы межсферной работы Kerberos
  • RFC 5896 Общий программный интерфейс приложения службы безопасности (GSS-API): делегирование, если одобрено политикой
  • RFC 6111 Дополнительные ограничения именования Kerberos
  • RFC 6112 Поддержка анонимности для Kerberos
  • RFC 6113 Обобщенная структура для предварительной проверки подлинности Kerberos
  • RFC 6251 Использование Kerberos версии 5 по протоколу безопасности транспортного уровня (TLS)
  • RFC 6448 Незашифрованная форма сообщения Kerberos 5 KRB-CRED
  • RFC 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Гибкость хэша привязки канала
  • RFC 6560 Одноразовый пароль (OTP) Предварительная аутентификация
  • RFC 6649 Отказ от поддержки DES, RC4-HMAC-EXP и других слабых криптографических алгоритмов в Kerberos
  • RFC 6784 Параметры Kerberos для DHCPv6
  • RFC 6803 Шифрование Camellia для Kerberos 5
  • RFC 6806 Канонизация основного имени Kerberos и переходы между областями
  • RFC 6880 Информационная модель для Kerberos версии 5

дальнейшее чтение

  1. «Комментарий Novell Inc к предлагаемому мировому соглашению между Microsoft и Министерством юстиции в соответствии с Законом Танни». Гражданский иск № 98-1232 (CKK): Соединенные Штаты Америки против Microsoft Corporation. Департамент правосудия. 29 января 2002 г.. Получено 15 августа 2012.
  2. Брайант, Билл (февраль 1988 г.). «Разработка системы аутентификации: диалог в четырех сценах». Юмористическая пьеса о том, как эволюционировал дизайн Kerberos. Массачусетский технологический институт.
  3. Хорнштейн, Кен (18 августа 2000 г.). «Вопросы и ответы по Kerberos, v2.0». Секретарь военно-морского флота. Архивировано из оригинал 3 декабря 2002 г.. Получено 15 августа 2012.

внешняя ссылка