Схема работы Kerberos 5 в настоящее время происходит следующим образом:
Вход пользователя в систему:
1. Пользователь вводит имя и пароль на клиентской машине.
2. Клиентская машина выполняет над паролем одностороннюю функцию (обычно хэш), и результат становится секретным ключом клиента/пользователя.
Аутентификация клиента:
1. Клиент отсылает запрос (AS_REQ) на СА для получения аутентификационных верительных данных и последующего их предоставления TGS серверу (впоследствии он будет их использовать для получения билетов без дополнительных запросов на применение секретного ключа пользователя.) Данный запрос содержит:
· Идентификатор клиента, его метка времени и идентификатор сервера.
2. Если политика ЦРК требует предварительной аутентификации, то пользователь получает сообщение KRB_ERROR, в ответ на которое посылает повторный запрос, но с уже данными для установления подлинности.
3. СА проверяет, есть ли такой клиент в базе. Если есть, то назад СА отправляет сообщение (AS_REP) включающее:
· Сессионный ключ клиент/TGS, идентификатор TGS и время жизни билета зашифрованные секретным ключом клиента.
· TGT (который включает идентификатор и сетевой адрес клиента, метку времени ЦРК, период действия билета и сессионный ключ Клиент/TGS), зашифрованный секретным ключом TGS.
- Если же нет, то клиент получает новое сообщение, говорящее о произошедшей ошибке.
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 символов).
