Просмотр исходного текста страницы SASL (Simple Authentication and Security Layer)

'''SASL''' ({{lang-en|'''S'''imple '''A'''uthentication and '''S'''ecurity '''L'''ayer}}) определяет общий метод добавления поддержки аутентификации к протоколам, ориентированным на соединение ([[POP3 (Post Office Protocol v3)|POP3]], IMAP4, [[SMTP (Simple Mail Transfer Protocol)|SMTP]], [[FTP (File Transfer Protocol)|FTP]], telnet, [[ACAP (Application Configuration Access Protocol)|ACAP]], LDAPv3).

== Понятие SASL ==
SASL ( англ. Simple Authentication and Security Layer — простой уровень аутентификации и безопасности) — это фреймворк (каркас) для предоставления аутентификации и защиты данных в протоколах на основе соединений. Он разделяет механизмы аутентификации от прикладных протоколов, в теории позволяя любому механизму аутентификации, поддерживающему SASL, быть использованным в любых прикладных протоколах, которые используют SASL. Фреймворк также предоставляет слой защиты данных. Для использования SASL протокол включает команду для идентификации и аутентификации пользователя на сервере и для опциональной защиты переговоров последующей интерактивности протокола. Если это используется в переговорах, то слой безопасности вставляется между протоколом и соединением.<br />
В 1997 Джон Гардинер Майерс написал изначальную спецификацию SASL (RFC 2222) при университете Карнеги-Меллона. В 2006 году этот документ утратил силу после введения RFC 4422, под редакцией Алексея Мельникова (Alexey Melnikov) и Курта Зейлинга. <ref group="Источник"> Simple Authentication and Security Layer // Wikipedia.[2017—2017]. Дата обновления:31.10.17. URL: https://ru.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer (дата обращения: 04.11.2017)</ref>

== Общие принципы работы SASL==
SASL определяет как добавить к различным протоколам команду идентификации и аутентификации клиента и определения протокола обеспечения безопасности (шифрования) - AUTH (POP3), AUTHENTICATE (IMAP4). Для аутентификации могут быть использованы различные механизмы. Имена механизмов регистрируются [[IANA (Internet Assigned Numbers Authority)|IANA]]. Протокол определяется именем сервиса, задаваемым разработчиком протокола. Имена сервисов регистрируются [[IANA (Internet Assigned Numbers Authority)|IANA]].<br />
====Процесс аутентификации====
Имя требуемого механизма задаётся клиентом в команде аутентификации. Если сервер поддерживает указанный механизм, он посылает клиенту последовательность окликов (challenges), на которые клиент посылает ответы (responses), чтобы удостоверить себя. Содержимое окликов и ответов определяется используемым механизмом и может представлять собой двоичные последовательности произвольной длины. Кодировка последовательностей определяется прикладным протоколом. Вместо очередного оклика сервер может послать подтверждение аутентификации или отказ. Кодировка также определяется протоколом. Вместо ответа клиент может послать отказ от аутентификации. Кодировка опять определяется протоколом.<br />
В результате обменов откликам и ответами должна произойти [[аутентификация]] (или отказ), передача идентификатора клиента (пустой идентификатор влечёт получение идентификатора из аутентификации) серверу и, возможно, договорённость об использовании безопасного транспортного протокола (security layer), включая максимальный размер буфера шифрования. Идентификатор клиента может отличаться от идентификатора, определяемого из аутентификации, для обеспечения возможности работы прокси. Шифрование начинается немедленно после получения подтверждения аутентификации от сервера в виде обмена буферами с шифрованными текстами (перед каждым буфером посылается его длина).<br />
Опциональным параметром команды аутентификации может быть первый ответ клиента (чтобы сэкономить один обмен по сети). Подтверждение аутентификации может содержать дополнительную информацию (например, аутентификацию сервера).
Метод подвержен атакам способом "человек в середине", с помощью которого можно выбрать наименее защищённый механизм из имеющихся.
Прикладной протокол может иметь команду (STARTTLS для [[SMTP (Simple Mail Transfer Protocol)|SMTP]]), позволяющую перейти к использованию безопасного транспортного протокола несовместимого с SASL до аутентификации. Если прикладной протокол изначально запущен под достаточно безопасным транспортным уровнем, то использование SASL не принесёт много пользы. <ref group="Источник"> SASL: общие принципы, механизмы, использование // Bog BOS. [2017—2017]. Дата обновления:24.10.17. URL: http://www.bog.pp.ru/work/SASL.html (дата обращения: 06.11.2017)</ref><br />
====Особенности SASL====
SASL не является протоколом, но является средой, которая может использоваться с такими протоколами, как [[SMTP (Simple Mail Transfer Protocol)|SMTP]]. Для каждого протокола, использующего SASL, будет спецификация (Интернет-стандарт в случаях, когда базовый протокол является стандартом Интернета) относительно того, как протокол использует SASL. Это означает, что SASL может использоваться с широким спектром протоколов и может быть адаптирован к деталям работы конкретных протоколов. <ref group="Источник">Simple Authentication & Security Layer (SASL) // Isode Ltd. [2002-2016]. URL: https://www.isode.com/products/sasl.html (дата обращения: 27.05.2017)</ref>
Основная операция SASL проста. Сервер предоставляет список поддерживаемых механизмов аутентификации, а затем клиент говорит, какой из них будет использоваться (на основе возможностей клиента и требований безопасности).

