Kerberos (протокол)

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

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

История и развитие [ править ]

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

Kerberos версии 4 был разработан Стивом Миллером и Клиффордом Ньюманом . ^[4] Опубликованная в конце 1980-х годов версия 4 также была нацелена на Project Athena .

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

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

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

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

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

Microsoft Windows [ править ]

Windows 2000 и более поздние версии используют Kerberos в качестве метода проверки подлинности по умолчанию. ^[5] Некоторые дополнения Microsoft к набору протоколов Kerberos задокументированы в RFC 3244 «Microsoft Windows 2000 Kerberos Change Password и Set Password Protocols». 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 «S 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) вместе со своим сервисным запросом.

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

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

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

Недостатки и ограничения [ править ]

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

Уязвимости [ править ]

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

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

См. Также [ править ]

• Единая точка входа
• Управление идентификацией
• СПНЕГО
• S / ключ
• Протокол защищенного удаленного пароля (SRP)
• Общий прикладной программный интерфейс служб безопасности (GSS-API)
• Протокол идентификации хоста (HIP)
• Список реализаций единого входа

Ссылки [ править ]

Общий

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 Online Certificate Status Protocol (OCSP) Поддержка криптографии с открытым ключом для начальной аутентификации в Kerberos (PKINIT)
• RFC 4757 RC4-HMAC Типы шифрования Kerberos, используемые Microsoft Windows [Устарело]
• RFC 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Обмены через TCP
• RFC 5349 Поддержка криптографии с эллиптическими кривыми (ECC) для криптографии с открытым ключом для начальной аутентификации в Kerberos (PKINIT)
• RFC 5868 изложение проблемы межсферной работы Kerberos
• RFC 5896 Generic Security Service Application Program Interface (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 версии 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

Дальнейшее чтение [ править ]

Внешние ссылки [ править ]

Викискладе есть медиафайлы по теме Kerberos .

• Консорциум Kerberos
• Страница Kerberos на сайте MIT
• Рабочая группа Kerberos на веб-сайте IETF
• Схема последовательности Kerberos
• Реализация Heimdal / Kerberos