&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as postmaster@domain.tld, usenet@domain.tld, and webmaster@domain.tld). However, no such conventional email address or Jabber ID (JID) has been specified for XMPP services. This document remedies that oversight.
+&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as postmaster@domain.tld, usenet@domain.tld, and webmaster@domain.tld). However, no such conventional email address or XMPP address (JID) has been specified for XMPP services. This document remedies that oversight.
Many existing Jabber/XMPP server implementations use the bare domain of the server as an alias for the server administrators, such that a &MESSAGE; stanza addressed to that domain name (e.g., "jabber.org") is delivered to the JIDs of the server administrators (this does not apply to &IQ; or &PRESENCE; stanzas). It is RECOMMENDED that all server implementations support this functionality, and the authors will work toward standardization of this functionality in the forthcoming revisions to &rfc3920;.
+Many existing Jabber/XMPP server implementations use the bare domain of the server as an alias for the server administrator(s), such that a &MESSAGE; stanza addressed to that domain name (e.g., "jabber.org") is delivered to the JIDs of the server administrator(s).
Consistent with RFC 2142, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service, which MAY be advertised through a URI of <mailto:xmpp@domain.tld>.
+Consistent with RFC 2142, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service. A domain that provides such functionality MAY also advertise the service through a Mailto URI (see &rfc2368;) of <mailto:xmpp@domain.tld>.
Advertising contact addresses may open those addresses to unwanted communication. Server administrators should balance the need for openness with the desire for control over communication with customers and peers. That said, certain contact addresses (e.g., abuse addresses and security addresses) may enable server administrators to more quickly learn of abusive usage and potential security holes, and advertisement of those addresses is strongly encouraged.
+Providing or advertising contact addresses may open those addresses to unwanted communication. Server administrators should balance the need for openness with the desire for control over communication with customers and peers.
This document requires no interaction with &IANA;.
RFC 3920 does not specify how to generate the keys used in the server dialback protocol, and why each of the variables used in key generation is crucial for security. This document is provided for discussion purposes and aims at clarifying the key generation and its validation mechanism and to show common attacks on weak mechanisms. It is not meant to supersede the text in RFC 3920; however, the recommendations in this document have been incorporated into rfc3920bis.
+RFC 3920 does not specify in detail how to generate the keys used in the server dialback protocol, and why each of the variables used in key generation is crucial for security. This document is provided for discussion purposes and aims at clarifying the key generation and its validation mechanism and to show common attacks on weak mechanisms. It is not meant to supersede the text in RFC 3920; however, the recommendations in this document have been incorporated into rfc3920bis.
The Originating Server, which generates the dialback key, and the Authoritative Server, which validates the dialback key, may reside on different hosts or be running in separate processes. The method used in key generation and validation should not require interactive communication between Originating Server, Authoritative Server and optionally a third party like a database.
-The key is generated based on
+The key is generated based on:
The last item, a shared secret known to Originating Server and Authoritative Server, is used in a Keyed-Hash Message Authentication Code (HMAC) to generate and validate the dialback keys. This key must either be set up in a configuration option for each host or process or generated as a random string when starting the server.
-&nistfips198a; recommends that the length of the key should be at least half of the size of the hash function output. To fulfill this requirement, the secret should be hashed with the hash function prior to usage as key in HMAC.
+The last item, a shared secret known to Originating Server and Authoritative Server, is used in a Keyed-Hash Message Authentication Code (HMAC) to generate and validate the dialback keys. This key must either be set up in a configuration option for each host or process, or generated as a random string when starting the server.
+&nistfips198a; recommends that the length of the key should be at least half the size of the hash function output. To fulfill this requirement, the secret SHOULD be hashed with the hash function prior to usage as a key in HMAC.
The Stream ID and the involved hostnames should be concatenated with a unicode space character (U+0020) for the delimiter.
key = HEX( HMAC-SHA256( SHA256(Secret), { Receiving Server, ' ',
@@ -76,8 +76,10 @@ key = HEX( HMAC-SHA256( SHA256(Secret), { Receiving Server, ' ',
To avoid problems of encoding, a hexadecimal representation of the digest algorithm output SHOULD be used.
| Originating and Authoritative Server | example.com | @@ -95,9 +97,6 @@ key = HEX( HMAC-SHA256( SHA256(Secret), { Receiving Server, ' ',D60000229F |
This document closely follows the description of the dialback protocol in RFC 3920, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of RFC 3920.
3. Receiving Server sends a stream header back to the Originating Server, including a unique ID for this interaction:
The Originating Server now generates a dialback key to be sent to the Receiving Server:
-key = HMAC-SHA256( SHA256(secret), { Receiving server, ' ', Originating server, ' ', Stream ID})
- = HMAC-SHA256( SHA256('s3cr3tf0rd14lb4ck'), { 'example.net', ' ', 'example.com', ' ', 'D60000229F' })
- = HMAC-SHA256( 'a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc', 'example.net example.com D60000229F')
+key = HMAC-SHA256(
+ SHA256(secret),
+ { Receiving server, ' ', Originating server, ' ', Stream ID}
+ )
+ = HMAC-SHA256(
+ SHA256('s3cr3tf0rd14lb4ck'),
+ { 'example.net', ' ', 'example.com', ' ', 'D60000229F' }
+ )
+ = HMAC-SHA256(
+ 'a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc',
+ 'example.net example.com D60000229F'
+ )
= '008c689ff366b50c63d69a3e2d2c0e0e1f8404b0118eb688a0102c87cb691bdc'
4. The Originating Server sends the generated dialback key to the Receiving Server:
@@ -134,9 +142,18 @@ key = HMAC-SHA256( SHA256(secret), { Receiving server, ' ', Originating server, ]]>The Authoritative Server calculates the valid key for this verify request, using data supplied in the packet and the secret shared with the Originating Server.
-key = HMAC-SHA256( secret, { Receiving Server, ' ', Authoritative Server, ' ', Stream ID })
- = HMAC-SHA256( SHA256('s3cr3tf0rd14lb4ck'), { 'example.net', ' ', 'example.com', ' ', 'D60000229F' })
- = HMAC-SHA256( 'a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc', 'example.net example.com D60000229F')
+key = HMAC-SHA256(
+ secret,
+ { Receiving Server, ' ', Authoritative Server, ' ', Stream ID }
+ )
+ = HMAC-SHA256(
+ SHA256('s3cr3tf0rd14lb4ck'),
+ { 'example.net', ' ', 'example.com', ' ', 'D60000229F' }
+ )
+ = HMAC-SHA256(
+ 'a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc',
+ 'example.net example.com D60000229F'
+ )
= '008c689ff366b50c63d69a3e2d2c0e0e1f8404b0118eb688a0102c87cb691bdc'
9. The Authoritative Server compares this value to the key contained in the verification requests and informs the Originating Server of the result, in our example a success:
@@ -151,7 +168,7 @@ key = HMAC-SHA256( secret, { Receiving Server, ' ', Authoritative Server, ' ', SThis section contains attack scenarios that illustrate why each of the factors used in key generation is important.
An attacker will assume the role of the Originating Server and try to send a dialback key that the Authoritative Server acknowledges as valid. If this is successful, the attacker is allowed to send packets for the hostname of the Authoritative Server.
-In each subsection, the example hash method, which uses the SHA1 algorithm as described in &rfc3174; for simplicity, ignores one of the variables,
+In each subsection, the example hash method, which uses the (compromised and NOT RECOMMENDED) SHA1 algorithm as described in &rfc3174; for simplicity, ignores one of the variables,
key = SHA1({ Secret, Originating Server, Stream ID })
- The attacker can use a dialback key and stream ID we have sent a domain under his control.
+The attacker can use a dialback key and stream ID we have sent to a domain under his control.
This document introduces no security considerations or concerns above and beyond those discussed in RFC3920, but describes what might happen if the security considerations are ignored.
+This document introduces no security considerations or concerns above and beyond those discussed in RFC 3920, but describes what might happen if the security considerations are ignored.
This document requires no interaction with &IANA;.
diff --git a/xep-0190.xml b/xep-0190.xml index 12b59402..59f013bf 100644 --- a/xep-0190.xml +++ b/xep-0190.xml @@ -7,7 +7,7 @@RFC 3920 offers several ways on how to terminate an XMPP stream, but - doesn't always make a clear statement which one to take. This can lead - to faulty implementations. In particular, closing a stream that hasn't - been in use for a while is very often achieved using a connection-timeout - error, then closing the socket. This can lead to loss of data. Therefore - this document proposes a practice that will avoid such data loss. Note: The - recommendation described herein has been incorporated into rfc3920bis.
+RFC 3920 describes several ways to terminate an XMPP stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.
+Note: The recommendation described herein has been incorporated into rfc3920bis.
As shown in the basic "session" example in the - Simplified Stream Examples (4.8 of RFC 3920), - it is a valid transaction to close the outgoing stream by sending +
As shown in the basic "session" example in the Simplified Stream Examples (4.8 of RFC 3920), it is a valid transaction to close the outgoing stream by sending
]]>
then wait for the other entity to close its stream, like this:
]]>
and shut down the underlying TCP connection.
This will ensure that, should the other entity have transmitted - any data, it will arrive and be processed before the TCP connection - is terminated.
-Special care MUST be taken that under no circumstance further - packets may be written to the socket after the stream was closed, - until the other side shuts down the socket.
-On the outgoing TCP connection you MAY do a read-only shutdown - of the socket, as long as the other side will safely be able to - send its stream termination token.
+This will ensure that, should the other entity have transmitted any data, it will arrive and be processed before the TCP connection is terminated.
+Special care MUST be taken that under no circumstance further packets may be written to the socket after the stream was closed, until the other side shuts down the socket.
+On the outgoing TCP connection, an implementation MAY do a read-only shutdown of the socket, as long as the other side will safely be able to send its stream termination token.
In case the other entity fails to close the stream within a - reasonable time frame, the entity that started the handshake is - entitled to terminate the TCP connection. Since the stream has - already been closed, it is correct not to produce an error condition.
+In case the other entity fails to close the stream within a reasonable time frame, the entity that started the handshake is entitled to terminate the TCP connection. Since the stream has already been closed, it is correct not to produce an error condition.
Please update your implementations to use the 'Handshake Stream Shutdown' - strategy when shutting down streams you no longer need.
-Even not to shut down idle streams at all is a better strategy than to - shut them down by creating an error condition, so if your application - has no necessity for shutting down idle connections, just don't do it.
+Existing implementations should be updated to use the 'Handshake Stream Shutdown' strategy when shutting down streams that are no longer needed. This strategy is fully backwards-compatible and does not introduce any known communication problems.
This proposal introduces no new security aspects.
This proposal requires no interaction with &IANA;.
This proposal requires no interaction with the ®ISTRAR;.
As specified in RFC 3920, suupport for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:
+As specified in RFC 3920, support for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:
RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a client daemon that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings. Note: The recommendations described herein have been incorporated into rfc3920bis.
+RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &xep0078;). As defined in RFC 3920, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.
+Note: The recommendations described herein have been incorporated into rfc3920bis.
In order to properly manage the resources associated with an XML stream, a client must be able to unbind resources. This shall be completed by sending an IQ-set with a child element of <unbind/> qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of <resource/> whose XML character data specifies the resource to be unbound:
@@ -53,7 +54,7 @@ ]]>If the server does not understand the <unbind/> element, it MUST return an error of &badrequest;. Otherwise, if there is no such resource, the server MUST return an error of ¬found;. When the client unbinds the only resource associated with the stream, the server SHOULD close the stream and terminate the TCP connection.
-A server SHOULD advertise its support for the 'urn:ietf:params:xml:ns:xmpp-bind' namespace by returning an appropriate stream feature as shown below:
+A server SHOULD advertise its support for the 'urn:ietf:params:xml:ns:xmpp-bind' namespace and the unbind functionality by returning an appropriate stream feature as shown below: