Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have

[Chris Newman <Chris.Newman@xxxxxxx>]

--On March 6, 2008 5:59:06 -0800 Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx> 
wrote:
> 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 
administrative
 credentials to back-end
* Has equivalent of both server & client nonces (to avoid CRAM-MD5 
server-only nonce
 weakness)
* 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 
every login
* Include a rarely used optional feature, such as a SASL security layer.
* Silly syntax variations that create interop problems (folding whitespace, 
etc).

Nice-to-have features:
* Complexity closer to CRAM-MD5 than DIGEST-MD5.
* Textual protocol like CRAM-MD5 over binary protocol that's harder to 
test/debug
* 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

		- Chris