A simple usecase being ignored

[Mathias Laurenz Baumann]

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

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