Network Working Group                                          M. Eisler
Internet-Draft                                                    Editor
Document: draft-ietf-nfsv4-secinfo-02.txt        Network Appliance, Inc.
                                                               July 2004


               NFSv4.1: SECINFO Changes

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html"

ABSTRACT

   This document proposes some changes to security negotiation in NFS
   version 4 [RFC3530]. It is hoped, but not promised, that these
   changes will be part of a new minor version of NFS: NFSv4.1.

TABLE OF CONTENTS

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Modified Operation 16: LOOKUPP - Lookup Parent Directory . . . 2
   3.  Modified Operation 33: SECINFO - Obtain Available Security . . 4
   4.  New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed
       Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Clarification of Security Negotiation in NFSv4.1 . . . . . . . 8
   5.1.  PUTFH + LOOKUP . . . . . . . . . . . . . . . . . . . . . . . 9
   5.2.  PUTFH + LOOKUPP  . . . . . . . . . . . . . . . . . . . . . . 9
   5.3.  PUTFH + SECINFO  . . . . . . . . . . . . . . . . . . . . . . 9



Expires: January 2005                                           [Page 1]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


   5.4.  PUTFH + Anything Else  . . . . . . . . . . . . . . . . . .  10
   6.  RPC Definition File Changes  . . . . . . . . . . . . . . . .  10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  13
   10.  Normative References  . . . . . . . . . . . . . . . . . . .  14
   11.  Informative References  . . . . . . . . . . . . . . . . . .  14
   12.  Editor's Address  . . . . . . . . . . . . . . . . . . . . .  14
   13.  IPR Notices . . . . . . . . . . . . . . . . . . . . . . . .  15
   14.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   This document assumes understanding of the NFSv4.0 specification.

   The NFSv4.0 specification contains three oversights and ambiguities
   with respect to the SECINFO operation.

   First, it is impossible for the client to use the SECINFO operation
   to determine the correct security triple for accessing a parent
   directory. This is because SECINFO takes as arguments the current
   file handle and a component name. However, NFSv4.0 uses the LOOKUPP
   operation to get the parent directory of the current file handle. If
   the client uses the wrong security when issuing the LOOKUPP, and gets
   back an NFS4ERR_WRONGSEC error, SECINFO is useless to the client. The
   client is left with guessing which security the server will accept.
   This defeats the purpose of SECINFO, which was to provide an
   efficient method of negotiating security.

   Second, there is ambiguity as to what the server should do when it is
   passed a LOOKUP operation such that the server restricts access to
   the current file handle with one security triple, and access to the
   component with a different triple, and remote procedure call uses one
   of the two security triples. Should the server allow the LOOKUP?

   Third, there is a problem as to what the client must do (or can do),
   whenever the server returns NFS4ERR_WRONGSEC in response to a PUTFH
   operation. The NFSv4.0 specification says that client should issue a
   SECINFO using the parent filehandle and the component name of the
   filehandle that PUTFH was issued with. This may not be convenient for
   the client.

   This document resolves the above three issues in the context of
   NFSv4.1.

2.  Modified Operation 16: LOOKUPP - Lookup Parent Directory

   If the NFSv4 minor version is 1, then following replaces section
   14.2.14 of the NFSv4.0 specification.  The LOOKUPP operation's "over


Expires: January 2005                                           [Page 2]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


   the wire" format is not altered, but the semantics are slightly
   modified to account for the addition of SECINFO_NO_NAME.

   SYNOPSIS
        (cfh) -> (cfh)

   ARGUMENT
        /* CURRENT_FH: object */
        void;

   RESULT
        struct LOOKUPP4res {
                     /* CURRENT_FH: directory */
                     nfsstat4        status;
        };

   DESCRIPTION
        The current filehandle is assumed to refer to a regular
        directory or a named attribute directory.  LOOKUPP assigns the
        filehandle for its parent directory to be the current
        filehandle.  If there is no parent directory an NFS4ERR_NOENT
        error must be returned.  Therefore, NFS4ERR_NOENT will be
        returned by the server when the current filehandle is at the
        root or top of the server's file tree.

        As for LOOKUP, LOOKUPP will also cross mountpoints.

        If the current filehandle is not a directory or named attribute
        directory, the error NFS4ERR_NOTDIR is returned.

        If the requester's security flavor does not match that
        configured for the parent directory, then the server SHOULD
        return NFS4ERR_WRONGSEC (a future minor revision of NFSv4 may
        upgrade this to MUST) in the LOOKUPP response.  However, if the
        server does so, it MUST support the new SECINFO_NO_NAME
        operation, so that the client can gracefully determine the
        correct security flavor.  See the discussion of the
        SECINFO_NO_NAME operation for a description.

   ERRORS
        NFS4ERR_ACCESS
        NFS4ERR_BADHANDLE
        NFS4ERR_FHEXPIRED
        NFS4ERR_IO
        NFS4ERR_MOVED
        NFS4ERR_NOENT
        NFS4ERR_NOFILEHANDLE
        NFS4ERR_NOTDIR
        NFS4ERR_RESOURCE


Expires: January 2005                                           [Page 3]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


        NFS4ERR_SERVERFAULT
        NFS4ERR_STALE
        NFS4ERR_WRONGSEC

3.  Modified Operation 33: SECINFO - Obtain Available Security

   If the NFSv4 minor version is 1, then following replaces section
   14.2.31 of the NFSv4.0 specification.  The SECINFO operation's "over
   the wire" format is not altered, but the semantics are slightly
   modified to account for the addition of SECINFO_NO_NAME.

   SYNOPSIS
        (cfh), name -> { secinfo }

   ARGUMENT
        struct SECINFO4args {
             /* CURRENT_FH: directory */
             component4     name;
        };

   RESULT
        enum rpc_gss_svc_t {/* From RFC 2203 */
             RPC_GSS_SVC_NONE        = 1,
             RPC_GSS_SVC_INTEGRITY   = 2,
             RPC_GSS_SVC_PRIVACY     = 3
        };

        struct rpcsec_gss_info {
             sec_oid4        oid;
             qop4            qop;
             rpc_gss_svc_t   service;
        };

        union secinfo4 switch (uint32_t flavor) {
        case RPCSEC_GSS:
              rpcsec_gss_info        flavor_info;
        default:
              void;
        };

        typedef secinfo4 SECINFO4resok<>;

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



Expires: January 2005                                           [Page 4]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


   DESCRIPTION
        The SECINFO operation is used by the client to obtain a list of
        valid RPC authentication flavors for a specific directory
        filehandle, file name pair.  SECINFO should apply the same
        access methodology used for LOOKUP when evaluating the name.
        Therefore, if the requester does not have the appropriate access
        to LOOKUP the name then SECINFO must behave the same way and
        return NFS4ERR_ACCESS.

        The result will contain an array which represents the security
        mechanisms available, with an order corresponding to the
        server's preferences, the most preferred being first in the
        array. The client is free to pick whatever security mechanism it
        both desires and supports, or to pick in the server's preference
        order the first one it supports.  The array entries are
        represented by the secinfo4 structure.  The field 'flavor' will
        contain a value of AUTH_NONE, AUTH_SYS (as defined in
        [RFC1831]), or RPCSEC_GSS (as defined in [RFC2203]). The field
        flavor can also any other security flavor registered with IANA.

        For the flavors AUTH_NONE and AUTH_SYS, no additional security
        information is returned.  The same is true of many (if not most)
        other security flavors, including AUTH_DH. For a return value of
        RPCSEC_GSS, a security triple is returned that contains the
        mechanism object id (as defined in [RFC2743]), the quality of
        protection (as defined in [RFC2743]) and the service type (as
        defined in [RFC2203]).  It is possible for SECINFO to return
        multiple entries with flavor equal to RPCSEC_GSS with different
        security triple values.

        On success, the current filehandle retains its value.

        If the name has a length of 0 (zero), or if name does not obey
        the UTF-8 definition, the error NFS4ERR_INVAL will be returned.

   IMPLEMENTATION
        The SECINFO operation is expected to be used by the NFS client
        when the error value of NFS4ERR_WRONGSEC is returned from
        another NFS operation.  This signifies to the client that the
        server's security policy is different from what the client is
        currently using.  At this point, the client is expected to
        obtain a list of possible security flavors and choose what best
        suits its policies.

        As mentioned, the server's security policies will determine when
        a client request receives NFS4ERR_WRONGSEC.  The operations
        which may receive this error are: LINK, LOOKUP, LOOKUPP, OPEN,
        PUTFH, PUTPUBFH, PUTROOTFH, RESTOREFH, RENAME, and indirectly
        READDIR.  LINK and RENAME will only receive this error if the


Expires: January 2005                                           [Page 5]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


        security used for the operation is inappropriate for saved
        filehandle.  With the exception of READDIR, these operations
        represent the point at which the client can instantiate a
        filehandle into the "current filehandle" at the server.  The
        filehandle is either provided by the client (PUTFH, PUTPUBFH,
        PUTROOTFH) or generated as a result of a name to filehandle
        translation (LOOKUP and OPEN).  RESTOREFH is different because
        the filehandle is a result of a previous SAVEFH.  Even though
        the filehandle, for RESTOREFH, might have previously passed the
        server's inspection for a security match, the server will check
        it again on RESTOREFH to ensure that the security policy has not
        changed.

        If the client wants to resolve an error return of
        NFS4ERR_WRONGSEC, the following will occur:

        o    For LOOKUP and OPEN, the client will use SECINFO with the
             same current filehandle and name as provided in the
             original LOOKUP or OPEN to enumerate the available security
             triples.

        o    For LINK, PUTFH, PUTROOTFH, PUTPUBFH, RENAME, and
             RESTOREFH, the client will use SECINFO_NO_NAME { style =
             current_fh }. The client will prefix the SECINFO_NO_NAME
             operation with the appropriate PUTFH, PUTPUBFH, or
             PUTROOTFH operation that provides the file handled
             originally provided by the PUTFH, PUTPUBFH, PUTROOTFH, or
             RESTOREFH, or for the failed LINK or RENAME, the SAVEFH.

             =========================================================
             NOTE: In NFSv4.0, the client was required to use SECINFO,
             and had to reconstruct the parent of the original file
             handle, and the component name of the original filehandle.
             ========================================================

        o    For LOOKUPP, the client will use SECINFO_NO_NAME { style =
             parent } and provide the filehandle with equals the
             filehandle originally provided to LOOKUPP.

        The READDIR operation will not directly return the
        NFS4ERR_WRONGSEC error.  However, if the READDIR request
        included a request for attributes, it is possible that the
        READDIR request's security triple did not match that of a
        directory entry.  If this is the case and the client has
        requested the rdattr_error attribute, the server will return the
        NFS4ERR_WRONGSEC error in rdattr_error for the entry.

        See the section "Security Considerations" for a discussion on
        the recommendations for security flavor used by SECINFO and


Expires: January 2005                                           [Page 6]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


        SECINFO_NO_NAME.

   ERRORS
        NFS4ERR_ACCESS
        NFS4ERR_BADCHAR
        NFS4ERR_BADHANDLE
        NFS4ERR_BADNAME
        NFS4ERR_BADXDR
        NFS4ERR_FHEXPIRED
        NFS4ERR_INVAL
        NFS4ERR_MOVED
        NFS4ERR_NAMETOOLONG
        NFS4ERR_NOENT
        NFS4ERR_NOFILEHANDLE
        NFS4ERR_NOTDIR
        NFS4ERR_RESOURCE
        NFS4ERR_SERVERFAULT
        NFS4ERR_STALE

