Subject: Re: [nfsv4] rfc7861 - new rpcsec gss3 text for IANA registry of structured privilege names text

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 20 Jun 2016 18:34:04 +0000

Backgroung: The rp_name is used to identify the RPC application defined structured privilege, so we need some more text describing the rp_name namespace. Two means were proposed: IANA registry, or an SSHv2-like naming scheme.

The working group has had some time to look at this issue.

The summary of WG comments to date:

1) IANA registry for structured privilege rp_names vrs SSHv2 - like scheme. The comments I’ve received:

Nico: SSHv2-like scheme.

Tom Haynes, Chuck Lever, Dave Novec, Andy Adamson: IANA registry.

             - D. Novec: Base structured privilege rp_name IANA registry on Section 20.1 of rfc7530 and use a "standards action" rather than "specification required” registry.

The WG has chosen to use an IANA registry.

2) IANA registry in separate document vrs add to existing document.

It would be best to have the IANA registry in rfc 7861. Does this delay the RFC process in an unacceptable way?
 
3) If IANA registry in a separate document, mention this in rfc 7861.

How would this work - wouldn’t we need to have a resolved document to reference?

—>Andy

> On Jun 16, 2016, at 10:46 AM, Thomas Haynes <[email-masked]> wrote:
> 
> 
>> On Jun 16, 2016, at 10:42 AM, Adamson, Andy <[email-masked]> wrote:
>> 
>> 
>>> On Jun 16, 2016, at 2:59 AM, Nico Williams <[email-masked]> wrote:
>>> 
>>> Yes, this change would have to be confirmed with the WG.  I'm ok with making no change here and publishing another RFC later to correct this.  Inserting a note about this now would be ok, however.
>> 
>> 
>> The WG comments so far support an IANA registry.
>> I’m also ok with having a separate document to describe the IANA registry, or another solution that the WG agrees on, and to note this in RFC 7861.
>> 
> 
> I would say a separate document to describe the IANA registry.
> 
> I don’t care about the note one way or the other.
> 
> 
>> Is this the way forward?
>> 
>> —>Andy
>

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 20 Jun 2016 21:16:34 +0000

Thanks for the summary, Andy.  I would prefer that the IANA registry requirement be added to the existing I-D.

The delay will come from an IANA review.  Spencer D. will need to weigh in on the need for further review and potential schedule.

Spencer

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of Adamson, Andy
Sent: Monday, June 20, 2016 11:34 AM
To: [email-masked]
Cc: Nico Williams <[email-masked]>; Adamson, Andy <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>; [email-masked]
Subject: Re: [nfsv4] rfc7861 - new rpcsec gss3 text for IANA registry of structured privilege names text

Nico: SSHv2-like scheme.

 

—>Andy

> I don’t care about the note one way or the other.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fnfsv4&data=01%7c01%7csshepler%40microsoft.com%7c2a2e841c3bcf4b1548e108d3993a3819%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fx4DBM%2f61ZFBlN9Zy%2brEMte8uCZYsTvjQoA26GXZEos%3d

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 21 Jun 2016 13:15:39 +0000

> On Jun 20, 2016, at 5:16 PM, Spencer Shepler <[email-masked]> wrote:
> 
> 

OK. Here is what I came up with.

How should we register the three NFSv4.2 Inter server to server copy structured privilege names (copy_to_auth, copy_from_auth, copy_confirm_auth)?  Register them here in the initial registry? 

—Andy

—— new section under IANA Considerations 

