A simple usecase being ignored

[Kari Hurtta]

Dan White <dwhite at olp.net>: (Sun Aug 15 05:57:15 2010)
[ Charset ISO-8859-1 converted... ]
> 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?

Hmm. On SRP server does not need know plain-text password and these
values what are send to server are not usefull -- replaying them does
not help. Values depends also what server sends as challenge.

http://srp.stanford.edu/whatisit.html

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