Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.txt
Peter Saint-Andre <stpeter@stpeter.im> Tue, 26 October 2010 21:09 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538FD3A68FD; Tue, 26 Oct 2010 14:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.595
X-Spam-Level:
X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQPqRYgdfK4O; Tue, 26 Oct 2010 14:09:25 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 06CA83A6804; Tue, 26 Oct 2010 14:09:25 -0700 (PDT)
Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 69D2A40D1E; Tue, 26 Oct 2010 15:19:11 -0600 (MDT)
Message-ID: <4CC743EE.6090703@stpeter.im>
Date: Tue, 26 Oct 2010 15:11:10 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "Richard L. Barnes" <rbarnes@bbn.com>
References: <4CC63810.2030809@bbn.com>
In-Reply-To: <4CC63810.2030809@bbn.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms000706070402090606080209"
X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700
Cc: draft-ietf-xmpp-address@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Oct 2010 21:09:27 -0000
[Copying xmpp@ietf.org to keep the WG in the loop...] Thanks for the review. Please be aware that you reviewed draft-ietf-xmpp-address-05, but based on further discussion in the XMPP WG we published -06 right before the October 25 cutoff, and I think -06 includes text that might address some of your concerns (details below). A diff is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-xmpp-address-06.txt On 10/25/10 8:08 PM, Richard L. Barnes wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This document describes a data structure for addressing XMPP resources. > As such, it has the potential to create authentication issues, in > particular related to spoofing and mimicry of addresses. The document > does a good job of describing these risks and available mitigations, but > could use a little bit of clarification on a few points. > > Detailed comments follow. > > --Richard > > > > > Major issues: > > General: It's not clear to me from the text in this document JIDs differ > from XMPP URIs. My naïve assumption would be that an XMPP URI would > simply be a JID with the scheme "xmpp:" prepended, Correct. There are complexities involved when the JID contains characters outside the ASCII range, which is why RFC 5122 says to convert the URI to an IRI before extracting the JID. > but the last > paragraph of Section 2.1 made me uncertain about this. (I have not > checked RFC 5122 to verify whether this is the case syntactically.) Is this revised text clearer? For the purpose of communication over an XMPP network (e.g., in the 'to' or 'from' address of an XMPP stanza), an entity's address MUST be represented as a JID, not as a Uniform Resource Identifier [URI] or Internationalized Resource Identifier [IRI]. An XMPP URI or IRI [XMPP-URI] is in essence a JID prepended with 'xmpp:', but the native addressing format used in XMPP is that of a mere JID without a URI scheme. ([XMPP-URI] is provided only for identification and interaction outside the context of XMPP itself, for example when linking to a JID from a web page.) > Since many client applications will have to convert from XMPP URIs to > JIDs -- and because this is a security-sensitive operation -- it seems > like it would be helpful for this document to specify conversions > between XMPP URIs and JIDs, even if only by reference to RFC 5122. I agree that we need to somewhere describe how a JID can be securely extracted from an XMPP URI, and I think RFC 5122 handles that fairly well at the moment. If the matter is not clear in RFC 5122, then it needs to be clarified in 5122bis -- RFC 5122 will be revised anyway once we supersede the address spec you've reviewed, once 3987bis is published, etc. Because this (temporary) address spec mentions XMPP URIs/IRIs only to say that they are explicitly out of scope for XMPP itself and must not be used as the address format for communication over an XMPP network, I think it's not proper to introduce dependencies on RFC 5122 in the core specification. However, we might want to add the following sentence at the end of the revised paragraph quoted above: See [XMPP-URI] for a description of the process for securely extracting a JID from an XMPP URI or IRI. > S4.3: > It seems like there should be some discussion here about how entities > that create JIDs can help mitigate issues of confusability. For > example, the existence of confusable characters in the domainpart is > mitigated by proper registry policies (which I presume could be > incorporated by reference to some IDNA documents). Localparts and > resourceparts are not constrained to be domain names, but they are > controlled or at least approved by a server, so the server can apply > similar policies to these parts. The XMPP community is just beginning to get a handle on these issues. I agree that an XMPP server functions as a registry of sorts: a registry of localparts associated with accounts. See for instance the last paragraph here: http://tools.ietf.org/html/draft-saintandre-xmpp-i18n-02#section-2 Similarly, an XMPP groupchat service functions as kind of registry for temporary resourceparts, and in some cases even permanent resourceparts: http://xmpp.org/extensions/xep-0045.html#register With the understanding that usernames can be provisioned and not registered directly by a user, I'll point out that the "in-band registration" protocol (XEP-0077) traditionally used for registration of an account at an XMPP server has included absolutely no support for registration *policies* (e.g., disallowing symbol characters in the localpart), because the XMPP community was blithely unaware of possible problems with the lack of such policies. This is something that needs to be remedied, but it has not been remedied yet. I'm hoping that work on the successor to the address spec you've reviewed will lead to at least some solutions to these problems, and the individual I-D that I mentioned above is an attempt at starting that conversation. That said, I think draft-ietf-xmpp-address-06 (you reviewed -05) includes some text that might address your concern, to wit: ### Despite the fact that some specific suggestions about identification and handling of confusable characters appear in the Unicode Security Considerations [UNICODE-SEC], it is also true (as noted in [IDNA-DEFS]) that "there are no comprehensive technical solutions to the problems of confusable characters". Mimicked JIDs that involve characters from only one script, or from the script typically employed by a particular user or community of language users, are not easy to combat (e.g., the simple typejacking attack previously described, which relies on a surface similarity between the characters "1" and "l" in some presentations). However, mimicked addresses that involve characters from more than one script, or from a script not typically employed by a particular user or community of language users, can be mitigated somewhat through the application of appropriate registration policies at XMPP services and presentation policies in XMPP client software. Therefore the following policies are encouraged: 1. Because an XMPP service that allows registration of XMPP user accounts (localparts) plays a role similar to that of a registry for DNS domain names, such a service SHOULD establish a policy about the scripts or blocks of characters it will allow in localparts at the service. Such a policy is likely to be informed by the languages and scripts that are used to write registered account names; in particular, to reduce confusion, the service MAY forbid registration of XMPP localparts that contain characters from more than one script and to restrict registrations to characters drawn from a very small number of scripts (e.g., scripts that are well-understood by the administrators of the service). For related considerations in the context of domain name registration, refer to Section 4.3 of [IDNA-PROTO] and Section 3.2 of [IDNA-RATIONALE]. Note well that methods for enforcing such restrictions are out of scope for this document. 2. Because every human user of an XMPP client presumably has a preferred language (or, in some cases, a small set of preferred languages), an XMPP client SHOULD gather that information either explicitly from the user or implicitly via the operating system of the user's device. Furthermore, because most languages are typically represented by a single script (or a small set of scripts) and most scripts are typically contained in one or more blocks of characters, an XMPP client SHOULD warn the user when presenting a JID that mixes characters from more than one script or block, or that uses characters outside the normal range of the user's preferred language(s). This recommendation is not intended to discourage communication across different communities of language users; instead, it recognizes the existence of such communities and encourages due caution when presenting unfamiliar scripts or characters to human users. ### Does that help? > S4.4.1 P2: > The observation that only part of an identifier can be authenticated is > a good one to make, but there's one subtlety: The remote server is > actually authoritative for the localpart and resourcepart of the JID, so > the fact that the remote domain has assigned a particular 'from' address > effectively authenticates those fields when the domain is authenticated. > It might help to note that end-to-end authentication of XMPP stanzas > could help mitigate this risk, since it would require the rogue server > to generate false credentials in addition to modifying 'from' addresses. > > > Minor issues: > > S2.2 P2: For clarity, I would change the "SHOULD be an FQDN, can be an > IP address or unqualified host name" to "MUST be an FQDN, IPv4 address > literal, IPv6 address literal, or unqualified host name". If the > intention here is that unqualified host names should have the same > syntax as FQDNs, then that should be stated. I take it you mean something like the following edited text: ### The domainpart for every XMPP service MUST be a fully qualified domain name ("FQDN"; see [DNS]), IPv4 address, IPv6 address, or unqualifed hostname (i.e., a text label that is resolvable on a local network). Interoperability Note: Domainparts that are IP addresses might not be accepted by other services for the sake of server-to-server communication, and domainparts that are unqualified hostnames cannot be used on public networks because they are resolvable only on a local network. ### Is that what you were looking for? > S2.2 P3: Not clear why this is a "Note:" paragraph, especially since it > has "MUST" requirements in it. I've removed the "Implementation Note:" string at the beginning of that paragraph. Thanks again for the review. Peter -- Peter Saint-Andre https://stpeter.im/
- [secdir] SECDIR review of draft-ietf-xmpp-address… Richard L. Barnes
- Re: [secdir] SECDIR review of draft-ietf-xmpp-add… Richard L. Barnes
- Re: [secdir] SECDIR review of draft-ietf-xmpp-add… Richard L. Barnes
- Re: [secdir] SECDIR review of draft-ietf-xmpp-add… Peter Saint-Andre
- Re: [secdir] SECDIR review of draft-ietf-xmpp-add… Peter Saint-Andre