Subject: minor comments on draft-ietf-nfsv4-00.txt

From: Mike Eisler <[email-masked]>
Date: Thu, 12 Aug 1999 07:51:29 -0700 (PDT)

minor comments on the June 1999 edition of the draft:

> 2.2.1.1.  Kerberos V5 as security triple
> 
>    The Kerberos V5 GSS-API mechanism as described in [RFC1964] MUST be
>    implemented and provide the following security triples.
> 
>  columns:
...
>  1 == number of pseudo flavor
>  2 == name of pseudo flavor
>  3 == mechanism's OID
>  4 == mechanism's algorithm(s)
>  5 == RPCSEC_GSS service
> 
>  1      2     3                    4              5
>  -----------------------------------------------------------------------
>  390003 krb5  1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_none
>  390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_integrity
>  390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_privacy

Note that the pseudo flavor number is needed for NFS V3 to negotiate
security via the V3 MOUNT protocol. NFS V4, which has has in-band
security negotiation that groks GSS-API, doesn't need the flavor.
Nonetheless, NFS V4 implementors may find a unique number to map to the
fields 3, 4, and 5 in the above table to be useful.

>        This section will be expanded to include the pertinent
>        details from draft-ietf-nfsv4-nfssec-00.txt.

Rather than expand it, perhaps the section should simply refer to
RFC 2623.

> 10.2.  Procedure 1: COMPOUND - Compound Operations
...
> 
>    RESULT
> 
>      struct COMPOUND4resok {
>        utf8string tag;
>        resultdata data<>;
>      };
> 
>      union COMPOUND4res switch (nfsstat4 status){
>       case NFS4_OK:
>         COMPOUND4resok resok4;
>       default:
>         void;
>      };

The above doesn't quite do what I was looking for.
The above returns a void result if the global status is non-zero.

What I was seeking was:

     struct COMPOUND4resok {
       utf8string tag;
       resultdata data<>;
     };

     struct COMPOUND4res {
		nfsstat4 status; /* status of last operation */
		utf8string tag;
		resultdata data<>

     };

This way, the NFS client can quickly determine the status code for the
purpose of deciding if there is say a JUKEBOX error that requires
retrying the operations that didn't complete.

There seems to be lots of cases where  white space between a data type and
field is missing:

     struct CLOSE4args {
       stateid4stateid;
     };  

>    enum rpc_flavor4 {
>            AUTH4_NONE              = 0,
>            AUTH4_SYS               = 1,
>            AUTH4_DH                = 2,
>            AUTH4_KRB4              = 3,
>            AUTH4_RPCSEC_GSS        = 4
				       ^

BTW, RPCSEC_GSS is 6, not 4.
>    };

> 10.29.  Procedure 28: SECINFO - Obtain Available Security
...
>    RESULT
>  
>      struct rpc_flavor_info {
>        sec_oid4oid;   
>        qop4qop;   
>        rpc_gss_svc_t service;
>      };  
>  
>      struct secinfo4 {
>        rpc_flavor4flavor;
>        rpc_flavor_info *flavor_info;
>        secinfo4*nextentry;
>      };  
>  
>      struct SECINFO4resok {
>        secinfo4reply; 
>      };  
>  
>  
>      union SECINFO4res switch (nfsstat4 status) {
>       case NFS4_OK:
>         SECINFO4resokresok4;
>       default:
>         void;
>      };  

Instead of linked list, the secinfo4 entries ought to be in an
array. I don't expect the list to be lengthy, so an array is more
appropriate.

While the WG has reached consensus on the use of RPCSEC_GSS, NFS V4
should be flexible enough to work over other kinds of security flavors,
jsut as NFS V3's mount protocol should have been flexible enough to work
over flavors other than AUTH_NONE, AUTH_SYS, AUTH_KERB, AUTH_DES, and
wasn't.

So I propose:

	/* delete rpc_flavor4 enum */

     struct rpcsec_gss_info {
       sec_oid4 oid;   
       qop4 qop;   
       rpc_gss_svc_t service;
     };  
 
     struct secinfo4 {
       unsigned int flavor;
       opaque flavor info /* null for AUTH_SYS, AUTH_NONE, contains
		rpcsec_gss_info for RPCSEC_GSS.
     };  
 
     struct SECINFO4resok {
       secinfo4 reply<>;
     };  

     union SECINFO4res switch (nfsstat4 status) {
      case NFS4_OK:
        SECINFO4resok resok4;
      default:
        void;
     };  

The abve has the side benefits of using less bandwidth for flavors other
than RPCSEC_GSS, and less bandwidth if there are two more more 
RPCSEC_GSS flavors in the results.

>   [SPNEGO]
>   Baize, E., Pinkas, D., "The Simple and Protected GSS-API Negotiation
>   Mechanism", draft-ietf-cat-snego-09.txt, Bull, April 1998.
>
>   ftp://ftp.isi.edu/internet-drafts/draft-ietf-cat-snego-09.txt

There doesn't appear to be a reference to this document in specification.
This i-d has become RFC 2478.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 12 Aug 1999 14:44:18 -0500

...

> Rather than expand it, perhaps the section should simply refer to

Will update the draft.

> retrying the operations that didn't complete.

Sounds reasonable and it appears that COMPOUND4resok is not needed since
the data is contained in COMPOUND4res.

> There seems to be lots of cases where  white space between a data type and

I will check the document formatting.

> BTW, RPCSEC_GSS is 6, not 4.

Will change.

> array. I don't expect the list to be lengthy, so an array is more

Okay.

> RPCSEC_GSS flavors in the results.

Good idea.  If no objections, I will go ahead and update.

> This i-d has become RFC 2478.

Will change.

Spencer