Kerberos

Доброго времени суток коллеги.

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

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

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

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

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

Для проверки подлинности желающего войти в защищенную систему применяется простой протокол, использующий секретный ключ. При входе инициатор соединения предъявляет свой аутентификатор в виде информации, зашифрованной секретным ключом. Предоставляемая в качестве аутентификатора информация должна быть уникальна для каждого сеанса проверки, что исключит возможность ее перехвата и повторного использования для незаконного проникновения в систему. Служба безопасности защищенной системы получает этот аутентификатор и расшифровывает его. Если эта операция прошла успешно, служба безопасности уверена в том, что предъявитель аутентификатора владеет верным ключом. Так как владеть данным ключом могут только двое, а служба безопасности — одна из них, то владельцем второго является предъявитель аутентификатора. Служба безопасности, получив и расшифровав предъявленный аутентификатор, извлекает из него часть информации и зашифровывает ее в новый аутентификатор, который и отправляет инициатору соединения. Тот расшифровывает его и сравнивает со своим оригиналом. Совпадение данных является подтверждением того, что служба безопасности смогла расшифровать оригинал, и следовательно, ее ключ верен.

В основе протокола Kerberos лежит модифицированный протокол Нидхема — Шрёдера, причём полученный метод аутентификации и обмена ключами также называют протоколом Kerberos.

Давайте рассмотрим как он работает на примере общения Алисы и Боба.

1. Алиса передаст Бобу сообщение, содержащее ее имя открытым текстом и аутентификатор, зашифрованный общим секретным ключом. Согласно договоренности, данные в аутентификаторе хранятся в структуре, состоящей из двух полей. В первом поле находится информация о самой Алисе. Второе поле содержит метку времени на рабочей станции Алисы.

2. Получив сообщение от отправителя, называющего себя Алисой, Боб расшифровывает аутентификатор общим ключом и оценивает достоверность штампа времени. Допустим, что временной сдвиг не может превышать пяти минут(такой сдвиг задан по умолчанию в Active Directory Domain Service). Боб сравнивает время, указанное в аутентификаторе, с показаниями своих часов. Если разница оказывается больше пяти минут, аутентификатор автоматически отвергается. Если разница во времени находится в пределах допустимого сдвига, то вполне возможно, что аутентификатор прислала Алиса. Тем не менее существует вероятность, что некто, просматривая сетевой трафик, перехватил предыдущую попытку Алисы установить соединение c Бобом и воспроизвел ее со своего компьютера.

3. Боб зашифровывает метку времени из сообщения Алисы с помощью общего ключа и отправляет сообщение обратно. Боб отправляет обратно не всю информацию из аутентификатора Алисы, а только метку времени. Передавая лишь часть информации, Боб демонстрирует, что ему удалось расшифровать аутентификатор и изменить информацию, находившуюся в нем. Выбор метки времени определяется его уникальностью и тем, что он заведомо известен Алисе.

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

Как это работает в жизни?

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

· AS (Authentication Server) = Сервер аутентификации

· TGS (Ticket Granting Server) = Сервер предоставления билетов

· SS (Service Server) = Ресурс, предоставляющий некий сервис, к которому требуется получить доступ

· TGT (Ticket Granting Ticket) = Билет для получения билета

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

1. Пользователь вводит имя и пароль на клиентской машине.

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

Шаги аутентификации клиента:

1. Клиент посылает простым текстом сообщение серверу AS, запрашивая сервисы от имени пользователя. Например так: «Пользователь АБВ хочет запросить сервисы». Обратите внимание, что ни секретный ключ, ни пароль не посылаются на AS.

2. AS проверяет, есть ли такой клиент в базе. Если есть, то назад AS отправляет следующие два сообщения:

· Сообщение A: Сессионный Ключ Client/TGS, зашифрованный секретным ключом клиента/пользователя.

· Сообщение B: TGT (который включает ID клиента, сетевой адрес клиента, период действия билета, и Сессионный Ключ Client/TGS), зашифрованный секретным ключом TGS.

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

Шаги авторизации клиента для получения сервиса:

1. При запросе сервисов клиент отправляет следующие два сообщения на TGS:

· Сообщение C: Содержит TGT, полученный в сообщении B и ID требуемого сервиса.

· Сообщение D: Аутентикатор (составленный из ID клиента и временного штампа), зашифрованный на Сессионном Ключе Client/TGS.

2. После получения сообщений C и D, TGS извлекает сообщение B из сообщения C и расшифровывает его используя секретный ключ TGS. Это дает ему Сессионный Ключ Client/TGS. Используя его TGS расшифровывает сообщение D и посылает следующие два сообщения клиенту:

· Сообщение E: Client-to-server ticket (который содержит ID клиента, сетевой адрес клиента, время действия билета и Сессионный Ключ Client/server) зашифрованный секретным ключом сервиса.

· Сообщение F: Сессионный ключ Client/server, зашифрованный на Сессионном Ключе Client/TGS.

Шаги клиента при запросе сервиса:

1. При получении сообщений E и F от TGS, у клиента достаточно информации для авторизации на SS. Клиент соединяется с SS и посылает следующие два сообщения:

· Сообщение E из предыдущего шага (client-to-server ticket, зашифрованный секретным ключом сервиса).

· Сообщение G: новый аутентикатор, зашифрованный на client/server session key, и включающий ID клиента и временной штамп.

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

· Сообщение H: Временной штамп, указанный клиентом + 1, зашифрованный на Сессионном Ключе Client/Server.

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

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

При написание этой статьи была использована информация из статьи на Wikipedia и информация найденная в сети.

Рубрики:Active Directory Метки:
  1. Комментариев нет.
  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: