Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17

Peter Saint-Andre <stpeter@stpeter.im> Mon, 01 November 2010 19:19 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 1845128C111; Mon, 1 Nov 2010 12:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.999
X-Spam-Level:
X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 TAdhu6NjIiqb; Mon, 1 Nov 2010 12:19:19 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0AFAF28C119; Mon, 1 Nov 2010 12:19:15 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A63AB40D1E; Mon, 1 Nov 2010 13:27:47 -0600 (MDT)
Message-ID: <4CCF12B2.3050902@stpeter.im>
Date: Mon, 01 Nov 2010 13:19:14 -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.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <4CC9503D.2000809@gmail.com> <4CCB1334.3030203@stpeter.im> <4CCD8D2B.50900@gmail.com>
In-Reply-To: <4CCD8D2B.50900@gmail.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="------------ms050608020209070706030105"
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
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: Mon, 01 Nov 2010 19:19:21 -0000

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/