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

[Nicolas Williams <[e-mail]>]

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.

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

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

Nico
--