4.  New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed Object


   SYNOPSIS
        (cfh), secinfo_style -> { secinfo }

   ARGUMENT
        enum secinfo_style_4 {
            current_fh = 0,
            parent = 1
        };

        typedef secinfo_style_4 SECINFO_NO_NAME4args;

   RESULT
        typedef SECINFO4res SECINFO_NO_NAME4res;

   DESCRIPTION
        Like the SECINFO operation, SECINFO_NO_NAME is used by the
        client to obtain a list of valid RPC authentication flavors for
        a specific file object.  Unlike SECINFO, SECINFO_NO_NAME only
        works with objects are accessed by file handle.

        There are two styles of SECINFO_NO_NAME, as determined by the
        value of the secinfo_style_4 enumeration. If "current_fh" is
        passed, then SECINFO_NO_NAME is querying for the required
        security for the current filehandle. If "parent" is passed, then
        SECINFO_NO_NAME is querying for the required security of the
        current filehandles's parent. If the style selected is "parent",
        then SECINFO should apply the same access methodology used for


Expires: January 2005                                           [Page 7]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


        LOOKUPP when evaluating the traversal to the parent directory.
        Therefore, if the requester does not have the appropriate access
        to LOOKUPP the parent then SECINFO_NO_NAME must behave the same
        way and return NFS4ERR_ACCESS.

        Note that if PUTFH, PUTPUBFH, or PUTROOTFH return
        NFS4ERR_WRONGSEC, this is tantamount to the server asserting
        that the client will have to guess what the required security
        is, because there is no way to query.  Therefore, the client
        must iterate through the security triples available at the
        client and reattempt the PUTFH, PUTROOTFH or PUTPUBFH operation.
        In the unfortunate event none of the MANDATORY security triples
        are supported by the client and server, the client SHOULD try
        using others that support integrity. Failing that, the client
        can try using other forms (e.g. AUTH_SYS and AUTH_NONE), but
        because such forms lack integrity checks, this puts the client
        at risk.

        The server implementor should pay particular attention to the
        section "Clarification of Security Negotiation in NFSv4.1" for
        implementation suggestions for avoiding NFS4ERR_WRONGSEC error
        returns from PUTFH, PUTROOTFH or PUTPUBFH.

        Everything else about SECINFO_NO_NAME is the same as SECINFO.
        See the previous discussion on SECINFO.

   IMPLEMENTATION
        See the previous discussion on SECINFO.

   ERRORS
        NFS4ERR_ACCESS
        NFS4ERR_BADCHAR
        NFS4ERR_BADHANDLE
        NFS4ERR_BADNAME
        NFS4ERR_BADXDR
        NFS4ERR_FHEXPIRED
        NFS4ERR_INVAL
        NFS4ERR_MOVED
        NFS4ERR_NAMETOOLONG
        NFS4ERR_NOENT
        NFS4ERR_NOFILEHANDLE
        NFS4ERR_NOTDIR
        NFS4ERR_RESOURCE
        NFS4ERR_SERVERFAULT
        NFS4ERR_STALE

5.  Clarification of Security Negotiation in NFSv4.1

   This section attempts to clarify NFSv4.1 security negotiation issues.


Expires: January 2005                                           [Page 8]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


   Unless noted otherwise, for any mention of PUTFH in this section, the
   reader should interpret it as applying to PUTROOTFH and PUTPUBFH in
   addition to PUTFH.

5.1.  PUTFH + LOOKUP

   The server implementation may decide whether to impose any
   restrictions on export security administration. There are at least
   three approaches (Sc is the flavor set of the child export, Sp that
   of the parent),

   a.   Sc <= Sp (<= for subset)

   b.   Sc ^ Sp != {} (^ for intersection, {} for the empty set)

   c.   free form

   To support b (when client chooses a flavor that is not a member of
   Sp) and c, PUTFH must NOT return NFS4ERR_WRONGSEC in case of security
   mismatch.  Instead, it should be returned from the LOOKUP that
   follows.

   Since the above guideline does not contradict a, it should be
   followed in general.

