Subject: [nfsv4] [PATCH] Document the use of AUTH_NONE as a wildcard in SECINFO replies

From: Trond Myklebust <[email-masked]>
Date: Thu, 1 Sep 2011 16:51:59 -0400

Several servers already support this practice.
---
 nfsv4_middle_procedures.xml |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/nfsv4_middle_procedures.xml b/nfsv4_middle_procedures.xml
index 516dcad..900f7eb 100644
--- a/nfsv4_middle_procedures.xml
+++ b/nfsv4_middle_procedures.xml
@@ -3397,6 +3397,21 @@ M        named by filename from the directory corresponding to the
       </t>
 
       <t>
+        Note that a server MAY use the AUTH_NONE flavor to signify that
+        the client is allowed to attempt to use authentication flavors
+        that are not explicitly listed in the SECINFO results.
+        Instead of using a listed flavor, the client might then, for instance
+        opt to use an otherwise unlisted RPCSEC_GSS mechanism instead of
+        AUTH_NONE. It may wish to do so in order to meet an application
+        requirement for data integrity or privacy.
+        In choosing to use an unlisted flavor, the client SHOULD always
+        be prepared to handle a failure by falling back to using AUTH_NONE
+        or another listed flavor. It MUST NOT assume that identity mapping
+        is supported, and should be prepared for the fact that its identity
+        is squashed.
+      </t>
+
+      <t>
         See <xref target="sec:security" /> for a discussion
         on the recommendations for security flavor used by SECINFO.
       </t>
-- 
1.7.6

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 1 Sep 2011 21:01:14 +0000

Why isn't the server responding with the full list of supported security mechanisms?
Because the AUTH_NULL return super, special, secret handshake and SECINFO
doesn't capture the desired semantics...

It is my opinion that this practice should be captured in a separate
I-D and pushed as an RFC.  The subtleties of AUTH_NONE allowing anonymous/mapped
access to the client seem too much to accept at this point in the 3530bis process.
Having the accepted practice described more fully such that others can
replicated it is very worthwile.  The paragraph provided, while correct, is incomplete
for an implementer that is on the "outside".

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Trond Myklebust
> Sent: Thursday, September 01, 2011 1:52 PM
> To: [email-masked]; [email-masked]
> Cc: Trond Myklebust
> Subject: [nfsv4] [PATCH] Document the use of AUTH_NONE as a wildcard in
> SECINFO replies
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4