Аутентификатор еще одно важное понятие в Kerberos

Вид материала

Подобный материал:

Лекция №6

24.03.2009

Гурьев

Продолжаем Kerberos

Аутентификатор – еще одно важное понятие в Kerberos.

Authenticator

ver_no = 5 номер версии
crealm - ID_C
cname - ID_C – область и имя клиента
cusec – время, TS, Time Stamp, с точностью до секунды как принято в Unix,
ctime – дополнительное уточнение времени с точностью до ms.
Subkey – дополнительный ключ будущего сеанса. Там есть такой вариант, когда основной ключ используется только для аутентификации, а для обмена информацией – этот ключ. Но это поле может быть и не заполнено.
Seqnumber – номер этого аутентификатора
Authdata – то же самое, что было в билете. Данные для авторизации. Используется в сообщении для подтверждения подлинности стороны.

Все это шифруется при помощи ключа между сервером и клиентом – K_C_/_S. Это ключ сеанса, ключ, который им назначает Kerberos сервер.

Дальше нужно рационализировать этот протокол, поэтому для аутентификатора используется сокращенная запись

- обозначение аутентификатора.

Основные обмены в Kerberos

Есть пользователи, серверы и Kerberos-сервер, который состоит из двух серверов – AS и TGS.

Первый вид обмена называется ASExchange и это обмен между пользователем и AS, когда пользователь исходно аутентифицируется в системе. Этот обмен состоит из двух сообщений. Клиент посылает серверу сообщение AS_REQUEST, а сервер отвечает ему сообщением AS_REPLY

AS_REQ

ver_no = 5 – номер версии
msg_type = 10 тип сообщения
Дальше идут характеристики того билета, который клиент запрашивает, каким он хочет, что бы билет был.

OPTIONS – битовая строка, которая является расширением поля FLAGS, которое было в билете. Но там есть еще несколько бит, которых во флагах не бывает.
- RENEWABLE_OK если нельзя создать билет с длинным сроком действия, то дай билет с установленным флагом RENEWABLE
- INC_TKT_IN_SKEY билет должен быть дополнительно зашифрован при помощи системы SKEY (это система одноразовых ключей)
- RENEW предъявляется билет устаревший, который можно проблить.
- VALIDATE
Cname – ID_C.
Realm – ID_C and ID_S. – если только речь не идет о запросе в чужой области. Но ASExchange не бывает в чужой области, так что все в порядке, область одна и та же, имя сервера, имя клиента
Sname – ID_S.
From – параметры продолжительности действия билета
Till – параметры продолжительности действия билета
Renewtime – параметры продолжительности действия билета

Nounce
etype – перечисление алгоритмов шифрования в порядке предпочтения. Поле появилось в версии 5, потому что в ней может быть не один алгоритм шифрования, а несколько, и нужно согласовывать.

Address – IP адреса с которых будет действителен билет.
Additional_ticket – дополнительные билеты.

Для краткости всё, выделенное белым кружочком, обозначается PARAMS. Параметры будущего билета. И тогда запишем этот запрос в сокращенной форме

Все это передается в открытом виде, никак не шифруется.

Как правило, так запрашивается билет не на любой сервер, а на сервер TGS.

Ответное сообщение AS_REPLY

ver_no = 5 – номер версии
msg_type = 11 тип сообщения
crealm – ID_C
cname – ID_C
ticket – билет, то что просил клиент у сервера. Содержит необходимую информацию для сервера, для которого он выдан.
А дальше идут поля, частично повторяющие информацию тикета, но адресованные клиенту, который запрашивал сообщение. Напомню, что в тикете есть несколько существенных вещей, в частности, ключ между клиентом и сервером.

Key - тот же самый ключ, но он адресуется уже самому клиенту.
Nounce – то же самое, которое было в запросе
Key_expiration_time время, когда этот ключ будет считаться недействительным
FLAGS – флаги, те, которые включены в билет. Запрашивал клиент одни флаги, а сервер мог выставить совсем другие.
Lastrequest информация, когда последний раз проводилась аутентификация. Имеет вид (тип, время). Тип имеет значения

нет информации
последний запрос был к TGS
последний запрос был начальным
???
последнее обновление (операция renew)
любой другой запрос

Auth_time – время, когда произведена аутентификация.
Starttime – время начала действия билета
End_time – время конца действия билета
Renewtill – время до которого действуют дочерние билеты
Srealm ID_S.
sname ID_S.
saddr IPадрес, с которых может использоваться билет

