Протоколы безопасного сетевого взаимодействия
Простой аутентификационный протокол
В незащищенном сетевом окружении любой клиент может использовать любой сервер в качестве сервиса. В этом случае существует очевидный риск для системы безопасности. Оппонент может попытаться представиться другим клиентом и получить неавторизованные привилегии на сервере. Для того чтобы избежать этой опасности, сервер должен иметь возможность проверить идентификацию клиента, который запрашивает сервис. Практически не представляется возможным, чтобы каждый сервер выполнял эту задачу при соединении с каждым клиентом.
Альтернативой является использование аутентификационного сервера AS, который знает пароли всех пользователей и хранит их в специальной базе данных. Кроме того, AS разделяет уникальный секретный ключ с каждым сервером. Эти ключи распределяются физически или некоторым другим безопасным способом. Рассмотрим следующий протокол, который является скорее гипотетичеким:
-
C
AS: IDC, PC, IDS
-
AS
C: Ticket -
C
S: IDC, Ticket Ticket = EKs [IDC, ADC, IDS]
Где:
С - клиент;
AS - аутентификационный сервер;
S - сервер;
IDC - идентификатор пользователя на С;
IDS - идентификатор S;
РС - пароль пользователя на С;
ADC - сетевой адрес С;
KS - секретный ключ шифрования, разделяемый AS и S.
В данном сценарии предполагается, что пользователь входит на рабочую станцию и хочет получить доступ к серверу S. Клиентский модуль С на пользовательской рабочей станции запрашивает пользовательский пароль и затем посылает сообщение AS, которое включает идентификатор пользователя, идентификатор сервера и пароль пользователя. AS проверяет в своей базе данных правильность пароля пользователя и то, что данному пользователю разрешен доступ к серверу S. Если обе проверки выполнены успешно, AS считает, что пользователь аутентифицирован, и должен теперь убедить сервер, что это так. Для того, чтобы это сделать, AS создает билет (ticket), который содержит идентификатор пользователя, сетевой адрес, с которого вошел пользователь, и идентификатор сервера. Этот билет шифруется с использованием секретного ключа, разделяемого AS и S.
Он посылается С. Так как билет зашифрован, его не может изменить ни С, ни оппонент.
Имея данный билет, С может теперь обращаться к S за сервисом. Для этого он посылает серверу сообщение, содержащее идентификатор C и билет. S расшифровывает билет и проверяет, совпадают ли идентификатор пользователя в билете и незашифрованный идентификатор пользователя в сообщении. Если это соответствие выполняется, то сервер считает пользователя аутентифицированным и предоставляет соответствующий сервис.
Каждая часть сообщения (3) важна. Билет зашифрован для предотвращения изменения или подделки. Идентификатор сервера IDS включается в билет, чтобы сервер мог убедиться, что он расшифровал билет корректно. IDC включается в билет, чтобы определить, что данный билет послан от имени С. Наконец, АDC служит для предотвращения следующей угрозы. Оппонент может перехватить билет, передаваемый в сообщении (2), затем использовать имя IDC и передать сообщение в форме (3) с другой рабочей станции. Сервер получит законный билет, который соответствует пользователю ID, и предоставит доступ пользователю с другой рабочей станции. Для предотвращения подобной атаки AS включает в билет сетевой адрес, с которого приходит первоначальный запрос. Теперь билет действителен только в том случае, если он передан с той же самой рабочей станции, с которой первоначально запрашивался.
