RE: beep+sasl+srp draft issues

Hi Stephen,

Some responses below.

> - We want to hash the userid in case the user types her
> password into the "username" box. We could do this above
> SASL-SRP or else could try get the SASL-SRP draft to include
> the trick itself (I prefer the latter). Any opinions?
> 

As I've stated before, I've never felt this was necessary to do in the first
place, so I'd say neither. If the password is entered in the "username" box,
then I presume nothing would be entered in the "password" box.  Can't the
client just ensure that both fields are populated before communicating with
the server. It just seems annoying as well for the server to have to key on
the hash of the username.  

> - The sacred-pdm draft had an "extra" rsa private key which 
> was used for signing credential uploads - do we want to 
> maintain this feature? (The reason for it was to make
> it harder to benefit from stealing the server's database.)
> 

Where does the user obtain this key pair from?  From the credential server?
I'd prefer if the credential server didn't have to act like a CA as well.
The user can just register one of their credentials for authenticating to
the credential server, or use their password as for credential download.

Thinking about how this might actually be built, the credential server might
exist in the same organization as the user, and hence, could be initiated
with the CA trust anchor, allowing the credential server to trust users
issued certificates by this CA.

> - SASL-SRP makes it easy to authenticate and derive keys for
> credential download, changes etc, but what about initial
> registration? Is that to be offline only or do we need
> to have a credential deposit operation that uses some other
> "in-payload" security?
> 

It could be offline (as initial authentication in CMP), or could be online,
with the user authenticating with their credentials. As I indicate above, in
an enterprise environment, the credential server could have a CA trust
anchor installed, allowing them to trust all certificates issued by this CA.
Users can then use their own authentication credentials to authenticate to
the credential server for initialization, and upload. (Download, of course,
would still have to be password based.)  

In case the user doesn't have such a relationship established with the
credential server, their likely needs to be some offline mechanism, e.g.
user registers with and obtains an "authentication code" from the credential
server.  (This assumes that the client must actually be properly identified
to the credential server.  Couldn't the client just anonymously register a
set of credentials, establish a password, and thereafter, use that password
for authenticating to obtain the registerd credentials.  I remember thinking
about this before, but can't recall if concluded it was a good or bad
idea....)

> - The sacred-pdm draft had some notes about "away-from-home"
> operation, which is harder using SASL (unless we put the 
> SASL PDUs in our payload as Magnus suggested). Do we want
> to support this & if so, how?
> 

I'm not sure.

Cheers,
Mike