5.2.  Structured Privilege Name Definitions

   IANA has created a registry called the "RPCSEC_GSS Structured
   Privilege Names Registry".

   Structured privilege assertions (Section 2.7.1.4) are defined by a
   specific RPC application.  The namespace identifiers for these
   assertions (the rp_name) are defined as string names.  The
   RPCSEC_GSSv3 protocol does not define the specific assignment of the
   namespace for these structured privilege assertion names.  The IANA
   registry promotes interoperability where common interests exist.
   While RPC application developers are allowed to define and use
   structured privileges as needed, they are encouraged to register
   structured privilege assertion names with IANA.

   The registry is to be maintained using the Standards Action policy as
   defined in Section 4.1 of [RFC5226].

   Under the RPCSEC_GSS version 3 specification, the name of a
   structured privilege can in theory be up to 2^32 - 1 bytes in length,
   but in practice RPC application clients and servers will be unable to
   handle a string that long.  IANA should reject any assignment request
   with a structured privilege name that exceeds 128 UTF-8 characters.
   To give the IESG the flexibility to set up bases of assignment of
   Experimental Use, the prefixe "EXPE" is Reserved.  The structured
   privilege with a zero-length name is Reserved.

   The prefix "PRIV" is allocated for Private Use.  A site that wants to
   make use of unregistered named attributes without risk of conflicting
   with an assignment in IANA's registry should use the prefix "PRIV" in
   all of its structured privilege assertion names.

   Because some RPC application clients and servers have case-
   insensitive semantics, the fifteen additional lower case and mixed
   case permutations of each of "EXPE", and "PRIV" are Reserved (e.g.,
   "expe", "expE", "exPe", etc. are Reserved).  Similarly, IANA must not
   allow two assignments that would conflict if both structured
   privilege names were converted to a common case.

   The registry of structured privilege names is a list of assignments,
   each containing three fields for each assignment.

   1.  A US-ASCII string name that is the actual name of the structured
       privilege.  This name must be unique.  This string name can be 1
       to 128 UTF-8 characters long.

   2.  A reference to the specification of the RPC application defined
       structured privilege.  The reference can consume up to 256 bytes
       (or more if IANA permits).

   3.  The point of contact of the registrant.  The point of contact can
       consume up to 256 bytes (or more if IANA permits).

5.2.1.  Initial Registry

   There is no initial registry

5.2.2.  Updating Registrations

   The registrant is always permitted to update the point of contact
   field.  To make any other change will require Expert Review or IESG
   Approval.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 21 Jun 2016 16:14:55 +0000

Thanks, Andy. Yes, the initial registry for the 3 names should be noted in the IANA section.

-----Original Message-----
From: Adamson, Andy [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2016 6:16 AM
To: Spencer Shepler <[email-masked]>
Cc: Adamson, Andy <[email-masked]>; [email-masked]; Spencer Dawkins at IETF <[email-masked]>; Nico Williams <[email-masked]>; [email-masked]
Subject: Re: rfc7861 - new rpcsec gss3 text for IANA registry of structured privilege names text

—Andy

5.2.1.  Initial Registry

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Jun 2016 16:11:38 -0400 (EDT)

>    defined in Section 4.1 of [RFC5226].

"RPC application developers [...] are encouraged to register" seems
inconsistent with the Standards Action policy. It seems like Expert Review
would provide more flexibility for non-RFC registrations?

-Ben

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 24 Jun 2016 21:46:43 +0000

> On Jun 24, 2016, at 4:11 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

"RPC application developers [...] are encouraged to register”. 

Here is the current plan:
If they want an official IANA blessed structuctured privilege name, write an RFC. If not, then use PRIV or EXPE are for.

The v4 working group so far has suggested the Standards Action Policy. I could clarify the above plan.

—>Andy

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 25 Jun 2016 23:40:59 -0400 (EDT)

On Fri, 24 Jun 2016, Adamson, Andy wrote:

> If they want an official IANA blessed structuctured privilege name,
> write an RFC. If not, then use PRIV or EXPE are for.
>

Sure, it might be worth putting ", so application developers that do not
wish to publish an RFC for the RPC usage should use the PREV or EXPE
namespaces" at the end.  I mostly just wanted to confirm that this is the
intended policy and double-check that the WG didn't want something more
lenient for application developers to be able to use.

Thanks,

Ben

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 28 Jun 2016 13:07:18 +0000

> On Jun 25, 2016, at 11:40 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> namespaces" at the end.

Sure - that makes it very clear.

Any other comments on Section 5.2 before I submit an updated version?

—>Andy

>  I mostly just wanted to confirm that this is the