Re: beep+sasl+srp draft issues

Hi Stephen,

Comments inline.

Best Regards,

Dale Gustafson


Stephen Farrell wrote:

> All,
>
> In transforming the sacred-pdm draft to the above, I've come
> across the following issues, about which I'd appreciate your
> feedback and/or ideas.
>
> - 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?

preference 1)  skip it.  do appropriate UI checking in the client

preference 2)  send in hash(user-id) as part of SASL-SRP authenticated login
sequence.

Base-64 encode of the hashed user name should work fine with the SRP draft as
is.

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

Defeats one benefit of any strong-pw protocol which requires nothing to be
preconfigured in the client.

Seems like time would be better spent protecting the server's database.

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

I think we've previously agreed that the Admin <--> credential server interface
is out of scope for now (e.g., offline or server specific).

Implies that admin activities such as installing SRP info. that must be known
apriori by the server (user name, salt, password verifier, etc.) would not be
part of the credential exchange protocol.

I'd be inclined to stick with that for now although I can see the benefit of
some type of self-registration feature.

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

Seems like an unnecessary complication.

Why can't the roaming user access the target credential server directly?
Clearly, she can access lots of other things directly.

> I'm sure there'll be more as I go through it, but that's
> enough for now.
>
> Stephen.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.               mailto:[email protected]
> Ireland                            http://www.baltimore.com