view release on metacpan or  search on metacpan

doc/rfc3920-notes.txt  view on Meta::CPAN

   the fallback is a normal IPv4/IPv6 address record resolution to
   determine the IP address, using the "xmpp-server" port 5269,
   registered with the IANA.

   Server dialback helps protect against domain spoofing, thus making it
   more difficult to spoof XML stanzas.  It is not a mechanism for
   authenticating, securing, or encrypting streams between servers as is
   done via SASL and TLS, and results in weak verification of server
   identities only.  Furthermore, it is susceptible to DNS poisoning
   attacks unless DNSSec [DNSSEC] is used, and even if the DNS



Saint-Andre, Ed.            Standards Track                    [Page 66]

RFC 3920                       XMPP Core                    October 2004


   information is accurate, dialback cannot protect from attacks where
   the attacker is capable of hijacking the IP address of the remote
   domain.  Domains requiring robust security SHOULD use TLS and SASL.
   If SASL is used for server-to-server authentication, dialback SHOULD
   NOT be used since it is unnecessary.

14.5.  Order of Layers

   The order of layers in which protocols MUST be stacked is as follows:

   1.  TCP
   2.  TLS
   3.  SASL
   4.  XMPP

   The rationale for this order is that [TCP] is the base connection
   layer used by all of the protocols stacked on top of TCP, [TLS] is
   often provided at the operating system layer, [SASL] is often
   provided at the application layer, and XMPP is the application
   itself.

14.6.  Lack of SASL Channel Binding to TLS

   The SASL framework does not provide a mechanism to bind SASL
   authentication to a security layer providing confidentiality and
   integrity protection that was negotiated at a lower layer.  This lack
   of a "channel binding" prevents SASL from being able to verify that
   the source and destination end points to which the lower layer's
   security is bound are equivalent to the end points that SASL is
   authenticating.  If the end points are not identical, the lower
   layer's security cannot be trusted to protect data transmitted
   between the SASL authenticated entities.  In such a situation, a SASL
   security layer should be negotiated that effectively ignores the
   presence of the lower layer security.

14.7.  Mandatory-to-Implement Technologies

   At a minimum, all implementations MUST support the following
   mechanisms:

   for authentication: the SASL [DIGEST-MD5] mechanism

   for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
      cipher)

   for both: TLS plus SASL EXTERNAL(using the
      TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
      certificates)



Saint-Andre, Ed.            Standards Track                    [Page 67]

RFC 3920                       XMPP Core                    October 2004


14.8.  Firewalls

   Communications using XMPP normally occur over [TCP] connections on
   port 5222 (client-to-server) or port 5269 (server-to-server), as
   registered with the IANA (see IANA Considerations (Section 15)).  Use
   of these well-known ports allows administrators to easily enable or
   disable XMPP activity through existing and commonly-deployed
   firewalls.

14.9.  Use of base64 in SASL

   Both the client and the server MUST verify any [BASE64] data received
   during SASL negotiation.  An implementation MUST reject (not ignore)
   any characters that are not explicitly allowed by the base64
   alphabet; this helps to guard against creation of a covert channel
   that could be used to "leak" information.  An implementation MUST NOT
   break on invalid input and MUST reject any sequence of base64
   characters containing the pad ('=') character if that character is
   included as something other than the last character of the data
   (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer
   overflow attacks and other attacks on the implementation.  Base 64
   encoding visually hides otherwise easily recognized information, such
   as passwords, but does not provide any computational confidentiality.
   Base 64 encoding MUST follow the definition in Section 3 of RFC 3548
   [BASE64].

14.10.  Stringprep Profiles

   XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for the
   processing of domain identifiers; for security considerations related
   to Nameprep, refer to the appropriate section of [NAMEPREP].

   In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep
   (Appendix A) for node identifiers and Resourceprep (Appendix B) for
   resource identifiers.

   The Unicode and ISO/IEC 10646 repertoires have many characters that
   look similar.  In many cases, users of security protocols might do
   visual matching, such as when comparing the names of trusted third
   parties.  Because it is impossible to map similar-looking characters
   without a great deal of context, such as knowing the fonts used,
   stringprep does nothing to map similar-looking characters together,
   nor to prohibit some characters because they look like others.

   A node identifier can be employed as one part of an entity's address
   in XMPP.  One common usage is as the username of an instant messaging
   user; another is as the name of a multi-user chat room; many other
   kinds of entities could use node identifiers as part of their