5.2.  PUTFH + LOOKUPP

   Since SECINFO only works its way down, there is no way LOOKUPP can
   return NFS4ERR_WRONGSEC without the server implementing
   SECINFO_NO_NAME. SECINFO_NO_NAME solves this issue because via style
   "parent", it works in the opposite direction as SECINFO (component
   name is implicit in this case).

5.3.  PUTFH + SECINFO

   This case should be treated specially.

   A security sensitive client should be allowed to choose a strong
   flavor when querying a server to determine a file object's permitted
   security flavors. The security flavor chosen by the client does not
   have to be included in the flavor list of the export. Of course the
   server has to be configured for whatever flavor the client selects,
   otherwise the request will fail at RPC authentication.

   In theory, there is no connection between the security flavor used by
   SECINFO and those supported by the export.  But in practice, the
   client may start looking for strong flavors from those supported by
   the export, followed by those in the mandatory set.



Expires: January 2005                                           [Page 9]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


5.4.  PUTFH + Anything Else

   PUTFH must return NFS4ERR_WRONGSEC in case of security mismatch. This
   is the most straightforward approach without having to add
   NFS4ERR_WRONGSEC to every other operations.

   PUTFH + SECINFO_NO_NAME (style "current_fh") is needed for the client
   to recover from NFS4ERR_WRONGSEC.

