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

[Nicolas Williams <[e-mail]>]

On Thu, Dec 03, 2009 at 03:54:30PM -0500, James Lentini wrote:
>   - NFS URL

This seems good to me:

	fednfs://<domain>/<path>

For all other paths use nfs://<server>/<path> (RFC2224), or change the
scheme to "nfs4".

See below.

>   - Client Processing of an NFS SRV RR 
>     (as defined in draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02)
> 
>     [...]
> 
>     Craig noted that there were two ways of naming a particular point. 
>     There is the traditional way, server://path/to/file, and a new 
>     SRV based name, roughly <domain> + <federated namespace path>.

Yes.

>     Paul speculated that the behavior of the OS mount command could be updated
>     to incorporate the federated naming. In particular, he wondered if the 
>     mount command would take a domain and mount the domain's federated root. 

The distinction between "server:/path" and "domain:/path" is very
important.  It must be made.  It must be made in URLs, and it must be
made in mount command arguments, and in automount maps, and GUIs.

See above.

>     We noted that an OS mount command could be augmented to include the 
>     process of (1) mapping from a domain to an SRV query string, 
>     (2) performing the SRV query and extracting the host fileservers running 
>     the service, and (3) mounting the fileserver + ".domain-root-<domain>" 
>     path. Another option would be to perform steps (1) and (2) separately 
>     and then input the result into the standard mount command.

Oh no, the mount command must do the whole enchilada.  Also, we can't
actually tell implementors what to do in their UIs.  What we can do is
create a distinct URI/URL scheme for domain-relative paths.  See above.

> + Admin NSDB Trust Anchor Management
> 
>   We briefly reviewed the mechanisms by which LDAP can be secured. LDAP 
>   connections can be secured using TLC or SASL. [Editor's note see RFC4513].

s/TLC/TLS/  (yes, lately TLS has needed TLC, but that's another story!  ;)

>   We discussed the following question who or what determines if a fileserver's
>   NSDB connections are secure. We asked if the ONC RPC Administrative protocol 
>   should indicate, possibly at junction create time, the desired security 
>   properties to use for an FSN's resolution.

In order to use TLS for this you only have two choices:

 - server certs (here's where TA mgmt comes in)
 - PSK (pre-shared keys), which is not really scalable here, so I say to
   heck with PSK

As for SASL... you have these choices:

 - PLAIN

   PLAIN offers no real security unless you're running over TLS and
   authenticating the server via TLS, but since that's all we want to
   do, PLAIN is not applicable!

 - DIGEST-MD5
 - SCRAM (on the RFC-Editor queue now)

   These are not unlike PSK in terms of scalability, ergo: not scalable,
   ergo not applicable for us.

 - GSSAPI (RFC4752) or GS2-KRB5, meaning Kerberos (GS2-KRB5 will soon be
   on the RFC-Editor queue)

   I.e., Kerberos.  As long as you're willing to have cross-realm trusts
   for this, this is an available choice, and it will scale.

So we really only have two choices for server authentication:

 - TLS with server certs (and TA mgmt, since we're NOT going to have a
   global PKI)

 - Kerberos V5 (via SASL/GSSAPI or SASL/GS2-KRB5)

By far the most likely case in actual federated deployments will be "TLS
with server certs".  It's just simpler (e.g., no need to talk to
Kerberos realm administrators).

>   There are at least three different ways the security properties of an NSDB 
>   connection could be derived: (1) each implementation could have its own 
>   policy and settings, (2) the ONC RPC Admin protocol could indicate the 
>   desired security mechanism, or (3) the NSDB could require a particular 
>   security mechanism.

(3) is not quite right: it's the _client_ that wants to authenticate the
_server_ here, not vice-versa.  The reverse of (3) is really what you
wrote for (1).  The server might want to insist on confidentiality
protection, in which case it will want to authenticate the client, but
the bottom line is that the most important thing here is that the client
authenticate the server.

>   Trond asked if there was a standard way for LDAP to indicate the required 
>   level of security. If so, it could be used as an auto configuration 
>   mechanism. James noted that there are ways for a user to indicate to 
>   an LDAP client that a security mechanism should be used (ldap:// versus
>   ldaps:// to request standard versus SSL/TLS connections respectively or 
>   the various SASL configuration settings). James was not aware of any 
>   way to automatically determine if an LDAP directory should be contacted 
>   via TLS, SASL, etc. 
> 
>   [AI] James Lentini will investigate if an LDAP client can automatically 
>        determine the security properties of an LDAP directory.

See above and below.

>   James suggested that it could be dangerous for a fileserver to depend 
>   totally on an NSDB for indicating the security mechanism for an LDAP 
>   connection. For example, a impostor might setup a rogue NSDB that 
>   indicated no security was necessary (and hence the NSDB did not need to 
>   be authenticated).

Exactly!

>   We discussed the security properties desired for an NSDB connection.
>   If security is a concern, the fileserver will want to authenticate the 
>   identity of the NSDB and have protect the integrity of the LDAP connection. 

Note that the identity of the NSDB, in the sense of having a "name" is
not important.  The identity of the NSDB in the sense of it have
authentication credentials that match what the ADMIN client meant (when
they created the junction) is important.  A very subtle distinction, I
know, but think of self-signed certs -- the names they bear are not
important, but the names you take them to authenticate are.

>   Privacy did not stand out as a concern on the call. [editor's note: while 
>   writing up these notes, I realized that privacy is also desirable. The 
>   contents of an FSL, for example the path name, may convey information 
>   that the federation members which to keep private].

Confidentiality protection may or may not be desirable; it should be
OPTIONAL.

In practice TLS is always used with confidentiality protection, so this
is practically moot, except that a server that wants confidentiality
protection also wants to authenticate (and authorize) clients.

>   James suggested that the fileserver administrator would have a 
>   vested interest in ensuring that the fileserver's referrals were 
>   valid. Therefore, the administrator will want the ability to 
>   configure the security properties used to resolve an FSN.

Yes.

>   Trond pointed out that the fileserver must be able to query the NSDB 
>   over a long period of time. This leads inevitably to the topic of 
>   key/certificate management.

With Kerberos, for example, this is non-issue.

With PKI this is a real issue.  The ADMIN protocol may need a procedure
by which to list soon-to-expire certs/TAs and a procedure to update
them.

Nico
--