FYI, I sent this to some of my contacts within the IETF and will report back regarding their recommendations.
/psa -------- Original Message -------- Date: Tue, 07 Aug 2007 10:44:15 -0600 From: Peter Saint-Andre <[EMAIL PROTECTED]> Subject: SASL mechanisms in rfc3920bis (XMPP) My apologies for the large distribution list, but I have a question about mandatory-to-implement SASL mechanisms in rfc3920bis (XMPP), so it seems appropriate to ask folks from the Apps and Security areas as well as the SASL WG. 1. In RFC 3920, the DIGEST-MD5 mechanism was mandatory-to-implement for the purpose of authentication without confidentiality. Given the uncertainty and lack of enthusiasm regarding DIGEST-MD5 in the SASL WG (at least according to my perception), as well as confusion among XMPP developers regarding DIGEST-MD5 and some problems with deployment of DIGEST-MD5 (e.g., Google found it unworkable and used its own token authentication method instead, or TLS + SASL PLAIN), the consensus of the XMPP community is that DIGEST-MD5 is problematic. However, we don't know what to replace it with in rfc3920bis. YAP is too young (and not even a SASL WG item). CRAM-MD5, which we have not fully investigated, may introduce problems with non-US-ASCII characters in XMPP addresses and questions about interaction with existing XMPP stringprep profiles. Are there perhaps even other mechanisms that the XMPP developer community should look into? Should we investigate CRAM-MD5 more fully? Or should we stick with DIGEST-MD5 as tried if not perhaps true (e.g., by clarifying usage of that mechanism)? 2. In RFC 3920, TLS + SASL EXTERNAL was mandatory-to-implement for the purpose of both authentication and confidentiality. This makes sense for server-to-server connections (especially since we established an intermediate certification authority for XMPP servers in December 2006, which issues cost-free digital certificates to server administrators under the auspices of root CA StartCom). However, it makes less sense for client-to-server connections because it is difficult and confusing for most end users to obtain client certificates. Therefore, based on implementation and deployment experience in the XMPP community, the current revision of rfc3920bis mandates TLS + SASL PLAIN for both authentication and confidentiality in the client-to-server case, while retaining TLS + SASL EXTERNAL in the server-to-server case. Does this approach seem reasonable? Before we proceed much further with rfc3920bis, I would like to get feedback on these issues. Also, we are thinking about holding a one-day "XMPP Security Summit" close in time and space to an upcoming IETF meeting (e.g., IETF 70 in Vancouver) so that we can work through issues of this kind with both XMPP developers and appropriate people from the IETF community. If you think this would be helpful, I would appreciate hearing about it so that I can begin to plan for such a meeting. Thanks. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
