Requirement of plaintext pass for sasl_setpass
Mathias Laurenz Baumann
marenz at supradigital.org
Tue May 25 13:06:17 EDT 2010
Greetings,
I was wondering if there is another way to add a new user without ever
sending his real plain-text password over the wire and without the server
knowing the plain-text password? I think in SRP this should be the case,
but I was confused by the sasl_setpass method, because it seems to require
an plain-text password.
What I was also wondering about: If a client chooses SCRAM-SHA (let's say,
while it is registering) and then later chooses a different one like SRP,
isn't this a problem because you can't "convert" the secret that SCRAM
uses to the one that SRP uses? (I don't know SCRAM in detail, but I think
it has a secret instead of a password, for the sake of the example let's
assume this here). I guess this is closely related to my first question :)
And while I am at it, another question: Did I understand it right that
libsasl also provides the encryption itself with the sasl_encode functions
and no ssl is required anymore if one uses this? And can I use sasl_encode
even when a user didn't authenticate yet (for example to secure the
registering process)? If not, I would have to setup an encrypted
certificate based TLS encryption just for the registering process and then
use sasl_encode from that point on. Which is kinda .. redundant.
In the protocol([1]psyc), it should be possible to "link" a client to
several personalities, that's what I want to use sasl for. But the RFC and
the libsasl documentation says there should only be one context for one
connection. Of course I could just ignore that, but first I want to know
your opinion on that matter. Is it a good choice to ignore that? Are there
alternatives? And of course it could confuse the encryption layer as to
which context to use for which transmission (in that case I would just
declare that the first link to a personality is the one that will be used
for encryption... at least if I am going to use sasl_encode).
--Marenz
[1] http://about.psyc.eu/Specification (dont bitch about the organisation,
I agree that it sucks)
More information about the Cyrus-sasl
mailing list