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

From: Yaron Sheffer <[email-masked]>
Date: Mon, 01 Nov 2010 11:25:57 +0200

Hi Peter,

Responding to the last part. Thanks for a constructive discussion.

	Yaron

On 10/30/2010 07:05 AM, Peter Saint-Andre wrote:
> 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?

Yes, this is more convincing than the current justification.

>
>> - 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.
>
Sorry, I misread the text.

- New comment: 10.5.1 and 10.5.2 read funny. Without the context they 
both sound like "the server MUST handle the stanza, or not." I suggest 
to append to both sections: "The server MUST NOT route the stanza to 
another server".

>> - 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?
>
> That feature is not part of XMPP.
>
Pity. I can see several use cases: deliver photos into a large screen, 
deliver messages in specific non-ASCII scripts to devices that can 
actually display them...

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

Yes, but nothing in the Note or the preceding paragraph mentions 
end-to-end security.
>
>> - 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.
>
Yes.

>> - 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?
>
Maybe this would be more realistic: It SHOULD be possible to provision 
an implementation (in both c-to-s and s-to-s situations) with specific 
trust anchors for the opposite entity. When an application is thus 
provisioned, it MUST NOT use a generic PKI trust store to authenticate 
the opposite entity.

>> - 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.
>
Let's keep it then.

>> - 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"?
>
> 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
>     certificates:
>
> That way we are using the appropriate terminology from RFC 5280.
>
Yes.

>> - 13.7.1.1: 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
> draft-hildebrand-dna:
>
>     The issuer MUST support signing attribute certificate with the PKCS
>     #1 version 1.5 signature algorithm with SHA-256, as specified in
>     [RFC4055].
>
> Clearly something has been lost in translation. I'll check with Sean on
> this point.
>
I'll defer to Sean.

>> - 13.7.1.1: what are "access certificates"? Neither 5280 nor Google can
>> help...
>
> s/access/attribute/
>
>> 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:
>
> http://tools.ietf.org/id/draft-hildebrand-dna-00.txt
>
> http://tools.ietf.org/id/draft-ietf-xmpp-dna-00.txt
>
> http://www.ietf.org/id/draft-barnes-xmpp-dna-00.txt
>
> 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.
>
Wow! This is very forward looking. Yes, the whole package should 
probably be removed from 3290bis and moved into a future update to this 
document.

>> - 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?
>
> 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.
>
Please do. In particular, trusting a non-CA to sign certificates seems 
to contradict the spirit of PKIX policies.

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

I suggest to remove the text altogether. People will have debug tools, 
log files etc., we shouldn't specify them.

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

>> - 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?
>
> 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
>
Can you add such text then?

>> - 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
> account.
>
Ahem, the client's 'from' attribute is a SHOULD (4.6.1).

>> 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 13.7.2.1 ("Server
> Certificates") and 13.7.2.2 ("Client Certificates")...
>
> ###
>
> 13.7.2.1.  Server Certificates
>
>     For server certificates, the rules and guidelines defined in
>     [TLS-CERTS] apply, with the proviso that the XmppAddr identifier
>     specified under Section 13.7.1.4 is allowed as a reference
>     identifier.
>
>     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.
>
> 13.7.2.2.  Client Certificates
>
>     When an XMPP server validates a certificate presented by a client,
>     there are three possible cases, as discussed in the following
>     sections.
>
>     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
>        assert.
>
> ###
>
>
>> - 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?
>
AES-128 is just fine. Actually there are major issues with AES-256. But 
I think this document should specify a ciphersuite, rather than rely on 
RFC 5246 for that. After all you are essentially profiling TLS.

>
>> - 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.
>
OK, I see your point now.

>> - 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?
>
No, what I meant was: you don't need to test them especially, because 
the connection will break immediately. Just like you don't check that 
"streem" is spelled right.

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

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

>> By the way, please expand the
>> acronym MTI somewhere.
>
> It's not used as an acronym, just as a string in some feature names.
>
Still, you want people to understand what it means.

>
>> - 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?
>
- Server side: correlate cert-asserted client ID with "from".
- Server: correlate "from" on stream to identity as authenticated by SASL.
- Server: rewrite "from" on stanza to authenticated ID.
- Client side: correlate cert-asserted server ID with "from".
- Client: correlate "from" on stream to identity as authenticated by TLS 
certs and/or SASL.

> Thanks again for your review.
>
> Peter
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Oct 2010 22:01:15 -0600

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.

[Copying [email-masked] to keep the WG in the loop...]

On 10/28/10 4:28 AM, Yaron Sheffer wrote:
> 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.

Thanks.

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

We hope so!

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

True. In my working I've added this sentence (including a forward
reference to the discussion of strong security):

   The solutions specified in this document offer a significantly
   stronger level of security (see also Section 13.6).

> - 3.3: why do we not recommend to use TLS (stateless) session resumption
> for reconnection?

Your suggestion is a good one.

The XMPP WG and broader XMPP developer community have had some
discussions about methods for "quick reconnect". These would involve the
use of TLS session resumption, pipelining of requests from the
initiating entity to the receiving entity, perhaps some SASL tricks (see
for example draft-cridland-sasl-tls-sessions-00), etc. Those discussions
are rather preliminary at this time, however I think we can safely
recommend the use TLS session resumption.

I propose that we add the following paragraph at the end of Section 3.3:

   It is RECOMMENDED to make use of TLS session resumption [TLS-RESUME]
   when reconnecting.  A future version of this document, or a separate
   specification, might provide more detailed guidelines regarding
   methods for speeding the reconnection process.

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

I now see that the following paragraph is poorly phrased:

   The initiating entity MUST NOT attempt to send XML stanzas
   (Section 8) to entities other than itself (i.e., the client's
   connected resource or any other authenticated resource of the
   client's account) or the server to which it is connected until stream
   negotiation has been completed.  Even if the initiating entity does
   attempt to do so, the receiving entity MUST NOT accept such stanzas
   and MUST return a <not-authorized/> stream error.  This rule applies
   to XML stanzas only (i.e., <message/>, <presence/>, and <iq/>
   elements qualified by the content namespace) and not to XML elements
   used for stream negotiation (e.g., elements used to complete TLS
   negotiation (Section 5) or SASL negotiation (Section 6)).

There are several points that could be clarified here:

1. You can't send non-stanzas to other entities because (as XMPP is
currently defined) only stanzas have 'to' addresses. The XML elements
that we use for things like TLS negotiation and SASL negotiation are not
addressable to other entities (e.g., a remote server or client) but only
to the server to which a client has connected, so we don't need to
mention them in this paragraph.

2. However, that's contingent on how XMPP is currently defined, i.e., we
assume that there are only stanzas and stream-negotiation elements. This
leaves a bit of a loophole for elements that don't fit in either of
those buckets, e.g., sending <foo:bar to='baz'/> from the client. Is the
server supposed to route or deliver that element to baz? I would say no.
Someone could write a server that allows the communication of arbitrary
XML elements over XML streams, but that's not what 3920bis defines. So I
think we need to tighten that up, although this paragraph is not the
place to do so (I think it belongs in Section 4.7.3 "Other Namespaces").

3. Yes, a server might allow a client to communicate with its bare JID
or other full JIDs after it has authenticated but before it has bound a
resource (e.g., to send a service discovery request so it can discover
which other resources are currently connected). This is not an important
"feature" by any means, but as far as I can see it does not open any
security holes as long as the server requires authentication first. Thus
the phrase "until stream negotiation has been completed" in the quoted
paragraph is misleading.

Taking these considerations together, I propose the following modified
paragraph at the end of Section 4.2.5:

   An initiating entity MUST NOT attempt to send data to entities
   other than itself (i.e., the bare JID of the user's account) or the
   server to which it has connected until it has authenticated with the
   receiving entity.  If the initiating entity attempts to do so, the
   receiving entity MUST NOT accept such data and MUST close the stream
   with a <not-authorized/> stream error.

Then I propose that we modify Section 4.7.4 as follows:

###

4.7.3.  Other Namespaces

   Either party to a stream MAY send data qualified by namespaces other
   than the content namespace and the streams namespace.  For example,
   this is how data related to TLS negotiation and SASL negotiation are
   exchanged, as well as XMPP extensions such as Stream Management
   [XEP-0198] and Server Dialback [XEP-0220].  (For historical reasons,
   some server implementations expect a declaration of the 'jabber:
   server:dialback' namespace on server-to-server streams, as explained
   in [XEP-0220].)

   However, an XMPP server MUST NOT route or deliver data received over
   an input stream if that data is (a) qualified by another namespace
   and (b) addressed to an entity other than the server, unless the
   other party to the output stream over which the server would send the
   data has explicitly negotiated or advertised support for receiving
   arbitrary data from the server.  This rule is included because XMPP
   is designed for the exchange of XML stanzas (not arbitrary XML data),
   and because allowing an entity to send arbitrary data to other
   entities could significantly increase the potential for exchanging
   malicious information.  As an example of this rule, the server
   hosting the example.net domain would not route the following first-
   level XML element from <[email-masked]> to <[email-masked]>:

     <ns1:foo xmlns:ns1='http://example.org/ns1'
              from=[email-masked]/resource1'
              to=[email-masked]'>
       <ns1:bar/>
     </ns1:foo>

   This rule also applies to first-level elements that look like stanzas
   but that are improperly namespaced and therefore really are not
   stanzas at all (see also Section 4.7.4), for example:

     <ns2:message xmlns:pre='http://example.org/ns2'
                  from=[email-masked]/resource1'
                  to=[email-masked]'>
       <body>hi</body>
     </ns2:message>

   Upon receiving arbitrary first-level XML elements over an input
   stream, a server MUST either ignore the data or return a stream
   error, which SHOULD be <unsupported-stanza-type/>.

###

> - 4.2.6: why do we even allow non-SASL protected server-to-server
> communication?

Because, in practice, most existing services end up using Server
Dialback, not TLS + SASL EXTERNAL with PKIX certificates.

> - 4.3: How is TLS negotiated for the additional streams? 

Each stream is separately secured.

> How is it bound
> to the SASL negotiation that (apparently) only takes place once?

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.

###

> - 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)?

