draft-ietf-xmpp-core-22.txt

开源代码的pwlib的1.10.0版本,使用openh323的1.18.0版本毕备

Internet-Draft                 XMPP Core                      March 2004


       receiving entity and initiating entity MUST consider the original
       stream to be closed upon successful TLS negotiation).

   8.  Upon receiving the new stream header from the initiating entity,
       the receiving entity MUST respond by sending a new XML stream
       header to the initiating entity along with the available features
       (but not including the STARTTLS feature).


5.3 Client-to-Server Example

   The following example shows the data flow for a client securing a
   stream using STARTTLS (note: the alternate steps shown below are
   provided to illustrate the protocol for failure cases; they are not
   exhaustive and would not necessarily be triggered by the data sent in
   the example).

   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>





Saint-Andre (ed.)      Expires September 17, 2004              [Page 23]

Internet-Draft                 XMPP Core                      March 2004


   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 (Section 6).




Saint-Andre (ed.)      Expires September 17, 2004              [Page 24]

Internet-Draft                 XMPP Core                      March 2004


5.4 Server-to-Server Example

   The following example shows the data flow for two servers securing a
   stream using STARTTLS (note: the alternate steps shown below are
   provided to illustrate the protocol for failure cases; they are not
   exhaustive and would not necessarily be triggered by the data sent in
   the example).

   Step 1: Server1 initiates stream to Server2:

   <stream:stream
       xmlns='jabber:server'
       xmlns:stream='http://etherx.jabber.org/streams'
       to='example.com'
       version='1.0'>

   Step 2: Server2 responds by sending a stream tag to Server1:

   <stream:stream
       xmlns='jabber:server'
       xmlns:stream='http://etherx.jabber.org/streams'
       from='example.com'
       id='s2s_123'
       version='1.0'>

   Step 3: Server2 sends the STARTTLS extension to Server1 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>KERBEROS_V4</mechanism>
     </mechanisms>
   </stream:features>

   Step 4: Server1 sends the STARTTLS command to Server2:

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

   Step 5: Server2 informs Server1 that it is allowed to proceed:

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

   Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed
   and closes stream:



Saint-Andre (ed.)      Expires September 17, 2004              [Page 25]

Internet-Draft                 XMPP Core                      March 2004


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

   Step 6: Server1 and Server2 attempt to complete TLS negotiation via
   TCP.

   Step 7: If TLS negotiation is successful, Server1 initiates a new
   stream to Server2:

   <stream:stream
       xmlns='jabber:server'
       xmlns:stream='http://etherx.jabber.org/streams'
       to='example.com'
       version='1.0'>

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

   Step 8: Server2 responds by sending a stream header to Server1 along
   with any available stream features:

   <stream:stream
       xmlns='jabber:server'
       xmlns:stream='http://etherx.jabber.org/streams'
       from='example.com'
       id='s2s_234'
       version='1.0'>
   <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>KERBEROS_V4</mechanism>
       <mechanism>EXTERNAL</mechanism>
     </mechanisms>
   </stream:features>

   Step 9: Server1 continues with SASL negotiation (Section 6).

6. Use of SASL

6.1 Overview

   XMPP includes a method for authenticating a stream by means of an
   XMPP-specific profile of the Simple Authentication and Security Layer
   (SASL) protocol [SASL].  SASL provides a generalized method for
   adding authentication support to connection-based protocols, and XMPP
   uses a generic XML namespace profile for SASL that conforms to the
   profiling requirements of [SASL].




Saint-Andre (ed.)      Expires September 17, 2004              [Page 26]

Internet-Draft                 XMPP Core                      March 2004


   The following rules apply:

   1.   If the SASL negotiation occurs between two servers,
        communications MUST NOT proceed until the Domain Name System
        (DNS) hostnames asserted by the servers have been resolved (see
        Server-to-Server Communications (Section 14.4)).

   2.   If the initiating entity is capable of SASL negotiation, it MUST
        include the 'version' attribute set to a value of at least "1.0"
        in the initial stream header.

   3.   If the receiving entity is capable of SASL negotiation, it MUST
        advertise one or more authentication mechanisms within a
        <mechanisms/> element qualified by the
        'urn:ietf:params:xml:ns:xmpp-sasl' namespace in reply to the
        opening stream tag received from the initiating entity (if the
        opening stream tag included the 'version' attribute set to a
        value of at least "1.0").

   4.   During SASL negotiation, an entity MUST NOT send any white space
        characters (matching production [3] content of [XML]) within the
        root stream element as separators between elements (any white
        space characters shown in the SASL examples below are included
        for the sake of readability only); this prohibition helps to
        ensure proper security layer byte precision.

   5.   Any XML character data contained within the XML elements used
        during SASL negotiation MUST be encoded using base64, where the
        encoding adheres to the definition in Section 3 of RFC 3548
        [BASE64].

   6.   If provision of a "simple username" is supported by the selected
        SASL mechanism (e.g., this is supported by the DIGEST-MD5 and
        CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI
        mechanisms), during authentication the initiating entity SHOULD
        provide as the simple username its sending domain (IP address or
        fully qualified domain name as contained in a domain identifier)
        in the case of server-to-server communications or its registered
        account name (user or node name as contained in an XMPP node
        identifer) in the case of client-to-server communications.

   7.   If the initiating entity wishes to act on behalf of another
        entity and the selected SASL mechanism supports transmission of
        an authorization identity, the initiating entity MUST provide an
        authorization identity during SASL negotiation.  If the
        initiating entity does not wish to act on behalf of another
        entity, it MUST NOT provide an authorization identity.  As
        specified in [SASL], the initiating entity MUST NOT provide an



Saint-Andre (ed.)      Expires September 17, 2004              [Page 27]

Internet-Draft                 XMPP Core                      March 2004


        authorization identity unless the authorization identity is
        different from the default authorization identity derived from
        the authentication identity as described in [SASL].  If
        provided, the value of the authorization identity MUST be of the
        form <domain> (i.e., a domain identifier only) for servers and
        of the form <node@domain> (i.e., node identifier and domain
        identifier) for clients.

   8.   Upon successful SASL negotiation that involves negotiation of a
        security layer, the receiving entity MUST discard any knowledge
        obtained from the initiating entity which was obtained in an
        insecure manner before the SASL negotiation.

   9.   Upon successful SASL negotiation that involves negotiation of a
        security layer, the initiating entity MUST discard any knowledge
        obtained from the receiving entity which was not obtained from
        the SASL negotiation itself.

   10.  See Mandatory-to-Implement Technologies (Section 14.7) regarding
        mechanisms that MUST be supported.


6.2 Narrative

   When an initiating entity authenticates with a receiving