6.  RPC Definition File Changes

   /*
    * Copyright (C) The Internet Society (2004)
    * All Rights Reserved.
    */

   /*
    * nfs41_prot.x
    */

   %/* $Id: nfs41_prot.x,v 1.2 2004/06/18 23:19:28 mre Exp $ */

   /* new operation, SECINFO_NO_NAME */

   enum secinfo_style_4 {
       current_fh = 0,
       parent = 1
   };

   typedef secinfo_style_4 SECINFO_NO_NAME4args;
   typedef SECINFO4res SECINFO_NO_NAME4res;


   /*
    * Operation arrays
    */

   enum nfs_opnum4 {
      OP_ACCESS               = 3,
      OP_CLOSE                = 4,
      OP_COMMIT               = 5,
      OP_CREATE               = 6,
      OP_DELEGPURGE           = 7,
      OP_DELEGRETURN          = 8,
      OP_GETATTR              = 9,
      OP_GETFH                = 10,
      OP_LINK                 = 11,
      OP_LOCK                 = 12,
      OP_LOCKT                = 13,


Expires: January 2005                                          [Page 10]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


      OP_LOCKU                = 14,
      OP_LOOKUP               = 15,
      OP_LOOKUPP              = 16,
      OP_NVERIFY              = 17,
      OP_OPEN                 = 18,
      OP_OPENATTR             = 19,
      OP_OPEN_CONFIRM         = 20,
      OP_OPEN_DOWNGRADE       = 21,
      OP_PUTFH                = 22,
      OP_PUTPUBFH             = 23,
      OP_PUTROOTFH            = 24,
      OP_READ                 = 25,
      OP_READDIR              = 26,
      OP_READLINK             = 27,
      OP_REMOVE               = 28,
      OP_RENAME               = 29,
      OP_RENEW                = 30,
      OP_RESTOREFH            = 31,
      OP_SAVEFH               = 32,
      OP_SECINFO              = 33,
      OP_SETATTR              = 34,
      OP_SETCLIENTID          = 35,
      OP_SETCLIENTID_CONFIRM  = 36,
      OP_VERIFY               = 37,
      OP_WRITE                = 38,
      OP_RELEASE_LOCKOWNER    = 39,
      OP_SECINFO_NO_NAME      = 40,
      OP_ILLEGAL              = 10044
   };

   union nfs_argop4 switch (nfs_opnum4 argop) {
   case OP_ACCESS:        ACCESS4args opaccess;
   case OP_CLOSE:         CLOSE4args opclose;
   case OP_COMMIT:        COMMIT4args opcommit;
   case OP_CREATE:        CREATE4args opcreate;
   case OP_DELEGPURGE:    DELEGPURGE4args opdelegpurge;
   case OP_DELEGRETURN:   DELEGRETURN4args opdelegreturn;
   case OP_GETATTR:       GETATTR4args opgetattr;
   case OP_GETFH:         void;
   case OP_LINK:          LINK4args oplink;
   case OP_LOCK:          LOCK4args oplock;
   case OP_LOCKT:         LOCKT4args oplockt;
   case OP_LOCKU:         LOCKU4args oplocku;
   case OP_LOOKUP:        LOOKUP4args oplookup;
   case OP_LOOKUPP:       void;
   case OP_NVERIFY:       NVERIFY4args opnverify;
   case OP_OPEN:          OPEN4args opopen;
   case OP_OPENATTR:      OPENATTR4args opopenattr;
   case OP_OPEN_CONFIRM:  OPEN_CONFIRM4args opopen_confirm;


Expires: January 2005                                          [Page 11]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


   case OP_OPEN_DOWNGRADE:        OPEN_DOWNGRADE4args opopen_downgrade;
   case OP_PUTFH:         PUTFH4args opputfh;
   case OP_PUTPUBFH:      void;
   case OP_PUTROOTFH:     void;
   case OP_READ:          READ4args opread;
   case OP_READDIR:       READDIR4args opreaddir;
   case OP_READLINK:      void;
   case OP_REMOVE:        REMOVE4args opremove;
   case OP_RENAME:        RENAME4args oprename;
   case OP_RENEW:         RENEW4args oprenew;
   case OP_RESTOREFH:     void;
   case OP_SAVEFH:        void;
   case OP_SECINFO:       SECINFO4args opsecinfo;
   case OP_SETATTR:       SETATTR4args opsetattr;
   case OP_SETCLIENTID:   SETCLIENTID4args opsetclientid;
   case OP_SETCLIENTID_CONFIRM:   SETCLIENTID_CONFIRM4args
                                      opsetclientid_confirm;
   case OP_VERIFY:        VERIFY4args opverify;
   case OP_WRITE:         WRITE4args opwrite;
   case OP_RELEASE_LOCKOWNER:     RELEASE_LOCKOWNER4args
                                  oprelease_lockowner;
   case OP_SECINFO_NO_NAME:       SECINFO_NO_NAME4args
                                  opsecinfo_no_name;
   case OP_ILLEGAL:       void;
   };

   union nfs_resop4 switch (nfs_opnum4 resop){
   case OP_ACCESS:        ACCESS4res opaccess;
   case OP_CLOSE:         CLOSE4res opclose;
   case OP_COMMIT:        COMMIT4res opcommit;
   case OP_CREATE:        CREATE4res opcreate;
   case OP_DELEGPURGE:    DELEGPURGE4res opdelegpurge;
   case OP_DELEGRETURN:   DELEGRETURN4res opdelegreturn;
   case OP_GETATTR:       GETATTR4res opgetattr;
   case OP_GETFH:         GETFH4res opgetfh;
   case OP_LINK:          LINK4res oplink;
   case OP_LOCK:          LOCK4res oplock;
   case OP_LOCKT:         LOCKT4res oplockt;
   case OP_LOCKU:         LOCKU4res oplocku;
   case OP_LOOKUP:        LOOKUP4res oplookup;
   case OP_LOOKUPP:       LOOKUPP4res oplookupp;
   case OP_NVERIFY:       NVERIFY4res opnverify;
   case OP_OPEN:          OPEN4res opopen;
   case OP_OPENATTR:      OPENATTR4res opopenattr;
   case OP_OPEN_CONFIRM:  OPEN_CONFIRM4res opopen_confirm;
   case OP_OPEN_DOWNGRADE:        OPEN_DOWNGRADE4res opopen_downgrade;
   case OP_PUTFH:         PUTFH4res opputfh;
   case OP_PUTPUBFH:      PUTPUBFH4res opputpubfh;
   case OP_PUTROOTFH:     PUTROOTFH4res opputrootfh;


Expires: January 2005                                          [Page 12]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


   case OP_READ:          READ4res opread;
   case OP_READDIR:       READDIR4res opreaddir;
   case OP_READLINK:      READLINK4res opreadlink;
   case OP_REMOVE:        REMOVE4res opremove;
   case OP_RENAME:        RENAME4res oprename;
   case OP_RENEW:         RENEW4res oprenew;
   case OP_RESTOREFH:     RESTOREFH4res oprestorefh;
   case OP_SAVEFH:        SAVEFH4res opsavefh;
   case OP_SECINFO:       SECINFO4res opsecinfo;
   case OP_SETATTR:       SETATTR4res opsetattr;
   case OP_SETCLIENTID:   SETCLIENTID4res opsetclientid;
   case OP_SETCLIENTID_CONFIRM:   SETCLIENTID_CONFIRM4res
                                      opsetclientid_confirm;
   case OP_VERIFY:        VERIFY4res opverify;
   case OP_WRITE:         WRITE4res opwrite;
   case OP_RELEASE_LOCKOWNER:     RELEASE_LOCKOWNER4res
                                  oprelease_lockowner;
   case OP_SECINFO_NO_NAME:       SECINFO_NO_NAME4res
                                  opsecinfo_no_name;
   case OP_ILLEGAL:       ILLEGAL4res opillegal;
   };

   struct COMPOUND4args {
      utf8str_cs      tag;
      uint32_t        minorversion; /* == 1 !!! */
      nfs_argop4      argarray<>;
   };

   struct COMPOUND4res {
      nfsstat4 status;
      utf8str_cs      tag;
      nfs_resop4      resarray<>;
   };

