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

From: James Lentini <[email-masked]>
Date: Thu, 3 Dec 2009 15:54:30 -0500 (EST)

FedFS Meeting Minutes, 12/03/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Sorin Faibish (EMC)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Chris Stacey (EMC)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ Review Action Items

  - Chris Stacey will writeup a description of an SNMP MIB.

    Complete.

    Chris summarized our discussions over that past few weeks in an 
    email to the list. Chris summarized the genesis of the idea 
    standardizing statistics, asked if this was within the scope 
    of the NFSv4 WG, and asked for feedback on how to approach the 
    problem.

    Chris is going to chat with his colleagues about SMI-S. Sorin 
    is going to investigate the SNMP MIB.

+ Mailing List Questions

  We discussed Paul's mailing list questions.

  - NFS URL

    We discussed the RFC 2224 definition of a NFS URL. It defines the NFS URL 
    format for NFSv2 and NFSv3, but not NFSv4. This RFC is part of WebNFS. 

    This was not the type of NFS URL Paul was asking about.

    Trond noted the NFSv4 has a public filehandle concept, but the 
    mechanism for obtaining it, the NFSv4 PUTPUBFH operation, is 
    different from WebNFS.

    We discussed the difference between a fileserver's namespace and a 
    federated namespace. An NFSv4 fileserver has a / pseudo root directory.  
    Such a fileserver may also host the root of a federated namespace. For 
    example, the federated namespace root for example.net would be located at 
    /.domain-root-example.net on an NFSv4 fileserver. 

    A fileserver's pseudo root and federated namespace root are intentionally 
    different. This allows for greater flexibility. A single server can be 
    the root of multiple namespaces, contain other directories, etc. 

    A junction may be present at any point beneath the federated root and 
    point to an arbitrary location (the target of a junction does not need 
    to be beneath /.domain-root-example.net).

  - Client Processing of an NFS SRV RR 
    (as defined in draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02)

    To mount a federated namespace, say example.net's namespace, the NFS client 
    will look up the NFS SRV record at_nfs4._write._domainroot._tcp.example.net
    in DNS (assuming the client wants a read/write view of the namespace).
    The SRV record will have one or more host names implementing the service
    (e.g. nfs1tr.example.net).

    The NFS client will then mount nfs1tr.example.net://.domain-root-example.net 
    at /nfs4/example.net in the client's local namespace.

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

    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. 

    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.

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

  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.

  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.

  We reviewed some of the advantages and disadvantages of these options.

  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.

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

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

  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.

  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.

  [time - we plan to continue discussing this topic on the WG email 
   list and at next week's meeting]

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Dec 2009 15:12:32 -0600

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

>     [...]

Yes.

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

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

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

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

>   desired security mechanism, or (3) the NSDB could require a particular 

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

>        determine the security properties of an LDAP directory.

See above and below.

>   indicated no security was necessary (and hence the NSDB did not need to 

Exactly!

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

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

>   configure the security properties used to resolve an FSN.

Yes.

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

---

From: James Lentini <[email-masked]>
Date: Thu, 3 Dec 2009 17:32:35 -0500 (EST)

On Thu, 3 Dec 2009, Nicolas Williams wrote:

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

Good catch.

>    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

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

> Kerberos realm administrators).

Doesn't Active Directory use SASL with Kerberos?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Dec 2009 16:41:59 -0600

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

They are clearly not applicable:

 - KERBEROS_V4 is obsolete.
 - SKEY is obsolete.
 - EXTERNAL means "look at the secure channel we're using, likely TLS"
 - CRAM-MD5 is of limited applicability, and anyways fails to be useful
   here for the same reasons as DIGEST-MD5 and SCRAM
 - ANONYMOUS clearly doesn't help
 - OTP doesn't help
 - GSS-SPNEGO isn't relevant (you don't want to use it, ever)
 - SECURID clearly doesn't help
 - NTLM is like Kerberos, but with obviously much more limited
   applicability
 - NMAS_* -- I've no clue what they are, and I doubt they are
   applicable, and they are listed as having LIMITED use
 - 9798-* are for authenticating clients, while we want to authenticate
   servers
 - KERBEROS_V5 is not really in use, and anyways we have "GSSAPI" and
   GS2-KRB5 (see previous e-mail), which are applicable

> than what security mechanism are possible.

You have to take into account what's actually available.  And my post
did address the issue of what properties are desired.

> junction should be resolved in the future?

