Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 02 November 2010 10:47 UTC
Return-Path: <yaronf.ietf@gmail.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 771C33A69A9; Tue, 2 Nov 2010 03:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.466
X-Spam-Level:
X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[AWL=2.133, 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 h30cjpl9xg4g; Tue, 2 Nov 2010 03:47:40 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EFCB83A68DC; Tue, 2 Nov 2010 03:47:39 -0700 (PDT)
Received: by wwe15 with SMTP id 15so6788760wwe.13 for <multiple recipients>; Tue, 02 Nov 2010 03:47:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9kv7wkFbrYHpNf8LVKtMi3yf0nsIf3zEWaCts/+wS08=; b=ZoYXn33rfKr7djN/znkerF7j9UsYIWdF5cpz0wDdxl5eAiQY8uAzfyYJCqUkgvChs6 KexeQYxMmBBevVFociYtRpUxZhVwH8GZ6eyPpSTGEcRqDTos2aClONVqVU6Hmjhn0Y0d XUOzHzgzw+3YbtiNOAkcSI7Se5/xbT7owdKIY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wpkzNNzeTcvsEy0wDSd6qHY6Xyt528Wmpf05sxLT0u1V3M6m3JCwafFVCtaZ1mvRj4 UbOmY/iW+tvtH4IFzJiF6/udUsTcOKT3R6onebCXTqsQxg6lXwtTg7h/JsWhhkU/v0V0 0oxQXV8k3ljlYd9a4wQI8FBSkxET26omlj4KI=
Received: by 10.227.144.13 with SMTP id x13mr16694879wbu.213.1288694862877; Tue, 02 Nov 2010 03:47:42 -0700 (PDT)
Received: from [10.0.0.2] (bzq-79-181-26-165.red.bezeqint.net [79.181.26.165]) by mx.google.com with ESMTPS id b30sm6179355wbb.4.2010.11.02.03.47.37 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 03:47:39 -0700 (PDT)
Message-ID: <4CCFEC48.7000808@gmail.com>
Date: Tue, 02 Nov 2010 12:47:36 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4CC9503D.2000809@gmail.com> <4CCB1334.3030203@stpeter.im> <4CCD8D2B.50900@gmail.com> <4CCF12B2.3050902@stpeter.im>
In-Reply-To: <4CCF12B2.3050902@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
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, 02 Nov 2010 10:47:42 -0000
Hi Peter, I'm OK with all your changes below. Thanks, Yaron On 11/01/2010 09:19 PM, Peter Saint-Andre wrote: > On 10/31/10 9:37 AM, Yaron Sheffer wrote: > > > > On 10/29/2010 08:32 PM, Peter Saint-Andre wrote: > >> This is Part 2 of my reply, from the start of Section 5 through the end > >> of Section 9. I should be able to address the remainder (Section 10 > >> through Section 15) in Part 3. > >> > >> On 10/28/10 4:28 AM, Yaron Sheffer wrote: > >> > >>> - 5.3.5: the text mentions that client certificates are "sufficiently > >>> rare", which is a pity because they do make sense for server-to-server > >>> interaction. So I suggest to promote renegotiation from OPTIONAL to > >>> RECOMMENDED. > >> > >> A bit of background: by client certificates we mean end-user > >> certificates (XMPP client, not TLS client). PKIX certificates are more > >> common for XMPP servers, but unfortunately they are still far from > >> ubiquitous. The XMPP Standards Foundation even ran an intermediate CA > >> for a few years (under the StartCom root) to help seed the network, > >> which helped us work out bugs in many codebases but still didn't result > >> in wide adoption. Many service admins still think that PKI is "too > hard" > >> or "too expensive" (despite the fact that our ICA gave out free > >> certificates, and StartCom continues to do so). > >> > >> The XMPP WG had a discussion about TLS renegotiation, starting here: > >> > >> http://www.ietf.org/mail-archive/web/xmpp/current/msg01146.html > >> > >> At one point we banned TLS renegotiation entirely, then we weighed the > >> benefits and the costs (including code complexity) and concluded > that it > >> was appropriate to make support strictly optional in XMPP, given how > >> rarely it would be needed. Simon Josefsson suggested during the WG > >> discussion that we document our reasons, which we've done in Section > >> 5.3.5. If you do not find those reasons compelling, the WG needs to > >> either explain itself more clearly or realize that it is wrong. :) > >> > > I accept your reasoning. And servers in most cases can take the risk of > > information disclosure and still use mutual cert authentication. > > One clarification.... In the case of a client-to-server ("c2s") > connection, it's the client that might leak its credentials to an > unauthenticated server at the TLS negotiation stage, so IMHO it's not > quite right to say that the server takes the risk of information > disclosure. In the server-to-server ("s2s") case, the initiating server > might leak its credentials. I don't think we're worried about the s2s > case, because the initiating server is the one that's asking to > "federate" the two domains in the first place. For the c2s case, so far > end-user certificates are rare enough that I think the sense of the WG > was to not make renegotiation a SHOULD. There are some deployment > scenarios in which end-user certificates are more common (think certain > military or financial organizations), but in general those deployments > might lock down the allowable clients and will probably deal with the > issue at the level of local service policy or a deployment profile > (i.e., both the client and the server must support TLS renegotiation), > so in that sense the risk of information disclosure is indeed accepted > by the application service provider or the organization in which such a > closed deployment occurs. However, those are specialized deployments and > we didn't see a need for TLS renegotiation in the general case. > > >>> - 5.3.6: extensions may be out of scope. But I think we need to > include > >>> a few words re: the TLS version, at least to prohibit SSL 3.0. > >> > >> In fact, discussions within the XMPP WG are what led to this: > >> > >> https://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/ > >> > >> However, it seems there is not yet consensus to prohibit SSL 3.0 in the > >> TLS WG. Are you suggesting that the XMPP WG go where the TLS WG has not > >> gone? > > > > I was assuming that XMPP has less legacy baggage than HTTP (i.e. > > browsers) and therefore prohibiting SSLv3 would be reasonable. If it > > isn't, forget it. > > XMPP as an application protocol does have less baggage, but it uses all > the same TLS libraries and those tend to be driven by HTTP, so I don't > know if we can really push the envelope here, unfortunately. > > >>> - 5.4.3.3: where do we say that both sides must validate the "to" and > >>> "from" identities in view of the identities presented at the TLS layer > >>> (if any)? > >> > >> Section 13.7.2 ("Certificate Validation"). There is a forward reference > >> in bullet 4 of Section 5.4.3.3: > >> > >> 4. The initiating entity MUST validate the certificate to > determine > >> if the TLS negotiation will succeed; see Section 13.7.2 > regarding > >> certificate validation procedures. > >> > >> Perhaps it would be easier to read if we switched bullets 4 and 5 in > >> that section? > > > > Yes, it makes sense to switch #4 and #5. > > Done in my working copy. > > > BTW, you meant 5.4.3.1. > > Yep, sorry. > > >> Also, the bullet about validation probably also needs to say that > if the > >> initiating entity presents a certificate then the receiving entity > needs > >> to also perform validation. Do you agree? > > > > Yes, this is the basic case, of course it should be mentioned. > > In my working copy the text now reads as follows (order changed, text > tweaked, bullet added)... > > 4. The receiving entity SHOULD choose which certificate to present > based on the 'to' attribute of the initial stream header. > > 5. To determine if the TLS negotiation will succeed, the initiating > entity MUST attempt to validate the receiving entity's > certificate in accordance with the certificate validation > procedures specified under Section 13.7.2. > > 6. If the initiating entity presents a certificate, the receiving > entity too MUST attempt to validate the initiating entity's > certificate in accordance with the certificate validation > procedures specified under Section 13.7.2. > > >>> - 7.7.2.2: the preferred option #1, while reasonable in itself, > does not > >>> allow the client to determine its own policy (whether it wants > multiple > >>> sessions from multiple devices or not). > >> > >> If the client wants multiple sessions from multiple devices, it can > >> generate a unique resourcepart for each device or ask the server to do > >> so on its behalf. > >> > > But if the client prefers the old behavior (newest resource wins), it > > cannot have it. Anyway, I'm sure you have debated this point to death. > > It's true that some legacy clients used the old behavior to kick the > existing resource, but we have better ways to do that now and the costs > outweighed the benefits (user complaints about not being able to stay > logged in, etc.). So yes it's been debated. :) > > >>> - 8.3.2: MUST NOT... be presented to the human user - this is > impossible > >>> to enforce, and most likely will not be followed. Moreover, there's a > >>> reason why we include a language tag. I suggest to tone it down a bit. > >> > >> I suppose SHOULD NOT is fine. The error message shown to the user is > >> supposed to be based on the defined condition, not some random text > >> placed in the<text/> element (even if language-tagged). > > > > Yes, SHOULD NOT would be BETTER... > > Done. > > >>> - 8.3.3.11: what are "improper credentials"? It sounds like we are not > >>> differentiating the conditions of authentication failure vs. > >>> authorization failure. > >> > >> As an example, if a client attempts to join a password-protected > >> chatroom without providing a password, the chatroom service will return > >> a<not-authorized/> stanza error. It will return the same error if the > >> client attempts to join a password-protected chatroom but provides the > >> wrong password. Is there a need to differentiate between these two > cases? > >> > > What triggered my comment was the name of this element, "not > > authorized". > > We inherited that from HTTP 401 "Unauthorized". > > > Both of your examples are (broadly speaking), "not > > authenticated". What about the same service, where I am duly > > authenticated as Yaron, but still am not allowed to use the service, > > e.g. because only users belonging to the all-saints group are allowed to > > it. This would be a true authorization failure. > > Sure. Sticking with the example of multi-user chat rooms, a room admin > has privileges to perform certain actions (say, kick people out of the > room); if a non-privileged user attempts to perform such an action, the > service will return a<forbidden/> error. Perhaps we don't have a very > sophisticated authorization model in XMPP, but we've not yet found the > need for error conditions that are strictly limited to authorization. > > >>> - 8.3.3.21: do you explain anywhere what is the difference between > >>> "prior registration" and "prior subscription"? > >> > >> That's really an issue for various XMPP applications. One such > >> application is IM and presence (3920bis), where we have the concept of > >> subscriptions. Another application in which we have subscriptions is > >> publish-subscribe<http://xmpp.org/extensions/xep-0060.html>. An example > >> of registration can be found in the multi-user chat extension > >> <http://xmpp.org/extensions/xep-0045.html> or in the older "gateway" > >> that we used to maintain for connecting to legacy IM services. I don't > >> see much reason to describe all those differences in 3920bis, but > we can > >> add a sentence or two about it if that would be helpful. > >> > > I would appreciate a pointer to benefit the uninitiated. > > Adjusted text: > > ### > > 8.3.3.16. registration-required > > The requesting entity is not authorized to access the requested > service because prior registration is necessary (examples of prior > registration include members-only rooms in XMPP multi-user chat > [XEP-0045] and gateways to non-XMPP instant messaging services, which > traditionally required registration in order to use the gateway > [XEP-0100]); the associated error type SHOULD be "auth". > > ### > > 8.3.3.21. subscription-required > > The requesting entity is not authorized to access the requested > service because a prior subscription is necessary (examples of prior > subscription include authorization to receive presence information as > defined in [XMPP-IM] and opt-in data feeds for XMPP publish-subscribe > as defined in [XEP-0060]); the associated error type SHOULD be > "auth". > > ### > > Better? > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > >
- [secdir] SecDir review of draft-ietf-xmpp-3920bis… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Florian Zeitz
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Jeffrey Hutzelman
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Matthew Wild
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Philipp Hancke
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre