Re: [FedFS] Meeting Minutes, 12/03/2009
James Lentini <jlentini <at> netapp.com>
2009-12-03 22:32:35 GMT
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
> --
>
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Mike Thompson is the EMC contact.
RSS Feed