что такое билеты kerberos
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 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применяться и другие алгоритмы). В результате формируется криптографический ключ.
В центре KDC долговременные ключи Алисы хранятся в базе данных с учетными записями пользователей. Получив запрос от клиента Kerberos, установленного на рабочей станции Алисы, KDC обращается в свою базу данных, находит в ней учетную запись нужного пользователя и извлекает из соответствующего ее поля долговременный ключ Алисы.
Такой процесс – вычисление одной копии ключа по паролю и извлечение другой его копии из базы данных – выполняется всего лишь один раз за сеанс, когда пользователь входит в сеть впервые. Сразу же после получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos рабочей станции запрашивает сеансовый билет и сеансовый ключ, которые используются во всех последующих транзакциях с KDC на протяжении текущего сеанса работы в сети.
На запрос пользователя KDCотвечает специальным сеансовым билетом для самого себя, так называемый билет на выдачу билетов (ticket-granting ticket), или билет TGT. Как и обычный сеансовый билет, TGT содержит копию сеансового ключа для связи службы (в данном случае –KDC) с клиентом. В сообщение с билетом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Билет TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа – с помощью долговременного ключа пользователя.
Получив ответ службы KDC на свой первоначальный запрос, клиент расшифровывает свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью сеансового ключа. Как и все другие сеансовые ключи, он имеет временный характер и действителен до истечения срока действия билета TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key).
С точки зрения клиента, билет TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент, прежде всего, обращается в кэш-память удостоверений и достает оттуда сеансовый билет для этой службы. Если его нет, он начинает искать в этой же кэш-памяти билет TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с TGT высылает в KDC. Одновременно туда направляется запрос на сеансовый билет для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена – она требует сеансового ключа, аутентификатора и билета (в данном случае TGT).
С точки же зрения службы KDC, билеты TGT позволяют ускорить обработку запросов на получение билетов, сэкономив несколько наносекунд на пересылке каждого из них. Центр распределения ключей KDC обращается к долговременному ключу пользователя только один раз, когда предоставляет клиенту первоначальный билет TGT. Во всех последующих транзакциях с этим клиентом центр KDC расшифровывает билеты TGT с помощью собственного долговременного ключа и извлекает из него сеансовый ключ регистрации, который использует для проверки подлинности аутентификатора клиента.
Аутентификация за пределами домена
Функции центра KDC можно разделить на две категории: службу аутентификации, в задачу которой входит генерация билетов TGT, и службу выдачи билетов, создающую сеансовые билеты. Такое разделение труда позволяет применять протокол Kerberos и за пределами его «родного» домена. Клиент, получивший билет TGT из службы аутентификации одного домена, может воспользоваться им для получения сеансовых билетов в службах выдачи билетов других доменов.
Чтобы лучше понять принцип междоменной аутентификации, рассмотрим для начала простейшую сеть, содержащую всего два домена – «Восток» и «Запад». Предположим, что администраторы этих доменов являются сотрудниками одной организации или у них есть какие-либо другие веские причины уравнять пользователей второго домена со своими собственными. В любом из этих случаев наладить аутентификацию между доменами нетрудно, для этого достаточно договориться о едином междоменном ключе (в Windows 2000 такой ключ генерируется автоматически, когда между доменами устанавливаются доверительные отношения). Как только ключ создан, служба выдачи билетов каждого домена регистрируется в центре KDC другого домена в качестве главного абонента безопасности. В результате служба выдачи билетов каждого из доменов начинает рассматривать службу выдачи билетов второго домена, как еще одну свою службу. Благодаря этому клиент, прошедший аутентификацию и зарегистрировавшийся в системе, может запрашивать и получать сеансовые билеты для нее.
А теперь рассмотрим, что происходит, когда пользователь с учетной записью в домене «Восток» запрашивает доступ к серверу из домена «Запад». Прежде всего, клиент Kerberos, установленный на рабочей станции этого пользователя, посылает запрос в службу выдачи билетов своего домена, в котором просит выдать сеансовый билет для доступа на нужный сервер. Служба выдачи билетов домена «Восток» проверяет список своих абонентов безопасности и убеждается, что такого сервера среди них нет. Поэтому она направляет клиенту так называемый билет переадресации (referral ticket), который представляет собой TGT, зашифрованный с помощью междоменного ключа, общего для служб KDC доменов «Восток» и «Запад». Получив билет переадресации, клиент использует его для подготовки другого запроса на сеансовый ключ. Однако на этот раз запрос пересылается в службу выдачи билетов того домена, где находится учетная запись нужного сервера, то есть, домена «Запад». Его служба выдачи билетов пытается расшифровать билет переадресации с помощью собственной копии междоменного ключа. Если попытка удается, центр KDC направляет клиенту сеансовый билет на доступ к соответствующему серверу своего домена.
Процесс переадресации запроса несколько усложняется в сетях, где развернуто более двух доменов. Теоретически служба KDC каждого домена может установить непосредственную связь с аналогичными службами всех доменов сети, договорившись с каждой из них об индивидуальном междоменном ключе. Однако на практике количество и сложность подобных взаимосвязей очень быстро возрастают до такой степени, что становятся просто неуправляемыми, особенно в сложных сетях. Протокол Kerberos решает эту проблему, делая ненужными прямые связи между доменами. Клиент одного домена может получить билет на доступ к серверу другого домена через один или несколько промежуточных серверов, каждый из которых выдаст ему билет переадресации.
В качестве примера рассмотрим сеть, состоящую из трех доменов: «Восток», «Запад» и «Штаб-квартира». В службе KDC домена «Восток» нет междоменного ключа для аналогичной службы домена «Запад», но центры распределения ключей обоих доменов наладили обмен билетами с доменом «Штаб-квартира». Когда пользователь с учетной записью в домене «Восток» хочет подключиться к серверу из домена «Запад», его запрос будет переадресован дважды. Сначала он пройдет через службу KDC «родного» домена, затем – через промежуточный домен «Штаб-квартира» и, наконец, достигнет центра распределения ключей домена «Запад», которому известен ключ нужного сервера. Таким образом, клиент здесь посылает сеансовые билеты трижды в три различные службы KDC.
1. Клиент запрашивает у службы KDC домена «Восток» билет на доступ к серверу домена «Запад».
Служба KDC домена «Восток» направляет клиенту билет переадресации в службу KDC домена «Штаб-квартира», зашифрованный с междоменным ключом, общим для доменов «Восток» и «Штаб-квартира».
2. Клиент обращается в службу KDC домена «Штаб-квартира» с просьбой о билете на доступ к серверу домена «Запад».
Служба KDC домена «Штаб-квартира» направляет клиенту билет переадресации в службу KDC домена «Запад», зашифрованный с междоменным ключом, общим для доменов «Штаб-квартира» и «Запад».
3. Клиент обращается в службу KDC домена «Запад» с просьбой о билете на доступ к серверу домена «Запад».
Служба KDC домена «Запад» направляет клиенту билет на доступ к нужному серверу.
Подпротоколы
Протокол Kerberos содержит в себе три подпротокола. Первый из них используется службой KDC для передачи клиенту сеансового ключа регистрации и билета TGT. Он называется Authentication Service Exchange (обмен со службой аутентификации) или, сокращенно AS Exchange. Второй подпротокол под названием Ticket-Granting Service Exchange (обмен со службой выдачи билетов) или TGS Exchange служит для рассылки служебных сеансовых ключей и сеансовых ключей самой службы KDC. Третий подпротокол, Client/Server Exchange (клиент-серверный обмен) или CS Exchange, используется клиентом для пересылки сеансового билета доступа к службам.
Чтобы лучше разобраться в том, как эти подпротоколы взаимодействуют между собой, давайте посмотрим, что происходит, когда Алиса, пользователь рабочей станции, обращается к Бобу, сетевой службе.
Подпротокол AS Exchange
Прежде всего, Алиса входит в сеть, для чего вводит свое пользовательское имя и пароль. Клиент Kerberos, установленный на ее рабочей станции, преобразует пароль в криптографический ключ и сохраняет полученный результат в кэш-памяти удостоверений.
После этого клиент посылает в службу аутентификации центра KDC запрос KRB_AS_REQ (Kerberos Authentication Service Request – запрос к службе аутентификации Kerberos). Первая часть его сообщения содержит идентификатор пользователя, то есть Алисы, а также имя службы, для которой ей нужно удостоверение, то есть службы выдачи билетов. Во второй же части указываются данные предварительной аутентификации (pre-authentication data), которые подтверждают, что Алиса знает пароль. Обычно в качестве таких данных используется метка времени, зашифрованная с долговременным ключом Алисы, хотя Kerberos допускает и другие виды предаутентификационных данных.
Рис. 5. Подпротокол AS Exchange
Получив запрос KRB_AS_REQ, служба KDC обращается в свою базу данных и находит в ней долговременный ключ Алисы, после чего расшифровывает данные предварительной аутентификации и оценивает метку времени, содержащуюся в них. Если проверка прошла успешно, служба KDC делает вывод, что данные предварительной аутентификации были зашифрованы с долговременным ключом Алисы и, следовательно, поступили от клиента, имя которого содержится в первой части сообщения.
После того, как проверка личности Алисы завершена, служба KDC генерирует удостоверение, подтверждающее, что клиент Kerberos на ее рабочей станции имеет право обратиться к службе выдачи билетов. Этот процесс выполняется в два этапа. Во-первых, KDC создает сеансовый ключ регистрации и шифрует его копию с помощью долговременного ключа Алисы. Во-вторых, служба включает еще одну копию сеансового ключа регистрации в билет TGT. Туда же заносятся и другая информация об Алисе, например, ее данные авторизации. Затем KDC шифрует билет TGT с собственным долговременным ключом и, наконец, включает зашифрованный сеансовый ключ регистрации вместе с билетом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply – ответ службы аутентификации Kerberos), который направляет клиенту.
Получив такое сообщение, клиент расшифровывает сеансовый ключ регистрации и сохраняет его в кэш-памяти удостоверений. После этого из сообщения извлекается билет TGT, который также помещается в эту кэш-память.
Подпротокол TGS Exchange
Клиент Kerberos, установленный на рабочей станции Алисы, запрашивает удостоверение на доступ к службе Боб, для чего посылает в службу KDC сообщение KRB_TGS_REQ (Kerberos Ticket-Granting Service Request – запрос к службе выдачи билетов Kerberos). В него включается имя пользователя, аутентификатор, зашифрованный с помощью сеансового ключа регистрации Алисы, билет TGT, который был получен с помощью подпротокола AS Exchange, а также имя службы, на доступ к которой нужен билет.
Рис. 6. Подпротокол TGS Exchange
Получив запрос KRB_TGS_REQ, служба KDC с помощью собственного секретного ключа расшифровывает билет TGT и извлекает из него сеансовый ключ регистрации Алисы, который тут же использует для расшифровки аутентификатора. Если содержимое аутентификатора выдерживает проверку, служба KDC извлекает из билета TGT регистрационные данные Алисы и генерирует сеансовый ключ, общий для клиента Алисы и службы Боб. Одну копию этого ключа KDC шифрует с помощью сеансового ключа регистрации Алисы, а другую вместе с данными авторизации Алисы помещает в билет, который шифрует с помощью долговременного ключа Боба. После этого удостоверение Алисы включается в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply – ответ службы выдачи билетов Kerberos) и направляется на ее рабочую станцию.
Получив такое сообщение, клиент с помощью сеансового ключа регистрации Алисы расшифровывает сеансовый ключ доступа к службе и помещает его в кэш-память удостоверений. После этого клиент извлекает билет на доступ к службе и сохраняет его в той же кэш-памяти.
Подпротокол CS Exchange
Клиент Kerberos, установленный на рабочей станции Алисы, обращается к службе Боб, для чего посылает на нее запрос KRB_AP_REQ (Kerberos Application Request – запрос приложения Kerberos). Это сообщение содержит аутентификатор Алисы, зашифрованный посредством сеансового ключа для службы Боб, билет, полученный с помощью протокола TGS Exchange, а также флаг, указывающий о желании клиента провести взаимную аутентификацию (наличие или отсутствие этого флага определяется конфигурацией Kerberos; он устанавливается автоматически без запроса пользователя).
Рис. 7. Подпротокол CS Exchange
Получив сообщение KRB_AP_REQ, служба Боб расшифровывает билет, извлекает из него данные авторизации Алисы и сеансовый ключ, с помощью которого сразу же расшифровывает аутентификатор Алисы. Если метка времени, заложенная в него, выдерживает проверку, Боб ищет в запросе флаг взаимной аутентификации. Найдя его, Боб шифрует метку времени из аутентификатора Алисы сеансовым ключом, включает полученный результат в пакет KRB_AP_REP (Kerberos Application Reply – ответ приложения Kerberos) и возвращает его на рабочую станцию Алисы.
После получения пакета клиент рабочей станции Алисы расшифровывает аутентификатор Боба, используя для этого сеансовый ключ, и сравнивает полученную метку времени с исходной. Если они совпадают, делается вывод, что связь установлена с нужной службой, и можно приступать к обмену информацией.
Билеты
Выше мы говорили о билетах лишь в общих чертах. Теперь пришло время более подробно рассмотреть, что же это такое, как рассчитывается срок годности билета, и какая его часть становится известной клиенту. Все эти детали важны для разработки политики Kerberos, поэтому к ним нужно присмотреться как можно ближе.
Что такое билет
В рамках данного информационного документа достаточно перечислить поля билета и описать содержащуюся в них информацию. Более подробно структура билета и различных сообщений Kerberos описана в документе RFC 1510.
Таблица 1. Поля билета
Первые три поля билета не шифруются. Содержащаяся здесь информация пересылается открытым текстом, что позволяет клиенту использовать ее для управления билетами, хранящимися в кэш-памяти.
Номер версии формата билета. Для Kerberos 5 здесь указывается цифра 5.
Имя области (домена), где генерирован билет. Служба KDC может создавать билеты только для серверов собственной области, поэтому здесь, по существу, указывается имя области, где расположен сервер.
Остальные поля шифруются с помощью секретного ключа сервера.