[Standards] Proposed XMPP Extension: Extensible SASL Profile
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
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