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

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 22 Jun 2012 18:30:38 +0000

We should also do this for the admin document as well?

On 11/10/11 3:59 PM, "Daniel Ellard" <[email-masked]> wrote:

>One of the original reasons for using Type 1 uuids was exactly for the
>reason that it permitted them to be tracked back to a distinct origin
>(although they could be forged).  An FSL would have provenance, so to
>speak.  As Chuck points out, this is also a problem for people who
>don't want host-specific info to leak out.
>
>At this time, I see no reason not to use Type 4 uuids in all contexts.
> It's true that their provenance can't be discerned, but I don't think
>this is terribly important any more, perhaps because the discussions
>are fading from my memory.
>
>-Dan
>
>On Thu, Nov 10, 2011 at 2:52 PM, Spencer Shepler <[email-masked]>
>wrote:
>>
>> Any followup for Chuck on this issue?
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of
>>> Chuck Lever
>>> Sent: Wednesday, November 09, 2011 3:18 PM
>>> To: [email-masked]
>>> Subject: Re: [nfsv4] FedFS: security concern regarding the use of time-
>>> variant UUIDs
>>>
>>>
>>> On Oct 27, 2011, at 10:12 AM, Chuck Lever wrote:
>>>
>>> > 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.
>>>
>>> Allow me to exercise this issue a little more.  Section 4.2.1.1 of the
>>> NSDB protocol draft currently states:
>>>
>>> > 4.2.1.1. fedfsUuid
>>> >
>>> > A fedfsUuid is the base type for all of the universally unique
>>> identifiers (UUIDs) used by the federated filesystem protocols.
>>> >
>>> > 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).
>>>
>>> Other areas of the NSDB protocol draft have language similar to this:
>>>
>>> > The DN of an FSN is REQUIRED to take the following form:
>>> "fedfsFsnUuid=$FSNUUID,$NCE", where $FSNUUID is the UUID of the FSN and
>>> $NCE is the DN of the NCE ("o=fedfs" by default). Since LDAP requires
>>>a DN
>>> to be unique, this ensures that each FSN entry has a unique UUID value
>>> within the LDAP directory.
>>>
>>> The FSN stored in a junction does contain the name of the NSDB, but
>>>due to
>>> recent protocol changes, no longer contains an NCE.  Thus we can have
>>>two
>>> UUIDs stored on one NSDB that are exactly the same, but reside under
>>> unique NCEs.  This defines our FSN UUID collision domain:
>>>
>>>   FSN UUIDs must be unique on one NSDB, even across NCEs.  An LDAP
>>>server
>>> will not prevent administrators from creating two FSN records using the
>>> same UUID under different NCEs.  Proper FSN resolution is then
>>>dependent
>>> on the order in which the LDAP server lists its naming contexts.
>>>
>>> And our FSL collision domain:
>>>
>>>   FSL UUIDs must be unique only for a single FSN.  An LDAP server can
>>> easily prevent the creation of FSL records with the same FSL UUID under
>>> the same FSN.
>>>
>>> The Security Considerations section of RFC 4122 ("A Universally Unique
>>> IDentifier (UUID) URN Namespace") recommends the use of the namespace
>>> variant of UUIDs when it can't be guaranteed that the random number
>>> generation across distributed hosts can't be relied upon.  Perhaps we
>>> should explicitly justify our choice of version 1 UUIDs in section
>>> 4.2.1.1, in light of this recommendation.
>>>
>>> I still have not been able to find a citable reference which lays out
>>>the
>>> exact security ramification of exposing version 1 UUIDs in the clear.
>>> However, nearly every document I've discovered which discusses UUIDs at
>>> length refers to this issue and generally recommends avoiding version 1
>>> UUIDs.
>>>
>>> A UUID expert I consulted considers the exposure obvious, and thus not
>>> worth a citation.  However, he feels that administrative hosts are
>>>already
>>> exposed on the network, and thus the use of version 1 UUIDs generated
>>>on
>>> them would likely not introduce any further exposure.  He recommends
>>> providing explicit analysis in our Security Considerations section that
>>> shows there should be no concern.
>>>
>>> I propose the following language for the Security Considerations
>>>section
>>> or in or near section 4.2.1.1 of the NSDB protocol draft.  This
>>>language
>>> describes the exposure, allows readers to draw their own conclusion,
>>> offers implementation alternatives, and finally provides parameters for
>>> choosing an alternate UUID generation mechanism, if desired.
>>>
>>> > This document recommends the use of version 1 UUIDs [RFC 4122] for
>>>both
>>> FSN and FSL UUIDs.  Version 1 UUIDs are constructed from local time and
>>> MAC hardware addresses in addition to random data.  Version 1 UUIDs can
>>> thus be traced to a particular random data source on a particular
>>>machine
>>> at a particular time.
>>> >
>>> > File servers bind anonymously to NSDBs when performing FSN
>>>resolution.
>>> Thus FSN and FSL records must be world-readable.  During FSN
>>>resolution,
>>> these records are typically accessed in the clear, exposing FSN and FSL
>>> UUIDs to everyone who has access to the network.
>>> >
>>> > If UUIDs are considered sensitive at a particular site (say, if
>>> administrative hosts are required to maintain anonymity), access to the
>>> site's NSDBs can be restricted to TLS-only.  Alternately, implementers
>>>may
>>> consider a method of generating RFC 4122-compliant version 1 UUIDs
>>>using
>>> mock time and MAC address information.
>>> >
>>> > FSN UUIDs must be unique across all NCEs on one NSDB.  An LDAP server
>>> cannot prevent administrators from creating two FSN records using the
>>>same
>>> UUID but different NCEs.  In the presence of multiple FSN records with
>>>the
>>> same UUID, the result of FSN resolution becomes dependent on the order
>>>in
>>> which the LDAP server lists its naming contexts.
>>> >
>>> > Therefore, an UUID generation mechanism that can ensure (with high
>>> probability) the uniqueness of UUIDs on an NSDB with multiple NCEs is
>>> REQUIRED.  Conversely, allowing no more than one NCE per NSDB
>>>eliminates
>>> the possibility of a disastrous FSN UUID collision.
>>> >
>>> > FSL UUIDs must be unique only for a single FSN.  Because of the way
>>>FSL
>>> DNs are constructed, an LDAP server can easily prevent the creation of
>>>FSL
>>> records with the same FSL UUID under the same FSN.  Therefore FSL UUID
>>> uniqueness is not a strong consideration when choosing an UUID
>>>generation
>>> mechanism.
>>>
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>_______________________________________________
>nfsv4 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nfsv4