A simple usecase being ignored

[Dan White]

On 10/08/10 08:03 +0200, Mathias Laurenz Baumann wrote:
> Greetings,
>
> I plan to use sasl for a conferencing protocol. Users would register 
> using a simple registering mechanism using the protocol itself, before 
> they link themselves to their identities.
>
> I don't want my server to ever know the plain-text password. So I mainly
> want to use SCRAM and SRP.  The server itself takes care of storing the
> secrets (I define a secret as something that proves that you know the
> password).

Try using a saslauthd backend that supports hashing, such as pam_unix,
which would use a typical crypt(1) verification on the user supplied
password. User management can then be handled outside of libsasl and would
not require any extensions, or use of auxprop.

> For this to work, a client would simply transmit the secret (not the 
> plain password- in the registering process so the server can add it
> to its database. There are several problems in this scenario and the  
> library as it is now.

If the user is sending a pregenerated value to the server, it's really a
password either way. For instance, what happens if the secret is captured
over the wire by an attacker?

> I was very surprised to discover that these very simple usecases are so  
> difficult to realize. I assumed this would be the normal usecase.

SASL mechanisms, in the protocol sense, are not really designed to get
involved with account management or creation. You should aim for a clear
distinction between authentication and account management (or lack thereof)
in your protocol design.

 From a server implementation perspective, if you are using the Cyrus SASL
library to implement your SASL support, you shouldn't really know or care
how passwords are stored. That should be a security decision made by the
system administrator via SASL config files.

Augmenting auxprop, or adding addition auxprop plugins should also be a
separate activity from your protocol design, and server implementation.

-- 
Dan White