Kerberos

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:08, 14 мая 2017.
7c4ac2c956a808e2d7179111e5bde18e.jpg

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

История создания

Kerberos был создан MIT в качестве решения проблем с безопасностью сети. Протокол Kerberos использует стойкую криптографию, так что клиент может идентифицироваться на сервере (и обратно) через незащищенное сетевое соединение. Kerberos это и имя сетевого протокола аутентификации и общий термин для описания программ, где он реализован (например, Kerberos telnet). Доступно несколько свободных реализаций этого протокола, работающих на множестве операционных систем. Massachusetts Institute of Technology (MIT), где Kerberos был первоначально разработан, продолжает разрабатывать собственный пакет Kerberos. Он обычно использовался в США как криптографический продукт, и в этом качестве попадал под действие ограничений на экспорт. MIT Kerberos доступен в виде порта (security/krb5). Heimdal Kerberos это другая реализация версии 5, которая разрабатывалась исключительно вне США для обхода экспортных ограничений (и поэтому часто включалась в некоммерческие реализации UNIX(R)). Heimdal Kerberos доступен в виде порта (security/heimdal), его минимальный комплект включен в базовую установку FreeBSD. [2]

Терминология Kerberos

  • Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
  • Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
  • Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
  • Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
  • Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.[3]

Общие сведения

Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей.

Предусматривается, что начальный обмен информацией между клиентом и сервером происходит в незащищённой среде, а передаваемые пакеты могут быть перехвачены и модифицированы.

Протокол Kerberos может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sign-On (возможность использования единой учетной записи пользователя для доступа к любым ресурсам области).

Протокол основан на понятии Ticket (билет).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).

Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS).

Одним из преимуществ протокола Kerberos, обеспечивающим высокий уровень безопасности, является то, что при любых взаимодействиях не передаются ни пароли, ни значения хеша паролей в открытом виде.

Работая с протоколом Kerberos, необходимо, чтобы системные часы всех участвующих во взаимодействии узлов были синхронизированы.

В качестве примера реализации протокола Kerberos имеет смысл отметить доменную аутентификацию пользователей в операционных системах Microsoft, начиная с Windows 2000.[4]

Развитие протокола

Ранние версии

Ранние версии Kerberos (c 1 по 3) были созданы внутри МIT и использовались в целях тестирования. Эти реализации содержали существенные ограничения и были полезны только для изучения новых идей и выявления проблем, которые могли возникнуть во время разработки.

Kerberos 4

Kerberos 4 впервые была опубликована 24 января 1989 года. Она стала первой версией, распространяемой за пределами MIT, подготовленной для нескольких производителей, которые включили её в свои операционные системы. Кроме того, другие крупные проекты по распределённым системам (например, AFS) использовали идеи Kerberos 4 для своих систем аутентификации. Основными разработчиками данной версии были Стив Миллер (Steve Miller) и Клиффорд Ньюман (Clifford Neuman). Основы того, что должно было стать Kerberos 4, были описаны в техническом плане «Афина», а окончательный вариант был закреплён в исходном коде эталонной реализации, опубликованной MIT. Однако из-за ограничений на экспорт программного обеспечения, использующего шифрование, наложенных американским правительством, Kerberos 4 не мог быть распространён за пределами Соединённых Штатов. Так как Kerberos 4 при шифровании использовал алгоритм DES, организации за пределами США не могли по закону использовать данное программное обеспечение. В ответ на это команда разработчиков из MIT создала специальную версию Kerberos 4, исключив из неё весь код, касающийся шифрования. Данные меры позволили обойти ограничение на экспорт. Позже Эррол Янг (Errol Young) в Университете связи Австралии (Bond University of Australia) добавил в эту версию собственную реализацию DES. Она называлась «E-Bones» (сокращение от «encrypted bones») и могла свободно распространяться за пределами США. В 2006 году было объявлено о прекращении поддержки Kerberos 4.

Kerberos 5

