Bill Sommerfeld wrote:
> On Tue, 2007-08-14 at 15:44 -0700, Alan Wright wrote:
> > > I don't see any way to require the exclusive use of CRAM-MD5 when we
> > > know that the peer supports it (to avoid a downgrade attack).
> >
> > The CRAM-MD5 hash is never stored. ...
>
> this does not actually answer my question.
>
> Maybe I can explain better:
>
> regardless of how the secret is stored, and regardless of which end of
> the protocol you're implementing, if your configuration inherently
> permits a single configured secret value to be used with multiple
> authentication algorithms (sometimes as a CRAM-MD5 HMAC key, sometimes
> as a plaintext password), you are creating a significant potential
> vulnerability to a downgrade attack, even if you always try the
> strongest algorithm first, because it is almost always possible for an
> an attacker to interfere with a negotiation to make it appear to fail.
>
> A configuration of this form implies that sometimes you use the
> plaintext password, and sometimes you use the exact same value as a
> CRAM-MD5 key. this is not cryptographically sound; there must be some
> way to configure the system (both client and server) to only use
> CRAM-MD5 and not use plaintext password directly, or to only use a
> plaintext password, or to use one value as a CRAM-MD5 key and another as
> a plaintext password.
We can introduce a configuration parameter of the form below,
which would allow an administrator to control the authentication
mechanisms offered by the NDMP server during the negotation phase.
ndmp_auth={all|cram-md5|plain-text}
all: All available authentication mechanisms are
offered. The client can select from the list.
cram-md5: CRAM-MD5 only.
plain-text: plain text only.
NDMP clients don't offer the end-user an option to select an
authentication mechanism and only support a single username
and password. Without a client-side interface to control which
authentication mechanism the client should choose, I don't
think there is any value in supporting multiple passwords.
Alan
