Система единого входа в сеть на основе протокола Kerberos

7.3.1. Общие сведения о протоколе Kerberos

Протокол Kerberos является универсальным протоколом аутентифика-

ции, основанным на распределении симметричных ключей шифрования неко-

торым доверенным сервером. Протокол Kerberos является открытым стандар-

том и описан в документе RFC 1510.

С  помощью  протокола  Kerberos  распределяются  криптографические ключи в некоторой области (realm), которая имеет строковый идентификатор, как правило, совпадающий с именем DNS-домена. Например, для компьюте- ров    DNS-домена    example.com    можно    определить    область    Kerberos EXAMPLE.COM (имя области всегда заглавными буквами).

Каждая учетная запись в системе Kerberos называется сущностью (prin- cipal), причем учетные записи существуют не только для пользователей, но и

для   каждого   сервиса.   Имя   учетной   записи   имеет   следующий   вид:

«user@REALM» (где user — имя пользователя, а RELAM — имя области).

Например, имя учетной записи пользователя root из домена «example.com» —

«root@EXAMPLE.COM».

Учетные записи сервисов имеют вид /@REALM, где

name1 — как правило, имя сервиса, а name2 — полное DNS-имя компьютера.

Например, «HTTP/ws-linux.exampel.com@EXAMPLE.COM». Важно отметить,

что имена сущностей Kerberos чувствительны к регистру.

Рис. 7.6. Аутентификация по протоколу Kerberos

Информация обо  всех  учетных  записях,  а  также  их  долговременные ключи (в случае пользователя это, например, хэш его пароля, т. е. ключ, кото- рый будет действителен не меньше месяца) хранятся на специальном сервере, называемом центром распределения ключей (Key Distribution Centre — KDC). Когда у пользователя появляется необходимость в использовании некоторого сервиса, то он обращается в центр распределения ключей с запросом кратко-

временного сеансового ключа. KDC возвращает ключ в двух вариантах — один зашифрован долговременным ключом пользователя, другой зашифрован долговременным ключом сервиса. Ответ KDC называется билетом, поскольку кроме ключа содержит и  некоторую дополнительную информацию. После этого пользователь самостоятельно пересылает билет сервиса, и у них появля- ется некоторый общий секрет, который уже можно использовать как для ау- тентификации, так и для защиты канала (рис. 7.6).

Применение доверенного сервера, который хранит секреты всех своих пользователей, дает возможность обойтись без асимметричных алгоритмов

шифрования,  что  делает  протокол  Kerberos  более  легким  в  реализации  и управлении.

На приведенной схеме видно, что каждый сервис должен хранить собст-

венный долговременный ключ. В Unix-системах ключи сервисов хранятся в так называемом keytab-файле (понятно, что данный файл не должен быть дос- тупен для чтения всем пользователям), в ОС Windows ключ хранится в ло- кальной базе учетных записей SAM (стандартными средствами просмотреть информацию о ключе невозможно).

Долговременный ключ  пользователя, как  уже  упоминалось выше, —

это, например, некоторая хэш-функция его пароля. Таким образом, в приве- денной выше схеме пользователь все равно должен вводить свой пароль при обращении к очередному сервису. Для обеспечения реальной возможности однократной аутентификации схема взаимодействия клиента, сервера и KDC реально несколько отличается от приведенной на рис. 7.6. В процессе аутен- тификации при входе в сеть пользователь получает специальный билет, назы- ваемый  ticket  granting  ticket  (TGT),  использующийся  для  аутентификации пользователя в KDC (рис. 7.7).

Полученные пользователем билеты сохраняются в специальном защи-

щенном кэше (в случае Unix-систем это файл, доступ к которому имеет только пользователь, получивший билет, в Windows — это защищенное хранилище

модуля SSPI, т. е. оперативная память). При необходимости билет может пе-

реместиться на другой компьютер (например, если пользователь открыл сеанс по SSH или RDP), но при этом действительным он останется только в том

случае, если в нем присутствует специальный флаг (соответственно, на KDC

можно задавать, какие из пользователей будут получать этот флаг в билете, а какие нет).

Из изложенного выше механизма следует, что KDC не аутентифицирует клиента перед самим собой. Аутентификация есть только неявная — смог ли клиент воспользоваться тем сеансовым ключом, который он получил, или нет.

Это создает две проблемы: во-первых, злоумышленник может получить билет пользователя и за какое-то время извлечь сеансовый ключ (например, если применялся слабый алгоритм шифрования); во-вторых, злоумышленник мо-

жет запросить TGT и после пытаться взломать долговременный ключ пользо-

вателя.

Рис. 7.7. Механизм однократной аутентификации при помощи вспомогательного билета

TGT

Первой проблемы на самом деле не существует, поскольку билет Kerbe- ros содержит информацию о своем времени жизни (по умолчанию 8 часов). Поэтому к тому времени, когда злоумышленник сможет извлечь сеансовый ключ, последний окажется уже недействительным.

Вторая проблема решается при помощи механизма преаутентифкации.

Данный механизм не зафиксирован в RFC 1510, т. е. каждый производитель может добавлять свои механизмы, однако приведен один вариант, который наиболее широко распространен в настоящее время — это преаутентификация по меткам времени. Работает данный механизм следующим образом: клиент в своем запросе, в специальном разделе пакета Kerberos, отправляет зашифро- ванную своим долговременным ключом метку времени, сервер расшифровы- вает эту метку времени и сверяет ее со своим текущим временем. Если разни- ца не превышает некоторого порогового значения (по умолчанию 3 минуты), то считается, что клиент прошел преаутентифкацию, и ему можно выдавать

билет. Понятно, что данный механизм требует синхронизации времени между всеми клиентами Kerberos и всеми KDC.

Источник: Андрончик А. Н., Богданов В. В., Домуховский Н. А., Коллеров А. С., Синадский Н. И., Хорьков Д. А., Щербаков М. Ю., Защита информации в компьютерных сетях. Практический курс