=== Структура ===
SASL предоставляет структуру, которая позволяет протоколам приложений согласовывать согласованный механизм аутентификации. SASL может включать (в зависимости от согласованных механизмов)
* Аутентификацию сервера клиентом.
* Аутентификацию клиента на сервере.
Идентификационный идентификатор аутентификации SASL также обеспечивает элегантный механизм, позволяющий эффективно управлять приложениями с использованием простых «идентификаторов» в конфигурации на основе каталогов и скрыть имена каталогов от конечного пользователя.
Концептуально SASL представляет собой схему, обеспечивающую уровень абстракции между протоколами и механизмами (Показано на рисунке).<br />
[[Файл:Структура sasl.png|центр|Структура SASL]] <br />
Можно разработать и реализовать схему таким образом, чтобы абстрагироваться от конкретных деталей механизмов. Реализация такой схемы, как и реализации механизмов могут использоваться не только множеством реализаций конкретного протокола, но и реализациями различных протоколов.
Для использования SASL каждый протокол обеспечивает метод идентификации используемого механизма, метод обмена обусловленными механизмом запросами со стороны сервера и откликами клиентов, а также метод обмена результатами аутентификации.
=== Принцип работы на примере ===
Клиент и сервер могут находится в разных сетях, которые построены и сконфигурированы разными администраторами, каждый из которых имеет свой взгляд на политику сетевой безопасности.Предположим, что один из них сконфигурировал сервис таким образом, что тот позволяет аутентифицировать пользователя через Kerberos5 (условное обозначение механизма – GSSAPI), с помощью пароля, закодированного по алгоритму MD5 (CRAM-MD5) и простого текстового пароля (PLAIN). Если в клиенте настроена поддержка какого-нибудь из этих механизмов, то SASL позволяет провести аутентификацию посредством именно этого механизма, причем в случае множественного пересечения будет выбран наиболее сильный. Программная реализация выглядит одинаково - разработчик должен инициализировать библиотеку (c помощью функций ''sasl_client/server_new, ..._init, ..._start'') и затем войти в цикл аутентификации. На каждом шаге цикла программа должна прочитать блок данных полученный по сети (реплика клиента/сервера) и передать его функции '''sasl_client/server_step'''. На выходе функции контролируется возвращаемое значение и один из ссылочных параметров. Ссылочный параметров передается по сети без дополнительной обработки, а возвращаемое значение анализируется и в зависимости от его значение принимается решение о продолжении или остановки цикла аутентификации. Цикл прекращается когда возвращаемое значение станет равным SASL_OK, что означает успешную аутентификацию, или функция вернет сообщение об ошибке, что означает отказ в аутентификации. Хотя число шагов, которое требуется для подтверждения идентичности пользователя может быть различно для разных механизмов аутентификации, да и сам способ ввода пароля (или его отсутствие) в клиентском приложении может быть различным, но сам алгоритм аутентификации при этом остается тем же самым.  <ref group="Источник"> SASL – модуль сетевой аутентификации пользователей.[2018—2018]. Дата обновления:24.05.18. URL: http://post.hppi.troitsk.ru/~mike/sasl_krb/sasl_krb.html (дата обращения: 24.05.2018)</ref>

