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

RFC 3920, Страница 18 из 63

5. Использование TLS

5.1. Overview

XMPP включает в себя метод обеспечения безопасности потока от фальсификации и подслушивания. Метод криптозащиты канала использует протокол безопасности транспортного уровня [TLS], с расширениями "STARTTLS", которые смоделированы для протоколов IMAP [IMAP], POP3 [POP3] и ACAP [ACAP], как это описано в RFC 2595 [USINGTLS]. Имя пространства имен для расширения STARTTLS = 'urn:ietf:params:xml:ns:xmpp-tls'.

Администратор данного домена может потребовать использования TLS для коммуникаций клиент-сервер и сервер-сервер. Клиенты должны использовать TLS, чтобы обеспечить безопасность потоков, прежде чем пытаться завершить согласование SASL (раздел 6), а серверы должны использовать TLS между двумя доменами для целей обеспечения безопасности коммуникаций сервер-сервер.

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

  1. Инициатор, который следует данной спецификации должен включить в заголовок потока атрибут 'version', содержащий значение "1.0".

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

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

  4. Если приемник намерен использовать TLS, согласование параметров TLS должно быть завершено до согласования использования SASL; такой порядок диалога необходим, чтобы защитить аутентификационную информацию, посланную во время согласования применения SASL.

  5. Во время согласования использования TLS, объект не должен посылать каких-либо символов пробелов в элементе корневого потока в качестве сепараторов между элементами (любой пробел, имеющийся в примерах TLS ниже, включен исключительно из соображений читаемости); этот запрет помогает гарантировать корректность байт на уровне безопасности.

  6. Приемник должен осуществлять согласование применения TLS сразу после посылки завершающего символа ">" элемента <proceed/>. Инициатор должен осуществлять согласование применения TLS сразу после получения завершающего символа ">" элемента <proceed/> от приемника.

  7. Инициатор должен проверить сертификат, представленный приемником; (смотри "Проверка сертификата" (раздел 14)).

  8. Сертификаты должны проверяться по поводу имени машины, выданного инициатором, (например, пользователем), а не имя машины, полученное с помощью DNS; например, если пользователь специфицирует имя машины "example.com", а DNS SRV прислал "im.example.com", сертификат должен проверять версию "example.com". Если JID для любого XMPP-объекта (например, клиента или сервера) присутствует в сертификате, он должен быть представлен, в виде UTF8String в пределах имени некоторого объекта (otherName) внутри subjectAltName. Делается это с привлечением объектного идентификатора [ASN.1] "id-on-xmppAddr", специфицированного в разделе 5.

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

  10. Если согласование применения TLS прошло успешно, инициатор должен аннулировать любые данные, полученные ранее от приемника небезопасным способом.

  11. Если согласование применения TLS прошло успешно, приемник не должен предлагать инициатору расширения STARTTLS, а также другие возможности, которые предложены, когда поток рестартовал.

  12. Если согласование применения TLS прошло успешно, инициатор должен приступить к согласованию SASL.

  13. Если согласование применения TLS завершилось неудачей, приемник должен прервать XML-поток и разорвать TCP-соединение.

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

5.1.1. Идентификатор объекта ASN.1 для XMPP-адреса

Идентификатор объекта [ASN.1] "id-on-xmppAddr", описанный выше, определяется следующим образом:

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-on  OBJECT IDENTIFIER ::= { id-pkix 8 }  -- other name forms
id-on-xmppAddr  OBJECT IDENTIFIER ::= { id-on 5 }
XmppAddr ::= UTF8String

Этот объектный идентификатор может быть представлен в точечном формате вида "1.3.6.1.5.5.7.8.5".

Страница 18 из 63

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