New proposal: introduce enable and disable sub-commands to
ndmpdadm and the use of separate username and password
properties per authentication algorithm.
ndmpadm enable -a auth -u username -p password
ndmpadm disable -a auth
- where auth is currently one of: cram-md5 or cleartext.
Authentication algorithms can be added or obsoleted without
breaking the interface. No interface will be provided via
ndmpadm to view the username or password and issuing an
enable command again will replace the current values for
that algorithm.
The service will use a separate username property and password
(secret) property per authentication algorithm.
The username and password property values will be initialized
to null. ndmpd will only offer authentication algorithms with
a non-null password during connection negotation. Disabling
an authentication algorithm will set the appropriate username
and password properties to null.
We will allow both secrets to have the same value but recommend
best practice in the documentation. We will recommend against
cleartext unless there is no other option.
With clients supporting cram-md5, end-users will only have to
issue a single command to enable the service:
ndmpadm enable -a cram-md5 -u username -p password
Alan
----- Original Message -----
From: "Bill Sommerfeld" <[email protected]>
To: "Alan Wright" <Alan.M.Wright at Sun.COM>
Cc: "Gary Winiger" <gww at eng.sun.com>; <Michael.Shapiro at Sun.COM>;
<PSARC-ext at sun.com>; <Barry.Greenberg at Sun.COM>; <Reza.Sabdar at Sun.COM>
Sent: Friday, August 24, 2007 3:08 PM
Subject: Re: PSARC 2007/397 NDMP Service
> On Wed, 2007-08-22 at 16:11 -0700, Alan Wright wrote:
> > Sorry we don't have that information and we are unlikely to
> > be able to provide a definitive answer. Some clients use
> > only plain-text, some use cram-md5. ndmpd supports multiple
> > versions of the protocol and there are may be some older
> > clients that use plain-text but newer revisions of those
> > same clients use v4 and cram-md5.
>
> I took a look at the ndmp protocol spec. It looks like the NDMP v4 spec
> allows a client to query the server for the list of supported
> authentication algorithms. But I was hoping to get data on actual
> observed v4 client behavior when connecting to a server which did both.
>
> (ndmp.org failed to let me download the v3 spec so I couldn't tell when
> this showed up).
>
> To summarize the state of this issue:
>
> original proposal:
> plaintext and cram-md5 always enabled
> single secret used for both protocols.
>
> my proposed change:
> separate secrets for each protocol;
> - setting secret to null (default out of box config) disables
> protocol
> - allows best practice operation (never use same secret with
> multiple algorithms).
> - setting both secrets to the same value allows behavior like
> the original proposal if you really want that.
>
> project team counterproposal:
> single secret value, and a second parameter listing enabled
> protocols which use the single secret value.
>
> I still don't like the counterproposal. It's still built around a
> really horrible idea (potentially using one secret with more than one
> protocol/algorithm) which I don't want to see copied by other projects.
> And I don't really think it's either more or less usable than my
> suggested change.
>
> In particular, a big part of security usability is being transparent
> about what's going on under the hood, and from that standpoint, having
> separate per-protocol secrets makes it much more likely that the admin
> setting policy is aware that there are meaningful differences in
> security between v4 and earlier protocols.
>
> But the only even vaguely sensible security policy is to avoid pre-v4
> clients and configure the server for md5-only, and in that configuration
> (only) there's no practical difference.
>
> So I'm torn.
>
> - Bill
>
>
>
>
>
>
>
>
>
>
>