== Механизмы ==
Механизмы SASL реализуют серию запросов и ответов. Механизмы условно можно разделить на 3 группы. '''Первая группа''', наиболее слабые механизмы – это аутентификация посредством открытых текстовых паролей, PLAIN и LOGIN.
===== [[PLAIN]] (RFC 2595) =====
Применяется в сочетании с [[TLS (Transport Layer Security)|TLS]] (команда STARTTLS для [[IMAP (Internet Message Access Protocol)|IMAP]], команда STLS для [[POP3 (Post Office Protocol v3)|POP3]]), обеспечивающим шифрованное соединение и аутентификацию сервера. Обязательно наличие набора TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA в реализации TLS. Аутентификация клиента при установленном TLS соединении может обеспечиваться с помощью SASL механизма EXTERNAL (команда AUTHENTICATE EXTERNAL или AUTH EXTERNAL). Клиент посылает идентификатор авторизации, идентификатор аутентификации и пароль в открытом виде. Сервер проверяет идентификатор аутентификации и пароль на соответствие своей базе и наличие у данного идентификатора аутентификации права на идентификатор авторизации.

===== [[ANONYMOUS]] (RFC 2245) ===== 
Пустой оклик сервера, почтовый адрес или ещё что-нибудь в качестве ответа.
Различие между ними только в формате, в котором имя и пароль пользователя передаются по сети от клиента к серверу. Это очень слабые механизмы (слабее них только ANONYMOUS открывающий  доступ без пароля любому пользователю), поскольку пароли могут быть перехвачены злоумышленником в момент передачи по сети. Если же системный администратор решит использовать эти механизмы, то ему нужно озаботиться поиском внешнего способа криптования канала передачи, например, с помощью [[SSL (Secure Sockets Layer)|SSL]]/[[TLS (Transport Layer Security)|TLS]]. <br />
'''Вторая группа механизмов –''' это механизмы с общим ключом, [[CRAM-MD5]], [[DIGEST-MD5]] и несколько особняком стоящим от них механизмом одноразовых паролей – OTP. Слабость механизмов [[CRAM-MD5]] и [[DIGEST-MD5]] состоит в том, что хотя пароли и передаются по сети в зашифрованном виде, но они могут быть перехвачены и взломаны offline с помощью простого перебора. С другой стороны, при использовании этих механизмов требуется наличие незашифрованных паролей на почтовом сервере, где их безопасность бывает сложно гарантировать. Метод одноразовых паролей в этом смысле более безопасен. Идея этого метода состоит в создании последовательности легко запоминающихся фраз, сгенерированных из одного секретного пароля. Этот список хранится на сервере и время от времени пополняется. Для подключении к серверу пользователь использует очередную фразу из сгенерированного списка как свой пароль, после чего эта фраза из списка вычеркивается и для следующего подключения должна быть использована следующая в списке. Понятно, что перехват пароля ничего не дает злоумышленнику, хотя по-прежнему остается опасность, что злоумышленник сумеет завладеть всем списком одноразовых паролей, хранящимся на сервере.  <ref group="Источник"> SASL – модуль сетевой аутентификации пользователей // hppi.troitsk.ru. [2017—2017]. Дата обновления:24.10.17. URL: http://post.hppi.troitsk.ru/~mike/sasl_krb/sasl_krb.html (дата обращения: 06.11.2017)</ref>

