Re: [nfsv4] New MAC label support Internet Draft posted to IETF website

[Peter Staubach <[e-mail]>]

David P. Quigley wrote:
> Hello,
>    I have just posted a new document for the MAC labeling support work
> to the IETF website. It contains a lot of clarifying text that has been
> asked for by several people in the IETF community. I would like to ask
> that people give it a look over and provide comments if possible. I
> would prefer that discussion takes place on the NFSv4 WG mailing list
> since it shows interest in the technology which is what the WG is
> currently looking for. If you have any questions regarding the text or
> the system outlined in it email me and I'll be more than happy to help
> with any confusion. I am hoping to drum up enough interest in the work
> to request that it be added to the NFSv4 WG charter at the next IETF
> meeting. If you are interested in the work and would like to participate
> or just think that it is a worthwhile technology and would like to see
> it added to the NFSv4 standard feel free to speak up. 
>
> The information for the document which I received in the conformation
> email and a link to it can be found below.
>
> Dave Quigley
>
>
> A new version of I-D, draft-quigley-nfsv4-sec-label-00.txt has been
> successfuly submitted by David Quigley and posted to the IETF
> repository.
>
> Filename:        draft-quigley-nfsv4-sec-label
> Revision:        00
> Title:           MAC Security Label Support for NFSv4
> Creation_date:   2009-01-22
> WG ID:           Independent Submission
> Number_of_pages: 12
>
> Abstract:
> This Internet-Draft describes additions to NFSv4 minor version one to
> support Mandatory Access Control systems.  The current draft
> describes the mechanism for transporting a MAC security label using
> the NFSv4.1 protocol and the semantics required for that label.  In
> addition to this it describes an example system of using this label
> in a fully MAC aware environment.
>                                                                                   
>
>
> The IETF Secretariat.
>
> http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-sec-label-00.txt

I have been looking at the document and have some comments,
questions, and suggestions --

In section 1, MAC is defined, but perhaps it might be useful for
NFS folks to expand upon the definition just a tad.  For example,
how is this different than normal access control and why?  Perhaps
I am dense, but the text in Section 3 might make better sense if
I understood a little more about MAC at a high level.

In Section 3, there is discussion of using a recommended attribute
to store the security attribute.  A request is made for security
attribute number 76.  This one appears to be used already in the
NFSv4.1 specification.  Perhaps this should be flagged so that it
can be updated appropriate when this specification is included
into a larger, NFSv4.2, document?

In Section 3.1, DOI is defined for a third time.  The acronym can
probably just be used here.  That said, providing a little more
detail on how a DOI would be represented would be useful.  Is it
a 32 bit unsigned integer or something else?  Perhaps including
a pseudo description of the syntax of the security_attribute
would be good.

Section 3.2 discusses handling if a security attribute is
changed while a client is holding a delegation to an object.
The text describes that the client should flush changes to the
server and relinquish the delegation.  Why?  Is access to an
open file on the client to be revoked?  What happens on a
client which does not happen to be holding a delegation at the
time?

This leads to a further question concerning client side caching
of these attributes.  Is the client allowed to do caching?  If
so, how would it go about doing cache validation?

Section 4.1 includes an XXX reference probably to a draft
document.  Is this the draft for RPCSEC_GSSAPI v3?

Section 4.1.1 discusses denying a request if a security
attribute can not be translated from one DOI to another.
What error should be returned?  It seems to me that a new
set of errors may potentially need to be introduced to
handle the new cases where servers need to inform clients
exactly what happened.  Section 4.1.2 is missing a period
on the end of the second paragraph.  Perhaps this is the
intended error to be returned?

Section 4.2.1 discusses a smart client and the need for a
common DOI.  Could a client not implement its own translations
for the DOIs that it may choose to know about?

Section requests an IANA registry for DOIs.  Perhaps document
like, draft-ietf-nfsv4-rpc-netid-06.txt, previously circulated
by Michael Eisler, will need to be constructed to handle the
issue.

---

Anyway, enough for the time being.  I think that some more
detailed definitions and declarations need to be specified
in order to move along.

    Thanx...

       ps