Subject: [secdir] Secdir review of draft-ietf-nfsv4-rpcsec-gssv3-14

From: Radia Perlman <[email-masked]>
Date: Tue, 15 Dec 2015 19:10:18 -0800

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

Note I'm reviewing the version 14 (although it was version 13 in the
assignments list).

The document specifies where to carry Mandatory Access Control information
in the protocol. It does not specify the Mandatory Access Control
information itself… that is inherited from another spec.

The language in places is a bit foreign to me, perhaps because I don't
"speak" GSS-API or mandatory access control.  So, for instance, in the
sentence

    "Existing GSS-API mechanisms are insufficient for communicating certain
aspects of authority               to a server"

I gather from context that this is authorization information.  I'd have
said "...insufficient for communicating certain authorization
information".  If "aspects of authority" means something else then perhaps
"aspects of authority" should be defined here, even if defined elsewhere.
If indeed this is common terminology then OK.

There's a typo in section 2.5  "with an acccept stat of PROC_UNAVAIL"
 (extra "c" in accept)

Radia

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 22 Dec 2015 17:10:29 +0000

> On Dec 15, 2015, at 10:10 PM, Radia Perlman <[email-masked]> wrote:
> 
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
> 
> Note I'm reviewing the version 14 (although it was version 13 in the assignments list).
> 
> The document specifies where to carry Mandatory Access Control information in the protocol. It does not specify the Mandatory Access Control information itself… that is inherited from another spec.

Hi

draft version 14 says:

2.7.1.3.  Label Assertions

   ….Full mode MAC is
   enabled when an RPCSEC_GSS_CREATE process subject label assertion is
   combined with a file object label provided by the NFSv4.2 sec_label
   attribute.

and 

  Servers that support labeling in the requested LFS MAY map the
   requested subject label to a different subject label as a result of
   server-side policy evaluation.

I guess I could be a bit clearer - "the Label assertion asserts the client process subject labels"

> 
> The language in places is a bit foreign to me, perhaps because I don't "speak" GSS-API or mandatory access control.  So, for instance, in the sentence
> 
>     "Existing GSS-API mechanisms are insufficient for communicating certain aspects of authority               to a server"
> 
> I gather from context that this is authorization information.  I'd have said "...insufficient for communicating certain authorization information".  If "aspects of authority" means something else then perhaps "aspects of authority" should be defined here, even if defined elsewhere. If indeed this is common terminology then OK.

We used ‘aspects of authority’ instead of ‘authorization information’ as the multi-principal assertion adds additional authentication. We could change it to ‘…insufficient for communicating certain authorization and authentication information"

> 
> There's a typo in section 2.5  "with an acccept stat of PROC_UNAVAIL"  (extra "c" in accept)

Oops - thought I got rid of that :)

Thanks for the review

—>Andy