Subject: [nfsv4] Stephen Farrell's No Objection on draft-ietf-nfsv4-lfs-registry-04: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Apr 2015 06:04:05 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-nfsv4-lfs-registry-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think there is a possibly missing security consideration in
section 4 - if two label formats "overlap" so that a value for
one could represent a (different) value for the other and if
the label format specifier is not somehow bound to the
packet/object, then some confusion attacks may be possible.
The mitigation I think is to either (maybe implicitly) bind
the format specifier into the object/label or to ensure that
label values cannot be valid for other label format
specifiers. (Note that attacks here are probably only
interesting in highly specific cases, so it's not a huge deal,
but maybe worth a mention.)

---

From: Tom Haynes <[email-masked]>
Date: Wed, 8 Apr 2015 16:42:24 -0700

> On Apr 8, 2015, at 6:04 AM, Stephen Farrell <[email-masked]> wrote:
> 

Hi Stephen,

Section 3.3 of RFC7204 has a discussion on this topic:

   Labeled NFS MUST provide a means for servers and clients to identify
   their LFSs for the purposes of authorization, security service
   selection, and security label interpretation.

   Labeled NFS MUST provide a means for servers and clients to identify
   their mode of operation (see Section 4).

   A negotiation scheme SHOULD be provided, allowing systems from
   different Label Formats to agree on how they will interpret or
   translate each other's foreign labels.  Multiple concurrent
   agreements may be current between a server and a client.

So for Labeled NFS, it does bind the Label Format Specifier to the objects
such that translation can occur. I.e., as you point out, the label itself is not
sufficient to describe the intended behavior - it has to be in the context of the
binding.

Thanks,
Tom

> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4