Re: [nfsv4] [FedFS] Meeting Minutes, 12/10/2009

[James Lentini <[e-mail]>]

On Mon, 14 Dec 2009, Nicolas Williams wrote:

> On Thu, Dec 10, 2009 at 04:29:34PM -0500, James Lentini wrote:
> > + Admin NSDB Trust Anchor Management
> > 
> >   We reviewed our discussion from last week and the following 
> >   mailing list discussion.
> > 
> >   Trond noted that we need more detail on the proposals.
> > 
> >   James agreed. We discussed several potential security 
> >   options. It seems like there are three options emerging: 
> >   NULL, TLS, and SASL+Kerberos 5. It is unclear how useful 
> >   SASL+Kerberos 5 would be.
> 
> Kerberos will be helpful for federations where admins are willing to
> have cross-realm trusts.  That will likely be only subsets of
> federations, not whole ones.
> 
> TLS (LDAPS) / StartTLS seems like the way to go.  That means PKI for
> server certs will be the most common way to authenticate servers.  For
> client authentication we can have TLS client certs, or a per-{client,
> NSDB} password if need be and use SASL/DIGEST-MD5 or TLS w/ PSK.

Note that there are two different types of LDAP clients: fileservers 
and administrative hosts.

A fileserver requires read-only access to the NSDB. It is essential 
that a fileserver be allow unauthenticated access to an NSDB. 
Otherwise, NSDBs would require constant configuration updates as 
fileservers were added and removed. The exact text from the NSDB draft 
is:

   It MUST be possible for an unprivileged (unauthenticated) user to
   perform LDAP queries that access the NSDB data.  A fileserver
   performs the operations described in Section 5.2 as an unprivileged
   user.

The administrative hosts are required to authenticate to the NSDB. The 
mechanisms you describe above ("TLS client certs, or a per-{client, 
NSDB} password if need be and use SASL/DIGEST-MD5 or TLS w/ PSK") all 
strike me as good options. The NSDB draft says the following about 
this:

   The NSDB SHOULD be configured with one or more privileged LDAP users.
   These users are able to modify the contents of the LDAP database.  An
   administrator that performs the operations described in Section 5.1
   SHOULD authenticate using the DN of a privileged LDAP user.

Is it necessary to require a specific mechanisms for administrator 
authentication? I'd argue that the NSDB's administrator should have 
the freedom to choose an authentication mechanism.

> >   Trond asked if we could define a set of security options 
> >   and allow for future extensions. He suggested that a 
> >   possibility would be to include an opaque field with a format 
> >   determined by the security parameter, similar to RPC.
> 
> Extensibility should be required, and can be arranged, yes.

I agree.

> >   Trond suggested that, if the ADs were comfortable with this 
> >   approach, it would be reasonable to define one or two 
> >   security mechanisms now and defer the defining other options 
> >   until there was a need.
> 
> Sounds like you guys want to avoid the subject of TA mgmt.  I think the
> simplest thing to do is to pass the cert of one NSDB server to the
> fileserver, and publish the certs of all replicas of that NSDB server in
> the NSDB itself (the fileserver can then treat all NSDB servers as
> having pre-shared certs and to hell with TA mgmt).

I like the idea of passing the NSDB cert in the ONC/RPC Admin 
protocol. I will start working on an update to the Admin protocol with 
this capability.

Are there alternatives to publishing the replica certs in the NSDB? I 
can't think of a natural place for these certs in our current schema 
and DIT structure.