A simple usecase being ignored

[Mathias Laurenz Baumann]

After reading over my mail again, I saw some potential bad  
phrased/explained points. Let me clarify here:

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

Registering means the one-time process of creating an account on the  
server.
After that they can just "link" to their identities. For that they need to  
auth using sasl.

>
> 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).
>
> 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.
>
> * To get the secret, the client has to call sasl_setpasswd with the  
> appropriate mechanisms enabled (at least SRP) which will use the auxprop  
> plugin(s) to set the secret.
> ** I can either write my own small auxprop plugin that does nothing more  
> than providing the secret to the host application or
> ** I call the mechanisms setpasswd function myself and change the  
> parameter for sasl_setprop (or something like this) to my own  
> host-internal function.

What I mean here is, sasl calls the mechanisms setpasswd function and  
provides structs with function-pointers for utility functions as well as  
functions like sasl_setprop. I would create a copy of that structure and  
change the provided function-pointer for sasl_setprop to a function in my  
host application

This is my first proposal for a change in libsasl:

> Both solutions are ugly hacks in my opinion and yet the solution to this  
> would be very simple: A mechanism specific function that gets the  
> password and returns the secret.

(just to make sure it doesn't get over-read)

> A third possibility exists:
> ** Write a auxprop plugin that does the registering process itself. I  
> don't like this solution, as it requires creating a connection and takes  
> away the control from the library user. But this would be the only one  
> not being an ugly hack.
>
> * the server manages the storing itself, yet libsasl requires me to  
> write a auxprop plugin which would in turn just call/forward the calls  
> back to the server. Also an ugly hack.

And this my second proposal:

> Again, the solution would be very simple: let the hostapplication  
> provide some callbacks in libsasl so it can take care of  
> fetching/storing.

(..)

>
> On a side note:
> I discovered, that only SRP and OTP use prop_set to store their  
> cmusaslsecret* using the auxprop plugin and that for example CRAM  
> doesn't provide a setpasswd function at all. I don't understand why?  
> Doesn't CRAM (and some others) use only a secret for authentication? How  
> would the cmusaslsecret for CRAM be created?
>
>
> I was very surprised to discover that these very simple usecases are so  
> difficult to realize. I assumed this would be the normal usecase.
>
> what do you think about my proposed changes/extensions to libsasl?
>
>
> Greetings,
>
> 	--Marenz