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

Peter Saint-Andre <> Sat, 30 October 2010 05:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5E043A681D; Fri, 29 Oct 2010 22:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4tHjQZkKBQv1; Fri, 29 Oct 2010 22:04:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AEAC63A67A5; Fri, 29 Oct 2010 22:04:00 -0700 (PDT)
Received: from squire.local ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 63C0840BB9; Fri, 29 Oct 2010 23:14:12 -0600 (MDT)
Message-ID: <>
Date: Fri, 29 Oct 2010 23:05:45 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Yaron Sheffer <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
OpenPGP: url=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms030901010109050600060007"
X-Mailman-Approved-At: Mon, 01 Nov 2010 08:18:58 -0700
Cc:,, XMPP <>,
Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 Oct 2010 05:04:03 -0000

This is Part 3 of my reply, from the start of Section 10 through the end
of Section 15. This completes my reply to Yaron's security review.

On 10/28/10 4:28 AM, Yaron Sheffer wrote:

> - 10.2: "try many different resources", I suppose it is typically fewer
> than 10 per JID, which does not make the attack uninteresting.

In my experience, few entities connect from more than three or four
devices at a time, although that might increase in the future. The use
of randomized resourceparts helps to mitigate the risk here (because an
attacker can't simply guess if the victim is at the "home" or "work"
resource or whatever) -- perhaps it would be good to mention that?

> - 10.4.2: if the protocol supports routing, shouldn't we mention that
> there are cases where the IQ stanza will be forwarded to another server,
> not the one mentioned in the "To" header? And what about loop prevention?

Could you clarify what you mean by "forward"? We don't have multi-hop
routing in XMPP, just direct server-to-server connections, so it's not
as if the stanza would be forwarded through multiple servers in order to
reach the destination domain.

> - this is a strange rule. Does it mean that if I'm using a
> desktop (/desktop) and a mobile (/mobile), and I'm connected to the
> desktop, I cannot have messages targeted at my mobile be deferred (and
> stored somewhere) until I connect from that device?

That feature is not part of XMPP.

> - 13.4: "for the ensuring" -> "for ensuring" (or: to ensure).


> - 13.4: the security note is confusing, because it is unclear whether it
> has any normative status. Otherwise, it is almost trivial: of course you
> can provide these guarantees by different means.

This security note provides truth in advertising: we don't want to
misrepresent the extent to which the use of TLS can protect stanzas,
since they can be routed or delivered outside the context of their
original stream. It does not use any normative keywords because it is
purely informative.

> - 13.4: the cipher suites are not just "nun-null". They MUST provide
> both confidentiality and integrity.

Is this more accurate?

   The use of Transport Layer Security (TLS) with appropriate
   ciphersuites provides a reliable mechanism to ensure the
   confidentiality and integrity of data exchanged between a client and
   a server or between two servers.

> - 13.6: the out-of-band trust chain rule may be practical for
> server-to-server connections, but probably not for large client
> deployments and when certificates are sometimes rolled over.

Do you think that we need to modify the text of that paragraph?

> - 13.7: terminology: "mutual authentication" describes authentication
> with client certs, just as much as it describes the server presenting a
> cert and the client authenticating with SASL. This also applies to 5.4.3.

In this context we have always used the term "authentication" only with
regard to SASL. The use of SASL EXTERNAL with PKIX certificates enables
an entity to point back to a certificate it provided during TLS
negotiation, but in general we don't refer to TLS as an authentication
mechanism. I don't see an easy way to disambiguate the term here, but
suggestions are welcome.

> - The word "issuer" is ambiguous. It usually refers to a
> person/organization, but here you use it to refer to the certificate
> itself. How about replacing the heading of the second list by: "the
> following rules apply to issuer certificates, used to sign XMPP
> end-entity certificates"?

I think the first and second headings are best phrased like this:

   The following rules apply to end entity public key certificates that
   are issued to XMPP servers or clients:


   The following rules apply to certification authority (CA)
   certificates that are used by issuers of XMPP end entity

That way we are using the appropriate terminology from RFC 5280.

> - it's strange to specify the hash algorithm, but not the
> signature algorithm (RSA-512 anyone?)

Ah, I got that text from Sean Turner (IIRC, we copied it from a
never-released version of draft-hildebrand-dna), and I'm pretty sure
that by "the hash algorithm for the signature" he meant the
signatureAlgorithm field from RFC 5280, as in this text from

   The issuer MUST support signing attribute certificate with the PKCS
   #1 version 1.5 signature algorithm with SHA-256, as specified in

Clearly something has been lost in translation. I'll check with Sean on
this point.

> - what are "access certificates"? Neither 5280 nor Google can
> help... 


> And how can an issuer cert NOT be marked with the CA bit?

