[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                          M. Eisler
Internet-Draft                                                    Editor
Document: draft-eisler-nfsv4-secinfo-00.txt      Network Appliance, Inc.
                                                           February 2003

               NFSv4.1: SECINFO Changes

Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   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 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 as
   "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


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


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Modified Operation 33: SECINFO - Obtain Available Security . . 2
   3.  New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed
       Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Clarification of Security Negotiation in NFSv4.1 . . . . . . . 7
   4.1.  PUTFH+LOOKUP . . . . . . . . . . . . . . . . . . . . . . . . 7
   4.2.  PUTFH+LOOKUPP  . . . . . . . . . . . . . . . . . . . . . . . 8
   4.3.  PUTFH+SECINFO  . . . . . . . . . . . . . . . . . . . . . . . 8
   4.4.  PUTFH+Anything Else  . . . . . . . . . . . . . . . . . . . . 8
   5.  RPC Definition File Changes  . . . . . . . . . . . . . . . . . 8

Expires: August 2003                                            [Page 1]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

   6.  Security Considerations  . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  12
   9.  Normative References . . . . . . . . . . . . . . . . . . . .  12
   10.  Informative References  . . . . . . . . . . . . . . . . . .  13
   11.  Editor's Address  . . . . . . . . . . . . . . . . . . . . .  13
   12.  IPR Notices . . . . . . . . . . . . . . . . . . . . . . . .  13
   13.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . .  13

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

2.  Modified Operation 33: SECINFO - Obtain Available Security

   If the NFSv4 minor version 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 addition of SECINFO_NO_NAME.

Expires: August 2003                                            [Page 2]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

        (cfh), name -> { secinfo }

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

        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;

        typedef secinfo4 SECINFO4resok<>;

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

        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

Expires: August 2003                                            [Page 3]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

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

        For the flavors AUTH_NONE and AUTH_SYS, no additional security
        information is returned.  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.

        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,
        READDIR.  LINK and RENAME will only receive this error if the
        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

Expires: August 2003                                            [Page 4]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

        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, RENAME, and RESTOREFH, the client will use
           SECINFO_NO_NAME { style = current_fh },  and provide the
           filehandle which equals to the filehandle originally provided
           by the PUTFH, RESTOREFH, or for LINK and 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.

      o    For PUTROOTFH and PUTPUBFH, the client will be unable to use
           SECINFO or SECINFO_NO_NAME operations since te SECINFO
           operations require a current filehandle and none exist for
           PUTROOTFH and PUTPUBFH.  Therefore, the client must iterate
           through the security triples available at the client and
           reattempt the 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 AUTH_NONE, but because such forms lack
           integrity checks, this puts the client at risk.  Nonetheless,
           the server SHOULD allow the client to use whatever security
           form the client requests and the server supports, since the
           risks of doing so are on the client.

        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 does 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: August 2003                                            [Page 5]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003


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

        (cfh), secinfo_style -> { secinfo }

        enum secinfo_style_4 {
            current_fh = 0,
            parent = 1

        typedef secinfo_style_4 SECINFO_NO_NAME4args;

        typedef SECINFO4res SECINFO_NO_NAME4res;

        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
        LOOKUPP when evaluating the traversal to the parent directory.
        Therefore, if the requester does not have the appropriate access

Expires: August 2003                                            [Page 6]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

        to LOOKUPP the parent then SECINFO_NO_NAME must behave the same
        way and return NFS4ERR_ACCESS.

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

        See the previous discussion on SECINFO.


4.  Clarification of Security Negotiation in NFSv4.1

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


   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)

   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

   Since the above guideline does not contradict a, it should be

Expires: August 2003                                            [Page 7]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

   followed in general.


   Since SECINFO only works its way down, there is no way LOOKUPP can
   return NFS4ERR_WRONGSEC without 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).


   This case should be treated specially.

   A security sensitive client should be allowed to choose a strong
   flavor. 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 it, otherwise the request will fail at RPC

   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.

4.4.  PUTFH+Anything Else

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

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

5.  RPC Definition File Changes

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

    * nfs41_prot.x

   %/* $Id: nfs41_prot.x,v 1.1 2003/02/23 05:10:53 mre Exp mre $ */

   /* new operation, SECINFO_NO_NAME */

Expires: August 2003                                            [Page 8]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

   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,
      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_VERIFY               = 37,

Expires: August 2003                                            [Page 9]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

      OP_WRITE                = 38,
      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;
   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_VERIFY:        VERIFY4args opverify;
   case OP_WRITE:         WRITE4args opwrite;
   case OP_ILLEGAL:       void;

Expires: August 2003                                           [Page 10]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003


   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;
   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_VERIFY:        VERIFY4res opverify;
   case OP_WRITE:         WRITE4res opwrite;
   case OP_ILLEGAL:       ILLEGAL4res opillegal;

   struct COMPOUND4args {
      utf8str_cs      tag;

Expires: August 2003                                           [Page 11]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

      uint32_t        minorversion; /* == 1 !!! */
      nfs_argop4      argarray<>;

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

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

7.  IANA Considerations

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

8.  Acknowledgements

   The basis for the text in this document comes from the NFSv4.0
   specification as edited by Spencer Shepler.  Dai Peng wrote the
   "Clarification of Security Negotiation in NFSv4.1" section. Sergey
   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

9.  Normative References

        S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C.  Beame, M.
        Eisler, D. Noveck, A work in progress, "NFS version 4 Protocol",
        November, 2002.

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

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

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

Expires: August 2003                                           [Page 12]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

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

10.  Informative References


11.  Editor's Address

   Mike Eisler
   5765 Chase Point Circle
   Colorado Springs, CO 80919

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

12.  IPR Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

13.  Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any

Expires: August 2003                                           [Page 13]

INTERNET-DRAFT         NFSv4.1: SECINFO Changes"           February 2003

   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Expires: August 2003                                           [Page 14]