Jabber学习笔记 之二

三、Jabber核心协议（XMPP Core ：RFC3920）

1、 ／XML StanzaXML Stream

Stream ：以<stream>开始，至</stream>结束，在整个生命周期中，可以包含任意数量的XML元素

Stanza：Stream中结构化的XML片断

整个流看起来大致如下：

|--------------------|

| <stream>           |

|--------------------|

| <presence>         |

|   <show/>          |

| </presence>        |

|--------------------|

| <message to='foo'> |

|   <body/>          |

| </message>         |

|--------------------|

| <iq to='bar'>      |

|   <query/>         |

| </iq>              |

|--------------------|

| ...                |

|--------------------|

| </stream>          |

|--------------------|

 

 

2、 Stream Attributes

to ：用于发起方stream 中（initial stream），表明接收者，响应Stream不能包含to，如果有则被忽略；

from ：用于响应Stream中（response stream），表明接收者，发起方Stream不能包含from，如果有则被忽略；

id ：用于响应Stream中，唯一性标识，出于安全性考虑，建议随机生成；

xml:lang：缺省语言

version：版本号，通常为1.0

 

3、 Stream Error:

当遇到有stream级别的错误时，需要发送一个<error/>tag，具体语法如下：

<stream:error>

 <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>

 <text xmlns='urn:ietf:params:xml:ns:xmpp-streams'

        xml:lang='langcode'>

    OPTIONAL descriptive text

 </text>

 [OPTIONAL application-specific condition element]

</stream:error>

 

defined-condition举例：<xml-not-well-formed/>、<not-authorized/>、<bad-format/>、<host-unknown/>等

 

4、 Transport Layer Security (TLS) protocol

当一个Stream被发起以后，需要通过TLS来保证连接的安全性，下面是一个从客户端到服务器的例子。

Step 1: Client initiates stream to server:

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    to='example.com'

    version='1.0'>

Step 2: Server responds by sending a stream tag to client:

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    id='c2s_123'

    from='example.com'

    version='1.0'>

Step 3: Server sends the STARTTLS extension to client along with authentication mechanisms and any other stream features:

<stream:features>

 <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>

    <required/>

 </starttls>

 <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

    <mechanism>DIGEST-MD5</mechanism>

    <mechanism>PLAIN</mechanism>

 </mechanisms>

</stream:features>

Step 4: Client sends the STARTTLS command to server:

<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

Step 5: Server informs client that it is allowed to proceed:

<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

Step 5 (alt): Server informs client that TLS negotiation has failed and closes both stream and TCP connection:

<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

</stream:stream>

Step 6: Client and server attempt to complete TLS negotiation over the existing TCP connection.

Step 7: If TLS negotiation is successful, client initiates a new stream to server:

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    to='example.com'

    version='1.0'>

Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP connection.

Step 8: Server responds by sending a stream header to client along with any available stream features:

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    from='example.com'

    id='c2s_234'

    version='1.0'>

<stream:features>

 <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

    <mechanism>DIGEST-MD5</mechanism>

    <mechanism>PLAIN</mechanism>

    <mechanism>EXTERNAL</mechanism>

 </mechanisms>

</stream:features>

Step 9: Client continues with SASL negotiation (Use of SASL).

 

5、Simple Authentication and Security Layer (SASL) protocol

在TLS之后是用户的安全认证，采用SASL协议，下面是一个从client到server的例子：

   Step 1: Client initiates stream to server:

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    to='example.com'

    version='1.0'>

Step 2: Server responds with a stream tag sent to client:

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    id='c2s_234'

    from='example.com'

    version='1.0'>

Step 3: Server informs client of available authentication mechanisms:

<stream:features>

 <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

    <mechanism>DIGEST-MD5</mechanism>

    <mechanism>PLAIN</mechanism>

 </mechanisms>

</stream:features>

Step 4: Client selects an authentication mechanism:

<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

      mechanism='DIGEST-MD5'/>

Step 5: Server sends a [BASE64] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) encoded challenge to client:

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi

LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==

</challenge>

The decoded challenge is:

realm="somerealm",nonce="OA6MG9tEQGm2hh",/

qop="auth",charset=utf-8,algorithm=md5-sess

Step 5 (alt): Server returns error to client:

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

 <incorrect-encoding/>

</failure>

</stream:stream>

Step 6: Client sends a [BASE64] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) encoded response to the challenge:

<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i

T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw

MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i

LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo

YXJzZXQ9dXRmLTgK

</response>

The decoded response is:

username="somenode",realm="somerealm",/

nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",/

nc=00000001,qop=auth,digest-uri="xmpp/example.com",/

response=d388dad90d4bbd760a152321f2143af7,charset=utf-8

Step 7: Server sends another [BASE64] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) encoded challenge to client:

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=

</challenge>

The decoded challenge is:

rspauth=ea40f60335c427b5527b84dbabcdfffd

Step 7 (alt): Server returns error to client:

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

 <temporary-auth-failure/>

</failure>

</stream:stream>

Step 8: Client responds to the challenge:

<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

Step 9: Server informs client of successful authentication:

<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

Step 9 (alt): Server informs client of failed authentication:

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

 <temporary-auth-failure/>

</failure>

</stream:stream>

Step 10: Client initiates a new stream to server:

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    to='example.com'

    version='1.0'>