С целью преодоления проблем безопасности предыдущей версии Джоном Колем (John Kohl) и Клиффордом Ньюманом (Clifford Neuman) была разработана 5 версия протокола, которая в 1993 году была опубликована в RFC 1510. По прошествии времени, в 2005 спецификацией начала заниматься IETF Kerberos work group. Опубликованные ими документы включают в себя:

  • характеристики шифрования и контрольной суммы (RFC 3961);
  • продвинутый стандарт шифрования Advanced Encryption Standard (AES) (RFC 3962);
  • Kerberos 5 «The Kerberos Network Authentication Service (V5)» (RFC 4120), уточняет некоторые аспекты RFC 1510, и намерен использоваться для более подробного и четкого описания;
  • новое издание GSS-API спецификации «The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2.» (RFC 4121).

В июне 2006 года был представлен RFC 4556 описывающий расширение для 5-й версии под названием PKINIT (англ. public key cryptography for initial authentication in Kerberos). Данный RFC описывал, как использовать асимметричное шифрование на этапе аутентификации клиента. На следующий год (2007) MIT сформировали Kerberos Консорциум (Kerberos Consortium) по содействию дальнейшему развитию.

Использование и распространение

Распространение реализации Kerberos происходит в рамках авторского права аналогичного правам для BSD. В настоящее время множество ОС поддерживают данный протокол, в число которых входят: Windows 2000 и более поздние версии, которые используют Kerberos как метод аутентификации в домене между участниками. Некоторые дополнения к этому протоколу отражены в RFC 3244 «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». Документ RFC 4757 описывает использование RC4 Kerberos в Windows; различные UNIX и UNIX подобные ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При этом существует две наиболее используемые реализации с открытым исходным кодом — MIT Kerberos и Heimdal, последняя из которых была изначально создана в Швеции из-за ограничений на экспорт криптографического ПО из США (англ.)[5].

Как работает Kerberos?

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

Вход пользователя в настоящее время происходит следующим образом:

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

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

Керберос1.jpg

Клиент отсылает запрос (AS_REQ) на СА для получения аутентификационных верительных данных и последующего их предоставления TGS серверу (впоследствии он будет их использовать для получения мандатов без дополнительных запросов на применение секретного ключа пользователя.) Данный запрос содержит:

  • Идентификатор клиента, его метка времени и идентификатор сервера.
Керберос2.jpg
Керберос3.jpg

Если политика KDC требует предварительной аутентификации, то пользователь получает сообщение KRB_ERROR, в ответ на которое посылает повторный запрос, но уже c данными для установления подлинности.

Керберос4.jpg

СА проверяет, есть ли такой клиент в базе. Если есть, то назад СА отправляет сообщение (AS_REP), включающее:

Керберос5.jpg
  • Сессионный ключ Клиент/TGS, идентификатор TGS и время жизни мандата, зашифрованные секретным ключом клиента.
  • TGT (который включает идентификатор и сетевой адрес клиента, метку времени KDC, период действия мандата и сессионный ключ Клиент/TGS), зашифрованный секретным ключом TGS.

Если же нет, то клиент получает новое сообщение, говорящее о произошедшей ошибке.

Керберос6.jpg

Получив сообщение, клиент расшифровывает свою часть для получения Сессионного Ключа Клиент/TGS. Этот сессионный ключ используется для дальнейшего обмена с сервером TGS. (Важно: Клиент не может расшифровать TGT, так как оно зашифровано секретным ключом TGS) В этот момент у пользователя достаточно данных, чтобы авторизоваться на TGS.

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

Для запроса сервиса клиент формирует запрос на TGS (TGS_REQ) содержащий следующие данные:

  • TGT, полученный ранее и идентификатор сервиса.
  • Аутентификатор (составленный из ID клиента и временного штампа), зашифрованный на Сессионном Ключе Клиент/TGS.

