Subject: [nfsv4] AUTH48 review of rfc7861 "Remote Procedure Call (RPC) Security Version 3” issue

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 13 Jun 2016 16:23:06 +0000

In his AUTH48 review, Nico Williams, the co-author of rfc7861 "Remote Procedure Call (RPC) Security Version 3” brought up the need for a registry of structured privilege assertion rp_name namespace.

Here is the current draft text on rp_name:

      ///  struct rgss3_privs {
      ///          utf8str_cs      rp_name<>;
      ///          opaque          rp_privilege<>;
      ///  };

   The
   rp_name field of rpc_gss3_privs carries the description string used
   to identify and list the privilege.  The utf8str_cs definition is
   from [RFC7530].

Since the rp_name is used to identify the RPC application defined structured privilege, I agree that we need some more text describing the rp_name namespace.

> On May 27, 2016, at 1:00 AM, Nico Williams <[email-masked]> wrote:
> 
> - Section 5, IANA Considerations.
> 
>   Surely we need a registry for privilege names!  Alternatively we
>   could declare an SSHv2-style naming convention for privilege names.
> 
>   Please pick one of these two options.
> 

SSHv2-style naming uses a name@domain syntax. From Nico:

> On May 30, 2016, at 6:18 PM, Nico Williams <[email-masked]> wrote:
> 
> A name will do.  Just say something like that names of the form @name
> will be allocated by future RFCs and that names of the form name@domain
> (for domains other than ietf.org) are available for allocation by the
> owner of any domain.  This way we can avoid another trip through IANA.
> I strongly recommend this.

I don’t understand what “@name” means. Just “a name” such as copy_for_auth? f this is the case, then that is what we want if future RFCs that choose a name do not collide with an existing name - how is this enforced?

I guess that is why the IANA registry is better. 

In this version of the AUTH48 rfc7861, I added Section 5.2.  "Structured Privilege Name Definitions” modeled after rfc5661 Section 22.1. "Named Attribute Definitions”

The addition of a Structured Privilege rp_name registry is a big enough change to ask for WG comments.

Opinions?

—>Andy

---

From: David Noveck <[email-masked]>
Date: Mon, 13 Jun 2016 14:53:46 -0400

> I added Section 5.2.  "Structured Privilege Name Definitions” modeled
after rfc5661 Section 22.1. "Named Attribute Definitions”

I would suggest that you use Section 20.1 of rfc7530 instead. When this
rfc7530 was reviewed, it became clear that Section 22.1 of rfc5661,
which Tom copied into the submitted draft of rfc7530 was
incorrect/inconsistent.  As a result, section  20.1 in the published
rfc7530 is a better
place to start than section 22.1 of rfc5661.

On the other hand, I think that the structured privilege registry is better
as "standards action" rather than "specification required".  That
would be consistent with Nico's idea that these should require an RFC.

On Mon, Jun 13, 2016 at 12:23 PM, Adamson, Andy <[email-masked]>
wrote:

> In his AUTH48 review, Nico Williams, the co-author of rfc7861 "Remote
> Procedure Call (RPC) Security Version 3” brought up the need for a registry
> of structured privilege assertion rp_name namespace.
>
> Since the rp_name is used to identify the RPC application defined
> structured privilege, I agree that we need some more text describing the
> rp_name namespace.
>
>
> I don’t understand what “@name” means. Just “a name” such as
> copy_for_auth? f this is the case, then that is what we want if future RFCs
> that choose a name do not collide with an existing name - how is this
> enforced?
>
> In this version of the AUTH48 rfc7861, I added Section 5.2.  "Structured
> Privilege Name Definitions” modeled after rfc5661 Section 22.1. "Named
> Attribute Definitions”
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>