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

[Mike Eisler <[e-mail]>]

--- Nicolas Williams <[e-mail]> wrote:

>  - 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.

I'll take a look

> 
>  - 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).

In that case, we can keep it really simple. The MIC input
consists of what is currently input into the MIC plus:

        struct rpc_gss_chan_bind_input {
                int             rgbci_chan_bind_type;
                opaque          rgcbi_chan_bindings<>;
        };

I.e., the RPC header plus the above is passed into GetMIC().


> 
>  - 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.

An RPC auth-level error should be returned. I will add text.

> 
> 
>  - 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.
> 

AUTH_NONE is the flavor of the verifer. The flavor of the cred
remains RPCSEC_GSS, and the cred has the same format as it does now.

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

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