idnits 2.17.1 draft-ietf-nfsv4-secinfo-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 703. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3530]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 128: '...rent directory, then the server SHOULD...' RFC 2119 keyword, line 131: '...rver does so, it MUST support the new ...' RFC 2119 keyword, line 353: '...ient and server, the client SHOULD try...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7225 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1832' is defined on line 660, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Eisler 2 Internet-Draft Editor 3 Document: draft-ietf-nfsv4-secinfo-02.txt Network Appliance, Inc. 4 July 2004 6 NFSv4.1: SECINFO Changes 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than a "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html" 31 ABSTRACT 33 This document proposes some changes to security negotiation in NFS 34 version 4 [RFC3530]. It is hoped, but not promised, that these 35 changes will be part of a new minor version of NFS: NFSv4.1. 37 TABLE OF CONTENTS 39 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 2. Modified Operation 16: LOOKUPP - Lookup Parent Directory . . . 2 41 3. Modified Operation 33: SECINFO - Obtain Available Security . . 4 42 4. New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed 43 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 44 5. Clarification of Security Negotiation in NFSv4.1 . . . . . . . 8 45 5.1. PUTFH + LOOKUP . . . . . . . . . . . . . . . . . . . . . . . 9 46 5.2. PUTFH + LOOKUPP . . . . . . . . . . . . . . . . . . . . . . 9 47 5.3. PUTFH + SECINFO . . . . . . . . . . . . . . . . . . . . . . 9 48 5.4. PUTFH + Anything Else . . . . . . . . . . . . . . . . . . 10 49 6. RPC Definition File Changes . . . . . . . . . . . . . . . . 10 50 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 51 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 52 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 53 10. Normative References . . . . . . . . . . . . . . . . . . . 14 54 11. Informative References . . . . . . . . . . . . . . . . . . 14 55 12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 14 56 13. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 15 57 14. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 15 59 1. Introduction 61 This document assumes understanding of the NFSv4.0 specification. 63 The NFSv4.0 specification contains three oversights and ambiguities 64 with respect to the SECINFO operation. 66 First, it is impossible for the client to use the SECINFO operation 67 to determine the correct security triple for accessing a parent 68 directory. This is because SECINFO takes as arguments the current 69 file handle and a component name. However, NFSv4.0 uses the LOOKUPP 70 operation to get the parent directory of the current file handle. If 71 the client uses the wrong security when issuing the LOOKUPP, and gets 72 back an NFS4ERR_WRONGSEC error, SECINFO is useless to the client. The 73 client is left with guessing which security the server will accept. 74 This defeats the purpose of SECINFO, which was to provide an 75 efficient method of negotiating security. 77 Second, there is ambiguity as to what the server should do when it is 78 passed a LOOKUP operation such that the server restricts access to 79 the current file handle with one security triple, and access to the 80 component with a different triple, and remote procedure call uses one 81 of the two security triples. Should the server allow the LOOKUP? 83 Third, there is a problem as to what the client must do (or can do), 84 whenever the server returns NFS4ERR_WRONGSEC in response to a PUTFH 85 operation. The NFSv4.0 specification says that client should issue a 86 SECINFO using the parent filehandle and the component name of the 87 filehandle that PUTFH was issued with. This may not be convenient for 88 the client. 90 This document resolves the above three issues in the context of 91 NFSv4.1. 93 2. Modified Operation 16: LOOKUPP - Lookup Parent Directory 95 If the NFSv4 minor version is 1, then following replaces section 96 14.2.14 of the NFSv4.0 specification. The LOOKUPP operation's "over 97 the wire" format is not altered, but the semantics are slightly 98 modified to account for the addition of SECINFO_NO_NAME. 100 SYNOPSIS 101 (cfh) -> (cfh) 103 ARGUMENT 104 /* CURRENT_FH: object */ 105 void; 107 RESULT 108 struct LOOKUPP4res { 109 /* CURRENT_FH: directory */ 110 nfsstat4 status; 111 }; 113 DESCRIPTION 114 The current filehandle is assumed to refer to a regular 115 directory or a named attribute directory. LOOKUPP assigns the 116 filehandle for its parent directory to be the current 117 filehandle. If there is no parent directory an NFS4ERR_NOENT 118 error must be returned. Therefore, NFS4ERR_NOENT will be 119 returned by the server when the current filehandle is at the 120 root or top of the server's file tree. 122 As for LOOKUP, LOOKUPP will also cross mountpoints. 124 If the current filehandle is not a directory or named attribute 125 directory, the error NFS4ERR_NOTDIR is returned. 127 If the requester's security flavor does not match that 128 configured for the parent directory, then the server SHOULD 129 return NFS4ERR_WRONGSEC (a future minor revision of NFSv4 may 130 upgrade this to MUST) in the LOOKUPP response. However, if the 131 server does so, it MUST support the new SECINFO_NO_NAME 132 operation, so that the client can gracefully determine the 133 correct security flavor. See the discussion of the 134 SECINFO_NO_NAME operation for a description. 136 ERRORS 137 NFS4ERR_ACCESS 138 NFS4ERR_BADHANDLE 139 NFS4ERR_FHEXPIRED 140 NFS4ERR_IO 141 NFS4ERR_MOVED 142 NFS4ERR_NOENT 143 NFS4ERR_NOFILEHANDLE 144 NFS4ERR_NOTDIR 145 NFS4ERR_RESOURCE 146 NFS4ERR_SERVERFAULT 147 NFS4ERR_STALE 148 NFS4ERR_WRONGSEC 150 3. Modified Operation 33: SECINFO - Obtain Available Security 152 If the NFSv4 minor version is 1, then following replaces section 153 14.2.31 of the NFSv4.0 specification. The SECINFO operation's "over 154 the wire" format is not altered, but the semantics are slightly 155 modified to account for the addition of SECINFO_NO_NAME. 157 SYNOPSIS 158 (cfh), name -> { secinfo } 160 ARGUMENT 161 struct SECINFO4args { 162 /* CURRENT_FH: directory */ 163 component4 name; 164 }; 166 RESULT 167 enum rpc_gss_svc_t {/* From RFC 2203 */ 168 RPC_GSS_SVC_NONE = 1, 169 RPC_GSS_SVC_INTEGRITY = 2, 170 RPC_GSS_SVC_PRIVACY = 3 171 }; 173 struct rpcsec_gss_info { 174 sec_oid4 oid; 175 qop4 qop; 176 rpc_gss_svc_t service; 177 }; 179 union secinfo4 switch (uint32_t flavor) { 180 case RPCSEC_GSS: 181 rpcsec_gss_info flavor_info; 182 default: 183 void; 184 }; 186 typedef secinfo4 SECINFO4resok<>; 188 union SECINFO4res switch (nfsstat4 status) { 189 case NFS4_OK: 190 SECINFO4resok resok4; 191 default: 192 void; 193 }; 195 DESCRIPTION 196 The SECINFO operation is used by the client to obtain a list of 197 valid RPC authentication flavors for a specific directory 198 filehandle, file name pair. SECINFO should apply the same 199 access methodology used for LOOKUP when evaluating the name. 200 Therefore, if the requester does not have the appropriate access 201 to LOOKUP the name then SECINFO must behave the same way and 202 return NFS4ERR_ACCESS. 204 The result will contain an array which represents the security 205 mechanisms available, with an order corresponding to the 206 server's preferences, the most preferred being first in the 207 array. The client is free to pick whatever security mechanism it 208 both desires and supports, or to pick in the server's preference 209 order the first one it supports. The array entries are 210 represented by the secinfo4 structure. The field 'flavor' will 211 contain a value of AUTH_NONE, AUTH_SYS (as defined in 212 [RFC1831]), or RPCSEC_GSS (as defined in [RFC2203]). The field 213 flavor can also any other security flavor registered with IANA. 215 For the flavors AUTH_NONE and AUTH_SYS, no additional security 216 information is returned. The same is true of many (if not most) 217 other security flavors, including AUTH_DH. For a return value of 218 RPCSEC_GSS, a security triple is returned that contains the 219 mechanism object id (as defined in [RFC2743]), the quality of 220 protection (as defined in [RFC2743]) and the service type (as 221 defined in [RFC2203]). It is possible for SECINFO to return 222 multiple entries with flavor equal to RPCSEC_GSS with different 223 security triple values. 225 On success, the current filehandle retains its value. 227 If the name has a length of 0 (zero), or if name does not obey 228 the UTF-8 definition, the error NFS4ERR_INVAL will be returned. 230 IMPLEMENTATION 231 The SECINFO operation is expected to be used by the NFS client 232 when the error value of NFS4ERR_WRONGSEC is returned from 233 another NFS operation. This signifies to the client that the 234 server's security policy is different from what the client is 235 currently using. At this point, the client is expected to 236 obtain a list of possible security flavors and choose what best 237 suits its policies. 239 As mentioned, the server's security policies will determine when 240 a client request receives NFS4ERR_WRONGSEC. The operations 241 which may receive this error are: LINK, LOOKUP, LOOKUPP, OPEN, 242 PUTFH, PUTPUBFH, PUTROOTFH, RESTOREFH, RENAME, and indirectly 243 READDIR. LINK and RENAME will only receive this error if the 244 security used for the operation is inappropriate for saved 245 filehandle. With the exception of READDIR, these operations 246 represent the point at which the client can instantiate a 247 filehandle into the "current filehandle" at the server. The 248 filehandle is either provided by the client (PUTFH, PUTPUBFH, 249 PUTROOTFH) or generated as a result of a name to filehandle 250 translation (LOOKUP and OPEN). RESTOREFH is different because 251 the filehandle is a result of a previous SAVEFH. Even though 252 the filehandle, for RESTOREFH, might have previously passed the 253 server's inspection for a security match, the server will check 254 it again on RESTOREFH to ensure that the security policy has not 255 changed. 257 If the client wants to resolve an error return of 258 NFS4ERR_WRONGSEC, the following will occur: 260 o For LOOKUP and OPEN, the client will use SECINFO with the 261 same current filehandle and name as provided in the 262 original LOOKUP or OPEN to enumerate the available security 263 triples. 265 o For LINK, PUTFH, PUTROOTFH, PUTPUBFH, RENAME, and 266 RESTOREFH, the client will use SECINFO_NO_NAME { style = 267 current_fh }. The client will prefix the SECINFO_NO_NAME 268 operation with the appropriate PUTFH, PUTPUBFH, or 269 PUTROOTFH operation that provides the file handled 270 originally provided by the PUTFH, PUTPUBFH, PUTROOTFH, or 271 RESTOREFH, or for the failed LINK or RENAME, the SAVEFH. 273 ========================================================= 274 NOTE: In NFSv4.0, the client was required to use SECINFO, 275 and had to reconstruct the parent of the original file 276 handle, and the component name of the original filehandle. 277 ======================================================== 279 o For LOOKUPP, the client will use SECINFO_NO_NAME { style = 280 parent } and provide the filehandle with equals the 281 filehandle originally provided to LOOKUPP. 283 The READDIR operation will not directly return the 284 NFS4ERR_WRONGSEC error. However, if the READDIR request 285 included a request for attributes, it is possible that the 286 READDIR request's security triple did not match that of a 287 directory entry. If this is the case and the client has 288 requested the rdattr_error attribute, the server will return the 289 NFS4ERR_WRONGSEC error in rdattr_error for the entry. 291 See the section "Security Considerations" for a discussion on 292 the recommendations for security flavor used by SECINFO and 293 SECINFO_NO_NAME. 295 ERRORS 296 NFS4ERR_ACCESS 297 NFS4ERR_BADCHAR 298 NFS4ERR_BADHANDLE 299 NFS4ERR_BADNAME 300 NFS4ERR_BADXDR 301 NFS4ERR_FHEXPIRED 302 NFS4ERR_INVAL 303 NFS4ERR_MOVED 304 NFS4ERR_NAMETOOLONG 305 NFS4ERR_NOENT 306 NFS4ERR_NOFILEHANDLE 307 NFS4ERR_NOTDIR 308 NFS4ERR_RESOURCE 309 NFS4ERR_SERVERFAULT 310 NFS4ERR_STALE 312 4. New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed Object 314 SYNOPSIS 315 (cfh), secinfo_style -> { secinfo } 317 ARGUMENT 318 enum secinfo_style_4 { 319 current_fh = 0, 320 parent = 1 321 }; 323 typedef secinfo_style_4 SECINFO_NO_NAME4args; 325 RESULT 326 typedef SECINFO4res SECINFO_NO_NAME4res; 328 DESCRIPTION 329 Like the SECINFO operation, SECINFO_NO_NAME is used by the 330 client to obtain a list of valid RPC authentication flavors for 331 a specific file object. Unlike SECINFO, SECINFO_NO_NAME only 332 works with objects are accessed by file handle. 334 There are two styles of SECINFO_NO_NAME, as determined by the 335 value of the secinfo_style_4 enumeration. If "current_fh" is 336 passed, then SECINFO_NO_NAME is querying for the required 337 security for the current filehandle. If "parent" is passed, then 338 SECINFO_NO_NAME is querying for the required security of the 339 current filehandles's parent. If the style selected is "parent", 340 then SECINFO should apply the same access methodology used for 341 LOOKUPP when evaluating the traversal to the parent directory. 342 Therefore, if the requester does not have the appropriate access 343 to LOOKUPP the parent then SECINFO_NO_NAME must behave the same 344 way and return NFS4ERR_ACCESS. 346 Note that if PUTFH, PUTPUBFH, or PUTROOTFH return 347 NFS4ERR_WRONGSEC, this is tantamount to the server asserting 348 that the client will have to guess what the required security 349 is, because there is no way to query. Therefore, the client 350 must iterate through the security triples available at the 351 client and reattempt the PUTFH, PUTROOTFH or PUTPUBFH operation. 352 In the unfortunate event none of the MANDATORY security triples 353 are supported by the client and server, the client SHOULD try 354 using others that support integrity. Failing that, the client 355 can try using other forms (e.g. AUTH_SYS and AUTH_NONE), but 356 because such forms lack integrity checks, this puts the client 357 at risk. 359 The server implementor should pay particular attention to the 360 section "Clarification of Security Negotiation in NFSv4.1" for 361 implementation suggestions for avoiding NFS4ERR_WRONGSEC error 362 returns from PUTFH, PUTROOTFH or PUTPUBFH. 364 Everything else about SECINFO_NO_NAME is the same as SECINFO. 365 See the previous discussion on SECINFO. 367 IMPLEMENTATION 368 See the previous discussion on SECINFO. 370 ERRORS 371 NFS4ERR_ACCESS 372 NFS4ERR_BADCHAR 373 NFS4ERR_BADHANDLE 374 NFS4ERR_BADNAME 375 NFS4ERR_BADXDR 376 NFS4ERR_FHEXPIRED 377 NFS4ERR_INVAL 378 NFS4ERR_MOVED 379 NFS4ERR_NAMETOOLONG 380 NFS4ERR_NOENT 381 NFS4ERR_NOFILEHANDLE 382 NFS4ERR_NOTDIR 383 NFS4ERR_RESOURCE 384 NFS4ERR_SERVERFAULT 385 NFS4ERR_STALE 387 5. Clarification of Security Negotiation in NFSv4.1 389 This section attempts to clarify NFSv4.1 security negotiation issues. 391 Unless noted otherwise, for any mention of PUTFH in this section, the 392 reader should interpret it as applying to PUTROOTFH and PUTPUBFH in 393 addition to PUTFH. 395 5.1. PUTFH + LOOKUP 397 The server implementation may decide whether to impose any 398 restrictions on export security administration. There are at least 399 three approaches (Sc is the flavor set of the child export, Sp that 400 of the parent), 402 a. Sc <= Sp (<= for subset) 404 b. Sc ^ Sp != {} (^ for intersection, {} for the empty set) 406 c. free form 408 To support b (when client chooses a flavor that is not a member of 409 Sp) and c, PUTFH must NOT return NFS4ERR_WRONGSEC in case of security 410 mismatch. Instead, it should be returned from the LOOKUP that 411 follows. 413 Since the above guideline does not contradict a, it should be 414 followed in general. 416 5.2. PUTFH + LOOKUPP 418 Since SECINFO only works its way down, there is no way LOOKUPP can 419 return NFS4ERR_WRONGSEC without the server implementing 420 SECINFO_NO_NAME. SECINFO_NO_NAME solves this issue because via style 421 "parent", it works in the opposite direction as SECINFO (component 422 name is implicit in this case). 424 5.3. PUTFH + SECINFO 426 This case should be treated specially. 428 A security sensitive client should be allowed to choose a strong 429 flavor when querying a server to determine a file object's permitted 430 security flavors. The security flavor chosen by the client does not 431 have to be included in the flavor list of the export. Of course the 432 server has to be configured for whatever flavor the client selects, 433 otherwise the request will fail at RPC authentication. 435 In theory, there is no connection between the security flavor used by 436 SECINFO and those supported by the export. But in practice, the 437 client may start looking for strong flavors from those supported by 438 the export, followed by those in the mandatory set. 440 5.4. PUTFH + Anything Else 442 PUTFH must return NFS4ERR_WRONGSEC in case of security mismatch. This 443 is the most straightforward approach without having to add 444 NFS4ERR_WRONGSEC to every other operations. 446 PUTFH + SECINFO_NO_NAME (style "current_fh") is needed for the client 447 to recover from NFS4ERR_WRONGSEC. 449 6. RPC Definition File Changes 451 /* 452 * Copyright (C) The Internet Society (2004) 453 * All Rights Reserved. 454 */ 456 /* 457 * nfs41_prot.x 458 */ 460 %/* $Id: nfs41_prot.x,v 1.2 2004/06/18 23:19:28 mre Exp $ */ 462 /* new operation, SECINFO_NO_NAME */ 464 enum secinfo_style_4 { 465 current_fh = 0, 466 parent = 1 467 }; 469 typedef secinfo_style_4 SECINFO_NO_NAME4args; 470 typedef SECINFO4res SECINFO_NO_NAME4res; 472 /* 473 * Operation arrays 474 */ 476 enum nfs_opnum4 { 477 OP_ACCESS = 3, 478 OP_CLOSE = 4, 479 OP_COMMIT = 5, 480 OP_CREATE = 6, 481 OP_DELEGPURGE = 7, 482 OP_DELEGRETURN = 8, 483 OP_GETATTR = 9, 484 OP_GETFH = 10, 485 OP_LINK = 11, 486 OP_LOCK = 12, 487 OP_LOCKT = 13, 488 OP_LOCKU = 14, 489 OP_LOOKUP = 15, 490 OP_LOOKUPP = 16, 491 OP_NVERIFY = 17, 492 OP_OPEN = 18, 493 OP_OPENATTR = 19, 494 OP_OPEN_CONFIRM = 20, 495 OP_OPEN_DOWNGRADE = 21, 496 OP_PUTFH = 22, 497 OP_PUTPUBFH = 23, 498 OP_PUTROOTFH = 24, 499 OP_READ = 25, 500 OP_READDIR = 26, 501 OP_READLINK = 27, 502 OP_REMOVE = 28, 503 OP_RENAME = 29, 504 OP_RENEW = 30, 505 OP_RESTOREFH = 31, 506 OP_SAVEFH = 32, 507 OP_SECINFO = 33, 508 OP_SETATTR = 34, 509 OP_SETCLIENTID = 35, 510 OP_SETCLIENTID_CONFIRM = 36, 511 OP_VERIFY = 37, 512 OP_WRITE = 38, 513 OP_RELEASE_LOCKOWNER = 39, 514 OP_SECINFO_NO_NAME = 40, 515 OP_ILLEGAL = 10044 516 }; 518 union nfs_argop4 switch (nfs_opnum4 argop) { 519 case OP_ACCESS: ACCESS4args opaccess; 520 case OP_CLOSE: CLOSE4args opclose; 521 case OP_COMMIT: COMMIT4args opcommit; 522 case OP_CREATE: CREATE4args opcreate; 523 case OP_DELEGPURGE: DELEGPURGE4args opdelegpurge; 524 case OP_DELEGRETURN: DELEGRETURN4args opdelegreturn; 525 case OP_GETATTR: GETATTR4args opgetattr; 526 case OP_GETFH: void; 527 case OP_LINK: LINK4args oplink; 528 case OP_LOCK: LOCK4args oplock; 529 case OP_LOCKT: LOCKT4args oplockt; 530 case OP_LOCKU: LOCKU4args oplocku; 531 case OP_LOOKUP: LOOKUP4args oplookup; 532 case OP_LOOKUPP: void; 533 case OP_NVERIFY: NVERIFY4args opnverify; 534 case OP_OPEN: OPEN4args opopen; 535 case OP_OPENATTR: OPENATTR4args opopenattr; 536 case OP_OPEN_CONFIRM: OPEN_CONFIRM4args opopen_confirm; 537 case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4args opopen_downgrade; 538 case OP_PUTFH: PUTFH4args opputfh; 539 case OP_PUTPUBFH: void; 540 case OP_PUTROOTFH: void; 541 case OP_READ: READ4args opread; 542 case OP_READDIR: READDIR4args opreaddir; 543 case OP_READLINK: void; 544 case OP_REMOVE: REMOVE4args opremove; 545 case OP_RENAME: RENAME4args oprename; 546 case OP_RENEW: RENEW4args oprenew; 547 case OP_RESTOREFH: void; 548 case OP_SAVEFH: void; 549 case OP_SECINFO: SECINFO4args opsecinfo; 550 case OP_SETATTR: SETATTR4args opsetattr; 551 case OP_SETCLIENTID: SETCLIENTID4args opsetclientid; 552 case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4args 553 opsetclientid_confirm; 554 case OP_VERIFY: VERIFY4args opverify; 555 case OP_WRITE: WRITE4args opwrite; 556 case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4args 557 oprelease_lockowner; 558 case OP_SECINFO_NO_NAME: SECINFO_NO_NAME4args 559 opsecinfo_no_name; 560 case OP_ILLEGAL: void; 561 }; 563 union nfs_resop4 switch (nfs_opnum4 resop){ 564 case OP_ACCESS: ACCESS4res opaccess; 565 case OP_CLOSE: CLOSE4res opclose; 566 case OP_COMMIT: COMMIT4res opcommit; 567 case OP_CREATE: CREATE4res opcreate; 568 case OP_DELEGPURGE: DELEGPURGE4res opdelegpurge; 569 case OP_DELEGRETURN: DELEGRETURN4res opdelegreturn; 570 case OP_GETATTR: GETATTR4res opgetattr; 571 case OP_GETFH: GETFH4res opgetfh; 572 case OP_LINK: LINK4res oplink; 573 case OP_LOCK: LOCK4res oplock; 574 case OP_LOCKT: LOCKT4res oplockt; 575 case OP_LOCKU: LOCKU4res oplocku; 576 case OP_LOOKUP: LOOKUP4res oplookup; 577 case OP_LOOKUPP: LOOKUPP4res oplookupp; 578 case OP_NVERIFY: NVERIFY4res opnverify; 579 case OP_OPEN: OPEN4res opopen; 580 case OP_OPENATTR: OPENATTR4res opopenattr; 581 case OP_OPEN_CONFIRM: OPEN_CONFIRM4res opopen_confirm; 582 case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4res opopen_downgrade; 583 case OP_PUTFH: PUTFH4res opputfh; 584 case OP_PUTPUBFH: PUTPUBFH4res opputpubfh; 585 case OP_PUTROOTFH: PUTROOTFH4res opputrootfh; 586 case OP_READ: READ4res opread; 587 case OP_READDIR: READDIR4res opreaddir; 588 case OP_READLINK: READLINK4res opreadlink; 589 case OP_REMOVE: REMOVE4res opremove; 590 case OP_RENAME: RENAME4res oprename; 591 case OP_RENEW: RENEW4res oprenew; 592 case OP_RESTOREFH: RESTOREFH4res oprestorefh; 593 case OP_SAVEFH: SAVEFH4res opsavefh; 594 case OP_SECINFO: SECINFO4res opsecinfo; 595 case OP_SETATTR: SETATTR4res opsetattr; 596 case OP_SETCLIENTID: SETCLIENTID4res opsetclientid; 597 case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4res 598 opsetclientid_confirm; 599 case OP_VERIFY: VERIFY4res opverify; 600 case OP_WRITE: WRITE4res opwrite; 601 case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4res 602 oprelease_lockowner; 603 case OP_SECINFO_NO_NAME: SECINFO_NO_NAME4res 604 opsecinfo_no_name; 605 case OP_ILLEGAL: ILLEGAL4res opillegal; 606 }; 608 struct COMPOUND4args { 609 utf8str_cs tag; 610 uint32_t minorversion; /* == 1 !!! */ 611 nfs_argop4 argarray<>; 612 }; 614 struct COMPOUND4res { 615 nfsstat4 status; 616 utf8str_cs tag; 617 nfs_resop4 resarray<>; 618 }; 620 7. Security Considerations 622 The security considerations of NFSv4.0 apply to NFSv4.1, with the 623 proviso that security considerations of SECINFO apply to the new 624 operation, SECINFO_NO_NAME. 626 8. IANA Considerations 628 The IANA considerations of NFSv4.0 apply to NFSv4.1. 630 9. Acknowledgements 632 The basis for the text in this document comes from the NFSv4.0 633 specification as edited by Spencer Shepler. Peng Dai wrote the 634 "Clarification of Security Negotiation in NFSv4.1" section. Sergey 635 Klyushin contributed to the discussion that led to this document. 636 Mike Eisler proposed the SECINFO_NO_NAME operation to address the 637 issues Sergey and Peng brought to the nfsv4 working group's 638 attention. Carl Burnett reviewed an earlier draft of this document 639 which resulted in substantial improvements. 641 10. Normative References 643 [RFC3530] 644 S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. 645 Eisler, D. Noveck, Internet RFC3530, "NFS version 4 Protocol", 646 April, 2003. 648 [RFC1831] 649 R. Srinivasan, Internet RFC1831, "RPC: Remote Procedure Call 650 Protocol Specification Version 2", August, 1995. 652 [RFC2743] 653 J. Linn, Internet RFC2743, "Generic Security Service Application 654 Program Interface Version 2, Update 1", January, 2000. 656 [RFC2203] 657 M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS 658 Protocol Specification", September, 1997. 660 [RFC1832] 661 R. Srinivasan, Internet RFC1832, "XDR: External Data 662 Representation Standard", August, 1995. 664 11. Informative References 666 None. 668 12. Editor's Address 670 Mike Eisler 671 5765 Chase Point Circle 672 Colorado Springs, CO 80919 673 USA 675 Phone: 719-599-9026 676 EMail: mike@eisler.com 678 Comments on this document should be sent to the NFSv4 working group: 679 nfsv4@ietf.org 681 13. IPR Notices 683 The IETF takes no position regarding the validity or scope of any 684 Intellectual Property Rights or other rights that might be claimed to 685 pertain to the implementation or use of the technology described in 686 this document or the extent to which any license under such rights 687 might or might not be available; nor does it represent that it has 688 made any independent effort to identify any such rights. Information 689 on the procedures with respect to rights in RFC documents can be 690 found in BCP 78 and BCP 79. 692 Copies of IPR disclosures made to the IETF Secretariat and any 693 assurances of licenses to be made available, or the result of an 694 attempt made to obtain a general license or permission for the use of 695 such proprietary rights by implementers or users of this 696 specification can be obtained from the IETF on-line IPR repository at 697 http://www.ietf.org/ipr. 699 The IETF invites any interested party to bring to its attention any 700 copyrights, patents or patent applications, or other proprietary 701 rights that may cover technology that may be required to implement 702 this standard. Please address the information to the IETF at ietf- 703 ipr@ietf.org. 705 14. Copyright Notice 707 Copyright (C) The Internet Society (2004). This document is subject 708 to the rights, licenses and restrictions contained in BCP 78, and 709 except as set forth therein, the authors retain all their rights. 711 This document and the information contained herein are provided on an 712 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 713 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 714 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 715 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 716 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 717 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.