That is an excellent question. Section 4.4 currently assumes that there
is a defined pairing of streams because that is what happens in well
over 99% of the cases (I'd venture to guess that using multiple streams
over multiple TCP connections is extremely rare and happens only for
some high-volume server-to-server links). IMHO we don't have enough
experience with this case to recommend server behavior, although it
would be good to gather feedback from any service providers who are
using multiple streams over multiple TCP connections. Therefore I
propose that we modify Section 4.4 as follows:

###

   If the parties are using either two streams over a single TCP
   connection or two streams over two TCP connections, the entity that
   sends the closing stream tag SHOULD behave as follows:

   1.  Wait for the other party to also close its stream before
       terminating the underlying TCP connection(s); this gives the
       other party an opportunity to finish transmitting any data in the
       opposite direction before the TCP connection(s) is terminated.

   2.  Refrain from initiating the sending of further data over that
       stream but continue to process data sent by the other entity
       (and, if necessary, react to such data).

   3.  Consider both streams to be void if the other party does not send
       its closing stream tag within a reasonable amount of time (where
       the definition of "reasonable" is a matter of implementation or
       deployment).

   4.  After receiving a reciprocal closing stream tag from the other
       party or waiting a reasonable amount of time with no response,
       terminate the underlying TCP connection(s).

   If the parties are using multiple streams over multiple TCP
   connections, there is no defined pairing of streams and therefore the
   behavior is a matter for implementation.

###

> - 4.4: what about orderly tear-down of the TLS association ("closure
> alert")?

Sending of the closure alert is mandated by RFC 4346. Do you think it is
necessary (or would be helpful) to call it out in the specification of
an application protocol that re-use TLS?

I note that Section 7.2.1 ("Closure Alerts") of RFC 4346 states in part:

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding close_notify.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

I note also that rule #2 in Section 4.4 of 3920bis states:

   2.  Refrain from initiating the sending of further data over that
       stream but continue to process data sent by the other entity
       (and, if necessary, react to such data).

This implies that the entity that is closing the stream might send more
data and certaily might receive data (on the other stream). Thus I think
we do need to clarify use of closure alerts. I propose adding the
following security note to Section 4.4:

      Security Note: In accordance with Section 7.2.1 of [TLS], to help
      prevent a truncation attack the party that is closing the stream
      MUST send a TLS close_notify alert and MUST receive a responding
      close_notify alert from the other party before closing the
      underlying TCP connection(s).

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

There are three <not-authorized/> error conditions, each qualified by a
different namespace:

1. The stream error condition is triggered by trying to send data before
completing authentication.

2. The SASL error condition is triggered by providing a bad username or
incorrect credentials.

3. The stream error condition is triggered by attempting to complete an
application-layer action that requires authentication (e.g., attempting
to join a password-protected chatroom without providing the password).

A server could restrict a user's ability to send different types of
stanzas (e.g., a presence-only XMPP service could return a stanza error
if a user attempts to send a <message/> stanza, but in that case it's a
service-wide policy and the <not-allowed/> stanza error condition is
more appropriate). In general, the <not-authorized/> stanza error
condition implies that the sender could do *something* to modify the
data it sent in order to prove that it is in fact authorized to perform
the action requested in the stanza (e.g., include a password in the
chatroom join request).

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

It's not an internal error because the source of the failure is a remote
entity. As far as I know, this error condition has been used only in the
context of server dialback (in the case where a stream error occurs
between the Receiving Server and the Authoritative Server), but we've
tried to scrub the-protocol-that-shall-not-be-named from 3920bis
wherever possible; doing so in here has led to confusion on your part so
I propose that we might want to modify the description, as so:

   The server is unable to properly connect to a remote entity that is
   needed for authentication or authorization (e.g., in certain
   scenarios related to Server Dialback [XEP-0220]); this condition is
   not to be used when the cause of the error is within the
   administrative domain of the XMPP service provider, in which case the
   <internal-server-error/> condition is more appropriate.

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

Good point. I propose that we modify the description as follows:

   The server is closing the stream because it has new (typically
   security-critical) features to offer, because the keys or
   certificates used to establish a secure context for the stream have
   expired or have been revoked during the life of the stream
   (Section 13.7.2.3), because the TLS sequence number has wrapped
   (Section 5.3.5), etc.  The reset applies to the stream and to any
   security context established for that stream (e.g., via TLS and
   SASL), which means that encryption and authentication need to be
   negotiated again for the new stream (e.g., TLS session resumption
   cannot be used).

> - 4.8.3.18: what are the security implications of a "redirect"? 

Of <see-other-host/>? Seemingly underspecified. :(

> Should
> the client apply the same policy, e.g. for using TLS, as for the
> 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
> before the recipient is even authenticated?

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

> - 4.9: Don't we resend the "stream" header again after completing the
> TLS negotiation (Sec. 4.2.3).

For sure. I propose that we change this:

   [ ... channel encryption ... ]

   [ ... authentication ... ]

   [ ... resource binding ... ]

to:

   [ ... stream negotiation ... ]

### END OF PART 1 ###

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Oct 2010 08:20:00 -0600

Hi Yaron, a few additional comments and text proposals inline.

On 10/29/10 1:46 AM, Yaron Sheffer wrote:
> Hi Peter,
> 
> On 10/29/2010 06:01 AM, Peter Saint-Andre wrote:
> 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.
> 
> Perhaps add a final sentence: "This separate TCP connection is then
> secured using a new round of TLS and/or SASL negotiation."

Yes, that's good. Paragraph updated with your text.

>> Of<see-other-host/>? Seemingly underspecified. :(
>>
>>> Should
>>     of the same service provider.  The XML character data of the<see-
>>     resolve the hostname specified in the<see-other-host/>  element as
>>     receiving entity returns a<see-other-host/>  error before the
>>     entity SHOULD NOT return a<see-other-host/>  error until after the
> ... 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.

Thanks. I propose that we change this paragraph to:

   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 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
> down. Although the "simple" examples would no longer fit a page. Maybe
> add a "really simple" example with no security?

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

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Oct 2010 08:41:59 -0600

Excellent. I'll try to finish Part 2 today.

On 10/29/10 8:26 AM, Yaron Sheffer wrote:
> Hi Peter,
> 
> I'm fine with your proposals.
> 
> Thanks,
>     Yaron
> 
> On 10/29/2010 04:20 PM, Peter Saint-Andre wrote:
>>> entity MAY have a policy where it only accepts<see-other-host>  elements
>>> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Oct 2010 12:32:20 -0600

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Oct 2010 23:05:45 -0600

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

Fixed.

Is this more accurate?

   [...]

s/access/attribute/

> - 13.7.1.2.2: enabling entity -> enabling entities.
> - 13.7.1.4: "conjuction" misspelled.

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

> - 13.7.2.2.1: "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:

http://tools.ietf.org/id/draft-saintandre-rfc3920bis-05.txt

###

###

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

Added.

> - 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
   [PLAIN].

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

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Mon, 01 Nov 2010 19:20:03 +0100

> Responding to the last part. Thanks for a constructive discussion.
Hi,

>> mandatory-to-implement technologies.
FWIW, I'm not entirely content with that for two reasons:
a) Even if TLS+SASL PLAIN is not MTI people still will and do implement
it. I think it would therefore make sense to still specify that PLAIN
shall only be used as a "last resort".

b) (which is my bigger concern) As strange as that may sound, we need
PLAIN in order to upgrade to a new mechanism. I though this was also
explicit in 3920bis, but I can't find it right now.
Consider a case where a server only stores the MD5 hash of the password.
This is sufficient to do PLAIN and DIGEST MD5 auth. But for SCRAM a
different representation is needed.
The common way for the server to upgrade is to once offer only PLAIN as
a mechanism. If that is not possible (clients can choose not to support
PLAIN) some deployments might be stuck with DIGEST MD5...
We could mandate that PLAIN is only MTI for clients (servers would
implement it when they need to), but that would allow for the same
down-grade attacks that are already possible now (i.e. hopefully none ;) ).

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Nov 2010 13:19:14 -0600

On 10/31/10 9:37 AM, Yaron Sheffer wrote:
> 
> On 10/29/2010 08:32 PM, Peter Saint-Andre wrote:
> 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.

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

> Yes, it makes sense to switch #4 and #5. 

Done in my working copy.

> BTW, you meant 5.4.3.1.

Yep, sorry.

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

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

>> placed in the<text/>  element (even if language-tagged).
> 
> Yes, SHOULD NOT would be BETTER...

Done.

>> a<not-authorized/>  stanza error. It will return the same error if the
> 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.

>> publish-subscribe<http://xmpp.org/extensions/xep-0060.html>. An example
> 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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Nov 2010 14:19:51 -0600

> Responding to the last part. Thanks for a constructive discussion.

I hope it's productive -- I was getting pretty tired on Friday night
when I wrote the last bits of Part 3, so I'm not sure I was fully
coherent. :)

> Yes, this is more convincing than the current justification.

Agreed. Adjusted text follows:

###

   2.  How a server processes stanzas sent to the bare JID
       <localpart@domainpart> has implications for directory harvesting,
       because if the server responds differently depending on whether
       there there is an account registered for that bare JID.

   3.  How a server processes stanzas sent to a full JID has
       implications for presence leaks, because an attacker could send
       requests to multiple full JIDs and receive different replies
       depending on whether the user has a device currently online at
       that full JID.  The use of randomized resourceparts (whether
       generated by the client or the server) significantly helps to
       mitigate this attack, so it is of somewhat lesser concern than
       the directory harvesting attack.

###

> Sorry, I misread the text.

There's a lot of text to read, so that's fully understandable!

> to append to both sections: "The server MUST NOT route the stanza to

I'd prefer to add the text in only one place, and the best place seems
to be a new sentence at the end of the only paragraph in Section 10.5,
as follows:

###

10.5.  Local Domain

   If the hostname of the domainpart of the JID contained in the 'to'
   attribute matches one of the configured hostnames of the server, the
   server MUST first determine if the hostname is serviced by the server
   itself or by a specialized local service.  If the latter, the server
   MUST route the stanza to that service.  If the former, the server
   MUST proceed as follows.  However, the server MUST NOT route or
   "forward" the stanza to another domain because it is the server's
   responsibility to process all stanzas for which the domainpart of the
   'to' address matches one of the configured hostnames of the server
   (among other things, this helps to prevent looping).

###

> deliver messages in specific non-ASCII scripts to devices that can

Well, the "X" in XMPP stands for "extensible". We could always define an
XMPP extension for that feature. In fact, I think we could do it already
with XEP-0273 ("Stanza Interception and Filtering Technology"):

http://xmpp.org/extensions/xep-0273.html

But it's not part of the core.

> Yes, but nothing in the Note or the preceding paragraph mentions

Section 13.1 has this paragraph:

   This specification covers only the security of a direct XML stream
   between two servers or between a client and a server (cases #1 and
   #2), where each stream can be considered a single "hop" along a
   communication path.  The goal of security for a multi-hop path (cases
   #3 and #4), although very desirable, is out of scope for this
   specification.

The note in Section 13.4 expands on that, specifically with regard to
confidentiality and integrity (the topic of 13.4). That's the best place
I could find for it, but suggestions are welcome.

>>     a server or between two servers.

OK, done.

> provisioned, it MUST NOT use a generic PKI trust store to authenticate

That does seem better. In my working copy that paragraph now reads:

###

   [STRONGSEC] defines "strong security" and its importance to
   communication over the Internet.  For the purpose of XMPP
   communication over client-to-server and server-to-server streams, the
   term "strong security" refers to the use of security technologies
   that provide both mutual authentication and integrity checking (e.g.,
   a combination of TLS encryption and SASL authentication using
   appropriate SASL mechanisms).  An implementation SHOULD make it
   possible for an end user or service administrator to provision a
   deployment with specific trust anchors for the certificate presented
   by a connecting entity (either client or server); when an application
   is thus provisioned, it MUST NOT use a generic PKI trust store to
   authenticate the connecting entity.  More detailed rules and
   guidelines regarding certificate validation are provided in the next
   section.

###

>> mechanism. I don't see an easy way to disambiguate the term here, but

OK. I'd prefer not to perform major terminological surgery at this point...

Done.

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

I'll make sure to check with him about this before IESG review.

> probably be removed from 3290bis and moved into a future update to this

Agreed. I've removed that bullet.

> to contradict the spirit of PKIX policies.

Yes, I now see that you are right (see previous warning about lack of
coherence). I've provisionally updated the relevant paragraph of Section
13.7.2 as follows, breaking it into bullets for easier readability:

###

   For both server certificates and client certificates, the validating
   entity MUST do the following:

   1.  Attempt to verify the integrity of the certificate.

   2.  Attempt to verify that the certificate has been properly signed
       by the issuing Certificate Authority.

   3.  Attempt to validate the full certification path.

   4.  Check the rules for end entity public key certificates and
       certification authority certificates specified under
       Section 13.7.1.1 for the general case and under either
       Section 13.7.1.2 or Section 13.7.1.2 for XMPP server or client
       certificates, respectively.

   5.  Check certificate revocation messages.

   If any of those validation attempts fail, either entity MAY choose to
   unilaterally terminate the session.

###

> log files etc., we shouldn't specify them.

Sentence removed.

Done.

> Can you add such text then?

In my working copy I now have:

   2.  Periodically query the Online Certificate Status Protocol [OCSP]
       responder listed in the Authority Information Access (AIA)
       extension of the certificate presented by the other party and any
       certificates on which that certificate depends (such as a root or
       intermediate certificate for a certification authority), and
       close the stream if any such certificate has been revoked, with a
       stream error of <reset/> (Section 4.8.3.16).  It is RECOMMENDED
       to query the OSCP responder 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.

> Ahem, the client's 'from' attribute is a SHOULD (4.6.1).

It is, but that's in an effort to move people in the right direction.
This matter was very unclear in RFC 3920.

>>        header; i.e., this is the identity that the client is trying to

Does that text seem helpful?

Done.

There was talk in the XMPP WG of moving all MTI technologies out of the
core spec so that they could be updated more frequently. Maybe we'll do
that in the next revision cycle (which will result in a much smaller diff).

OK.

> "streem" is spelled right.

True. I've removed those features.

>> mandatory-to-implement technologies.

I'll reply about this one separately, given the response from Florian
Zeitz on the XMPP WG list.

> Still, you want people to understand what it means.

I've added the acronym on first use (Section 5.4.3).

> - Client: correlate "from" on stream to identity as authenticated by TLS

Thanks. I'll add features for those and also think further about the
stream-level 'from' for client-to-server streams.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Nov 2010 14:27:04 -0600

> shall only be used as a "last resort".

I think that's what we were trying to say in the text, but we didn't do
a good job of it.

> down-grade attacks that are already possible now (i.e. hopefully none ;) ).

I had forgotten about that use case, so thanks for the reminder.

Sometime in the next 24-48 hours I'll propose rewritten text about MTI
technologies, including TLS + SASL PLAIN. However it requires careful
crafting and unfortunately I don't have time to do that right now.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Mon, 01 Nov 2010 20:57:23 +0000

> FWIW, I'm not entirely content with that for two reasons:

I'll scrap yours, and add a third.

> shall only be used as a "last resort".
I think SASL PLAIN should be specifying this. There's nothing special  
in XMPP which makes PLAIN a poor choice.

> down-grade attacks that are already possible now (i.e. hopefully  

You're thinking of transition-needed, which was IIRC removed from the  
bis drafts.

It's pretty scary itself, as it provides an easy path to a downgrade  
attack.

But here's another compelling (in my view) reason to keep PLAIN,  
quoted from the opening lines of RFC 4616:

   Clear-text, multiple-use passwords are simple, interoperate with
   almost all existing operating system authentication databases

In particular, where we use an Active Directory, or other third-party  
LDAP directory, we more or less have to drop down to only offering  
PLAIN. (With AD we can also offer GSSAPI sometimes, but this isn't an  
ideal choice for an MTI, and with any LDAP directory we could provide  
SCRAM secrets to some extent).

Requiring clients and servers to be capable of using PLAIN, whilst  
advising (and providing) better alternatives to cover other cases,  
seems to be the best choice for interoperability.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Cridland <[email-masked]>
Date: Mon, 01 Nov 2010 21:16:08 +0000

On Mon Nov  1 20:57:22 2010, Dave Cridland wrote:
> You're thinking of transition-needed, which was IIRC removed from  
> the  bis drafts.
> 
> It's pretty scary itself, as it provides an easy path to a  
> downgrade  attack.

FWIW, Philip Hancke pointed out that transition-needed *is* in the  
current drafts at §6.5.12, with suitable security note.

Dave.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 02 Nov 2010 12:47:36 +0200

Hi Peter,

I'm OK with all your changes below.

Thanks,
     Yaron

On 11/01/2010 09:19 PM, Peter Saint-Andre wrote:
> service will return a<forbidden/>  error. Perhaps we don't have a very

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 02 Nov 2010 13:10:40 +0200

Hi Peter,

please see my comments in-line. I have removed already-closed issues.

Thanks,
     Yaron

>     unilaterally terminate the session.
This is all fine, other than the last sentence. There's little security 
value (or performance value, for that matter) in "MUST check, but only 
MAY choose to fail". With possible minor exceptions, these rules are all 
security-critical.

> Does that text seem helpful?
Yes, definitely.

> that in the next revision cycle (which will result in a much smaller 
I also think it's a good idea.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 02 Nov 2010 13:20:06 +0200

I'm OK with this text, including (sigh) PLAIN.

On 11/02/2010 06:45 AM, Peter Saint-Andre wrote:
> On 11/1/10 8:59 PM, Peter Saint-Andre wrote:
>
> > As mentioned, I'll work to capture these considerations in proposed 
> text.
>
> Here is proposed text. Please review and provide feedback.
>
> ###
>
> 13.8.  Mandatory-to-Implement Technologies
>
>     The following TLS ciphersuites and SASL mechanisms are mandatory-to-
>     implement (naturally, implementations MAY support other ciphersuites
>     and mechanisms as well).  For security considerations related to TLS
>     ciphersuites, see Section 13.9.4 and [TLS].  For security
>     considerations related to SASL mechanisms, Section 13.9.4, [SASL],
>     and specifications for particular SASL mechanisms such as [SCRAM],
>     [DIGEST-MD5], and [PLAIN].
>
> 13.8.1.  For Authentication Only
>
>     For authentication only, servers and clients MUST support the SASL
>     Salted Challenge Response mechanism [SCRAM], in particular the SCRAM-
>     SHA-1 variant (REQUIRED) and SCRAM-SHA-1-PLUS variant (RECOMMENDED if
>     channel binding is possible).
>
>        Security Note: Even though it is possible to complete
>        authentication only without confidentiality, it is RECOMMENDED for
>        servers and clients to protect the stream with TLS before
>        attempting authentication with SASL, both to help protect the
>        information exchanged during SASL negotiation and to help prevent
>        certain downgrade attacks; see also Section 13.9.4 and
>        Section 13.9.5.
>
>        authentication only.  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.8.2.  For Confidentiality Only
>
>     For confidentiality only, servers SHOULD support TLS with the
>     TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.
>
>        Security Note: Because a connection with confidentiality only has
>        weaker security properties than a connection with both
>        confidentiality and authentication, it is RECOMMENDED for servers
>        and clients to prefer connections with both qualities (e.g., by
>        protecting the stream with TLS before attempting authentication
>        with SASL).  In practice, confidentiality only is employed merely
>        for server-to-server connections when the peer server does not
>        present a certificate and the servers use Server Dialback
>        [XEP-0220] for weak identity verification, but TLS is still
>        desirable to protect the connection against casual eavesdropping.
>
> 13.8.3.  For Confidentiality and Authentication With Passwords
>
>     For both confidentiality and authentication with passwords, servers
>     and clients MUST support TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
>     ciphersuite plus SCRAM-SHA-1 and (when channel binding is possible)
>     SCRAM-SHA-1-PLUS.
>
>     As a fallback when SCRAM is not available, servers MAY offer and
>     clients MAY use TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite
>     plus SASL PLAIN.
>
>        Security Note: The SCRAM-SHA-1 and SCRAM-SHA-1-PLUS mechanisms are
>        superior security properties.  TLS plus SASL PLAIN is primarily
>        intended to be a fallback for implementations that do not yet
>        support SCRAM.  However, in certain deployment scenarios it can be
>        difficult for a server to offer SCRAM-based mechanisms (e.g.,
>        because the XMPP service depends for authentication purposes on a
>        database or directory that is not under the control of the XMPP
>        administrators).  Furthermore, it can be appropriate for an XMPP
>        service to offer the SASL PLAIN mechanism when it upgrades
>        security mechanisms and needs the plaintext password in order to
>        seed user credentials (see Section 6.5.12).  A client needs to
>        treat all such uses of the SASL PLAIN mechanism with caution, MUST
>        prefer other mechanisms (e.g., SCRAM-SHA-1, SCRAM-SHA-1-PLUS, and
>        EXTERNAL) to the PLAIN mechanism, and MUST NOT use the PLAIN
>        mechanism without confidentiality and integrity protection via
>        TLS.
>
> 13.8.4.  For Confidentiality and Authentication Without Passwords
>
>     For both confidentiality and authentication without passwords,
>     servers MUST and clients SHOULD support TLS with the
>     TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus the SASL EXTERNAL
>     mechanism (see Appendix A of [SASL]) supporting PKIX certificates.
>
> ###
>
> Peter
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 2 Nov 2010 07:13:14 -0700

On Nov 2, 2010, at 5:12 AM, Peter Saint-Andre wrote:

> On 11/2/10 5:20 AM, Yaron Sheffer wrote:
> If it's any consolation, I'm sighing along with you. :)
> 
> Two points:
> 
> 1. Eventually, we should be able to drop PLAIN in a future revision of
> the MTI technologies spec that we'll pull out of 3920bis in 1+ years.

Good luck with that.  The arguments used now for its inclusion is likely to be repeated and, again, win.

Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it does offer good interoperability, it does good enough security for today's, and more importantly, tomorrow's Internet.

I think we actually should be mandating a SCRAM-*-PLUS mechanism, because channeling bindings are really needed due to 'user click through' of TLS warnings, downgrade attack warnings, etc..   I do suspect that it will take time for this mechanism to be come ubiquitous, but I fear that without a MUST, it will never become ubiquitous.   But I do suspect well have multiple independently developed implementations of SCRAM-*-PLUS in XMPP within a few months of publication of this revision of XMPP.

I suspect I'm in the rough on both points.  Oh well.

> 2. The technology that the XMPP community uses for account registration
> (XEP-0077) could benefit from an update, or even a replacement, and when
> that work is completed I'd like to include a method by which a client
> could register a key or cert with the server, thus smoothing the path
> toward password-less authentication. IMHO that will be the best approach
> in the longer term, instead of continually tweaking the password-based
> methods. But that's a topic for another time...

I also think transition-needed needs to be deprecated in favor of transition within the bound channel (e.g., today via XEP 77, tomorrow ?).

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 2 Nov 2010 08:40:50 -0700

> Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it does offer good interoperability, it does good enough security for today's, and more importantly, tomorrow's Internet.

s/does good enough/does NOT offer good enough/

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 2 Nov 2010 12:03:31 -0700

On Nov 2, 2010, at 9:37 AM, Peter Saint-Andre wrote:

>>> 2. The technology that the XMPP community uses for account
>>> registration (XEP-0077) could benefit from an update, or even a
>>> replacement, and when that work is completed I'd like to include a
>>> method by which a client could register a key or cert with the
>>> server, thus smoothing the path toward password-less
>>> authentication. IMHO that will be the best approach in the longer
>>> term, instead of continually tweaking the password-based methods.
>>> But that's a topic for another time...
>> 
>> I also think transition-needed needs to be deprecated in favor of
>> transition within the bound channel (e.g., today via XEP 77, tomorrow
>> ?).
> 
> I'm not sure exactly what "transition within the bound channel" is, but
> it sounds worthy of discussion when we work on 3920ter.

The problem with transition-needed is that the error is sent outside the bound channel.

By "within the bound channel", I mean a transitioning method, including any necessary signaling, would be performed inside the bound channel, that is, within the new <stream:stream/> protected by the SASL exchange.

> At this point I
> don't think the XMPP community has a great deal of experience with, or
> even understanding of, channel binding, so it's difficult for us to make
> strong recommendations that depend on channel binding.

It would be same issue of doing transition outside of a SASL negotiated security layer.  It's prone to attack.  And the fix is the same.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 2 Nov 2010 14:11:36 -0700

On Nov 2, 2010, at 1:17 PM, Peter Saint-Andre wrote:

> On 11/2/10 1:03 PM, Kurt Zeilenga wrote:
>> 
>>>>> registration (XEP-0077) could benefit from an update, or even
>>>>> a replacement, and when that work is completed I'd like to
>>>>> include a method by which a client could register a key or cert
>>>>> with the server, thus smoothing the path toward password-less 
>>>>> authentication. IMHO that will be the best approach in the
>>>>> longer term, instead of continually tweaking the password-based
>>>> I also think transition-needed needs to be deprecated in favor
>>>> of transition within the bound channel (e.g., today via XEP 77,
>>>> tomorrow ?).
>>> 
>>> I'm not sure exactly what "transition within the bound channel" is,
>>> but it sounds worthy of discussion when we work on 3920ter.
>> 
>> By "within the bound channel", I mean a transitioning method,
>> including any necessary signaling, would be performed inside the
>> bound channel, that is, within the new <stream:stream/> protected by
>> the SASL exchange.
>> 
>>> At this point I don't think the XMPP community has a great deal of
>>> experience with, or even understanding of, channel binding, so it's
>>> difficult for us to make strong recommendations that depend on
>>> channel binding.
>> 
>> It would be same issue of doing transition outside of a SASL
>> negotiated security layer.  It's prone to attack.  And the fix is the
>> same.
> 
> What is the attack?

> If the client required negotiation of TLS before
> moving on to SASL, the server has already authenticated to the client at
> the stage.

In the SASL negotiated security label case, assume no TLS is used.

In the channeling binding case, assume the user/client is relying on the SASL mechanism's mutual authentication capabilities to identify the server and is merely using TLS to provide stream security.   This is, I think, one of the most significant use case of channel binding, at least from the client's perspective. (From the server's perspective, I think the most significant aspect of channel binding is that server no longer needs to rely on the client and its user to verify the server's certificate and perform subject name checks, both of which are likely not to done well.)

> As I far as I understand, you are arguing that SASL negotiation could result
> in establishment of a further security layer
> that is bound to the TLS layer via channel binding, and that it is safe
> for the client to send plaintext credentials to the server only after
> channel binding has taken place. Correct?

I am assuming one either has a SASL negotiated security layer OR a securely bound lower-level channel (eg, TLS), not both.

In both cases, with the existing <transition-needed/> error, the SASL exchanged has failed, nothing is protected by the SASL exchange.  Which means there is no (new) SASL security layer and no channel binding.  So, if the user/client is relying on the SASL mechanism's mutual authentication, it needs to be extremely caution about what it does in response to that error.

By signaling the client that transition is needed in the new stream and performing the transition in that stream, we ensure that protections provided by any security layer or bound channel is in place.

While the attacker could just as well have attempted to get the client to do PLAIN by ensuring PLAIN is the only mechanism listed, a client might well caution that use of PLAIN is generally dangerous, most clients won't give a complain about the downgrade (because most clients don't remember last used mechanism).  By using <transition-needed/> error, the attacker likely can get the client to display specific noting the server has requested transition (hopefully with a warning about the possibility this could be spoofed, and PLAIN is dangerous.  Though I don't have a reference, I recall some claiming that users are more likely to click through the latter dialogs than the former. 

That is, <transition-needed/> spoofing may well be a more successful downgrade attack than SASL mechanism spoofing.

> If so, then we'd need to
> define a post-SASL protocol (that might include work on periodic
> re-authentication requests sent from server to client). But IMHO that
> work is out of scope for 3920bis. The question is: is it better to

> remove the <transition-needed/> SASL condition pending work on the
> future protocol extension?

I think the question can simple as simple as "Should <transition-needed/> be removed?".  I am fine with the question being viewed as "too late" to ask.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 2 Nov 2010 17:14:19 -0700

On Nov 2, 2010, at 3:19 PM, Peter Saint-Andre wrote:

> On 11/2/10 3:11 PM, Kurt Zeilenga wrote:
> 
>> I think the question can simple as simple as "Should
>> <transition-needed/> be removed?".  I am fine with the question being
>> viewed as "too late" to ask.
> 
> I don't think that folks in the WG would cry if the feature were
> removed, given that:
> 
> 1. It would be used rarely.
> 
> 2. No one has implemented it (AFAIK).
> 
> 3. The text provides many warnings about it.
> 
> 4. It supposedly opens up the possibility of downgrade attacks.
> 
> However, I still fail to see how <transition-needed/> is more evil than
> using SASL, at least if TLS is negotiated first (an attacker could just
> advertise the PLAIN mechanism over the TLS-protected stream, and if an
> attacker has so much control over the server that it can launch attacks
> after TLS has been negotiated then the client is in deep trouble anyway!).

I think you are considering the issue under a different assumptions than I.  I am assuming the user has clicked through any and all warnings they were faced with.  I am assuming the client did not well implement handling all cases.

For instance, if the user clicked said "connect anyways" to a certificate verification/subject check warning, a decent client would still warn if it previously used SCRAM-SHA1-PLUS and now is only getting SCRAM-SHA1 or just PLAIN, and warning about downgrade possibilities with transition-needed.  But far too often clients, not surprisingly, will assume that "connect anyways" means that TLS is good for purposes (e.g., server has been authenticated by the user by means outside the clients control) instead of "good enough for use with mechanisms that provide mutual authentication".  Of course, what the user meant was "just connect, damn it".

Our application protocol security designs are far too reliant on users making non-trival decisions, and far too complex for client developers to well implement.  (Such issues are certainly not limited to XMPP.)   We ought to design our protocols to avoid having to ask the user to make non-trival decisions, and simplify things the client developers as much possible (such as by ensuring key protocol bits are adequately protected from various attacks, instead of "TLS will save us").  And to make matters worse, we tend to repeat 'bad designs' (The transition-needed error in protocols has been a problem since introduced, as it never been protected by the SASL exchange.)

> Furthermore, I think that any client sophisticated enough to support
> <transition-needed/> is going to be sophisticated enough to support
> SCRAM-based mechanisms,

I disagree here.  A client developer is likely to implement transition-needed without at all thinking about the implications of whether "connect anyways" means "good enough for mechanism which provides server authentication and channel bindings" or simply "good enough for anything the server might ask us to do".  And, of course, the user just meant "I don't care about this" (but that doesn't mean the server operator does care).

Note that I don't mean to blame the user or the client developer here, I mean to blame the protocol designers for pushing these problems upon them.

> which means it can perform a further check to
> make sure that the server really is offering upgraded security
> mechanisms (likely, upgrading from DIGEST-MD5 to SCRAM-SHA-1) before
> sending the password in plaintext over the TLS-encrypted stream.

And if it notices an issue, what, prompt the user again?

> Another
> check: don't use <transition-needed/> more than once with any given XMPP
> service (once is enough!).

Once is enough?  I don't think so.

> And never send the plaintext password over an
> unprotected stream.

Ah, some will take "unprotected" to mean its okay to send the password over a stream so long as it has data integrity and data confidentiality protection.

That isn't enough.  One ought not send a plaintext password without server authentication (preferably that's bound to the protected stream end-point).  If the user may have intended to rely on SCRAM for server authentication, then just having TLS without any server authentication is not good enough.

> So IMHO we have a number of protections in place

The only protections we have assumption that TLS is used with client's authentication of the server.  That's a hell of an assumption with todays use of TLS on the Internet.   Certainly <transition-protected/> is not protected in XMPP use without TLS but with SASL security layers.

Of course, we also rely on this assumption to prevent downgrade via mechanism advertisements.  We really ought to do something about that as well.

> and
> that we can safely use the <transition-needed/> feature if we feel that
> we really need it.  The question is: do we really need it? We do want to
> encourage folks to migrate from DIGEST-MD5 (lots of interoperability
> issues) to SCRAM, and as part of that upgrade process XMPP services
> might need to collect the plaintext password just once.

Or again if they select SCRAM specific secrets and then realize they still need to support DIGEST-MD5.
Or they decide to move to some other password based mechanism and its mechanism specific secret.

It's not 'just once'.

> I'd rather have
> it done over the XMPP channel than, say, via an HTTPS web page (more
> phishing possibilities), but opinions might differ.

I rather have it done in a well-protected XMPP channel.   I don't consider the use transition-needed and TLS*+PLAIN as generally well protected.

(* TLS as often implemented and used on the Internet, e.g., without authentication).

> Feedback from our
> security reviewer and the Security ADs would be especially helpful.
> 
> All that having been said, if we're going to remove the feature then I
> think we need to make sure that the WG has consensus to do so.

Of course.

-- Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 Nov 2010 23:58:16 -0400

--On Tuesday, November 02, 2010 07:13:14 AM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

> Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it does
> offer good interoperability, it does good enough security for today's,
> and more importantly, tomorrow's Internet.
>
> I think we actually should be mandating a SCRAM-*-PLUS mechanism, because
> channeling bindings are really needed due to 'user click through' of TLS
> warnings, downgrade attack warnings, etc..   I do suspect that it will
> take time for this mechanism to be come ubiquitous, but I fear that
> without a MUST, it will never become ubiquitous.   But I do suspect well
> have multiple independently developed implementations of SCRAM-*-PLUS in
> XMPP within a few months of publication of this revision of XMPP.
>
> transition within the bound channel (e.g., today via XEP 77, tomorrow ?).

FWIW, I agree on all of these points.

-- Jeff

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 3 Nov 2010 08:02:22 -0700

On Nov 3, 2010, at 5:13 AM, Peter Saint-Andre wrote:
> You make a compelling argument. I wish you had made that argument months
> ago, but it is compelling.  Indeed, it leads in the direction of two
> consensus calls within the XMPP WG:
> 
> (a) to remove the <transition-needed/> SASL error condition
> 
> (b) to remove TLS plus SASL PLAIN as MTI for confidentiality and
> authentication
> 
> Ideally, both of those changes would be accompanied by additional
> security-related text, and in case (b) an interoperability note.

First, I note that (b) is a no-op in practice.  Implementations are going to support SASL PLAIN regardless.  Hell, we could even MUST NOT it and folks would still implement it.  It's simply too damn necessary for integration with 'legacy' password stores.  (I still rather we not MTI PLAIN.)

Second, (a) only removes one of two significant downgrade attack vectors, the other vector being the mechanisms advertisement and its handling.  (I still rather we remove it.)

While we can well craft our security warnings and considerations and guidance on how to use unauthenticated v. authenticated TLS and hope that client developers get it right.  Basically that text would say "use authenticated TLS" to protect against downgrade attack.  That sounds great but I doubt its going to have much effect (though I think it still should be said).  Clients are still going to offer user's security check bypasses and users are going to continue to take those bypasses.

Also as I noted previously, these problems are not unique to XMPP.  Instead of slowing down the publication of XMPP, it might be better to spin a more general effort to explore ways to address security issues due to general assumption that TLS will be used with server authentication when it is often used without server authentication, and more generally, explore ways to address the "user click through" problem (that is, how to secure protocols such that bypasses are less needed).

Lastly, please note that I don't consider this issue 'critical' at this point.  It's not going to be critical until such attacks are far more common place.  The best way to currently mitigate such attacks is to restrict the set of usable mechanisms to those immune to the attack.  (For enterprises which provide 'client builds' to their users, they can do this for their users as part of those builds.  But, in general, this requires user configuration and hence prone to failure.)

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 3 Nov 2010 14:03:42 -0700

On Nov 3, 2010, at 11:10 AM, Matthew Wild wrote:

> On 3 November 2010 17:31, Peter Saint-Andre <[email-masked]> wrote:
>> 
> 
>>      as described under Section 13.7.2.1 (however, the lack of channel
>>      binding in the PLAIN mechanism implies that even authenticated TLS
>>      cannot fully protect the SASL negotiation and subsequent
>>      communications when PLAIN is used).
>> 
> 
> I'm no expert on this, but is this text technically true? I thought
> channel binding would only be beneficial where there is not full TLS
> authentication.

Channel binding is beneficial regardless of whether there the client performed TLS server cert/subject checks.  Note that the server has no clue what checks, if any, the client (or its user) performed.  With channel bindings, it becomes irrelevant to the server whether the client performed these checks or not.  That is, (amongst other things) channel bindings provide a means for the server itself to protect against MITM attacks.

I do agree, however, that he wording of the however comment is confusing and seems should either be removed or replaced.

My main concern is that Unauthenticated TLS is subject to downgrade to PLAIN by two vectors, spoofing mechanisms and spoofing transition required.

Removing <transition-needed/> (in favor of a yet to be specified extension) addresses one vector.

There seems no good way to address the other vector at this time.  I do suggest however that the 13.9.4 text:
   To help prevent this attack, the parties
   SHOULD protect the channel using TLS before attempting SASL
   negotiation.
be replaced with:
   To mitigate this attack, the partied SHOULD protect the channel using TLS before attempting SASL negotiation and either
   perform full certificate validation as described in Section 13.7.2.1 or utilize a mechanism which provides channel bindings,
   such as SCRAM-SHA-1-PLUS. 

-- Kurt

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 04 Nov 2010 18:02:23 +0200

Hi Peter,

yes, these seem reasonable. Is there a "converse" to the rewriting of 
the client's From header before forwarding to other servers, i.e. is 
there a server-side check on stanza From headers received from other 
servers?

Thanks,
	Yaron

On 11/03/2010 11:41 PM, Peter Saint-Andre wrote:
> Hi Yaron, following up our discusion, here is proposed text for the
> conformance features you suggested...
>
> On 11/1/10 2:19 PM, Peter Saint-Andre wrote:
> I think we can combine client and server validation into two features
> (instead of four), one for TLS and one for SASL.
>
> The TLS feature would be:
>
>     Feature:  tls-correlate
>     Description:  When validating a certificate presented by a stream
>        peer during TLS negotiation, correlate the validated identity with
>        the 'from' address (if any) of the stream header it received from
>        the peer.
>     Section:  Section 13.7.2
>     Roles:  Client SHOULD, Server SHOULD.
>
> As a target for that pointer, I think we need to add the following
> paragraph to the end of Section 13.7.2 ("Certificate Validation"):
>
>     Once the identity of the stream peer has been validated, the
>     validating entity SHOULD also correlate the validated identity with
>     the 'from' address (if any; see Section 4.6.1) of the stream header
>     it received from the peer.  If the two identities do not match, the
>     validating entity SHOULD terminate the connection attempt.
>
> The SASL feature would be:
>
>     Feature:  sasl-correlate
>     Description:  When authenticating a stream peer using SASL, correlate
>        the authentication identifier resulting from SASL negotiation with
>        the 'from' address (if any) of the stream header it received from
>        the peer.
>     Section:  Section 6.4.6
>     Roles:  Client N/A, Server SHOULD.
>
> As a target for that pointer, I think we need to add the following
> paragraph to the beginning of Section 6.4.6 ("SASL Success"):
>
>     Before considering the SASL handshake to be a success, the receiving
>     entity SHOULD correlate the authentication identity resulting from
>     the SASL negotiation with the 'from' address (if any; see
>     Section 4.6.1) of the stream header it received from the initiating
>     entity.  If the two identities do not match, the receiving entity
>     SHOULD terminate the connection attempt.
>
> Finally, we need one more feature, for server stamping of client 'from'
> addresses:
>
>     Feature:  stanza-attribute-from-stamp
>     Description:  Stamp or rewrite the 'from' address of all stanzas
>        received from connected clients.
>     Section:  Section 8.1.2.1
>     Roles:  Client N/A, Server MUST.
>
> Let me know if those seem reasonable.
>
> Peter
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Nov 2010 20:59:06 -0600

On 11/1/10 2:57 PM, Dave Cridland wrote:
> I think SASL PLAIN should be specifying this. There's nothing special in
> XMPP which makes PLAIN a poor choice.

I disagree -- it's our job to specify how we use the tools we've been given.

> It's pretty scary itself, as it provides an easy path to a downgrade

If the stream is already TLS-protected, the attacker would need to have
control over the server (in which case the server wouldn't offer TLS in
the first place, of course). It seems to me that the client can take
appropriate protective measures to avoid this attack (just always force
TLS).

> But here's another compelling (in my view) reason to keep PLAIN, quoted
> from the opening lines of RFC 4616:
> 
> advising (and providing) better alternatives to cover other cases, seems
> to be the best choice for interoperability.

IMHO that's been the experience of the XMPP community so far.

As mentioned, I'll work to capture these considerations in proposed text.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Nov 2010 22:45:42 -0600

###

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Nov 2010 06:06:47 -0600

> MAY choose to fail". With possible minor exceptions, these rules are all

Very true. At the least, SHOULD is much more appropriate, and even then
there are, as you say, only some possible minor exceptions (which I
think are RECOMMENDED in the profile, e.g., including the address of an
OCSP responder).

> I also think it's a good idea.

It seems a bit late in this revision cycle to do that, but as mentioned
I think we'll be working on 3920ter after a year or more of experience
with the spec you've reviewed (and after we've had a chance to fix up
the address format based on the results of the PRECIS WG), so I think
that would be a good time to help ensure the longevity of the specs by
moving the MTI security technologies into a "living document". I don't
know if any other application protocols have done that, but I'll ask the
Security ADs for advice about how we might proceed when the time comes.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Nov 2010 06:12:21 -0600

Two points:

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Nov 2010 10:37:10 -0600

On 11/2/10 8:13 AM, Kurt Zeilenga wrote:
>> 1. Eventually, we should be able to drop PLAIN in a future revision
>> of the MTI technologies spec that we'll pull out of 3920bis in 1+
>> years.
> 
> Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it
> does offer good interoperability, it does [NOT offer] good enough security for
> today's, and more importantly, tomorrow's Internet.

IMHO the point of moving the MTI list out of the core spec is that we
can revise it more frequently. I think we'll be in a stronger position
to discard PLAIN once we have more SCRAM implementations in our world.

> I think we actually should be mandating a SCRAM-*-PLUS mechanism,
> because channeling bindings are really needed due to 'user click
> through' of TLS warnings, downgrade attack warnings, etc..   I do
> suspect that it will take time for this mechanism to be come
> ubiquitous, but I fear that without a MUST, it will never become
> ubiquitous.   But I do suspect well have multiple independently
> developed implementations of SCRAM-*-PLUS in XMPP within a few months
> of publication of this revision of XMPP.

I think the section on "Mandatory-to-Implement Technologies" is not
quite right, because it needs to say that SCRAM-SHA1-PLUS shall be
*implemented in code*:

###

   For authentication only, servers and clients MUST support the SASL
   Salted Challenge Response mechanism [SCRAM], in particular the SCRAM-
   SHA-1 variant and SCRAM-SHA-1-PLUS variant.

###

Whereas the section on "Use of SASL" specifies when those MTI variants
are actually *used in deployment* by software that implements it:

###

13.9.4.  Use of SASL

   [...]

   The SASL framework itself does not provide a method for binding SASL
   authentication to a security layer providing confidentiality and
   integrity protection that was negotiated at a lower layer (e.g.,
   TLS).  Such a binding is known as a "channel binding" (see
   [CHANNEL]).  Some SASL mechanisms provide channel bindings, which in
   the case of XMPP would typically be a binding to TLS (see
   [CHANNEL-TLS]).  If a SASL mechanism provides a channel binding
   (e.g., this is true of [SCRAM]), then XMPP entities using that
   mechanism SHOULD prefer the channel binding variant (e.g., preferring
   "SCRAM-SHA-1-PLUS" over "SCRAM-SHA-1").  If a SASL mechanism does not
   provide a channel binding, then the mechanism cannot provide a way to
   verify that the source and destination end points to which the lower
   layer's security is bound are equivalent to the end points that SASL
   is authenticating; furthermore, if the end points are not identical,
   then the lower layer's security cannot be trusted to protect data
   transmitted between the SASL-authenticated entities.  In such a
   situation, a SASL security layer SHOULD be negotiated that
   effectively ignores the presence of the lower-layer security.

###

it sounds worthy of discussion when we work on 3920ter. At this point I

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Nov 2010 14:17:25 -0600

> negotiated security layer.  It's prone to attack.  And the fix is the

What is the attack? If the client required negotiation of TLS before
moving on to SASL, the server has already authenticated to the client at
the stage. As I far as I understand, you are arguing that SASL
negotiation could result in establishment of a further security layer
that is bound to the TLS layer via channel binding, and that it is safe
for the client to send plaintext credentials to the server only after
channel binding has taken place. Correct? If so, then we'd need to
define a post-SASL protocol (that might include work on periodic
re-authentication requests sent from server to client). But IMHO that
work is out of scope for 3920bis. The question is: is it better to
remove the <transition-needed/> SASL condition pending work on the
future protocol extension?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Nov 2010 16:19:14 -0600

Furthermore, I think that any client sophisticated enough to support
<transition-needed/> is going to be sophisticated enough to support
SCRAM-based mechanisms, which means it can perform a further check to
make sure that the server really is offering upgraded security
mechanisms (likely, upgrading from DIGEST-MD5 to SCRAM-SHA-1) before
sending the password in plaintext over the TLS-encrypted stream. Another
check: don't use <transition-needed/> more than once with any given XMPP
service (once is enough!). And never send the plaintext password over an
unprotected stream. So IMHO we have a number of protections in place and
that we can safely use the <transition-needed/> feature if we feel that
we really need it. The question is: do we really need it? We do want to
encourage folks to migrate from DIGEST-MD5 (lots of interoperability
issues) to SCRAM, and as part of that upgrade process XMPP services
might need to collect the plaintext password just once. I'd rather have
it done over the XMPP channel than, say, via an HTTPS web page (more
phishing possibilities), but opinions might differ. Feedback from our
security reviewer and the Security ADs would be especially helpful.

All that having been said, if we're going to remove the feature then I
think we need to make sure that the WG has consensus to do so. I leave
that up to the chairs.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Campbell <[email-masked]>
Date: Tue, 2 Nov 2010 17:29:36 -0500

(as XMPP chair)

> think we need to make sure that the WG has consensus to do so. I leave

I concur that we need WG consensus to remove this. We can assume we had consensus for the feature to be there in the first place, since it was in the doc as pubreq'd.

Certainly the are room for changes due to post WG review without taking everything back to the WG. This seems to me to border on too big a change for that. It's no big deal to query the work group on it, if we see the need.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Nov 2010 06:13:43 -0600

On 11/2/10 6:14 PM, Kurt Zeilenga wrote:
>>> <transition-needed/> be removed?".  I am fine with the question
>>> being viewed as "too late" to ask.
>> 
>> However, I still fail to see how <transition-needed/> is more evil
>> than using SASL, at least if TLS is negotiated first (an attacker
>> could just advertise the PLAIN mechanism over the TLS-protected
>> stream, and if an attacker has so much control over the server that
>> it can launch attacks after TLS has been negotiated then the client
>> is in deep trouble anyway!).
> 
> I think you are considering the issue under a different assumptions
> than I.  I am assuming the user has clicked through any and all
> warnings they were faced with.  I am assuming the client did not well
> implement handling all cases.
> 
> For instance, if the user clicked said "connect anyways" to a
> certificate verification/subject check warning, a decent client would
> still warn if it previously used SCRAM-SHA1-PLUS and now is only
> getting SCRAM-SHA1 or just PLAIN, and warning about downgrade
> possibilities with transition-needed.  But far too often clients, not
> surprisingly, will assume that "connect anyways" means that TLS is
> good for purposes (e.g., server has been authenticated by the user by
> means outside the clients control) instead of "good enough for use
> with mechanisms that provide mutual authentication".  Of course, what
> the user meant was "just connect, damn it".
> 
> Our application protocol security designs are far too reliant on
> users making non-trival decisions, and far too complex for client
> developers to well implement.  (Such issues are certainly not limited
> to XMPP.)   We ought to design our protocols to avoid having to ask
> the user to make non-trival decisions, and simplify things the client
> developers as much possible (such as by ensuring key protocol bits
> are adequately protected from various attacks, instead of "TLS will
> save us").  And to make matters worse, we tend to repeat 'bad
> designs' (The transition-needed error in protocols has been a problem
> since introduced, as it never been protected by the SASL exchange.)
> 
>> Furthermore, I think that any client sophisticated enough to
>> support <transition-needed/> is going to be sophisticated enough to
>> support SCRAM-based mechanisms,
> 
> I disagree here.  A client developer is likely to implement
> transition-needed without at all thinking about the implications of
> whether "connect anyways" means "good enough for mechanism which
> provides server authentication and channel bindings" or simply "good
> enough for anything the server might ask us to do".  And, of course,
> the user just meant "I don't care about this" (but that doesn't mean
> the server operator does care).
> 
> Note that I don't mean to blame the user or the client developer
> here, I mean to blame the protocol designers for pushing these
> problems upon them.
> 
>> which means it can perform a further check to make sure that the
>> server really is offering upgraded security mechanisms (likely,
>> upgrading from DIGEST-MD5 to SCRAM-SHA-1) before sending the
>> password in plaintext over the TLS-encrypted stream.
> 
>> Another check: don't use <transition-needed/> more than once with
>> any given XMPP service (once is enough!).
> 
>> And never send the plaintext password over an unprotected stream.
> 
> Ah, some will take "unprotected" to mean its okay to send the
> password over a stream so long as it has data integrity and data
> confidentiality protection.
> 
> That isn't enough.  One ought not send a plaintext password without
> server authentication (preferably that's bound to the protected
> stream end-point).  If the user may have intended to rely on SCRAM
> for server authentication, then just having TLS without any server
> authentication is not good enough.
> 
> The only protections we have assumption that TLS is used with
> client's authentication of the server.  That's a hell of an
> assumption with todays use of TLS on the Internet.   Certainly
> <transition-protected/> is not protected in XMPP use without TLS but
> with SASL security layers.
> 
> Of course, we also rely on this assumption to prevent downgrade via
> mechanism advertisements.  We really ought to do something about that
> as well.
> 
>> and that we can safely use the <transition-needed/> feature if we
>> feel that we really need it.  The question is: do we really need
>> it? We do want to encourage folks to migrate from DIGEST-MD5 (lots
>> of interoperability issues) to SCRAM, and as part of that upgrade
>> process XMPP services might need to collect the plaintext password
>> just once.
> 
> Or again if they select SCRAM specific secrets and then realize they
> still need to support DIGEST-MD5. Or they decide to move to some
> other password based mechanism and its mechanism specific secret.
> 
> It's not 'just once'.
> 
>> I'd rather have it done over the XMPP channel than, say, via an
>> HTTPS web page (more phishing possibilities), but opinions might
>> differ.
> 
> I rather have it done in a well-protected XMPP channel.   I don't
> consider the use transition-needed and TLS*+PLAIN as generally well
> protected.
> 
>> Feedback from our security reviewer and the Security ADs would be
>> especially helpful.
>> 
>> All that having been said, if we're going to remove the feature
>> then I think we need to make sure that the WG has consensus to do
>> so.
> 
> Of course.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Nov 2010 11:31:45 -0600

On 11/3/10 9:02 AM, Kurt Zeilenga wrote:
>> You make a compelling argument. I wish you had made that argument
>> months ago, but it is compelling.  Indeed, it leads in the
>> direction of two consensus calls within the XMPP WG:
>> 
> First, I note that (b) is a no-op in practice.  Implementations are
> going to support SASL PLAIN regardless.  Hell, we could even MUST NOT
> it and folks would still implement it.  It's simply too damn
> necessary for integration with 'legacy' password stores.  (I still
> rather we not MTI PLAIN.)

This is true.

> Second, (a) only removes one of two significant downgrade attack
> vectors, the other vector being the mechanisms advertisement and its
> handling.  (I still rather we remove it.)

We're not about to get rid of mechanisms advertisement, given that it's
what enables us to do SASL authentication in the first place. :)

However, <transition-needed/> is new in 3920bis and it's better to
remove it now than to encourage software to implement it, only to remove
it in a few years.

> While we can well craft our security warnings and considerations and
> guidance on how to use unauthenticated v. authenticated TLS and hope
> that client developers get it right.  Basically that text would say
> "use authenticated TLS" to protect against downgrade attack.  

And we already say that.

> That
> sounds great but I doubt its going to have much effect (though I
> think it still should be said).  Clients are still going to offer
> user's security check bypasses and users are going to continue to
> take those bypasses.

Also true.

> Also as I noted previously, these problems are not unique to XMPP.
> Instead of slowing down the publication of XMPP, it might be better
> to spin a more general effort to explore ways to address security
> issues due to general assumption that TLS will be used with server
> authentication when it is often used without server authentication,
> and more generally, explore ways to address the "user click through"
> problem (that is, how to secure protocols such that bypasses are less
> needed).

That does sound like a worthy effort. It might intersect with the WEBSEC WG.

> Lastly, please note that I don't consider this issue 'critical' at
> this point.  It's not going to be critical until such attacks are far
> more common place.  The best way to currently mitigate such attacks
> is to restrict the set of usable mechanisms to those immune to the
> attack.  (For enterprises which provide 'client builds' to their
> users, they can do this for their users as part of those builds.
> But, in general, this requires user configuration and hence prone to
> failure.)

OK, so here is one path forward:

(a) Remove <transition-needed/> because it opens a hole that wasn't open
with RFC 3920 and doesn't need to be opened now.

(b) Remove TLS plus SASL PLAIN as mandatory-to-implement for the same
reason (note that it was not mandatory-to-implement in RFC 3920).

As previously mentioned, I think we also need to update the relevant
part of the security considerations -- here is proposed text:

###

   For both confidentiality and authentication with passwords, servers
   and clients MUST implement TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
   ciphersuite plus SASL SCRAM, in particular the SCRAM-SHA-1 and SCRAM-
   SHA-1-PLUS variants.

      Interoperability and Security Note: In practice, when SCRAM is not
      available, typically servers and clients use TLS plus SASL PLAIN.
      The SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants of the SCRAM
      mechanism are strongly preferred over the PLAIN mechanism because
      of their vastly superior security properties (including the
      ability to enforce channel binding as described under
      Section 13.9.4).  Although in certain deployment scenarios it can
      be difficult for a server to offer SCRAM-based mechanisms (e.g.,
      because the XMPP service depends for authentication purposes on a
      database or directory that is not under the control of the XMPP
      administrators), in general implementations SHOULD treat TLS plus
      SASL PLAIN as a technology of last resort when interacting with
      implementations that do not yet support SCRAM; in particular, a
      client MUST prefer more secure mechanisms (e.g., SCRAM-SHA-1,
      SCRAM-SHA-1-PLUS, and EXTERNAL) to the PLAIN mechanism and MUST
      NOT use the PLAIN mechanism without at a minimum confidentiality
      and integrity protection via TLS with full certificate validation
      as described under Section 13.7.2.1 (however, the lack of channel
      binding in the PLAIN mechanism implies that even authenticated TLS
      cannot fully protect the SASL negotiation and subsequent
      communications when PLAIN is used).

###

I have no great love for <transition-needed/> or SASL PLAIN, and given
that they were not mentioned or encouraged in RFC 3920 I see no strong
reason to add them in 3920bis. Yes, PLAIN will be used in the short run
and it is helpful to document that fact for interoperability purposes,
but hopefully we can move away from PLAIN with all due speed by
encouraging the use of SCRAM and of EXTERNAL with client certificates.

If the chairs are willing, I would like to request a consensus call on
(a) and (b), based on feedback received during the security review.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Campbell <[email-masked]>
Date: Wed, 3 Nov 2010 12:39:52 -0500

(as chair)

On Nov 3, 2010, at 12:31 PM, Peter Saint-Andre wrote:

> If the chairs are willing, [...]

No objection to the consensus call from me, at least

> I would like to request a consensus call on

I think you just did :-)

---

From: Matthew Wild <[email-masked]>
Date: Wed, 3 Nov 2010 18:10:25 +0000

On 3 November 2010 17:31, Peter Saint-Andre <[email-masked]> wrote:

I'm not going to weigh in on the to-MTI/to-not-MTI issue... it's not
going to affect anything either way. There are deployment scenarios
where PLAIN is necessary, and as far as I'm aware it is quite safe
with full TLS verification/authentication. I think Kurt is mainly
arguing that in practice TLS is rarely fully verified. However this is
a deployment issue, and has no bearing on the protocol - though were
we to MTI for interop reasons we should of course strongly stress the
importance of TLS being fully verified when using PLAIN.

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Nov 2010 15:41:28 -0600

