[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 6, 2008 5:59:06 -0800 Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx>
In response to reviewer comments on our charter proposal, we need to
quickly produce replacement text which clarifies the qualities we desire
the DIGEST-MD5 replacement mechanism to have.
I'd like one or two persons (working together) to take a quick stab at
this (for initial WG review BEFORE our IETF#71 session). Any volunteers?
As a technical participant
The qualities I want are:
* Simple username/password mechanism that is hash-based.
* Minimize administrative set-up cost
* Ability to store a password verifier in LDAP (or other identity store)
that is not
the password itself
* Ability to use one layer of reverse/server-side proxy where the proxy
doesn't have a
direct copy of the password verifier database and doesn't require
credentials to back-end
* Has equivalent of both server & client nonces (to avoid CRAM-MD5
* Support for channel bindings to TLS
* Support for authentication & authorization ID
Things mechanism should not do:
* Require client UI for realm selection
* Require client-side configuration for the authentication mechanism itself
* Require a write operation to the server credential verifier database on
* Include a rarely used optional feature, such as a SASL security layer.
* Silly syntax variations that create interop problems (folding whitespace,
* Complexity closer to CRAM-MD5 than DIGEST-MD5.
* Textual protocol like CRAM-MD5 over binary protocol that's harder to
* Support for mutual authentication (may be an option)
* Server-stored password verifier that is not plaintext-equivalent
* Mechanism that's useful without TLS
* Minimize round-trips
* Avoid ASN.1
* Avoid expensive public-key operations in authentication mechanism