4. Требования к протоколам
Для того, чтобы протокол мог предлагать сервис SASL, его спецификация должна содержать следующую информацию:
Имя сервиса, которое может быть выбрано из регистра элементов "service" для связанного с хостом имени сервиса GSSAPI, как описано в параграфе 4.1 документа [RFC2743].
Отметим, что этот регистр совместно используется всеми механизмами GSSAPI и SASL.
Детали всех аспектов согласования механизма, обеспечиваемых протоколом (см. параграф 3.2). Протоколу следует задавать средства, с помощью которых клиент может (как до начала обмена SASL, так и после установки уровня защиты в результате обмена) имена механизмов SASL, которые сервер делает доступными для клиента. Это важно для обеспечения клиенту возможности детектирования атак, направленных на снижение уровня защиты. Такие средства обычно обеспечиваются с помощью функций детектирования расширений протокола и согласования возможностей.
Определения сообщений, требуемых при аутентификационном обмене, включая следующие:
сообщения для запроса аутентификационного обмена (см. параграф 3.3).
Такие сообщения должны содержать поле для передачи имени механизма, выбранного клиентом.
В такие сообщения следует включать необязательное поле для передачи начального отклика. Если сообщение определено с таким полем, спецификация должна описывать как сообщения с пустым начальным откликом отличаются от сообщений без такого отклика. Это поле должно обеспечивать возможность передачи произвольной последовательности октетов (включая последовательности нулевой длины и последовательности с нулевыми октетами).
Сообщения для передачи запросов (challenge) сервера и откликов (response) клиента (см. параграф 3.4).
Каждое из таких сообщений должно обеспечивать возможность передачи произвольных последовательностей октетов (включая последовательности нулевой длины и последовательности с нулевыми октетами).
Сообщение для индикации результата аутентификационного обмена (см. параграф 3.6).
В такие сообщения следует включать необязательное поле для передачи дополнительных данных при успешном завершении обмена. Если для сообщения определено такое поле, спецификация должна описывать способ различить сообщения с пустым полем дополнительной информации от сообщений без такого поля. Поде должно обеспечивать возможность передачи произвольной последовательности октетов (включая последовательности нулевой длины и последовательности с нулевыми октетами).
Описание синтаксиса и семантики непустых строк идентификации при проверке полномочий (см. параграф 3.4.1).
Чтобы избавиться от проблем интероперабельности в результате использования разной нормализации, спецификация протокола должна точно описывать как и где (клиент или сервер) готовятся непустые строки идентификации при проверке полномочий, включая любую нормализацию, для операций сравнения и других функций, обеспечивающих корректную работу.
Рекомендуется включать в спецификацию описание применения существующих форм идентификации при проверке полномочий, а также существующих вариантов представления строк таких, как обычные имена пользователей [RFC4013].
Когда спецификация не описывает точно как идентификация в SASL связана с идентификацией, используемой другими компонентами протокола (например, в правилах контроля доступа), для протокола может оказаться полезным поддержка для клиентов механизма обнаружения информации (например, представление идентификации, используемой при решении вопроса о предоставлении доступа) об имеющихся способах идентификации для таких целей.
Детали всех способов, которые позволяют клиенту и/или серверу прервать аутентификационный обмен (см. параграф 3.5).
Протоколы, поддерживающие множественную аутентификацию, обычно позволяют клиенту прервать происходящий аутентификационный обмен путем инициирования нового обмена. Протоколы, которые не поддерживают множественную аутентификацию, могут требовать от клиента закрывать соединение и открывать новое для прерывания происходящего аутентификационного обмена.
Протоколы обычно позволяют серверу прерывать происходящий аутентификационный обмен путем возврата сообщения о неудачной аутентификации.
Точного указания момента, с которого начинает использоваться вновь согласованный уровень защиты для обоих направлений (см. параграф 3.7).
Обычно спецификации требуют начинать использование уровня защиты, начиная с первого октета, передаваемого после результата аутентификации, для сообщений от сервера и первого октета, передаваемого после приема сообщения о результате аутентификации, для клиента.
Если протокол поддерживает другие службы обеспечения уровня защиты (такие, как TLS [RFC4346], спецификация должна описывать, как эти уровни применяются к данным протокола.
Например, когда протокол поддерживает уровни защиты TLS и SASL, спецификация может указать любой из перечисленных ниже вариантов:
уровень защиты SASL всегда применяется первым для передаваемых данных и последним для принимаемых;
уровень защиты SASL всегда применяется последним для передаваемых данных и первым для принимаемых;
уровни защиты применяются в порядке их установки;
уровни защиты применяются в порядке, обратном порядку их установки;
оба уровня TLS и SASL не могут быть установлены.
Индикация поддержки множественной аутентификации (см. параграф 3.8). Если такая аутентификация поддерживается, должно быть детально описано поведение при отказе от аутентификации SASL для тех случаев, когда предыдущая аутентификация была завершена успешно.
В спецификации протокола следует избегать требований к реализации, препятствующих замене применимых механизмов. В общем случае спецификации протокола следует быть нейтральной по отношению к механизмам. Однако из этого правила существует множество исключений, в том числе перечисленные ниже:
- детализация того, как в в протоколе происходит управление свидетельствами (которые связаны с механизмами);
- детализация того, как аутентификационная идентификация (определяется механизмом) и идентификация при проверке полномочий (определяется протоколом) связаны одна с другой;
- детализация применимости механизмов для данного протокола.