Subject: [nfsv4] [FedFS] Meeting Minutes, 1/14/2010

From: James Lentini <[email-masked]>
Date: Thu, 14 Jan 2010 15:22:59 -0500 (EST)

FedFS Meeting Minutes, 1/14/2010
--------------------------------

Attendees
---------

Sorin Faibish (EMC)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
David Quigley (NSA)

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

  - James Lentini draft text for Admin draft with security 
    mechanisms.

    Open. An initial proposal is below. Further work is necessary.
 
  - James Lentini will investigate scheduling FAST BOF on FedFS

    Complete.

    We will be in the Belvedere, from 7:30-8:30pm, on Thursday, 
    February 25, 2010. The FAST'10 website lists our BOF.

+ Discuss Security Considerations

 James presented the following: 

 enum FedFsConnectionSec { /* NEW enumeration */
 	FEDFS_SEC_NONE = 0,
        FEDFS_SEC_TLS = 1 /StartTLS mechanism; Section 3 of RFC4513 */
        /* other mechanisms TBD */
 };

 struct FedFsNsdbParams { /* NEW structure */
       FedFsNsdbName            nsdbName;
       FedFsConnectionSec       secType;
       /* type specific data follows */
       opaque                   secData<>; 
       /* secData is analogous to the RPC protocol's opaque_auth */
       /* For TLS, it could contain a TA's X.509 cert            */
       /* Allow each type to define data length bound?           */
 };

 program FEDFS_PROG {
  version FEDFS_VERSION {
          /* ... */
          FedFsStatus FEDFS_SET_NSDB_PARAMS(
                  FedFsNsdbParams) = 4;
          FedFsNsdbParams FEDFS_GET_NSDB_PARAMS(
                  FedFsNsdbName) = 5;
  } = 1;
 } = 100418;

We discussed the high level problem. 

A fileserver resolves a junction by querying an NSDB over LDAP. If the i
LDAP connection between the fileserver and NSDB is insecure, a malicious 
adversary could tamper with the communication and poison the fileserver's 
referral. Therefore it is desirable for the administrator to be able to 
configure the security mechanism used on the LDAP connection between the 
fileserver and NSDB.

To implement the above, the fileserver would contain a database 
mapping NSDB names to security parameters.

What should happen when FEDFS_JUNCTION_CREATE is called with an NSDB name 
that is not in the database? The FEDFS_JUNCTION_CREATE call could (A) succeed 
and assign a default policy to the NSDB, (B) fail, or (C) have an input 
parameter to indicate that the procedure should fail if there was no entry 
in this database. There appeared to be support for (B) or (C).

We discussed the following topics:

 * Security Policy Scope

   Are security parameters configured on a per fileserver, per NSDB, 
   or per junction basis? Per fileserver is very coarse grained; all
   junctions on a fileserver are resolved using the same policy. Per
   NSDB is shown above; all an NSDB's junctions are resolved the same 
   way. Per junction is very fine grained; different policies could be 
   set for two junctions with same NSDB.

We are not aware of any use cases that require per junction policies. 

We discussed some drawbacks to using per junction policies:

 - A per junction policy would require a different connection for each 
   security policy. There were concerns that this would not scale well.

 - When NSDB x's parameters changed, a per junction policy would require 
   every junction resolved via NSDB x to change (delete/create).

In general, David noted that it is useful to have multiple security 
mechanisms defined in a standard. If one mechanism is compromised, the 
others can be used as a backup. Would it be useful to have an way to turn 
off usage of a particular mechanism in the event it was compromised?

Trond observed that this is argument for a global policy and against a per 
junction policy as it would require every junction to change.

We discussed the ramifications of supporting multiple policy levels at 
the same time. For example, each junction might have its own policy but a 
global policy would take precedent. This scheme seemed brittle and 
confusing from an administration standpoint. It seemed easy to end up with 
non-functional junctions (if junction X was setup to use TLS, but global 
policy was to use no security, falling back to no security doesn't make 
sense).

There are use cases for a per NSDB policy: 
  - self signed certs 
  - NSDB on local, secure network.

 * Supported Security Mechanisms and Future Extensions

   What security mechanisms are required?

See discussion above about multiple security policies.

At least one policy (TLS?) would be REQUIRED to implement. The requirement 
to implement would not be a requirement that it be used.

   How are new security mechanisms added in future versions of the
   protocol?

The approach above is similar to that in RPC (an enumeration with security 
flavors that can be expanded in the future).

There was agreement that keeping close to RPC seemed best. 

 * TLS Cipher Suites

   The proposal does not provide a way to specify a list of 
   desired/acceptable TLS cipher suites. Support for the mandatory 
   cipher suite defined in Section 9 of RFC 5246 would be REQUIRED.
   Implementations might support other cipher suites and have 
   options for selecting them.

This seems like a global policy, not an NSDB specific policy.

Would it be useful to have a global on/off for a particular mechanism?
Probably not. The setting should be global to the entire fileserver and 
affect other services besides FedFS. Therefore, it should not be configured 
by FedFS.

 * StartTLS versus LDAPS

   The StartTLS mechanism described in Section 3 of RFC4513 is that 
   IETF standardized process for securing LDAP with TLS.

   Many LDAP implementations also support the non-standard process 
   of connecting to a special ldaps:// port (the OpenLDAP FAQ has some 
   details on this http://www.openldap.org/faq/data/cache/185.html).

   Since ldaps:// is non-standard, it is not included as an option in 
   FedFsConnectionSec.

David noted that to publish an RFC with a normative reference to the 
LDAPS mechanism would require the LDAPS mechanism to be standardized. 
That would require significant work. If there is a user community that 
needed LDAPS, then it could be justified. To date, a case has not been 
made for requiring LDAPS. 

An open question from above was if there should be a way to disable use of 
a particular security mechanism in the event it was compromised. Those on 
the call felt that a way to change the established security mechanism should 
suffice. A global on/off could be handled as cipher suite choice is done.

David asked how these security mechanisms affected junction traversal. James 
explained that access to the namespace is via existing file access protocols
(e.g. NFSv4, NFSv4.1,...). The clients ability to traverse a junction 
is separate from how the fileserver resolves the junction. David will follow 
up if he has more questions about this.