для чего используется система kerberos

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Kerberos

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

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

Протокол 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. Опубликованные ими документы включают в себя:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kerberos 4

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

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

Обычно эти компоненты поставляются как единая программа, которая запускается на центре распределения ключей (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 требует, чтобы пользователь удостоверил свою личность прежде, чем ему будет выдан мандат.

Настройка 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 на самой рабочей станции и воспользовавшись командой ktadd в kadmin:

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

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

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

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

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

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

Источник

Руководство по выживанию — Kerberos

Это руководство по выживанию посвящено системе Kerberos, в частности, Kerberos V (или Kerberos 5, кому как нравится), разработанной M.I.T.. Предыдущая версия, — Kerberos IV (Kerberos 4), — имеет значительные отличия и в этом руководстве не рассматривается.

Содержание:

Обзор

Kerberos 5 (в дальнейшем в этом тексте называемый просто Kerberos) — это сетевая система аутентификации, определённая в RFC 4120 (с дополнениями в RFC 4537 и RFC 5021, оба добавляют возможности проведения переговоров, но не меняют основу протокола).

Кроме того, в RFC 4121 определён метод, называемый GSSAPI (General Security System Application Program Interface, общий программный интерфейс систем безопасности), с помощью которого Kerberos-совместимые приложения могут напрямую вызвать службу Kerberos. Позднее GSSAPI был трансформирован для поддержки других (не Kerberos) систем обеспечения безопасности.

Kerberos может также использоваться для транспортировки информации по авторизации, но эта возможность рассматривается как специфичная для приложений и не определяется в RFC. Тем не менее, для транспортировки этой информации выделены общие поля (раздел 5.2.6 RFC 4120).

Kerberos широко используется повсюду в мире локальных и глобальных сетей и, возможно, в первую очередь в Microsoft, начиная с Windows 2000. В Kerberos активно используется симметричное шифрование. Голова уже начинает болеть.

И для особо любопытных: название Kerberos является искажением имени Cerberus (Цербер), которое в Древнегреческой мифологии носил трёхголовый пёс, охранявший врата царства мёртвых, чтобы не дать людям улизнуть оттуда.

Обзор Kerberos

Kerberos предоставляет как сетевую аутентификацию, так и безопасный метод, посредством которого может быть проведена авторизация без необходимости повторного ввода пароля или предоставления других удостоверяющих данных. Поэтому он используется для обеспечения того, что обычно называется Технологией единого входа (Single Sign-on, SSO). Для начала несколько общих определений:

Kerberos не делает никаких предположений о защищённости той сети, поверх которой он работает (по факту, он просто ей не доверяет). Однако, он предполагает, что хосты приложений и особенно хост, на котором работает Центр распределения ключей (Key Distribution Center, KDC) Kerberos, являются защищёнными. Особенности Kerberos:

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

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

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

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

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

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

Realm просто означает совокупность пользователей и серверов приложений, которые охватывает (или имеет о них информацию) Центр распределения ключей (KDC). Так, для того чтобы пользователь подсоединился (или вошёл) в Realm, у Сервера аутентификации (Authentication Server) этой области Realm должны быть сведения об удостоверяющих данных этого пользователя (и другая информация о нём), хранящиеся в защищённой базе данных безопасности того или иного вида (форма хранения не определяется в RFC). В терминологии Microsoft это будет называться Доменом (Domain). Области Realm могут доверять другим Realm, в этом случае доверяющие друг другу области должны быть взаимно аутентифицированными (Cross-Authenticated).

Форма имени Realm — . @REALM (регистр символов имеет значение). Например, если Realm называется JOE, то его Realm-имя будет @JOE (что отличается от Realm-имени @joe), а если Realm называется EXAMPLE.COM, то его Realm-имя будет @EXAMPLE.COM. (Примечание: Согласно текущей рекомендации (раздел 6.1 RFC 4120) в качестве имени REALM следует использовать доменное имя, которое часто преобразуется в верхний регистр.) Несмотря на то, что последняя форма может напоминать адрес электронной почты, никакого отношения к электронной почте она не имеет. Если буквы большие, это наверняка REALM, а не почта.

Принципал — это строка, полностью идентифицирующая пользователя службы Kerberos. Он имеет форму thing@REALM. Принципал может быть именем сервиса, выполняющегося на хосте (мы будем называть его принципалом сервиса (Service-Principal)), или именем пользователя (мы будем называть его принципалом пользователя (User-Principal)). Принципалы формируют индексное поле для информации об объекте, хранящейся в базе данных безопасности Kerberos (в Центре распределения ключей или KDC). Форматы принципалов для пользователей и сервисов различаются.

Имя принципала пользователя — это приблизительный эквивалент имени пользователя или имени учётной записи. Оно имеет форму principal-name[/instance-name]@REALM (где часть /instance-name является опциональной). Например, если имя пользователя в принципале пользователя — alice, а Realm — joe, то полный принципал будет alice@joe. Расширение instance-name позволяет любому пользователю иметь более одного принципала. Так, если alice является администратором области Realm joe, имя её принципала будет alice/admin@joe, и у этого принципала будут другие права (и удостоверяющие данные).

Если речь идёт о принципале сервиса, то форма имени принципала становится service-name/QDN@REALM, где QDN — это доменное имя хоста (без точки в конце, как того требует FQDN), на котором работает сервис, а service-name — это специфичная для приложения строка, идентифицирующая сервис на этом хосте. Некоторые типы сервисов используют ключевое слово host. Так, для сервиса ftp, работающего на хосте с именем fileserver.example.com в области Realm @EXAMPLE.COM, имя принципала сервиса будет ftp/fileserver.example.com@EXAMPLE.COM.

Разрешение — это структура данных, содержимое которой известно только издателю этого разрешения, и какой-либо стороне или сторонам, к которым это разрешение имеет отношение. Промежуточные хосты, такие как клиентский хост, рассматривают эти разрешения как неразбираемый набор бит и просто передают их на конечный пункт назначения. В Kerberos разрешения могут быть либо Разрешениями на получение разрешения (Ticket Granting Tickets, TGT), — по сути представляют собой доказательства успешно пройденной аутентификации, — либо Сервисными разрешениями (Service Tickets, ST), — выдаются Службой выдачи разрешений (Ticket Granting Service, TGS) и позволяют пользователю получить доступ к требуемому Сервису приложений (Application Service).

Рисунок 1: Обзор использования Kerberos

Двухминутный тур «Галопом по Kerberos»:

Пользователь выполняет вход в систему на клиентском хосте (1), предоставляя при этом принципал пользователя и требуемый принципал сервиса, которые посылаются (7) Серверу аутентификации (Authentication Server, AS) (2) Центра распределения ключей (KDC) Kerberos (5).

Предположим, что принципал сервиса есть в базе данных безопасности (6). Сервер аутентификации (2) посылает (8) разрешение на получение разрешения (TGT), которое интерпретируется клиентом как неразбираемый набор бит, а также уникальный ключ сессии, зашифрованный удостоверяющими данными принципала пользователя.

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

Когда аутентифицированный пользователь захочет получить доступ к сервису, клиент (1) посылает сообщение (9) Службе выдачи разрешений (Ticket Granting Service, TGS) (3) в составе KDC (5). В этом сообщении содержится TGT (полученный в сообщении (8)), а также имя требуемого принципала сервиса.

TGS (3) отправляет ответ (10) с сервисным разрешением (ST), разрешающим использование запрашиваемого сервиса. Это сервисное разрешение интерпретируется клиентом как неразбираемый набор бит.

Клиент (1) посылает (11) сервисное разрешение (ST) соответствующему Серверу приложений (Application Server) (4).

Сервер приложений (4) использует сервисное разрешение (ST) для проверки того, что запрашивающий авторизован на использование этого сервиса. Он отправляет ответ (12), только если клиент (1) запрашивал выполнение взаимной аутентификации, в противном случае с получением сообщения (11) процесс считается завершённым и можно начинать использовать сервис.

Kerberos — этап входа в систему

В этом разделе несколько более подробно (но не исчерпывающе) описываются различные диалоги протокола. В мельчайших подробностях форматы сообщений определяются в RFC 4120, и для каждого типа сообщения мы приведём ссылку на соответствующий раздел этого документа. Цифры в скобках, встречающиеся в тексте, относятся к приведённому ниже рисунку 2:

Клиент (1) посылает сообщение KRB_AS_REQ (7) (оно же «Первоначальный запрос аутентификации» («Initial Authentication Request»)) Серверу аутентификации (AS) (2), который логически является составной частью KDC (5). Это сообщение посылается открытым текстом (без какого-либо шифрования). Оно содержит имя принципала пользователя, имя принципала сервиса, к которому пользователь хочет подключиться (как правило, принципала Службы выдачи разрешений (TGS), имеющего название krbtgt/REALM@REALM), опциональный список IP-адресов, которые пользователь хочет использовать, опциональное время жизни для этого входа в систему, а также метку nonce (случайное число), используемую как для идентификации ответов, так и для снижения риска подвергнуться атакам воспроизведения (replay attacks).

Сообщение KRB_AS_REQ определено в разделах 3.1.2 и 5.4.1 RFC 4120.

При получении этого сообщения AS (2) проверяет наличие принципала пользователя и принципала сервиса в базе данных безопасности (6) и выдаёт сообщение об ошибке, если они не найдены. Примечание: RFC по Kerberos оставляют формат базы данных безопасности на усмотрение разработчиков системы. В мире Windows это Active Directory (структура, основанная на LDAP).

Сервер аутентификации (2) отвечает одним сообщением KRB_AS_REP (8), которое состоит из:

Случайным образом сгенерированного ключа сессии, времени жизни этого ключа, отметки времени timestamp и копии метки nonce, полученной от клиента (1). Эта информация шифруется с использованием удостоверяющих данных принципала пользователя.

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

Сообщение KRB_AS_REP определено в разделах 3.1.3 и 5.4.2 RFC 4120.

При получении этого сообщения (8) клиент (1) может наконец запросить удостоверяющие данные пользователя и использовать их в качестве ключа для выполнения дешифрования полученного сообщения. Если удалось успешно расшифровать сообщение и исходная метка nonce оказалась верной, то удостоверяющие данные пользователя должны быть корректными. После этого сведения об удостоверяющих данных пользователя могут быть сразу же забыты. Хотя системы, проводящие аутентификацию, могут запросить ввести удостоверяющие данные в тоже самое время, когда вводится имя учётной записи пользователя, на самом деле это не требуется, поскольку протокол Kerberos позволяет отложить запрос удостоверяющих данных вплоть до этого шага, чтобы минимизировать возможные негативные последствия при использовании небезопасной хост-системы или ПЭВМ.

Если предположить, что удостоверяющие данные были правильными, то пользователь с настоящего момента считается аутентифицированным KDC. У него также есть TGT (неразбираемый набор бит) и ключ сессии, так что теперь он может перейти к запросу сетевых сервисов с соответствующего Сервера приложений (4). Эти запросы описаны далее.

Рисунок 2: Операции Kerberos

Примечание: Хотя сообщения на этом рисунке отмечены цветами так, будто они зашифрованы с использованием одного какого-либо ключа, это, конечно же, упрощение (более точную детализацию сообщений можно найти в их описании в RFC). Подсветка сообщений и связанная с ней легенда говорит о ключе, используемом получателем сообщения для расшифровки и проверки данных. Некоторые части каждого сообщения будут в открытом виде, для шифрования других частей будут применяться иные ключи, которые всегда будут неизвестны получателю. Получатель интерпретирует такие части сообщения как неразбираемый набор бит.

Kerberos — запросы сервисов приложений

Цифры в скобках, встречающиеся в тексте, относятся к приведённому выше рисунку 2:

Если пользователь желает использовать сетевой сервис, он должен сначала получить Сервисное разрешение от TGS (3) KDC (5). Клиент (1) создаёт сообщение KRB_TGS_REQ (9) в Службу выдачи разрешений (TGS) (3) на получение Сервисного разрешения (ST) для целевого Сервиса приложений. Содержимое сообщения KRB_TGS_REQ:

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

TGT (неразбираемый набор бит), которое было получено клиентом во время последовательности обмена сообщений этапа входа в систему. Оно уже зашифровано ключом, который неизвестен клиенту, но может быть получен TGS (3) из базы данных безопасности (6) с использованием принципала пользователя.

Структура Authenticator, которая состоит в основном из принципала клиента (Client-Principal), метки nonce (случайное число) и других данных. Authenticator шифруется с помощью ключа сессии, полученного во время последовательности обмена сообщений этапа входа в систему. Опционально, вместе с Authenticator клиент может предложить «подключ» (по существу, замену ключа сессии). При наличии этого подключа, TGS (3) должен использовать его для шифрования ответа.

Сообщение KRB_TGS_REQ определено в разделах 3.2.2 и 5.4.1 RFC 4120. Оно посылается (9) Службе выдачи разрешений (TGS) (3) KDC (5).

TGS (3) отвечает сообщением KRB_TGS_REP (10), которое состоит из:

Случайным образом сгенерированного ключа сессии сервиса приложений (который будет использоваться для шифрования последующих сообщений между клиентом (1) и Сервисом приложений (4)), времени жизни этого ключа, отметки времени timestamp, принципала сервиса, который был запрошен, и копии метки nonce (случайное число), отправленной клиентом (1). Эта информация зашифрована либо с использованием ключа сессии, полученного во время последовательности обмена сообщений этапа аутентификации, либо с использованием подключа (замены ключа сессии), предложенного клиентом в сообщении KRB_TGS_REQ.

Сервисного разрешения (ST), зашифрованного с использованием ключа Сервера приложений, на котором выполняется запрашиваемый клиентом сервис. Это разрешение содержит множество информации, интересной Сервису приложений. С точки зрения клиента, ST представляет собой неразбираемый набор бит, который передаётся Серверу приложений, когда тот требует подтвердить свои права. Клиент не может интерпретировать содержимое ST, поскольку у него нет (да ему и не нужно) каких-либо ключей, которыми он мог бы его расшифровать. Важная часть содержимого ST — копия ключа сессии сервиса приложений, сгенерированного TGS и также отправленного клиенту (смотрите пункт a). Примечание: Серверы приложений также проходят аутентификацию в KDC (5), используя процедуру, практически аналогичную описанной выше для аутентификации пользователя.

Сообщение KRB_TGS_REP определено в разделах 3.2.4 и 5.4.2 RFC 4120.

Клиент (1) расшифровывает свою часть структуры с помощью либо ключа сессии, либо предложенного им подключа, и извлекает и сравнивает метку nonce. Он также извлекает новый ключ сессии сервиса приложений.

Наконец, клиент (1) посылает Серверу приложений (4) сообщение KRB_AP_REQ (11) на запрос доступа. Это сообщение состоит из:

Структуры Authenticator пользователя, как определено выше для сообщения KRB_TGS_REQ. Эта структура Authenticator зашифрована с помощью ключа сессии сервиса приложений, полученного из предыдущего сообщения KRB_TGS_REP (10).

Сервисного разрешения, полученного в предыдущем ответе (10).

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

Сообщение KRB_AP_REQ определено в разделах 3.3.1 и 5.5.1 RFC 4120.

Сервер приложений (4) отвечает (12) сообщением KRB_AP_REP только в случае, если была запрошена взаимная аутентификация. В противном случае считается, что целевой сервис доступен и ожидает поступления клиентских данных.

Сообщение KRB_AP_REP определено в разделах 3.3.3 и 5.5.2 RFC 4120.

В разрешениях (как TGT, так и ST) могут опционально содержаться данные авторизации (раздел 5.2.6 RFC 4520). Конкретное содержимое этих полей специфично для разных типов приложений. Microsoft использует эти поля с данными авторизации для передачи Атрибутных сертификатов привилегий (Privilege Attribute Certificates, PAC).

RFC по теме

Неполный список связанных с Kerberos RFC.

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Источник