===== [[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 (Domain Name System)|DNS]] имя или адрес сервера, исходное имя сервера (имя до обработки типа извлечения информации из MX), digest-uri (сочетание имени сервиса, имени сервера и исходного имени сервера), подтверждающий знание пароля ответ на оклик ([[MD5]] от имени пользователя, realm, пароля, случайной строки сервера, случайной строки клиента, идентификатора клиента, номера запроса, уровня защиты, digest-uri; некоторые компоненты берутся в виде MD5, некоторые в исходном виде, некоторые в обоих видах), максимальный размер буфера шифрования, использование utf-8 для имени и пароля, принятый алгоритм шифрования, идентификатор клиента. Сервер проверяет ответ на оклик и посылает ответ на ответ в похожем формате (но всё же отличающемся, чтобы клиент мог убедиться в подлинности сервера). Предусматривается упрощённый протокол повторной аутентификации (начинается сразу с посылки клиентом ответа с увеличенным на 1 номером запроса). Для обеспечения защиты целостности клиент и сервер создают ключи для HMAC-MD5 из MD5 от имени пользователя, realm, пароля, случайной строки сервера, случайной строки клиента, идентификатора клиента, текстовой константы (отличается для сервера и клиента). К каждому сообщению добавляется начало HMAC-MD5, тип сообщения и его номер. Если используется уровень защиты с шифрованием, то клиент и сервер создают ключи аналогичным образом. Каждое сообщение шифруется принятым алгоритмом шифрования и дополняется частично шифрованным заголовком, обеспечивающим целостность. Данный механизм слабее системы с открытыми ключами, но лучше [[CRAM-MD5]].<br />
'''Третья группа –''' механизмы использующие [[Kerberos]] (GSSAPI и KEBEROS_V4). KEBEROS_V4 применяется для аутентификации по старому, не очень надежному, так как требуется наличие инфраструктуры, но тем не менее все еще используемому протоколу Kerberos4, а GSSAPI следует понимать как синоним Kerberos5, более современной версии Kerberos.
Также есть и такие механизмы, как:
* [[EXTERNAL]] (RFC 2222). Клиент посылает первый ответ, содержащий идентификатор клиента. Сервер использует внешние средства для аутентификации клиента в соответствии с этим идентификатором. Используется, если прикладной протокол работает поверх IPSec или TLS.
* [[OTP]] (RFC 2444; One-Time-Password). Генератор одноразовых паролей использует оклик сервера и секрет клиента для получения пароля на один сеанс. Последовательность паролей для одного и того же отклика получается с помощью многократного применения MD5, SHA1 или MD4. От сервера требуется хранение баз данных последних использованных паролей для каждого пользователя. Аутентификации сервера нет.
* GSSAPI (RFC 2222).
* SKEY (RFC 2222; устаревший).
* SecurID (RFC 2808). Требуется оборудование.
=== Выбор механизма === 
Выбор механизма определяется процедурой “автоподстройки”, происходящей по сети между клиентской и серверной программой. Помимо разных механизмов SASL предлагает различные способы хранения паролей, которые в терминологии SASL называются методами. Системный администратор должен решить, какой из методов он будет использовать, причем можно подбирать метод индивидуально для каждого приложения. Возможные варианты: собственная база данных SASL (''sasldb2''), база данных [[LDAP (Lightweight Directory Access Protocol)|LDAP]], внешняя SQL-совместимая база данных, системные файлы с идентификационной информацией о пользователях (''/etc/passwd'', ''/etc/shadow''), использование инфраструктуры [[PAM (Pluggable Authentication Modules)|PAM]] или [[Kerberos]]. В последнем случае не нужно путать Kerberos, как метод, с механизмами GSSAPI и KERBEROS_V4. Использование этого метода позволяет просто использовать базу данных Kerberos как хранилище паролей, без необходимости развертывания всей инфраструктуры Kerberos. Выбор метода во многом определяет набор доступных механизмов – бесполезно объявлять механизм GSSAPI как поддерживаемый приложением, если единственный доступный для него метод – это системные файлы. Библиотека SASL может использовать методы либо напрямую, либо через своего “агента” – демона '''saslauthd''', с которым библиотека SASL общается через именованный сокет (название программного интерфейса для обеспечения обмена данными между процессами). Использование агента бывает необходимо для согласования прав доступа – сетевое приложение может быть запущено от непривилегированного системного пользователя, а для аутентификации, к примеру, через системные файлы нужен доступ на чтение ''/etc/shadow'', что при разумной установке возможно только для '''root'''. Однако, можно запустить сервис '''saslauthd''' с привилегированными правами, тем самым открывая ему доступ к ''/etc/shadow'' и при этом не компрометируя безопасность системы, поскольку непосредственный доступ к этому сервису из сети невозможен. Результат процедуры аутентификации '''saslauthd''' сообщает сервису через именованный сокет, права на доступ к которому могут быть более либеральны, чем к ''/etc/shadow''.

