Sorry, I shouldn't have put the password on the command line.
Assume that ndmpadm will prompt for the password in the usual
way (non-echoed).
# ndmpadm enable -a auth -u username
Enter new password:
Alan
----- Original Message -----
From: "Alan Wright" <[email protected]>
To: "Bill Sommerfeld" <sommerfeld 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 5:07 PM
Subject: Re: PSARC 2007/397 NDMP Service
> 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" <sommerfeld at sun.com>
> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
