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

[James Lentini <[e-mail]>]

On Thu, 3 Dec 2009, Nicolas Williams wrote:

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

We discussed performing steps (1) and (2) separately in the context of 
backward compatibility with existing tools. 

I guess I was doing too much talking and neglected to capture that. :)

> Also, we can't actually tell implementors what to do in their UIs.

I noted that a protocol specification would not be the proper place to 
define the behavior of the mount command. 

Again, I inadvertently omitted that from the minutes.

> 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!  ;)

Good catch.

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

What about these other SASL authentication mechanisms:

http://www.iana.org/assignments/sasl-mechanisms

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

This is great information, but we were discussing a different question 
than what security mechanism are possible.

In the current Admin protocol, the client can request a fileserver to 
create a junction but does not have a mechanism for indicating the 
authentication,integrity,and privacy mechanisms to use when resolving 
the junction. The question is therefore, should the Admin protocol's 
JUNCTION_CREATE arguments include a parameter that indicates how the 
junction should be resolved in the future?

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

Doesn't Active Directory use SASL with Kerberos? 

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