5. Требования к механизмам
Спецификации механизмов SASL должны обеспечивать следующую информацию:
Имя механизма (см. параграф 3.1). Это имя должно быть зарегистрировано, как описано в параграфе 7.1.
Определение запросов сервера (server-challenge) и откликов клиента (client-response) в процессе аутентификационного обмена, а также:
Индикацию того, начинает работу механизма клиент (client-first), сервер (server-first) или это может изменяться (variable). Если механизм SASL определен, как client-first, а клиент не передает начального отклика в запросе на аутентификацию, первый запрос (challenge) сервера должен быть пустым (механизм EXTERNAL является примером такого случая). Если механизм SASL определен, как variable, спецификация должна указывать поведение сервера для тех случаев, когда начальный отклик в клиентском запросе на аутентификацию опущен (механизм DIGEST-MD5 [DIGEST-MD5] является примером для этого случая). Если механизм SASL определен, как server-first, для клиента недопустимо передавать начальный отклик в запросе на аутентификацию (примером для этого случая может служить механизм CRAM-MD5 [CRAM-MD5]).
Индикация того, предполагается ли со стороны сервера предоставление дополнительных данных, показывающих успех при аутентификации. Если такие данные ожидаются и сервер шлет их как запрос (challenge), спецификация должна показывать, что в ответ на такой запрос передается пустой отклик. При разработке механизмов SASL следует минимизировать число запросов и откликов, требуемых для выполнения аутентификационного обмена.
При разработке механизмов SASL следует минимизировать число запросов и откликов, требуемых для выполнения аутентификационного обмена.
Идентификация возможности поддержки механизмом передачи строк идентификации при проверке полномочий (см. параграф 3.4.1). Хотя некоторые унаследованные механизмы не способны передавать строки authorization identity (это означает, что для данного механизма authorization identity во всех случаях является пустой строкой), новым механизмам следует поддерживать передачу строк идентификации при проверке полномочий. Механизмам не следует поддерживать одновременно передачу отсутствия строк authorization identity и передачу пустых строк идентификации при проверке полномочий.
Механизмы, способные передавать строки authorization identity, должны поддерживать возможность передачи произвольных непустых последовательностей символов Unicode, включая строки с символами NUL (U+0000). Механизмам следует использовать формат преобразования UTF-8 [RFC3629]. В спецификации должно быть указано, каким образом включаются в строки идентификации все последовательности символов, имеющие специальное значение для данного механизма, во избежание неоднозначности при декодировании строк authorization identity. Обычно механизмы, использующие специальные символы, требуют для таких символов добавки специального escape-символа или представления таких символов в виде последовательности (после преобразования в заданный формат Unicode) с использованием схем кодирования данных типа Base64 [RFC3548].
Спецификация должна указывать, предлагает ли механизм уровень защиты. Если механизм предлагает такой уровень, спецификация должна детально описывать защиту и другие услуги, обеспечиваемые этим уровнем, а также способы реализации сервиса.
Если используемая механизмом криптографическая технология поддерживает защиту целостности данных, спецификация механизма должна защищать целостность при передаче строк authorization identity и согласовании уровня защиты.
Механизмам SASL следует быть нейтральными по отношению к протоколам.
Механизмам SASL следует использовать существующие формы свидетельств (credential) и идентификации (identity), а также связанный с ними синтаксис и семантику.
Механизмам SASL следует использовать формат преобразования UTF-8 [RFC3629] для представления передаваемых кодов (code point) Unicode [Unicode].
Во избежание проблем интероперабельности в результате различной нормализации, когда механизм вызывается для символьных данных (отличных от строк authorization identity), которые будут использоваться в качестве входной информации для криптографических функций и/или функций сравнения, спецификация должна подробно описывать когда и где готовятся символьные данные (включая любую нормализацию) для передачи их функциям, чтобы обеспечить корректную работу.
Для простых имен пользователей и паролей в аутентификационных свидетельствах в качестве алгоритма подготовки следует указывать SASLprep [RFC4013] (профиль алгоритма подготовки StringPrep [RFC3454]).
Механизмам не следует использовать строки authorization identity при генерации каких-либо долгоживущих криптографических ключей или хэш-значений, поскольку не существует требования, по которому строки authorization identity должны быть каноническими. Долгосрочный в данном случае означает существование в течение срока, превышающего продолжительность аутентификационного обмена. Т. е., поскольку разные клиенты (одного или различных протоколов) могут предоставлять различные строки authorization identity, которые семантически будут эквивалентны, использование таких строк для генерации криптографических ключей и хэш-значений может приводить к проблемам интероперабельности и иным сложностям.