Re: beep+sasl+srp draft issues

Re: the mysterious encrypted private key in PDM.

The purpose of that was to make it so that someone couldn't use
a stolen copy of the server database to directly impersonate the user.

If we're only downloading credentials, this is not an important
property, since someone who stole the server's database already
has the credentials.

However, for "logging in" to the credential server for the purpose
of uploading new credentials, it seemed like a valuable property.

This property is known in the strong password biz as "the augmented property".
PDM accomplishes the augmented property with an RSA private key which
must be transmitted to the user, who can decrypt it with her password.
Someone who steals the server database cannot use it directly because
it requires knowing the user's password.

SRP accomplishes the augmented property by having the server store
g**W, where W is a hash of the password, and in the key generation
it requires the client to directly know W.

Since PDM was using an RSA key, we were saying that key could actually
be the user's credential. But SRP has no such quantity that gets
passed to the user, so with SRP it's just doing SASL-SRP which
authenticates to the credentials server and the credentials server
then transmits the credential. There's no option with SRP of having the
user already obtain the credential as part of the strong password
mechanism.

Radia