После получения TGS_REQ, TGS извлекает из него TGT и расшифровывает его используя секретный ключ TGS. Это дает ему Сессионный Ключ Клиент/TGS. Им он расшифровывает аутентификатор. Затем он генерирует сессионный ключ клиент/сервис и посылает ответ (TGS_REP) включающий:

  • мандат сервиса (который содержит ID клиента, сетевой адрес клиента, метку времени KDC, время действия мандата и Сессионный Ключ клиент/сервис) зашифрованный секретным ключом сервиса.
  • Сессионный ключ клиент/сервис, идентификатор сервиса и время жизни мандата, зашифрованные на Сессионном Ключе Client/TGS.

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

После получения TGS_REP, у клиента достаточно информации для авторизации на сервисе. Клиент соединяется с ним и посылает сообщение содержащее:

  • Зашифрованный мандат сервиса полученный ранее.
  • Новый аутентификатор, зашифрованный на сессионном ключе клиент/сервис, и включающий ID клиента и метку времени.

Сервис расшифровывает мандат используя свой секретный ключ и получает сессионный ключ клиент/сервис. Используя новый ключ, он расшифровывает аутентификатор и посылает клиенту следующее сообщение для подтверждения готовности обслужить клиента и показать, что сервер действительно является тем, за кого себя выдает:

  • Метку времени, указанную клиентом + 1, зашифрованную на сессионном ключе клиент/сервис.

Клиент расшифровывает подтверждение, используя сессионный ключ клиент/сервис и проверяет, действительно ли метка времени корректно обновлена. Если это так, то клиент может доверять серверу и может начать посылать запросы на сервер.

Сервер предоставляет клиенту требуемый сервис.[6]

Принцип работы

Kerberos 4

Kerberos 4 в значительной степени основан на протоколе Нидхема-Шрёдера, но с двумя существенными изменениями.

  • Первое изменение протокола уменьшало количество сообщений, пересылаемых между клиентом и сервером аутентификации.
  • Второе, более существенное изменение базового протокола, заключается в ведении TGT (англ. ticket granting ticket — мандат для получения мандата) концепции, позволяющей пользователям аутентифицироваться в нескольких сервисах, используя свои доверительные данные только один раз.

Как результат, протокол Kerberos 4 содержит два логических компонента:

  • Сервер аутентификации (сокр. СА, англ. Authentication Server, сокр. AS)
  • Сервер выдачи мандатов или разрешений (англ. Ticket Granting Server, сокр. TGS).

Обычно эти компоненты поставляются как единая программа, которая запускается на центре распределения ключей (KDC — содержит базу данных логинов/паролей для пользователей и сервисов использующих Kerberos). Сервер аутентификации выполняет одну функцию: получает запрос, содержащий имя клиента, запрашивающего аутентификацию, и возвращает ему зашифрованный TGT. Затем пользователь может использовать этот TGT для запроса дальнейших мандатов на другие сервисы. В большинстве реализаций Kerberos время жизни TGT 8-10 часов. После этого клиент снова должен запросить его у СА.

Первое сообщение, отправляемое центру распределения ключей — запрос к СА, так же известен как AS_REQ. Это сообщение отправляется открытым текстом и содержит идентификационные данные клиента, метку времени клиента и идентификатор сервера, предоставляющего мандат (TGS).

Когда KDC получает AS_REQ сообщение — он проверяет, что клиент, от которого пришёл запрос, существует, и его метка времени близка к локальному времени KDC (обычно ± 5 минут). Данная проверка производится не для защиты от повторов (сообщение посылается открытым текстом), а для проверки соответствия времени. Если хотя бы одна из проверок не проходит — клиенту отправляется сообщение об ошибке, и он не аутентифицируется.

В случае удачной проверки СА генерирует случайный сеансовый ключ, который будет совместно использоваться клиентом и TGS (данный ключ защищает дальнейшие запросы мандатов у TGS на другие сервисы). KDC создает 2 копии сессионного ключа: одну для клиента и одну для TGS.

Затем KDC отвечает клиенту сообщением сервера аутентификации (AS_REP), зашифрованным долгосрочным ключом клиента. Это сообщение включает TGT, зашифрованный TGS ключом, копию сессионного ключа для клиента, время жизни мандата и идентификатор TGS (TGT содержит: копию сессионного ключа для TGS, идентификатор клиента, время жизни мандата, метку времени KDC, IP адрес клиента).

