idnits 2.17.1 draft-eisler-nfsv4-secinfo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 ([RFC3010bis]), 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 226: '...ient and server, the client SHOULD try...' RFC 2119 keyword, line 230: '... the server SHOULD allow the clie...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 638 has weird spacing: '...for the purpo...' -- 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 (February 2003) is 7735 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 586, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3010 (Obsoleted by RFC 3530) ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Eisler 3 Internet-Draft Editor 4 Document: draft-eisler-nfsv4-secinfo-00.txt Network Appliance, Inc. 5 February 2003 7 NFSv4.1: SECINFO Changes 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "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 [RFC3010bis]. It is hoped that these changes will be part of a new 35 minor version of NFS: NFSv4.1. 37 TABLE OF CONTENTS 39 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 2. Modified Operation 33: SECINFO - Obtain Available Security . . 2 41 3. New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed 42 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 43 4. Clarification of Security Negotiation in NFSv4.1 . . . . . . . 7 44 4.1. PUTFH+LOOKUP . . . . . . . . . . . . . . . . . . . . . . . . 7 45 4.2. PUTFH+LOOKUPP . . . . . . . . . . . . . . . . . . . . . . . 8 46 4.3. PUTFH+SECINFO . . . . . . . . . . . . . . . . . . . . . . . 8 47 4.4. PUTFH+Anything Else . . . . . . . . . . . . . . . . . . . . 8 48 5. RPC Definition File Changes . . . . . . . . . . . . . . . . . 8 49 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 51 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 52 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 53 10. Informative References . . . . . . . . . . . . . . . . . . 13 54 11. Editor's Address . . . . . . . . . . . . . . . . . . . . . 13 55 12. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 13 56 13. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 13 58 1. Introduction 60 This document assumes understanding of the NFSv4.0 specification. 62 The NFSv4.0 specification contains three oversights and ambiguities 63 with respect to the SECINFO operation. 65 First, it is impossible for the client to use the SECINFO operation 66 to determine the correct security triple for accessing a parent 67 directory. This is because SECINFO takes as arguments the current 68 file handle and a component name. However, NFSv4.0 uses the LOOKUPP 69 operation to get the parent directory of the current file handle. If 70 the client uses the wrong security when issuing the LOOKUPP, and gets 71 back an NFS4ERR_WRONGSEC error, SECINFO is useless to the client. The 72 client is left with guessing which security the server will accept. 73 This defeats the purpose of SECINFO, which was to provide an 74 efficient method of negotiating security. 76 Second, there is ambiguity as to what the server should do when it is 77 passed a LOOKUP operation such that the server restricts access to 78 the current file handle with one security triple, and access to the 79 component with a different triple, and remote procedure call uses one 80 of the two security triples. Should the server allow the LOOKUP? 82 Third, there is a problem as to what the client must do (or can do), 83 whenever the server returns NFS4ERR_WRONGSEC in response to a PUTFH 84 operation. The NFSv4.0 specification says that client should issue a 85 SECINFO using the parent filehandle and the component name of the 86 filehandle that PUTFH was issued with. This may not be convenient for 87 the client. 89 This document resolves the above three issues in the context of 90 NFSv4.1. 92 2. Modified Operation 33: SECINFO - Obtain Available Security 94 If the NFSv4 minor version 1, then following replaces section 14.2.31 95 of the NFSv4.0 specification. The SECINFO operation's "over the 96 wire" format is not altered, but the semantics are slightly modified 97 to account for addition of SECINFO_NO_NAME. 99 SYNOPSIS 100 (cfh), name -> { secinfo } 102 ARGUMENT 103 struct SECINFO4args { 104 /* CURRENT_FH: directory */ 105 component4 name; 106 }; 108 RESULT 109 enum rpc_gss_svc_t {/* From RFC 2203 */ 110 RPC_GSS_SVC_NONE = 1, 111 RPC_GSS_SVC_INTEGRITY = 2, 112 RPC_GSS_SVC_PRIVACY = 3 113 }; 115 struct rpcsec_gss_info { 116 sec_oid4 oid; 117 qop4 qop; 118 rpc_gss_svc_t service; 119 }; 121 union secinfo4 switch (uint32_t flavor) { 122 case RPCSEC_GSS: 123 rpcsec_gss_info flavor_info; 124 default: 125 void; 126 }; 128 typedef secinfo4 SECINFO4resok<>; 130 union SECINFO4res switch (nfsstat4 status) { 131 case NFS4_OK: 132 SECINFO4resok resok4; 133 default: 134 void; 135 }; 137 DESCRIPTION 138 The SECINFO operation is used by the client to obtain a list of 139 valid RPC authentication flavors for a specific directory 140 filehandle, file name pair. SECINFO should apply the same 141 access methodology used for LOOKUP when evaluating the name. 142 Therefore, if the requester does not have the appropriate access 143 to LOOKUP the name then SECINFO must behave the same way and 144 return NFS4ERR_ACCESS. 146 The result will contain an array which represents the security 147 mechanisms available, with an order corresponding to the 148 server's preferences, the most preferred being first in the 149 array. The client is free to pick whatever security mechanism it 150 both desires and supports, or to pick in the server's preference 151 order the first one it supports. The array entries are 152 represented by the secinfo4 structure. The field 'flavor' will 153 contain a value of AUTH_NONE, AUTH_SYS (as defined in 154 [RFC1831]), or RPCSEC_GSS (as defined in [RFC2203]). 156 For the flavors AUTH_NONE and AUTH_SYS, no additional security 157 information is returned. For a return value of RPCSEC_GSS, a 158 security triple is returned that contains the mechanism object 159 id (as defined in [RFC2743]), the quality of protection (as 160 defined in [RFC2743]) and the service type (as defined in 161 [RFC2203]). It is possible for SECINFO to return multiple 162 entries with flavor equal to RPCSEC_GSS with different security 163 triple values. 165 On success, the current filehandle retains its value. 167 If the name has a length of 0 (zero), or if name does not obey 168 the UTF-8 definition, the error NFS4ERR_INVAL will be returned. 170 IMPLEMENTATION 171 The SECINFO operation is expected to be used by the NFS client 172 when the error value of NFS4ERR_WRONGSEC is returned from 173 another NFS operation. This signifies to the client that the 174 server's security policy is different from what the client is 175 currently using. At this point, the client is expected to 176 obtain a list of possible security flavors and choose what best 177 suits its policies. 179 As mentioned, the server's security policies will determine when 180 a client request receives NFS4ERR_WRONGSEC. The operations 181 which may receive this error are: LINK, LOOKUP, LOOKUPP, OPEN, 182 PUTFH, PUTPUBFH, PUTROOTFH, RESTOREFH, RENAME, and indirectly 183 READDIR. LINK and RENAME will only receive this error if the 184 security used for the operation is inappropriate for saved 185 filehandle. With the exception of READDIR, these operations 186 represent the point at which the client can instantiate a 187 filehandle into the "current filehandle" at the server. The 188 filehandle is either provided by the client (PUTFH, PUTPUBFH, 189 PUTROOTFH) or generated as a result of a name to filehandle 190 translation (LOOKUP and OPEN). RESTOREFH is different because 191 the filehandle is a result of a previous SAVEFH. Even though 192 the filehandle, for RESTOREFH, might have previously passed the 193 server's inspection for a security match, the server will check 194 it again on RESTOREFH to ensure that the security policy has not 195 changed. 197 If the client wants to resolve an error return of 198 NFS4ERR_WRONGSEC, the following will occur: 200 o For LOOKUP and OPEN, the client will use SECINFO with the 201 same current filehandle and name as provided in the original 202 LOOKUP or OPEN to enumerate the available security triples. 204 o For LINK, PUTFH, RENAME, and RESTOREFH, the client will use 205 SECINFO_NO_NAME { style = current_fh }, and provide the 206 filehandle which equals to the filehandle originally provided 207 by the PUTFH, RESTOREFH, or for LINK and RENAME, the SAVEFH. 209 ========================================================= 210 NOTE: In NFSv4.0, the client was required to use SECINFO, and 211 had to reconstruct the parent of the original file handle, 212 and the component name of the original filehandle. 213 ======================================================== 215 o For LOOKUPP, the client will use SECINFO_NO_NAME { style = 216 parent } and provide the filehandle with equals the 217 filehandle originally provided to LOOKUPP. 219 o For PUTROOTFH and PUTPUBFH, the client will be unable to use 220 SECINFO or SECINFO_NO_NAME operations since te SECINFO 221 operations require a current filehandle and none exist for 222 PUTROOTFH and PUTPUBFH. Therefore, the client must iterate 223 through the security triples available at the client and 224 reattempt the PUTROOTFH or PUTPUBFH operation. In the 225 unfortunate event none of the MANDATORY security triples are 226 supported by the client and server, the client SHOULD try 227 using others that support integrity. Failing that, the client 228 can try using AUTH_NONE, but because such forms lack 229 integrity checks, this puts the client at risk. Nonetheless, 230 the server SHOULD allow the client to use whatever security 231 form the client requests and the server supports, since the 232 risks of doing so are on the client. 234 The READDIR operation will not directly return the 235 NFS4ERR_WRONGSEC error. However, if the READDIR request 236 included a request for attributes, it is possible that the 237 READDIR request's security triple does not match that of a 238 directory entry. If this is the case and the client has 239 requested the rdattr_error attribute, the server will return the 240 NFS4ERR_WRONGSEC error in rdattr_error for the entry. 242 See the section "Security Considerations" for a discussion on 243 the recommendations for security flavor used by SECINFO and 244 SECINFO_NO_NAME. 246 ERRORS 247 NFS4ERR_ACCESS 248 NFS4ERR_BADCHAR 249 NFS4ERR_BADHANDLE 250 NFS4ERR_BADNAME 251 NFS4ERR_BADXDR 252 NFS4ERR_FHEXPIRED 253 NFS4ERR_INVAL 254 NFS4ERR_MOVED 255 NFS4ERR_NAMETOOLONG 256 NFS4ERR_NOENT 257 NFS4ERR_NOFILEHANDLE 258 NFS4ERR_NOTDIR 259 NFS4ERR_RESOURCE 260 NFS4ERR_SERVERFAULT 261 NFS4ERR_STALE 263 3. New Operation 40: SECINFO_NO_NAME - Get Security on Unnamed Object 265 SYNOPSIS 266 (cfh), secinfo_style -> { secinfo } 268 ARGUMENT 269 enum secinfo_style_4 { 270 current_fh = 0, 271 parent = 1 272 }; 274 typedef secinfo_style_4 SECINFO_NO_NAME4args; 276 RESULT 277 typedef SECINFO4res SECINFO_NO_NAME4res; 279 DESCRIPTION 280 Like the SECINFO operation, SECINFO_NO_NAME is used by the 281 client to obtain a list of valid RPC authentication flavors for 282 a specific file object. Unlike SECINFO, SECINFO_NO_NAME only 283 works with objects are accessed by file handle. 285 There are two styles of SECINFO_NO_NAME, as determined by the 286 value of the secinfo_style_4 enumeration. If "current_fh" is 287 passed, then SECINFO_NO_NAME is querying for the required 288 security for the current filehandle. If "parent" is passed, then 289 SECINFO_NO_NAME is querying for the required security of the 290 current filehandles's parent. If the style selected is "parent", 291 then SECINFO should apply the same access methodology used for 292 LOOKUPP when evaluating the traversal to the parent directory. 293 Therefore, if the requester does not have the appropriate access 294 to LOOKUPP the parent then SECINFO_NO_NAME must behave the same 295 way and return NFS4ERR_ACCESS. 297 Everything else about SECINFO_NO_NAME is the same as SECINFO. 298 See the previous discussion on SECINFO. 300 IMPLEMENTATION 301 See the previous discussion on SECINFO. 303 ERRORS 304 NFS4ERR_ACCESS 305 NFS4ERR_BADCHAR 306 NFS4ERR_BADHANDLE 307 NFS4ERR_BADNAME 308 NFS4ERR_BADXDR 309 NFS4ERR_FHEXPIRED 310 NFS4ERR_INVAL 311 NFS4ERR_MOVED 312 NFS4ERR_NAMETOOLONG 313 NFS4ERR_NOENT 314 NFS4ERR_NOFILEHANDLE 315 NFS4ERR_NOTDIR 316 NFS4ERR_RESOURCE 317 NFS4ERR_SERVERFAULT 318 NFS4ERR_STALE 320 4. Clarification of Security Negotiation in NFSv4.1 322 This section attempts to clarify NFSv4.1 security negotiation issues. 324 4.1. PUTFH+LOOKUP 326 The server implementation may decide whether to impose any 327 restrictions on export security administration. There are at least 328 three approaches (Sc is the flavor set of the child export, Sp that 329 of the parent), 331 a. Sc <= Sp (<= for subset) 333 b. Sc ^ Sp != {} (^ for intersection) 335 c. free form 337 To support b (when client chooses a flavor that is not a member of 338 Sp) and c, PUTFH must NOT return NFS4ERR_WRONGSEC in case of security 339 mismatch. Instead, it should be returned from the LOOKUP that 340 follows. 342 Since the above guideline does not contradict a, it should be 343 followed in general. 345 4.2. PUTFH+LOOKUPP 347 Since SECINFO only works its way down, there is no way LOOKUPP can 348 return NFS4ERR_WRONGSEC without implementing SECINFO_NO_NAME. 349 SECINFO_NO_NAME solves this issue because via style "parent", it 350 works in the opposite direction as SECINFO (component name is 351 implicit in this case). 353 4.3. PUTFH+SECINFO 355 This case should be treated specially. 357 A security sensitive client should be allowed to choose a strong 358 flavor. The security flavor chosen by the client does not have to be 359 included in the flavor list of the export. Of course the server has 360 to be configured for it, otherwise the request will fail at RPC 361 authentication. 363 In theory, there is no connection between the security flavor used by 364 SECINFO and those supported by the export. But in practice, the 365 client may start looking for strong flavors from those supported by 366 the export, followed by those in the mandatory set. 368 4.4. PUTFH+Anything Else 370 PUTFH must return NFS4ERR_WRONGSEC in case of security mismatch. This 371 seems is the most straightforward approach without having to add 372 NFS4ERR_WRONGSEC to every other operations. 374 SECINFO_NO_NAME (style "current_fh") is needed for the client to 375 recover from NFS4ERR_WRONGSEC. 377 5. RPC Definition File Changes 379 /* 380 * Copyright (C) The Internet Society (2003) 381 * All Rights Reserved. 382 */ 384 /* 385 * nfs41_prot.x 386 */ 388 %/* $Id: nfs41_prot.x,v 1.1 2003/02/23 05:10:53 mre Exp mre $ */ 390 /* new operation, SECINFO_NO_NAME */ 391 enum secinfo_style_4 { 392 current_fh = 0, 393 parent = 1 394 }; 396 typedef secinfo_style_4 SECINFO_NO_NAME4args; 397 typedef SECINFO4res SECINFO_NO_NAME4res; 399 /* 400 * Operation arrays 401 */ 403 enum nfs_opnum4 { 404 OP_ACCESS = 3, 405 OP_CLOSE = 4, 406 OP_COMMIT = 5, 407 OP_CREATE = 6, 408 OP_DELEGPURGE = 7, 409 OP_DELEGRETURN = 8, 410 OP_GETATTR = 9, 411 OP_GETFH = 10, 412 OP_LINK = 11, 413 OP_LOCK = 12, 414 OP_LOCKT = 13, 415 OP_LOCKU = 14, 416 OP_LOOKUP = 15, 417 OP_LOOKUPP = 16, 418 OP_NVERIFY = 17, 419 OP_OPEN = 18, 420 OP_OPENATTR = 19, 421 OP_OPEN_CONFIRM = 20, 422 OP_OPEN_DOWNGRADE = 21, 423 OP_PUTFH = 22, 424 OP_PUTPUBFH = 23, 425 OP_PUTROOTFH = 24, 426 OP_READ = 25, 427 OP_READDIR = 26, 428 OP_READLINK = 27, 429 OP_REMOVE = 28, 430 OP_RENAME = 29, 431 OP_RENEW = 30, 432 OP_RESTOREFH = 31, 433 OP_SAVEFH = 32, 434 OP_SECINFO = 33, 435 OP_SETATTR = 34, 436 OP_SETCLIENTID = 35, 437 OP_SETCLIENTID_CONFIRM = 36, 438 OP_VERIFY = 37, 439 OP_WRITE = 38, 440 OP_RELEASE_LOCKOWNER = 39, 441 OP_SECINFO_NO_NAME = 40, 442 OP_ILLEGAL = 10044 443 }; 445 union nfs_argop4 switch (nfs_opnum4 argop) { 446 case OP_ACCESS: ACCESS4args opaccess; 447 case OP_CLOSE: CLOSE4args opclose; 448 case OP_COMMIT: COMMIT4args opcommit; 449 case OP_CREATE: CREATE4args opcreate; 450 case OP_DELEGPURGE: DELEGPURGE4args opdelegpurge; 451 case OP_DELEGRETURN: DELEGRETURN4args opdelegreturn; 452 case OP_GETATTR: GETATTR4args opgetattr; 453 case OP_GETFH: void; 454 case OP_LINK: LINK4args oplink; 455 case OP_LOCK: LOCK4args oplock; 456 case OP_LOCKT: LOCKT4args oplockt; 457 case OP_LOCKU: LOCKU4args oplocku; 458 case OP_LOOKUP: LOOKUP4args oplookup; 459 case OP_LOOKUPP: void; 460 case OP_NVERIFY: NVERIFY4args opnverify; 461 case OP_OPEN: OPEN4args opopen; 462 case OP_OPENATTR: OPENATTR4args opopenattr; 463 case OP_OPEN_CONFIRM: OPEN_CONFIRM4args opopen_confirm; 464 case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4args opopen_downgrade; 465 case OP_PUTFH: PUTFH4args opputfh; 466 case OP_PUTPUBFH: void; 467 case OP_PUTROOTFH: void; 468 case OP_READ: READ4args opread; 469 case OP_READDIR: READDIR4args opreaddir; 470 case OP_READLINK: void; 471 case OP_REMOVE: REMOVE4args opremove; 472 case OP_RENAME: RENAME4args oprename; 473 case OP_RENEW: RENEW4args oprenew; 474 case OP_RESTOREFH: void; 475 case OP_SAVEFH: void; 476 case OP_SECINFO: SECINFO4args opsecinfo; 477 case OP_SETATTR: SETATTR4args opsetattr; 478 case OP_SETCLIENTID: SETCLIENTID4args opsetclientid; 479 case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4args 480 opsetclientid_confirm; 481 case OP_VERIFY: VERIFY4args opverify; 482 case OP_WRITE: WRITE4args opwrite; 483 case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4args 484 oprelease_lockowner; 485 case OP_SECINFO_NO_NAME: SECINFO_NO_NAME4args 486 opsecinfo_no_name; 487 case OP_ILLEGAL: void; 488 }; 490 union nfs_resop4 switch (nfs_opnum4 resop){ 491 case OP_ACCESS: ACCESS4res opaccess; 492 case OP_CLOSE: CLOSE4res opclose; 493 case OP_COMMIT: COMMIT4res opcommit; 494 case OP_CREATE: CREATE4res opcreate; 495 case OP_DELEGPURGE: DELEGPURGE4res opdelegpurge; 496 case OP_DELEGRETURN: DELEGRETURN4res opdelegreturn; 497 case OP_GETATTR: GETATTR4res opgetattr; 498 case OP_GETFH: GETFH4res opgetfh; 499 case OP_LINK: LINK4res oplink; 500 case OP_LOCK: LOCK4res oplock; 501 case OP_LOCKT: LOCKT4res oplockt; 502 case OP_LOCKU: LOCKU4res oplocku; 503 case OP_LOOKUP: LOOKUP4res oplookup; 504 case OP_LOOKUPP: LOOKUPP4res oplookupp; 505 case OP_NVERIFY: NVERIFY4res opnverify; 506 case OP_OPEN: OPEN4res opopen; 507 case OP_OPENATTR: OPENATTR4res opopenattr; 508 case OP_OPEN_CONFIRM: OPEN_CONFIRM4res opopen_confirm; 509 case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4res opopen_downgrade; 510 case OP_PUTFH: PUTFH4res opputfh; 511 case OP_PUTPUBFH: PUTPUBFH4res opputpubfh; 512 case OP_PUTROOTFH: PUTROOTFH4res opputrootfh; 513 case OP_READ: READ4res opread; 514 case OP_READDIR: READDIR4res opreaddir; 515 case OP_READLINK: READLINK4res opreadlink; 516 case OP_REMOVE: REMOVE4res opremove; 517 case OP_RENAME: RENAME4res oprename; 518 case OP_RENEW: RENEW4res oprenew; 519 case OP_RESTOREFH: RESTOREFH4res oprestorefh; 520 case OP_SAVEFH: SAVEFH4res opsavefh; 521 case OP_SECINFO: SECINFO4res opsecinfo; 522 case OP_SETATTR: SETATTR4res opsetattr; 523 case OP_SETCLIENTID: SETCLIENTID4res opsetclientid; 524 case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4res 525 opsetclientid_confirm; 526 case OP_VERIFY: VERIFY4res opverify; 527 case OP_WRITE: WRITE4res opwrite; 528 case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4res 529 oprelease_lockowner; 530 case OP_SECINFO_NO_NAME: SECINFO_NO_NAME4res 531 opsecinfo_no_name; 532 case OP_ILLEGAL: ILLEGAL4res opillegal; 533 }; 535 struct COMPOUND4args { 536 utf8str_cs tag; 537 uint32_t minorversion; /* == 1 !!! */ 538 nfs_argop4 argarray<>; 539 }; 541 struct COMPOUND4res { 542 nfsstat4 status; 543 utf8str_cs tag; 544 nfs_resop4 resarray<>; 545 }; 547 6. Security Considerations 549 The security considerations of NFSv4.0 apply to NFSv4.1, with the 550 proviso that security considerations of SECINFO apply to the new 551 operation, SECINFO_NO_NAME. 553 7. IANA Considerations 555 The IANA considerations of NFSv4.0 apply to NFSv4.1. 557 8. Acknowledgements 559 The basis for the text in this document comes from the NFSv4.0 560 specification as edited by Spencer Shepler. Dai Peng wrote the 561 "Clarification of Security Negotiation in NFSv4.1" section. Sergey 562 Klyushin contributed to the discussion that led to this document. 563 Mike Eisler proposed the SECINFO_NO_NAME operation to address the 564 issues Sergey and Peng brought to the nfsv4 working group's 565 attention. 567 9. Normative References 569 [RFC3010bis] 570 S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. 571 Eisler, D. Noveck, A work in progress, "NFS version 4 Protocol", 572 November, 2002. 574 [RFC1831] 575 R. Srinivasan, Internet RFC1831, "RPC: Remote Procedure Call 576 Protocol Specification Version 2", August, 1995. 578 [RFC2743] 579 J. Linn, Internet RFC2743, "Generic Security Service Application 580 Program Interface Version 2, Update 1", January, 2000. 582 [RFC2203] 583 M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS 584 Protocol Specification", September, 1997. 586 [RFC1832] 587 R. Srinivasan, Internet RFC1832, "XDR: External Data 588 Representation Standard", August, 1995. 590 10. Informative References 592 None. 594 11. Editor's Address 596 Mike Eisler 597 5765 Chase Point Circle 598 Colorado Springs, CO 80919 599 USA 601 Phone: 719-599-9026 602 EMail: mike@eisler.com 604 12. IPR Notices 606 The IETF takes no position regarding the validity or scope of any 607 intellectual property or other rights that might be claimed to 608 pertain to the implementation or use of the technology described in 609 this document or the extent to which any license under such rights 610 might or might not be available; neither does it represent that it 611 has made any effort to identify any such rights. Information on the 612 IETF's procedures with respect to rights in standards-track and 613 standards-related documentation can be found in BCP-11. Copies of 614 claims of rights made available for publication and any assurances of 615 licenses to be made available, or the result of an attempt made to 616 obtain a general license or permission for the use of such 617 proprietary rights by implementors or users of this specification can 618 be obtained from the IETF Secretariat. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights which may cover technology that may be required to practice 623 this standard. Please address the information to the IETF Executive 624 Director. 626 13. Copyright Notice 628 Copyright (C) The Internet Society (2003). All Rights Reserved. 630 This document and translations of it may be copied and furnished to 631 others, and derivative works that comment on or otherwise explain it 632 or assist in its implementation may be prepared, copied, published 633 and distributed, in whole or in part, without restriction of any 634 kind, provided that the above copyright notice and this paragraph are 635 included on all such copies and derivative works. However, this 636 document itself may not be modified in any way, such as by removing 637 the copyright notice or references to the Internet Society or other 638 Internet organizations, except as needed for the purpose of 639 developing Internet standards in which case the procedures for 640 copyrights defined in the Internet Standards process must be 641 followed, or as required to translate it into languages other than 642 English. 644 The limited permissions granted above are perpetual and will not be 645 revoked by the Internet Society or its successors or assigns. 647 This document and the information contained herein is provided on an 648 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 649 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 650 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 651 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 652 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.