[Standards] Proposed XMPP Extension: Extensible SASL Profile

Dave Cridland dave at cridland.net
Thu Feb 9 08:40:49 UTC 2017

On 9 February 2017 at 05:50, Evgeny Khramtsov <xramtsov at gmail.com> wrote:
> Thu,  9 Feb 2017 02:05:35 +0000 (UTC)
> XMPP Extensions Editor <editor at xmpp.org> wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> Title: Extensible SASL Profile
>> Abstract: This document describes a replacement for the SASL profile
>> documented in RFC 6120 which allows for greater extensibility.
>> URL: http://xmpp.org/extensions/inbox/sasl2.html
>> The council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
> Section 2.2:
>> In order to explicitly transmit a zero-length SASL challenge or
>> response, the sending party sends a single equals sign character
>> ("=").
> I'm always wondered what is the point in this "="? What's the
> difference between, let's say, <response/> and <response>=<response/> ?

And there was me thinking you'd complain it wasn't possible to
authenticate any other way due to RFC 6120. ;-)

Your question should have been answered by the rest of Section 2.2,
actually, so if it's not clear I'd welcome further suggestions for

A SASL exchange can need to send three cases. For ease of notation,
I'll use C strings, but note that really, these may be binary blobs:

1) Normal data: "foobar"

2) Empty String: ""

3) Nothing: NULL

The difference can be seen in SASL EXTERNAL - I'll use the RFC 6120 form, here:

1) <authenticate mechanism="EXTERNAL">abcdef</authenticate><!-- Send
an explicitly requested authorization identifier - server will respond
directly with <success/> or <failure/> -->

2) <authenticate mechanism="EXTERNAL">=</authenticate><!-- Send a
request to not specify any authorization identifier - server will
respond directly with <success/> or <failure/>, using the authzid from
the stream header, or derived from the certificate. -->

3) <authenticate mechanism="EXTERNAL"/><!-- (or the long-hand form
with both opening and closing tags) - no initial response, so the
server will respond with an empty string challenge - encoded as
<challenge>=</challenge> -->

In practise, many servers treat an input of "" as equivalent to NULL
in some cases, but that can cause confusion, particularly in the
EXTERNAL case where it makes a significant difference.

In this new proposal, an absent initial response can be encoded in two ways:

a) <authenticate mechanism="EXTERNAL"/>

b) <authenticate mechanism="EXTERNAL"><initial-response/></authenticate>

However a zero-length initial-response is always encoded as

We could change the profile such that this <initial-response/> meant a
zero-length (empty string), and drop "=" entirely, but we'd need to
then provide child elements for each case, and I would have some
concerns that because the SASL data encoding changes between profiles,
some errors may be made.

Still, perhaps this would be cleaner, and remove an edge-case that
seems to be causing problems in practise anyway.


More information about the Standards mailing list