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

From: Yaron Sheffer <[email-masked]>
Date: Thu, 28 Oct 2010 12:28:13 +0200

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

The document updates RFC 3920, which is the definition of the core XMPP 
real-time messaging protocol. It should be noted the instant messaging 
and presence are layered on top of this protocol, and specified separately.

General

The document is initially intimidating, because of its length. But it is 
extremely well written (for which I would like to thank the editor) and 
well organized. So overall, a good read.

I have not found anything that I consider a glaring security hole. But 
this is a layered security architecture (application layer == XMPP core 
== SASL == TLS) which is not easy to do right. Hence the large number of 
comments and questions below.

I also appreciate the open discussion of the existing implementations 
and their security issues (e.g. "server dialback", shiver). I hope this 
document results in a security improvement in real deployments.

Detailed Comments

Note: these comments are based on rev -17 of the draft. This only 
matters as far as section numbers, with the only security-relevant 
change in -18 being a useful note on end-to-end protection.

- 1.3: Implementation note: I suggest adding something like "Solutions 
specified in this document offer a significantly better level of security."
- 3.3: why do we not recommend to use TLS (stateless) session resumption 
for reconnection?
- 4.2.5 the access control rule at the bottom of this section makes 
sense. Why why does it explicitly not apply to elements other than XML 
stanzas? Are there cases where you negotiate TLS with someone other than 
the server? You can even imagine weird tunneling attacks using this 
"feature".
- 4.2.5: "other than itself" - am I really allowed to send "message" 
stanzas from one resource of a JID to another resource of the same JID, 
before feature negotiation and before TLS negotiation?
- 4.2.6: why do we even allow non-SASL protected server-to-server 
communication?
- 4.3: How is TLS negotiated for the additional streams? How is it bound 
to the SASL negotiation that (apparently) only takes place once?
- 4.4: this section appears to tie the two streams in the opposite 
directions together - when you close one you expect the other guy to 
close the other ASAP. But what is the behavior for "multiple streams 
over multiple connections" (Sec. 4.3)?
- 4.4: what about orderly tear-down of the TLS association ("closure 
alert")?
- 4.8.3.12: does not-authorized only refer to stream-level, rather than 
stanza-level errors? Are there cases when I am authorized to send some 
stanza types but not others?
- 4.8.3.14 remote-connection-failed has dubious security benefit (why 
tell the world that your RADIUS server is down), compared to reusing 
internal-error.
- 4.8.3.16: shouldn't we say that "reset" (when the stream is encrypted) 
also applies to the higher layers, i.e. encryption and authentication 
should be performed again?
- 4.8.3.18: what are the security implications of a "redirect"? Should 
the client apply the same policy, e.g. for using TLS, as for the 
original server? Which "to" identity to use? Can redirection occur 
before the recipient is even authenticated?
- 4.9: Don't we resend the "stream" header again after completing the 
TLS negotiation (Sec. 4.2.3).
- 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.
- 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.
- 5.4.1: don't you have to declare version >= 1.0 if you simply support 
this draft? Same question in 6.4.1.
- 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".
- Global replace TLS "cipher" -> "ciphersuite".
- 5.4.3.1, bullet 5: actually, based on the "from" attribute that the 
receiving entity has just sent.
- 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)?
- 6.3.2: do you restart the stream twice, once after TLS and once after 
SASL??
- 6.3.3: shouldn't we simply "MUST NOT" the PLAIN mechanism?
- 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.
- 6.4.4: isn't it inconsistent that SASL aborts are converted into XMPP 
failures, but TLS failures are not?
- 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).
- 8.1.1.2: any validated domain -> any validated subdomain.
- 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.
- Same, rule #6, the recipient MUST NOT include the original XML if it's 
not well formed, right?
- 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.
- 8.3.3.11: what are "improper credentials"? It sounds like we are not 
differentiating the conditions of authentication failure vs. 
authorization failure.
- 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.
- 8.3.3.15: Are there no security implications to redirection at the 
stanza level?
- 8.3.3.18: The "wait" error type might not be appropriate for some 
situations, e.g. authentication issues.
- 8.3.3.21: do you explain anywhere what is the difference between 
"prior registration" and "prior subscription"?
- 9.1.1, step 7: this is utterly trivial, but please mention that the 
new "stream" element is sent over TLS.
- 9.1.5: as I noted in Sec. 4.4, the TLS connection needs to be closed 
as well.
- 10.2: "try many different resources", I suppose it is typically fewer 
than 10 per JID, which does not make the attack uninteresting.
- 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?
- 10.5.3.3: 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?
- 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.
- 13.4: the cipher suites are not just "nun-null". They MUST provide 
both confidentiality and integrity.
- 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.
- 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.
- 13.7.1.1: 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"?
- 13.7.1.1: it's strange to specify the hash algorithm, but not the 
signature algorithm (RSA-512 anyone?)
- 13.7.1.1: what are "access certificates"? Neither 5280 nor Google can 
help... And how can an issuer cert NOT be marked with the CA bit?
- 13.7.1.1: 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?
- 13.7.1.2.2: enabling entity -> enabling entities.
- 13.7.1.4: "conjuction" misspelled.
- 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.
- 13.7.2.2.1: "MUST either validate" - incomplete sentence (and 
actually, at a sensitive point in the text).
- 13.7.2.2.1, 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.
- 13.7.2.3: "periodically query OCSP" - is there any guidance about the 
period? Is a recommended period specified in the cert or communicated by 
the OCSP responder?
- 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)? And vice versa, for the server cert 
and the client's To header.
- 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."
- 13.8: "For both confidentiality and authentication with passwords" - 
here you don't specify a TLS ciphersuite.
- 13.8: the note kind of implies that PLAIN is preferable to DIGEST-MD5, 
which is clearly not the case.
- 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.
- 13.11: all three examples of "service unavailable" can be ruled out on 
an operational server. Are there no better examples?
- 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.
- 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).
- 15: why is confidentiality-only a MUST? Is it widely deployed? Is it 
required for backward compatibility? By the way, please expand the 
acronym MTI somewhere.
- 15: and hey, there's no feature defined for TLS+SCRAM+? Isn't this the 
one we want/expect to be deployed?
- 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.
- 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.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 29 Oct 2010 09:46:53 +0200

