📄 draft-ietf-xmpp-core-22.txt
字号:
o <resource-constraint/> -- the server lacks the system resources
necessary to service the stream.
o <restricted-xml/> -- the entity has attempted to send restricted
XML features such as a comment, processing instruction, DTD,
entity reference, or unescaped character (see Restrictions
(Section 11.1)).
o <see-other-host/> -- the server will not provide service to the
initiating entity but is redirecting traffic to another host; the
server SHOULD specify the alternate hostname or IP address (which
MUST be a valid domain identifier) as the XML character data of
the <see-other-host/> element.
o <system-shutdown/> -- the server is being shut down and all active
streams are being closed.
o <undefined-condition/> -- the error condition is not one of those
defined by the other conditions in this list; this error condition
SHOULD be used only in conjunction with an application-specific
condition.
Saint-Andre (ed.) Expires September 17, 2004 [Page 17]
Internet-Draft XMPP Core March 2004
o <unsupported-encoding/> -- the initiating entity has encoded the
stream in an encoding that is not supported by the server (see
Character Encoding (Section 11.5)).
o <unsupported-stanza-type/> -- the initiating entity has sent a
first-level child of the stream that is not supported by the
server.
o <unsupported-version/> -- the value of the 'version' attribute
provided by the initiating entity in the stream header specifies a
version of XMPP that is not supported by the server; the server
MAY specify the version(s) it supports in the <text/> element.
o <xml-not-well-formed/> -- the initiating entity has sent XML that
is not well-formed as defined by [XML].
4.7.4 Application-Specific Conditions
As noted, an application MAY provide application-specific stream
error information by including a properly-namespaced child in the
error element. The application-specific element SHOULD supplement or
further qualify a defined element. Thus the <error/> element will
contain two or three child elements:
<stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information!
</text>
<escape-your-data xmlns='application-ns'/>
</stream:error>
</stream:stream>
4.8 Simplified Stream Examples
This section contains two simplified examples of a stream-based
"session" of a client on a server (where the "C" lines are sent from
the client to the server, and the "S" lines are sent from the server
to the client); these examples are included for the purpose of
illustrating the concepts introduced thus far.
A basic "session":
C: <?xml version='1.0'?>
<stream:stream
Saint-Andre (ed.) Expires September 17, 2004 [Page 18]
Internet-Draft XMPP Core March 2004
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
... encryption, authentication, and resource binding ...
C: <message from='juliet@example.com'
to='romeo@example.net'
xml:lang='en'>
C: <body>Art thou not Romeo, and a Montague?</body>
C: </message>
S: <message from='romeo@example.net'
to='juliet@example.com'
xml:lang='en'>
S: <body>Neither, fair saint, if either thee dislike.</body>
S: </message>
C: </stream:stream>
S: </stream:stream>
A "session" gone bad:
C: <?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
... encryption, authentication, and resource binding ...
C: <message xml:lang='en'>
<body>Bad XML, no closing body tag!
</message>
S: <stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
Saint-Andre (ed.) Expires September 17, 2004 [Page 19]
Internet-Draft XMPP Core March 2004
S: </stream:stream>
5. Use of TLS
5.1 Overview
XMPP includes a method for securing the stream from tampering and
eavesdropping. This channel encryption method makes use of the
Transport Layer Security (TLS) protocol [TLS], along with a
"STARTTLS" extension that is modelled after similar extensions for
the IMAP [IMAP], POP3 [POP3], and ACAP [ACAP] protocols as described
in RFC 2595 [USINGTLS]. The namespace name for the STARTTLS
extension is 'urn:ietf:params:xml:ns:xmpp-tls'.
An administrator of a given domain MAY require the use of TLS for
client-to-server communications, server-to-server communications, or
both. Clients SHOULD use TLS to secure the streams prior to
attempting to complete SASL negotiation (Section 6), and servers
SHOULD use TLS between two domains for the purpose of securing
server-to-server communications.
The following rules apply:
1. An initiating entity that complies with this specification MUST
include the 'version' attribute set to a value of "1.0" in the
initial stream header.
2. If the TLS 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)).
3. When a receiving entity that complies with this specification
receives an initial stream header that includes the 'version'
attribute set to a value of at least "1.0", after sending a
stream header in reply (including the version flag) it MUST
include a <starttls/> element (qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list
of other stream features it supports.
4. If the initiating entity chooses to use TLS, TLS negotiation
MUST be completed before proceeding to SASL negotiation; this
order of negotiation is required in order to help safeguard
authentication information sent during SASL negotiation, as well
as to make it possible to base the use of the SASL EXTERNAL
mechanism on a certificate provided during prior TLS
negotiation.
Saint-Andre (ed.) Expires September 17, 2004 [Page 20]
Internet-Draft XMPP Core March 2004
5. During TLS 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 TLS examples below are included
for the sake of readability only); this prohibition helps to
ensure proper security layer byte precision.
6. The receiving entity MUST consider the TLS negotiation to have
begun immediately after sending the closing ">" character of the
<proceed/> element. The initiating entity MUST consider the TLS
negotiation to have begun immediately after receiving the
closing ">" character of the <proceed/> element from the
receiving entity.
7. The initiating entity MUST validate the certificate presented by
the receiving entity; see Certificate Validation (Section 14.2)
regarding certificate validation procedures.
8. Certificates MUST be checked against the hostname as provided by
the initiating entity (e.g., a user), not the hostname as
resolved via the Domain Name System; e.g., if the user specifies
a hostname of "example.com" but a DNS SRV [SRV] lookup returned
"im.example.com", the certificate MUST be checked as
"example.com". If a JID for any kind of XMPP entity (e.g.,
client or server) is represented in a certificate, it SHOULD be
encoded as a GeneralName entry of type otherName inside the
subjectAltName, along with a type-id whose value is "xmpp" (as
these terms are profiled in [X509]).
9. If the TLS negotiation is successful, the receiving entity MUST
discard any knowledge obtained in an insecure manner from the
initiating entity before TLS takes effect.
10. If the TLS negotiation is successful, the initiating entity MUST
discard any knowledge obtained in an insecure manner from the
receiving entity before TLS takes effect.
11. If the TLS negotiation is successful, the receiving entity MUST
NOT offer the STARTTLS extension to the initiating entity along
with the other stream features that are offered when the stream
is restarted.
12. If the TLS negotiation is successful, the initiating entity MUST
continue with SASL negotiation.
13. If the TLS negotiation results in failure, the receiving entity
MUST terminate both the XML stream and the underlying TCP
connection.
Saint-Andre (ed.) Expires September 17, 2004 [Page 21]
Internet-Draft XMPP Core March 2004
14. See Mandatory-to-Implement Technologies (Section 14.7) regarding
mechanisms that MUST be supported.
5.2 Narrative
When an initiating entity secures a stream with a receiving entity
using TLS, the steps involved are as follows:
1. The initiating entity opens a TCP connection and initiates the
stream by sending the opening XML stream header to the receiving
entity, including the 'version' attribute set to a value of at
least "1.0".
2. The receiving entity responds by opening a TCP connection and
sending an XML stream header to the initiating entity, including
the 'version' attribute set to a value of at least "1.0".
3. The receiving entity offers the STARTTLS extension to the
initiating entity by including it with the list of other
supported stream features (if TLS is required for interaction
with the receiving entity, it SHOULD signal that fact by
including a <required/> element as a child of the <starttls/>
element).
4. The initiating entity issues the STARTTLS command (i.e., a
<starttls/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the
receiving entity that it wishes to begin a TLS negotiation to
secure the stream.
5. The receiving entity MUST reply with either a <proceed/> element
or a <failure/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case
occurs, the receiving entity MUST terminate both the XML stream
and the underlying TCP connection. If the proceed case occurs,
the entities MUST attempt to complete the TLS negotiation over
the TCP connection and MUST NOT send any further XML data until
the TLS negotiation is complete.
6. The initiating entity and receiving entity attempt to complete a
TLS negotiation in accordance with [TLS].
7. If the TLS negotiation is unsuccessful, the receiving entity MUST
terminate the TCP connection. If the TLS negotiation is
successful, the initiating entity MUST initiate a new stream by
sending an opening XML stream header to the receiving entity (it
is not necessary to send a closing </stream> tag first, since the
Saint-Andre (ed.) Expires September 17, 2004 [Page 22]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -