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

From: Chuck Lever <[email-masked]>
Date: Wed, 9 Nov 2011 18:18:13 -0500

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 10 Nov 2011 19:52:29 +0000

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
> 
> 
> > 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
> > 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.
> 
> > A fedfsUuid is the base type for all of the universally unique
> identifiers (UUIDs) used by the federated filesystem protocols.
> >
> 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).
> 
> > 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.
> 
>   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
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Daniel Ellard <[email-masked]>
Date: Thu, 10 Nov 2011 16:59:20 -0500

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 10 Nov 2011 22:19:21 +0000

Thanks for the input, Dan.

I would suggest that we queue up a set of deltas to the I-D and
edit them in as the IESG-review and IETF last call are done.

Authors?

Spencer

> From: Daniel Ellard [mailto:[email-masked]]
> Sent: Thursday, November 10, 2011 1:59 PM
> To: Spencer Shepler
> Cc: Chuck Lever; [email-masked]
> speak.  As Chuck points out, this is also a problem for people who don't
> want host-specific info to leak out.
> 
> this is terribly important any more, perhaps because the discussions are
> fading from my memory.
> 
> -Dan
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Chuck Lever
> >> Subject: Re: [nfsv4] FedFS: security concern regarding the use of
> >> time- variant UUIDs
> >>
> >>
> >> >> 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).
> >> >
> >> 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.
> >> >
> >> 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.
> >> >
> >> 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
> >> >
> >> 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).
> >>
> >> "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.
> >>
> >> 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.
> >>
> >> 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.
> >> >
> >> 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.
> >> >
> >> 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.
> >> >
> >> 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.
> >> >
> >> REQUIRED.  Conversely, allowing no more than one NCE per NSDB
> >> eliminates the possibility of a disastrous FSN UUID collision.
> >> >
> >> 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