Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-rpcsec-gss-v2-00.txt

From: [email-masked]
Date: Mon, 18 Feb 2008 21:15:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title           : RPCSEC_GSS Version 2
	Author(s)       : M. Eisler
	Filename        : draft-ietf-nfsv4-rpcsec-gss-v2-00.txt
	Pages           : 8
	Date            : 2008-02-18

This Internet-Draft describes version 2 of the RPCSEC_GSS protocol.
Version 2 is the same as Version 1 but adds support for channel
bindings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpcsec-gss-v2-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-nfsv4-rpcsec-gss-v2-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nfsv4-rpcsec-gss-v2-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
nfsv4 mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Feb 2008 14:23:57 -0600

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

---

From: Mike Eisler <[email-masked]>
Date: Wed, 20 Feb 2008 13:29:35 -0800 (PST)

>    Quoting text from RFC5056 to describe channel binding might be

I'll take a look

>    getMIC() call for the request, and similarly for the reply

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

>    Is it possible that it may respond with silence or by closing the

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

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