Step 11: Server responds by sending a stream header to client along with any additional features (or an empty features element):

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    id='c2s_345'

    from='example.com'

    version='1.0'>

<stream:features>

 <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>

 <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>

</stream:features>

 

6、  Resource Binding

SASL之后便是Resource Binding，但这个只是client到server时需要，而server与server之间不需要。

    Server advertises resource binding feature to client:

<stream:stream

    xmlns='jabber:client'

    xmlns:stream='http://etherx.jabber.org/streams'

    id='c2s_345'

    from='example.com'

    version='1.0'>

<stream:features>

 <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>

</stream:features>

If the client wishes to allow the server to generate the resource identifier on its behalf, it sends an IQ stanza of type "set" that contains an empty <bind/> element:

Client asks server to bind a resource:

<iq type='set' id='bind_1'>

 <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>

</iq>

A server that supports resource binding MUST be able to generate a resource identifier on behalf of a client. A resource identifier generated by the server MUST be unique for that <node@domain>.

If the client wishes to specify the resource identifier, it sends an IQ stanza of type "set" that contains the desired resource identifier as the XML character data of a <resource/> element that is a child of the <bind/> element:

Client binds a resource:

<iq type='set' id='bind_2'>

 <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

    <resource>someresource</resource>

 </bind>

</iq>

Once the server has generated a resource identifier for the client or accepted the resource identifier provided by the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server:

Server informs client of successful resource binding:

<iq type='result' id='bind_2'>

 <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

    <jid>[e-mail]/someresource</jid>

 </bind>

</iq>

A server SHOULD accept the resource identifier provided by the client, but MAY override it with a resource identifier that the server generates; in this case, the server SHOULD NOT return a stanza error (e.g., <forbidden/>) to the client but instead SHOULD communicate the generated resource identifier to the client in the IQ result as shown above.

When a client supplies a resource identifier, the following stanza error conditions are possible (see Stanza Errors (Stanza Errors)):

·         The provided resource identifier cannot be processed by the server in accordance with Resourceprep (Resourceprep).

·         The client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed).

·         The provided resource identifier is already in use but the server does not allow binding of multiple connected resources with the same identifier.

The protocol for these error conditions is shown below.

Resource identifier cannot be processed:

<iq type='error' id='bind_2'>

 <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

    <resource>someresource</resource>

 </bind>

 <error type='modify'>

    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

 </error>

</iq>

Client is not allowed to bind a resource:

<iq type='error' id='bind_2'>

 <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

    <resource>someresource</resource>

 </bind>

 <error type='cancel'>

    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

 </error>

</iq>

Resource identifier is in use:

<iq type='error' id='bind_2'>

 <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

    <resource>someresource</resource>

 </bind>

 <error type='cancel'>

    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

 </error>

</iq>

If, before completing the resource binding step, the client attempts to send an XML stanza other than an IQ stanza with a <bind/> child qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the server MUST NOT process the stanza and SHOULD return a <not-authorized/> stanza error to the client.

 

7、  XML Stanzas

'jabber:client'和'jabber:server'命名空间定义了三种stanza:<message/>、 <presence/>、<iq/>.

       详细定义需要学习RFC3921。

8、  实验

分别选择两个Jabber Server做连接测试：

第一个：jabber.org

telnet jabber.org 5222

<?xml version='1.0'?>

<stream:stream

       to='jabber.org'

       xmlns='jabber:client'

       xmlns:stream='http://etherx.jabber.org/streams'

       version='1.0'>

收到如下内容：

<?xml version='1.0'?>

<stream:stream

       xmlns='jabber:client'

       xmlns:stream='http://etherx.jabber.org/streams'

       id='94769953'

       from='jabber.org'

       version='1.0'

       xml:lang='en'>

      

       <stream:features>

              <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

              <compression xmlns='http://jabber.org/features/compress'>

                     <method>zlib</method>

              </compression>                  

              <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

                     <mechanism>DIGEST-MD5</mechanism>

                     <mechanism>PLAIN</mechanism>

              </mechanisms>

              <register xmlns='http://jabber.org/features/iq-register'/>

       </stream:features>

从返回的内容来看，基本上跟RFC3720所说一致，不过多了一个压缩？，接下来就没法进行了，看来还得研究一下压缩算法

 

第二个：talk.google.com，这个就是大名鼎鼎的Google Talk了，由于也是采用XMPP，因此也可能连接：

telnet talk.google.com 5222

<?xml version='1.0'?>

<stream:stream

       to='google.com'

       xmlns='jabber:client'

       xmlns:stream='http://etherx.jabber.org/streams'

       version='1.0'>

收到内容如下：

<?xml version="1.0" encoding="UTF-8"?>

<stream:stream from="google.com"

       id="8F2DEA3E08EDD09C"

       version="1.0"

       xmlns:stream="http://etherx.jabber.org/streams"

       xmlns="jabber:client">

       <stream:features>

              <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>

              <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">

                     <mechanism>X-GOOGLE-TOKEN</mechanism>

              </mechanisms>

       </stream:features>

google talk倒是没采用压缩算法，不过居然是自己专用的SASL。

接下来发送：

<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>

收到：

<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>

TLS还是能够顺利进行的，接下来的就没法进行了。可以看出跟Google Talk通信是可行的，只不过需要熟悉Google Talk的扩展协议，目前暂时还没有收集这方面的资料。