Подробное описание. Схема работы Kerberos 5 в настоящее время происходит следующим образом:

Схема работы Kerberos 5 в настоящее время происходит следующим образом:

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

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

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

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

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

· Идентификатор клиента, его метка времени и идентификатор сервера.

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

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

· Сессионный ключ клиент/TGS, идентификатор TGS и время жизни билета зашифрованные секретным ключом клиента.

· TGT (который включает идентификатор и сетевой адрес клиента, метку времени ЦРК, период действия билета и сессионный ключ Клиент/TGS), зашифрованный секретным ключом TGS.

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

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

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

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

· TGT, полученный ранее и идентификатор сервиса.

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

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

· Билет сервиса (который содержит ID клиента, сетевой адрес клиента, метку времени ЦРК, время действия билета и Сессионный Ключ клиент/сервис) зашифрованный секретным ключом сервиса.

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

Схема работы Kerberos 5

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

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

· Зашифрованный билет сервиса полученный ранее.

· Новый аутентификатор, зашифрованный на сессионном ключе клиент/сервис, и включающий ID клиента и метку времени.

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

· Метку времени, указанную клиентом + 1, зашифрованную на сессионном ключе клиент/сервис.

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

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

PKINIT

Расширение PKINIT затронуло этап предварительной аутентификации клиента. После чего она стала происходить следующим образом:

1. Пользователь идентифицируется в системе и предъявляет свой закрытый ключ.

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

3. Получив запрос, ЦРК сначала проверяет достоверность сертификата пользователя, а затем электронную подпись (используя полученный открытый ключ пользователя). После этого ЦРК проверяет локальное время, присланное в запросе (для защиты от повторов).

4. Удостоверившись в подлинности клиента, ЦРК формирует ответ (AS_REP), в котором в отличие от стандартной версии, сеансовый ключ зашифровывается открытым ключом пользователя. Кроме того ответ содержит сертификат ЦРК и подписывается его закрытым ключом (аналогично запросу клиента).

5. Получив ответ, пользователь проверяет подпись ЦРК и расшифровывает свой сеансовый ключ (используя свой закрытый)

Дальнейшие этапы происходят согласно стандартному описанию Kerberos V5.

Задание для самостоятельной работы:

Проверить пароли на стойкость с помощью программы LC3.

Критерии по которым необходимо вводить пароли:

· пароль пустой,

· пароль, совпадающий с именем пользователя,

· пароль, состоящий из нескольких символов (простое слово, написанное на русском языке и на русской же раскладке клавиатуры – 4-5 символов),

· пароль, состоящий из нескольких символов (простое слово, написанное на русском языке, но на английской раскладке клавиатуры – 4-5 символов),

· пароль, придуманный вами (более 8 символов),

· пароль, сгенерированный с помощью программы генерации паролей (более 8 символов).