Subject: [nfsv4] [FedFS] meeting agenda (1/14)

From: James Lentini <[email-masked]>
Date: Wed, 13 Jan 2010 17:26:12 -0500 (EST)

Tomorrow's proposed agenda is below. Please let me know if you would
like to add additional topics.

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 (us)
          303-218-2659 (international)
      Id: 2354843

Proposed Agenda
---------------

+ 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.
  
  - James Lentini will investigate scheduling FAST BOF on FedFS

+ Discuss Security Considerations

---

From: James Lentini <[email-masked]>
Date: Thu, 14 Jan 2010 13:00:35 -0500 (EST)

>   - James Lentini draft text for Admin draft with security 

I've been working on the above AI. I'll present the following today:

 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;

Some topics for discussion:

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

 * Supported Security Mechanisms and Future Extensions

   What security mechanisms are required?

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

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

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

I look forward to feedback at the meeting and on the mailing list.

-james