Kerberos (протокол)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:31, 8 июня 2016.

Kerberos — сетевой протокол аутентификации, основанный на модели, представленной Нидхемом и Шредером[1], который был разработан для обеспечения надежной аутентификации для клиент-серверных приложений с помощью использования симметричного шифрования. Свободная реализация этого протокола разработана Массачусетским технологическим институтом. Kerberos так же используется во многих коммерческих продуктах.[2]

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

Клиент проходит проверку подлинности на сервере аутентификации , который направляет пользователя к центру распределения ключей . выдает мандат для получения мандата , зависящий от текущего времени, шифрует его с помощью пароля пользователя и возвращает шифрованный результат пользователю. Это делается редко, обычно при входе пользователя в систему или когда истекает текущий .[3]

Когда клиенту необходимо обмениваться данными с другим узлом ("основной" в терминах Kerberos) клиент посылает в сервер выдачи мандатов , который обычно размещен на том же узле, что и один и . После проверки при условии, что он является действительным и пользователю разрешен доступ к запрашиваемой услуге, выдает мандат и сеансовые ключи, которые возвращаются клиенту. Затем клиент посылает мандат на сервер службы вместе с его запросом на обслуживание.

Рисунок 1. Схема работы Kerberos 5

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

Вход пользователя в систему

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

Аутентификация клиента

  1. Клиент посылает сообщение c идентификатором пользователя на сервер аутентификации с запросом услуги от имени пользователя.[прим. 1] генерирует секретный ключ путем хэширования пароля пользователя, найденного в базе данных.
  2. проверяет, существует ли клиент в базе данных. Если да, то посылает обратно следующие два сообщения клиенту:
    • Сообщение A: Сессионный ключ Клиент/, зашифрованный с использованием секретного ключа клиента / пользователя.
    • Сообщение B: Мандат для получения мандата (, который включает в себя идентификатор клиента, сетевой адрес клиента, срок действия мандата, и сессионный ключ Клиент/), зашифрованный с использованием секретного ключа .
  3. После того, как клиент принимает сообщения А и В, он пытается расшифровать сообщение A с помощью секретного ключа, cгенерированного из пароля, введенного пользователем. Если пользователь ввел пароль, который не совпадает с паролем в базе данных , секретный ключ клиента будет отличаться и, следовательно, клиент не сможет расшифровать сообщение A. С действительным паролем и секретным ключом клиент расшифровывает сообщение A, чтобы получить сессионный ключ Клиент/. Этот сессионный ключ используется для дальнейших коммуникаций с . [прим. 2] В этот момент у пользователя достаточно данных, чтобы авторизоваться на .

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

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

Запрос сервиса клиентом

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

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

  1. Единая точка отказа: требуется постоянное наличие центрального сервера. Когда сервер Kerberos падает, новые пользователи не могут войти. Это может быть устранено с помощью нескольких серверов Kerberos и резервных механизмов аутентификации.
  2. Kerberos имеет строгие требования к времени, что означает, что часы участников должны быть синхронизированы в заданных пределах. Мандаты имеют время жизни и, если часы клиента не синхронизированы с часами сервера Kerberos, аутентификация не будет выполнена. Конфигурация по умолчанию требует, чтобы часы расходились не боле чем на пять минут друг от друга. На практике, как правило, используются демоны Network Time Protocol для синхронизации часов у клиентов.
  3. Протокол администрирования не стандартизирован и зависит от конкретной реализации сервера. Смена пароля описана в RFC 3244.
  4. В случае использования симметричной криптографии (Kerberos может работать с использованием как симметричной, так и асимметричной (с открытым ключом) криптографии), так как все способы аутентификации управляются централизованно центром распределения ключей (KDC), эта особенность инфраструктуры аутентификации позволит злоумышленнику выдавать себя за пользователя.
  5. Каждый сетевой сервис, требующий смены имени хоста, должен будет обновить собственный набор ключей Kerberos. Это усложняет использование виртуального хостинга и кластеров.
  6. Kerberos требует, чтобы учетные записи пользователей, клиенты и пользователи услуг на сервере, все доверяли серверу Kerberos (все должны быть в одном и том же домене с Kerberos или в доменах, имеющих доверительные отношения друг с другом). Kerberos не может использоваться в случаях, когда пользователи хотят подключаться к службам от неизвестных / ненадежных клиентов, как в обычном интернете.

Уязвимости

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

В ноябре 2014 года Microsoft выпустила патч (MS14-068), чтобы исправить уязвимость в реализации Windows сервера .[5] Уязвимость, согласно заявлению, позволяла пользователям "поднять" их привилегии до уровня домена.

Примечания

  1. Ни секретный ключ, ни пароль не отправляется на
  2. Клиент не может расшифровать сообщение B, так как оно зашифровано с помощью секретного ключа

Литература

  1. R. M. Needham and M. D. Schroeder, ‘‘Using Encryption for Authentication in Large Networks of Computers,’’ Communications of the ACM 21(12), pp.993-999 (December, 1978)
  2. Jennifer G. Steiner, Clifford Neuman, and Jeffrey I. Jennifer G. Steiner, Clifford Neuman, and Jeffrey I, 1988
  3. https://en.wikipedia.org/wiki/Kerberos_(protocol)
  4. https://tools.ietf.org/html/rfc6649
  5. http://www.zdnet.com/details-emerge-on-windows-kerberos-vulnerability-7000035976/