Requirement of plaintext pass for sasl_setpass

Mathias Laurenz Baumann marenz at
Tue May 25 13:06:17 EDT 2010


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).


[1] (dont bitch about the organisation,  
I agree that it sucks)

More information about the Cyrus-sasl mailing list