Subject: [nfsv4] Use of RPCSEC_GSSv3 for labeled NFS in draft-ietf-nfsv4-minorversion2-19

From: Andy Adamson <[email-masked]>
Date: Wed, 11 Sep 2013 11:07:23 -0400

Hi David, Tom

Could you expand on exactly what "additional information" an NFSv4
server needs from the client in order to apply MAC checks?

-------------
>From Section 8.1 draft-ietf-nfsv4-minorversion2-19:

  The final change necessary is a modification to the RPC layer used in
   NFSv4 in the form of a new version of the RPCSEC_GSS [RFC2203]
   framework.  In order for an NFSv4 server to apply MAC checks it must
   obtain additional information from the client.  Several methods were
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^

   explored for performing this and it was decided that the best
   approach was to incorporate the ability to make security attribute
   assertions through the RPC mechanism.  RPCSECGSSv3 [rpcsecgssv3]
   outlines a method to assert additional security information such as
   security labels on gss context creation and have that data bound to
   all RPC requests that make use of that context.
-------------

I'm reviewing draft-ietf-nfsv4-rpcsec-gssv3-05 where rpcsec_gssv3
sends security labels in the form:

      ///  typedef opaque rpc_gss3_doi<>;
      ///  struct rpc_gss3_label {
      ///          rpc_gss3_doi    doi;
      ///          opaque          label<>;
      ///  };

The above seems to be a repeat (although in DOI vrs LFS form) of
information sent in 12.2.2 of draft-ietf-nfsv4-minorversion2-19:

Section 12.2.2. Attribute 80: sec_label

   typedef uint32_t  policy4;

   struct labelformat_spec4 {
           policy4 lfs_lfs;
           policy4 lfs_pi;
   };

   struct sec_label4 {
           labelformat_spec4       slai_lfs;
           opaque                  slai_data<>;
   };

Does rpcsec_gssv3 really need to send the same security label as
NFSv4.2 to enable full mode via server MAC checks?

Thanks

-->Andy

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 11 Sep 2013 15:15:57 +0000

> server needs from the client in order to apply MAC checks?

NFSv4.2 sends the object label back.

RPCSEC_GSSv3 sends the subject label forward.

Two totally different things, but with the same underlying syntax.

---

From: Andy Adamson <[email-masked]>
Date: Wed, 11 Sep 2013 11:33:13 -0400

> Two totally different things, but with the same underlying syntax.

Ohh that's right, it's an NFSv4.2 attribute. OK - I can make that a
bit clearer in the 4.2 draft, and fix rpcsecgssv3.

Thanks

-->Andy

---

From: Dave Quigley <[email-masked]>
Date: Fri, 13 Sep 2013 23:04:32 -0400

> server needs from the client in order to apply MAC checks?

DOI was what we use to call the LFS. At some point we specified the 
format of the label data and the semantics of the label data. A DOI 
represents a coherent policy domain. Its can be part of a Label Format 
Specifier but is not necessary. The idea is if you speak a DOI then you 
can be sure you know the semantics of every Label in that DOI. In the 
labelformat_spec4 below its synonymous with the lfs_pi field.

> NFSv4.2 to enable full mode via server MAC checks?

The answer to that is Yes. As Tom said the sec_label4 is the label on 
objects while the RPCSECGSSv3 label is the label of the subject making 
the access. They need to line up or whatever policy engine is making the 
decisions on the server side can't make a decision.