Мандаты на выдачу мандатов.
Как уже отмечалось, долговременный ключ пользователя генерируется на основе его пароля. Чтобы лучше понять это, вернемся к нашему примеру. Когда Ольга проходит регистрацию, клиент Kerberos, установленный на ее рабочей станции, пропускает указанный пользователем пароль через функцию одностороннего хеширования (все реализации протокола Kerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применяться и другие алгоритмы). В результате генерируется криптографический ключ. В центре KDC долговременные ключи Ольги хранятся в базе данных с учетными записями пользователей. Получив запрос от клиента Kerberos, установленного на рабочей станции Ольги, KDC обращается в свою базу данных, находит в ней учетную запись нужного пользователя и извлекает из соответствующего ее поля долговременный ключ Ольги. Такой процесс – вычисление одной копии ключа по паролю и извлечение другой его копии из базы данных – выполняется всего лишь один раз за сеанс, когда пользователь входит в сеть впервые. Сразу же после получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos рабочей станции запрашивает сеансовый мандат и сеансовый ключ, которые используются во всех последующих транзакциях с KDC на протяжении текущего сеанса работы в сети. На запрос пользователя KDC отвечает специальным сеансовым мандатом для самого себя, так называемый мандат на выдачу мандатов (ticket-granting ticket), или мандат TGT. Как и обычный сеансовый мандат, мандат TGT содержит копию сеансового ключа для связи службы (в данном случае – центра KDC) с клиентом. В сообщение с мандатом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Мандат TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа – с помощью долговременного ключа пользователя. Получив ответ службы KDC на свой первоначальный запрос, клиент дешифрует свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью полученного сеансового ключа. Как и все другие сеансовые ключи, он имеет временный характер и действителен до истечения срока действия мандата TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key). С точки зрения клиента мандат TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент прежде всего обращается в кэш-память удостоверений и достает оттуда сеансовый мандат нужной службы. Если его нет, он начинает искать в этой же кэш-памяти мандат TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с мандатом TGT высылает в центр KDC. Одновременно туда направляется запрос на сеансовый мандат для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена – она требует сеансового ключа, аутентификатора и мандата (в данном случае мандата TGT). С точки же зрения службы KDC, мандаты TGT позволяют ускорить обработку запросов на получением мандатов, сэкономив несколько наносекунд на пересылке каждого из них. Центр распределения ключей KDC обращается к долговременному ключу пользователя только один раз, когда предоставляет клиенту первоначальный мандат на выдачу мандата. Во всех последующих транзакциях с этим клиентом центр KDC дешифрует мандаты TGT с помощью собственного долговременного ключа и извлекает из него сеансовый ключ регистрации, который использует для проверки подлинности аутентификатора клиента.
Асимметричная криптография для шифрования и дешифрования использует разные ключи, которые генерируются совместно. Наилучшая асимметричная система базируется на алгоритме, предложенном Rivest, Shamir и Adleman, и называется по инициалам авторов RSA.
Криптографические контрольные суммы являются одним из наиболее важных средств разработчиков криптографических протоколов. Криптографическая контрольная сумма или MIC (message integrity checksum) служат для контроля целостности сообщений и аутентификации.
RADIUS Сервер сетевого доступа NAS (Network Access Server) работает как клиент системы RADIUS (RFC-2138, 2618-2621). Клиент передает информацию о пользователе специально выделенным серверам RADIUS, и далее действует в соответствии с полученным откликом на эти данные. Серверы RADIUS принимают запросы от пользователей, осуществляют аутентификацию и выдают конфигурационную информацию, которая необходима клиенту, чтобы предоставить пользователю запрошенный вид услуг. Каждый вид услуг, предоставляемый NAS, представляет собой сессию. Начало сессии сопряжено с моментом начала предоставления данной услуги, а конец - со временем завершения этого процесса. Пользователь может иметь несколько сессий одновременно, если сервер поддерживает такой режим. Когда клиент сконфигурирован для использования RADIUS, любой пользователь предоставляет аутентификационные данные клиенту. Это может быть сделано с помощью традиционной процедуры login, когда пользователь вводит свое имя и пароль. В качестве альтернативы может использоваться протокол типа PPP, который имеет специальные пакеты, несущие аутентификационную информацию. Когда клиент получил такую информацию, он может выбрать для аутентификации протокол RADIUS. Для реализации этого клиент формирует запрос доступа (Access-Request), содержащий такие атрибуты как имя пользователя, его пароль, идентификатор клиента и идентификатор порта, к которому должен получить доступ пользователь. При передаче пароля используется метод, базирующийся на алгоритме MD5 (RSA Message Digest Algorithm [1]). Когда сервер RADIUS получил запрос, он проверяет корректность клиента-отправителя. Запрос, для которого сервер RADIUS не имеет общего секретного ключа (пароля), молча отбрасывается. Если клиент корректен, сервер RADIUS обращается к базе данных пользователей, чтобы найти пользователя, чье имя соответствует запросу. Пользовательская запись в базе данных содержит список требований, которые должны быть удовлетворены, прежде чем будет позволен доступ. Сюда всегда входит сверка пароля, но можно специфицировать клиента или порт, к которому разрешен доступ пользователя. Сервер RADIUS может посылать запросы к другим серверам, для того чтобы выполнить запрос, в этом случае он выступает в качестве клиента. Если хотя бы какое-то условие не выполнено, сервер посылает отклик "Access-Reject" (отклонение Access-Reject текст комментария. Если все условия выполнены, сервер может послать отклик-приглашение (Access-Challenge). Этот отклик может содержать текстовое сообщение, которое отображается клиентом и предлагает пользователю откликнуться на приглашение. RADIUS использует протокол UDP вместо TCP. UDP был выбран по чисто техническим причинам. RADIUS является протоколом, ориентированным на операции и имеющим ряд интересных особенностей: 1. Если запрос к первичному аутентификационному серверу не прошел, он должен быть переадресован вторичному серверу. Чтобы удовлетворить этому, копия запроса должна храниться на уровне выше транспортного, с тем, чтобы позволить альтернативную попытку. Отсюда следует, что необходим таймер ретрансмиссии. 2. Временные требования данного конкретного протокола значительно отличаются от тех, которые обеспечивает TCP. 3. Природа данного протокола не требует контроля состояния, что упрощает применение протокола UDP.
UDP полностью исключает влияние таких событий как отключение серверов, клиентов или каналов связи на работу системы. Любой клиент и сервер может открыть UDP обмен однажды и оставлять его в таком состоянии, игнорируя какие-либо сбои в сетевой среде. Один пакет RADIUS вкладывается в одну UDP-дейтограмму [2]. При этом порт назначения равен 1812 (десятичное). При формировании отклика коды портов отправителя и получателя меняются местами. Формат пакета RADIUS показан на рис. Разряды пронумерованы в порядке их передачи.
Рис. Формат пакета RADIUS
Поле код содержит один октети идентифицирует тип пакета RADIUS. Если получен пакет с неверным значением поля код, он молча отбрасывается. Стандартизованы следующие значения поля код:
Cпецификация стандартизованных значений атрибутов:
Пример Удаленный доступ пользователя на указанную ЭВМ (Telnet) Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP пакете серверу RADIUS для пользователя с именем NEMO, подключаемого к порту 3. Code = 1 (Access-Request) User-Password = {16-октетный пароль, дополненный в конце нулями и объединенный операцией XOR с MD5(общий секретный пароль|Request Authenticator)} NAS-IP-Address = 192.168.1.16 Сервер RADIUS аутентифицирует NEMO и посылает запрос Access-Accept в UDP пакете серверу NAS, требуя от него организации удаленного доступа пользователя NEMO к ЭВМ с заданным адресом. Code = 2 (Access-Accept) id (0), приведенного выше Request Authenticator, атрибутов этого отклика и общего секретного пароля } Атрибуты:
|
