Requirement of plaintext pass for sasl_setpass

[Dan White]

On 25/05/10 19:06 +0200, Mathias Laurenz Baumann wrote:
> 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.

Users do not need to be created with sasl_setpass or other SASL utility,
and often are not, such as when using PAM for authentication.

That's also true when storing cmusaslsecretSRP for SRP authentication,
which can be stored using any method supported by the auxprop store, such
as the mysql client when using the SQL auxprop plugin.

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

Right. In the case where you don't want the server storing the secret
directly, you'll need to store both auxprop attributes such as
cmusaslsecretSRP and cmusaslsecretOTP when preparing to use the SRP and OTP
mechanisms.

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

Cyrus SASL can encrypt the session on the fly using a SASL security layer.
That doesn't depend on using network based SSL/TLS, but is sometimes used
in addition to it for further protection.

SASL security layers depend on successful authentication, so your new users
will either need to know a password, or be able to authentication in some
other form, such as with GSSAPI, EXTERNAL over STARTTLS, or EXTERNAL over
Unix domain sockets, among others.

If you use a network enabled auxprop plugin (SQL or LDAPDB), and you allow
users permissions to change their own security credentials, then you could
assign a temporary password and let them change it themselves.

Since LDAPDB support SASL authentication, you could configure your LDAP
server to perform SASL authentication using the very same cmusaslsecretSRP
that you allow them to change.

For example, given a user that has libsasl and related utilities installed
on their client system, and assuming proper configuration of the LDAP
server, the client could do:

cat > /usr/lib/sasl2/password.conf << EOF
auxprop_plugin: ldapdb
ldapdb_uri: ldap://ldap.example.net
ldapdb_id: jsmith at example.net
ldapdb_pw: oldsecret
ldapdb_mech: SRP
mech_list: SRP OTP
EOF

echo "newsecret" | saslpasswd2 -p -n -a password jsmith at example.net

In which case the clear text secret never leaves the client system, and
only the SRP and OTP mechanisms are called upon to store their
security attributes. 

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

Experience shows that using the authentication/authorization paradigm along
with access control lists offer a well understood and extensible security
model.

-- 
Dan White