[nfsv4] Comments on draft-ietf-nfsv4-rpcsec-gss-v2-00

[Nicolas Williams <[e-mail]>]

 - Please add a reference to RFC5056
 
 - Section 2 discusses what RFC5056 calls "unique channel bindings."

   There's another kind, "end-point channel bindings" that IPsec is
   likely to provide instead of unique channel bindings.

   Quoting text from RFC5056 to describe channel binding might be more
   appropriate.

 - Instead of:

           struct rpc_gss_chan_bind_input {
                   unsigned int    rgcbi_seq_num;
                   opaque          rgcbi_chan_bindings<>;
           };

           struct rpc_gss_bind_channel_arg {
                   int             rgbca_chan_bind_type;
                   opaque          rgbca_MIC_hdr<>;
                   opaque          rgbca_MIC_chan_bindings<>;
           };

   I propose this:

           struct rpc_gss_chan_bind_input {
                   opaque          rgbca_chan_bind_prefix;
                   opaque          rgcbi_chan_bindings<>;
                   opaque          rgbca_hdr<>;
                   unsigned int    rgcbi_seq_num;
           };

           struct rpc_gss_bind_channel_arg {
                   opaque          rgbca_MIC_chan_bindings<>;
           };

   and similarly for rpc_gss_bind_channel_res.

   I.e., make the RPC header and sequence number, and the channel
   binding type (or, rather, "prefix") part of the input to a single
   getMIC() call for the request, and similarly for the reply (instead
   of two getMIC()s).

 - As implied above, there's a registry of channel binding types that
   includes a "prefix" that should be included in the channel binding
   operation.  See section 7 of RFC5056.
   

 - How is v1 vs. v2 negotiated?

   In the case of NFSv4 the answer is simple: the new rpc_gss_service_t
   value allows this to be negotiated via SECINFO/WRONGSEC.

   But in general, what should happen if a server that supports only
   RPCSEC_GSS_VERS_1 receives a RPCSEC_GSS_VERS_2?

   Is it possible that it may respond with silence or by closing the
   connection?  I hope not.


 - Section 3.3.  AUTH_NONE cannot be the right answer here!  We need to
   use an RPCSEC_GSS context handle so we can identify the client
   principal of a given RPC request -- we just don't need to
   authenticate that handle via a getMIC()/verifyMIC() because we have
   the protection of the underlying channel.


Nico
-- 
_______________________________________________
nfsv4 mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/nfsv4