Initial client responses with GNU SASL

[RichardSteele]

I've come across a (misconfigured) SMTP server which requires clients to supply an initial response with SASL authentication although it is supposed to be optional. This has lead me to VMime's default SASL implementation based on GNU SASL:

vmime/src/vmime/security/sasl/builtinSASLMechanism.cpp

Lines 141 to 145 in 43b262b

	bool builtinSASLMechanism::hasInitialResponse() const {
	// It seems GNU SASL does not support initial response
	return false;
	}

In fact, GNU SASL can be used with initial responses. It's just a matter of the underlying protocol (IMAP/POP3/SMTP) supporting it and the mechanism being client-first. Of the mechanisms implemented by GNU SASL all but CRAM-MD5 and DIGEST-MD5 are client-first.

A minimal change would be to give builtinSASLMechanism a new boolean member m_initialResponse and do something like

builtinSASLMechanism::builtinSASLMechanism(
	const shared_ptr <SASLContext>& ctx,
	const string& name
)
	: m_context(ctx),
	  m_name(name),
	  m_complete(false),
	  m_initialResponse(name == "PLAIN" || name == "LOGIN" || name == "EXTERNAL" || name == "ANONYMOUS" || name == "SCRAM-SHA-1" || name == "SCRAM-SHA-256" || name == "NTLM" || name == "SECURID" || name == "GSSAPI" || name == "GS2-KRB5" || name == "SAML20" || name == "OPENID20") {

}

bool builtinSASLMechanism::hasInitialResponse() const {

	return m_initialResponse;
}

Another way would be to check if the name is contained in a std::unordered_set instead of comparing all names. Or you could reduce the amount down to those mechanisms that are fully supported by SASLSession::gsaslCallback.

Additionally, IMAPConnection::authenticateSASL should be changed so that the initial response is used only if the server supports the SASL-IR capability.

These would be behavioural changes. So what do you think?

[vincent-richard]

Hi!

This would be a useful addition to the SASL support, indeed.

At first, I didn't like comparing the mech name for determining whether there is an initial response, but after checking the API, it seems there is no easy way of doing it (aside from instantiating a SASL session for each mech and testing whether gsasl_step() with empty input buffer returns GSASL_NEEDS_MORE...).

[RichardSteele]

Yes, unfortunately there's no API function for that since it's implicit knowledge. Calling gsasl_step() with an empy input won't help you. If you look at its implementation you'll see that it just delegates to the specific mechanism. And PLAIN doesn't even care about the input.

[Neustradamus]

@vincent-richard: Can you look for SCRAM support?

Linked to:

• SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports #279