Керберос (протокол)

Керберос

Разработчик(и)	Массачусетский технологический институт
Стабильная версия	Версия 5, Выпуск 1.21 / 5 июня 2023 г ( 05.06.2023 )
Написано в	С
Операционная система	Кросс-платформенный
Тип	Протокол аутентификации
Веб-сайт	сеть .с .edu /керберос /

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

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

Протокол был назван в честь персонажа Кербера (или Цербера ) из греческой мифологии , свирепого трехголового сторожевого пса Аида .

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

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

Версия Kerberos 4, первая общедоступная версия, была выпущена 24 января 1989 года. Поскольку Kerberos 4 был разработан в Соединенных Штатах и ​​поскольку он использовал стандарта шифрования данных (DES) алгоритм шифрования , ограничения экспортного контроля США не позволяли его экспортировать. в другие страны. MIT создал экспортируемую версию Kerberos 4, из которой удален весь код шифрования. под названием «Кости». Эрик Янг из Австралийского университета Бонда повторно реализовал DES в Bones в версии под названием «eBones», которую можно было свободно использовать в любой стране. Швеции Королевский технологический институт выпустил еще одну модификацию под названием KTH-KRB.

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

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

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

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

Протокол

Описание

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

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

Переговоры Кербероса

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

Вход на основе клиента пользователя без Kerberos

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

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

1. Клиент отправляет открытое текстовое сообщение с идентификатором пользователя AS (серверу аутентификации), запрашивая услуги от имени пользователя. (Примечание. Ни секретный ключ, ни пароль не отправляются в AS.)
2. AS проверяет, находится ли клиент в его базе данных. Если это так, AS генерирует секретный ключ путем хеширования пароля пользователя, найденного в базе данных (например, Active Directory в Windows Server), и отправляет обратно клиенту следующие два сообщения:
   • Сообщение A: Ключ сеанса клиента/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 (найденного клиентом в сообщении A).
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: из предыдущего шага ( билет клиент-сервер , зашифрованный TGS с использованием секретного ключа службы).
   • Сообщение G: новый аутентификатор, который включает идентификатор клиента, метку времени и зашифрован с использованием ключа сеанса клиента/сервера .
2. SS расшифровывает билет (сообщение E), используя свой собственный секретный ключ для получения сеансового ключа клиента/сервера . Используя ключ сеанса, SS расшифровывает Аутентификатор и сравнивает идентификатор клиента из сообщений E и G, если они совпадают, сервер отправляет клиенту следующее сообщение, чтобы подтвердить его истинную личность и готовность обслуживать клиента:
   • Сообщение H: временная метка, найденная в аутентификаторе клиента (плюс 1 в версии 4, но не обязательно в версии 5). ), зашифрованный с использованием сеансового ключа клиента/сервера .
3. Клиент расшифровывает подтверждение (сообщение H) с помощью сеансового ключа клиента/сервера и проверяет правильность метки времени. Если это так, то клиент может доверять серверу и может начать отправлять запросы на обслуживание на сервер.
4. Сервер предоставляет клиенту запрошенные услуги.

Поддержка операционных систем

Microsoft Windows

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

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

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

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

Microsoft Windows и Windows Server включают в себя setspn — утилита командной строки , которую можно использовать для чтения, изменения или удаления имен участников службы (SPN) для учетной записи службы Active Directory .

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

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

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

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

Безопасность

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

См. также

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

Ссылки

Общий

