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/