1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
|
<pre>Internet Engineering Task Force (IETF) W. Adamson
Request for Comments: 8000 NetApp
Category: Standards Track N. Williams
ISSN: 2070-1721 Cryptonector
November 2016
<span class="h1">Requirements for NFSv4 Multi-Domain Namespace Deployment</span>
Abstract
This document presents requirements for the deployment of the NFSv4
protocols for the construction of an NFSv4 file namespace in
environments with multiple NFSv4 Domains. To participate in an NFSv4
multi-domain file namespace, the server must offer a multi-domain-
capable file system and support RPCSEC_GSS for user authentication.
In most instances, the server must also support identity-mapping
services.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc8000">http://www.rfc-editor.org/info/rfc8000</a>.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Adamson & Williams Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Federated File System . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. Stand-Alone NFSv4 Domain Deployment Examples . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. AUTH_SYS with Name@domain . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. RPCSEC_GSS with Name@domain . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. Multi-Domain Constraints to the NFSv4 Protocol . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Name@domain Constraints . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.1.1">6.1.1</a>. NFSv4 Domain and DNS Services . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.1.2">6.1.2</a>. NFSv4 Domain and Name Services . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. RPC Security Constraints . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.2.1">6.2.1</a>. NFSv4 Domain and Security Services . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7">7</a>. Stand-Alone Examples in an NFSv4 Multi-Domain Deployment . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. Resolving Multi-Domain Authorization Information . . . . . . <a href="#page-12">12</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The NFSv4 protocols NFSv4.0 [<a href="./rfc7530" title=""Network File System (NFS) Version 4 Protocol"">RFC7530</a>], NFSv4.1 [<a href="./rfc5661" title=""Network File System (NFS) Version 4 Minor Version 1 Protocol"">RFC5661</a>], and NFSv4.2
[<a href="./rfc7862" title=""Network File System (NFS) Version 4 Minor Version 2 Protocol"">RFC7862</a>] introduce the concept of an NFS Domain. An NFSv4 Domain is
defined as a set of users and groups using the NFSv4 name@domain user
and group identification syntax with the same specified @domain.
Previous versions of the NFS protocol, such as NFSv3 [<a href="./rfc1813" title=""NFS Version 3 Protocol Specification"">RFC1813</a>], use
the UNIX-centric user identification mechanism of numeric user and
group ID for the uid3 and gid3 [<a href="./rfc1813" title=""NFS Version 3 Protocol Specification"">RFC1813</a>] file attributes and for
identity in the authsys_parms AUTH_SYS credential defined in the Open
Network Computing (ONC) Remote Procedure Call (RPC) protocol
[<a href="./rfc5531" title=""RPC: Remote Procedure Call Protocol Specification Version 2"">RFC5531</a>]. <a href="./rfc2624#section-6.1">Section 6.1 of [RFC2624]</a> notes that the use of UNIX-
centric numeric IDs limits the scale of NFS to large local work
groups. UNIX-centric numeric IDs are not unique across NFSv3
deployments and so are not designed for Internet scaling achieved by
taking into account multiple naming domains and multiple naming
mechanisms (see <a href="#section-6.2">Section 6.2</a>). The NFSv4 Domain's use of the
name@domain syntax provides this Internet scaling by allowing servers
<span class="grey">Adamson & Williams Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
and clients to translate between the external name@domain string
representation to a local or internal numeric (or other identifier)
representation, which matches internal implementation needs.
Multi-domain deployments require support for unique identities across
the deployment's name services and security services, as well as the
use of multi-domain file systems capable of the on-disk
representation of identities belonging to multiple NFSv4 Domains.
The name@domain syntax can provide unique identities and thus enables
the NFSv4 multi-domain file namespace.
Unlike previous versions of NFS, the NFSv4 protocols define a
referral mechanism (<a href="./rfc7530#section-8.4.3">Section 8.4.3 of [RFC7530]</a>) that allows a single
server or a set of servers to present a multi-server namespace that
encompasses file systems located on multiple servers. This enables
the establishment of site-wide, organization-wide, or even a truly
global file namespace.
The NFSv4 protocols' name@domain syntax and referral mechanism along
with the use of RPCSEC_GSS security mechanisms enables the
construction of an NFSv4 multi-domain file namespace.
This document presents requirements on the deployment of the NFSv4
protocols for the construction of an NFSv4 file namespace in
environments with multiple NFSv4 Domains. To participate in an NFSv4
multi-domain file namespace, the server must offer a multi-domain-
capable file system and support RPCSEC_GSS [<a href="./rfc2203" title=""RPCSEC_GSS Protocol Specification"">RFC2203</a>] for user
authentication. In most instances, the server must also support
identity-mapping services.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
NFSv4 Domain: A set of users and groups using the NFSv4 name@domain
user and group identification syntax with the same specified
@domain.
Stand-alone NFSv4 Domain: A deployment of the NFSv4 protocols and
NFSv4 file namespace in an environment with a single NFSv4 Domain.
<span class="grey">Adamson & Williams Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
Local representation of identity: A representation of a user or a
group of users capable of being stored persistently within a file
system. Typically, such representations are identical to the form
in which users and groups are represented within internal server
APIs. Examples are numeric IDs such as a uidNumber (UID),
gidNumber (GID) [<a href="./rfc2307" title=""An Approach for Using LDAP as a Network Information Service"">RFC2307</a>], or a Windows Security Identifier (SID)
[<a href="#ref-CIFS" title=""[MS-CIFS]: Common Internet File System (CIFS) Protocol"">CIFS</a>]. In some cases, the identifier space for user and groups
overlap, requiring anyone using such an ID to know a priori
whether the identifier is for a user or a group.
Unique identity: An on-the-wire form of identity that is unique
across an NFSv4 multi-domain namespace that can be mapped to a
local representation. For example, the NFSv4 name@domain or the
Kerberos principal [<a href="./rfc4120" title=""The Kerberos Network Authentication Service (V5)"">RFC4120</a>].
Multi-domain: In this document, the term "multi-domain" always
refers to multiple NFSv4 Domains.
Multi-domain-capable file system: A local file system that uses a
local ID form that can represent NFSv4 identities from multiple
domains.
Principal: An RPCSEC_GSS [<a href="./rfc2203" title=""RPCSEC_GSS Protocol Specification"">RFC2203</a>] authentication identity. It is
usually, but not always, a user; rarely, if ever, a group; and
sometimes a host or server.
Authorization Context: A collection of information about a principal
such as user name, userID, group membership, etc., used in
authorization decisions.
Stringified UID or GID: NFSv4 owner and group strings that consist
of decimal numeric values with no leading zeros and that do not
contain an '@' sign. See <a href="./rfc5661#section-5.9">Section 5.9 of [RFC5661]</a>.
Name Service: Facilities that provide the mapping between {NFSv4
Domain, group, or user name} and the appropriate local
representation of identity. Also includes facilities providing
mapping between a security principal and local representation of
identity. Can be applied to unique identities or principals from
within local and remote domains. Often provided by a Directory
Service such as the Lightweight Directory Access Protocol (LDAP)
[<a href="./rfc4511" title=""Lightweight Directory Access Protocol (LDAP): The Protocol"">RFC4511</a>].
Name Service Switch (nsswitch): A facility that provides a variety
of sources for common configuration databases and name resolution
mechanisms.
<span class="grey">Adamson & Williams Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
FedFS: The Federated File System (FedFS) [<a href="./rfc5716" title=""Requirements for Federated File Systems"">RFC5716</a>] describes the
requirements and administrative tools to construct a uniform NFSv4
file-server-based namespace that is capable of spanning a whole
enterprise and that is easy to manage.
Domain: This term is used in multiple contexts where it has
different meanings. "NFSv4 Domain" and "multi-domain" are defined
above.
DNS domain: A set of computers, services, or any Internet
resource identified by a DNS domain name [<a href="./rfc1034" title=""Domain names - concepts and facilities"">RFC1034</a>].
Security realm or domain: A set of configured security providers,
users, groups, security roles, and security policies running a
single security protocol and administered by a single entity,
for example, a Kerberos realm.
FedFS domain: A file namespace that can cross multiple shares on
multiple file servers using file-access protocols such as
NFSv4. A FedFS domain is typically a single administrative
entity and has a name that is similar to a DNS domain name.
Also known as a "Federation".
Administrative domain: A set of users, groups, computers, and
services administered by a single entity. Can include multiple
DNS domains, NFSv4 Domains, security domains, and FedFS
domains.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Federated File System</span>
The FedFS is the standardized method of constructing and
administrating an enterprise-wide NFSv4 file system and is thus
referenced in this document. The requirements for multi-domain
deployments described in this document apply to all NFSv4 multi-
domain deployments, whether or not they are run as a FedFS.
Stand-alone NFSv4 Domain deployments can be run in many ways. While
a FedFS can be run within all stand-alone NFSv4 Domain
configurations, some of these configurations (<a href="#section-5">Section 5</a>) are not
compatible with joining a multi-domain FedFS namespace.
<span class="grey">Adamson & Williams Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Identity Mapping</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. NFSv4 Server Identity Mapping</span>
NFSv4 servers deal with two kinds of identities: authentication
identities (referred to here as "principals") and authorization
identities ("users" and "groups" of users). NFSv4 supports multiple
authentication methods, each authenticating an "initiator principal"
(typically representing a user) to an "acceptor principal" (always
corresponding to the NFSv4 server). NFSv4 does not prescribe how to
represent authorization identities on file systems. All file access
decisions constitute "authorization" and are made by NFSv4 servers
using authorization context information and file metadata related to
authorization, such as a file's access control list (ACL).
NFSv4 servers may be required to perform two kinds of mappings
depending upon what authentication and authorization information is
sent on the wire and what is stored in the exported file system. For
example, if an authentication identity such as a Kerberos principal
is sent with authorization information such as a "privilege attribute
certificate" (PAC) [<a href="#ref-PAC" title=""Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources"">PAC</a>], then mapping is not required (see
<a href="#section-8">Section 8</a>).
1. Auth-to-authz: A mapping between the authentication identity and
the authorization context information.
2. Wire-to-disk: A mapping between the on-the-wire authorization
identity representation and the on-disk authorization identity
representation.
A name service such as LDAP often provides these mappings.
Many aspects of these mappings are entirely implementation specific,
but some require multi-domain-capable name resolution and security
services in order to interoperate in a multi-domain environment.
NFSv4 servers use these mappings for:
1. File access: Both the auth-to-authz and the wire-to-disk mappings
may be required for file access decisions.
2. Metadata setting and listing: The auth-to-authz mapping is
usually required to service file metadata setting or listing
requests such as ACL or UNIX permission setting or listing. This
mapping is needed because NFSv4 messages use identity
representations of the form name@domain, which normally differs
from the server's local representation of identity.
<span class="grey">Adamson & Williams Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. NFSv4 Client Identity Mapping</span>
A client setting the owner or group attribute will often need access
to identity-mapping services. This is because APIs within the client
will specify the identity in a local form (e.g., UNIX using a UID/
GID) so that when stringified id's cannot be used, the ID must be
converted to a unique identity form.
A client obtaining values for the owner or group attributes will
similarly need access to identity-mapping services. This is because
the client API will need these attributes in a local form, as above.
As a result, name services need to be available to convert the unique
identity to a local form.
Note that each of these situations arises because client-side APIs
require a particular local identity representation. The need for
mapping services would not arise if the clients could use the unique
representation of identity directly.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Stand-Alone NFSv4 Domain Deployment Examples</span>
The purpose of this section is to list some typical stand-alone
deployment examples to highlight the need for the required restraints
to the NFSv4 protocol, name service configuration, and security
service choices in an NFSv4 multi-domain environment described in
<a href="#section-6">Section 6</a>.
<a href="#section-7">Section 7</a> notes how these stand-alone deployment examples would need
to change to participate in an NFSv4 multi-domain deployment.
In order to service as many environments as possible, the NFSv4
protocol is designed to allow administrators freedom to configure
their NFSv4 Domains as they please. Stand-alone NFSv4 Domains can be
run in many ways.
These examples are for an NFSv4 server exporting a POSIX UID/GID-
based file system, a typical deployment. These examples are listed
in the order of increasing NFSv4 administrative complexity.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. AUTH_SYS with Stringified UID/GID</span>
This example is the closest NFSv4 gets to being run as NFSv3 as there
is no need for a name service for file metadata listing.
File access: The AUTH_SYS RPC credential [<a href="./rfc5531" title=""RPC: Remote Procedure Call Protocol Specification Version 2"">RFC5531</a>] provides a UID as
the authentication identity, and a list of GIDs as authorization
context information. File access decisions require no name service
interaction as the on-the-wire and on-disk representation are the
<span class="grey">Adamson & Williams Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
same and the auth-to-authz UID and GID authorization context
information is provided in the RPC credential.
Metadata setting and listing: When the NFSv4 clients and servers
implement a stringified UID/GID scheme, where a stringified UID or
GID is used for the NFSv4 name@domain on-the-wire identity, then a
name service is not required for file metadata listing as the UID, or
GID can be constructed from the stringified form on the fly by the
server.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. AUTH_SYS with Name@domain</span>
Another possibility is to express identity using the form
'name@domain', rather than using a stringified UID/GID scheme for
file metadata setting and listing.
File access: This is the same as in <a href="#section-5.1">Section 5.1</a>.
Metadata setting and listing: The NFSv4 server will need to use a
name service for the wire-to-disk mappings to map between the on-the-
wire name@domain syntax and the on-disk UID/GID representation.
Often, the NFSv4 server will use the nsswitch interface for these
mappings. A typical use of the nsswitch name service interface uses
no domain component, just the UID attribute [<a href="./rfc2307" title=""An Approach for Using LDAP as a Network Information Service"">RFC2307</a>] (or login name)
as the name component. This is not an issue in a stand-alone NFSv4
Domain deployment as the NFSv4 Domain is known to the NFSv4 server
and can be combined with the login name to form the name@domain
syntax after the return of the name service call.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. RPCSEC_GSS with Name@domain</span>
RPCSEC_GSS uses Generic Security Service Application Program
Interface (GSS-API) [<a href="./rfc2743" title=""Generic Security Service Application Program Interface Version 2, Update 1"">RFC2743</a>] security mechanisms to securely
authenticate users to servers. The most common mechanism is Kerberos
[<a href="./rfc4121" title=""The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2"">RFC4121</a>].
This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS
security mechanism.
File Access: The forms of GSS principal names are mechanism specific.
For Kerberos, these are of the form principal@REALM. Sometimes
authorization context information is delivered with authentication,
but this cannot be counted on. Authorization context information not
delivered with authentication has timely update considerations (i.e.,
generally it's not possible to get a timely update). File access
decisions therefore require a wire-to-disk mapping of the GSS
principal to a UID and an auth-to-authz mapping to obtain the list of
GIDs as the authorization context.
<span class="grey">Adamson & Williams Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
Metadata setting and listing: This is the same as in <a href="#section-5.2">Section 5.2</a>.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Multi-Domain Constraints to the NFSv4 Protocol</span>
Joining NFSv4 Domains under a single file namespace imposes slightly
on the NFSv4 administrative freedom. In this section, we describe
the required constraints.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Name@domain Constraints</span>
NFSv4 uses a syntax of the form "name@domain" (see <a href="./rfc7530#section-5.9">Section 5.9 of
[RFC7530]</a>) as the on-the-wire representation of the "who" field of an
NFSv4 access control entry (ACE) for users and groups. This design
provides a level of indirection that allows NFSv4 clients and servers
with different internal representations of authorization identity to
interoperate even when referring to authorization identities from
different NFSv4 Domains.
Multi-domain-capable sites need to meet the following requirements in
order to ensure that NFSv4 clients and servers can map between
name@domain and internal representations reliably. While some of
these constraints are basic assumptions in NFSv4.0 [<a href="./rfc7530" title=""Network File System (NFS) Version 4 Protocol"">RFC7530</a>] and
NFSv4.1 [<a href="./rfc5661" title=""Network File System (NFS) Version 4 Minor Version 1 Protocol"">RFC5661</a>], they need to be clearly stated for the multi-
domain case.
o The NFSv4 Domain portion of name@domain MUST be unique within the
multi-domain namespace. See <a href="./rfc5661#section-5.9">[RFC5661], Section 5.9</a> ("Interpreting
owner and owner_group") for a discussion on NFSv4 Domain
configuration.
o The name portion of name@domain MUST be unique within the
specified NFSv4 Domain.
Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used
in a multi-domain deployment. This means that multi-domain-capable
servers MUST reject requests that use stringified UID/GIDs.
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. NFSv4 Domain and DNS Services</span>
Here we address the relationship between NFSv4 Domain name and DNS
domain name in a multi-domain deployment.
The definition of an NFSv4 Domain name, the @domain portion of the
name@domain syntax, needs clarification to work in a multi-domain
file system namespace. <a href="./rfc5661#section-5.9">[RFC5661], Section 5.9</a> loosely defines the
NFSv4 Domain name as a DNS domain name. This loose definition for
the NFSv4 Domain name is a good one, as DNS domain names are globally
unique. As noted in <a href="#section-6.1">Section 6.1</a>, any choice of NFSv4 Domain name can
<span class="grey">Adamson & Williams Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
work within a stand-alone NFSv4 Domain deployment whereas the NFSv4
Domain name is required to be unique across a multi-domain
deployment.
A typical configuration is that there is a single NFSv4 Domain that
is served by a single DNS domain. In this case, the NFSv4 Domain
name can be the same as the DNS domain name.
An NFSv4 Domain can span multiple DNS domains. In this case, one of
the DNS domain names can be chosen as the NFSv4 Domain name.
Multiple NFSv4 Domains can also share a DNS domain. In this case,
only one of the NFSv4 Domains can use the DNS domain name, the other
NFSv4 Domains must choose another unique NFSv4 Domain name.
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. NFSv4 Domain and Name Services</span>
As noted in <a href="#section-6.1">Section 6.1</a>, each name@domain is unique across the multi-
domain namespace and maps, on each NFSv4 server, to the local
representation of identity used by that server. Typically, this
representation consists of an indication of the particular domain
combined with the UID/GID corresponding to the name component. To
support such an arrangement, each NFSv4 Domain needs to have a single
name resolution service capable of converting the names defined
within the domain to the corresponding local representation.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. RPC Security Constraints</span>
As described in <a href="./rfc5661#section-2.2.1.1">[RFC5661], Section 2.2.1.1</a> ("RPC Security Flavors"):
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This
requirement to implement is not a requirement to use.) Other
flavors, such as AUTH_NONE and AUTH_SYS, MAY be implemented as
well.
The underlying RPCSEC_GSS GSS-API [<a href="./rfc2203" title=""RPCSEC_GSS Protocol Specification"">RFC2203</a>] security mechanism used
in a multi-domain namespace is REQUIRED to employ a method of cross
NFSv4 Domain trust so that a principal from a security service in one
NFSv4 Domain can be authenticated in another NFSv4 Domain that uses a
security service with the same security mechanism. Kerberos is an
example of such a security service.
The AUTH_NONE [<a href="./rfc5531" title=""RPC: Remote Procedure Call Protocol Specification Version 2"">RFC5531</a>] security flavor can be useful in a multi-
domain deployment to grant universal read-only access to public data
without any credentials.
<span class="grey">Adamson & Williams Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
The AUTH_SYS security flavor [<a href="./rfc5531" title=""RPC: Remote Procedure Call Protocol Specification Version 2"">RFC5531</a>] uses a host-based
authentication model where the weakly authenticated host (the NFSv4
client) asserts the user's authorization identities using small
integers, uidNumber, and gidNumber [<a href="./rfc2307" title=""An Approach for Using LDAP as a Network Information Service"">RFC2307</a>] as user and group
identity representations. Because this authorization ID
representation has no domain component, AUTH_SYS can only be used in
a namespace where all NFSv4 clients and servers share a name service
as described in [<a href="./rfc2307" title=""An Approach for Using LDAP as a Network Information Service"">RFC2307</a>]. A shared name service is required because
uidNumbers and gidNumbers are passed in the RPC credential; there is
no negotiation of namespace in AUTH_SYS. Collisions can occur if
multiple name services are used, so AUTH_SYS MUST NOT be used in a
multi-domain file system deployment.
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. NFSv4 Domain and Security Services</span>
As noted in <a href="#section-6.2">Section 6.2</a> regarding AUTH_NONE, multiple NFSv4 Domain
security services are RPCSEC_GSS based with the Kerberos 5 security
mechanism being the most commonly (and as of this writing, the only)
deployed service.
A single Kerberos 5 security service per NFSv4 Domain with the upper
case NFSv4 Domain name as the Kerberos 5 REALM name is a common
deployment.
Multiple security services per NFSv4 Domain is allowed and brings the
need of mapping multiple Kerberos 5 principal@REALMs to the same
local ID. Methods of achieving this are beyond the scope of this
document.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Stand-Alone Examples in an NFSv4 Multi-Domain Deployment</span>
In this section, we revisit the stand-alone NFSv4 Domain deployment
examples in <a href="#section-5">Section 5</a> and note what is prohibiting them from
participating in an NFSv4 multi-domain deployment.
Note that because all on-disk identities participating in a stand-
alone NFSv4 Domain belong to the same NFSv4 Domain, stand-alone NFSv4
Domain deployments have no requirement for exporting multi-domain-
capable file systems. To participate in an NFSv4 multi-domain
deployment, all three examples in <a href="#section-5">Section 5</a> would need to export
multi-domain-capable file systems.
Due to the use of AUTH_SYS and stringified UID/GIDs, the first stand-
alone deployment example (described in <a href="#section-5.1">Section 5.1</a>) is not suitable
for participation in an NFSv4 multi-domain deployment.
<span class="grey">Adamson & Williams Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
The second example (described in <a href="#section-5.2">Section 5.2</a>) does use the
name@domain syntax, but the use of AUTH_SYS prohibits its
participation in an NFSv4 multi-domain deployment.
The third example (described in <a href="#section-5.3">Section 5.3</a>) can participate in a
multi-domain namespace deployment if:
o The NFSv4 Domain name is unique across the namespace.
o All exported file systems are multi-domain capable.
o A secure method is used to resolve the remote NFSv4 Domain
principal's authorization information from an authoritative
source.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Resolving Multi-Domain Authorization Information</span>
When an RPCSEC_GSS principal is seeking access to files on an NFSv4
server, after authenticating the principal, the server SHOULD obtain
in a secure manner the principal's authorization context information
from an authoritative source such as the name service in the
principal's NFSv4 Domain.
In the stand-alone NFSv4 Domain case where the principal is seeking
access to files on an NFSv4 server in the principal's home NFSv4
Domain, the server administrator has knowledge of the local policies
and methods for obtaining the principal's authorization information
and the mappings to local representation of identity from an
authoritative source. For example, the administrator can configure
secure access to the local NFSv4 Domain name service.
In the multi-domain case where a principal is seeking access to files
on an NFSv4 server not in the principal's home NFSv4 Domain, the
NFSv4 server may be required to contact the remote name service in
the principal's NFSv4 Domain. In this case, there is no assumption
of:
o Remote name service configuration knowledge.
o The syntax of the remote authorization context information
presented to the NFSv4 server by the remote name service for
mapping to a local representation.
There are several methods the NFSv4 server can use to obtain the
NFSv4 Domain authoritative authorization information for a remote
principal from an authoritative source. While detailing these
methods is beyond the scope of this document, some general methods
are listed here.
<span class="grey">Adamson & Williams Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
1. A mechanism-specific GSS-API authorization payload containing
credential authorization data such as a "privilege attribute
certificate" (PAC) [<a href="#ref-PAC" title=""Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources"">PAC</a>] or a "principal authorization data"
(PAD) [<a href="#ref-GEN-PAC" title=""A Generalized PAC for Kerberos V5"">GEN-PAC</a>]. This is the preferred method as the payload is
delivered as part of GSS-API authentication, avoids requiring any
knowledge of the remote authoritative service configuration, and
has a well-known syntax.
2. When there is a security agreement between the local and remote
NFSv4 Domain name services plus regular update data feeds, the
NFSv4 server local NFSv4 Domain name service can be authoritative
for principals in the remote NFSv4 Domain. In this case, the
NFSv4 server makes a query to its local NFSv4 Domain name service
just as it does when servicing a local domain principal. While
this requires detailed knowledge of the remote NFSv4 Domain name
service for the update data feeds, the authorization context
information presented to the NFSv4 server is in the same form as
a query for a local principal.
3. An authenticated direct query from the NFSv4 server to the
principal's NFSv4 Domain authoritative name service. This
requires the NFSv4 server to have detailed knowledge of the
remote NFSv4 Domain's authoritative name service and detailed
knowledge of the syntax of the resultant authorization context
information.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This RFC discusses security throughout. All the security
considerations of the relevant protocols, such as NFSv4.0 [<a href="./rfc7530" title=""Network File System (NFS) Version 4 Protocol"">RFC7530</a>],
NFSv4.1 [<a href="./rfc5661" title=""Network File System (NFS) Version 4 Minor Version 1 Protocol"">RFC5661</a>], RPCSEC_GSS [<a href="./rfc2203" title=""RPCSEC_GSS Protocol Specification"">RFC2203</a>], GSS-API [<a href="./rfc4121" title=""The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2"">RFC4121</a>], LDAP
[<a href="./rfc4511" title=""Lightweight Directory Access Protocol (LDAP): The Protocol"">RFC4511</a>], Requirements for Federated FS [<a href="./rfc5716" title=""Requirements for Federated File Systems"">RFC5716</a>], FedFS Namespace
Database Protocol [<a href="./rfc7532" title=""Namespace Database (NSDB) Protocol for Federated File Systems"">RFC7532</a>], FedFS Administration Protocol [<a href="./rfc7533" title=""Administration Protocol for Federated File Systems"">RFC7533</a>],
and FedFS Security Addendum [<a href="#ref-SEC-ADD" title=""Federated Filesystem Security Addendum"">SEC-ADD</a>] apply.
Authentication and authorization across administrative domains
present security considerations, most of which are treated elsewhere,
but we repeat some of them here:
o latency in propagation of revocation of authentication credentials
o latency in propagation of revocation of authorizations
o latency in propagation of granting of authorizations
o complications in establishing a complete authorization context for
users of a foreign domain (only parts may be available to servers)
<span class="grey">Adamson & Williams Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
o privacy considerations in a federated environment
Most of these are security considerations of the mechanisms used to
authenticate users to servers and servers to users and of the
mechanisms used to evaluate a user's authorization context.
Implementors may be tempted to assume that "realm" (or "issuer") and
"NFSv4 Domain" are roughly the same thing, but they are not.
Configuration and/or lookup protocols (such as LDAP) and associated
schemas are generally required in order to evaluate a user
principal's authorization context (see <a href="#section-8">Section 8</a>). In the simplest
scheme, a server has access to a database mapping all known principal
names to user names whose authorization context can be evaluated
using operating system interfaces that deal in user names rather than
principal names.
Note that clients may also need to evaluate a server's authorization
context when using labeled security [<a href="./rfc7862" title=""Network File System (NFS) Version 4 Minor Version 2 Protocol"">RFC7862</a>] (e.g., is the server
authorized to handle content at a given security level for the given
client process subject label).
When the server accepts user credentials from more than one realm, it
is important to remember that the server must verify that the client
it is talking to has a credential for the name the client has
presented the server and that the credential's issuer (i.e., its
realm) is allowed to issue it. Usually, the service principal realm
authorization function is implemented by the security mechanism, but
the implementor should check this.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC1034">RFC1034</a>] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, <a href="./rfc1034">RFC 1034</a>, DOI 10.17487/RFC1034, November 1987,
<<a href="http://www.rfc-editor.org/info/rfc1034">http://www.rfc-editor.org/info/rfc1034</a>>.
[<a id="ref-RFC1813">RFC1813</a>] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", <a href="./rfc1813">RFC 1813</a>,
DOI 10.17487/RFC1813, June 1995,
<<a href="http://www.rfc-editor.org/info/rfc1813">http://www.rfc-editor.org/info/rfc1813</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
<span class="grey">Adamson & Williams Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
[<a id="ref-RFC2203">RFC2203</a>] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", <a href="./rfc2203">RFC 2203</a>, DOI 10.17487/RFC2203, September
1997, <<a href="http://www.rfc-editor.org/info/rfc2203">http://www.rfc-editor.org/info/rfc2203</a>>.
[<a id="ref-RFC2743">RFC2743</a>] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", <a href="./rfc2743">RFC 2743</a>,
DOI 10.17487/RFC2743, January 2000,
<<a href="http://www.rfc-editor.org/info/rfc2743">http://www.rfc-editor.org/info/rfc2743</a>>.
[<a id="ref-RFC4121">RFC4121</a>] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", <a href="./rfc4121">RFC 4121</a>,
DOI 10.17487/RFC4121, July 2005,
<<a href="http://www.rfc-editor.org/info/rfc4121">http://www.rfc-editor.org/info/rfc4121</a>>.
[<a id="ref-RFC4511">RFC4511</a>] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", <a href="./rfc4511">RFC 4511</a>,
DOI 10.17487/RFC4511, June 2006,
<<a href="http://www.rfc-editor.org/info/rfc4511">http://www.rfc-editor.org/info/rfc4511</a>>.
[<a id="ref-RFC5661">RFC5661</a>] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", <a href="./rfc5661">RFC 5661</a>, DOI 10.17487/RFC5661, January 2010,
<<a href="http://www.rfc-editor.org/info/rfc5661">http://www.rfc-editor.org/info/rfc5661</a>>.
[<a id="ref-RFC7530">RFC7530</a>] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", <a href="./rfc7530">RFC 7530</a>, DOI 10.17487/RFC7530,
March 2015, <<a href="http://www.rfc-editor.org/info/rfc7530">http://www.rfc-editor.org/info/rfc7530</a>>.
[<a id="ref-RFC7862">RFC7862</a>] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 Protocol", <a href="./rfc7862">RFC 7862</a>, DOI 10.17487/RFC7862,
November 2016, <<a href="http://www.rfc-editor.org/info/rfc7862">http://www.rfc-editor.org/info/rfc7862</a>>.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-CIFS">CIFS</a>] Microsoft Corporation, "[MS-CIFS]: Common Internet File
System (CIFS) Protocol", MS-CIFS v20160714 (Rev 26.0),
July 2016.
[<a id="ref-GEN-PAC">GEN-PAC</a>] Sorce, S., Ed., Yu, T., Ed., and T. Hardjono, Ed., "A
Generalized PAC for Kerberos V5", Work in Progress,
<a href="./draft-ietf-krb-wg-general-pac-01">draft-ietf-krb-wg-general-pac-01</a>, October 2011.
[<a id="ref-PAC">PAC</a>] Brezak, J., "Utilizing the Windows 2000 Authorization Data
in Kerberos Tickets for Access Control to Resources",
February 2002.
<span class="grey">Adamson & Williams Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
[<a id="ref-RFC2307">RFC2307</a>] Howard, L., "An Approach for Using LDAP as a Network
Information Service", <a href="./rfc2307">RFC 2307</a>, DOI 10.17487/RFC2307,
March 1998, <<a href="http://www.rfc-editor.org/info/rfc2307">http://www.rfc-editor.org/info/rfc2307</a>>.
[<a id="ref-RFC2624">RFC2624</a>] Shepler, S., "NFS Version 4 Design Considerations",
<a href="./rfc2624">RFC 2624</a>, DOI 10.17487/RFC2624, June 1999,
<<a href="http://www.rfc-editor.org/info/rfc2624">http://www.rfc-editor.org/info/rfc2624</a>>.
[<a id="ref-RFC4120">RFC4120</a>] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", <a href="./rfc4120">RFC 4120</a>,
DOI 10.17487/RFC4120, July 2005,
<<a href="http://www.rfc-editor.org/info/rfc4120">http://www.rfc-editor.org/info/rfc4120</a>>.
[<a id="ref-RFC5531">RFC5531</a>] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", <a href="./rfc5531">RFC 5531</a>, DOI 10.17487/RFC5531,
May 2009, <<a href="http://www.rfc-editor.org/info/rfc5531">http://www.rfc-editor.org/info/rfc5531</a>>.
[<a id="ref-RFC5716">RFC5716</a>] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", <a href="./rfc5716">RFC 5716</a>,
DOI 10.17487/RFC5716, January 2010,
<<a href="http://www.rfc-editor.org/info/rfc5716">http://www.rfc-editor.org/info/rfc5716</a>>.
[<a id="ref-RFC7532">RFC7532</a>] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace
Database (NSDB) Protocol for Federated File Systems",
<a href="./rfc7532">RFC 7532</a>, DOI 10.17487/RFC7532, March 2015,
<<a href="http://www.rfc-editor.org/info/rfc7532">http://www.rfc-editor.org/info/rfc7532</a>>.
[<a id="ref-RFC7533">RFC7533</a>] Lentini, J., Tewari, R., and C. Lever, Ed.,
"Administration Protocol for Federated File Systems",
<a href="./rfc7533">RFC 7533</a>, DOI 10.17487/RFC7533, March 2015,
<<a href="http://www.rfc-editor.org/info/rfc7533">http://www.rfc-editor.org/info/rfc7533</a>>.
[<a id="ref-SEC-ADD">SEC-ADD</a>] Lever, C., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Federated+Filesystem+Security+Addendum%22'>"Federated Filesystem Security Addendum"</a>, Work
in Progress, <a href="./draft-cel-nfsv4-federated-fs-security-addendum-06">draft-cel-nfsv4-federated-fs-security-</a>
<a href="./draft-cel-nfsv4-federated-fs-security-addendum-06">addendum-06</a>, October 2016.
<span class="grey">Adamson & Williams Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8000">RFC 8000</a> Multi NFSv4 Domain November 2016</span>
Acknowledgments
Andy Adamson would like to thank NetApp, Inc., for its funding of his
time on this project.
We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and
David Noveck for their review.
Authors' Addresses
William A. (Andy) Adamson
NetApp
Email: andros@netapp.com
Nicolas Williams
Cryptonector
Email: nico@cryptonector.com
Adamson & Williams Standards Track [Page 17]
</pre>
|
