Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
Peter Saint-Andre <stpeter@stpeter.im> Fri, 29 October 2010 18:30 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 4B7793A6A4E; Fri, 29 Oct 2010 11:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level:
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 0oGs961vXcsF; Fri, 29 Oct 2010 11:30:28 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 72E713A6A43; Fri, 29 Oct 2010 11:30:28 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1523140BB9; Fri, 29 Oct 2010 12:40:36 -0600 (MDT)
Message-ID: <4CCB1334.3030203@stpeter.im>
Date: Fri, 29 Oct 2010 12:32:20 -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>
In-Reply-To: <4CC9503D.2000809@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="------------ms020301030306050504050409"
X-Mailman-Approved-At: Mon, 01 Nov 2010 08:18:58 -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: Fri, 29 Oct 2010 18:30:33 -0000
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. :) > - 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? > - 5.4.1: don't you have to declare version >= 1.0 if you simply support > this draft? Same question in 6.4.1. Yes. The mentions in 5.4.1 and 6.4.1 are artifacts of RFC 3920, when the 'version' attribute was new. I've removed those clauses in both sections. > - 5.4.3.1: why is the initiator required to present a certificate "So > that mutual authentication will be possible"? There are many other ways > of ensuring mutual auth. I suggest to reword as "mutual certificate > authentication". Done. > - Global replace TLS "cipher" -> "ciphersuite". Done. > - 5.4.3.1, bullet 5: actually, based on the "from" attribute that the > receiving entity has just sent. You refer to this text: 5. The receiving entity SHOULD choose which certificate to present based on the 'to' attribute of the initial stream header. I'm not quite sure about your recommendation. Practically speaking I think it doesn't make a difference, because the two will be the same unless the receiving entity does not service the domainpart specified by the initiating entity (in which case the parties won't end up negotiating TLS anyway, since the receiving entity will close the stream). However, the 'to' address of the initial stream header seems like a "purer" indication of the initiating entity's "reference identifier" (in the language of [TLS-CERTS]). > - 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? 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? > - 6.3.2: do you restart the stream twice, once after TLS and once after > SASL?? Yes. We defined it that way in RFC 3920 because it was our understanding of TLS and SASL that we needed to flush the previous security context in both cases because either one of those technologies might result in negotiation of a security layer. If we were defining things anew at this point, we would probably remove the stream restarts, but I think it's probably too late to do that now. (Perhaps that will be part of our work on "quick reconnect" or streamlined stream negotiation.) > - 6.3.3: shouldn't we simply "MUST NOT" the PLAIN mechanism? Yes. Done. > - 6.3.7: and what is the identity used for server-to-server auth? Also, > it is very uncommon to consider the password as part of the identity. I think we acquired this notion from a misreading of RFC 4422. Looking at that specification again, I see that it refers to "credentials" as consisting (in some SASL mechanisms) of a simple username / password, whereas the authentication identity would be the simple username. I propose modifying the offending paragraph as follows: Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify that the authentication identity used in the context of such mechanisms is a "simple user name" (see Section 2 of [SASL] as well as [SASLPREP]). The exact form of the simple user name in any particular mechanism or deployment thereof is a local matter, and a simple user name does not necessarily map to an application identifier such as a JID or JID component (e.g., a localpart). However, in the absence of local information provided by the server, an XMPP client SHOULD assume that the authentication identity for such a SASL mechanism is a simple user name equal to the localpart of the user's JID. > - 6.4.4: isn't it inconsistent that SASL aborts are converted into XMPP > failures, but TLS failures are not? I don't think so. TLS is a layer unto itself, and the STARTTLS feature in XMPP is merely a way of triggering the underlying TLS negotiation (we don't represent all the TLS bits in XMPP syntax). By contrast, there is no special SASL layer to invoke, so all of the protocol bits to negotiate SASL happen using XMPP syntax. > - 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. > - 8.1.1.2: any validated domain -> any validated subdomain. We've gone through some effort to scrub the term "subdomain" from the spec (you'll notice it was used more frequently in RFC 3920) because of ambiguities surrounding that term. This is connected to the common XMPP practice of server-side components that offer services in addition to or on top of the core XMPP router. Consider an XMPP service whose canonical DNS domain name is "im.example.com"; that service might offer add-on services such as groupchat rooms (say, "rooms.example.com") and publish-subscribe (say, "pubsub.example.com"). Nothing says that such add-on services need to be subdomains of the canonical DNS domain name for the service, but RFC 3920 implied such a necessity, leading to confusion among server developers and service administrators. > - 8.3.1, rule #2: if the error is a result of something gone bad with > the addresses, then simply swapping "to" and "from" may not be > appropriate, and may even be a security issue. I suppose that is possible. I propose modifying the rule as follows: 2. The error stanza SHOULD simply swap the 'from' and 'to' addresses from the generated stanza, unless doing so would result in an information leak (see under Section 13.10) or other breach of security. > - Same, rule #6, the recipient MUST NOT include the original XML if it's > not well formed, right? True. Or if it is otherwise harmful. I propose modifying the rule as follows: 6. The entity that returns an error stanza MAY include the original XML sent so that the sender can inspect and, if necessary, correct the XML before attempting to resend (however, this is a courtesy only and the originating entity MUST NOT depend on receiving the original payload); naturally, the entity MUST NOT include the original data if it not well-formed XML, violates the XML restrictions of XMPP (see under Section 11.1, or is otherwise harmful (e.g, exceeds a size limit). > - 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). > - 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? > - 8.3.3.14: the "security note" doesn't makes sense to me - no matter > what error code is returned, the sender has gained information that we > don't want to provide. The note should say something along the lines of: > such services must not be available to entities that cannot be trusted > with knowing the status of an arbitrary recipient. See also 8.3.3.20. It's not necessarily true that the sender has gained information that we don't want to provide. In RFC 3920 (and 3920bis), we have the concept of presence subscriptions. If the sender is authorized to know the recipient's network availability (via presence subscription), then it is perfectly legitimate for the recipient's server to tell the sender that the recipient is now offline. Perhaps a reference to 3920bis would clear this up. I propose modifying the note as follows: Security Note: An application MUST NOT return this error if doing so would provide information about the intended recipient's network availability to an entity that is not authorized to know such information (for details, refer to the discussion of presence subscriptions in [XMPP-IM]); instead it MUST return a <service- unavailable/> stanza error. > - 8.3.3.15: Are there no security implications to redirection at the > stanza level? Good point, there certainly might be. If the sender is attempting to join a chatroom at rooms.example.com and the service redirects the request to conference.example.net, the client might want to ask the sender if the redirect is acceptable before proceeding (e.g., because the redirected service might have different security policies). I propose adding the following security note: Security Note: An application receiving a stanza-level redirect SHOULD warn a human user of the redirection attempt and request approval before proceeding to communicated with the entity whose URI or IRI is contained in the XML character data of the <redirect/> element, because that entity might have a different identity or might enforce different security policies. However, the end-to-end authentication or signing of XMPP stanzas could help to mitigate this risk, since it would enable the sender to determine if the entity to which it has been redirected has the same identity as the entity it originally attempted to contact. > - 8.3.3.18: The "wait" error type might not be appropriate for some > situations, e.g. authentication issues. True. I propose changing it to: A remote server or service specified as part or all of the JID of the intended recipient (or needed to fulfill a request) was resolved but communications could not be established within a reasonable amount of time (e.g., an XML stream cannot be established at the resolved IP address and port, or an XML stream can be established but stream negotiation fails because of problems with TLS, SASL, Server Dialback, etc.); the associated error type SHOULD be "wait" (unless the error is of a more permanent nature, e.g., the remote server is found but it cannot be authenticated or it violates security policies). > - 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. > - 9.1.1, step 7: this is utterly trivial, but please mention that the > new "stream" element is sent over TLS. Changed to: Step 7: If TLS negotiation is successful, client initiates a new stream to server over the TLS-protected TCP connection: (also changed in 9.2.1) > - 9.1.5: as I noted in Sec. 4.4, the TLS connection needs to be closed > as well. Changed in my working copy to: The client now sends a TLS close_notify alert, receives a responding close_notify alert from the server, and then terminates the underlying TCP connection. (also in 9.2.5 with "Server1" and "Server2") ### END OF PART 2 ###
- [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