#3862: Error in POP3 authentication via SASL mechanism DIGEST-MD5
-----------------------+----------------------
Reporter: g1pimutt | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone:
Component: POP | Version:
Resolution: | Keywords:
-----------------------+----------------------
Comment (by g1pimutt):
Replying to [comment:5 kevin8t8]:
> > The manual for sasl_client_step() says:
> >
> > "... in IMAP sasl_client_step should still be called one more time
with a serverinlen of zero."
>
> > (presumably "after it returns SASL_OK")
>
> No, I don't believe the above presumption is correct. They are pointing
out that you should follow the return codes, not assume that "+OK" in the
response means you are done. If there is another response needed from the
client, the sasl_client_step() should return SASL_CONTINUE, even if the
clientout is empty. SASL_OK means "the authentication is complete."
Unless I'm mistaken, after step 4 returns SASL_OK, authentication IS
complete, because the server has responded "I verified that you know the
password, here is my rspauth for you to verify that I'm authoritative for
the realm", and the client has successfully checked the rspauth. Now, per
the protocol, the client has to send an additional blank line: I'm not
sure that has anything to do with authentication.
>
> It looks like the code currently tries to handle the case where
rc==SASL_OK but the olen is set for some strange reason.
>
> But if what is happening is that olen==0, rc==SASL_OK, and yet there is
supposed to be another sasl_client_step(), that is clearly a bug in the
SASL libraries, and I don't think there is any good way to work around it
in the application (mutt) code.
Perhaps it's a bug for sasl_client_step to return SASL_OK at this stage,
and working around it is a mistake. But as far as I can tell, the code in
imap/auth_sasl.c does the same.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3862#comment:7>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
