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/
>
>
>