|
Bog BOS: SASL: общие принципы, механизмы, использование |
|
Последние изменения: |
Последнее изменение файла: 2008.02.05
Скопировано с www.bog.pp.ru: 2024.11.21
SASL (Simple Authentication and Security Layer) определяет общий метод добавления поддержки аутентификации к протоколам, ориентированным на соединение (POP3, IMAP4, SMTP, FTP, telnet, ACAP, LDAPv3). Рекомендуется предварительное знакомство с алгоритмами криптографически стойкого хеширования. В статье описываются общие принципы работы, некоторые конкретные механизмы, реализация с помощью cyrus-sasl.
SASL определяет как добавить к различным протоколам команду идентификации и аутентификации клиента и определения протокола обеспечения безопасности (шифрования) - AUTH (POP3), AUTHENTICATE (IMAP4). Для аутентификации могут быть использованы различные механизмы. Имена механизмов регистрируются IANA. Протокол определяется именем сервиса, задаваемым разработчиком протокола. Имена сервисов регистрируются IANA.
Имя требуемого механизма задаётся клиентом в команде аутентификации. Если сервер поддерживает указанный механизм, он посылает клиенту последовательность окликов (challenges), на которые клиент посылает ответы (responses), чтобы удостоверить себя. Содержимое окликов и ответов определяется используемым механизмом и может представлять собой двоичные последовательности произвольной длины. Кодировка последовательностей определяется прикладным протоколом. Вместо очередного оклика сервер может послать подтверждение аутентификации или отказ. Кодировка также определяется протоколом. Вместо ответа клиент может послать отказ от аутентификации. Кодировка опять определяется протоколом. В результате обменов откликам и ответами должна произойти аутентификация (или отказ), передача идентификатора клиента (пустой идентификатор влечёт получение идентификатора из аутентификации) серверу и, возможно, договорённость об использовании безопасного транспортного протокала (security layer), включая максимальный размер буфера шифрования. Идентификатор клиента может отличаться от идентификатора, определяемого из аутентификации, для обеспечения возможности работы прокси. Шифрование начинается немедленно после получения подтверждения аутентификации от сервера в виде обмена буферами с шифрованными текстами (перед каждым буфером посылается его длина).
Опциональным параметром команды аутентификации может быть первый ответ клиента (чтобы сэкономить один обмен по сети). Подтверждение аутентификации может содержать дополнительную информацию (например, аутентификацию сервера).
Метод подвержен атакам способом "человек в середине", с помощью которого можно выбрать наименее защищённый механизм из имеющихся.
Прикладный протокол может иметь команду (STARTTLS для SMTP), позволяющую перейти к использованию безопасного транспортного протокола несовместимого с SASL до аутентификации. Если прикладной протокол изначально запущен под достаточно безопасным транспортным уровнем, то использование SASL не принесёт много пользы.
CRAM-MD5 (RFC 2195). Сервер в приглашении или первом оклике посылает сроку, состоящую из случайного числа, временной отметки и доменного имени сервера (кодируется как идентификатор сообщения). Ответ должен содержать идентификатор клиента, пробел и HMAC-MD5 оклика. В качестве ключа в HMAC-MD5 используется разделяемый секрет. В принципе, HMAC-MD5 позволяет хранить на сервере не сам секрет, а некоторую производную (contexts), однако это не увеличивает безопасность. Аутентификации сервера нет. Подвержен атаке со стороны фальшивого сервера (chosen plaintext attack).
DIGEST-MD5 (RFC 2831). Начальная аутентификация: сервер посылает оклик, состоящий из realm (область действия, подсказывает клиенту какую пару имя/пароль выбрать; например, имя хоста), случайная строка, уровень обеспечиваемой защиты (только аутентификация, аутентификация и защита целостности, аутентификация и защита целостности и шифрование), максимальный размер буфера шифрования, наличие поддержки utf-8 для имени и пароля, алгоритм аутентификации (обязательно md5-sess), алгоритм шифрования (3des, des, rc4-40, rc4, rc4-56; всё, кроме rc4 и 3des лучше не использовать). Клиент отвечает строкой, содержащей: идентификатор клиента, realm, полученную от сервера случайную строку, случайную строку клиента, номер запроса (позволяет серверу заметить попытку replay attack), приемлимый уровень защиты, имя сервиса, DNS имя или адрес сервера, исходное имя сервера (имя до обработки типа извлечения информации из MX), digest-uri (сочетание имени сервиса, имени сервера и исходного имени сервера), подтверждающий знание пароля ответ на оклик (MD5 от имени пользователя, realm, пароля, случайной строки сервера, случайной строки клиента, идентификатора клиента, номера запроса, уровня защиты, digest-uri; некоторые компоненты берутся в виде MD5, некоторые в исходном виде, некоторые в обоих видах), максимальный размер буфера шифрования, использование utf-8 для имени и пароля, принятый алгоритм шифрования, идентификатор клиента. Сервер проверяет ответ на оклик и посылает ответ на ответ в похожем формате (но всё же отличающемся, чтобы клиент мог убедиться в подлинности сервера). Предусматривается упрощённый протокол повторной аутентификации (начинается сразу с посылки клиентом ответа с увеличенным на 1 номером запроса). Для обеспечения защиты целостности клиент и сервер создают ключи для HMAC-MD5 из MD5 от имени пользователя, realm, пароля, случайной строки сервера, случайной строки клиента, идентификатора клиента, текстовой константы (отличается для сервера и клиента). К каждому сообщению добавляется начало HMAC-MD5, тип сообщения и его номер. Если используется уровень защиты с шифрованием, то клиент и сервер создают ключи аналогичным образом. Каждое сообщение шифруется принятым алгоритмом шифрования и дополняется частично шифрованным заголовком, обеспечивающим целостность. Данный механизм слабее системы с открытыми ключами, но лучше CRAM-MD5.
PLAIN (RFC 2595). Применяется в сочетании с TLS (команда STARTTLS для IMAP, команда STLS для POP3), обеспечивающим шифрованное соединение и аутентификацию сервера. Обязательно наличие набора TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA в реализации TLS. Аутентификация клиента при установленном TLS соединении может обеспечиваться с помощью SASL механизма EXTERNAL (команда AUTHENTICATE EXTERNAL или AUTH EXTERNAL). Клиент посылает идентификатор авторизации, идентификатор аутентификации и пароль в открытом виде. Сервер проверяет идентификатор аутентификации и пароль на соответствие своей базе и наличие у данного идентификатора аутентификации права на идентификатор авторизации.
ANONYMOUS (RFC 2245). Пустой оклик сервера, почтовый адрес или ещё что-нибудь в качестве ответа.
EXTERNAL (RFC 2222). Клиент посылает первый ответ, содержащий идентификатор клиента. Сервер использует внешние средства для аутентификации клиента в соответствии с этим идентификатором. Используется, если прикладной протокол работает поверх IPSec или TLS.
OTP (RFC 2444; One-Time-Password). Генератор одноразовых паролей использует оклик сервера и секрет клиента для получения пароля на один сеанс. Последовательность паролей для одного и того же отклика получается с помощью многократного применения MD5, SHA1 или MD4. От сервера требуется хранение БД последних использованных паролей для каждого пользователя. Аутентификации сервера нет. Почему-то непопулярен (проблемы с несколькими открытыми сессиями или требуется слишком качественный датчик случайных чисел?).
KERBEROS_V4 (RFC 2222), KERBEROS_V5. Требуется наличие инфраструктуры Kerberus.
GSSAPI (RFC 2222).
SKEY (RFC 2222; помечен, как устаревший).
SecurID (RFC 2808). Требуется оборудование.
NTLM, NMAS_LOGIN, NMAS_AUTHEN, NMAS-SAMBA-AUTH.
Итого, PLAIN поверх TLS (пароли на сервере в зашифрованном виде) или DIGEST-MD5 с шифрованием (пароли придётся держать открытыми).
Библиотека Cyrus SASL (версия 2) обеспечивает API для серверов и клиентов, использующих механизмы SASL: DIGEST-MD5, PLAIN, EXTERNAL, CRAM-MD5, ANONYMOUS, GSSAPI (Kerberos 5), LOGIN, SRP, NTLM, OTP, KERBEROS_V4, PASSDSS (версия 2.1.21). В CentOS 4.4 разбит на пакеты (версия 2.1.19): cyrus-sasl, cyrus-sasl-md5, cyrus-sasl-plain, cyrus-sasl-gssapi, cyrus-sasl-ntlm, cyrus-sasl-sql, cyrus-sasl-devel. В FC6 добавлены пакеты cyrus-sasl-lib и cyrus-sasl-ldap (версия 2.1.22). Используется в Cyrus IMAPd, OpenLDAP, Sendmail, Mutt, sieveshell и других. Для хранения секретов на стороне сервера используется Berkeley DB, gdbm или ndbm (в пакетах собрана для Berkeley DB (Hash, version 8, native byte-order)).
Переменная окружения SASL_PATH может содержать имя директории с библиотеками (по умолчанию - /usr/lib/sasl2).
Набор библиотек включает ядро (glue) libsasl2.so и модули:
Файлы конфигурации по умолчанию для каждого приложения лежат в /usr/lib/sasl2/имя-приложения.conf. В каждой строке файла задаётся значение одной опции в виде: имя-опции, двоеточие, значение. Приложение может иметь свой файл настройки в своём формате (например, в файле настройки Cyrus IMAP опции SASL имеют те же имена, но с добавлением префикса sasl_).
Опции конфигурационного файла (c):
Утилита saslpasswd2 используется для занесения паролей в БД, из которой их сможет извлекать libsasldb. Параметр - идентификатор пользователя (идентификаторы аутентификации и авторизации совпадают). Ключи:
Утилита sasldblistusers2 выдаёт список идентификаторов и realm из указанной БД (/etc/sasldb2). И ещё она выдаёт слово userPassword вместо пароля ;).
Сервер saslauthd позволяет верифицировать открытые (plaintext) пароли с помощью PAM, LDAP, Kerberos, /etc/shadow для библиотеки Cyrus SASL. Интерфейс с Cyrus SASL - сокет /var/run/saslauthd/mux. Записи в syslog делаются с источником LOG_AUTH. Ключи запуска:
Тестирование с помощью sasl2-sample-server/sasl2-sample-client:
sasldb_path: ~/sasldb2
Тестирование с помощью sasl2-sample-server/sasl2-sample-client (MySQL):
CREATE DATABASE passwords;
USE passwords;
CREATE TABLE realm (id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL);
CREATE TABLE service (id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL);
CREATE TABLE authentication (id_realm BIGINT UNSIGNED NOT NULL, \
id_service BIGINT UNSIGNED NOT NULL, id_authentication VARCHAR(255) NOT NULL, \
password VARBINARY(255) NOT NULL);
insert realm (name) values ('результат hostname');
insert service (name) values ('testservice');
insert authentication (1, 1, 'testuser', 'testpassword');
pwcheck_method: auxprop
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: имя-хоста-с-MySQL
sql_user: имя-пользователя-MySQL
sql_passwd: его-пароль
sql_database: passwords
sql_usessl: yes
sql_select: SELECT password FROM authentication WHERE \
id_realm = (SELECT id FROM realm WHERE name = '%r') AND \
id_service = (SELECT id FROM service WHERE name = 'testservice') \
AND id_authentication = '%u'
Хранения паролей в БД мы добились, но их приходится помещать туда в открытом виде, что неприятно. К счастью, добрые люди выложили заплатку, позволяющую хранить пароли в зашифрованном виде (при использовании механизма PLAIN; естественно, его можно использовать только под прикрытием TLS). При шифровании используется функция crypt() (ENCRYPT() в MySQL), которая в Linux может также шифровать в режиме MD5CRYPT (соль или зашифрованный пароль должны начинаться со строки "$1$"). Итак, соберём пакет
Patch14: cyrus-sasl-2.1.19-cryptplain.patch ... %patch14 -p1 -b .cryptplain
Аналогичную вивисекцию удалось сделать над cyrus-sasl-2.1.21-10.src.rpm из FC5 и подменить ею пакеты cyrus-sasl* из CentOS 4.3 (необходимо учесть появление нового пакета cyrus-sasl-lib).
И над cyrus-sasl-2.1.22-4.src.rpm из CentOS 5.1/x86_64 (заплатка для 2.1.22).
А вот сделать выбор колонки в зависимости от используемого механизма не удалось. В %p подставляется сначала userPassword и делается запрос, потом cmusaslsecretИМЯМЕХАНИЗМА и делается второй запрос, затем читается первая строка суммарного результата (естественно, не та). При попытке заблокировать первый запрос процесс аутентификации разваливается.
Отличия версий (новые возможности и проблемы с совместимостью) |
|
Bog BOS: SASL: общие принципы, механизмы, использование |
|
Последние изменения: |