Когда пользователь захочет получить доступ к сервису — он подготовит сообщение для TGS (TGS_REQ), содержащее 3 части: идентификатор сервиса, копию TGT, полученную ранее, и аутентификатор (аутентификатор состоит из метки времени, зашифрованной сессионным ключом, полученным от СА, и служит для защиты от повторов).

При получении запроса мандата от клиента KDC формирует новый сессионный ключ для взаимодействия клиент/сервис. Затем отправляет ответное сообщение (TGS_REP), зашифрованное сессионным ключом, полученным от СА. Это сообщение содержит новый сеансовый ключ, мандат сервиса, зашифрованный долговременным ключом сервиса, идентификатор сервиса и время жизни мандата (Service ticket содержит: копию нового сессионного ключа, идентификатор клиента, время жизни мандата, локальное время KDC, IP клиента).

Детали последнего шага — отправки мандата службы серверу приложений — не стандартизировались Kerberos 4, поэтому его реализация полностью зависит от приложения.

Kerberos 5

Kerberos 5 является развитием четвертой версии, включает всю предыдущую функциональность и содержит множество расширений. Однако с точки зрения реализации Kerberos 5 является абсолютно новым протоколом.

Основной причиной появления пятой версии являлась невозможность расширения. Со временем, атака полным перебором на DES используемом в Kerberos 4 стала актуальна, но используемые поля в сообщениях имели фиксированный размер и использовать более стойкий алгоритм шифрования не представлялось возможным.

Для решения данной проблемы было решено создать расширяемый протокол с возможностью использования на различных платформах на основе технологии ASN.1. Это позволило использовать в транзакциях различные типы шифрования. Благодаря этому была реализована совместимость с предыдущей версией. Кроме того у KDC появляется возможность выбирать наиболее безопасный протокол шифрования, поддерживаемый участвующими сторонами.

Кроме того оригинальный протокол Kerberos 4 подвержен перебору по словарю. Данная уязвимость связана с тем, что KDC выдает по требованию зашифрованный TGT любому клиенту. Важность данной проблемы также подчеркивает то, что пользователи обычно выбирают простые пароли.

Чтобы усложнить проведение данной атаки, в Kerberos 5 было введено предварительное установление подлинности. На данном этапе KDC требует, чтобы пользователь удостоверил свою личность прежде, чем ему будет выдан мандат.

За предварительную аутентификацию отвечает политика KDC, если она требуется, то пользователь при первом запросе к СА получит сообщение KRB_ERROR. Это сообщение скажет клиенту, что необходимо отправлять AS_REQ запрос со своими данными для установления подлинности. Если KDC не опознает их, то пользователь получит другое сообщение KRB_ERROR, сообщающее об ошибке, и TGT не будет выдан[7].


Настройка Kerberos 5

Настройка клиента Kerberos 5 выполняется гораздо проще, чем настройка сервера. Как минимум, вы должны установить пакеты клиента и сформировать для своих клиентов правильный файл конфигурации krb5.conf. Версии rsh и rlogin, поддерживающие Kerberos, также потребуют некоторых изменений в конфигурации.

1.Убедитесь в том, что между клиентом Kerberos и KDC время синхронизировано. За дополнительной информаций обратитесь к разделу Настройка сервера Kerberos 5. Помимо этого, до установки на компьютере клиентских программ Kerberos необходимо убедиться в корректной работе DNS.

2.Установите пакеты krb5-libs и krb5-workstation на всех клиентских компьютерах вашей сферы. Вы должны поместить собственную версию файла /etc/krb5.conf на клиентские компьютеры; обычно это тот же файл krb5.conf, что и на KDC.

3.До того как определённая рабочая станция в вашей сфере позволит пользователям подключиться, используя rsh и rlogin, использующие Kerberos, на этом компьютере необходимо установить пакет xinetd, и создать для него собственную запись узла в базе данных Kerberos. Серверным программам kshd и klogind также понадобится получить ключи своих учётных записей служб.

