Kerberos (протокол)

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

Kerberos () - это компьютерная сеть аутентификация протокол, который работает на основе билетов на разрешить узлам обмениваться данными по незащищенной сети для безопасного подтверждения своей личности друг другу. Протокол был назван в честь персонажа Кербер (или Цербер ) из греческой мифологии, свирепого трехголового сторожевого пса из Аида. Его разработчики ориентировали его в первую очередь на модель клиент-сервер, и он обеспечивает взаимную аутентификацию - и пользователь, и сервер проверяют идентичность друг друга. Сообщения протокола Kerberos защищены от перехвата и атак с повторным воспроизведением.

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

Содержание

  • 1 История и разработка
  • 2 Microsoft Windows
  • 3 Unix и другие операционные системы
  • 4 Протокол
    • 4.1 Описание
      • 4.1.1 Пользовательский вход на основе клиента
      • 4.1.2 Аутентификация клиента
      • 4.1.3 Авторизация службы клиента
      • 4.1.4 Запрос службы клиента
  • 5 Недостатки и ограничения
  • 6 Уязвимости
  • 7 См. Также
  • 8 Ссылки
  • 9 Дополнительная литература
  • 10 Внешние ссылки

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

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

Kerberos версии 4 изначально был разработан и. Опубликованная в конце 1980-х, версия 4 была также нацелена на Project Athena.

. Нойман и Джон Коль опубликовали версию 5 в 1993 году с целью преодоления существующих ограничений и проблем безопасности. Версия 5 появилась как RFC 1510, а 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 году Internet Engineering Task Force (IETF) Рабочая группа Kerberos обновила спецификации. Включены обновления:

  • спецификации шифрования и контрольной суммы (RFC 3961 ).
  • Advanced Encryption Standard (AES) Encryption for Kerberos 5 (RFC 3962 ).
  • Новая редакция спецификации Kerberos V5) » Служба сетевой аутентификации Kerberos (V5) »(RFC 4120 ). Эта версия отменяет RFC 1510, разъясняет аспекты протокола и предполагаемое использование в более подробном и ясном объяснении.
  • Новая редакция спецификации Generic Security Services Application Program Interface (GSS-API) «Механизм Generic Security Services Application Program Interface (GSS-API) Kerberos версии 5: версия 2» ( RFC 4121 ).

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

Microsoft Windows

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

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

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

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

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

Многие Unix-подобные операционные системы, включая FreeBSD, OpenBSD, Apple macOS, Red Hat Enterprise Linux, Oracle Solaris, 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), и отправляет клиенту следующие два сообщения:
    • Сообщение A: клиент / сеансовый ключ TGS, зашифрованный с использованием секретного ключа клиента / пользователя.
    • Сообщение B: Ticket-Granting-Ticket (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 : новый Authenticator, который включает идентификатор клиента, временную метку и зашифрован с использованием сеансового ключа клиент / сервер.
  2. SS расшифровывает билет (сообщение E), используя свой собственный секретный ключ для получения сеансового ключа клиент / сервер. Используя ключ сеанса, SS дешифрует аутентификатор и сравнивает идентификатор клиента из сообщений E и G, если они совпадают, сервер отправляет клиенту следующее сообщение, чтобы подтвердить его истинную идентичность и готовность обслуживать клиента:
    • Сообщение H : метка времени, найденная в аутентификаторе клиента (плюс 1 в версии 4, но не обязательно в версии 5), зашифрованная с помощью сеансового ключа клиент / сервер.
  3. Клиент расшифровывает подтверждение (сообщение H) с помощью сеансового ключа клиент / сервер и проверяет правильность отметки времени. Если это так, то клиент может доверять серверу и может начать посылать серверу запросы на обслуживание.
  4. Сервер предоставляет запрашиваемые услуги клиенту.

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

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

Уязвимости

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

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

См. Также

  • Портал бесплатного программного обеспечения с открытым исходным кодом

Ссылки

Общие
RFC
  • RFC 1510 Служба сетевой аутентификации Kerberos (V5) [Устарело]
  • RFC 1964 Механизм GSS-API Kerberos версии 5
  • RFC 3961 Шифрование и контрольная сумма Технические характеристики Kerberos 5
  • RFC 3962 Расширенный стандарт шифрования (AES) Шифрование для Kerberos 5
  • RFC 4120 Служба сетевой аутентификации Kerberos (V5) [Текущая]
  • RFC 4121 Механизм прикладного программного интерфейса Generic Security Service (GSS-API) Kerberos версии 5: версия 2
  • RFC 4537 Kerberos Cryptosystem Negotiation Extension
  • RFC 4556 Криптография открытого ключа для начальной аутентификации в Kerberos (PKINIT)
  • RFC 4557 Online Ce Протокол состояния rtificate (OCSP) Поддержка криптографии с открытым ключом для начальной аутентификации в Kerberos (PKINIT)
  • RFC 4757 Типы шифрования RC4-HMAC Kerberos, используемые Microsoft Windows [Устарело]
  • RFC 5021 Расширенное Центр распространения ключей Kerberos версии 5 (KDC) обменивается по 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 Ser Vice 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

Дополнительная литература

Внешние ссылки

На Викискладе есть носители, связанные с Kerberos.
Последняя правка сделана 2021-05-25 04:24:12
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте