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

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

Hi Peter,

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

Thanks,
	Yaron

On 10/29/2010 08:32 PM, Peter Saint-Andre wrote:
> This is Part 2 of my reply, from the start of Section 5 through the end
> of Section 9. I should be able to address the remainder (Section 10
> through Section 15) in Part 3.
>
> On 10/28/10 4:28 AM, Yaron Sheffer wrote:
>
>> - 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. :)
>
I accept your reasoning. And servers in most cases can take the risk of 
information disclosure and still use mutual cert authentication.

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

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.

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

Yes, it makes sense to switch #4 and #5. BTW, you meant 5.4.3.1.
>
> Also, the bullet about validation probably also needs to say that if the
> initiating entity presents a certificate then the receiving entity needs
> to also perform validation. Do you agree?

Yes, this is the basic case, of course it should be mentioned.
>
>> - 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.
>
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.

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

Yes, SHOULD NOT would be BETTER...
>
>> - 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?
>
What triggered my comment was the name of this element, "not 
authorized". Both of your examples are (broadly speaking), "not 
authenticated". What about the same service, where I am duly 
authenticated as Yaron, but still am not allowed to use the service, 
e.g. because only users belonging to the all-saints group are allowed to 
it. This would be a true authorization failure.

>
>> - 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.
>
I would appreciate a pointer to benefit the uninitiated.

---

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

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

> browsers) and therefore prohibiting SSLv3 would be reasonable. If 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.

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

> Yes, SHOULD NOT would be BETTER...

Done.

> authorized". 

We inherited that from HTTP 401 "Unauthorized".

> Both of your examples are (broadly speaking), "not

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.

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

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

      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.  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
      strongly preferred over the SASL PLAIN mechanism because of their
      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

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

---

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

On 11/2/10 5:10 AM, Yaron Sheffer wrote:
> 
> On 11/01/2010 10:19 PM, Peter Saint-Andre wrote:
> 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.

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

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

On 11/2/10 5:20 AM, Yaron Sheffer wrote:
> I'm OK with this text, including (sigh) PLAIN.

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.

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

Peter

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

---

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

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

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

###

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

Peter

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

---

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:

> 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

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: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Nov 2010 14:17:25 -0600

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

> What is the attack?

> If the client required negotiation of TLS before
> 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
> 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

> 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: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Nov 2010 16:19:14 -0600

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

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: Kurt Zeilenga <[email-masked]>
Date: Tue, 2 Nov 2010 17:14:19 -0700

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

> 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
> sending the password in plaintext over the TLS-encrypted stream.

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

> Another
> 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
> 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
> 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
> think we need to make sure that the WG has consensus to do so.

Of course.

-- Kurt

---

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

Yes, definitely.

---

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

---

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.

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.

Peter

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

---

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

> 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: 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: 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: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Nov 2010 12:09:03 -0600

(trimming to the XMPP WG list, changing the subject)

>> (a) and (b), based on feedback received during the security review.

Heh, OK. Usually I would defer to the chairs for issuance of a call for
consensus, but since you've said it's OK, here goes...

In case WG folks have tuned out list discussion related to the security
review (and do refer to the preceding messages for the full context!), I
would like to request a call for consensus on the following changes to
draft-ietf-xmpp-3920bis:

(a) Remove the <transition-needed/> SASL error condition, 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 a mandatory-to-implement security
technology, for the same reason (note that it was not
mandatory-to-implement in RFC 3920).

Please reply by 23:59 UTC on Wednesday, November 10, since that will
enable me to submit a revised I-D during the IETF meeting next week.

Thanks!

Peter

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

---

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:

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

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: Kurt Zeilenga <[email-masked]>
Date: Wed, 3 Nov 2010 14:03:42 -0700

> channel binding would only be beneficial where there is not full TLS

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: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Nov 2010 15:41:28 -0600

Hi Yaron, following up our discusion, here is proposed text for the
conformance features you suggested...

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

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

-- 
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: "Dave Cridland" <[email-masked]>
Date: Wed, 03 Nov 2010 23:10:31 +0000

------- Original message -------
> From: Peter Saint-Andre <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Sent: 3/11/'10,  18:17
>

I see no reason to retain this unless - perhaps - there is demonstrated 
client support.

> mandatory-to-implement in RFC 3920).

I think for interop it needs to be MTI at least in clients. It can be 
reduced to a SHOULD in servers.

---

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

---

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: Joe Hildebrand <[email-masked]>
Date: Fri, 05 Nov 2010 06:14:40 +0800

(as individual)

> I see no reason to retain this unless - perhaps - there is demonstrated

I doubt there's been much client implementation of this yet, so I don't
think removing it for now breaks anything.

> reduced to a SHOULD in servers.

MUST in clients, SHOULD or even MAY in servers.  Seems like a good
compromise.

-- 
Joe Hildebrand

---

From: Kevin Smith <[email-masked]>
Date: Fri, 5 Nov 2010 13:20:43 +0000

> think removing it for now breaks anything.

My understanding is that this was added into 3920bis for completeness,
without any deployment experience in the community. I'm in favour of
removing it.

> MUST in clients, SHOULD or even MAY in servers.  Seems like a good

My understanding of this is that it was added to 3920bis after much
deployment experience in the community showed that it was necessary
for interop. I'm in favour of MUST for clients. For servers I could be
talked in most directions - but I think what's generally important
there is that there's a sensible MTI that's common for clients and
servers and SCRAM is currently serving that purpose in bis; SHOULD is
where I'd currently lean.

/K

---

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: Matthew Wild <[email-masked]>
Date: Fri, 5 Nov 2010 13:58:03 +0000

>> I see no reason to retain this unless - perhaps - there is demonstrated

Agreed.

> MUST in clients, SHOULD or even MAY in servers.  Seems like a good

Agreed.

I didn't know consensus calls were so effective :)

Matthew

---

From: Remko Tronçon <[email-masked]>
Date: Fri, 5 Nov 2010 15:59:52 +0100

> (a)

Dito, can be removed.

Agreed.

cheers,
Remko

---

From: Florian Zeitz <[email-masked]>
Date: Sat, 06 Nov 2010 14:50:24 +0100

> without any deployment experience in the community. I'm in favour of
+1

> where I'd currently lean.
I agree with that assessment MUST in clients and SHOULD in servers
sounds fine.

However one comment since this came out of a security discussion:
The real security gain would be if clients could refuse to use PLAIN, a
MITM can spoof mechanisms whether the server does PLAIN or not,
therefore this change is IMHO somewhat cosmetic as far as security gain
goes.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 06 Nov 2010 08:00:51 -0600

>> without any deployment experience in the community. I'm in favour of

It seems we have pretty strong agreement on that point.

> therefore this change is IMHO somewhat cosmetic as far as security gain

Agreed, it's the client that needs to be careful here, so we need
appropriate text. I think we can use what I sent a few days ago as a
starting point.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 7 Nov 2010 20:26:51 +0900

Hi,

> It seems we have pretty strong agreement on that point.

I agree too.

> appropriate text. I think we can use what I sent a few days ago as a

That was not MTI in RFC3920, so why would we add this constraint now
which would make it a security burden for lot lot of years from now? I
agree it is much deployed right now, and for this reason we should not
just wipe out such technology, but it does not mean we should make it
a mandatory one.

I would suggest a SHOULD or MIGHT for both clients and servers,
accompanied by an informational note about the fact that it is
currently widely implemented as well as security considerations. For
the short term, it would have probably the same consequences than a
MUST (developers will implement it in order to keep compatibility with
older implementations), with the difference that (not being a MTI) it
won't be a burden to carry for the long term and would probably fade
out with time.

On the security side, I don't agree with the fact this is a cosmetic
security change. We are still removing one layer of security here,
because it means that if a MITM can pass somehow the TLS security, and
if the client accept TLS + PLAIN, then the MITM attacker simply has to
propose only SASL PLAIN for identification to access unencrypted
passwords. With TLS + SCRAM, the attacker may be able to make a single
connection, but at least won't collect the current password (at least
not this way, because I agree that if the server store unencrypted
passwords, and proposes for instance to retrieve the user password
with ad-hoc commands — which is a very bad idea and a security flaw,
according to me —, he might be able to), which we know is a more
serious issue than simply impersonating one single connection (as
users often use the same passwords on many services, so an attacker
may access more than just the XMPP server; also the attacker will be
able to do as many connections as he wish later as he has the actual
password instead of a salted one; and so one).

This is saying TLS is breakable, but that's still a risk and an
additional weakness we can avoid.
And this is all even more true because many servers out-there are self
authenticated. And as we know, a TLS connection made with a bad
certificate cannot be trusted at all. Yet most clients will
unfortunately just ignore this security breach (considering the
current sad state of our park of network's certificates) and would
send clear passwords with SASL PLAIN through such an unsecure canal (I
also remind that SCRAM provides also server authentication, weaker
than TLS but still a nice addition inside an unsecure TLS canal as we
see a lot in our network).
So no really if we can avoid it: TLS + PLAIN should not be a mandatory
to implement technology. Keeping it a MIGHT + informational note on
our current XMPP park is preferred here.

I seem to be the only one to think so for now, but I still give my
opinion about this.
Bye.

Jehan

---

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

---

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

>> It seems we have pretty strong agreement on that point.

OK, I have scrubbed <transition-needed/> from my working copy. If anyone
has objections, please speak up.

I'll reply seperately about TLS + SASL PLAIN.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Nov 2010 04:27:05 +0800

[trimming the subject to SASL PLAIN]

On 11/7/10 7:26 PM, Jehan Pagès wrote:

>> Agreed, 

To be clear, when I said "agreed" I was agreeing with Florian about the
security issue, not necessarily about including TLS + SASL PLAIN as a
mandatory-to-implement technology.

>> it's the client that needs to be careful here, so we need

As a reminder, here's the text I sent:

###

###

> won't be a burden to carry for the long term and would probably fade

Can you suggest modifications to the text I posted above?

> I seem to be the only one to think so for now, but I still give my

Well, Kurt agrees with you since he brought this up in the first place.

My opinion is that we don't need to use conformance language (MUST or
SHOULD) with regard to TLS + SASL PLAIN. Yes, we know that many clients
and servers implement it, and we know that it's commonly used in
deployment, but that doesn't mean we need to tell developers that they
MUST or SHOULD implement it.

For comparison, we don't say that servers MUST or SHOULD implement
Server Dialback (XEP-0220), and in practice that's much more necessary
to establish s2s connections than SASL PLAIN is necessary to establish
c2s connections. Here's our interoperability note on that topic:

      * Interoperability Note: At the time of writing, most deployed
      servers use the Server Dialback protocol [XEP-0220] to provide
      weak identity verification instead of using SASL to provide strong
      authentication, especially in cases where SASL negotiation would
      not result in strong authentication anyway (e.g., because TLS
      negotiation was not mandated by the peer server, or because the
      PKIX certificate presented by the peer server during TLS
      negotiation is self-signed and has not been previously accepted);
      for details, see [XEP-0220].  The solutions specified in this
      document offer a significantly stronger level of security (see
      also Section 13.6).

The note I posted above about SASL PLAIN serves much the same purpose:
we put developers on notice that in practice they will probably want to
implement SASL PLAIN so that they can maximize the potential for
connecting to a server, but we don't make this a conformance issue
(instead leaving the implementation and deployment decisions up to the
best judgment of developers and service operators).

So: how is SASL PLAIN any different from Server Dialback with regard to
conformance?

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Mon, 8 Nov 2010 21:03:36 +0000

2010/11/8 Peter Saint-Andre <[email-masked]>:
> c2s connections.

The difference here is that dialback is not needed for interop,
deployments can always choose to use TLS + EXTERNAL. The reason I
think PLAIN should be MUST for clients is that it *is* needed for
interop, as there are plenty of situations where SCRAM isn't an
option.

/K

---

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

> interop, as there are plenty of situations where SCRAM isn't an

By which you mean that a service admin always *could* deploy a cert,
they're just too lazy?

Possible counter-argument: large hosting services in which it's quite
impractical to deploy one certificate that contains entries for 10,000
hosted domains.

Peter

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

---

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

> impractical to deploy one certificate that contains entries for  

No, they could obtain 10,000 certificates, and present the "right"  
one.

This might not be desirable, but it's entirely possible.

On the other hand, it's simply impossible in some deployments to  
offer SCRAM - PLAIN's the only thing that'll work.

FWIW, I'd argue that we should be marking XEP-0220 at the SHOULD  
level anyway, I was just pointing out your counter-argument is flawed.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Nov 2010 05:25:55 +0800

On 11/9/10 5:17 AM, Dave Cridland wrote:
> No, they could obtain 10,000 certificates, and present the "right" one.
> 

At what expense?

> On the other hand, it's simply impossible in some deployments to offer
> SCRAM - PLAIN's the only thing that'll work.

Really? Isn't that, too, a deployment decision? Couldn't the operator
replicate the authentication database so that the XMPP server has access
to credentials in a form that enables the use of SCRAM?

> FWIW, I'd argue that we should be marking XEP-0220 at the SHOULD level
> anyway, 

That would require us to document TLS + Server Dialback, I think.

> I was just pointing out your counter-argument is flawed.

You were pointing out that you think my counter-argument is flawed. :)

Peter

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

---

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

> > This might not be desirable, but it's entirely possible.
That's irrelevant - we're talking about the possible versus the  
impossible. Besides, it'll be the same cost per domain, presumably,  
no matter the numbers of domains, and that cost could be zero.

> offer
No. If the credentials are in the form of a hash (one, presumably,  
incompatible with SCRAM), the operator does not have access to the  
credentials, and can only verify a supplied password against them.

To give a concrete example, a deployment which authenticates via  
ActiveDirectory will have to authenticate clients either using  
Kerberos V (via GSSAPI), possibly NTLM, or PLAIN. SCRAM is not an  
option, without mandating a password change (ie, transition-needed),  
and even if we were to go that route, we'd only be requiring PLAIN  
via another route.

> level
No, I don't think so. But in any case, I don't see how to phrase this  
that doesn't either invalidate the security offered by S2S TLS, or  
introduce dialback-without-dialback, which seems to confuse lots of  
people.

> You were pointing out that you think my counter-argument is flawed.  

Yes, but you think my thinking that your counter-argument is flawed  
is flawed - but that thinking's flawed.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Nov 2010 06:14:42 +0800

On 11/9/10 5:58 AM, Dave Cridland wrote:
> impossible. Besides, it'll be the same cost per domain, presumably, no
> matter the numbers of domains, and that cost could be zero.

I meant the administrative cost, not the cost of purchasing certificates
(since certs can be sourced at no cost).

> ActiveDirectory will have to authenticate clients either using Kerberos
> V (via GSSAPI), possibly NTLM, or PLAIN. SCRAM is not an option, without
> mandating a password change (ie, transition-needed), and even if we were
> to go that route, we'd only be requiring PLAIN via another route.

Thanks for the explanation.

What I'm saying is that an XMPP service could make other deployment
decisions. It doesn't *have* to authenticate via ActiveDirectory. That's
a matter of local service policy.

> that doesn't either invalidate the security offered by S2S TLS, 

Probably right.

> or
> introduce dialback-without-dialback, which seems to confuse lots of people.

Indeed!

> Yes, but you think my thinking that your counter-argument is flawed is
> flawed - but that thinking's flawed.

:)

---

From: Justin Karneges <[email-masked]>
Date: Mon, 8 Nov 2010 14:26:58 -0800

On Monday 08 November 2010 14:14:42 Peter Saint-Andre wrote:
> >> >> >> Server Dialback (XEP-0220), and in practice that's much more
> >> 
> >> necessary
> >> 
> >> >> >> to establish s2s connections than SASL PLAIN is necessary to
> >> 
> >> establish
> >> 
> >> >> >> c2s connections.
> >> >> > 
> >> >> impractical to deploy one certificate that contains entries for
> >> >> 10,000 hosted domains.
> >> > 

As long as the configurations for each virtual host are managed by individual 
users (domain owners), then I don't think there is much administrative cost to 
the hosting provider.  Even bargain-bin HTTP hosting providers allow users to 
set certificates.

If I personally owned 10,000 domains and certificates, well that sounds like 
hell. :)

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Nov 2010 08:52:18 +0800

> a matter of local service policy.

Well, *assuming* that you're right, I think we wouldn't need to change
the existing note very much...

###

   In addition, servers and clients SHOULD implement TLS with the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN.

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

###

Thoughts?

/psa

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 9 Nov 2010 13:29:44 +0900

Hi,

On Tue, Nov 9, 2010 at 6:58 AM, Dave Cridland <[email-masked]> wrote:
> ActiveDirectory will have to authenticate clients either using Kerberos V
> (via GSSAPI), possibly NTLM, or PLAIN. SCRAM is not an option, without
> mandating a password change (ie, transition-needed), and even if we were to
> go that route, we'd only be requiring PLAIN via another route.
>

Ok so let's say that we want to use SCRAM, this does not have to be
immediate. Moreover the transition can actually be transparent. For
instance if the user has to use PLAIN, then the server has access for
a short time to the password. Even though it won't store it like this,
it can still compute from it the StoredKey and ServerKey for SCRAM.
Then for the next connection, it will be able to propose SCRAM to this
user without this one having to ever ask him to change his password.

We don't say that the changes must be done suddenly for all existing
implementations. That's impossible anyway and we have to accept the
latency. But we still need to initiate the change if we ever want it
to happen. And saying TLS + PLAIN is a MTI is not initiating any
change, worse it is creating a burden on us, as for security at least.

Jehan

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 9 Nov 2010 14:04:56 +0900

Hi,

[...]
> mandatory-to-implement technology.

Ok.

>      communications when PLAIN is used).

Ok I might be lagging a bit, but where do I find this version of the
text? The last version I know is 3920bis-18 and I don't see any -19.

Actually this text seems already pretty nice. In particular we already
unset TLS + PLAIN from being a MTI, with good warning on its security
issues (while still stating that many implementations use it though).

> Can you suggest modifications to the text I posted above?

As I was saying, TLS + PLAIN is already not a MTI anymore in this text
you posted above, nor it has any kind of recommendation (like "MIGHT"
or "SHOULD"), and it has the warning text about its current use in the
XMPP part as well as security issues, so this is good like this as far
as I read it now. I will re-read it later with a new eye to be sure,
but seems good.

> Well, Kurt agrees with you since he brought this up in the first place.

Yes indeed. I was refering to responses between your call and my own
response. But you are right. :-)

> MUST or SHOULD implement it.

Actually I really like this approach. Simply stating a fact (many
implementations currently support TLS + PLAIN), but not giving any
recommendation with conformance language. That's far better than the
MIGHT/SHOULD solution.

And I definitely prefer the text with this logic that the one you
posted a few hours ago, adding TLS+PLAIN as SHOULD-Implement
technologies. Actually if we ever "had to" use the conformance
language, I would use a "MIGHT" to say "it is not wrong to support
PLAIN for interoperability" rather than a "SHOULD" which is still a
very strong recommendation (some people even consider that a really
conformant implementation is one with all the SHOULD. So SHOULDs in
this optic are MUSTs, so that's not good for me, here).

See you.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 05:59:44 +0800

> text? The last version I know is 3920bis-18 and I don't see any -19.

I will publish -19 once we've finished this discussion on the list,
which I hope we can do Real Soon Now. I posted that text earlier in this
thread.

> issues (while still stating that many implementations use it though).

That was the idea.

> as I read it now. I will re-read it later with a new eye to be sure,

Super.

> this optic are MUSTs, so that's not good for me, here).

BTW, in RFC 2119 it is "MAY", not "MIGHT". But "might" captures the idea
behind MAY: the feature is truly optional, you might implement it if you
so please (and there might even be good reasons to do so) but it's all
up to you. Whereas SHOULD means "we'd call it a MUST except that in a
few well-defined circumstances it might not be a appropriate" or (which
I see as equivalent) "you really really need to support this feature
unless have an awfully good reason not to!"

Also remember that this is about *implementation* in software, not
*deployment* in a particular service.

So do we want to tell client and server developers that they really
really need to support SASL PLAIN unless they have an awfully good
reason not to -- that we'd say you MUST implement it except that in a
few well-defined circumstances it might not be appropriate?

I don't think so. It's difficult for me to see how we can honestly
include such text in the spec, including a description of those few
well-defined circumstances in which SASL PLAIN not appropriate at the
implementation level (say, a constrained device that simply doesn't have
the ability to perform certain cryptographic operations). Instead, we
seem to have a few well-defined deployment scenarios in which TLS plus
SASL PLAIN actually *is* appropriate. And that leads me to think it's
most likely a MAY, most likely not a SHOULD, and certainly not a MUST.
But we already say that implementations MAY implement any SASL mechanism
that's not listed in this section. So in fact there's no need for
additional text at all, except that we think an interoperability note is
in order because server code might be deployed in scenarios where the
service needs to offer SASL PLAIN over TLS, and clients might try to
connect to deployed services that are constrained in that way. But in
general that's a deployment issue and does not rise to the level of a
strong recommendation that we can make in the spec.

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Tue, 09 Nov 2010 22:17:46 +0000

> few well-defined circumstances it might not be appropriate?

The point you failed to mention about RFC 2119 language is:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm

And what we're saying is that servers - for reasons which are most  
certainly outside the control of the client - may be unable to offer  
anything but PLAIN. A client which does not implement PLAIN will,  
therefore, fail to interoperate with such servers. It may be  
acceptable, or even desirable, for a client to behave in this way,  
for example if the client is marketed as being highly secure, but  
this will have an effect on interoperability, and as such is a  
trade-off.

The fact that a client which doesn't implement PLAIN will often work  
fine allows me to be persuaded that a SHOULD (on clients) is  
sufficient - a client failing to implement PLAIN will suffer interop  
failure on occasion, but in many cases it'll be fine. (I would note  
that a client failing to implement either PLAIN or GSSAPI is likely  
to fail to operate in most enterprise deployments, however).

The fact that the deployment case is controlled by the server  
suggests that for servers, PLAIN is truly optional, and I'm willing  
to drop the requirement on servers.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 06:46:30 +0800

> The point you failed to mention about RFC 2119 language is:

I prefer "neglected" to "failed". Heinlein's Razor and all that.

>   and sparingly. 

Well, 3920bis is absolutely packed with imperatives. I realize that's
not your style, but it seems to be mine (based in part on my experience
with implementers, who blithely ignore even the strongest SHOULD).

> In particular, they MUST only be used where it is
> therefore, fail to interoperate with such servers. It may be acceptable,
> or even desirable, for a client to behave in this way, for example if
> the client is marketed as being highly secure, but this will have an
> effect on interoperability, and as such is a trade-off.
> 
> fine allows me to be persuaded that a SHOULD (on clients) is sufficient
> - a client failing to implement PLAIN will suffer interop failure on
> occasion, but in many cases it'll be fine. (I would note that a client
> failing to implement either PLAIN or GSSAPI is likely to fail to operate
> in most enterprise deployments, however).
> 
> The fact that the deployment case is controlled by the server suggests
> that for servers, PLAIN is truly optional, and I'm willing to drop the
> requirement on servers.

Does "required for interoperation" mean "required for interoperation in
all possible deployment scenarios"? If so, then as you note a client
might need to implement SASL EXTERNAL, GSSAPI (Kerberos), DIGEST-MD5
(still lots of deployment), etc. It seems silly to say that all of those
are mandatory to implement. Better, I think, to note the reality of
deployment on the network and enable client developers to make the most
appropriate implementation decisions based on the deployment
environments in which they expect their clients to be used.

The text you've quoted refers to imperatives. Although RFC 2119 does not
specify which keywords are imperative, in general an imperative is a
command or exhortation. Thus, IMHO, "MAY" is not an imperative, whereas
SHOULD is an exhortation (i.e., an instance of emphatic urging) and MUST
is a command (i.e., an authoritative order).

Now let's look at the other branch of the quoted text: "to limit
behavior which has potential for causing harm". We've established that
TLS plus SASL PLAIN has the potential for causing harm, right? Although
I am far from an advocate of the precautionary principle, and there is
always the potential for harm no matter what we say or do, it seems that
there's more potential for harm in using SASL PLAIN over TLS than there
is in being prevented from connecting to a given service.

What I get from "clients SHOULD implement SASL PLAIN" is "clients really
really need to support SASL PLAIN unless they have a good reason to do
so -- like, say, offering an acceptable level of security to their users".

So the real question is: what's an acceptable level of security? Do we
have enough confidence in TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
ciphersuite (and proper certificate validation and so on) to think that
it's OK to send plaintext credentials over such a channel? That seems to
be a topic on which folks in the security directorate could provide
useful input, because I don't know if we have enough expertise in the
XMPP WG to say.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 07:10:09 +0800

> useful input, because I don't know if we have enough expertise in the

And while we're quoting chapter and verse from RFC 2119, consider the
description of "MAY" from that document:

   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

By your description, XMPP services that "require" GSSAPI (Kerberos) are
part of a "particular marketplace" (say, certain kinds of enterprise
deployments). Something similar seems to be going on with services that
"require" SASL PLAIN, but I'm open to persuasion that this situation is
different enough to justify special dispensation.

The proposed note about interoperability does not explicitly warn client
developers that omitting support for PLAIN might lead to an inability to
connect to services that don't or can't offer SCRAM, but that might be
an appropriate warning to include. (Is the same true for GSSAPI and
DIGEST-MD5?) Contrariwise, RFC 2119 seems to envision that MAY applies
only to add-on features that provide enhanced functionality (the lack of
support for the feature would still result in basic interoperability,
"though perhaps with reduced functionality").

We're in a grey area here, and it seems that one could argue that
clients SHOULD support PLAIN (although so far it appears to me that the
same or similar arguments might apply to GSSAPI, but not to DIGEST-MD5
because it's being obsoleted by SCRAM).

I'll continue to ponder this and ask some security area folks about it
this week in Beijing.

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 9 Nov 2010 15:15:46 -0800

On Nov 9, 2010, at 2:17 PM, Dave Cridland wrote:

> And what we're saying is that servers - for reasons which are most certainly outside the control of the client - may be unable to offer anything but PLAIN. A client which does not implement PLAIN will, therefore, fail to interoperate with such servers. It may be acceptable, or even desirable, for a client to behave in this way, for example if the client is marketed as being highly secure, but this will have an effect on interoperability, and as such is a trade-off.

One could make the argument that PLAIN (without TLS) is needed for interoperability and hence should be MTI'ed.

One MTI authentication mechanism ought to be sufficient for interoperability.  Yes, there will deployments where other mechanisms are needed, but isn't that always the case?

That said, I don't mind too much a SHOULD or a MUST implement Authenticated TLS + PLAIN, with at least a SHOULD NOT use PLAIN without TLS or with unauthenticated TLS or weak TLS.   That is, I was fine (IIRC) with the TLS + PLAIN text we had going into this recent consensus call.

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 07:20:30 +0800

On 11/10/10 7:15 AM, Kurt Zeilenga wrote:
>>> So do we want to tell client and server developers that they
>>> really really need to support SASL PLAIN unless they have an
>>> awfully good reason not to -- that we'd say you MUST implement it
>>> except that in a few well-defined circumstances it might not be
>>> appropriate?
>> 
>> Imperatives of the type defined in this memo must be used with
>> care and sparingly.  In particular, they MUST only be used where it
>> is actually required for interoperation or to limit behavior which
>> has potential for causing harm
>> 
>> certainly outside the control of the client - may be unable to
>> offer anything but PLAIN. A client which does not implement PLAIN
>> will, therefore, fail to interoperate with such servers. It may be
> One could make the argument that PLAIN (without TLS) is needed for
> interoperability and hence should be MTI'ed.
> 
> One MTI authentication mechanism ought to be sufficient for
> interoperability.  Yes, there will deployments where other mechanisms
> are needed, but isn't that always the case?
> 
> That said, I don't mind too much a SHOULD or a MUST implement
> Authenticated TLS + PLAIN, with at least a SHOULD NOT use PLAIN
> without TLS or with unauthenticated TLS or weak TLS.  That is, I was
> fine (IIRC) with the TLS + PLAIN text we had going into this recent
> consensus call.

Color me confused. Your posts to the list are the whole reason we had
this consensus call in the first place.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 10 Nov 2010 08:29:28 +0900

Hi,

> useful input, because I don't know if we have enough expertise in the

and that's the exact problem of TLS and the reason why it has not an
acceptable level of security: it is so complicated that many skilled
computer people don't get all the consequences. Yet it relies on many
people during it whole life chain (creation of certificates by people
who only care about money they get from it, and accepting them by
people who don't care about security warnings). I even remember to
have read once on a XSF list someone saying that a self-signed
certificate was as secure as one signed by a CA (whereas a self-signed
cert is basically same as no cert at all, unless its owner came to
give it to you physically with his usb key and his ID card).

But the truth is that CA makes mistakes and give away some certs, that
developpers don't really warn well against unsecure streams to users
(it becomes better in web browsers, but in XMPP, that's definitely
still bad, looking at the behaviour of all well-spread clients) nor do
they know which CA root certs to include (even in the web market, this
point is a mess), and that users don't really care in the end anyway,
mostly because to understand when you are secure, you need to
understand how the protocol itself work (that's also why even the
computer professionals don't understand themselves when it is secure)!

So no, TLS is well spread and better than nothing to stick with while
we don't have some technology definitely better, but that's not an
acceptable level of security to allow oneself to become "light
hearted" once this layer has been passed. Especially not on giving
away passwords.

Jehan

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 9 Nov 2010 15:32:35 -0800

> this consensus call in the first place.

While I rather remove any requirement to implement PLAIN, I realized that I'm in the rough on that one (and even tried to offer a few outs).  The consensus call only seems to have confirmed that.

My point above is more of a statement that the text we had was basically as good as it was going to get.

-- Kurt

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 10 Nov 2010 01:10:48 +0100

>    does not include the option (except, of course, for the feature the
Personally I'd interpret that text differently from you.
Some people have said that there are valid deployment scenarios where a
server can only offer PLAIN. And I tend to believe them that those exist.

A server that *can* only offer PLAIN:
a) Has a good reason not to offer SCRAM
b) Can't prepare itself to interoperate with clients that don't support
   PLAIN
Therefore I'd deem "clients MAY support SASL PLAIN + TLS" insufficient.
As far as I can tell this is also the main reason some other people
argued for SHOULD.

--
Florian Zeitz

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 9 Nov 2010 16:15:41 -0800

> While I rather remove any requirement to implement PLAIN, I realized that I'm in the rough on that one (and even tried to offer a few outs).  The consensus call only seems to have confirmed that.

Actually, let me further clarify that my largest pre-consensus call concern was better discouraging use of Unauthenticated TLS (in absence of channel bindings) as Unauthenticated TLS opens the down to a wide range of attacks, such as downgrade attacks and hijack attacks.  I think these issues have been resolved reasonable well.

I'm still concerned that we're pushing a lot of complexity upon client developers and overly relying on users to make non-trivial security decisions.  Unfortunately, this seems presently unavoidable.

As I noted before, even if we were to remove the Authenticated TLS + PLAIN mandate/recommendation/option with a MUST NOT implement PLAIN, PLAIN (with and without TLS, authenticated or not) support is going to remain ubiquitous.   Hence users are going to increasing become the target of attacks.  Aside from words of caution and recommending good alternatives, there's little we can presently do about that.  And that's why I'm fine with earlier text.

---

From: Matt Miller <[email-masked]>
Date: Tue, 9 Nov 2010 17:26:36 -0700

> As I noted before, even if we were to remove the Authenticated TLS + PLAIN mandate/recommendation/option with a MUST NOT implement PLAIN, PLAIN (with and without TLS, authenticated or not) support…

At the end of the day, there's only so much we can do to prevent everyone from shooting their own arms off (-:

I was fine with the earlier missive for that reason.

- m&m

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 10 Nov 2010 01:24:53 +0100

> give it to you physically with his usb key and his ID card).
You said yourself CAs only care about money. So if CAs aren't to be
trusted self-signed certs are certainly just as good. Also you have the
leap-of-faith (i.e. clients make sure the cert doesn't change after the
first connection, having a MITM on your very first connection is
relatively rare) that most people are willing to risk for ssh and many
people were willing to risk for XTLS.

> still bad, looking at the behaviour of all well-spread clients) nor do
Did you report that as bugs against those clients?
Also which were those?
I have seen shiny windows with big fonts about failed certificate checks
that asked you to check the fingerprint etc. in most clients I have
used. Complaining isn't going to get us anywhere.
> hearted" once this layer has been passed. Especially not on giving
I'm sitting here all the time thinking: "What's up with those peoples
passwords"
Honestly the first thing I would worry about is not the password I use
only for that one XMPP server (which is a easy security measure to teach
people).
I'm far more concerned that somebody can impersonate me at will, change
my roster, perform administrative tasks on the server, etc. And that is
a HUGE problem not easily fixed by using a different mechanism (mind it
can even happen if you use SASL SCRAM unless you do channel binding).
Can we please at least have some screaming and worrying about that too
if we are going to bash TLS like that?

--
Florian Zeitz (sorry for the rant)

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 10 Nov 2010 20:36:35 +0900

Hi,

> people were willing to risk for XTLS.

Euh... not at all. A self-signed cert is just like no cert at all. A
self-signed cert is as though someone in the street that you don't
know tell you "hello my name is Florian Zeitz" (and considering that
anyone can make a cert on one's computer, it is not like a country ID,
more like he shows you a random paper with his name on it as a proof).
Having nothing to prove it right or wrong at this time, I am still at
the same point: I don't know if this guy is actually you or not, but
all I have is the word of the guy who pretend to be.

As for a CA, even though we still cannot trust them to the point of
saying "this is an extremely good security", that's still better than
nothing (as I said, we stick with it as long as there is no better
option). Having a CA is like you definitely know someone whose job is
to check identities of others, but he is not a friend, and you don't
trust him fully because you suspect he is lazy and does not always
does his work very well (as long as he get paid, sometimes he is
reluctant to look for details). And this guy tells you: "yeah this guy
is indeed Florian Zeitz!". You cannot trust the answer at 100% because
your CA guy can still be fooled by a fake ID (or whatever) but that's
still a first good insurance.

Saying that self-certs are the same is exactly what I said: you didn't
understand fully how TLS work so you assume that anyway a cert is a
cert. A self-signed cert has absolutely NO VALUE at all (unless, as I
told, when you get handed this cert via another trusted network, as I
said, which is what people do when they make keysigning party, so that
they can exchange "physically" their certs).

