Subject: [nfsv4] Fwd: New Version Notification for draft-quigley-nfsv4-labeled-00

From: Thomas Haynes <[email-masked]>
Date: Wed, 30 Mar 2011 17:34:17 +0200

This document folds the three Quiqley documents into one.

It provides an XDR encoding based on those documents.

It is a starting point for discussion based on today's meeting.

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: March 30, 2011 5:15:39 PM GMT+02:00
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: New Version Notification for draft-quigley-nfsv4-labeled-00 
> 
> 
> A new version of I-D, draft-quigley-nfsv4-labeled-00.txt has been successfully submitted by Thomas Haynes and posted to the IETF repository.
> 
> Filename:	 draft-quigley-nfsv4-labeled
> Revision:	 00
> Title:		 Labeled NFS
> Creation_date:	 2011-03-30
> WG ID:		 Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> This Internet-Draft describes additions to NFSv4 to support Mandatory
> Access Control systems.  The current draft describes the mechanism
> for transporting a MAC security label using the NFSv4 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.
> 
>

---

From: sfaibish <[email-masked]>
Date: Thu, 31 Mar 2011 04:42:21 -0400

I want to start the discussion on the draft by adding the items and issues
we need to address in the draft based on my discussions with Jarrett
and included in the slides I didn't show in the WG meeting.

1. Add in the introduction in more detail what security issues are not
    addressed by the current ACL that are resolved by the current draft.
2. Add more usecases at least usecases related to virtualization needs,
    government usecases, Linux usecases, cloud possible usecases, additional
    usecases from Kathleen (CCed) mentioned during the meeting.
3. Add or group in one section addressing the implementation mechanism
    and new xdr additions to make it clear for implementers.
    - Change MAC attributes to be represented as 2 separate entities:
    	Domain of Interpretation (DOI, specified by LFS)
    	Opaque without special separator @
    - Mechanism to allow systems to advertise MAC attributes support
    	Negotiated by requesting supported attributes from server (EXCHANGE_ID)
    	May turn off support by not requesting attribute.
    - Define fixed max size of the opaque (not less than IPv6 HBH extension  
length?)
    - Add text to better define support of full mode MAC security as  
implementation
      recommendations for servers not mandating it but rather MAY be  
implemented.
    - Address different policy reinforcement implementations more clearily:
	+ full server reinforcement only for dumb MAC unaware clients (define
	  how dumb, v2, v3, v4.0).
	  * Need to define/recommend which policies.
	  * Mention what are goals and non-goals addressed by current draf
		# full mode for pNFS
		# delegations (directory and files?)
		# untrusted devfelopments
	  * Separate "visibility" from "access permission" reinforcement.
	+ server policy to just prevent non MAC aware clients access and see the
           secured objects
	+ full server policy reinforcements for MAC aware clients

4. Include a section about the pNFS support where to mention why
    pNFS is different than 4.1. The current explanation may not be
    enough. I would also include the reasoning why named attributes
    is not recommended to be used.
5. Add a section addressing the delegations and explain why delegations
    are non-goals for 4.2 and what will be the roadmap for adding delegation
    support in future versions.
6. Define in more details all the behaviors: MAC aware cleint, MAC un-aware
    clients, MAC supportive server, MAC aware server and full mode server.
7. Add explanation on the issues related to root protection and/or  
recommendation
    how to solve them in the server (or and client)
8. Define the impact of new labels on dumb clients and MAC un-aware  
clients both
    from perspective of backward compatibility (new labels not break the  
clients)
    how to inform them that server will reinforce MAC (maybe?)

We discussed additional issues which I may forgot so please jump in
and add issues I missed that we will discuss during the calls. And I insist
of having bi-weekly calls as Jarrett, me and Dave recommend to have. It
worked good last time we had the series. Thank you very much for your
patience.

/Sorin

On Wed, 30 Mar 2011 11:34:17 -0400, Thomas Haynes <[email-masked]>  
wrote:

>> A new version of I-D, draft-quigley-nfsv4-labeled-00.txt has been  
>> successfully submitted by Thomas Haynes and posted to the IETF  
>> repository.
>>

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 31 Mar 2011 11:18:01 +0200

>   usecases from Kathleen (CCed) mentioned during the meeting.

I'm more interested in seeing if our model addresses those use cases than
in documenting those use cases. (Note that this is my opinion only and not
a requirement.)

>   	Opaque without special separator @

This part was done in this draft.

>   - Define fixed max size of the opaque (not less than IPv6 HBH extension length?)

Not done

>   - Add text to better define support of full mode MAC security as implementation
>     recommendations for servers not mandating it but rather MAY be implemented.
> 7. Add explanation on the issues related to root protection and/or recommendation
> 8. Define the impact of new labels on dumb clients and MAC un-aware clients both
>   from perspective of backward compatibility (new labels not break the clients)

I'll send out the details early next week, but I did promise to start up a conference
call on this that is open to anyone who wishes to participate. 

My suggestion would be for us to hold it in the time slot we were using for the FedFS
calls. I.e., on the off week for the NFSv4.2 calls. (Which I will also send out the details
on soon.)

By the way, thank you very much for providing this list of open issues.

> 
> /Sorin
> 
> 
> On Wed, 30 Mar 2011 11:34:17 -0400, Thomas Haynes <[email-masked]> wrote:
>

---

From: sfaibish <[email-masked]>
Date: Thu, 31 Mar 2011 05:37:36 -0400

> calls. I.e., on the off week for the NFSv4.2 calls. (Which I will also  
I am for it as the slot is booked in my calendar but only if there is
no conflict with other topics related to 3530bis and 4.2. Otherwise we had
the MAC call every second Wednesday at 4PM EST. Dave was available at that
time as well as me.

/Sorin

-- 
Best Regards

Sorin Faibish

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: sfaibish <[email-masked]>
Date: Thu, 31 Mar 2011 05:40:03 -0400

> in documenting those use cases. (Note that this is my opinion only and  
My opinion is to at least document all the known usecases and see how many
of them we can cover with what we target for 4.2 even if there are usecases
that we will not address in 4.2 but later. It is good to have the final  
target.

/Sorin

-- 
Best Regards

Sorin Faibish

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 31 Mar 2011 12:02:58 +0200

On Mar 31, 2011, at 11:37 AM, sfaibish wrote:

> On Thu, 31 Mar 2011 05:18:01 -0400, Thomas Haynes <[email-masked]> wrote:
> 
>> 

I can do that, I just want to make sure this is all done on the WG alias.