Воспользовавшись kadmin добавьте учётную запись компьютера для этой рабочей станции. Именем экземпляра в этом случае будет имя рабочей станции. Так как вам никогда больше не понадобится вводить пароль для этой учётной записи, и вероятно, вы не будет против сильного пароля, воспользуйтесь параметром -randkey команды addprinc для программы kadmin для создания учётной записи и присвоения ей случайного пароля:

addprinc -randkey host/blah.example.com

Обратите внимание, после создания учётной записи, вы можете извлечь ключи рабочей станции, выполнив команду kadmin на самой рабочей станции и воспользовавшись командой ktadd в kadmin:

ktadd -k /etc/krb5.keytab host/blah.example.com

Чтобы использовать версии rsh и rlogin, поддерживающие Kerberos, вы должны включить klogin, eklogin и kshell.

4.Также может понадобиться запуск других сетевых служб, поддерживающих Kerberos. Чтобы использовать telnet с поддержкой Kerberos, вы должны включить krb5-telnet. Чтобы предоставить FTP доступ, создайте и извлеките ключ для учётной записи корня ftp, указав в качестве экземпляра имя FTP сервера. Затем включите gssftp. Сервер IMAP, включенный в пакет imap, будет использовать проверку подлинности GSS-API с Kerberos 5, если найдёт соответствующий ключ в /etc/krb5.keytab. Корнем для учётной записи должен быть imap. Служба CVS gserver использует учётную запись с корнем cvs и во остальном совпадает с ??????????????? pserver.[8]

Использование и распространение

Распространение реализации Kerberos происходит в рамках авторского права аналогичного правам для BSD.

В настоящее время множество ОС поддерживают данный протокол, в число которых входят:

  • Windows 2000 и более поздние версии, которые используют Kerberos как метод аутентификации в домене между участниками. Некоторые дополнения к этому протоколу отражены в «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». Документ описывает использование RC4 Kerberos в Windows;
  • различные UNIX и UNIX подобные ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При этом существует две наиболее используемые реализации с открытым исходным кодом — MIT Kerberos и Heimdal, последняя из которых была изначально создана в Швеции из-за ограничений на экспорт криптографического ПО из США.[9]

Применение для централизованной аутентификации

Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании.[10]

Примечания

  1. Kerberos [Электронный ресурс] : Материал из http://cryptowiki.net: — Режим доступа: http://cryptowiki.net/index.php?title=Керберос
  2. Kerberos [Электронный ресурс] : Материал из https://www.freebsd.org: — Режим доступа: https://www.freebsd.org/doc/ru/books/handbook/kerberos5.html
  3. Kerberos [Электронный ресурс] : Материал из https://habrahabr.ru/: — Режим доступа: https://habrahabr.ru/company/aktiv-company/blog/170829/
  4. Kerberos [Электронный ресурс] : Материал из http://itband.ru/: — Режим доступа: http://itband.ru/2010/12/kerberos1/
  5. Kerberos [Электронный ресурс] : Материал из Википедии: — Режим доступа: https://ru.wikipedia.org/wiki/Kerberos
  6. Kerberos [Литрература] : Шнайер Б. Глава 3. Основные протоколы. Протокол Kerberos // Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — С. 81. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.
  7. Kerberos [Электронный ресурс] : Материал из Википедии: — Режим доступа: https://ru.wikipedia.org/wiki/Kerberos
  8. Kerberos [Электронный ресурс] : Материал из http://www.rhd.ru: — Режим доступа: http://www.rhd.ru/docs/manuals/enterprise/RHEL-AS-2.1-Manual/custom-guide/s1-kerberos-clients.html
  9. Kerberos [Электронный ресурс] : Материал из Википедии — свободной энциклопедии: — Режим доступа:https://ru.wikipedia.org/wiki/Kerberos
  10. Kerberos [Электронный ресурс] : Материал из https://habrahabr.ru/: — Режим доступа: https://habrahabr.ru/company/aktiv-company/blog/170829/