[secdir] SECDIR review of draft-ietf-xmpp-address-05.txt
"Richard L. Barnes" <rbarnes@bbn.com> Tue, 26 October 2010 02:06 UTC
Return-Path: <rbarnes@bbn.com>
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 E8E353A67D6; Mon, 25 Oct 2010 19:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.557
X-Spam-Level:
X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 X5iyipUrJajo; Mon, 25 Oct 2010 19:06:33 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id ACEFA3A68A8; Mon, 25 Oct 2010 19:06:33 -0700 (PDT)
Received: from [128.89.253.84] (port=50299 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1PAYxX-0003Nx-5w; Mon, 25 Oct 2010 22:08:19 -0400
Message-ID: <4CC63810.2030809@bbn.com>
Date: Mon, 25 Oct 2010 22:08:16 -0400
From: "Richard L. Barnes" <rbarnes@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-xmpp-address@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [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 02:06:35 -0000
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, 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.) 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. 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. 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. S2.2 P3: Not clear why this is a "Note:" paragraph, especially since it has "MUST" requirements in it.
- [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