As for the « having a MITM on your very first connection is relatively
rare », I "don't think" attackers care. That's not relevant. Basically
if some server gets redirected to a malevolent one (through a DNS
vulnerability for instance) , they'll just get everyone who connects
during this lapse of time, whatever this is their first connection or
not. Moreover even though it is true that we connect for the first
time only once (if not changing clients), making security rules on
this kind of probability is not the best choice.
And finally we really cannot say this kind of thing in a "connected
world" where users are constantly switching from a machine to another
(theirs, their mobile, from a friend's computer), or via web clients,
or on random machines when traveling, etc. So in fact people connects
"for the first time" many many times (if not each time in some
environment which does not "remember" the certs).

> only for that one XMPP server (which is a easy security measure to teach

You can do a lot of thing with passwords:
- keep a database of common passwords for future brute force attacks.
- try it on several other Internet services associated with the login,
because many people use the same login/password couple across services
(so an automated script to run on all famous services to check which
log/pass will work and hop you have access to dozens of people's
emails, paypal accounts, private photos and data, and so on).
- if this is a targeted attack, you can also study the password (in
case the person does not use the same login/pass everywhere) because
many people use a same pattern to make different passwords for all
service without having to remember. Then you may figure out their
passwords for other services.

> can even happen if you use SASL SCRAM unless you do channel binding).

With SASL SCRAM, if the attacker can pass TLS, then with a MITM, he
will be able to connect "ONCE" (thanks to the nonce attribute used, so
that the attacker cannot connect again with the data he stole once he
disconnected). Of course he may still make a mess, but that's worse
with PLAIN where if he forgot something, he can just connect again as
much as he want (or do nothing to remain unseen but regularly connect
in order to spy on you regularly, which he cannot do if he cannot
reconnect). And also he can do  all the actions previously cited, like
connect on another services you use, etc.
MITM on SCRAM enables this one thing if TLS is broken: connect ONCE,
nothing more (of course if once connected, big security leaks like
ad-hoc commands enables to retrieve the password, or modify it without
having to rewrite the old one... that's another issue about crazy
unsafe features). You can't knowingly compare damages possible with
SCRAM and PLAIN.

Bye.

Jehan

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 10 Nov 2010 14:37:59 +0100

> they can exchange "physically" their certs).
Thank you, but I was in fact fully aware of this. This was partially
speaking as devils advocate.
You can not honestly say in the same breath that CAs aren't to be
trusted, but self-signed certs are worthless.
The statement I made is absolutely true. A cert signed by a CA you don't
trust is as good as a self-signed one. That CA could be completely made
up after all.

Self-signed certs don't have a great value or anything, they slightly
reduced the risk though. And apparently to an extend that some people
are willing to take it.

> environment which does not "remember" the certs).
The friend's computer probably had a key-logger installed anyway ;)
It's definitely much worse than a CA signed cert, but I maintain it's
better than no cert at all or worthless (at least as long as you cache
certs).
Even encryption without authentication has some (limited) merit.
Consider everyone on the same WLAN hotspot vs. one potential attacker
being able to see your password.
I'm not saying it's a good idea to use self-signed certs, or anything
like that.
But I'm also not fine with this "We are all screwed"-subtone some of
this discussion has taken. There is no such thing as perfect security.
Leap-of-faith gives you limited, better not risk it security.
CAs give you acceptable security if you got the CA's cert out of band.
Checking the certificate against another copy of it you received out of
band gives you relatively strong security.
One can have all three of these with TLS. I don't see a reason to think
it has failed us as a technology. The system surrounding it is a far
bigger problem.
E.g. people are often not willing or capable of paying for certificates
(I myself am a student and could barely take even money for one of the
cheaper certs out of my "budget" and I know of people that have an even
tighter one).
Also CAs that don't require payment are often not taken seriously,
because they get no compensation for their honesty (The assumption
apparently being that bribing a "normal" CA would be too expensive if
you want to compensate for the potential loss of trust/income).
That's nothing for this WG to solve though.

>> used. Complaining isn't going to get us anywhere.
My question here still stands. If you really want to change something
misbehaving clients are a good start.

> passwords for other services.
Sure, I never claimed getting access to passwords was useless. It would
just not be my personal primary worry on a hijacked session.

> unsafe features). You can't knowingly compare damages possible with
I disagree. ONCE would be nice. But an attacker can do this EVERY TIME
you log in. He can also maintain the session for as long as he wants to.
And then there are those "crazy unsafe features" that most people in
fact really like. Especially being able to change your password once in
a while sounds nice if you don't assume that you will be impersonated.
Teaching people to assume they might be impersonated is quite hard, and
as far as I'm concerned that is something we actually (should) try to
protect against anyway.
My point is: We are discussing password security for a scenario that
should ideally never happen for a lot of other good reasons.

--
Florian Zeitz

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 10 Nov 2010 11:48:02 +0200

Although a literary analysis of RFC 2119 is much more fun, I would like 
to comment on the paragraph below:

The crux of the matter is the parenthetical "and proper certificate 
validation and so on": while the TLS *protocol* offers a very high level 
of security, TLS *in actual use* unfortunately often does not. Jehan 
pointed out some of the reasons earlier today (negligent CA procedures, 
security "warnings" whose goal is to let the communication proceed - no 
matter what, etc.). This makes the distinction between authenticated and 
unautheticated TLS much more blurry than we would have liked it to be. 
And if it wasn't clear: please don't send plaintext passwords over this 
channel.

Thanks,
     Yaron

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Nov 2010 07:05:14 +0800

On 11/10/10 8:26 AM, Matt Miller wrote:
>> As I noted before, even if we were to remove the Authenticated TLS
>> + PLAIN mandate/recommendation/option with a MUST NOT implement
>> PLAIN, PLAIN (with and without TLS, authenticated or not) support
>> is going to remain ubiquitous.   Hence users are going to
>> increasing become the target of attacks.  Aside from words of
>> caution and recommending good alternatives, there's little we can
>> presently do about that.  And that's why I'm fine with earlier
>> text.
> 
> At the end of the day, there's only so much we can do to prevent
> everyone from shooting their own arms off (-:

Sure. People are going to implement SASL PLAIN no matter what we say in
the spec. But that doesn't mean we need to actively exhort people to
implement it.

> I was fine with the earlier missive for that reason.

And I was concerned that WG might be making a decision that was not
fully informed.

I'll post further once I've had a chance to talk with more security area
folks in Beijing.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Nov 2010 17:05:59 +0800

> And if it wasn't clear: please don't send plaintext passwords over this

Yes, that is the crux.

Here at IETF 79 in Beijing, I've talked with both of the Security ADs as
well as several other folks who are active in the security area. I've
also raised the issue of plaintext passwords over TLS during the
Security Area Advisory Group (SAAG) session. I've also talked with the
XMPP WG chairs. Based on those discussions as well as Yaron's feedback,
here is how I see it:

1. Developers will implement SASL PLAIN no matter what we say in the spec.

2. I don't particularly want to give people an official blessing to use
SASL PLAIN, but I recognize that in sometime it's unavoidable. I think
we need to say a bit more about what those circumstances are, but we
need to recognize reality.

3. We need to have strong text about when it's appropriate to use TLS
plus SASL PLAIN instead of SCRAM.

Therefore I (somewhat reluctantly) propose the following text:

###

      Security Note: The SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants of
      the SCRAM mechanism are strongly preferred over the PLAIN
      mechanism because of their superior security properties (including
      the ability to enforce channel binding as described under
      Section 13.9.4).  Therefore, a client SHOULD treat TLS plus SASL
      PLAIN as a technology of last resort to be used only when
      interacting with a server that does not yet support SCRAM, 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 if the stream does not at a minimum have
      confidentiality and integrity protection via TLS with full
      certificate validation as described under Section 13.7.2.1.
      Similarly, a server MUST NOT offer SASL PLAIN if the stream is not
      protected via TLS and SHOULD NOT offer TLS plus SASL PLAIN unless
      it is unable to offer some variant of SASL SCRAM, 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, such as Pluggable Authentication Modules (PAM), an
      LDAP database [LDAP], or an Authentication, Authorization, and
      Accounting (AAA) key management protocol (for guidance, refer to
      [AAA]).

###

Feedback is welcome from our Security Directorate reviewer and from the WG.

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Fri, 12 Nov 2010 11:33:02 +0000

> Feedback is welcome from our Security Directorate reviewer and from the WG.

That works for me, thanks Peter.

/K

---

From: Dave Cridland <[email-masked]>
Date: Fri, 12 Nov 2010 11:45:25 +0000

>       Accounting (AAA) key management protocol (for guidance, refer  

 From the PLAIN perspective, this is fine, modulo  
s/database/directory/.

However, can we replace "SCRAM-SHA-1 and SCRAM-SHA-1-PLUS" with  
"SCRAM-SHA-1-PLUS, or, failing that, SCRAM-SHA-1" or something, just  
to remind readers that they ought to be using channel binding?

(We chose the names to make it obvious that the -PLUS variant is the  
one you want to use, but even so).

Dave.

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 12 Nov 2010 21:39:34 +0900

Hi,

> Therefore I (somewhat reluctantly) propose the following text:

As you might guess from the previous discussion, I don't like this new
version. See comments below.

>   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN.

Even from what you reported from your previous discussions with
various security people, I don't understand why it makes the feature
become a MUST. Even without a MUST, it doesn't mean we forbid people
from implementing PLAIN (not using a MUST is not a MUST NOT), and we
would still recognize the existence and sometimes even the necessity
(necessity also is not a MUST, it is not a "mandatory in all
situations" but "sometimes this is unfortunately unavoidable) in the
following note. I really don't understand because you do the opposite
of what you say before: here we give the blessing to use PLAIN.

>      Security Note: The SCRAM-SHA-1 and CRAM-SHA-1-PLUS variants of

Here to me, that's nearly as though we were giving the directions to
malevolent people on how to make a successful downgrade attack.

I still go from the base that it is possible, and have already been
done (so this is not some theoretical stuff) to get certificates which
validate perfectly (either by fooling CAs to give them, as it happened
in 2001 for Microsoft for instance:
http://www.verisign.com/support/advisories/authenticodefraud.html or
by exploiting cryptographic exploits, which with time and technical
progress can always occurre again:
http://phreedom.org/research/rogue-ca/ or probably other ways, like
simply being able to steal a certificate on the machine itself during
an intrusion) for a domain, and also to redirect connections (DNS
cache poisoining being one common solution, but not the only one, far
from it unfortunately), all your recommendations are not enough to be
secure enough to be passing PLAIN password in my opinion.

A client would need for instance to cache certificates and compare the
old and current one. If the certificate is different — even though
valid — while the previous one has apparently not be revoked nor
approaching end of validity, that's suspicious for instance. Also even
SASL mechanisms should be memorized by the clients to prevent
downgrade attacks: if the server usually only propose SCRAM or some
other very strong mechanisms and suddenly propose only PLAIN (which in
the new text seems to be considered as completely acceptable...
hum...), this is EXTREMELY suspicious on a normal running service,
even with a perfectly valid and well authenticated certificate.

That's recommendations among many others that would be worth written
in a security XEP. But if we are to say PLAIN is a "MUST", then this
should as well be in the RFC itself if we don't want the protocol to
be completely weak on security.

> Feedback is welcome from our Security Directorate reviewer and from the WG.

And so here is was above. ;-)

Bye.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Nov 2010 21:24:29 +0800

On 11/12/10 7:45 PM, Dave Cridland wrote:
> From the PLAIN perspective, this is fine, modulo s/database/directory/.
> 
> "SCRAM-SHA-1-PLUS, or, failing that, SCRAM-SHA-1" or something, just to
> remind readers that they ought to be using channel binding?

Further edited...

###

   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 (with SCRAM-SHA1-PLUS being preferred, as
   described under Section 13.9.4).

      Security Note: The SCRAM-SHA-1 and especially SCRAM-SHA-1-PLUS
      variants of the SCRAM mechanism are strongly preferred over the
      PLAIN mechanism because of their superior security properties
      (including for SCRAM-SHA-1-PLUS the ability to enforce channel
      binding as described under Section 13.9.4).  Therefore, a client
      SHOULD treat TLS plus SASL PLAIN as a technology of last resort to
      be used only when interacting with a server that does not yet
      support SCRAM, MUST prefer more secure mechanisms (e.g., EXTERNAL,
      SCRAM-SHA-1-PLUS, and SCRAM-SHA-1) to the PLAIN mechanism, and
      MUST NOT use the PLAIN mechanism if the stream does not at a
      minimum have confidentiality and integrity protection via TLS with
      full certificate validation as described under Section 13.7.2.1.
      Similarly, a server MUST NOT offer SASL PLAIN if the stream is not
      protected via TLS and SHOULD NOT offer TLS plus SASL PLAIN unless
      it is unable to offer some variant of SASL SCRAM, 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, such as Pluggable Authentication Modules (PAM), an
      LDAP directory [LDAP], or an Authentication, Authorization, and
      Accounting (AAA) key management protocol (for guidance, refer to
      [AAA]).

###

---

From: Kevin Smith <[email-masked]>
Date: Fri, 12 Nov 2010 13:33:50 +0000

>      Accounting (AAA) key management protocol (for guidance, refer to

Also works for me.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Nov 2010 21:33:55 +0800

> version. See comments below.

I'm not particularly happy, either, but I think this is the best we'll
do for now.

> become a MUST. 

It is SHOULD, not MUST.

> Even without a MUST, it doesn't mean we forbid people

Given the widespread deployment of LDAP directories as the
authentication backend for XMPP services, I think we're stuck with PLAIN
as a very common server offering.

> malevolent people on how to make a successful downgrade attack.

You think they can't figure it out on their own?

> be completely weak on security.

The best way to improve security would be to move away from
password-based authentication entirely (unless it's something like
Secure Remote Password), i.e., to use certificate auth or key auth. We
need more deployment experience before we can recommend that even more
strongly.

Peter

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

---

From: Matthew Wild <[email-masked]>
Date: Fri, 12 Nov 2010 13:43:17 +0000

This is the best text proposed so far in my opinion; it most
accurately reflects the majority consensus call responses and
addresses the security and interoperability issues directly. However a
couple of points inline...

>>>    TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN.

Consensus was that PLAIN ought to be SHOULD only for clients - servers
can implement it as fitting for the deployment scenarios they want to
support.

>>>       it is unable to offer some variant of SASL SCRAM

I don't see that this requirement aids security or interoperability.
Assuming the client obeys the rest of the text, it will not use PLAIN
even if offered. Also this essentially discourages a SCRAM-capable
server from ever offering PLAIN for interoperability with clients that
do not support SCRAM. This is the majority of clients in the field
today. I believe whether to offer PLAIN should be a deployment and
implementation decision entirely.

Thanks,
Matthew

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 12 Nov 2010 22:49:36 +0900

Hi,

sorry I come back to an older message. It is not really relevant
because the discussion has moved on, but I felt bad leaving this
discussion with Florian Zeitz like this (though it is my last answer
on these points with Florian).

> speaking as devils advocate.

Yeah I am sorry. I hesitated before writing this like that because I
feared to appear rude. But the fact is that you are maybe the
advocate, but the devils, they really think so in the end. And those
devils are most people because they just don't care about security or
don't understand it simply. And unfortunately this applies too to
soooo many of computer scientists as well.

> trust is as good as a self-signed one. That CA could be completely made

Of course I can say this! This is not because this is POSSIBLE to
break a security measure that this is the same than no security at
all. And if you really think that a self-cert cert is the same as one
signed by a CA which you don't fully trust (and I don't because they
are human, that's all basically), then I am sorry but I will have
again to be rude and say you didn't fully understand how TLS work. But
I think you just are still being the "advocate". ;-)

> reduced the risk though. And apparently to an extend that some people

But we are making an Internet standard here. We are not simply end
user playing around.
We should actually not take any risk *on the behalf of users* as much
as we can avoid them. Because that's the problem: here we are
upstream, we make decisions for end users, that nearly most of them
will most probably never know about. Our role is to reduce the risks
to the maximum so that these users will have only finale decisions to
make (and a very good security is when they do not have any more
decisions to make, because users are tempted to always take these
"leap of faith" you talk about = clicking "yes" on any warning without
reading nor understanding).

Because it is simply not our role to take "leap of faith". We are not
any kind of religion, there is no faith in security.
In life, I am actually pretty "light", not paranoid at all, but when
it comes to work about security, I need to become paranoid just for
this. Because this is our job here: being paranoid on the behalf of
users, and let them have faith if they wish to, whatever.

> Even encryption without authentication has some (limited) merit.

Of course it has. It is all a question of "security level". Let's just
try to be at the higher possible level.
We must make the higher recommendation. In the end, implementers,
administrators and users will do what they can or want with it, but at
least let's not make our recommendation weak. As I said: our job is to
be paranoid.

> this discussion has taken. There is no such thing as perfect security.

I didn't say this, either "we are screwed", nor "there is a perfect security".

> Leap-of-faith gives you limited, better not risk it security.

See above. Not our role.

> it has failed us as a technology. The system surrounding it is a far

I didn't say that either. It is one of the best we have (or at least
widely deployed), but it is still breakable (has already been broken
several time and will most certainly be again) and we cannot rely on
it fully, not enough to send PLAIN password at least, in my opinion,
considering we have access to technologies allowing us not to do so
(SCRAM or other secure enough mechanisms).

> cheaper certs out of my "budget" and I know of people that have an even

Some CA gives free certificates. Sometimes not as featured as paid one
(like only one domain, etc.). Some CA are also community driven (I
think obviously about CAcert and I hear they are quite secure), and
fully free. I understand the excuse of this being annoying and
complicated (I myself — lazy as a cat! — has not had a CA signed cert
for years, just by laziness), but not the money excuse because they
are many free solution better than self-signed certs.

> you want to compensate for the potential loss of trust/income).

That's not true. I know at the opposite many people who give more
trust to cacert for instance than for some of the well know commercial
CAs. The main reason why they are not integrated in browser for
instance is money: they don't get paid for the service, hence are
small on money as well and a security audit to get proven secure is
extremely expensive (see http://wiki.cacert.org/InclusionStatus ).

> misbehaving clients are a good start.

I am participating in many ways in many Free softwares, in the XMPP
world and outside. Don't worry for this.
And the misbehaving is for instance that clients don't tell you what
kind of connection you are on. They will tell you a problem on a cert
but a non TLS connection will make no warning!

We have lot to learn from modern browsers, how they deal with level of
connections with colors (on the url bar for instance), icons (the
lock), etc.

> just not be my personal primary worry on a hijacked session.

That's the worst one! The guy get full access and forever to this
service, and potentially others.

> you log in.

Usually such attacks are only lasting a given period, until the
administrators of the right service notice there is a problem and take
act.

> He can also maintain the session for as long as he wants to.

Then he might be noticed more easily with his resource. Not as useful
as being able to regularly connect a few second, gather information
and disconnect.

> as far as I'm concerned that is something we actually (should) try to

This is why we should make this as secure as possible upstream to make
problems less serious for users who don't understand these security
issues and often don't listen nor learn.

> should ideally never happen for a lot of other good reasons.

But which happened already quite a few times (see my previous email
for instance, and I just took 2 random examples) and will certainly
again. I told it: our role is not to imagine an "ideal", we must
imagine the "worst".

Bye.

Jehan

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 12 Nov 2010 23:04:01 +0900

Hi,

>> various security people, I don't understand why it makes the feature

Yes right. Still as we said in a previous email, experience teach that
SHOULD are usually to be considered as MUST. I would have prefered
MAY.
Anyway as Matthew Wild point in a further email, SHOULD was only for
the client, not for the server. So at least if we ever have to accept
compromise, let's take the stronger one.

> need more deployment experience before we can recommend that even more

That might be pretty hard to be deployed massively (I mean with common
users, with corporate use, it might work well) with the current state
of technology. Right now, it is pretty annoying procedure.
But yeah that could be great. But obviously it should not stop us from
securing what is currently used, which is why I will always fight as
much as I can from this kind of things (though I obviously accept
finale consensus even though it disagrees with me).
Bye!

Jehan

---

From: Matt Miller <[email-masked]>
Date: Fri, 12 Nov 2010 08:03:41 -0700

>      Accounting (AAA) key management protocol (for guidance, refer to

I can live this this also.

- m&m

---

From: Florian Zeitz <[email-masked]>
Date: Fri, 12 Nov 2010 18:17:39 +0100

>       Accounting (AAA) key management protocol (for guidance, refer to

As Matthew Wild noted I think we had pretty strong consensus on making
PLAIN a MAY for servers. Otherwise this looks good to me.

My personal rational for having PLAIN as a SHOULD for clients
(admittedly somewhat included as a semi-response to Jehan Pagès) is that
while we need to be as secure as possible we also need to care about
interoperability.
We certainly can do better than using SASL PLAIN over TLS, but it's in
fact quite secure (if done correctly and the text is quite precise on
what "correct" should mean here (at least IMHO)).
Considering PLAIN as strictly optional on the other hand seems like a
burden for interoperability given current deployments.
I agree people would probably figure out they need to implement SASL
PLAIN to be able to authenticate against some deployments, but they
shouldn't run into issues in the first place after implementing the RFC.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 13 Nov 2010 07:50:31 +0800

Yes, that is the approach I was going to take before the WG chairs
talked me back from the edge. :)

That is, in relation to my previous email:

1. Remove this sentence:

2. Add this sentence to the beginning of the Security Note:

   In practice, many servers offer, and many clients use, TLS plus
   SASL PLAIN.

So that would result in:

###

      Interoperability and Security Note: In practice, many servers
      offer, and many clients use, TLS plus SASL PLAIN.  However, the
      SCRAM-SHA-1 and especially SCRAM-SHA-1-PLUS variants of the SCRAM
      mechanism are strongly preferred over the PLAIN mechanism because
      of their superior security properties (including for SCRAM-SHA-1-
      PLUS the ability to enforce channel binding as described under
      Section 13.9.4).  Therefore, a client SHOULD treat TLS plus SASL
      PLAIN as a technology of last resort to be used only when
      interacting with a server that does not yet support SCRAM, MUST
      prefer more secure mechanisms (e.g., EXTERNAL, SCRAM-SHA-1-PLUS,
      and SCRAM-SHA-1) to the PLAIN mechanism, and MUST NOT use the
      PLAIN mechanism if the stream does not at a minimum have
      confidentiality and integrity protection via TLS with full
      certificate validation as described under Section 13.7.2.1.
      Similarly, a server MUST NOT offer SASL PLAIN if the stream is not
      protected via TLS and SHOULD NOT offer TLS plus SASL PLAIN unless
      it is unable to offer some variant of SASL SCRAM, 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, such as Pluggable Authentication Modules (PAM), an
      LDAP directory [LDAP], or an Authentication, Authorization, and
      Accounting (AAA) key management protocol (for guidance, refer to
      [AAA]).

###

On 11/13/10 12:34 AM, Yaron Sheffer wrote:
> I agree that the best way forward is to move to password-based mutual
> authentication methods. Two efforts that I'm involved with are:
> 
> - An EAP method using the EKE protocol:
> http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-08
> 
> - IKEv2 with PACE:
> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-04
> 
> And to go back to the matter at hand, there is a conceptual problem with
> making PLAIN a SHOULD on the client side (although I appreciate  the
> interop aspects): if there are problems with the SSL channel, you are
> mandating that the client be susceptible to downgrade attacks. Or to put
> it bluntly, the client software is betraying the user. I think the way
> out is to avoid 2119 language even for the client, so that implementors
> can choose what is right for their deployments. For example, they can
> avoid PLAIN altogether for specific, well known servers.
> 
> Thanks,
>     Yaron
> 
> On 11/12/2010 03:33 PM, Peter Saint-Andre wrote:

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 13 Nov 2010 07:55:55 +0800

> shouldn't run into issues in the first place after implementing the RFC.

My personal rationale for saying that SASL PLAIN is only a MAY (i.e.,
strictly optional) is that we know that developers will implement it no
matter what we say in the spec anyway. However, I think it would be bad
for us to enable developers to point to the spec and say "oh sure there
are problems with SASL PLAIN, but the XMPP spec says I SHOULD implement
it and I couldn't find a good reason not to, so in our implementation we
just use SASL PLAIN -- I'm sorry that we haven't gotten around to adding
SCRAM yet, but we'll do it someday and in the meantime we basically
comply with the spec so what's the big deal?"

I'd rather not be responsible for that kind of thinking.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 13 Nov 2010 08:06:31 +0800

> can implement it as fitting for the deployment scenarios they want to

Right. We'll see where things actually end up (e.g., no conformance
language whatsoever).

> I don't see that this requirement aids security or interoperability.

I assume you are referring to the second clause, not the first.

> implementation decision entirely.

In which case, there's a good reason for overriding the SHOULD NOT at a
deployment level.

Thus:

###

      Interoperability and Security Note: In practice, many servers
      offer, and many clients use, TLS plus SASL PLAIN.  The SCRAM-SHA-1
      and especially SCRAM-SHA-1-PLUS variants of the SCRAM mechanism
      are strongly preferred over the PLAIN mechanism because of their
      superior security properties (including for SCRAM-SHA-1-PLUS the
      ability to enforce channel binding as described under
      Section 13.9.4).  A client SHOULD treat TLS plus SASL PLAIN as a
      technology of last resort to be used only when interacting with a
      server that does not yet support SCRAM, MUST prefer more secure
      mechanisms (e.g., EXTERNAL, SCRAM-SHA-1-PLUS, and SCRAM-SHA-1) to
      the PLAIN mechanism, and MUST NOT use the PLAIN mechanism if the
      stream does not at a minimum have confidentiality and integrity
      protection via TLS with full certificate validation as described
      under Section 13.7.2.1.  A server MUST NOT offer SASL PLAIN if the
      stream is not protected via TLS.  A server SHOULD NOT offer TLS
      plus SASL PLAIN unless it is unable to offer some variant of SASL
      SCRAM, 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, such as Pluggable Authentication
      Modules (PAM), an LDAP directory [LDAP], or an Authentication,
      Authorization, and Accounting (AAA) key management protocol (for
      guidance, refer to [AAA]); however, offering TLS plus SASL PLAIN
      even when the server supports SCRAM might be appropriate if the
      server needs to enable interoperability with an installed base of
      clients that do not yet support SCRAM.

###

---

From: Matthew Wild <[email-masked]>
Date: Sat, 13 Nov 2010 00:08:37 +0000

> I'd rather not be responsible for that kind of thinking.

It's easy to get into pointless arguments about how people are going
to interpret the spec. However I'll just note that 1) if they don't
implement and use SCRAM over PLAIN wherever possible they are /not/
complying with the spec 2) the kind of people you're talking about -
we both know they're not going to change depending on what we put in
the spec now anyway :)

I don't think I've much more to contribute to this discussion, I've
given the rationale for my viewpoint and I bow to the better judgement
of the editor and security-focused people in the IETF.

Regards,
Matthew

---

From: Kevin Smith <[email-masked]>
Date: Sat, 13 Nov 2010 00:09:13 +0000

>   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN.

-1

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 13 Nov 2010 08:17:49 +0800

>>   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN.

It's easy to say "-1" when it's not your name that's on the rope
developers use to hang themselves and their users. :)

Practically it's not going to make much of a difference whether we say
SHOULD or non-normatively explain the reasons why it sometimes makes
sense to use PLAIN over TLS. Morally it makes a difference to me as a
spec writer.

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Sat, 13 Nov 2010 09:32:51 +0000

> developers use to hang themselves and their users. :)

It is; I didn't want to write a multi-page mail that didn't say
anything new, but still wanted to say that I still think this is the
wrong way to go.

Without PLAIN we've got an MTI that is currently available in a
shockingly small number of software/deployments and that we know is
going to be unsuitable for (it seems to me given my experience so far)
the majority of enterprise deployments. I'd rather we specced
something that we know will work, and explained how to use it as
safely as possible, than spec something we believe to be safe but that
we know isn't adequate for interop.

If a new client implements just SCRAM, which is what 3920bis is
suggesting is all that's needed for interop given that it's the only
MTI, what proportion of the XMPP network will they be able to interop
with? What proportion of the XMPP network SHOULD a client that
implements 3920bis be able to interop with? I'm sorry for sounding
like a broken record here, but I think it should be the vast majority
(and ideally all), not a tiny minority.

/K

---

From: Dave Cridland <[email-masked]>
Date: Sat, 13 Nov 2010 11:48:32 +0000

> we both know they're not going to change depending on what we put in

I'd note that the argument that "whatever the spec says people will  
do X anyway" is entirely self-defeating, anyway. Why bother writing a  
specification *at all*?

The purpose of the specification is twofold:

1) To document how to an implementation needs to behave to work with  
as many deployments as possible.

2) To inform implementors on how to do so with the maximum security.

In the XMPP community, perhaps more so than anywhere else (and  
certainly more so than anywhere else I've had the pleasure of  
experiencing), implementors and even operators are exceptionally  
close to the standards process. The vast majority of implementors  
follow the specifications and contribute to their development - one  
only needs to look at those involved in the consensus call here.  
Operators of larger services *also* keenly follow the standards  
process and ensure that their deployments, too, match the   
requirements.

If there is a single application protocol that's likely to have the  
RFCs carefully read by all involved, it'll be these.

Even if this weren't the case, I feel every bit as morally obliged to  
document reality and running code over some theoretical ideal - and  
XMPP is highly deployed, and we have certainly got the deployment  
knowledge available to inform us on this list. Producing an  
unrealistic specification which "everyone knows" you don't need to  
adhere to is a recipe for condemnation to irrelevance.

Yes, indeed, we understand that PLAIN is not, from a security  
standpoint, the ideal, and the proposals document this clearly.  
However, we also know that SCRAM is not always possible, and not yet  
commonplace (though, by way of illustrating previous points, SCRAM  
has far more deployed implementations in XMPP than anywhere else).  
PLAIN, however, is always possible - the reason for its very  
existence - and thus the best choice for maximal interoperability for  
clients.

There is, in my opinion, clear consensus that the best option we  
have, balancing the demands of security with those of  
interoperability, is to state that clients SHOULD, and servers MAY,  
implement PLAIN.

> of the editor and security-focused people in the IETF.

Given the result of the consensus call, it's not entirely clear to me  
why we are continuing to debate this.

Do the chairs believe that the consensus call is unclear?

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 14 Nov 2010 09:13:18 +0800

<snip/>

I just got home from IETF 79 in Beijing so it might take me a day or two
to reply further in this thread. Just so you know!

Peter

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

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 12 Nov 2010 18:34:43 +0200

- IKEv2 with PACE: 

Thanks,
	Yaron

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Nov 2010 16:04:36 -0600

(as chair)

On Nov 13, 2010, at 5:48 AM, Dave Cridland wrote:

> Given the result of the consensus call, it's not entirely clear to me why we are continuing to debate this.
> 

The chairs see a rough consensus for:

- servers MAY offer PLAIN over TLS in the cases where something better
cannot be deployed

- clients SHOULD implement PLAIN over TLS (while preferring anything more
secure) in order to maximize interoperability with the servers that can't
deploy anything else

- Implementations SHOULD try really hard not to use PLAIN except as a last resort.

Let's move on to seeing if we can agree to text that adequately describes
this in more normative language. I think we are close, but may need another round of word-smithing to be sure.

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Nov 2010 18:42:33 -0700

> - Implementations SHOULD try really hard not to use PLAIN except as a last resort.

For the record, I still think this text is unnecessarily normative. Hmm,
I wonder if I can lodge a DISCUSS against my own document during IESG
review. ;-)

(JUST KIDDING!)

> this in more normative language. I think we are close, but may need another round of word-smithing to be sure.

Bowing to the rough consensus, here is proposed text:

###

   As further explained in the following Security Note, in certain
   circumstances a server MAY offer TLS with the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN when it is
   not possible to offer more secure alternatives; in addition, clients
   SHOULD implement PLAIN over TLS in order to maximize interoperability
   with servers that are not able to deploy more secure alternatives.

      Security Note: In practice, many servers offer, and many clients
      use, TLS plus SASL PLAIN.  The SCRAM-SHA-1 and especially SCRAM-
      SHA-1-PLUS variants of the SCRAM mechanism are strongly preferred
      over the PLAIN mechanism because of their superior security
      properties (including for SCRAM-SHA-1-PLUS the ability to enforce
      channel binding as described under Section 13.9.4).  A client
      SHOULD treat TLS plus SASL PLAIN as a technology of last resort to
      be used only when interacting with a server that does not offer
      SCRAM (or other alternatives that are more secure than TLS plus
      SASL PLAIN), MUST prefer more secure mechanisms (e.g., EXTERNAL,
      SCRAM-SHA-1-PLUS, SCRAM-SHA-1, or the older DIGEST-MD5 mechanism)
      to the PLAIN mechanism, and MUST NOT use the PLAIN mechanism if
      the stream does not at a minimum have confidentiality and
      integrity protection via TLS with full certificate validation as
      described under Section 13.7.2.1.  A server MUST NOT offer SASL
      PLAIN if the stream is not protected via TLS.  A server SHOULD NOT
      offer TLS plus SASL PLAIN unless it is unable to offer some
      variant of SASL SCRAM (or other alternatives that are more secure
      than TLS plus SASL PLAIN), 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, such as Pluggable
      Authentication Modules (PAM), an LDAP directory [LDAP], or an
      Authentication, Authorization, and Accounting (AAA) key management
      protocol (for guidance, refer to [AAA]); however, offering TLS
      plus SASL PLAIN even when the server supports more secure
      alternatives might be appropriate if the server needs to enable
      interoperability with an installed base of clients that do not yet
      support SCRAM or other alternatives that are more secure than TLS
      plus SASL PLAIN.

###

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 16 Nov 2010 11:40:41 +0900

Hi,

[...]
[...]

Ok, I guess this text looks ok, in the view of the consensus.

Jehan

---

From: Kevin Smith <[email-masked]>
Date: Tue, 16 Nov 2010 06:58:50 +0000

On Tue, Nov 16, 2010 at 1:42 AM, Peter Saint-Andre <[email-masked]> wrote:
> <proposed-text/>

Works for me, thanks.

/K

---

From: Dave Cridland <[email-masked]>
Date: Tue, 16 Nov 2010 08:58:10 +0000

>       variant of SASL SCRAM (or other alternatives that are more  

I'm not entirely comfortable with this, but I'm willing to go along  
with it if this is what people want.

Otherwise the text is spot on, thanks.

Dave.

---

From: Kevin Smith <[email-masked]>
Date: Tue, 16 Nov 2010 09:02:02 +0000

On Tue, Nov 16, 2010 at 8:58 AM, Dave Cridland <[email-masked]> wrote:
> I'm not entirely comfortable with this, but I'm willing to go along with it
> if this is what people want.

Me neither, but the later "Yeah, but it can do it anyway" negates this.

(however, offering TLS
     plus SASL PLAIN.)

/K

---

From: Dave Cridland <[email-masked]>
Date: Tue, 16 Nov 2010 09:19:31 +0000

>      support SCRAM or other alternatives that are more secure than  

Yes, indeed - explicitly spelling this out as a potential reason to  
ignore the SHOULD NOT does make this fine by me.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2010 11:07:58 -0700

> ignore the SHOULD NOT does make this fine by me.

Right. I'm beginning to understand why it's important to explain why an
implementation can legitimately not follow a SHOULD or SHOULD NOT. Not
that I have time to do that for every instance in the specs...

Peter

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