[Standards] [Fwd: SASL mechanisms in rfc3920bis (XMPP)]

Peter Saint-Andre stpeter at jabber.org
Tue Aug 7 16:47:24 UTC 2007


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 <stpeter at jabber.org>
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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070807/fe2ecd6b/attachment.bin>


More information about the Standards mailing list