== Протоколы, поддерживающие SASL: ==
* [[ACAP (Application Configuration Access Protocol)|ACAP]]
* [[AMQP (Advanced Message Queuing Protocol)|AMQP]]
* [[BEEP (Blocks Extensible Exchange Protocol)|BEEP]]
* [[IMAP (Internet Message Access Protocol)|IMAP]]
* [[IMSP (Internet Message Support Protocol)|IMSP]]
* [[IRC (Internet Relay Chat)|IRC]] (с IRCX, TS6 или IRCv3 SASL расширением)
* [[LDAP (Lightweight Directory Access Protocol)|LDAP]]
* [[libvirt]]
* [[ManageSieve]] (RFC 5804)
* [[Memcached]]
* [[POP (Post Office Protocol)|POP]]
* RFB protocol используется в VNC
* [[SMTP (Simple Mail Transfer Protocol)|SMTP]]
* Subversion's «svn» протокол
* [[XMPP (Extensible Messaging and Presence Protocol)|XMPP]]
* [[Apache Thrift]]

==Сопоставление имен SASL==
SASL будет аутентифицироваться с использованием идентификатора аутентификации, который обычно является простым именем пользователя. Это имя SASL может отличаться от имени, требуемого приложением, используя SASL. Реализация SASL в Isode обеспечивает гибкий подход для сопоставления этих имен.
* Для механизма SASL на основе пароля ([[CRAM-MD5]],[[DIGEST-MD5]], [[PLAIN]], [[LOGIN]], [[NTLM (NT LAN Manager)|NTLM]] и [[SCRAM-SHA-1]]) имя SASL является простым именем пользователя. Для многих протоколов эта строка будет такой же, как и имя приложения. Например, для [[XMPP (Extensible Messaging and Presence Protocol)|XMPP]] имя SASL будет JID, а для [[IMAP (Internet Message Access Protocol)|IMAP]] имя SASL будет адресом электронной почты.
* Однако для каталога имя, используемое приложением, представляет собой структурированное имя каталога (DN). Isode использует каталог, который может быть M-Vault Isode или другой каталог LDAP для сопоставления с именем SASL на DN. Isode's SASL предоставляет три варианта для этого сопоставления:
*#  Поиск в каталоге атрибута, содержащего идентификатор.
*#  Двухуровневый поиск для «пользователя» и «домена» в структурированном идентификаторе user @ domain.
*#  Алгоритмическое сопоставление адреса электронной почты в каталоге каталогов с помощью Active Directory.

Эти параметры позволяют организациям выбирать отображение, соответствующее эксплуатационным требованиям.

==Поиск в каталоге атрибута, содержащего идентификатор==
Двухуровневый поиск для «пользователя» и «домена» в структурированном идентификаторе user @ domain.
Алгоритмическое сопоставление адреса электронной почты в каталоге каталогов с помощью Active Directory.
Эти параметры позволяют организациям выбирать отображение, соответствующее эксплуатационным требованиям. Isode обычно рекомендует использовать первый вариант.

Часто желательно использовать проверку подлинности на основе каталогов для широкого круга приложений, включая веб-приложения. DN для каталогов обычно неудобен для пользователей, а SASL позволяет использовать более привычный подход к имени пользователя и паролю, а проверка подлинности SASL в каталоге скрывает имя каталога от пользователя, как показано ниже.

[[Файл:Sasl.png|Принцип проверки подлинности SASL]]

==Источники==
{{reflist|group=Источник}}