7.  Security Considerations

   The security considerations of NFSv4.0 apply to NFSv4.1, with the
   proviso that security considerations of SECINFO apply to the new
   operation, SECINFO_NO_NAME.

8.  IANA Considerations

   The IANA considerations of NFSv4.0 apply to NFSv4.1.

9.  Acknowledgements

   The basis for the text in this document comes from the NFSv4.0
   specification as edited by Spencer Shepler.  Peng Dai wrote the
   "Clarification of Security Negotiation in NFSv4.1" section. Sergey


Expires: January 2005                                          [Page 13]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


   Klyushin contributed to the discussion that led to this document.
   Mike Eisler proposed the SECINFO_NO_NAME operation to address the
   issues Sergey and Peng brought to the nfsv4 working group's
   attention. Carl Burnett reviewed an earlier draft of this document
   which resulted in substantial improvements.

10.  Normative References


   [RFC3530]
        S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C.  Beame, M.
        Eisler, D. Noveck, Internet RFC3530, "NFS version 4 Protocol",
        April, 2003.

   [RFC1831]
        R. Srinivasan, Internet RFC1831, "RPC: Remote Procedure Call
        Protocol Specification Version 2", August, 1995.

   [RFC2743]
        J. Linn, Internet RFC2743, "Generic Security Service Application
        Program Interface Version 2, Update 1", January, 2000.

   [RFC2203]
        M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS
        Protocol Specification", September, 1997.

   [RFC1832]
        R. Srinivasan, Internet RFC1832, "XDR: External Data
        Representation Standard", August, 1995.

11.  Informative References

   None.

12.  Editor's Address

   Mike Eisler
   5765 Chase Point Circle
   Colorado Springs, CO 80919
   USA

   Phone: 719-599-9026
   EMail: mike@eisler.com

   Comments on this document should be sent to the NFSv4 working group:
   nfsv4@ietf.org





Expires: January 2005                                          [Page 14]


INTERNET-DRAFT          NFSv4.1: SECINFO Changes               July 2004


13.  IPR Notices

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

14.  Copyright Notice

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.














Expires: January 2005                                          [Page 15]