Hi Peter,

On 10/29/2010 06:01 AM, Peter Saint-Andre wrote:
> Thanks for your careful and thorough review. To maintain forward
> momentum, this is Part 1 of my reply, up through the end of Section 4. I
> shall endeavor to reply regarding the remainder of your review in the
> next 24-48 hours.
>
Thanks a lot for using my comments and misunderstandings to improve the 
document.

I have removed pieces of this mail where I fully accept your 
response/changes.

>> - 4.3: How is TLS negotiated for the additional streams?
>
> Each stream is separately secured.
>
>> How is it bound
> It isn't, because each stream is separately secured (preferably by means
> of TLS + SASL).
>
> I propose that we clarify these matters by modifying the following
> paragraphs from Section 4.3 ("Directionality"):
>
> ###
>
> 4.3.  Directionality
>
>     An XML stream is always unidirectional, by which is meant that XML
>     stanzas can be sent in only one direction over the stream (either
>     from the initiating entity to the receiving entity or from the
>     receiving entity to the initiating entity).
>
>     Depending on the type of session that has been negotiated and the
>     nature of the entities involved, the entities might use:
>
>     o  Two streams over a single TCP connection, where the security
>        context negotiated for the first stream is applied to the second
>        stream.  This is typical for client-to-server sessions, and a
>        server MUST allow a client to use the same TCP connection for both
>        streams.
>
>     o  Two streams over two TCP connections, where each stream is
>        separately secured.  In this approach, one TCP connection is used
>        for the stream in which stanzas are sent from the initiating
>        entity to the receiving entity, and the other TCP connection is
>        used for the stream in which stanzas are sent from the receiving
>        entity to the initiating entity.  This is typical for server-to-
>        server sessions.
>
>     o  Multiple streams over two or more TCP connections, where each
>        stream is separately secured.  This approach is sometimes used for
>        server-to-server communication between two large XMPP service
>        providers; however, this can make it difficult to maintain
>        coherence of data received over multiple streams in situations
>        described under Section 10.1, which is why a server MAY return a
>        <conflict>  stream error to a remote server that attempts to
>        negotiate more than one stream (as described under
>        Section 4.8.3.3).
>
>     This concept of directionality applies only to stanzas and explicitly
>     does not apply to first-level children of the stream root that are
>     used to bootstrap or manage the stream (e.g., first-level elements
>     used for TLS negotiation, SASL negotiation, Server Dialback
>     [XEP-0220], and Stream Management [XEP-0198]).
>
>     The foregoing considerations imply that while completing STARTTLS
>     negotiation (Section 5) and SASL negotiation (Section 6) two servers
>     would use one TCP connection, but after the stream negotiation
>     process is done that original TCP connection would be used only for
>     the initiating server to send XML stanzas to the receiving server.
>     In order for the receiving server to send XML stanzas to the
>     initiating server, the receiving server would need to reverse the
>     roles and negotiate an XML stream from the receiving server to the
>     initiating server over a separate TCP connection.
>
Perhaps add a final sentence: "This separate TCP connection is then 
secured using a new round of TLS and/or SASL negotiation."
> ###
>
>> - 4.8.3.18: what are the security implications of a "redirect"?
>
> Of<see-other-host/>? Seemingly underspecified. :(
>
>> Should
>> original server?
> Yes.
>> Which "to" identity to use?
>
> The 'to' address of the initial stream header would still be the DNS
> domain name of the XMPP service to which the initiating entity is trying
> to connect (see also draft-saintandre-tls-server-id-check).
>
>> Can redirection occur
> Yes.
> I propose that we modify the description as follows:
>
>     The server will not provide service to the initiating entity but is
>     redirecting traffic to another host under the administrative control
>     of the same service provider.  The XML character data of the<see-
>     other-host/>  element returned by the server MUST specify the
>     alternate hostname or IP address at which to connect, which MUST be a
>     valid domainpart or a domainpart plus port number (separated by the
>     ':' character in the form "domainpart:port").  If the domainpart is
>     the same as the source domain, derived domain, or resolved IP address
>     to which the initiating entity originally connected (differing only
>     by the port number), then the initiating entity SHOULD simply attempt
>     to reconnect at that address.  Otherwise, the initiating entity MUST
>     resolve the hostname specified in the<see-other-host/>  element as
>     described under Section 3.2.
>
> I also propose that we add the following paragraph to the end of the
> section:
>
>     When negotiating a stream with the host to which it has been
>     redirected, the initiating entity MUST apply the same policies it
>     would have applied to the original connection attempt (e.g., a policy
>     requiring TLS), MUST specify the same 'to' address on the initial
>     stream header, and MUST verify the identity of the new host using the
>     same reference identifier(s) it would have used for the original
>     connection attempt (in accordance with [TLS-CERTS].  Even if
>     receiving entity returns a<see-other-host/>  error before the
>     confidentiality and integrity of the stream have been established
>     (thus introducing the possibility of a denial of service attack), the
>     fact that the initiating entity needs to verify the identity of the
>     XMPP service based on the same reference identifiers implies that the
>     initiating entity will not connect to a malicious entity; however, to
>     reduce the possibility of a denial of service attack, the receiving
>     entity SHOULD NOT return a<see-other-host/>  error until after the
>     stream has been protected (e.g., via TLS).
>
... and the sending entity SHOULD maintain a running redirect counter, 
and give up after a certain number of successive redirects.

Also, the mitigation you propose in the last sentence only helps if "An 
entity MAY have a policy where it only accepts <see-other-host> elements 
from authenticated peers.

> For sure. I propose that we change this:
>
>     [ ... channel encryption ... ]
>
>     [ ... authentication ... ]
>
>     [ ... resource binding ... ]
>
> to:
>
>     [ ... stream negotiation ... ]
>
I'm not sure. Since we start the example with two <stream> elements, it 
would make sense to show the additional (4?) <stream> elements further 
down. Although the "simple" examples would no longer fit a page. Maybe 
add a "really simple" example with no security?

> ### END OF PART 1 ###

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 29 Oct 2010 16:26:22 +0200

Hi Peter,

I'm fine with your proposals.

Thanks,
	Yaron

On 10/29/2010 04:20 PM, Peter Saint-Andre wrote:
> Hi Yaron, a few additional comments and text proposals inline.
>
> On 10/29/10 1:46 AM, Yaron Sheffer wrote:
>> Hi Peter,
>>
> Yes, that's good. Paragraph updated with your text.
>
>>> ###
>>>
>> entity MAY have a policy where it only accepts<see-other-host>  elements
> Thanks. I propose that we change this paragraph to:
>
>     stream has been protected (e.g., via TLS) and the receiving entity
>     MAY have a policy of following redirects only if it has authenticated
>     the receiving entity.  In addition, the initiating entity SHOULD give
>     up after a certain number of successive redirects (e.g., at least 2
>     but no more than 5).
>
>> I'm not sure. Since we start the example with two<stream>  elements, it
>> would make sense to show the additional (4?)<stream>  elements further
> These examples are included to provide a high-level illustration of what
> a session would look like, so I think eliding the whole stream
> negotiation process is fine. However, I think it would be good to add a
> forward reference to Section 9 so that the reader knows where to go for
> detailed examples. Thus propose modifying the first paragraph of Section
> 4.9 as follows:
>
>     This section contains two highly simplified examples of a stream-
>     based connection between a client and a server; these examples are
>     included for the purpose of illustrating the concepts introduced thus
>     far, but the reader needs to be aware that these examples elide many
>     details (see Section 9 for more complete examples).
>
> Peter
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 31 Oct 2010 17:37:15 +0200

Hi Peter,

again, I have removed the points where we are in agreement.

Thanks,
	Yaron

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:
>
> 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.

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

> 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. BTW, you meant 5.4.3.1.
>
> 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.
> 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.

> 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...
> 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". 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.

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