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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Chris Newman <Chris.Newman@xxxxxxx> writes:

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

Very useful summary.

I agree with all those requirements, except that I have some reservation
about using a textual protocol.  My experience with DIGEST-MD5 has been
that the free format created more problems than it solved.  There are
still interop problems with quoted text.  I recall interop problems
caused by the specification permitting empty comma sequences like ", ,".

If it is a textual protocol, I would want it to only permit ONE way to
say the same thing.  Reordering parameters so that 'foo=bar,baz=apa' is
equivalent to 'baz=apa,foo=bar' is bad.  Permitting whitespace so that
'foo=bar, baz=apa' is also equivalent is bad.  Using quoting, so that
'foo="bar",baz=apa' is also equivalent is bad.  Allowing unrecognized
parameters to be skipped is bad.  And so on.

If this approach is used, I would prefer a textual protocol too.

Finally, there is no conflict between avoiding ASN.1 and using GSS-API.
The ASN.1 used by GSS-API is minimal and does not need a DER parser or
encoder.

/Simon