idnits 2.17.1 draft-chiu-network-wnfs-sec-nego-01.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: ---------------------------------------------------------------------------- ** 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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 79 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2054], [RFC2055], [RFC1813]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1831' is mentioned on line 74, but not defined ** Obsolete undefined reference: RFC 1831 (Obsoleted by RFC 5531) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Chiu 2 Internet Draft M. Eisler 3 Category: Informational B. Callaghan 5 Security Negotiation for WebNFS 7 draft-chiu-network-wnfs-sec-nego-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months. 19 This Internet-Draft expires on April 4, 2000. Internet-Drafts may be 20 updated, replaced, or obsoleted by other documents at any time. It is not 21 appropriate to use Internet-Drafts as reference material or to cite them 22 other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To view the entire list of current Internet-Drafts, please check the "1id- 31 abstracts.txt" listing contained in the Internet-Drafts Shadow Directories 32 on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it 33 (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 34 Coast), or ftp.isi.edu (US West Coast). 36 Distribution of this memo is unlimited. 38 Abstract 40 This document describes a protocol for a WebNFS client [RFC2054] to 41 negotiate the desired security mechanism with a WebNFS server [RFC2055] 42 before the WebNFS client falls back to the MOUNT v3 protocol [RFC1813]. 43 This document is provided so that people can write compatible 44 implementations. 46 Table of Contents 48 1. Introduction ................................................2 49 2. Security Negotiation Multi-component LOOKUP .................3 50 3 Overloaded Filehandle .......................................4 51 3.1 Overloaded NFS Version 2 Filehandle .......................5 52 3.2 Overloaded NFS Version 3 Filehandle .......................5 53 4. WebNFS Security Negotiation .................................6 54 5. Security Considerations .....................................8 55 6. References ..................................................8 56 7. Acknowledgements ............................................9 57 8. Authors' Addresses ..........................................9 59 1. Introduction 61 The MOUNT protocol is used by an NFS client to obtain the necessary 62 filehandle for data access. MOUNT versions 1 and 2 [RFC1094] return NFS 63 version 2 filehandles, whereas MOUNT version 3 [RFC1813] returns NFS 64 version 3 filehandles. 66 Among the existing versions of the MOUNT protocol, only the MOUNT v3 67 provides an RPC procedure (MOUNTPROC3_MNT) which facilitates security 68 negotiation between an NFS v3 client and an NSF v3 server. When this RPC 69 procedure succeeds (MNT3_OK) the server returns to the client an array of 70 security mechanisms it supports for the specified pathanme, in addition to 71 an NFS v3 filehandle. 73 A security mechanism referred to in this document is a generalized security 74 flavor which can be an RPC authentication flavor [RFC1831] or a security 75 flavor referred to in the RPCSEC_GSS protocol [RFC2203]. A security 76 mechanism is represented as a four-octet integer. 78 No RPC procedures are available for security negotiation in versions 1 or 2 79 of the MOUNT protocol. 81 The NFS mount command provides a "sec=" option for an NFS client to specify 82 the desired security mechanism to use for NFS transactions. If this mount 83 option is not specified, the default action is to use the default security 84 mechanism over NFS v2 mounts, or to negotiate a security mechanism via the 85 MOUNTPROC3_MNT procedure of MOUNT v3 and use it over NFS v3 mounts. In the 86 latter, the client picks the first security mechanism in the array returned 87 from the server that is also supported on the client. 89 As specified in RFC 2054, a WebNFS client first assumes that the server 90 supports WebNFS and uses the publsc filehandle as the initial filehandle 91 for data access, eliminating the need for the MOUNT protocol. The WebNFS 92 client falls back to MOUNT if the server does not support WebNFS. 94 Since a WebNFS client does not use MOUNT initially, the MOUNTPROC3_MNT 95 procedure of MOUNT v3 is not available for security negotiation until the 96 WebNFS client falls back to MOUNT. A viable protocol needs to be devised 97 for the WebNFS client to negotiate security mechanisms with the server in 98 the absence of the MOUNTPROC3_MNT procedure. 100 The WebNFS security negotiation protocol must meet the following 101 requirements: 103 - Must work seamlessly with NFS v2 and v3, and the WebNFS protocols 105 - Must be backward compatible with servers that do not support 106 this negotiation 108 - Minimum number of network turnarounds (latency) 110 This document describes the WebNFS security negotiation protocol developed 111 by Sun Microsystems, Inc. Terminology and definitions from RFCs 2054 and 112 2055 are used in this document. The reader is expected to be familiar with 113 them. 115 2. Security Negotiation Multi-component LOOKUP 117 The goal of the WebNFS security negotiation is to allow a WebNFS client to 118 identify a security mechanism which is used by the WebNFS server to protect 119 a specified path and is also supported by the client. The WebNFS client 120 initiates the negotiation by sending the WebNFS server the path. The WebNFS 121 server responds with the array of security mechanisms it uses to secure the 122 specified path. From the array of security mechanisms the WebNFS client 123 selects the first one that it also supports. 125 Without introducing a new WebNFS request, the WebNFS security negotiation 126 is achieved by modifying the request and response of the existing multi- 127 component LOOKUP (MCL) operation [RFC2055]. Note that the MCL operation is 128 accomplished using the LOOKUP procedure (NFSPROC3_LOOKUP for NFS v3 and 129 NFSPROC_LOOKUP for NFS v2). This and the next sections describe how the 130 MCL request and response are modified to facilitate WebNFS security 131 negotiation. 133 For ease of reference, the modified MCL request is henceforth referred to 134 as SNEGO-MCL (security negotiation multi-component LOOKUP) request. 136 A multi-component LOOKUP request [RFC2055] is composed of a public 137 filehandle and a multi-component path: 139 For Canonical Path: 141 LOOKUP FH=0x0, "/a/b/c" 143 For Native Path: 145 LOOKUP FH=0x0, 0x80 "a:b:c" 147 A multi-component path is either an ASCII string of slash separated 148 components or a 0x80 character followed by a native path. Note that a 149 multi-component LOOKUP implies the use of the public filehandle in the 150 LOOKUP. 152 Similar to the MCL request, a SNEGO-MCL request consists of a public 153 filehandle and a pathname. However, the pathname is uniquely composed, as 154 described below, to distinguish it from other pathnames. 156 The pathname used in a SNEGO-MCL is the regular WebNFS multi-component path 157 prefixed with two octets. The first prefixed octet is the 0x81 non-ascii 158 character, similar to the 0x80 non-ascii character for the native paths. 159 This octet represents client's indication to negotiate security mechanisms. 160 It is followed by the security index octet which stores the current value 161 of the index into the array of security mechanisms to be returned from the 162 server. The security index always starts with one and gets incremented as 163 negotiation continues. It is then followed by the pathname, either an 164 ASCII string of slash separated canonical components or 0x80 and a native 165 path. 167 A security negotiation multi-component LOOKUP request looks like this: 169 For Canonical Path: 171 LOOKUP FH=0x0, 0x81 "/a/b/c" 173 For Native Path: 175 LOOKUP FH=0x0, 0x81 0x80 "a:b:c" 177 In the next section we will see how the MCL response is modified for WebNFS 178 security negotiation. 180 3. Overloaded Filehandle 182 As described in RFC2054, if a multi-component LOOKUP request succeeds, the 183 server responds with a valid filehandle: 185 LOOKUP FH=0x0, "a/b/c" 186 -----------> 187 <----------- 188 FH=0x3 190 NFS filehandles are used to uniquely identify a particular file or 191 directory on the server and are opaque to the client. The client neither 192 examines a filehandle nor has any knowledge of its contents. Thus, 193 filehandles make an ideal repository for the server to return the array of 194 security mechanisms to the client in response to a SNEGO-MCL request. 196 To a successful SNEGO-MCL request the server responds, in place of the 197 filehandle, with an array of integers that represents the valid security 198 mechanisms the client must use to access the given path. A length field is 199 introduced to store the size (in octets) of the array of integers. 201 As the filehandles are limited in size (32 octets for NFS v2 and up to 64 202 octets for NFS v3), it can happen that there are more security mechanisms 203 than the filehandles can accommodate. To circumvent this problem, a one- 204 octet status field is introduced which indicates whether there are more 205 security mechanisms (1 means yes, 0 means no) that require the client to 206 perform another SNEGO-MCL to get them. 208 To summarize, the response to a SNEGO-MCL request contains, in place of the 209 filehandle, the length field, the status field, and the array of security 210 mechanisms: 212 FH: length, status, {sec_1 sec_2 ... sec_n} 214 The next two sub-sections describe how NFS v2 and v3 filehandles are 215 "overloaded" to carry the length and status fields and the array of 216 security mechanisms. 218 3.1 Overloaded NFS Version 2 Filehandle 220 A regular NFS v2 filehandle is defined in RFC1094 as an opaque value 221 occupying 32 octets: 223 1 2 3 4 32 224 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+ 225 | | | | | | | | | ... | | | | | | | | 226 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+ 228 An overloaded NFS v2 filehandle looks like this: 230 1 2 3 4 5 8 32 231 +---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+ 232 | l | s | | | sec_1 | ... | sec_n | ... | | | 233 +---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+ 235 Note that the first four octets of an overloaded NFS v2 filehandle contain 236 the length octet, the status octet, and two padded octets to make them XDR 237 four-octet aligned. The length octet l = 4 * n, where n is the number of 238 security mechanisms sent in the current overloaded filehandle. Apparently, 239 an overloaded NFS v2 filehandle can carry up to seven security mechanisms. 241 3.2 Overloaded NFS Version 3 Filehandle 243 A regular NFS v3 filehandle is defined in RFC1813 as a variable length 244 opaque value occupying up to 64 octets. The length of the filehandle is 245 indicated by an integer value contained in a four octet value which 246 describes the number of valid octets that follow: 248 1 4 249 +---+---+---+---+ 250 | len | 251 +---+---+---+---+ 253 1 4 up to 64 254 +---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+ 255 | | | | | | | | | | | | | ... | | | | | 256 +---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+ 258 An overloaded NFS v3 filehandle looks like the following: 260 1 4 261 +---+---+---+---+ 262 | len | 263 +---+---+---+---+ 265 1 4 5 8 266 +---+---+---+---+---+---+---+---+ +---+---+---+---+ 267 | s | | | | sec_1 | ... | sec_n | 268 +---+---+---+---+---+---+---+---+ +---+---+---+---+ 269 Here, len = 4 * (n+1). Again, n is the number of security mechanisms 270 contained in the current overloaded filehandle. Three octets are padded 271 after the status octet to meet the XDR four-octet alignment requirement. 272 An overloaded NFS v3 filehandle can carry up to fifteen security 273 mechanisms. 275 4. WebNFS Security Negotiation 277 With the SNEGO-MCL request and the overloaded NFS v2 and v3 filehandles 278 defined above, the following diagram depicts the WebNFS security 279 negotiation protocol: 281 Client Server 282 ------ ------ 284 LOOKUP FH=0x0, 0x81 "path" 285 -----------> 286 <----------- 287 FH: length, status, {sec_1 sec_2 ... sec_n} 289 where 290 0x81 represents client's indication to negotiate security 291 mechanisms with the server, 293 path is either an ASCII string of slash separated components 294 or 0x80 and a native path, 296 sec-index, one octet, contains the index into the array of 297 security mechanisms the server uses to protect the specified 298 path, 300 status, one octet, indicates whether there are more security 301 mechanisms (1 means yes, 0 means no) that require the client 302 to perform another SNEGO-MCL to get them, 304 length (one octet for NFS v2 and four octets for NFS v3) 305 describes the number of valid octets that follow, 307 {sec_1 sec_2 ... sec_n} represents the array of security 308 mechanisms. As noted earlier, each security mechanism is 309 represented by a four-octet integer. 311 Here is an example showing the WebNFS security negotiation protocol with 312 NFS v2. In the example it is assumed the server shares /export with 10 313 security mechanisms {0x3900 0x3901 0x3902 ... 0x3909} on the export, two 314 SNEGO-MCL requests would be needed for the client to get the complete 315 security information: 317 LOOKUP FH=0x0, 0x81 0x01 "/export" 318 -----------> 319 <----------- 320 0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906} 322 LOOKUP FH=0x0, 0x81 0x08 "/export" 323 -----------> 324 <----------- 325 0x0c, 0x00, {0x3907 0x3908 0x3909} 327 The order of the security mechanisms returned in an overloaded filehandle 328 implies preferences, i.e., one is more recommended than those following it. 329 The ordering is the same as that returned by the MOUNT v3 protocol. 331 The following shows a typical scenario which illustrates how the WebNFS 332 security negotiation is accomplished in the course of accessing publicly 333 shared filesystems. 335 Normally, a WebNFS client first makes a regular multi-component LOOKUP 336 request using the public filehandle to obtain the filehandle for the 337 specified path. Since the WebNFS client does not have any prior knowledge 338 as to how the path is protected by the server the default security 339 mechanism is used in this first multi-component LOOKUP. If the default 340 security mechanism does not meet server's requirements, the server replies 341 with the AUTH_TOOWEAK RPC authentication error, indicating that the default 342 security mechanism is not valid and the WebNFS client needs to use a 343 stronger one. 345 Upon receiving the AUTH_TOOWEAK error, to find out what security mechanisms 346 are required to access the specified path the WebNFS client sends a SNEGO- 347 MCL request, using the default security mechanism. 349 If the SNEGO-MCL request succeeds the server responds with the filehandle 350 overloaded with the array of security mechanisms required for the specified 351 path. If the server does not support WebNFS security negotiation, the 352 SNEGO-MCL request fails with NFSERR_IO for NFS v2 or NFS3ERR_IO for NFS v3 353 [RFC2055]. 355 Depending on the size of the array of security mechanisms, the WebNFS 356 client may have to make more SNEGO-MCL requests to get the complete array. 358 For successful SNEGO-MCL requests, the WebNFS client retrieves the array of 359 security mechanisms from the overloaded filehandle, selects an appropriate 360 one, and issues a regular multi-component LOOKUP using the selected 361 security mechanism to acquire the filehandle. 363 All subsequent NFS requests are then made using the selected security 364 mechanism and the filehandle. 366 The following depicts the scenario outlined above. It is assumed that the 367 server shares /export/home as follows: 369 share -o sec=sec_1:sec_2:sec_3,public /export/home 371 and AUTH_SYS is the client's default security mechanism and is not one of 372 {sec_1, sec_2, sec_3}. 374 Client Server 375 ------ ------ 377 LOOKUP FH=0x0, "/export/home" 378 AUTH_SYS 379 -----------> 380 <----------- 381 AUTH_TOOWEAK 383 LOOKUP FH=0x0, 0x81 0x01 "/export/home" 384 AUTH_SYS 385 -----------> 386 <----------- 387 overloaded FH: length, status, {sec_1 sec_2 sec_3} 389 LOOKUP FH=0x0, "/export/home" 390 sec_n 391 -----------> 392 <----------- 393 FH = 0x01 395 NFS request with FH=0x01 396 sec_n 397 -----------> 398 <----------- 399 ... 401 In the above scenario, the first request is a regular multi-component 402 LOOKUP which fails with the AUTH_TOOWEAK error. The client then issues a 403 SNEGO-MCL request to get the security information. 405 There are WebNFS implementations that allow the public filehandle to work 406 with NFS protocol procedures other than LOOKUP. For those WebNFS 407 implementations, if the first request is not a regular multi-component 408 LOOKUP and it fails with AUTH_TOOWEAK, the client should issue a SNEGO-MCL 409 with 411 0x81 0x01 "." 413 as the path to get the security information. 415 5. Security Considerations 417 The reader may note that no mandatory security mechsnisms are specified in 418 the protocol that the client must use in making SNEGO-MCL requests. 420 Normally, the client uses the default security mechanism configured on his 421 system in the first SNEGO-MCL request. If the default security mechanism 422 is not valid the server replies with the AUTH_TOOWEAK error. In this case 423 the server does not return the array of security mechanisms to the client. 424 The client can then make another SNEGO-MCL request using a stronger 425 security mechanism. This continues until the client hits a valid one or 426 has exhausted all the supported security mechanisms. 428 6. References 430 [RFC1094] Sun Microsystems, Inc., "Network Filesystem 431 Specification", RFC 1094, March 1989. NFS 432 version 2 protocol specification. 433 http://www.ietf.org/rfc/rfc1094.txt 435 [RFC1813] Sun Microsystems, Inc., "NFS Version 3 Protocol 436 Specification", RFC 1813, June 1995. NFS version 437 3 protocol specification. 438 http://www.ietf.org/rfc/rfc1813.txt 440 [RFC2054] Callaghan, B., "WebNFS Client Specification", 441 RFC 2054, October 1996. 442 http://www.ietf.org/rfc/rfc2054.txt 444 [RFC2055] Callaghan, B., "WebNFS Server Specification", 445 RFC 2055, October 1996. 446 http://www.ietf.org/rfc/rfc2055.txt 448 [RFC2203] Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS 449 Protocol Specification", RFC 2203, September 1997. 450 http://www.ietf.org/rfc/rfc2203.txt 452 7. Acknowledgements 454 This specification was extensively brainstormed and reviewed by the NFS 455 group of Solaris Software Division. 457 8. Authors' Addresses 459 Alex Chiu 460 Sun Microsystems, Inc. 461 901 San Antonio Road 462 Palo Alto, CA 94303 464 Phone: +1 (650) 786-6465 466 E-mail: alex.chiu@Eng.sun.com 468 Mike Eisler 469 Sun Microsystems, Inc. 471 901 San Antonio Road 472 Palo Alto, CA 94303 474 Phone: +1 (719) 599-9026 476 E-mail: michael.eisler@Eng.sun.com 478 Brent Callaghan 479 Sun Microsystems, Inc. 480 901 San Antonio Road 481 Palo Alto, CA 94303 483 Phone: +1 (650) 786-5067 485 E-mail: brent.callaghan@Eng.sun.com