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

> On Apr 8, 2015, at 6:04 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 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.)
> 

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
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4