• Гарман, Джейсон (2003). Kerberos: Полное руководство . O'Reilly Media, Inc. ISBN  978-0-596-00403-3 .
• Проэль, Марк; Кобрас, Дэниел (14 апреля 2022 г.). Kerberos: единый вход в смешанных средах Linux/Windows (на немецком языке). dpunkt.verlag. п. 7. ISBN  9783960888512 .
• Линн Рут (30 мая 2013 г.) (2 апреля 2013 г.). «Объясните, как будто мне 5: Kerberos» . Блог Линн Рут . {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
• Microsoft TechNet 2017 (18 июля 2012 г.). «Основные понятия протокола Kerberos» . Библиотека MSDN . {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
• Команда набора ресурсов (7 января 2021 г.). «Microsoft Kerberos (Windows)» . Библиотека MSDN .
• Б. Клиффорд Нойман; Теодор Цо (сентябрь 1994 г.). «Керберос: служба аутентификации для компьютерных сетей» . IEEE-коммуникации . 32 (9): 33–8. дои : 10.1109/35.312841 . S2CID   45031265 .
• Коль, Джон Т.; Нойман, Б. Клиффорд; Цо, Теодор Ю. (1994). «Эволюция системы аутентификации Kerberos». В Бразье, FMT ; Йохансен, Д. (ред.). Распределенные открытые системы . Издательство Компьютерного общества IEEE. стр. 78–94. CiteSeerX   10.1.1.120.944 . ISBN  978-0-8186-4292-0 . OCLC   1191406172 .
• «Обзор Kerberos: служба аутентификации для открытых сетевых систем» . Сиско Системс. 19 января 2006 года . Проверено 15 августа 2012 г.
• «Как работает аутентификация Kerberos» . Learn-networking.com. 28 января 2008 г. Архивировано из оригинала 2 апреля 2015 г. Проверено 15 августа 2012 г.
• «Что такое аутентификация Kerberos?: Вход в систему и аутентификация» . Microsoft TechNet. 8 октября 2009 года . Проверено 7 декабря 2016 г.

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 Механизм общего прикладного программного интерфейса службы безопасности Kerberos версии 5 (GSS-API): версия 2
• RFC 4537 Расширение согласования криптосистемы Kerberos
• RFC 4556 Криптография с открытым ключом для начальной аутентификации в Kerberos (PKINIT)
• RFC 4557 Протокол статуса онлайн-сертификата (OCSP) Поддержка криптографии с открытым ключом для начальной аутентификации в Kerberos (PKINIT)
• RFC 4757 Типы шифрования Kerberos RC4-HMAC, используемые 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 версии 5. Общий прикладной программный интерфейс службы безопасности (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
• Шифрование AES RFC 8009 с HMAC-SHA2 для Kerberos 5

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

• «Комментарий Novell Inc. к предлагаемому мировому соглашению между Microsoft и Министерством юстиции в соответствии с Законом Танни» . Гражданский иск № 98-1232 (CKK): Соединенные Штаты Америки против корпорации Microsoft . Министерство юстиции. 29 января 2002 года . Проверено 15 августа 2012 г.
• Брайант, Билл (февраль 1988 г.). «Проектирование системы аутентификации: диалог в четырех сценах» . Юмористическая пьеса о том, как развивалась конструкция Kerberos . Массачусетский технологический институт .
• Хорнштейн, Кен (18 августа 2000 г.). «Часто задаваемые вопросы по Kerberos, v2.0» . Министр военно-морского флота . Архивировано из оригинала 3 декабря 2002 года . Проверено 15 августа 2012 г.
• Белловин, С.М.; Мерритт, М. (1 октября 1990 г.). «Ограничения системы аутентификации Kerberos» . Обзор компьютерных коммуникаций ACM SIGCOMM . 20 (5): 119–132. дои : 10.1145/381906.381946 . S2CID   8014806 .
• Нойман, Британская Колумбия; Цо, Т. (сентябрь 1994 г.). «Керберос: служба аутентификации для компьютерных сетей». Журнал коммуникаций IEEE . 32 (9): 33–38. дои : 10.1109/35.312841 . S2CID   45031265 .
• Белла, Джампаоло; Полсон, Лоуренс К. (1998). «Kerberos Версия IV: Индуктивный анализ целей секретности». Компьютерная безопасность — ESORICS 98 . Конспекты лекций по информатике. Том. 1485. стр. 361–375. дои : 10.1007/BFb0055875 . ISBN  978-3-540-65004-1 .
• Абдельмаджид, Северная Каролина; Хоссейн, Массачусетс; Шеперд, С.; Махмуд, К. (2010). «Улучшенная оценка протокола безопасности Kerberos с использованием модифицированной логики запрета». 2010 10-я Международная конференция IEEE по компьютерным и информационным технологиям . стр. 1610–1615. дои : 10.1109/CIT.2010.285 . ISBN  978-1-4244-7547-6 . S2CID   6246388 .

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

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