Путешествие на ракете Kerberos презентация

стандартах RFC 1510 и других
Имеет собственный словарь терминов: клиент, сервис, пре-аутентификатор, аутентификатор, учётные данные, ключ сессии, билет, Ticket Granting Ticket, Service Ticket, Key Distribution Center, Authentication Service, Ticket Granting Service

(“Principals”): пользователи и сервисы (такие как файловые службы на сервере)
Когда пользователь хочет получить сервис, он запрашивает билет на этот сервис
Затем, пользователь предъявляет сервису этот билет, когда хочет им воспользоваться

каждая имеет свой пароль и имя – “UPN”
Сервисы или “Service Principals”: нечто к чему мы хотим получить доступ; это может быть просто сервер или его отдельный сервис (файлы/печать, SQL, Exchange); каждый сервис имеет своё имя – “SPN” и пароль
Key Distribution Center (KDC) – контроллер домена, сервер, который знает все пароли пользователей и сервисов. Имеет собственный пароль, известный только ему самому (учётная запись “krbtgt”) и другим контроллерам в домене.
Отложим пароли на некоторое время в сторону; а сейчас…

бывают двух видов

систему; чтоб выполнять вход только один раз, мы просим KDC предоставить “билет на KDC”… и это Ticket Granting Ticket
Он предоставляется частью KDC, которая называется “Authentication Service” или AS
Получив TGT, мы можем предъявить его KDC и сказать: “Помнишь меня? Теперь мне нужен Service Ticket к такому-то сервису…”
Service ticket выдаёт другая часть KDC, которая называется “Ticket Granting Service” или TGS

Ticket Granting Service
KDC = AS + TGS
KDC, AS, TGS – всего лишь часть ролей, которые выполняет контроллер
Тем не менее, мы не можем увидеть AS, TGS и другие службы в Task Manager; они выполняются внутри процесса LSASS

нас сервису
Но обычно, всё заканчивается всего одним TGT и множеством ST
Причина наличия двух видов билетов: Kerberos защищает каждый билет, шифруя часть его данных с помощью пароля или ключа

помощью нашего пароля – это значит, что злоумышленник будет иметь множество данных для вычисления пароля
Итак – и это очень важный момент – то, что предоставляет Kerberos в TGT, по сути дела, является “паролем на день”
Информация, относящаяся к Service ticket, шифруется с помощью этого дневного пароля; только относящаяся к TGT информация шифруется с помощью вашего пароля – одна транзакция в день!

Vista пытается выполнить вход, мы увидим, что запрос TGT в первый раз всегда завершается неудачно.
Vista сознательно отправляет “плохой” пакет, чтобы определить возможность использования AES вместо RC4-HMAC – возвращаемое сообщение об ошибке “KDC_ERR_PREAUTH_REQUIRED” содержит в себе список возможных алгоритмов

пароль и получил TGT
Но он всё ещё не вошёл на свой компьютер
Ему нужен доступ к его рабочей станции
Он получит его с помощью Service Ticket
Итак, это следующая вещь, которую ему нужно попросить у Ticket Granting Service

и запрашивает ST на свою рабочую станцию

TGS проверяет TGT и создаёт Service Ticket, идентифицирующий Тома службе Workstation, компьютера TOMSPC; затем, Том предъявляет этот билет TOMSPC

Теперь Том вошёл на свою рабочую станцию!

запроса Service Ticket у Ticket Granting Service
Он получил Service Ticket к своей рабочей станции
Эти “билеты”, на самом деле, всего лишь данные в памяти компьютера TOMSPC
Том может посмотреть их с помощью kerbtray или klist, входящих в Resource Kit
klist теперь встроена в 2008

Time: 5/11/2010 22:10:08
Renew Time: 5/18/2010 12:10:08

Server: host/tomspc.stanky.ru@STANKY.RU
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
End Time: 5/11/2010 22:10:08
Renew Time: 5/18/2010 12:10:08

печати на PS (в klist это отображается, как cifs/ps.stanky.ru…)
Он предъявляет TGS свой TGT
Контроллер проверяет TGT и выдаёт Тому Service Ticket, идентифицирующий его на PS
Теперь у Тома три билета

Но как мы это обезопасим?
Почему злоумышленник не может перехватить билеты, которые говорят “Привет служба печати PS, я Том”?
Ключ – это хорошо… Ключи – это следующая часть нашего Марлезонского балета

можем сделать это, если:
Договоримся об алгоритме шифрования
Договоримся о секретном ключе
Договоримся о данных для коммуникации
Например: я говорю, что вы можете узнать меня по приветственному сообщению, которое вы расшифровываете DES’ом и 56-ти битным ключом, который знаем только я и вы, и если оно гласит “Текущее время X”, тогда я, действительно, могу безопасно идентифицировать себя перед вами, скажем, через интернет

создать произвольный 128-ми разрядный ключ и передать его только нам
Данные распознавания: блок данных, называемый “аутентификатор”
Когда “аутентификатор” расшифрован, он должен доказывать другой стороне, что мы знаем общий секретный ключ
*Server 2008 позволяет использовать AES (ура)!

