[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
--On March 11, 2008 5:14:14 -0700 Steven Simon <simon.s@xxxxxxxxx> wrote:
I would like a client-first mechanism that sends the username before the
challenge. My system supports multiple directories so I need to be able to
route the session to the correct one based on the user account location.
I'd put this in the nice-to-have category. The earlier the username is
sent, the more proxy-friendly the mechanism becomes, but there are ways to
deal with this otherwise.
Desirable on-disk hash features:
* salted
* iteration count
Obviously, I agree these are desirable as they're in SCRAM ;-). I consider
the iteration count necessary if the mechanism is to have any utility
without TLS.
• ability to switch algorithms in case the hash-du-jour is compromised
The auth mechanism should communicate the on-disk hash type and
iteration count so that the client can convert the cleartext to the right
hash before producing the response. We don't want to have to reconfigure
the
clients.
Hash agility is needed, but sub-negotiation can create more problems than
it solves. To keep the mechanism and negotiation simpler, I'd prefer the
hash be part of the mechanism name and we simply have a different mechanism
for each hash. The agility plan needs to be written, but I prefer an
approach where clients "latch-up" to better mechanisms, handle a
transition-needed error code gracefully and servers aggressively populate
all supported password verifiers whenever possible (e.g. password change
and/or successful use of TLS+plain).
BTW: we do use the privacy layer, though I think we can work around its
exclusion.
Interesting. Do you also support TLS? Would your code be simpler with TLS
and channel bindings but no SASL privacy layer?
- Chris