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