Фактически, это копия всех полей, которые есть в билете. Но что интересно, так это поля с белым кружочком шифруются при помощи ключа, назначенному данному клиенту. Как клиенту назначаются ключи - я говорил, никаких ключей у них, конечно, нету, а есть пароль. А ключ получается из пароля при помощи односторонней функции.

Открытой частью, фактическия является только ID_C идентификатор клиента, которому назначен билет. Тикет закрыт, потому что он зашифрован ключом сервера на который он выдан. А остальная часть закрыта, потому что зашифрована ключом того клиента, которому этот билет выдан. В билете информация для сервера, а в остальной части информация о том, что есть в билете, для этого клиента.

В сокращенном виде для анализа транзакции это записывается так:

Следующая транзакция – обмен с TGS, TGSExchange

Считается, что в этот момент у клиента уже есть ключ на TGS, который получен с помощью ASExchange. Эта транзакция тоже состоит из двух сообщений - TGS_REQUEST и ответное сообщение TGS_REPLY.

TGS_REQUEST

ver_no = 5 – номер версии
msg_type = 12 тип сообщения
Ticket_C_/_TGS клиент должен предъявить билет на этот сервер.
Authenticator_C_/_TGSаутентификатор клиента и TGS
PARAMS в точности такие же что и AS_REQ
Additional_tickets – дополнительные билеты. Это может быть запрос на возобновление билета, на получение билета для другого IP адреса, или что-то еще. Если билет выдается на основе других билетов.

В сокращенном виде

TGS_REPLY

Аналогично тому что было в AS_REPLY

ver_no = 5 – номер версии
msg_type = 13 тип сообщения
crealm – ID_C
cname – ID_C
Ticket_C_/_S – билет на тот сервер, который запрашивался

Nounce
Key – будущий ключ для связи клиента с сервером, который назначил Kerberos сервер
Last_request – который информирует когда было предыдущее обращение
PARAMS – как в AS_REPLY, фактически все характеристики выданного билета

То, что выделено белыми кружочками, адресовано только данному клиенту, поэтому она шифруется при помощи ключа K_C_/TGS – ключ для общения клиента к TGS, он пришел в AS_REPLY.

В сокращенном виде

От AS_REPLY отличается только используемым ключом. Там фиксированный ключ, связанный с клиентом, а здесь динамически назначенный ключ для связи клиента с TGS.

Операция APExchange

Клиент связывается с конкретным сервером и запрашивает у него службу. Состоит тоже из запроса и ответа.

AP_REQUEST

ver_no = 5 – номер версии
msg_type = 14 тип сообщения
ap_options битовое поле типа FLAGS. Используется только несколько битов

не используется
use_session_key session_key это ключ, который вставлен в билет. Если этот ключ установлен, значит его и использовать для шифрования. Если бит сброшен, то для шифрования данных нужно использовать ключ, который есть в аутентификаторе.
mutual_required необходима взаимная аутентификация клиента и сервера.

Ticket_C_/_S – билет на этот сервер
Authenticator_C_/_S – аутентикатор на этот сервер

Естественно, сервер проверяет билет и информацию, которая есть в аутентификаторе. Таким образом, этим сообщением клиент доказывает серверу свою подлинность. Но сам-то клиент не знает, он связался с подлинным сервером или нет. Что бы клиент мог тоже это узнать, сервер должен послать ответное сообщение. По правилам Kerberos аутентификация сервера не обязательна и это ответное сообщение может не посылаться. То есть установление соединения с сервером может быть короткое – клиент послал одно сообщение и сразу все заработало. Но если требуется, что бы сервер тоже доказывал свою подлинность, то должен устанавливаться флажок mutual_required, и это означает, что от сервера требуется ответ.

Сокращенный вид

И следующее сообщение – этот самый ответ, который не обязательный, но клиент может его потребовать.

AP_REPLY

ver_no = 5 – номер версии
msg_type = 15 тип сообщения

ctyme – временные отметки из Authenticator
cuser – временные отметки из Authenticator
subkey – из Authenticator
seq_number – из Authenticator

То, что отмечено белыми кружочками шифруется ключом сеанса, то есть ключом K_C_/_S.

Сокращенно

Что есть в билете?

ver_no = 5 – номер версии
crealm – ID_S.
cname – ID_S.