The idea was that attribute certificates would be issued by non-CA
entities, such as organizations that wish to delegate an XMPP service to
a hosting provider. However, I think we should delete any mention of
attribute certificates because that was something we envisioned for use
in "domain name assertions" but the feature is far from well defined.
See here for more details:

Therefore I propose that we remove these lines (where "access" really
should be "attribute", not that it matters if we remove the bullet):

   6.  For issuers of access certificates, the issuer's certificate MUST
       NOT contain a basicConstraints extension with the cA boolean set
       to TRUE.

> - and most important, is the "relying party" (e.g. the client)
> required to check all these rules and fail validation if any of them is
> not met?

As I understand it from my conversations with Sean when we were adding
this text, these rules are not set in stone within RFC 5280 and
therefore need to be specified by any technology that reuses PKIX. Our
intent was that CAs would conform to these rules, not necessarily that
replying parties would necessarily fail on validation if the rules were
violated. Here again I'll check with Sean.

> - enabling entity -> enabling entities.
> - "conjuction" misspelled.

Typos fixed. Maybe it would be helpful for me to finally run this
document through a spell-checker...

> - 13.7.2: "An implementation MUST enable a human user to view
> information about the certification path." I'm afraid this is security
> theater, because 99.5% of your target population cannot understand this
> information.

Do you recommend changing SHOULD to MUST, removing this text entirely,
or something else?

I suppose that 0.5% could always view the path via a dedicated piece of
security software...

> - "MUST either validate" - incomplete sentence (and
> actually, at a sensitive point in the text).

Here "either" is extraneous because it is an artifact of an earlier
version of the spec. Much earlier:

> -, subcase #3: please mention that some servers will simply
> fail validation at this point, subject to their policy. I.e., some might
> insist on correct client certs.

True. Does the following proposed text capture that point?

   Sub-Case #3:  The server finds no XmppAddrs, or finds at least one
      XmppAddr but the domainpart of the represented JID does not match
      one of the configured hostnames of the server; the server MUST NOT
      use the represented JID (if any) as the validated identity of the
      client but instead MUST validate the identity of the client using
      other means.  If the identity cannot be so validated, depending on
      local service policy the server MAY abort the validation process
      and terminate the TLS negotiation.

> - "periodically query OCSP" - is there any guidance about the
> period? Is a recommended period specified in the cert or communicated by
> the OCSP responder?

I don't see a way to specify this in the certificate, but it seems
reasonable to query at or near the time communicated via the nextUpdate
field received in the OCSP response or, if the nextUpdate field is not
set, to query every 24 hours. This is for long-lived streams

> - 13.7.2: a silly question, but anyway: where do you say that the
> client's cert is correlated with the client's JID, as it appears in the
> From line (when setting up the original stream and/or when setting the
> stream anew after TLS negotiation)? 

Few clients include the 'from' address on the stream header and we're
not actively working to make sure they do, because what really matters
is that the client authenticates using the credentials of a registered

> And vice versa, for the server cert
> and the client's To header.

For s2s communication, in essence (and using the terms of [TLS-CERTS])
the initiating entity sets its reference identifier to the 'to' address
it communicates in the initial stream header, and the receiving entity
sets its reference identifier to the 'from' address communicated by the
initiating entity in the initial stream header (i.e., the 'from' address
is the identity that the initiating entity is trying to assert). Per
recent list discussion Jeff Hodges and I have added a note about that to
our working copy of draft-saintandre-tls-server-id-check.

