Re: [nfsv4] Comments on draft-ietf-nfsv4-lfs-registry-00

[Thomas Haynes <[e-mail]>]

On Aug 31, 2014, at 9:58 AM, David Noveck <[e-mail]> wrote:

> Here's my stab at an abstract of the document as I understood  its intent.  You can adopt it, in whole or in part, if it works for you.
> 
> In the past Mandatory Access Control (MAC) systems have used particular
> rigidly-specified policies which were implemented in particular protocols 
> and platforms.  As MAC systems become more widely deployed, additional
> flexibility in mechanism and policy will be required.  While traditional
> trusted systems implemented Multi-Level Security (MLS) and integrity
> models, modern systems have expanded to include technologies such as
> type enforcement.  Due to the wide range of policies and mechanisms which
> need to be accommodated, it is unlikely that use of a single security label 
> format and model will be viable.
> 
> To allow multiple MAC mechanisms and label formats to co-exist in a network, this document proposes a registry of label format specifications.  This
> registry would contain label format identifiers and would provide for the
> association of each such identifier with a corresponding extensive document
> document outlining the exact syntax and use of the particular label
> format.
> 

^^ Thanks, taken


> With regard to the second paragraph of section 1, I don't think you are harsh enough about the complexity.  It is not enough to say the complexity is "unneeded".  I'd say it is actively harmful.  How about the following:
> 
> One solution might be to define a single label format which consists of the
> union of the requirements of all MAC models/implementations, known at a 
> given time. This approach is not desirable because it introduces an 
> environment where many MAC models would either have blank fields for many 
> of the label's components or where many implementations would ignore 
> many of values that are present altogether.  The resulting complexity
> would be likely to result in a confusing situation in which the interaction
> of fields that that derive from different MAC models is never clearly 
> specified and the addition of new models or extension of existing models 
> is unduly difficult.
>    
> An additional consideration is that if a policy authority or identifier 
> field is specified in the label format it would require a robust 
> description that encompassed multiple MAC models where implaementation would lock policy administration into the
>    described model.
> 

^^ Thanks, taken


> In section 2, there's a problem with the definition of "label format specification".  This same term has a different definition in section 6, and the definition in section 2, seems to match "Label format selector" in section 6. 


Ohh, good catch!

So, to be consistent with RFC 7204:

Section 2:

   Label Format Specifier:  an identifier used by the client to
      establish the syntactic format of the security label and the
      semantic meaning of its components.

   Label Format Specification:  is a reference to a stable, public
      document that specifies the label format.


Section 6:

   Label Format Specifier:  An integer number that maps to a particular
      label format, e.g., the CALIPSO label format defined by [RFC5570].
      The name space of this identifier has the range of 0..65,535.

...

   Label Format Specification:  A reference to a stable, public document
      that specifies the label format, e.g., an URL to [RFC5570].

I'd like to keep both in place. Section 2 helps the reader understand the terms for the rest of the document and Section 6 provides specifics for the registry format.


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