[nfsv4] Interim meeting agenda topics

[David Noveck <[e-mail]>]

On Fri, Sep 6, 2024, 4:35 PM Rick Macklem <[e-mail]> wrote:

> On Fri, Sep 6, 2024 at 1:05 PM Chris Inacio <[e-mail]> wrote:
> >
> > All,
> >
> > What would the agenda topics for the (yet to be scheduled) interim
> meeting be?
>

Since I've published a number of post-IETF120 drafts as part of the
respecification effort, it makes to discuss these.  Of particular
importance are is the latest draft of the acl document for which I have
made considerable changes to align the acl document with the work Rick is
doing to support draft POSIX ACLs as an NFSv4.2 extension.

I expect this to take about twenty minutes.

> What is left to be resolved / is controversial on the POSIX_ACL draft?

Nothing from my point of view.  I don't know of any issues Rick has.   It
is reasonable to expect that anyone who does have issues to raise them on
the list.   We may need to confirm the non-existence of such issues at the
forthcoming interim meeting.  I think we should allocate five minutes for
this.

>
> > I would like to add an Authentication/Authorization topic.


It seems to me that you need to be somewhat clearer about what we might
discuss, so we can appropriately schedule a discussion slot.

With regard to authorization, I don't see you mention anything
authorization-related below.   Btw, the security document has made a
considerable change from rfc8881 which unfortunately took the position that
there was no essential connection between the documented authorization
decisions and the actual authorization of operations.  "Lasciate ogni
speranza voi ch'entrate"

In any case, if there are no issues with this new approach, that's good to
know.

>
Although we still need some more detail as to the topic, it appears to me
that all of your materials fit within identification/authentication.

To scope down what I would like to discuss here: I need to read RFC2203
> first.  Just from browsing the table of contents for 2203, I’m not sure
> this helps me understand what are *the protocol needs* with how a file
> system backend stores/maps the network identity of the client.
>

I don't  think it does either.  Should it?

I don't know if this will help save you some time, but here is my
> recollection of how RPCSEC_GSS/Kerberized NFS works...
> - The client translates a user identity into a Kerberos principal (a
> string like "[e-mail]").
>    (This is usually a trivial mapping of username and default REALM.)
>   --> The client uses the user's TGT to acquire a session ticket from the
> KDC.
> - The GSSAPI layer wraps this session ticket up in a blob they call a
> token.
> - This "token" is sent to the server via a Null RPC by RPCSEC_GSS layer.
>   --> There is a back and forth between client and server, using Null RPCs
>        in the RPCSEC_GSS layer that, if successful, authenticates the
> Kerberos
>        prinicipal name on the server and creates a shorthand for the
> Kerberos principal.
>

This is helpful material but what exactly are you proposing the working
group do with it?  I can't see that it would fit very well in the security
document, which currently focuses on RPCSEC_GSS, rather than Kerberos
proper.  Maybe we can discuss how to change things to incorporate this sort
of material

       (Translation from Kerberos principal is whatever the server
> chooses to do.
>

Implementations may differ but there have to be some rules the server has
to adhere to to make this work.  What are they?

         For POSIX like systems, it typically strips off the @REALM
> and then looks
>          name up in the password/group databases to create POSIX
> credentials

for the user.
>

I don't understand the meaning of "POSIX  credentials".  Are you really
talking about credentials here?

Also, the password/group  databases have to be correct or security is not
real.  This needs to be clarified.

         which are associated with the shorthand mentioned above.)
> --> Then the client uses the shorthand (authenticated via encryption
> using the session key
>       from the Kerberos session ticket) to identify the "user" to the
> server. That's what RPCSEC_GSS
>       is doing for non-NULL RPCs.
> (Hopefully this is close. It has been a long time since I coded this
> stuff.)
>

A lot of people never have.  The important question is whether we are
missing something that implementors need to know. I expect there are
documents that describe this that we might reference.  Ideas?

>
> In theory, other mechanisms than Kerberos can be created for
> GSSAPI/RPCSEC_GSS,
> but there has not been much done. (Long ago there was an RFC and some code
> for
> a public key system, but no one adopted it.
>

Rfc8881 suggests pretty strongly that any new mechanism be implemented
using RPCSEC_GSS.   We should consider whether that suggestion needs to be
modified given that new mechanisms do not have to deal with encryption but
only authentication/identification.


> It sounds like Tigran et al might be thinking of a new mechanism,
> although I haven't looked
> at what he has written up yet,
>

I think so but it is not clear what the working group can do with that
until there is an actual proposal.

>
> >  Please *do not* think I’m trying to standardize how that works (that is
> a server implementation choice) but what needs to be on the wire to enable
> servers do that _however they chose to do it._
>  Reading through enough of the POSIX ACLs some of the large
> differences between NFSv3 and NFSv4 become clear.
> I'm not sure if this sounds silly, but on-the-wire it is basically a
> string (owner/owner_group defines it as "user@domain",
> where the domain was never well defined.


Right.  No attempt was made to define it. I don't think we are in position
to fix that now.

>(Right now, most just handle

> one "domain".


 I don't know of any that support more than one domain.  If there are not,
we would be able to simply avoid trying to address the purely aspirational
parts of the name@domain proposal.

> I don't think there is even a well

> defined way of checking "same string".


There isn't.   I hope we don't need one.

>By this I mean, does the DNS

> case insensitive and/or puny encoded rules apply?)
>

I don't know how to deal with thise complexities and never got appropriate
help with IDNA issues.  J. Klensin's advice was to make it someone else's
problem.  In any case, if you only support one domain (Or a  very small
set), you can just insist on only using the identity mappings.  BTW, there
are a few cases in which German domains involving unlauts are supported.
These use punycode rather than the utf-8 encoded umlaut characters.  I
don't know of any support for Turkish domain names.

>
> (For authentication, it is still a string, but with something that assures
> the
> server that it is legit.
>

The following are not clear:


   - what is referrent of "it"?
   - what is the "something" you are referring to?


> rick
>
> >
> > Dave what issues (not precisely drafts) are highest on your list of
> things to get resolved for us to make progress.
>

Since you asked for it, I have to say that we need to address and correct
the breakdown  in the chair function in which when one is  asking for some
specific thing that is needed,  it is neither done promptly nor is there
any explanation for the delay.  In particular, we need to avoid repetitions
of the following sorts of events:


   - The request to move the internationalization document to WGLC was not
   followed up at all.  There was neither an announcement of the change in the
   status document or request for input leading to a decision.

We now have no idea of the status of this document.  It is not clear why
this request was not addressed immediately.


   - The adoption call for for acl, security and rfc5662bis began "at or
   before" IETF120 but still, six weeks later there is neither adoption  or an
   explanation of issues preventing adoption.

What is going on here?



   - The adoption process for security started around two years ago.


There has been ample time to correct the problem.  What is missing is
sufficient attention to the process to correct the problems that exist.


>
> >
> > Chris
> >
> > _______________________________________________
> > nfsv4 mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>