kerberos ticket что это

Kerberos за 5 минут: знакомство с сетевой аутентификацией

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

В этой статье мы ответим, что такое Kerberos, как он работает, и рассмотрим типичные атаки, которые инженеры безопасности Kerberos должны преодолевать ежедневно.

К концу вы получите новую оценку современной сетевой безопасности и, надеюсь, пик интереса к кибербезопасности!

Что такое Kerberos?

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

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

Протокол Kerberos получил широкое признание с момента его создания в Массачусетском технологическом институте в 1980-х годах. Теперь он встроен в бесчисленное количество зависимых от безопасности реализаций в Интернете, и почти все компании ежедневно взаимодействуют по крайней мере с одной системой Kerberos.

Наиболее известное использование Kerberos — это Microsoft Active Directory, служба каталогов по умолчанию, включенная в Windows 2000 и более поздних версий для управления доменами и аутентификации пользователей.

Другие известные применения — Apple, НАСА, Google, Министерство обороны США и университеты по всей территории Соединенных Штатов.

Преимущества Kerberos

Kerberos так широко используется из-за его простоты и непревзойденной безопасности данных. Вот лишь некоторые из его преимуществ:

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

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

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

Основные компоненты Kerberos

Центр распространения ключей

Центр распространения ключей (KDC) — это центральный процесс Kerberos, содержащий сервер аутентификации (AS) и службу выдачи билетов (TGS). Его основная функция — быть посредником между этими двумя, ретранслируя сообщения от AS, выдает билет на выдачу билетов (TGT), а затем передает его для шифрования с помощью TGS. После этого KDC мало влияет на процесс аутентификации.

Билет на выдачу билетов

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

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

Скрывая TGT от клиента, Kerberos предотвращает мошенническое копирование или изменение разрешений клиентом.

Сервер аутентификации

Сервер аутентификации — это первая остановка при аутентификации с помощью Kerberos. Сначала клиент должен аутентифицироваться в AS, используя имя пользователя и пароль для входа.

После этого AS перенаправляет имя пользователя в KDC, который, в свою очередь, предоставляет TGT. Без выполнения этого первого шага клиент не сможет взаимодействовать с какой-либо другой частью системы Kerberos.

Служба выдачи билетов

Служба предоставления билетов действует как привратник между клиентами, владеющими TGT, и различными службами в сети. Когда клиент хочет получить доступ к услуге, он должен представить свой TGT в TGS.

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

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

Проверка подлинности Kerberos состоит из 4 этапов, в зависимости от того, какие компоненты взаимодействуют между собой:

Пример процесса Kerberos

Каждый из этих этапов состоит из нескольких этапов, но в режиме реального времени процесс происходит очень быстро. Чтобы поместить то, что мы узнали выше, в контекст, давайте рассмотрим пример из реальной жизни.

В начале рабочего дня вы вводите пароль в свой клиент. Пароль аутентифицируется AS, а затем KDC предоставляет вам TGT. В этом билете есть набор ключей от dataScienceкоролевства.

Затем TGT кэшируется на вашем компьютере для дальнейшего использования. Этот доступ позволяет вам использовать любые услуги в dataScienceобласти, например, доступ к покупательскому поведению клиентов.

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

В конце рабочего дня срок действия вашего TGT истекает, и вы не сможете снова получить доступ к этим службам, пока не получите новый билет при входе в систему на следующий день.

Разбивка процесса Kerberos (16 шагов)

Теперь мы разберем каждый этап процесса, чтобы вы лучше понимали, что происходит за кулисами:

1. Войти

Пользователь вводит свое имя пользователя и пароль. Затем клиент с поддержкой Kerberos преобразует этот пароль в секретный ключ клиента.

2. Запросы клиентов на сервер выдачи билетов

Затем клиент отправляет серверу аутентификации текстовое сообщение, содержащее:

3. Сервер проверяет имя пользователя.

Имя пользователя проверяется на соответствие проверенным именам пользователей, хранящимся в KDC. Если имя пользователя знакомо, программа продолжится.

4. Выдача билета. Билет возвращается клиенту.

Сервер аутентификации отправляет клиенту два зашифрованных сообщения:

5. Клиент получает сеансовый ключ TGS.

Теперь клиент расшифровывает, message Aиспользуя секретный ключ клиента, предоставляя клиенту доступ к ключу сеанса TGS. Message Bхранится локально в зашифрованном состоянии.

6. Клиент запрашивает доступ к службе с сервера

Теперь клиент отправляет обратно два сообщения:

7. Сервер проверяет службу.

Затем TGS проверяет, существует ли служба запросов в KDC. Если это так, программа продолжается.

8. Сервер получает сеансовый ключ TGS.

Теперь сервер получает все еще зашифрованные message Bотправленные message C. Message B(TGT) затем расшифровывается с использованием секретного ключа TGS сервера, давая серверу сеансовый ключ TGS.

Теперь с помощью этого сеансового ключа TGS сервер может расшифровать message D.