Feature:  tls-correlate

   Feature:  sasl-correlate

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Nov 2010 15:53:30 -0600

On 11/3/10 3:03 PM, Kurt Zeilenga wrote:
>>> as described under Section 13.7.2.1 (however, the lack of
>>> channel binding in the PLAIN mechanism implies that even
>>> authenticated TLS cannot fully protect the SASL negotiation and
>>> subsequent communications when PLAIN is used).
>>> 
>> 
>> I'm no expert on this, but is this text technically true? I
>> thought channel binding would only be beneficial where there is not
>> full TLS authentication.
> 
> Channel binding is beneficial regardless of whether there the client
> performed TLS server cert/subject checks.  Note that the server has
> no clue what checks, if any, the client (or its user) performed.
> With channel bindings, it becomes irrelevant to the server whether
> the client performed these checks or not.  That is, (amongst other
> things) channel bindings provide a means for the server itself to
> protect against MITM attacks.
> 
> I do agree, however, that he wording of the however comment is
> confusing and seems should either be removed or replaced.

Removed in my working copy.

> My main concern is that Unauthenticated TLS is subject to downgrade
> to PLAIN by two vectors, spoofing mechanisms and spoofing transition
> required.
> 
> There seems no good way to address the other vector at this time.  I
> do suggest however that the 13.9.4 text: To help prevent this attack,
> the parties SHOULD protect the channel using TLS before attempting
> SASL negotiation. be replaced with: To mitigate this attack, the
> partied SHOULD protect the channel using TLS before attempting SASL
> negotiation and either perform full certificate validation as
> described in Section 13.7.2.1 or utilize a mechanism which provides
> channel bindings, such as SCRAM-SHA-1-PLUS.

Text incorporated, with minor tweaks.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 04 Nov 2010 21:41:32 +0100

> there a server-side check on stanza From headers received from other

Yes, see 8.1.2.2. Server-to-Server Streams (or search for the associated 
invalid-from stream error).

---

From: "Peter Saint Andre" <[email-masked]>
Date: Fri, 5 Nov 2010 06:54:50 -0700

Yes, it would be good to add a conformance feature for that one, too.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Nov 2010 03:45:01 +0800

Never mind, we already have that:

   Feature:  stanza-attribute-from-validate
   Description:  Validate the 'from' address of all stanzas received
      from a peer servers.
   Section:  Section 8.1.2.2
   Roles:  Client N/A, Server MUST.

Issue closed. :)

On 11/5/10 9:54 PM, Peter Saint Andre wrote:
> ----- Original Message ----- From: Philipp Hancke
> <[email-masked]> To: Yaron Sheffer <[email-masked]> 
> Cc: Peter Saint-Andre <[email-masked]>;
> [email-masked]
> <[email-masked]>; [email-masked]
> <[email-masked]>; XMPP <[email-masked]>; [email-masked]
> <[email-masked]> Sent: Thu Nov 04 13:41:32 2010 Subject: Re: [xmpp]
> SecDir review of draft-ietf-xmpp-3920bis-17
> 
> Yaron Sheffer wrote:
>> Hi Peter,
>> 
>> yes, these seem reasonable. Is there a "converse" to the rewriting
>> of the client's From header before forwarding to other servers,
>> i.e. is there a server-side check on stanza From headers received
>> from other servers?
> 
> Yes, see 8.1.2.2. Server-to-Server Streams (or search for the
> associated invalid-from stream error).