To me it makes no sense to talk about TA mgmt in the ADMIN protocol if
we don't either a) require TLS with confidentiality protection and
server certs, or b) make NSDB LDAP connection security parameters
configurable via the ADMIN protocol.  To me this is an obvious yes.
(I've not actually reviewed the ADMIN protocol in detail though.)

> Doesn't Active Directory use SASL with Kerberos? 

That's one way to use it (you have to in order to access non-public data
-- object attributes that have ACLs that don't grant read permission to
Everyone).

Nico
--

---

From: Daniel Ellard <[email-masked]>
Date: Thu, 3 Dec 2009 20:31:36 -0500

A few comments below.  If they're just rehashing things
covered in the conf call, just let me know...  Sorry that I
have a perpetual conflict on Thursday...

> FedFS Meeting Minutes, 12/03/2009

I really like the idea of having an SNMP MIB for NFSv4, and
eventually for the NSDB and fedfs aspects of the file servers.
But is doing an NFSv4 MIB part of the charter for the fedfs
discussions?  It seems like there's plenty of work to do already.

>    format for NFSv2 and NFSv3, but not NFSv4. This RFC is part of WebNFS.

One of the original goals of the fedfs effort was to make the
fedfs part of the protocol as fs-agnostic as possible.  It seems
like putting the string "nfs" in the URL (as I've seen in at least
one suggestion) is a bit NFS-centric.  (yes, I'm aware that I'm
addressing this to the nfsv4 wg...)

>    mechanism for obtaining it, the NFSv4 PUTPUBFH operation, is

If we rely on the availability of  a "public filehandle", will we be able
to support underlying file systems that do not?  (how do people feel
about putpbfh in the first place--is it something we'd want to support
in perpetuity ourselves?)

>    ...

An old topic, but just in case...

Junction can still point to something *other* than the root of the pseudo-fs,
right?

>  desired security mechanism, or (3) the NSDB could require a particular

I'm missing something here.  Given that it's possible for any server to
host a junction referring to an NSDB in any (or every) other admin domain,
how can (1) possibly work (unless the entire federation is homogeneous)?

The possible permutations of different security policies and mechanisms
could be a real headache.  The fewer the better.

-Dan

---

From: James Lentini <[email-masked]>
Date: Fri, 4 Dec 2009 09:33:25 -0500 (EST)

>    GS2-KRB5 (see previous e-mail), which are applicable

Thanks for the rundown.

> To me it makes no sense to talk about TA mgmt in the ADMIN protocol if

Agreed. This is why we discussed how a fileserver decides to the 
security properties of an NSDB connection.

> server certs, 

For (a), do you mean that TLS would be required for all NSDB 
connections? That sounds too restrictive. I'd rather allow 
administrators to choose the security mechanism that makes the most 
sense for their situation and SASL is also very popular in the LDAP 
world (as we discussed below regarding Active Directory).

> or b) make NSDB LDAP connection security parameters configurable via 
> the ADMIN protocol.  To me this is an obvious yes. (I've not 
> actually reviewed the ADMIN protocol in detail though.)

Yes, this is one of the options we discussed. The arguments to 
FEDFS_CREATE_JUNCTION would be a natural place to include such a 
parameter and perhaps the appropriate security context as well.

> -- object attributes that have ACLs that don't grant read permission to

This would be an argument for supporting SASL with Kerberos.

---

From: James Lentini <[email-masked]>
Date: Fri, 4 Dec 2009 09:57:05 -0500 (EST)

On Thu, 3 Dec 2009, Daniel Ellard wrote:

> discussions?  

This question was raised in Chris Stacey's message. I haven't seen a 
response on that.

> It seems like there's plenty of work to do already.

Agreed.

> addressing this to the nfsv4 wg...)

Yes, our discussion was a bit NFS-centric. Let me explain.

On the call, it became clear that the question was was NOT about an 
RFC 2224 style URL, but rather the syntax of the OS mount command's 
server path parameter (for example the Linux mount.nfs(1)'s 
"remotetarget" parameter).

It would have helped if this next line from the minutes had been more 

> in perpetuity ourselves?)

If memory serves correct, Trond was responding to my comment that 
there is no NFSv4 version of a WebNFS URL defined in RFC 2224. He was 
pointing out that NFSv4 retains the public filehandle concept. Again, 
we realized fairly quickly that the question wasn't really about URLs.

Yes. I noted that and included it in the minutes:

> >    A junction may be present at any point beneath the federated
> >    root and point to an arbitrary location (the target of a 
> >    junction does not need to be beneath 
> >    /.domain-root-example.net).

> how can (1) possibly work (unless the entire federation is homogeneous)?

I didn't word (1) very well. 

The question is how does a fileserver determine the security policy 
for an NSDB connection. 

Option (1) is for the administrator to use an implementation-specific 
interface to configure a security policy (it might be a global on/off 
switch that requires the fileserver to use TLS for all NSDB 
connections or a fine-grained per-junction setting). Option (1) isn't 
incredibly attractive, but it is how things are likely to work absent 
a configuration mechanism in the ONC RPC Admin protocol or some other 
standardized mechanism.

> could be a real headache.  The fewer the better.

That is a good point. At the moment, the specifications allow for two 
options: insecure or TLS. It seems we should consider adding SASL with 
Kerberos as another option.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 4 Dec 2009 12:11:57 -0600

Yes.

> This would be an argument for supporting SASL with Kerberos.

It'd be fine to have that as a recommended or even required to implement
feature.  But we really need TLS to be required to implement.  The
reason is that use of self-signed certs and even small PKI island
deployments are less heavyweight than Kerberos + cross-realm trust
deployments -- we need a lightweight mechanism, and the lightest one is
TLS with server certs and passing of TAs via the ADMIN protocol.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 4 Dec 2009 12:27:45 -0600

> addressing this to the nfsv4 wg...)

I'd have no problem with:

    - fedfs://<domain>/<path>
    and
    - fed<protocol>://<domain>/<path>

I.e., there may be times when you want to specify the protocol, but
still also want the federated namespace.

> in perpetuity ourselves?)

I say forget the public filehandle.

> Junction can still point to something *other* than the root of the pseudo-fs,

That's my understanding, yes.

> how can (1) possibly work (unless the entire federation is homogeneous)?

(1) would require the existence of a PKI or Kerberos world that can
authenticate all the NSDBs in the federation.  That's just not likely.
(3) is insufficient because we need the client to authenticate the
server much more than the reverse.  That really only leaves (2) or (2) +
(3).

> could be a real headache.  The fewer the better.

I think we are really limited to considering these:

1) TLS
   a) with self-signed certs (which must be passed via the ADMIN proto)
   b) with un-bridged PKI islands (TAs must be passed via the ADMIN proto)
   c) with un-bridged PKI islands (TAs administered OOB via TAMP)
   d) with global or bridged PKIs (no need to manage TAs)
2) SASL/GSSAPI (a misnomer for "Kerberos", basically)

(Here "TA" == trust anchor; TAMP is a work-in-progress protocol for TA
administration that works by having each org have their own TA, separate
from their normal PKI's TAs, for TAMP.)

Of these five I think we should make three be required to implement:
(1a), (1b), (2).  My rationale for this choice:

 - Kerberos support is pretty much ubiquitous, so it's "free", but it
   can't be the only required-to-implement choice because it's not free
   as far as deployment effort goes.  (2) is in.

 - Self-signed certs suck in many ways, but they are the simplest
   authentication mechanism to deploy.  (1a) is in by necessity.

 - There will not be a global PKI nor even a bridged PKI covering all
   participants of any sufficiently large federation.  Ever.  So (1d) is
   out.

 - TAMP requires infrastructure (a place to hold the private key for
   the TAMP apex TA, and a place to use it to sign TAMP messages) and
   procedures (any time you introduce a new root key of any kind you're
   going to have to design administration procedures).  TAMP is not
   realistic for an application like FedFS, though it is realistic for
   others.  So (1c) is out.

 - (1b) is reasonably simple to implement and deploy, and simpler to
   administer than (1a).  (1b) is in as the best alternative to (1a).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 4 Dec 2009 14:50:32 -0600

> still also want the federated namespace.

Speaking of this...  If we can have protocol-neutral FedFS URIs then we
can have an all-text encoding of paths to use in the NSDB objects.  I'd
much, much rather have the NSDB refer to filesystems using URIs than via
binary enodings of NFSv4 paths.

Nico
--

---

From: Daniel Ellard <[email-masked]>
Date: Fri, 4 Dec 2009 16:33:05 -0500

[Oops, replied directly to Nico instead of the list.]

> still also want the federated namespace.

If you want to avoid having to register a new scheme for each
new file system type (because you're worried that there might
be a bunch of them...  this doesn't apply if there are only ever
two or three!) then you might want to move the fs type into
the uri path (where by path I mean the path of the URI, not the
path that NFS sees), i.e.,

   fedfs://nfsv4/<domain>/<path>
   fedfs://cifs/<domain>/<path>

-Dan