Subject: [nfsv4] FedFS: security concern regarding the use of time-variant UUIDs

From: Chuck Lever <[email-masked]>
Date: Thu, 27 Oct 2011 10:12:15 -0400

Hi-

Section 4.2.1.1 of revision 11 of the NSDB protocol draft says this:

> To minimize the probability of two UUIDs colliding, a consistent
> procedure for generating UUIDs SHOULD be used throughout a
> federation. Within a federation, UUIDs SHOULD be generated using the
> procedure described for version 1 of the UUID variant specified in
> [RFC4122]. This is the time-based UUID variant provided by many UUID
> programming libraries (e.g., the OSF DCE uuid_generate_time(1) API).

These UUIDs are stored in NSDBs.  The records where they stored are required to be readable by anyone who can bind anonymously to the NSDB's LDAP service so that FedFS-enabled file servers can perform FSN resolution via anonymous binding.  Thus FSN and FSL UUIDs should be considered public.

While coding the Linux FedFS implementation, I've come across several documents that complain about the security of time-variant UUIDs:

  o  The Linux uuid_generate(3) man page

  o  http://commons.apache.org/sandbox/id/uuid.html#Security

  o  http://en.wikipedia.org/wiki/Universally_unique_identifier#Version_1_.28MAC_address.29

To summarize, a time-variant UUID contains the host's MAC address and a valid time stamp in the clear.  Attackers can use such details to guess information about the host where the UUID was generated.  By convention, modern network protocols use only real random numbers in opaque data fields like UUIDs, sequence numbers, and so on, that appear in the clear to prevent leaking this kind of information.

At the very least, this issue should be covered in the Security Considerations section of the NSDB protocol draft.

However, we might instead want to consider using one of the more "random" UUID variants, especially because in FedFS, these UUIDs are visible to anyone who can view the LDAP directory where these are stored.  In addition, for NSDBs that allow access to their DIT without the use of TLS, these UUIDs flow in the clear on the network.

In my opinion, the federation UUID uniqueness requirement laid out in section 4.2.1.1 is vague.  An FSN is a tuple [ UUID, NSDB name, NSDB port ].  Thus the critical requirement for UUID uniqueness, for FedFS, is that a UUID be unique on a particular NSDB for FSNs.  An even narrower requirement exists for FSL UUIDs; they must be unique for a single FSN.

I believe the probability of an FSN UUID collision on a single NSDB is zero.  Since FSN UUIDs are used to form the DN of FSN and FSL records, an FSN UUID collision would be detected immediately when an administrator attempts to make an FSN or FSL public by storing it in the appropriate NSDB.  Further, an FSN and an FSL could even share the same UUID without consequence because of the way FedFS DNs are constructed.

A problem arises only when FedFS records are replicated across NSDBs.  Do we expect replicated FedFS records to exist on an NSDB which is the master for a different set of FedFS records?  If so, would the replicated records ever reside under the same NCE as records for which that NSDB is a master?

(Many thanks to James for helping me sharpen the questions).
 
-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com