From 411f0cff8809ecd7dc777040b58c14b5e130a5a7 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 22 Dec 2006 16:25:33 +0000 Subject: [PATCH] 0.9 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@297 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0174.xml | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/xep-0174.xml b/xep-0174.xml index 95258b03..33154f9c 100644 --- a/xep-0174.xml +++ b/xep-0174.xml @@ -25,6 +25,12 @@ N/A &stpeter; + + 0.9 + 2006-12-22 + psa +

Updated the security considerations to recommend either TLS+SASL at the stream layer or encrypted sessions at the messaging layer.

 + 0.8 2006-07-31 @@ -239,15 +245,7 @@ psa IN TXT "vc=CA!" ]]> -

The exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. Subject to client configuration and local service policies, two entities MAY accept such a channel. However, it is RECOMMENDED to use Transport Layer Security (TLS) for channel encryption (see &rfc4346;) and the Simple Authentication and Security Layer (SASL) for authentication (see &rfc4422;), in a manner essentially the same as that defined in RFC 3920. If the initiating party wishes to TLS and SASL, it MUST include a 'version' attribute with a value of "1.0" in the stream header it sends:

- - ]]> -

If the receiving entity supports TLS and SASL for stream security, it MUST also include the 'version' attribute:

- - ]]> -

The parties then can complete TLS and SASL negotiation (including stream feature advertisement) as specified in RFC 3920. A future version of this specification may include more detailed examples showing the relevant protocol flows. Handling of the 'version' attribute (or lack thereof) MUST follow the rules specified in RFC 3920.

+

The exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. See the Security Considerations section of this document regarding methods for authenticating and encrypting the stream.

Once the streams are established, either entity then can send XMPP message or IQ stanzas by specifying 'to' and 'from' addresses using the logical local addresses: The "JIDs" MUST be of the form "username@machine-name" as discovered via SRV (this is the <Instance> portion of the Service Instance Name).

@@ -291,9 +289,21 @@ _presence._tcp.local. IN NULL raw-binary-data-here

Although RFC 1464 does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of DNS-Based Service Discovery mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in DNS-Based Service Discovery.

 -

XMPP networks depend on TLS (&rfc2246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for validation of server hostnames; these technologies help to ensure the identity of sending entities. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, zero-configuration networking does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between local entities. (TLS could be negotiated on the local streams, but is out of scope for this specification.)

-

Because of fundamental differences between a true XMPP network and a localized XMPP client "mesh", local entities MUST NOT attempt to inject local traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated. However, a client on a local mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a local client mesh to a contact on an XMPP network).

-

The TXT records optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).

+ +

XMPP networks use TLS (&rfc2246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, link-local messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between local entities.

+

There are two potential solutions to this problem:

+
    +
  1. Negotiate the use of TLS and SASL for the XML stream as described in RFC 3920.
    2. +
  2. Negotiate encryption with identity checking for the message exchange using &xep0116;.
    3. +
+

It is RECOMMENDED to use one of these methods to secure communications between local entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client MUST warn the human user that the channel is unauthenticated and unencrypted.

+ + +

Because of fundamental differences between a true XMPP network and a localized XMPP client "mesh", local entities MUST NOT attempt to inject local traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in RFC 3920. However, a client on a local mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a local client mesh to a contact on an XMPP network).

+ + +

The TXT records optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).

+

The p2pj port number 5298 is not included in the &ianaports; maintained by &IANA;. The author will investigate whether that port number (or some other port number) needs to be registered.