Теперь у сервера есть отметка времени и имя из message Bи message D(сообщения аутентификатора). Сервер следит за тем, чтобы имена и временные метки совпадали, чтобы предотвратить мошеннические сообщения. Он также проверяет метку времени на соответствие времени жизни билета, чтобы убедиться, что время ожидания не истекло.

9. Сервер генерирует служебный сеансовый ключ.

Затем сервер генерирует случайный ключ сеанса службы и еще два сообщения.

10. Клиент получает ключ сеанса обслуживания.

Используя ключ сеанса TGS, кэшированный на шаге 5, клиент расшифровывает, message Fчтобы получить ключ сеанса службы.

11. Клиент связывается с Сервисом

Теперь клиент отправляет еще два сообщения, на этот раз службе:

12. Расшифровка сервисов Message G

Затем служба расшифровывает message Hсвой секретный ключ службы, чтобы получить ключ сеанса службы изнутри. С помощью этого ключа сервис расшифровывает message G.

13. Сервис проверяет запрос

Затем служба проверяет запрос, сравнивая имена пользователей, временные метки и время жизни из messages Gи H.

14. Сервис аутентифицируется для клиента.

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

15. Клиент проверяет услугу.

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

16. Свободное общение между клиентом и службой

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

Можно ли взломать Kerberos?

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

Хакеры нашли 5 основных способов обойти систему Kerberos, основанных на нацеливании на уязвимые системные настройки, слабые пароли или распространение вредоносного вредоносного ПО. Давайте рассмотрим каждый из 5 типов атак:

Что изучать дальше

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

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

Источник

Руководство по выживанию — 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). Для начала несколько общих определений:

Аутентификация (Authentication)	Процесс или процедуры, используемые для проверки того, что данные или информация, заявленные как поступившие из какого-то источника (от какого-то человека), могли поступить только из этого источника (от этого человека).
Авторизация (Authorization)	После того, как пользователи прошли аутентификацию, они могут быть авторизованы на получение или запрет доступа к определённым системным/сетевым ресурсам, таким как файлы, приложения, либо возможность отправки электронной почты, выхода в Интернет и т.п. Процесс аутентификации обычно обеспечивает доступ к набору записей в базе данных по защите информации, которые содержат данные по доступу и/или дополнительные данные, основанные на принадлежности учётной записи к одной или нескольким группам. Термин «привилегия» иногда используется как синоним авторизации. Так, пользователь может иметь достаточно привилегий для доступа к ресурсу X, но не к ресурсу Y, или, иными словами, он авторизован на доступ к X, но не авторизован на доступ к Y.
Удостоверяющие данные (Credentials)	Причудливое название того, что большинство из нас назвало бы паролем (хотя они могут принимать и иные формы, такие как аппаратный токен или биометрические данные). Ваши удостоверяющие данные являются одним из способов доказать, что Вы именно тот, за кого себя выдаёте. Так как Вы должны быть единственным человеком (или, в некоторых случаях, группой лиц) кто знает или имеет доступ к Вашим удостоверяющим данным, то когда Вы предоставляете их в системе или в сети и они совпадают с теми, которые ранее были безопасным способом занесены и сохранены в некоторую форму базы данных по защите информации, это доказывает, что Вы именно тот, за кого себя выдаёте. После выполнения неких форм обмена данными, которые будут включать в себя предоставление Ваших удостоверяющих данных (например, набор пароля), Вы становитесь аутентифицированы. Как правило, после аутентификации Вам ещё нужно быть авторизованным для доступа к ресурсам или информации.

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.

Область действия (Realm)

RFC	Описание/статус
RFC 4120	The Kerberos Network Authentication Service (V5). Служба сетевой аутентификации Kerberos (версия 5). C. Neuman, T. Yu, S. Hartman, K. Raeburn. Июль 2005 г. Отменяет RFC1510. Обновлён в RFC4537, RFC5021, RFC5896, RFC6111, RFC6112, RFC6113. Статус: PROPOSED STANDARD.
RFC 4121	The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2. Механизм общего программного интерфейса систем безопасности (GSS-API) Kerberos версии 5: версия 2. L. Zhu, K. Jaganathan, S. Hartman. Июль 2005 г. Обновляет RFC1964. Обновлён в RFC6112. Статус: PROPOSED STANDARD.
RFC 6111	Additional Kerberos Naming Constraints. Дополнительные ограничения именования в Kerberos. L. Zhu. Апрель 2011 г. Обновляет RFC4120. Статус: PROPOSED STANDARD.
RFC 6112	Anonymity Support for Kerberos. Поддержка анонимности для Kerberos. L. Zhu, P. Leach, S. Hartman. Апрель 2011 г. Обновляет RFC4120, RFC4121, RFC4556. Статус: PROPOSED STANDARD.
RFC 6113	A Generalized Framework for Kerberos Pre-Authentication. Обобщенный механизм предварительной аутентификации для Kerberos. S. Hartman, L. Zhu. Апрель 2011 г. Обновляет RFC4120. Статус: PROPOSED STANDARD.
RFC 6251	Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol. Использование Kerberos версии 5 поверх протокола TLS. S. Josefsson. Май 2011 г. Статус: INFORMATIONAL.

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

Источник