type – тип шифрования
FLAGS
K_C_/_S – ключ сеанса между будущими сторонами.
PARAMS

То, что выделено белыми кружочками – зашифровано ключом, связанным тем сервером, на который выдан этот билет (эту часть может прочесть только сервер) – K_S.

Сокращенно

Микро-анализ.

AS_REQUEST
AS_REPLY
TGS_REQ
TGS_REPLY
AP_REQ
AP_REPLY

Что происходит в Kerberos и на чем основана безопасность.

Запрос билета AS_REQUEST. Передается в открытом виде, и никаких секретов тут нет
AS_REPLY. AS отвечает и передает билет, который может прочитать только сервер назначения. И возвращает информацию об этом билете и в том числе тот же самый ключ, который в билете, и все это зашифровано ключом, связанным с клиентом (ключом, выработанным из пароля). Если клиент не знает этого пароля, то он не сможет сформировать ключ, не сможет прочесть. Далее, вот этот вот nounce защищает транзакцию от атаки повторения и злоумышленник не сможет подставить злостный Kerberos сервер. Аутентификатор генерируется в каждом сообщении заново – только так можно подтвердить свою подлинность здесь и сейчас. Аутентификатор это зашифрованные ключом сеанса между двумя сторонами ID_C, временная отметка по часам клиента и номер последовательности (считается, что будет каждый раз разным). Пара (временная отметка, номер последовательности) используется вместо nounce, и таким образом, обеспечивается защита от атаки повторения.
Сервер, получает этот аутентификатор. И если это удается расшифровать, то сервер получает ID_C, сравнивает с тем, что есть в сообщении, и таким образом клиент доказывает, что он действительно владеет этим ключом, который ему мог дать только Kerberos сервер в процессе корректной аутентификации, значит, это тот самый клиент. Где тут защита от атаки повторений? TS – временная метка. Но это слабая защита, потому что здесь предполагается синхронизованность часов клиента и сервера. Другое дело, что атака повторений в этой системе не дает никаких привилегий, это фактически, атака типа DoS (Denial of Service) Какой-то враг оттягивает на себя ресурсы, заставляет с собой общаться, но ничего получить не может, потому что он не может определить эти ключи. То есть, в реальные взаимоотношения он вступить не может, он может только обманывать на уровне неудающихся попыток установления соединений. Таким образом, при помощи аутентификатора доказывается подлинность (относительно здесь и сейчас, хотя мы считаем, что часы синхронизованы, это за рамками Kerberos). Что еще тут могло бы обсуждаться?
С последними транзакциями вроде все понятно. Аутентификатором клиент доказывает свою подлинность, а билетом доказывает свое право на использование сервера. Заодно в билете еще и ключ для будущего общения.
В конце сервер посылает информацию из аутентификатора, которую он должен был расшифровать, зашифрованную другим ключом (ключом сеанса). Клиент все это получает, сравнивает, и если это так, то значит сервер действительно смог расшифровать этот билет, значит, исходно он располагал своим собственным ключом, значит, это он.

Вот это самая интересная часть Kerberos. Такая изящная аутентификация при помощи одного алгоритма DES. Ну потом разрешили другие, но симметричные алгоритмы.

И остались еще другие техническиая информация. Какие еще бывают сообщения?

KRB_SAFE – передача данных с проверкой целостности (добавляется MAC код)
KRB_PRIV – передача данных с шифрованием.
KRB_CRED – обмен билетами между хостами или приложениями (проксирование, билет получает один хост/приложение для того что бы пользовался этим билетом другой хост/приложение)

Для всех сообщений используется транспорт UDP и порт 88.

Проблемы, которые отмечают сами разработчики этого протокола

Подвержен DoS атакам. Злоумышленник, вступая в ложные диалоги, может отвлекать ресурсы Kerberos сервера, прикладного сервера.
Атака угадывания пароля. Поскольку алгоритм перевода пароля в ключ известен, то можно предпринять такую атаку – перехватить сообщение и подбирая разные пароли пытаться что-то расшифровать, получить что-то осмысленное. Это можно делать не в процессе сетевых транзакций, а автономно.
Необходимость синхронизации времени. Аутентификация существенно зависит от того, что часы идут более или менее согласованно, и синхронизация времени может служить объектом атаки.
Нет механизма отмены ID_C и ID_S. То есть нет аналога отзывов сертификатов.

Blog

Аутентификатор еще одно важное понятие в Kerberos