RFC: 3920
Оригинал: Extensible Messaging and Presence Protocol (XMPP): Core
Другие версии: RFC 6120
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Семенов Юрий Алексеевич

6. Использование SASL

6.1. Overview

MPP содержит в себе метод аутентификации потока с помощью XMPP-профайла протокола SASL (Simple Authentication and Security Layer) [SASL]. SASL предоставляет обобщенный метод добавления поддержки аутентификации для протоколов с установлением соединения, и XMPP использует универсальный профайл XML пространства имен для SASL, который соответствует требованиям [SASL].

Используются следующие правила:

  1. Если согласование применения SASL происходит между двумя серверами, коммуникации не должны продолжаться до тех пор, пока с помощью DNS не выяснены имена присвоенные серверам (смотри "Коммуникации сервер-сервер" (раздел 14)).

  2. Если инициатор может согласовать применение SASL, он должен включить в заголовок исходного потока атрибут 'version' со значением по крайней мере равным "1.0".

  3. Если получатель может согласовать применение SASL, он должен анонсировать один или более аутентификационных механизмов в элементе <mechanisms/>, сопряженным с пространством имен 'urn:ietf:params:xml:ns:xmpp-sasl', в отклике на открывающий тэг потока, полученный от инициатора (если открывающий тэг потока включает в себя атрибут 'version' со значением по крайней мере равным "1.0").

  4. Во время согласования применения SASL, объект не должен в качестве сепараторов элементов посылать символы пробелов (см. процедуру формирования содержимого в [XMPP-IM] и [XML]) в элементе корневого потока (любой символ пробела, представленный в примерах SASL, введен исключительно с целью обеспечения читабельности текста); этот запрет помогает гарантировать корректность представления материала на уровне безопасности.

  5. Любые XML символьные данные, содержащиеся в XML-элементах, и используемые при согласовании SASL должны иметь кодировку base64, где кодировка привязана к определениям из раздела 3 RFC 3548 [BASE64].

  6. Если предоставление "simple username" поддерживается выбранным механизмом SASL (например, это поддерживается механизмами DIGEST-MD5 и CRAM-MD5, но не поддерживается механизмами EXTERNAL и GSSAPI), во время аутентификации, инициатор должен обеспечить в качестве простого имени пользователя свой домен (IP-адрес или полное доменное имя, как оно записано в доменном идентификаторе) в случае коммуникаций сервер-сервер, или свое имя аккоунта (имя пользователя или узла, содержащегося в XMPP-идентификаторе узла) в случае коммуникаций клиент-сервер.

  7. Если инициатор хочет действовать в интересах другого объекта и выбранный механизм SASL поддерживает передачу авторизационной идентичности, инициатор должен предоставить авторизационную идентичность в процессе согласования применения SASL. Если инициатор не хочет действовать в интересах другого объекта, он не должен предоставлять идентичность авторизации. Как специфицировано в [SASL], инициатор не должен предоставлять идентичность авторизации, за исключением случая, когда идентичность авторизации отличается от идентичности по умолчанию, полученной согласно [SASL]. Если такие данные предоставляются, значение идентичности авторизации должно иметь формат <domain> (т.е., только идентификатор домена) для серверов и формат <node@domain> (т.е., идентификатор узла и идентификатор домена) для клиентов.

  8. В случае успешного согласования SASL, которое включает в себя согласование уровня безопасности, получатель должен ликвидировать любую информацию, полученную от инициатора, которая не получена непосредственно в процессе согласования SASL.

  9. В случае успешного согласования SASL, которое включает в себя согласование уровня безопасности, инициатор должен ликвидировать любую информацию, полученную от получателя, которая не получена непосредственно в процессе согласования SASL.

  10. В отношении механизмов, которые нужно поддерживать смотри "Обязательные для использования технологии" (раздел 14).

2007 - 2017 © Русские переводы RFC, IETF, ISOC.