кто не знает, клиент и сервер могут выполнять другие вещи, помимо аутентификации, такие как:
Подписывание SMB
Безопасные (шифрованные) сессии
Обмен ключами IPsec для AH или ESP (подписывание или шифрование)
Любые другие формы подписывания или шифрования

мы используем, не был одним и тем же, каждый раз
Вместо этого, при необходимости поговорить, было бы лучше, если б мы каким-то образом договорились о ключе, который бы действовал всего несколько часов и мы бы никогда больше его не использовали – ключ для сессии
Такой ключ называется ключом сессии (“Session Key”)

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

– сперва TGT, потом Service Ticket? Теперь рассмотрим часть ключей
Когда Том просит TGT у AS, он, в действительности, просит две вещи:
TGT, который он предъявляет TGS, когда ему нужен Service Ticket и
Специальный ключ сессии “только на сегодня”, известный только Тому и KDC
Вот как это работает (уже подробней, но всё ещё немного упрощённо)

на AS

Шифрует используя “NT hash”, хэш MD4 Unicode-версии его пароля

время находится в пределах пяти минут от текущего, поэтому AS верит, что это Том.

Отправляет результаты Тому

он может расшифровать копию “сегодняшнего ключа” сессии Tom-KDC

Теперь только Том и KDC имеют копии ключа Tom-KDC, и ни кто не “прослушал” их общение.

между KDC и Томом
Во-вторых – получили структуру данных (TGT), которую может расшифровать только KDC
Так как только KDC мог создать TGT, и TGT содержит “сегодняшний ключ” Tom-KDC, Том может предъявить TGT всякий раз, когда захочет напомнить KDC, что они уже общались
И для KDC НЕТ необходимости запоминать, что Том сегодня уже аутентифицировался

что Тому нужен Service Ticket на его рабочую станцию, поэтому, он предъявляет TGT на Ticket Granting Service
Но как TGS может убедиться в том, что кто-нибудь не перехватил TGT Тома и не отправил его на TGS?
Это достигается с помощью аутентификатора (“Authenticator”) – структуры данных, содержащей в себе, среди прочих вещей, штамп времени, зашифрованный ключом Tom-KDC

он отправляет свой запрос (“Тому нужен ST на TOMSPC”), “Authenticator” (это больше, чем просо штамп, но нам этого достаточно) и копию TGT на TGS, НЕ на AS

Но на этот раз, он шифрует его, используя ключ сессии Tom-KDC, который он получил от AS ранее, а не свой NT hash

ли он когда-либо с Томом раньше, но распознаёт TGT, который он выдал. Так как TGT зашифрован, используя пароль известный KDC (учётная запись krbtgt), он может расшифровать TGT и получить ключ сессии Tom-KDC.

С помощью полученного ключа сессии Tom-KDC, KDC может расшифровать аутентификатор и извлечь из него штамп времени. Если штамп достаточно близок ко времени KDC, то TGS понимает, что это, действительно, Том просит Service Ticket на TOMSPC.

который Том и его рабочая станция TOMSPC (для краткости TPC) могут использовать сегодня

Как и прежде, делается копия этого ключа

Затем, TGS создаёт ST, содержащий ключ сессии TPC-Tom (и другие вещи) и шифрует его, используя пароль компьютера TPC

TGS шифрует другую копию ключа, используя “пароль на сегодня” Tom-KDC

TGS доставляет билет и новый ключ сессии Тому и забывает ключ Tom-KDC

него заглянуть не может, так как не знает пароля компьютера.

Но он знает пароль Tom-KDC, поэтому, он может расшифровать новый ключ сессии TPC-Tom, который можно использовать для общения со службой Workstation на компьютере TPC.

Теперь всё готов для входа на рабочую станцию.

и прежде, он шифрует его, чтобы доказать, что он является законным владельцем Service Ticket, который предъявляет, но на этот раз он шифрует его новым ключом TPC-Tom

Он отправляет аутентификатор, Service Ticket и запрос “Эй, ты не хочешь впустить Тома?” на службу Workstation компьютера TOMSPC

на TOMSPC открывает билет, так как он зашифрован личным паролем TOMSPC
TOMSPC находит внутри ключ TPC-Tom, который использует, чтобы открыть аутентификатор
Затем, TOMSPC проверяет штамп времени, видит что он в порядке
И Том снова аутентифицирован, но не авторизован… но авторизация – не работа Kerberos

билетах – помните аутентификатор? Он доказывает сервису, что пользователь, в самом деле, тот за кого себя выдаёт
В Kerberos, мы можем дополнительно попросить сервис отправить обратно наш штамп времени, зашифрованный ключом сессии – это взаимная аутентификация (“Mutual Authentication”)

чтобы аутентифицировать, не авторизовывать, пользователей и службы
Эти ключи предоставляются пользователям в форме билетов
Пользователи доказывают, что они являются законными владельцами билетов, используя аутентификаторы
Kerberos работает только в AD; современные системы до сих пор используют LM, NTLM или NTLMv2 для аутентификации

Directory Services
http://blogs.technet.com/askds/archive/tags/Kerberos/default.aspx
IIS and Kerberos от Ken Schaefer
http://www.adopenstatic.com/faq

and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.