Network Working Group J. Miller Internet-Draft P. Saint-Andre Expires: December 20, 2002 Jabber Software Foundation June 21, 2002 Базовые компоненты XMPP (XMPP Core) draft-miller-xmpp-core-00 Статус этого документа Этот документ является рабочим документом (Internet-Draft) и полностью соответствует всем требованиям главы 10 RFC2026. Internet-Drafts - это рабочие документы Internet Engineering Task Force (IETF), их подразделений и групп разработчиков. Другие группы также могут распространять свои рабочие документы в виде Internet-Draft. Internet-Drafts являются черновыми набросками и действительны максимум шесть месяцев, они могут быть обновлены, заменены или опровергнуты другими документами в любой момент. Не стоит рассматривать Internet-Drafts в качестве справочного пособия или ссылаться на них, иначе как на "рабочие документы". Этот рабочий документ потеряет силу 20 декабря 2002г. Авторские права Copyright (C) The Internet Society (2002). All Rights Reserved. Краткий обзор Этот документ описывает базовые компоненты протокола XMPP (eXtensible Messaging and Presence Protocol - вольный перевод: Расширяемый Протокол Обмена сообщениями и Определения доступности), который используется многочисленными приложениями, совместимыми со свободно распространяемой системой обмена сообщениями Jabber (Jabber instant messaging system). Оглавление 1. Введение 1.1 Общий обзор 1.2 Соглашения, использующиеся в документе 1.3 Обсуждение документа 1.4 Замечания об интеллектуальной собственности 2 Обобщенная архитектура 2.1 Обзор 2.2 Хост 2.3 Узел 2.4 Сервис 2.4.1 Шлюз 2.5 Сеть 3 Схема адресации 3.1 Обзор 3.2 Идентификатор домена 3.3 Идентификатор узла 3.4 Идентификатор ресурса 3.5 URIs 4 Потоки XML 4.1 Обзор 4.2 Область использования 4.3 Ограничения 4.4 Секции и атрибуты 4.5 Ошибки потока 4.6 Пример 4.7 DTD 4.8 Schema 5 Аутентификация потока 5.1 Аутентификация SASL 5.1.1 Обзор 5.1.2 Пример 5.1.3 DTD 5.1.4 Schema 5.2 Аутентификация "обратного вызова" 5.2.1 Протокол "обратного вызова" 6 Общие секции данных 6.1 Обзор 6.2 Секция message 6.2.1 Атрибуты 6.2.2 Дочерние секции 6.2.3 DTD 6.2.4 Schema 6.3 Секция presence 6.3.1 Атрибуты 6.3.2 Дочерние секции 6.3.3 DTD 6.3.4 Schema 6.4 Секция iq 6.4.1 Обзор 6.4.2 Атрибуты 6.4.3 Дочерние секции 6.4.4 DTD 6.4.5 Schema 7 Место XML в протоколе XMPP 7.1 Обзор 7.2 Пространства имен 7.3 Проверка допустимости 7.4 Расширенные пространства имен 7.5 Трактовка расширенных пространств имен 8 Анализ безопасности 8.1 Связь узел-хост 8.2 Связь хост-хост 8.3 Использование SASL * Справочная информация * Связь с авторами A Стандартные коды ошибок B Регистрация в IANA * Авторское право 1. Введение 1.1 Общий обзор XMPP (eXtensible Messaging and Presence Protocol) - это открытый, базирующийся на XML протокол для посылки сообщений и определения доступности абонента в режиме "почти реального" времени. В настоящий момент существует несколько реализаций протокола, главный образом предлагающихся под названием Jabber. Также имеется многочисленное применение этих реализаций, осуществляющих сервисы обмена сообщениями и определения доступности абонента в тысячах доменов для миллионов пользователей. Этот документ определяет базовые компоненты XMPP; конкретные протоколы, необходимые для обеспечения функциональности системы обмена сообщениями и определения доступности абонента определены в XMPPIM[2]. 1.2 Соглашения, использующиеся в документе Ключевые слова НЕОБХОДИМО (MUST), НЕДОПУСТИМО (MUST NOT), ТРЕБУЕТСЯ (REQUIRED), СЛЕДУЕТ (SHOULD), НЕ СЛЕДУЕТ (SHOULD NOT), РЕКОМЕНДУЕТСЯ (RECOMMENDED), МОЖЕТ (MAY), и НЕОБЯЗАТЕЛЬНО (OPTIONAL) в данном документе используются в соответствии с описанным в RFC2119[1]. 1.3 Обсуждение документа Авторы приглашают к обсуждению тем, представленных в этом документе, в список рассылки jabber-ietf@jabber.org (архивы и информация о подписке доступна на http://www.jabber.org/cgi-bin/mailman/listinfo/jabber-ietf/). 1.4 Замечания об интеллектуальной собственности Данный документ полностью совместим со всеми положениями главы 10 RFC 2026. В этом изложении встречается термин "jabber" для идентификации схем URI, пространств имен и другого синтаксиса протокола. Jabber[tm] является торговой маркой Jabber, Inc. Если IETF примет этот документ (или его более новую редакцию) в качестве стандарта, то Jabber, Inc предоставит разрешение на использование торговой марки "Jabber" в соответствии с такой спецификацией. 2 Обобщенная архитектура 2.1 Обзор Хотя XMPP и не связан с конкретной сетевой аpхитектypой, в настоящее вpемя он обычно использyется в аpхитектypе "клиент-сеpвеp": клиент чеpез XMPP получает достyп к сеpвеpy чеpез сокеты TCP [4]. Hесмотpя на yдобство такого подхода для понимания pаботы XMPP, мы постаpаемся отойти от pассмотpения конкpетной аpхитектypы и pассмотpим описываемый пpотокол в более общем виде. Следyющая диагpамма показывает общий вид pассматpиваемой обобщенной аpхитектypы ("-" соответствyет соединениям чеpез XMPP, "=" соответствyет соединениям чеpез дpyгие пpотоколы). Диагpамма соединений S1 S2 \ / N1 - H1 - H2 - N3 / \ N2 - G1 = F1 = C1 Условные обозначения: N1, N2, N3 - Узлы (Nodes) в сети Jabber H1, H2 - Хосты (Hosts) в сети Jabber S1, S2 - Сеpвисы, pасшиpяющие фyнкциональность хоста G1 - Шлюз (gateway), пpеобpазyющий данные XMPP в данные пpотоколов, использyющимися в дpyгих сетях обмена сообщениями F1 - Дpyгая (не Jabber) сеть обмена сообщениями C1 - Клиент такой сети (F1) 2.2 Хост (Host) Хост выполняет pоль посpедника в обмене данными по XMPP. Его главная задача - управлять соединениями с дpyгими yчастниками (автоpизованными yзлами, сеpвисами и дpyгими хостами) и пеpесылать им соответствyющие XML данные. Большинство XMPP-совместимых (Jabber) хостов также беpyт на себя фyнкцию хpанения данных, использyемых узлами и сеpвисами (напpимеp, контакт-листы пользователей системы, называемые "pостеp"(roster)); в этом слyчае данные XML обpабатываются непосpедственно этим хостом от имени yзла или сеpвиса и не пеpесылаются дpyгим yчастникам. 2.3 Узел (Node) Обычно узлы соединяются с хостами напpямyю чеpез сокеты TCP и использyют XMPP для полyчения pесypсов хоста и использования пpедоставляемых им сеpвисов. (Клиенты дpyгих систем обмена сообщениями достyпны чеpез шлюзы в эти системы). Несколько ресурсов МОГУТ быть подключены к хосту одновременно от имени одного автоpизованного yзла, в этом слyчае каждый pесypс соединяется чеpез отдельный сокет TCP и отличается своим идентификатоpом pесypса JID (Глава 3) (напpимеp, node@host/home и node@host/work). Для связи междy yзлом и хостом IANA [5] выделен поpт 5222. За подpобностями об обмене данными междy yзлом и хостом в системах обмена сообщениями и опpеделения достyпности абонента, смотpите XMPP IM [2]. 2.4 Сервис Базовая фyнкциональность, пеpедоставляемая хостом, может быть pасшиpенна подключением к хостy довеpенных сеpвисов. Hапpимеp, гpyпповые конфеpенции, системы оповещения в pеальном вpемени, дополнительные аyтентифициpyющие модyли, связь с базами данных и осyществление связи с дpyгими системами обмена сообщениями. Специально выделенных поpтов для таких сеpвисов не опpеделено - это оставляется на yсмотpение администpатоpа такого сеpвиса или хоста. 2.4.1 Шлюз (Gateway) Шлюз - это специальный сеpвис, основная фyнкция которого состоит в пpеобpазовании XMPP в пpотоколы, использyемые в дpyгих системах (и обратно). В качестве пpимеpа можно назвать шлюзы в системы Internet Relay Chat (IRC), Short Message Service (SMS), SMTP и в pазличные системы обмена сообщениями, такие как Yahoo!, MSN, ICQ и AIM. 2.5 Сеть Каждый хост идентифициpyется сетевым адpесом (обычно DNS именем), протокол обмена данными междy хостами пpедставляет собой некотоpое pасшиpение пpотокола для обмена данными междy yзлом и хостом. Таким обpазом система состоит из сети хостов, обменивающихся данными дpyг с дpyгом. Узел node-a@host1 может обмениваться сообщениями, инфоpмиpовать о достyпности и пеpедавать дpyгyю инфоpмацию yзлy hode-b@host2. Такой подход обычен для почтовых пpотоколов (напpимеp SMTP) и использyет стандаpтнyю адpесацию в сети. Обычный способ yстановления соединения междy двyмя хостами - это откpыть сокет TCP на поpт 5269 (выделенный IANA) и "договоpиться" о связи, использyя пpотокол "оpбатного вызова" (Dialback Protocol) (Глава 5.2). 3 Схема адресации 3.1 Обзор Любой yчастник обмена, котоpый может рассматриваться как получатель информации (то есть, имеющий идентификатор), и использующий для обмена XMPP, считается yчастником обмена данными в Jabber. Все yчастники имеют yникальный адpес в фоpме, совместимой со спецификацией URI [11]. Разрешенный идентификатоp Jabber (JID) формируется из идентификатоpа домена, идентификатоpа yзла и идентификатоpа pесypса в таком фоpмате: [node@]domain[/resource]. Все JIDы базиpyются на вышеyпомянyтой стpyктypе. Hаиболее часто эта стpyктypа использyется для идентификации пользователя системы обмена сообщениями, хоста, с котоpым он связался и текyщей сессии пользователя в фоpме user@host/resource. Однако, возможно и дpyгое использование. Hапpимеp, room-name@conference-service опpеделяет конфеpенцию (conference room), пpедоставляемyю сеpвисом гpyпповых конфеpенций. 3.2 Идентификатор домена Идентификатоp домена - это основной и единственно необходимый элемент в JID (пpосто идентификатоp домена - pазpешенный JID). Он обычно пpедставляет собой сетевой шлюз или "пеpвичный" хост, с котоpым соединяются yчастники для пеpедачи XML данных. Однако идентификатоpом домена может описываться не только хост, это может быть сеpвис, адpесyемый как поддомен хоста и pасшиpяющий его возможности (напpимеp, сеpвис гpyпповых конфеpенций или шлюз в дpyгyю системy пеpедачи сообщений). Идентификатор домена для любого хоста или сервиса СЛЕДУЕТ назначать в соответствии с требованиями RFC 952 [6] и RFC 1123 [7]. Более точно: прописные и строчные буквы не различаются, 7-ми битная ASCII кодировка и максимум 255 байт. 3.3 Идентификатор узла Идентификатор узла является дополнительным, необязательным идентификатором. Как правило, он представляет собой участника, использующего доступ к хосту (например, клиента), но может также представлять другие типы участников (напр. групповую конференцию, связанную с соответствующим сервисом). Участник, представленный идентификатором узла, адресуется в контексте своего домена. Длина идентификатора узла ограничена 256 байтами. Идентификатор узла может состоять из любых символов Unicode, старших чем #x20 исключая следующие: #x22 (") #x26 (&) #x27 (') #x3A (:) #x3C (<) #x3E (>) #x40 (@) #x7F (del) #xFFFE (BOM) #xFFFF (BOM) Регистр символов сохраняется, но при сравнении не учитывается. 3.4 Идентификатор ресурса Идентификатор ресурса - необязательный третий параметр. Он определяет конкретную сессию, соединение или объект (например, пользователя групповой конференции) и принадлежит узлу. Узел может иметь несколько ресурсов одновременно. Длина идентификатора ресурса ограничена 256 байтами. Идентификатор ресурса МОЖЕТ содержать любые символы Unicode, старшие чем #x20, за исключением #xFFFE и #xFFFF; если символ не является разрешенным символом XML (как определено в главе 2.2 XML 1.0 specification[8]), то его НЕОБХОДИМО заменить на соответствующую esc-последовательность перед включением в поток XML. Идентификаторы ресурса чувствительны к регистру. 3.5 URIs (Uniform Resource Identifier, Универсальный Идентификатор Ресурса) Нелишней была бы полная совместимость с RFC2369[11]. Хотелось бы использовать схемы URI 'im:' и 'pres:' ("im:node@host" для обмена сообщениями и "pres:node@host" для обмена данными для определения доступности). Однако, в настоящий момент это не стандартизовано. 4 Потоки XML 4.1 Обзор Две фундаментальных концепции делают возможным быстрый, асинхронный обмен данными (при относительно низкой загрузке структурированной информацией) между объектами: потоки XML и раздельные блоки информации (XML chunks). (Примечание: в этом обзоре мы используем пример обмена между узлом и хостом, однако потоки XML более обобщенны и используются для обмена между различными типами участников [см. Область использования]) При соединении с хостом, узел инициирует поток XML посылкой должным образом оформленного, в соответствии с пространством имен, тега , хост посылает ответный поток XML обратно узлу. В контексте XML-потока посылающий может отправить дискретный семантический блок структурированной информации любому получателю. Этот блок структурированной информации может быть сообщением, уведомлением о доступности или блоком IQ (блок должен быть сбалансирован в соответствии с требованием [43] XML 1.0 specification[8]). Данные блоки находятся на нижнем уровне (уровень_1) потока. Начало любого блока XML однозначно определено открывающим тегом секции уровня_1 (например, ; конец блока однозначно определен соответствующим закрывающим тегом уровня_1 (например, . Каждый блок XML может содержать дочерние секции или секции CDATA в порядке, необходимом для передачи нужной информации от посылающего получателю. Сессия закрывается по запросу узла посылкой хосту тега . Таким образом, сеанс между узлом и хостом может быть представлен как запись в два открытых XML документа (в один документ пишутся данные, передаваемые от узла хосту, в другой - от хоста к узлу). В сущности, поток XML выполняет роль "конверта" для блоков XML, посылаемых во время сеанса. Графически это можно представить так: |-------------------| | open stream | |-------------------| | | | | | | |-------------------| | | | | | | |-------------------| | | | | | | |-------------------| | close stream | |-------------------| 4.2 Область использования Потоки XML выполняют роль контейнеров для любых блоков XML, посылаемых асинхронно между объектами в сети. (Мы не вдаемся в детали, и назовем их "инициирующий" и "принимающий" участники). Потоки XML используются в следующих вариантах обмена данными: Узел-Хост Хост-Хост Сервис-Хост Эти варианты отличаются объявленным пространством имен потока, заданным инициирующим участником. Это же пространство имен используется в ответе принимающей стороны: Для обмена Узел-Хост (и Хост-Узел), пространство имен объявляется как "jabber:client". Для обмена Хост-Хост, пространство имен объявляется как "jabber:server". Существует два способа обмена данными между сервисом и хостом: Сервис устанавливает соединение с хостом. В этом случае объявление пространства имен: "jabber:component:accept" (т.к. хост принимает (accepts) соединение). Хост устанавливает соединение с сервисом. Объявление пространства имен: "jabber:component:connect" (т.к. хост запрашивает "connects" соединение с сервисом). 4.3 Ограничения Потоки XML используются для передачи подмножества XML. НЕ СЛЕДУЕТ использовать потоки XML, содержащие инструкции обработки данных, непредопределенные элементы (согласно главы 4.6 XML 1.0 specification[8]), комментарии или DTD. Такие данные в потоке СЛЕДУЕТ игнорировать. 4.4 Секции и атрибуты Определены следующие атрибуты потока: to - атрибут "to" обычно используется только в потоке XML от инициирующей стороны к принимающей и устанавливается в JID принимающего участника. Как правило, атрибут "to" не используется в ответе принимающего участника; однако, если таковой присутствует, его СЛЕДУЕТ игнорировать. from - атрибут "from" обычно используется только в потоке от принимающего участника к инициирующему и устанавливается в JID принимающей стороны, предоставляя доступ инициирующему участнику. Как правило, атрибут "from" не посылается инициирующей стороной принимающей; однако, если таковой присутствует, его СЛЕДУЕТ игнорировать. id - атрибут "id" обычно используется только в потоке от принимающего участника к инициирующему. Он содержит уникальный идентификатор, создаваемый принимающим участником и являет собой сессионный ключ(session key) для текущего сеанса. Как правило, атрибут "id" не посылается инициирующей стороной; однако если таковой присутствует, его СЛЕДУЕТ игнорировать. Представим это в виде таблицы: | инициирующий - принимающему | принимающий - инициирующему ------------------------------------------------------------------ to | JID принимающего | игнорируется from | игнорируется | JID принимающего id | игнорируется | сеансовый ключ Секция stream также содержит следующие объявления пространств имен: xmlns - это объявление ТРЕБУЕТСЯ и используется в обоих потоках XML в секции верхнего уровня. Объявление должно иметь одинаковое значение и для инициирующей стороны, и для принимающей. (О разрешенных значениях этого пространства имен см. Область использования) xmlns:stream - объявление ТРЕБУЕТСЯ в обоих потоках XML. Его значение НЕОБХОДИМО установить в "http://etherx.jabber.org/streams". В дополнение к Общим секциям данных (см. ниже) секция потока МОЖЕТ содержать как дочернюю секцию, означающую, что произошла ошибка уровня потока. 4.5 Ошибки потока На уровне потока могут происходить ошибки. Например, послан неверный XML, недоступность хоста, внутренняя ошибка сервера (такая, как закрытие диспетчера сессии), попытка узла вторично аутентифицироваться с текущим ресурсом. При возникновении ошибки на уровне потока участник (инициирующая или принимающая сторона), который ее обнаружит должен послать описание ошибки противоположной стороне и закрыть соединение тегом . XML данные посылаются в контексте текущего потока: ... Error message (e.g., "Invalid XML") 4.6 Пример Приведем простой пример сеанса Узел-Хост (строки NODE посылаются узлом хосту, строки HOST посылаются хостом узлу): NODE: HOST: NODE: NODE: Watson come here, I need you! NODE: HOST: HOST: I'm on my way! HOST: NODE: HOST: Если рассматривать отдельные потоки передающей и принимающей сторон, как два XML документа: NODE: NODE: NODE: Watson come here, I need you! NODE: NODE: HOST: HOST: HOST: I'm on my way! HOST: HOST: Пример сеанса, завершившегося ошибкой: NODE: HOST: NODE: Bad XML, no closing body tag! HOST: Invalid XML HOST: 4.7 DTD (Document Type Definition - Описание шаблона документа) 4.8 Schema 5 Аутентификация потока В XMPP существует два метода проведения аутентификации на уровне потоков XML. Когда один участник уже известен другому (то есть, имеются доверительные отношения между участниками; например, установленные при регистрации узла хостом, или установленное администратором доверие хостом сервису), для аутентификации участников используется SASL (Simple Authentication and Security Layer)[9], адаптированный для XMPP. В ситуации, когда доверительных отношений еще не установлено, такие отношения МОГУТ устанавливаться на базе имеющегося доверия в DNS; в случае, когда участники являются хостами для аутентификации используется протокол "обратного вызова" (dialback protocol). Оба этих метода описываются далее в этой главе. 5.1 Аутентификация SASL 5.1.1 Обзор SASL (Simple Authentication and Security Layer) обеспечивает обобщенный метод для поддержки аутентификации в протоколах с установленным соединением. XMPP использует профиль пространства имен для SASL, согласно главе 4 ("Profiling Requirements") RFC 2222[9] (идентификатор пространства имен для этого протокола - http://www.iana.org/assignments/sasl-mechanisms). Если участник (узел, хост или сервис) может проводить аутентификацию посредством SASL, ему НЕОБХОДИМО включить соответствующее пространство имен в тег , используемый при инициации обмена. Пример показывает использование SASL при аутентификации узла хостом, при этом используются следующие шаги: Узел запрашивает аутентификацию SASL, включая соответствующее объявление пространства имен (xmlns:sasl='http://www.iana.org/assignments/sasl-mechanisms') в заголовок потока XML, посылаемый хосту Хост включает объявление xmlns:sasl в заголовок потока, посылаемого узлу в ответ Хост посылает список возможных механизмов аутентификации SASL, каждый из которых оформляется как секция , включенная в контейнер (этот контейнер - дочерняя секция ) Узел выбирает подходящий механизм, посылая хосту ; эта секция МОЖЕТ содержать дополнительные символьные данные. При необходимости, хост посылает дополнительный запрос узлу; эта секция МОЖЕТ содержать дополнительные символьные данные. Узел отвечает на запрос посылкой секции ; эта секция МОЖЕТ содержать дополнительные символьные данные. Если нужно, хост посылает дополнительные запросы и узел посылает соответствующие ответы. Эти серии обменов запрос/ответ продолжаются до тех пор, пока не выполнится одно из условий: Узел прервет установление связи, послав хосту секцию . Хост сообщит о неудачной попытке, послав узлу секцию . Хост сообщит о удачном завершении посылкой узлу ; эта секция МОЖЕТ содержать дополнительные символьные данные. Все символьные данные, содержащиеся в этих секциях НЕОБХОДИМО передавать в кодировке base64. 5.1.2 Пример Этот пример демонстрирует поток данных при аутентификации узла хостом посредством SASL. Шаг 1: Узел начинает связь с хостом: Шаг 2: Хост отвечает узлу с тегом stream: Шаг 3: Хост сообщает узлу о возможных механизмах аутентификации: Шаг 4: Узел выбирает механизм аутентификации: Шаг 5: Хост посылает запрос узлу: cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz Шаг 6: Узел отвечает на запрос: dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJqYWJiZXIvY2F0YWNseX NtLmN4IixyZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0 M2FmNyxjaGFyc2V0PXV0Zi04 Шаг 7: Хост посылает дополнительный запрос: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== Шаг 8: Узел отвечает на него: Шаг 9: Хост сообщает об успешной аутентификации: Шаг 9(альтернативный): Хост сообщает узлу о неудачной аутентификации: 5.1.3 DTD DTD для sasl. пространства имен: 5.1.4 Schema 5.2 Аутентификация "обратного вызова" (Dialback Authentication) XMPP поддерживает метод, который на уровне протокола позволяет убедиться, что между хостами установлено доверительное соединение. Этот метод называется "обратным вызовом" (dialback) и используется только в потоках XML, которые объявлены внутри пространства имен "jabber:server". Протокол "обратного вызова" используется для предотвращения подмены IP адреса (spoofing) хоста и посылки ложных данных от его имени. "Обратный вызов" возможен при наличии DNS, когда хост может проверить, что другой хост (с которым он соединяется) авторизован для работы в сети Jabber. Разрешение имени хоста через DNS должно начинаться с поиска записи SRV[10] _jabber._tcp.host. Если таковая не найдена, то производится обычный поиск записи A для определения IP-адреса. Во втором случае используется порт сервера jabber 5269, назначенный IANA (Internet Assigned Numbers Authority[5]). Примечание: метод, используемый для генерации и проверки ключей, используемых в протоколе "обратного вызова" должен быть известен системам, участвующим в обмене, но ключ известен только принимающему хосту. Идентификатор (id) потока генерируется случайным образом. Использование уникальных, но верифицируемых ключей важно для предотвращения распространенных атак типа "man-in-the-middle" и подмены адреса хоста (spoofing). В дальнейшем описании мы будем использовать следующие термины: Инициирующий Хост - хост, который пытается установить соединение Принимающий Хост - хост, пытающийся получить подтверждение, что инициирующий хост - тот, за кого себя выдает Доверенный Хост - хост, установленный при поиске в DNS имени, заданного инициирующим хостом; обычно это сам инициирующий хост, но это может быть и другая машина в сети инициирующего хоста. Краткое описание последовательности событий при "обратном вызове" 1. Инициирующий Хост устанавливает соединение с Принимающим Хостом. 2. Инициирующий Хост посылает ключ Принимающему Хосту. 3. Принимающий Хост устанавливает соединение с Доверенным Хостом. 4. Принимающий Хост посылает тот же ключ Доверенному Хосту. 5. Доверенный Хост отвечает действителен ключ или нет. 6. Принимающий Хост сообщает Инициирующему Хосту подтверждена его подлинность или нет. Можно представить эту последовательность графически: Инициирующий Принимающий Хост Хост ----------- --------- | | | установление связи | | ----------------------> | | | | посылка заголовка потока| | ----------------------> | | | | установление связи | | <---------------------- | | | | посылка заголовка потока| | <---------------------- | | | Доверенный | посылка ключа | Хост | ----------------------> | ------------- | | | | установление связи | | ----------------------> | | | | посылка заголовка потока| | ----------------------> | | | | посылка заголовка потока| | <---------------------- | | | | посылка ключа | | ----------------------> | | | | проверка ключа | | <---------------------- | | | отчет о результате | | <---------------------- | | проверки | 5.2.1 Протокол "обратного вызова" Данные, передаваемые между хостами: 1. Инициирующий Хост устанавливает соединение с Принимающим Хостом 2. Инициирующий Хост посылает заголовок потока Принимающему Хосту (атрибуты 'to' и 'from' необязательны): Примечание: значение пространства имен xmlns:db указывает Принимающему Хосту, что Инициирующий Хост поддерживает "обратный вызов" 3. Принимающий Хост посылает заголовок потока обратно Инициирующему Хосту (атрибуты 'to' и 'from' необязательны): 4. Инициирующий Хост посылает ключ Принимающему Хосту: 98AF014EDC0... Примечание: этот ключ не проверяется Принимающим Хостом, и Принимающий Хост не сохраняет информацию об Инициирующем Хосте между сессиями. 5. Принимающий Хост устанавливает соединение с Инициирующим Хостом и получает адрес Доверенного Хоста. 6. Принимающий Хост посылает Доверенному Хосту заголовок потока (атрибуты 'to' и 'from' необязательны): 7. Доверенный Хост посылает Принимающему Хосту заголовок потока: 8. Принимающий Хост посылает Доверенному Хосту блок, говорящий ему, что требуется подтверждение ключа: 98AF014EDC0... 9. Доверенный Хост посылает блок Принимающему Хосту, подтверждая или отвергая ключ: или 10. Принимающий Хост сообщает Инициирующему Хосту о результате: Примечание: С этого места соединение считается подтвержденным (если возвращен тип='valid'), или не подтвержденным. После подтверждения соединения, данные могут посылаться Инициирующим Хостом и приниматься Принимающим Хостом; до этого момента, все блоки данных, посланные Принимающему Хосту СЛЕДУЕТ отвергать. В качестве окончательной защиты от подмены адреса Принимающему Хосту НЕОБХОДИМО проверять, что все блоки XML, принятые от Инициирующего Хоста включают атрибут 'from', и приняты от доверенного домена. Дополнительно, во все блоки XML с типом message, presence, и IQ НЕОБХОДИМО включать атрибут 'to'. 6 Общие секции данных 6.1 Обзор Общими секциями данных в XMPP являются секции , , и . Они являются прямыми наследниками корневой секции . 6.2 Секция message Этот раздел описывает разрешенные атрибуты и дочерние секции для секции message. 6.2.1 Атрибуты Блок message может иметь следующие атрибуты: to - определяет получателя блока from - определяет отправителя блока id - необязательный уникальный идентификатор для отслеживания сообщения. Отправитель блока message устанавливает этот атрибут, он МОЖЕТ возвращаться в любом ответе. type - Необязательная спецификация типа сообщения. За полной информацией об использовании этого атрибута, обращайтесь к XMPP IM[2]. Если предыдущее сообщение не может быть обработано или доставлено, хосту СЛЕДУЕТ возвратить его отправителю, установив type=error в дочерней секции . 6.2.2 Дочерние секции В блоке message МОЖЕТ содержаться ноль или более следующих дочерних секций: body - Текстовое содержимое сообщения; обычно имеется, но не требуется. НЕДОПУСТИМО вставлять в секцию никакие атрибуты. subject - Тема сообщения. НЕДОПУСТИМО вставлять в секцию никакие атрибуты. thread - Случайная строка, генерируемая отправителем, которая МОЖЕТ возвращаться в ответе; используется для отслеживания цепочки беседы. error - В сообщения с типом type="error", в блок НЕОБХОДИМО включать дочернюю секцию , в которой НЕОБХОДИМО поместить атрибут 'code', соответствующий одной из стандартных ошибок (см. приложение A). Дополнительно МОЖНО добавить описание ошибки на естественном языке. Как описывается в главе Расширенные пространства имен, блок message МОЖЕТ содержать любую дочернюю секцию (кроме общих секций данных, секций stream или их наследников). 6.2.3 DTD 6.2.4 Schema 6.3 Секция presence используется для представления текущего статуса доступности абонента (offline, online и т.п.) и передается другим участникам. Она также используется для подписки на получение доступности других абонентов. 6.3.1 Атрибуты Блок presence МОЖЕТ иметь следующие атрибуты: to - Определяет получателя статуса доступности from - Определяет отправителя статуса доступности id - Уникальный идентификатор, используемый для отслеживания присутствия. Отправитель статуса доступности устанавливает этот атрибут, он может быть возвращен в любом ответе. type - Описывает статус доступности, запрос на подписку, запрос на определение доступности или ошибку. При отсутствии атрибута 'type' или если его значение не совпадает с описанными здесь вариантами, подразумевается, что ресурс доступен. СЛЕДУЕТ устанавливать type в одно из значений: unavailable - Сигнализирует, что объект более недоступен для обмена данными subscribe - Посылающий запрашивает подписку на получение статуса доступности получателя subscribed - Посылающий разрешает получателю получать статус своей доступности unsubscribe - Извещение о том, что участник отписан от получения статуса объекта unsubscribed - Запрос на подписку отвергнут, или разрешенная ранее подписка закрыта probe - Запрос на получение текущего статуса доступности абонента error - Произошла ошибка при обработке или доставке посланного ранее статуса доступности 6.3.2 Дочерние секции В блоке presence может содержаться ноль или более следующих дочерних секций: show - Описывает статус доступности объекта или ресурса. Эту величину СЛЕДУЕТ устанавливать в одно из следующих значений (значения, не описанные здесь, обычно игнорируются; дополнительные статусы доступности могут быть определены в соответствующей секции блока presence): away - Объект или ресурс временно недоступен. chat - Объект или ресурс готов общаться (чат). xa - Объект или ресурс недоступен длительное время (xa = "eXtended Away"). dnd - Объект или ресурс занят (dnd = "Do Not Disturb"). status - Необязательное описание статуса доступности на естественном языке. Обычно используется совместно с секцией show для подробного описания статуса (напр. "Ушел на встречу"). priority - Положительное целое число, определяющее уровень приоритета соответствующего ресурса (0 - наименьший приоритет). error - если type="error", то в блок НЕОБХОДИМО включать дочернюю секцию , в которой НЕОБХОДИМ атрибут 'code', соответствующий одному из Стандартных Кодов Ошибок, и МОЖЕТ также содержать PCDATA с описанием ошибки на естественном языке. Как описывается в главе Расширенные пространства имен, блок message МОЖЕТ содержать любую дочернюю секцию (кроме общих секций данных, секций stream или их наследников). 6.3.3 DTD 6.3.4 Schema 6.4 Секция iq 6.4.1 Обзор IQ (Info/Query) - это простой механизм запроса-ответа. Как HTTP является средством для передачи запроса-ответа, так и секция iq позволяет участнику отправлять запросы и получать ответы от другого участника. Содержимое запроса и ответа определяется объявлением пространства имен дочерней секции iq. Большинство обменов IQ происходят по следующему сценарию: Запрашивающий Отвечающий Участник Участник ---------- ---------- | | | | | ---------------------> | | | | | | <--------------------- | | | | | | ---------------------> | | | | | | <--------------------- | | | 6.4.2 Атрибуты Блок IQ имеет следующие атрибуты: to - Определяет получателя блока IQ. from - Определяет отправителя блока IQ. id - Необязательный уникальный идентификатор, используемый для отслеживания обмена запрос-ответ. Отправитель блока IQ устанавливает этот атрибут, он может быть возвращен в любом ответе. type - Обязательный атрибут, определяющий конкретный этап обмена запрос-ответ. СЛЕДУЕТ устанавливать его в одно из следующих значений (другие значения игнорируются): get - Запрос информации. set - Блок содержит данные для установки нового значения или замещения имеющихся данных. result - Блок содержит ответ на выполненный запрос get или set. error - Произошла ошибка при обработке или доставке запроса get или set. 6.4.3 Дочерние секции Коротко говоря, секция iq не содержит дочерних секций, поскольку сам является контейнером для XML в другом пространстве имен. Как описывается в главе Расширенные пространства имен, блок IQ МОЖЕТ содержать любую дочернюю секцию (кроме общих секций данных, секций stream или их наследников). Если type="error", то в блок НЕОБХОДИМО включать дочернюю секцию , в которой НЕОБХОДИМ атрибут 'code', соответствующий одному из Стандартных Кодов Ошибок, и МОЖЕТ также содержать PCDATA с описанием ошибки на естественном языке. 6.4.4 DTD 6.4.5 Schema 7 Место XML в протоколе XMPP 7.1 Обзор В сущности, XMPP состоит из трех взаимосвязанных частей: 1. Потоки XML (XML streams), обеспечивающие средство для асинхронной передачи данных от одного участника другому 2. Аутентификация потока посредством SASL или протокола "обратного вызова" 3. Общие секции данных (message, presence, iq), дающие основу для обмена между участниками. XML[8] используется для определения каждого протокола, как описано в следующих главах. Дополнительно, XMPP имеет расширения протокола (напр. расширенные пространства имен), направленные на обеспечение конкретной функциональности, требуемой для создания приложений для обмена сообщениями и уведомления о доступности абонента; эти расширения протокола описаны в XMPP IM[2]. 7.2 Пространства имен Пространства имен XML (XML Namespaces[12]) используются во всех XML, совместимых с XMPP, для задания строгих границ владения данными. Базовая функция пространства имен - это разделить различные списки секций XML, конструктивно объединенные вместе. Гарантируется, что XML, совместимый с XMPP разбирается с пространством имен и позволяет любым XML смешиваться с любыми элементами данных XMPP. Это свойство позволяет разделять данные XMPP и XML, обрабатываемые другими сервисами. Дополнительно, XMPP имеет более строгие ограничения на префиксы пространства имен, чем разрешено спецификацией XML. 7.3 Проверка допустимости Хост не отвечает за проверку элементов XML, отсылаемых узлу; конкретная реализация МОЖЕТ обеспечивать посылку только проверенных элементов данных, но это НЕ ТРЕБУЕТСЯ. Узлам и сервисам НЕ СЛЕДУЕТ надеяться на возможность посылки данных, которые не совместимы со схемами, и СЛЕДУЕТ игнорировать любые несовместимые секции или атрибуты во входящем XML потоке. 7.4 Расширенные пространства имен Общие секции данных, описанные в этом документе обеспечивают базовый уровень функциональности для обмена сообщениями и определения доступности абонента. XMPP использует пространство имен XML для расширения общих секций данных с целью обеспечения дополнительной функциональности. Таким образом, секции message, presence или iq могут иметь необязательную секцию, включающую содержимое, расширяющее возможности для использования сообщения (напр. шифрование тела сообщения). При использовании XMPP это дочерняя секция обычно (в блоках message и presence) или секция (в блоках IQ), но это МОЖЕТ быть любая секция (кроме общих секций данных, секций stream или их наследников). Дочерней секции НЕОБХОДИМО иметь объявление пространства имен 'xmlns' (отличное от определенного для потоков XML), которое определяет границы данных, содержащихся в дочерней секции. Примечание: все расширенные пространства имен, принятые Jabber Software Foundation[13], начинаются со строк 'jabber:x' или 'jabber:iq' (например, jabber:iq:register). 7.5 Трактовка расширенных пространств имен Поддержка расширенных пространств имен НЕОБЯЗАТЕЛЬНА в конкретной реализации. Если участник обмена не понимает какой-либо дочерней секции или пространства имен, он должен игнорировать связанные с ним данные XML. При получении блока IQ с неизвестным пространством имен, получившему СЛЕДУЕТ вернуть блок IQ с type="error" и кодом ошибки 400 (неизвестный запрос). Если получен блок message или presence, содержащий данные с неизвестным пространством имен, неизвестную часть данных СЛЕДУЕТ игнорировать. В случае получения блока message без секции , но с неизвестным пространством имен дочернего элемента, такой блок НЕОБХОДИМО игнорировать. 8 Анализ безопасности 8.1 Связь узел-хост Протокол SASL для аутентификации потоков XML, установленный между узлом и хостом (описанный выше в главе Аутентификация SASL) обеспечивает надежный механизм для проверки того, что узел подключенный к хосту - тот за кого себя выдает. 8.2 Связь хост-хост Возможность соединения одного хоста с другим является НЕОБЯЗАТЕЛЬНОЙ, обмен данными между хостами МОЖЕТ быть запрещен администратором. Если два хоста желают разрешить обмен данными друг с другом, им НЕОБХОДИМО иметь некоторые доверительные отношения, базирующиеся либо на доверии к DNS, либо на уже существующих доверительных отношениях (например, путем обмена сертификатами). Если доверительные отношения уже имеются, они МОГУТ использовать аутентификацию SASL для уверенности друг в друге. Если таковых отношений нет, им НЕОБХОДИМО использовать протокол "обратного вызова", обеспечивающий надежный механизм защиты от подмены адреса (spoofing). 8.3 Использование SASL Несмотря на то, что обеспечение безопасности - вопрос политики, все реализации, как минимум, должны обеспечивать для аутентификации механизм SASL DIGEST-MD5 Дополнительно, реализация узла может предлагать возможность проверки целостности сообщения и обеспечения конфиденциальности средствами, базирующимися на MIME, такими как OpenPGP[14] или S/MIME[15]. * Справочная информация [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging (draft-miller-jabber-xmpp-im-00, work in progress)", June 2002. [3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [4] University of Southern California, "Transmission Control Protocol", RFC 793, September 1981. [5] Internet Assigned Numbers Authority, "Internet Assigned Numbers Authority", January 1998. [6] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985. [7] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [8] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C xml, October 2000. [9] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [10] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [12] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, January 1999. [13] Jabber Software Foundation, "Jabber Software Foundation", August 2001. [14] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [15] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [16] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997. [17] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [18] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for Presence and Instant Messaging", RFC 2779, February 2000. * Связь с авторами Jeremie Miller Jabber Software Foundation 1899 Wynkoop Street, Suite 600 Denver, CO 80202 US EMail: jeremie@jabber.org URI: http://www.jabber.org/ Peter Saint-Andre Jabber Software Foundation 1899 Wynkoop Street, Suite 600 Denver, CO 80202 US EMail: stpeter@jabber.org URI: http://www.jabber.org/ A Стандартные коды ошибок Стандартная секция error используется при возникновении ошибки обработки блоков XML. Эта секция является дочерней для неудачной секции и ей НЕОБХОДИМО содержать в атрибуте 'code' один из следующих кодов ошибки. 302 (Redirect - Переадресация) - Несмотря на то, что спецификация HTTP содержит восемь различных ошибок переадресации, в XMPP определена только одна (использующаяся для сообщения о любых ошибках переадресации). Кроме того, код 302 просто зарезервирован для использования и в настоящий момент не реализован. 400 (Bad Request - Неизвестный запрос) - Код 400 используется для информирования отправителя о том, что запрос не может быть распознан принимающим. Ошибка возвращается когда, например, участник отправляет сообщение без атрибута 'to' или когда узел пытается аутентифицироваться без посылки имени пользователя. 401 (Unauthorized - Несанкционировано) - Код 401 используется для информирования узлов о том, что они представили неверную информацию для авторизации, например, неверный пароль или неизвестное имя пользователя. 402 (Payment Required - Требуется оплата) - Код 402 зарезервирован для использования в дальнейшем. В настоящий момент не используется. 403 (Forbidden - Запрещено) - Код 403 используется для информирования участника, что его запрос распознан, но получатель его отверг, например, узел пытался изменить информацию (настройки, профиль...), принадлежащую другому узлу. 404 (Not Found - Не найдено) - Код 404 используется для информирования отправителя о том, что получатель с указанным JID не найден. Например, при посылке сообщения на JID, которого не существует. (примечание: если невозможно связаться с хостом получателя, то посылается код ошибки из 500 группы) 405 (Not Allowed - Не разрешено) - Код 405 используется, когда запрошенная операция не разрешена данному JID, указанному в 'from'. Например, если узел пытается изменить время или версию на хосте. 406 (Not Acceptable - Неприемлемо) - Код 406 используется, когда блок XML по каким-либо причинам неприемлем для хоста или другого участника. Возможно, к примеру, узел пытался зарегистрироваться на хосте с пустым паролем. 407 (Registration Required - Требуется регистрация) - Код 407 используется, когда сообщение или запрос отправлен сервису, требующему предварительной регистрации. Например, узел пытался послать сообщение через шлюз в другую систему обмена сообщениями, не имея предварительной регистрации в этом шлюзе. 408 (Request Timeout - Истекло время запроса) - Код 408 возвращается, когда получатель не отвечает на запрос в течении времени ожидания отправителем. 500 (Internal Server Error - Внутренняя ошибка сервера) - Код 500 используется, когда у хоста или сервиса случается непредвиденная ситуация, мешающая нормальной обработке блока XML, посланного отправителем. Например, при запросе на аутентификацию не найден пароль, или база с паролями недоступна. 501 (Not Implemented - Не реализовано) - Код 501 используется, если получатель не поддерживает требуемую отправителю функциональность. Например, узел пытается аутентифицироваться способом, который неизвестен хосту, или узел пытается зарегистрироваться на хосте, не разрешающем регистрацию. 502 (Remote Server Error - Ошибка удаленного сервера) - Код 502 используется, когда доставка блока XML завершилась неудачей в связи с недоступностью удаленного хоста или сервиса. Например, такой код может быть возвращен при невозможности соединения или поиска хоста. 503 (Service Unavailable - Сервис недоступен) - Код 503 используется, когда отправитель запрашивает сервис, который получатель в настоящий момент не может предоставить. Например, отправитель пытается послать сообщение получателю, находящемуся offline, а хост не поддерживает хранение сообщений для offline пользователей. 504 (Remote Server Timeout - Истекло время ожидания удаленного сервера) - Код 504 используется, когда вышел интервал времени для связи с удаленным хостом. Например, задано некорректное имя хоста. B Регистрация в IANA В IANA зарегистрированы как GSS-API[16] имена сервисов "jabber-client" и "jabber-server". * Авторское право (без перевода) Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.