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@xxxxxxxxxxx
ldapdb_pw: oldsecret
ldapdb_mech: SRP
mech_list: SRP OTP
EOF
echo "newsecret" | saslpasswd2 -p -n -a password jsmith@xxxxxxxxxxx
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