However, I agree that it would be helpful to mention this in 3920bis, so
I propose that we add some text to Sections ("Server
Certificates") and ("Client Certificates")...

###  Server Certificates

   For server certificates, the rules and guidelines defined in
   [TLS-CERTS] apply, with the proviso that the XmppAddr identifier
   specified under Section is allowed as a reference

   The identities to be checked are set as follows:

   o  The initiating entity sets its reference identifier to the 'to'
      address it communicates in the initial stream header; i.e., this
      is the identity it expects the receiving entity to provide in a
      PKIX certificate.

   o  The receiving entity sets its reference identifier to the 'from'
      address communicated by the initiating entity in the initial
      stream header; i.e., this is the identity that the initiating
      entity is trying to assert.  Client Certificates

   When an XMPP server validates a certificate presented by a client,
   there are three possible cases, as discussed in the following

   The identities to be checked are set as follows:

   o  The client sets its reference identifier to the 'to' address it
      communicates in the initial stream header; i.e., this is the
      identity it expects the server to provide in a PKIX certificate.

   o  The server sets its reference identifier to the 'from' address
      communicated by the initiating entity in the initial stream
      header; i.e., this is the identity that the client is trying to


> - 13.8: I suggest to add (here or elsewhere): "All password-based
> mechanisms are susceptible to password guessing attacks, and therefore
> the authenticator MUST implement common rate-limiting mitigations."

I think the right place is Section 13.9.4 ("Use of SASL").


> - 13.8: "For both confidentiality and authentication with passwords" -
> here you don't specify a TLS ciphersuite.

RFC 5246 has TLS_RSA_WITH_AES_128_CBC_SHA as the mandatory-to-implement
ciphersuite, so that seems appropriate here. Would you recommend
something stronger, for example TLS_RSA_WITH_AES_256_CBC_SHA?

> - 13.8: the note kind of implies that PLAIN is preferable to DIGEST-MD5,
> which is clearly not the case.

Clearly not, and that was unintentional.

I think it is better to limit this note strictly to the interoperability
issue here (see also the next section)...

      Interoperability Note: The use of the SCRAM-SHA-1 or SASL-SCRAM-
      SHA-1-PLUS mechanism replaces the SASL DIGEST-MD5 mechanism as
      XMPP's mandatory-to-implement password-based method for
      authentication only, and the use of TLS plus either of those SCRAM
      variants replaces TLS plus DIGEST-MD5.  For backward-compatibility
      with existing deployed infrastructure, implementations are
      encouraged to continue supporting the DIGEST-MD5 mechanism as
      specified in [DIGEST-MD5], however there are known
      interoperability issues with DIGEST-MD5 that make it impractical
      in the long term.

> - 13.9.4: why is SASL-PLAIN singled out here? Other mechanisms are
> susceptible to off-line password guessing when used without TLS
> confidentiality, which is not a trivial attack but still a significant
> risk.

You're right.

I propose that we split up the text a bit here (e.g., the text about
PLAIN in fact talks mostly about TLS verification)...

So, add the following modified paragraph to Section 13.9.4 ("Use of SASL"):

   The use of the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS mechanisms is
   strongly preferred over the SASL PLAIN mechanism because of their
   superior security properties, and TLS plus SASL PLAIN is intended to
   be a fallback only for implementations that do not yet support SCRAM.
   Implementations MUST NOT use the SASL PLAIN without confidentiality
   and integrity protection via TLS.  For additional security
   considerations related to these SASL mechanisms, see [SCRAM] and

Then add the following modified paragraph to Section 13.9.5 ("Use of TLS"):

   To prevent man-in-the-middle attacks, the TLS client (which might be
   an XMPP client or an XMPP server) MUST verify the certificate of the
   TLS server and MUST check its understanding of the server hostname
   against the server's identity as presented in the TLS Certificate
   message (for details, see [TLS-CERTS].

> - 13.11: all three examples of "service unavailable" can be ruled out on
> an operational server. Are there no better examples?

I don't see how they can be ruled out.

> - 15: The sasl-whitespace "feature" is not really a feature, because
> you'd fail any interoperability if you send whitespace during the SASL
> phase, right? Similarly tls-whitespace.

I take it you mean they are "negative features" and interoperability
testing should focus on positive features. But isn't appropriate to
ensure compliance with a MUST NOT statement in the spec?

> - 15: if we insist on PLAIN, I would expect a security-mti-auth-order
> feature, where the proposals are ordered right (i.e. with PLAIN at the
> end).

I think it's better to remove TLS plus SASL PLAIN from the list of
mandatory-to-implement technologies.

> - 15: why is confidentiality-only a MUST? Is it widely deployed? Is it
> required for backward compatibility? 

It was required in RFC 3920 (with a different ciphersuite) and in
practice it is used in the case of TLS plus Server Dialback for s2s

> By the way, please expand the
> acronym MTI somewhere.

It's not used as an acronym, just as a string in some feature names.

> - 15: and hey, there's no feature defined for TLS+SCRAM+? Isn't this the
> one we want/expect to be deployed?

There is a feature for security-mti-auth-scram, which includes both
variants. I propose that we change the feature definition to:

   Feature:  security-mti-auth-scram
   Description:  Support the SASL Salted Challenge Response mechanism
      for authentication only or confidentiality and authentication
      (this implies support for both the SCRAM-SHA-1 and SCRAM-SHA-1-
      PLUS variants).
   Section:  Section 13.8
   Roles:  Client MUST, Server MUST.

> - 15: stanza-* features - if you have an XML schema, can't you just say
> that conformance to the schema is REQUIRED and eliminate all this stuff?
> Given that these are MUSTs, not SHOULDs, a formal specification is so
> much easier to validate. This does *not* contradict the fact that
> runtime validation is optional.

I suppose, but it seems useful for interoperability testing purposes
(which we do plan to pursue more rigorously) to define the more specific
features specified throughout the spec with regard to stanza syntax and

> - 15: I would expect one or a few features around validation of
> identities at the various layers, since we're spending much of the
> document on this issue. "tls-certs" is an important piece of that, but
> not the whole thing.

I agree with you that the layering topics are important here. Do you
have specific suggestions?

Thanks again for your review.


Peter Saint-Andre