Re: SASL success responses

[Simon Josefsson]

Glenn Maynard <address@hidden> writes:

> Context:
>
> The "success" response sent from server to client in step three of
> DIGEST-MD5 contains the "rspauth" key.  There seem to be two ways this final
> message can be sent, according to [1].
>
> A: The rspauth message can be sent as the body of the success message.
>
> S (challenge): realm="example.com",nonce="...",...
> C (response): nonce="...",response=...
> S (success): rspauth=...
>
> B: The server can send the rspauth message as a challenge, expect an empty
> response, and then send success with no message.
>
> S (challenge): realm="example.com",nonce="...",...
> C (response): nonce="...",response=...
> S (challenge): rspauth=...
> C (response): ""
> S (success): (null)
>
> The DIGEST-MD5 implementation in gsasl seems to do the latter.  This wastes
> a round-trip, so I looked into eliminating it.  It seemed trivial: at the
> end of step 1 in digest-md5/server.c, return GSASL_OK instead of
> GSASL_NEEDS_MORE.
>
> However, when gsasl_step() returns GSASL_OK, how does it distinguish whether
> the output is the empty string or no response at all?  In B above, the
> success response is not the empty string, but null (DIGEST-MD5's third and
> final step concluded with the second challenge).  rfc6120 [2] explicitly
> distinguishes these: if success does not contain data at all it sends
> <success/>; if it contains zero-length data it sends <success>=</success>.
>
> Currently, my code (a minor patch to jabberd2) assumes that if gsasl_step()
> == GSASL_OK and strlen(out) == 0, it means to send no response rather than
> an empty response, but that's a brittle assumption.  The obvious thing would
> be for gsasl_step's "out" parameter to be set to NULL, but it doesn't do
> that.

Hi Glenn!  Thanks for your interest and pondering here.  I agree with
you, and I changed the logic for 1.5.0 and later and it does return
GSASL_OK in step 1.  Which version are you looking at?

However I never resolved in a good way your followup-question.  I think
your idea to separate OK-without-data from OK-with-empty-data by using
NULL vs "" is a good idea.

I am worried what effect this would have on existing applications,
though, if they now start to receive NULL on GSASL_OK.  And whether we
would have to bump the ABI version due to this.  But I never did for the
GSASL_OK/GSASL_NEEDS_MORE change, so I guess we could do this.

/Simon