Re: [secdir] [xmpp] SECDIR review of draft-ietf-xmpp-3921bis-15.txt
Peter Saint-Andre <stpeter@stpeter.im> Tue, 26 October 2010 16:58 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 40BA93A698F; Tue, 26 Oct 2010 09:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level:
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 BPZnqZGn110I; Tue, 26 Oct 2010 09:57:58 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6A8BF3A6939; Tue, 26 Oct 2010 09:57:58 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9CEAE40D1E; Tue, 26 Oct 2010 11:07:43 -0600 (MDT)
Message-ID: <4CC708FF.5070801@stpeter.im>
Date: Tue, 26 Oct 2010 10:59:43 -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: <4CC63813.5070101@bbn.com> <4CC654A1.7020502@stpeter.im>
In-Reply-To: <4CC654A1.7020502@stpeter.im>
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="------------ms060108050408090502020002"
X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700
Cc: draft-ietf-xmpp-3921bis@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] [xmpp] SECDIR review of draft-ietf-xmpp-3921bis-15.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 16:58:00 -0000
On 10/25/10 10:10 PM, Peter Saint-Andre wrote: > Thanks for the review. One comment inline. > > 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 an instant-messaging and presence system based >> on the core system of exchanging XML stanzas described in RFC 3920 and >> draft-ietf-xmpp-3920bis. As the document rightly notes, the underlying >> transport protocol addresses most of the security considerations for >> this document, and that document seems to have a thorough discussion of >> security considerations (although I have not done a thorough review). In >> general, I think that the security considerations in this document >> adequately describe the additional risks posed by the instant-messaging- >> and presence-specific parts of the protocol (beyond those of the base >> protocol), and corresponding mitigations. >> >> One thing that might merit clarification: The overriding >> application-layer security concern here is the proper routing of >> presence and instant messaging stanzas through the XMPP system. >> (Underlying communications security concerns are addressed by the core >> spec.) For the most part, these concerns with requirements on servers >> to act in certain ways on behalf of the user. It could be helpful to >> the reader to re-state some of the communications patterns from Section >> 13.1 of draft-ietf-xmpp-3920bis and comment on the particular roles that >> the entities play in the context of instant messaging and presence >> (e.g., routing unicast <message> stanzas, fan-out of broadcast presence >> messages). > > Although in general I'm not a fan of repeating material that is already > covered by a referenced specification, I agree that it might be > appropriate to provide a reminder about the underlying architecture of > XMPP and its implications for the security of various IM-related and > presence-related interactions. I'll reply again once I have investigated > the best location for such a reminder and have formulated proposed text. Does the following text (to be added to the Security Considerations section of 3920bis) address your concern? ### Section 13.1 of [XMPP-CORE] outlines the architectural roles of clients and servers in typical deployments of XMPP, and discusses the security properties associated with those roles. These roles have an impact on the security of instant messages, presence subscriptons, and presence notifications as described in this document. In essence, an XMPP user registers (or has provisioned) an account on an XMPP server and therefore places some level of trust in the server to complete various tasks on the user's behalf, enforce security policies, etc. Thus it is the server's responsibility to: 1. Preferably mandate the use of channel encryption for communication with local clients and remote servers. 2. Authenticate any client that wishes to access the user's account. 3. Process XML stanzas to and from clients that have authenticated as the user (specifically with regard to instant messaging and presence functionality, store the user's roster, process inbound and outbound subscription requests and responses, generate and handle presence probes, broadcast outbound presence notifications, route outbound messages, and deliver inbound messages and presence notifications). As discussed in Sections 13.1 and 13.4 of [XMPP-CORE], even if the server fulfills the foregoing responsibilities, the client does not have any assurance that stanzas it might exchange with other clients (whether on the same server or a remote server) are protected for all hops along the XMPP communication path, or within the server itself. It is the responsibility of the client to use an appropriate technology for encryption and signing of XML stanzas if it wishes to ensure end-to-end confidentiality and integrity of its communications. ### Peter -- Peter Saint-Andre https://stpeter.im/
- [secdir] SECDIR review of draft-ietf-xmpp-3921bis… Richard L. Barnes
- Re: [secdir] SECDIR review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SECDIR review of draft-ietf-x… Peter Saint-Andre