TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
■ Идентификатор транзакции
■ Текущий номер версии RPC
■ Номер программы
■ Версию программы
■ Номер процедуры
■ Мандат аутентификации
■ Проверочные сведения (verifier) аутентификации
■ Входные параметры
Рис. 15.5. Сообщения RPC
Если процедура выполнена успешно, ответ содержит результаты. Если при выполнении выявлены проблемы, ответ будет содержать информацию об ошибках.
15.9
Некоторые службы не нуждаются в защите. Для вывода времени дня на сервере служба RPC может быть оставлена открытой для общего доступа. Однако клиент, обращающийся к личным данным, должен обеспечить некоторую опознавательную информацию (проходить аутентификацию). В некоторых случаях важно, чтобы сервер также подтверждал свою подлинность. Не следует посылать номер своей кредитной карточки через систему интерактивных заказов, если не будет гарантии в подлинности сервера. Таким образом, в некоторых случаях аутентификационные данные должен предоставлять как клиент, так и сервер (они будут как в запросах, так и в ответах).
В сообщении запроса аутентификационные сведения RPC пересылаются в двух полях:
■ Поле мандата (credentials) — содержит идентификационную информацию.
■ Поле проверочных сведений аутентификации (verifier) — содержит дополнительную информацию и позволяет проверить идентификатор. Например, verifier мог бы содержать зашифрованный пароль и штамп времени.
Для аутентификации не существует единого стандарта. Реализовать проверку аутентификации должен разработчик каждого приложения. Именно он должен решить, что необходимо в каждом конкретном случае. Однако продолжаются работы по созданию единых стандартов для этой процедуры.
В настоящее время каждый метод аутентификации называется flavor (оттенок). Тип такого оттенка, используемый в мандатах или полях verifier, идентифицирован целым числом в начале поля. Новые типы аутентификации могут быть зарегистрированы таким же образом, что и новые программы. Поля мандата и verifier начинаются с целого числа.
15.9.1 Нулевая аутентификация
Нулевая аутентификация полностью соответствует своему названию. Не используется никакой аутентификационной информации — в полях мандата и verifier сообщений запросов и ответов содержатся одни нули.
15.9.2 Аутентификация систем
Аутентификация систем моделирует аналогичную информацию операционной системы Unix. Мандат системы содержит:
stamp (штамп) | Случайный идентификатор, сгенерированный вызывающим компьютером |
machinename (имя машины) | Имя запрашивающей машины |
uid (идентификатор пользователя) | Реальный номер идентификации пользователя, инициировавшего запрос |
gid (идентификатор группы) | Реальный номер идентификации группы пользователя, инициировавшего запрос |
gids (идентификаторы групп) | Список групп, к которым принадлежит пользователь |
Поле проверочных сведений аутентификации — нулевое.
Проверочные сведения аутентификации (verifier), возвращаемые сервером, могут быть пустыми или иметь оттенок short (краткие), означающий возвращение октета, определяющего систему. В некоторых реализациях этот октет используется как мандат в последующем сообщении от вызывающей стороны (мандат будет заменять информацию о пользователе и его группе).
Отметим, что этот способ не обеспечивает защиты. Следующие два метода применяют шифрование для защиты аутентификационной информации. Однако приходится выбирать между обеспечением безопасных служб RPC и достижением удовлетворительной производительности. Шифрование даже одного поля приводит к существенному снижению быстродействия службы, например NFS.
15.9.3 Аутентификация DCS
Стандарт шифрования данных (Data Encryption Standard — DES) использует симметричный алгоритм шифрования. DES — это федеральный стандарт обработки информации (Federal Information Processing Standard — FIPS), который был определен Национальным бюро стандартов США, в настоящее время называемым Национальным институтом стандартов и технологий (National Institute of Standards and Technology — NIST).
Аутентификация DES для RPC основана на сочетании асимметричных общедоступных и личных ключей с симметричным шифрованием DES:
■ Имя пользователя связано с общедоступным ключом.
■ Сервер шифрует ключ сеанса DES с помощью общедоступного ключа и посылает его клиентскому процессу пользователя.
■ Ключ сеанса DES используется для шифрования аутентификационной информации клиента и сервера.
15.9.4 Аутентификация в Kerberos
При аутентификации в системе Kerberos (по имени трехглавого сторожевого пса Цербера из древнегреческой мифологии. — Прим. пер.) используется сервер безопасности Kerberos, хранящий ключи пользователей и серверов (основанные на паролях). Kerberos аутентифицирует службу RPC с помощью:
■ использования секретных ключей (клиента и сервера), зарегистрированных на сервере безопасности Kerberos и распространяемых как ключи сеансов DES для клиентов и серверов
■ применения ключа сеанса DES для шифрования аутентификационной информации клиента и сервера
15.10 Пример сообщении RPC версии 2
На рис. 15.6 показан результат обработки монитором Sniffer компании Network General заголовка UDP и полей RPC из сообщения запроса к NFS о выводе атрибутов файла. Заголовки уровня связи данных и IP опущены, чтобы не загромождать рисунок.