idnits 2.17.1 draft-ietf-nfsv4-dns-rr-00.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 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 295. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (Oct 12, 2005) is 6769 days in the past. Is this intentional? 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: 'RFC2119' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 258, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1464 ** Obsolete normative reference: RFC 2929 (Obsoleted by RFC 5395) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Mesta 2 Internet-Draft Sun Microsystems, Inc. 3 Expires: April 15, 2006 Oct 12, 2005 5 A DNS RR for NFSv4 ID Domains 6 draft-ietf-nfsv4-dns-rr-00 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 18 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 as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 15, 2006. 33 Abstract 35 This document describes a new DNS Resource Record (RR) type that will 36 be utilized by NFSv4 clients and servers to determine the domain 37 string to utilize for on-the-wire user/group name attributes and ACL 38 entry information. Discussion and suggestions for improvements 39 requested. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. NFS4ID Resource Record Definition . . . . . . . . . . . . . . 4 45 3. Example: Using the NFS4ID RR . . . . . . . . . . . . . . . . . 5 46 3.1. NFS4ID: RR Unavailable . . . . . . . . . . . . . . . . . . 5 47 3.2. NFS4ID: RR Available . . . . . . . . . . . . . . . . . . . 5 48 3.3. NFS4ID: DNS Tree Traversal . . . . . . . . . . . . . . . . 6 49 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 50 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 51 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 52 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 53 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 54 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 55 10. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . 11 56 11. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . 11 58 1. Introduction 60 Version 4 of the Network File System (NFSv4) protocol specification 61 [RFC3530] introduces a way for clients and servers to exchange file 62 ownership and ACL entry information as string names qualified with a 63 domain name, whereas earlier versions of the protocol used 32-bit 64 integers for the same type of identifier meta data. Section 5.8 of 65 [RFC3530] defines the generic format for string based identifiers to 66 be "[user|group]@dns_domain". 68 The string identifier prescribed suggests that the domain to be used 69 for the on-the-wire format be a DNS domain. However, the use of an 70 NFSv4 client's and server's default DNS domain to qualify user/group 71 names would be inappropriate on network configurations that utilize 72 multiple DNS domains, but still use a common user/group name space 73 throughout. This would lead to user/group name recognition failures 74 across the network, at either client or server side, due to 75 potentially mismatched domains. More succinctly, accessing NFSv4 76 managed files across multiple DNS domains can cause string 77 identifiers to be mapped to "nobody", regardless of whether a common 78 user/group name space is shared or not. 80 The challenge presented is then to have a mechanism for distributing 81 a common domain configuration for use by NFSv4 implementations that 82 only deal with domain-agnostic identifiers; more specifically, for 83 NFSv4 clients and servers that are administratively controlled by 84 distinct DNS domains. 86 A natural solution for this type of problem would be to have NFSv4 87 clients and servers query their configured DNS server for the 88 specific "domain" to utilize for sending user/group and ACL 89 attributes across DNS boundaries. Thus, in a properly configured 90 deployment, having NFSv4 clients access NFSv4 servers on different 91 DNS domains that still use a common user/group name space, would not 92 lead to recognition failures due to the use of the same "domain" for 93 NFSv4 user names, group names and ACL entry information. 95 A secondary benefit of using a DNS RR for the NFSv4 domain data store 96 is that the resolver's searching mechanism can be leveraged to 97 perform higher level domain traversal. This enables properly 98 configured NFSv4 clients to perform searches on higher levels of the 99 DNS domain tree until either an NFS4ID RR is found or all 100 possibilities have been exhausted. 102 This is the solution proposed by this memo. 104 2. NFS4ID Resource Record Definition 106 The general syntax for an NFS4ID resource record, whose type is 107 expected to be IANA assigned as per [RFC2929], is: 109 NFS4ID "dname string" 111 where: 113 o , and specify the zone, time-to-live and "IN" 114 respectively, as defined in [RFC1034]. 116 o The RDATA for this record is a string that will be used to specify 117 the domain name to use in 'owner', 'owner_group' and ACL entry 118 information, as defined by [RFC3530]. 120 The proposed RR is meant for use solely by NFSv4; the use of the 121 RDATA field to store additional class information will lead to the 122 familiar sub-typing issues associated with the use of TXT RR's 123 [RFC1464]. 125 3. Example: Using the NFS4ID RR 127 As a real world example, assume that an enterprise has a top level 128 domain of "example.com" and that it has multiple (perhaps 129 geographically dispersed) DNS domains. For the sake of the current 130 discussion, two domains is more than enough; "foo.example.com" and 131 "bar.example.com". Assume further that NFSv4 has been deployed 132 across these DNS domains and there are active NFSv4 mounts crossing 133 the DNS domain boundary. 135 3.1. NFS4ID: RR Unavailable 137 Assuming that no NFS4ID RR's have been configured on either the 138 "foo.example.com" nor "bar.example.com" name servers, then the NFSv4 139 clients and servers that have active cross-domain mounts should be 140 sending user/group name attributes of the form "[user|group]@ 141 foo.example.com" or "[user|group]@bar.example.com". 143 If a user in client.foo.example.com wanted to access his/her files in 144 server.bar.example.com, the user would find his/her files (seemingly) 145 being owned by "nobody". The reason for this is that client.foo is 146 trying to match server.bar's domain to its own, and since the domains 147 are mismatched, that is, the DNS domain itself is being used for 148 NFSv4 transactions, the client has no choice but to reject the user/ 149 group mapping. 151 3.2. NFS4ID: RR Available 153 The following configuration would be expected in order to make the 154 NFS4ID RR available in both domains: 156 The "foo.example.com" domain zone file contains: 158 $ORIGIN foo.example.com. 160 foo.example.com. IN NFS4ID "example.com" 162 While the "bar.example.com" domain zone file contains: 164 $ORIGIN bar.example.com. 166 bar.example.com. IN NFS4ID "example.com" 168 Under this scenario, client.foo.example.com would access the user's 169 data in server.bar.example.com; this time, however, the user and 170 group name are of the form "[user|group@example.com" on-the-wire. 171 The client will attempt to match the domain in the in-bound user/ 172 group attribute data and will match its own configured domain since 173 both client.foo and server.bar are utilizing the same domain for 174 NFSv4 transactions. 176 3.3. NFS4ID: DNS Tree Traversal 178 Consider the case in which the top level domain zone file has the 179 following NFS4ID entry: 181 example.com. IN NFS4ID "example.com" 183 As previously stated, the lower level DNS domains, "foo.example.com" 184 and "bar.example.com", can each define their own NFS4ID RR's in order 185 to override the NFS4ID record defined by the top level domain. To 186 continue the example, assume that an NFS4ID record is only defined 187 for domain "foo.example.com" and it is defined to be: 189 foo.example.com. IN NFS4ID "foo.foo" 191 Assuming the NFSv4 clients' /etc/resolv.conf 'search' parameter has 192 been properly configured, an NFS4ID RR lookup in the 193 "foo.example.com" domain will yield the string "foo.foo", whereas a 194 lookup for the NFS4ID RR in the "bar.example.com" domain, will not 195 yield any value and will propagate to the higher level domain as 196 "example.com"; at this point, the string "example.com" will be 197 returned for NFS4ID RR lookups in domain "bar.example.com". 199 4. IANA Considerations 201 IANA is requested to allocate RR type code TBD for NFS4ID from the 202 standard RR type space. 204 5. Security Considerations 206 There are two main security considerations for this facility: 208 o Denial of service attacks where clients and servers are made to 209 disagree about their default NFSv4 domain and so ACL and file/ 210 directory ownership manipulation can be made to fail. 212 o Redirection attacks where a client is forced to use a different 213 domain than it was otherwise intended to use while a multi-domain 214 server can understand and distinguish between users (and groups) 215 with the same names but in different domains. In this attack a 216 user might be fooled into granting access to a file or directory 217 to the wrong user or group. For example, a "chown joe somefile" 218 command might be intended to reference "joe@one.domain" but the 219 client may be made to use a different domain to qualify "joe", 220 thus changing the ownership of 'somefile' to 221 "jane@some.other.domain". 223 The latter is of particular concern as servers capable of operating 224 in more than one domain are feasible and likely already exist. 226 The use of DNSSEC should foil both of these attacks, and thus, we 227 recommend its use. 229 6. Acknowledgments 231 David Robinson, Spencer Shepler, Nico Williams, Bill Sommerfeld, and 232 Olaf Kolkman. 234 7. Normative References 236 [RFC1034] Mockapetris, P., "Domain Names - Concepts And Facilities", 237 RFC 1034, Nov 1987. 239 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 240 Arbitrary String Attributes", RFC 1464, May 1993. 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, 246 "Domain Name System (DNS) IANA Considerations", RFC 2929, 247 Sep 2000. 249 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 250 Beame, C., Eisler, M., and D. Noveck, "Network File System 251 (NFS) version 4 Protocol", RFC 3530, April 2003. 253 8. Informative References 255 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 256 IANA Considerations Section in RFCs", Oct 1998. 258 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 259 March 1999. 261 9. Author's Address 263 Rick Mesta 264 Sun Microsystems, Inc. 265 5300 Riata Park Court 266 M/S: UAUS08-102 267 Austin, TX 78727 268 USA 270 Phone: +1 512-401-1076 271 Email: rick.mesta@sun.com 273 10. IPR Notices 275 The IETF takes no position regarding the validity or scope of any 276 Intellectual Property Rights or other rights that might be claimed to 277 pertain to the implementation or use of the technology described in 278 this document or the extent to which any license under such rights 279 might or might not be available; nor does it represent that it has 280 made any independent effort to identify any such rights. Information 281 on the procedures with respect to rights in RFC documents can be 282 found in BCP 78 and BCP 79. 284 Copies of IPR disclosures made to the IETF Secretariat and any 285 assurances of licenses to be made available, or the result of an 286 attempt made to obtain a general license or permission for the use of 287 such proprietary rights by implementers or users of this 288 specification can be obtained from the IETF on-line IPR repository at 289 http://www.ietf.org/ipr. 291 The IETF invites any interested party to bring to its attention any 292 copyrights, patents or patent applications, or other proprietary 293 rights that may cover technology that may be required to implement 294 this standard. Please address the information to the IETF at 295 ietf-ipr@ietf.org. 297 11. Copyright Statement 299 Copyright (C) The Internet Society (2005). This document is subject 300 to the rights, licenses and restrictions contained in BCP 78, and 301 except as set forth therein, the authors retain all their rights. 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.