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
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
|
<pre>Network Working Group M. Eisler
Request for Comments: 2623 Sun Microsystems, Inc.
Category: Standards Track June 1999
<span class="h1">NFS Version 2 and Version 3 Security Issues and the NFS Protocol's</span>
<span class="h1">Use of RPCSEC_GSS and Kerberos V5</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This memorandum clarifies various security issues involving the NFS
protocol (Version 2 and Version 3 only) and then describes how the
Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS
security flavor protocol and Kerberos V5. This memorandum is
provided so that people can write compatible implementations.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Overview of RPC Security Architecture . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Overview of NFS Security . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Port Monitoring . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1.1">2.1.1</a>. MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. RPC Security Flavors . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2.1">2.2.1</a>. AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2.2">2.2.2</a>. AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2.3">2.2.3</a>. RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Authentication for NFS Procedures . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.3.1">2.3.1</a>. NULL Procedure . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.3.2">2.3.2</a>. NFS Procedures Used at Mount Time . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.4">2.4</a>. Binding Security Flavors to Exports . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.5">2.5</a>. Anonymous Mapping . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.6">2.6</a>. Host-based Access Control . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-2.7">2.7</a>. Security Flavor Negotiation . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-2.8">2.8</a>. Registering Flavors . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3">3</a>. The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="grey">Eisler Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<a href="#section-3.1">3.1</a>. Server Principal . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.2">3.2</a>. Negotiation . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.3">3.3</a>. Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.4">3.4</a>. Registering Pseudo Flavors and Mappings . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4">4</a>. The NFS Protocol over Kerberos V5 . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.1">4.1</a>. Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . . <a href="#page-12">12</a>
4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor
Registration Entry . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6">6</a>. IANA Considerations [<a href="./rfc2434" title="">RFC2434</a>] . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.1">6.1</a>. Pseudo Flavor Number . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.2">6.2</a>. String Name of Pseudo Flavor . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.2.1">6.2.1</a>. Name Space Size . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.2.2">6.2.2</a>. Delegation . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.2.3">6.2.3</a>. Outside Review . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.3">6.3</a>. GSS-API Mechanism OID . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.4">6.4</a>. GSS-API Mechanism Algorithm Values . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.5">6.5</a>. RPCSEC_GSS Security Service . . . . . . . . . . . . . . . <a href="#page-16">16</a>
References . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The NFS protocol provides transparent remote access to shared file
systems across networks. The NFS protocol is designed to be machine,
operating system, network architecture, and security mechanism, and
transport protocol independent. This independence is achieved through
the use of ONC Remote Procedure Call (RPC) primitives built on top of
an eXternal Data Representation (XDR). NFS protocol Version 2 is
specified in the Network File System Protocol Specification
[<a href="./rfc1094" title=""NFS: Network File System Protocol Specification"">RFC1094</a>]. A description of the initial implementation can be found
in [<a href="#ref-Sandberg">Sandberg</a>]. NFS protocol Version 3 is specified in the NFS Version
3 Protocol Specification [<a href="./rfc1813" title=""NFS Version 3 Protocol Specification"">RFC1813</a>]. A description of some initial
implementations can be found in [<a href="#ref-Pawlowski">Pawlowski</a>].
For the remainder of this document, whenever it refers to the NFS
protocol, it means NFS Version 2 and Version 3, unless otherwise
stated.
The RPC protocol is specified in the Remote Procedure Call Protocol
Specification Version 2 [<a href="./rfc1831" title=""RPC: Remote Procedure Call Protocol Specification Version 2"">RFC1831</a>]. The XDR protocol is specified in
External Data Representation Standard [<a href="./rfc1832" title=""XDR: External Data Representation Standard"">RFC1832</a>].
A new RPC security flavor, RPCSEC_GSS, has been specified [<a href="./rfc2203" title=""RPCSEC_GSS Protocol Specification"">RFC2203</a>].
This new flavor allows application protocols built on top of RPC to
access security mechanisms that adhere to the GSS-API specification
<span class="grey">Eisler Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
[<a href="./rfc2078" title=""Generic Security Service Application Program Interface, Version 2"">RFC2078</a>].
The purpose of this document is to clarify NFS security issues and to
specify how the NFS protocol uses RPCSEC_GSS. This document will also
describe how NFS works over Kerberos V5, via RPCSEC_GSS.
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="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Overview of RPC Security Architecture</span>
The RPC protocol includes a slot for security parameters (referred to
as an authentication flavor in the RPC specification [<a href="./rfc1831" title=""RPC: Remote Procedure Call Protocol Specification Version 2"">RFC1831</a>]) on
every call. The contents of the security parameters are determined
by the type of authentication used by the server and client. A server
may support several different flavors of authentication at once.
Some of the better known flavors are summarized as follows:
* The AUTH_NONE flavor provides null authentication, that is, no
authentication information is passed.
* The AUTH_SYS flavor provides a UNIX-style user identifier, group
identifier, and an array of supplemental group identifiers with
each call.
* The AUTH_DH (sometimes referred to as AUTH_DES [<a href="./rfc1057" title=""RPC: Remote Procedure Call Protocol Specification Version 2"">RFC1057</a>]) flavor
provides DES-encrypted authentication parameters based on a
network-wide string name, with session keys exchanged via the
Diffie-Hellman public key scheme.
* The AUTH_KERB4 flavor provides DES encrypted authentication
parameters based on a network-wide string name (the name is a
Kerberos Version 4 principal identifier) with session keys
exchanged via Kerberos Version 4 secret keys.
The NFS protocol is not limited to the above list of security
flavors.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview of NFS Security</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Port Monitoring</span>
Many NFS servers will require that the client send its NFS requests
from UDP or TCP source ports with values < 1024. The theory is that
binding to ports < 1024 is a privileged operation on the client, and
so the client is enforcing file access permissions on its end. The
theory breaks down because:
<span class="grey">Eisler Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
* On many operating systems, there are no constraints on what port
what user can bind to.
* Just because the client host enforces the privilege on binding
to ports < 1024 does not necessarily mean that a non-privileged
user cannot gain access to the port binding privilege. For
example with a single-user desk-top host running a UNIX
operating system, the user may have knowledge of the root user
password. And even if he does not have that knowledge, with
physical access to the desk-top machine, root privileges are
trivially acquired.
In some rare cases, when the system administrator can be certain that
the clients are trusted and under control (in particular, protected
from physical attack), relying of trusted ports MAY be a reliable
form of security.
In most cases, the use of privileged ports and port monitoring for
security is at best an inconvenience to the attacker and SHOULD NOT
be depended on.
To maximize interoperability:
* NFS clients SHOULD attempt to bind to ports < 1024. In some
cases, if they fail to bind (because either the user does not
have the privilege to do so, or there is no free port < 1024),
the NFS client MAY wish to attempt the NFS operation over a port
>= 1024.
* NFS servers that implement port monitoring SHOULD provide a
method to turn it off.
* Whether port monitoring is enabled or not, NFS servers SHOULD
NOT reject NFS requests to the NULL procedure (procedure number
0). See sub<a href="#section-2.3.1">section 2.3.1</a>, "NULL procedure" for a complete
explanation.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. MOUNT Protocol</span>
The port monitoring issues and recommendations apply to the MOUNT
protocol as well.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. RPC Security Flavors</span>
The NFS server checks permissions by taking the credentials from the
RPC security information in each remote request. Each flavor packages
credentials differently.
<span class="grey">Eisler Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. AUTH_SYS</span>
Using the AUTH_SYS flavor of authentication, the server gets the
client's effective user identifier, effective group identifier and
supplemental group identifiers on each call, and uses them to check
access. Using user identifiers and group identifiers implies that the
client and server either share the same identifier name space or do
local user and group identifier mapping.
For those sites that do not implement a consistent user identifier
and group identifier space, NFS implementations must agree on the
mapping of user and group identifiers between NFS clients and
servers.
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. AUTH_DH and AUTH_KERB4</span>
The AUTH_DH and AUTH_KERB4 styles of security are based on a
network-wide name. They provide greater security through the use of
DES encryption and public keys in the case of AUTH_DH, and DES
encryption and Kerberos secret keys (and tickets) in the AUTH_KERB4
case. Again, the server and client must agree on the identity of a
particular name on the network, but the name to identity mapping is
more operating system independent than the user identifier and group
identifier mapping in AUTH_SYS. Also, because the authentication
parameters are encrypted, a malicious user must know another user's
network password or private key to masquerade as that user.
Similarly, the server returns a verifier that is also encrypted so
that masquerading as a server requires knowing a network password.
<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a>. RPCSEC_GSS</span>
The RPCSEC_GSS style of security is based on a security-mechanism-
specific principal name. GSS-API mechanisms provide security through
the use of cryptography. The cryptographic protections are used in
the construction of the credential on calls, and in the verifiers on
replies. Optionally, cryptographic protections will be in the body of
the calls and replies.
Note that the discussion of AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4,
and RPCSEC_GSS does not imply that the NFS protocol is limited to
using those five flavors.
<span class="grey">Eisler Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Authentication for NFS Procedures</span>
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. NULL Procedure</span>
The NULL procedure is typically used by NFS clients to determine if
an NFS server is operating and responding to requests (in other
words, to "ping" the NFS server). Some NFS servers require that a
client using the NULL procedure:
* send the request from TCP or UDP port < 1024. There does not
seem to be any value in this because the NULL procedure is of
very low overhead and certainly no more overhead than the cost
of processing a NULL procedure and returning an authentication
error. Moreover, by sending back an authentication error, the
server has confirmed the information that the client was
interested in: is the server operating?
* be authenticated with a flavor stronger than AUTH_SYS. This is a
problem because the RPCSEC_GSS protocol uses NULL for control
messages.
NFS servers SHOULD:
* accept the NULL procedure ping over AUTH_NONE and AUTH_SYS, in
addition to other RPC security flavors, and
* NOT require that the source port be < 1024 on a NULL procedure
ping.
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. NFS Procedures Used at Mount Time</span>
Certain NFS procedures are used at the time the NFS client mounts a
file system from the server. Some NFS server implementations will
not require authentication for these NFS procedures. For NFS
protocol Version 2, these procedures are GETATTR and STATFS. For
Version 3, the procedure is FSINFO.
The reason for not requiring authentication is described as follows.
When the NFS client mounts a NFS server's file system, the identity
of the caller on the client is typically an administrative entity (in
UNIX operating systems, this is usually the "root" user). It is
often the case that, for unattended operation in concert with an
automounter [<a href="#ref-Callaghan">Callaghan</a>], the AUTH_DH, AUTH_KERB4, or RPCSEC_GSS
credentials for the administrative entity associated with an
automounter are not available. If so, the NFS client will use
AUTH_NONE or AUTH_SYS for the initial NFS operations used to mount a
file system. While an attacker could exploit this implementation
artifact, the exposure is limited to gaining the attributes of a file
<span class="grey">Eisler Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
or a file system's characteristics. This OPTIONAL trade off favors
the opportunity for improved ease of use.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Binding Security Flavors to Exports</span>
NFS servers MAY export file systems with specific security flavors
bound to the export. In the event a client uses a security flavor
that is not the one of the flavors the file system was exported with,
NFS server implementations MAY:
* reject the request with an error (either an NFS error or an RPC
level authentication error), or
* allow the request, but map the user's credentials to a user
other than the one the client intended. Typically the user that
is the result of this mapping is a user with limited access on
the system, such as user "nobody" on UNIX systems.
If a client uses AUTH_NONE, the server's options are the same as the
above, except that AUTH_NONE carries with it no user identity. In
order to allow the request, on many operating systems the server will
assign a user identity. Typically this assignment will be a user with
limited access on the system, such as user "nobody" on UNIX systems.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Anonymous Mapping</span>
The following passage is excerpted verbatim from <a href="./rfc1813#section-4.4">RFC 1813, section </a>
<a href="#section-4.4">4.4</a> "Permission Issues" (except that "may" has been changed to
"MAY"):
In most operating systems, a particular user (on UNIX, the uid 0)
has access to all files, no matter what permission and ownership
they have. This superuser permission MAY not be allowed on the
server, since anyone who can become superuser on their client
could gain access to all remote files. A UNIX server by default
maps uid 0 to a distinguished value (UID_NOBODY), as well as
mapping the groups list, before doing its access checking. A
server implementation MAY provide a mechanism to change this
mapping. This works except for NFS version 3 protocol root file
systems (required for diskless NFS version 3 protocol client
support), where superuser access cannot be avoided. Export
options are used, on the server, to restrict the set of clients
allowed superuser access.
The issues identified as applying to NFS protocol Version 3 in the
above passage also apply to Version 2.
<span class="grey">Eisler Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Host-based Access Control</span>
In some NFS server implementations, a host-based access control
method is used whereby file systems can be exported to lists of
clients. File systems may also be exported for read-only or read-
write access. Several of these implementations will check access
only at mount time, during the request for the file handle via the
MOUNT protocol handshake. The lack of authorization checking during
subsequent NFS requests has the following consequences:
* NFS servers are not able to repudiate access to the file system
by an NFS client after the client has mounted the file system.
* An attacker can circumvent the MOUNT server's access control to
gain access to a file system that the attacker is not authorized
for. The circumvention is accomplished by either stealing a file
handle (usually by snooping the network traffic between an
legitimate client and server) or guessing a file handle. For
this attack to succeed, the attacker must still be able
impersonate a user's credentials, which is simple for AUTH_SYS,
but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS.
* WebNFS clients that use the public file handle lookup [<a href="./rfc2054" title=""WebNFS Client Specification"">RFC2054</a>]
will not go through the MOUNT protocol to acquire initial file
handle of the NFS file system. Enforcing access control via the
MOUNT protocol is going to be a little use. Granted, some WebNFS
server implementations cope with this by limiting the use of the
public file handle to file systems exported to every client on
the Internet.
Thus, NFS server implementations SHOULD check the client's
authorization on each NFS request.
<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>. Security Flavor Negotiation</span>
Any application protocol that supports multiple styles of security
will have the issue of negotiating the security method to be used.
NFS Version 2 had no support for security flavor negotiation. It was
up to the client to guess, or depend on prior knowledge. Often the
prior knowledge would be available in the form of security options
specified in a directory service used for the purpose of
automounting.
The MOUNT Version 3 protocol, associated with NFS Version 3, solves
the problem by having the response to the MNT procedure include a
list of flavors in the MNT procedure. Note that because some NFS
servers will export file systems to specific lists of clients, with
different access (read-only versus read-write), and with different
<span class="grey">Eisler Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
security flavors, it is possible a client might get back multiple
security flavors in the list returned in the MNT response. The use of
one flavor instead of another might imply read-only instead of read-
write access, or perhaps some other degradation of access. For this
reason, a NFS client SHOULD use the first flavor in the list that it
supports, on the assumption that the best access is provided by the
first flavor. NFS servers that support the ability to export file
systems with multiple security flavors SHOULD either present the best
accessing flavor first to the client, or leave the order under the
control of the system administrator.
<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>. Registering Flavors</span>
When one develops a new RPC security flavor, iana@iana.org MUST be
contacted to get a unique flavor assignment. To simplify NFS client
and server administration, having a simple ASCII string name for the
flavor is useful. Currently, the following assignments exist:
flavor string name
AUTH_NONE none
AUTH_SYS sys
AUTH_DH dh
AUTH_KERB4 krb4
A string name for a new flavor SHOULD be assigned. String name
assignments can be registered by contacting iana@iana.org.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The NFS Protocol's Use of RPCSEC_GSS</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Server Principal</span>
When using RPCSEC_GSS, the NFS server MUST identify itself in GSS-API
via a GSS_C_NT_HOSTBASED_SERVICE name type.
GSS_C_NT_HOSTBASED_SERVICE names are of the form:
service@hostname
For NFS, the "service" element is
nfs
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Negotiation</span>
RPCSEC_GSS is a single security flavor over which different security
mechanisms can be multiplexed. Within a mechanism, GSS-API provides
for the support of multiple quality of protections (QOPs), which are
pairs of cryptographic algorithms. Each algorithm in the QOP consists
<span class="grey">Eisler Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
of an encryption algorithm for privacy and a checksum algorithm for
integrity. RPCSEC_GSS lets one protect the RPC request/response pair
with plain header authentication, message integrity, and message
privacy. Thus RPCSEC_GSS effectively supports M * Q * 3 different
styles of security, where M is the number of mechanisms supported, Q
is the average number of QOPs supported for each mechanism, and 3
enumerates authentication, integrity, and privacy.
Because RPCSEC_GSS encodes many styles of security, just adding
RPCSEC_GSS to the list of flavors returned in MOUNT Version 3's MNT
response is not going to be of much use to the NFS client.
The solution is the creation of a concept called "pseudo flavors."
Pseudo flavors are 32 bit integers that are allocated out of the same
number space as regular RPC security flavors like AUTH_NONE,
AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. The idea is that each
pseudo flavor will map to a specific triple of security mechanism,
quality of protection, and service. The service will be one of
authentication, integrity, and privacy. Note that integrity includes
authentication, and privacy includes integrity. RPCSEC_GSS uses
constants named rpc_gss_svc_none, rpc_gss_svc_integrity, and
rpc_gss_svc_privacy, for authentication, integrity, and privacy
respectively.
Thus, instead of returning RPCSEC_GSS, a MOUNT Version 3 server will
instead return one or more pseudo flavors if the NFS server supports
RPCSEC_GSS and if the file system has been exported with one or more
<mechanism, QOP, service> triples. See <a href="#section-4">section 4</a>, "The NFS Protocol
over Kerberos V5" for an example of pseudo flavor to triple mapping.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Changing RPCSEC_GSS Parameters</span>
Once an RPCSEC_GSS session or context has been set up (via the
RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT control procedures of
RPCSEC_GSS), the NFS server MAY lock the <mechanism, QOP, service>
triple for the duration of the session. While RPCSEC_GSS allows for
the use of different QOPs and services on each message, it would be
expensive for the NFS server to re-consult its table of exported file
systems to see if the triple was allowed. Moreover, by the time the
NFS server's dispatch routine was reached, the typical RPC subsystem
would already have performed the appropriate GSS-API operation,
GSS_VerifyMIC() or GSS_Unwrap(), if the respective integrity or
privacy services were selected. If the file system being accessed
were not exported with integrity or privacy, or with the particular
QOP used to perform the integrity or privacy service, then it would
be possible to execute a denial of service attack, whereby the
objective of the caller is to deny CPU service to legitimate users of
the NFS server's machine processors.
<span class="grey">Eisler Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
Thus, in general, clients SHOULD NOT assume that they will be
permitted to alter the <mechanism, QOP, service> triple once the data
exchange phase of RPCSEC_GSS has started.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Registering Pseudo Flavors and Mappings</span>
Pseudo flavor numbers MUST be registered via same method as regular
RPC security flavor numbers via iana@iana.org.
Once the pseudo flavor number has been assigned, registrants SHOULD
register the mapping with iana@iana.org. The mapping registration
MUST contain:
* the pseudo flavor number, an ASCII string name for the flavor
(for example "none" has been assigned for AUTH_NONE), and
* the <mechanism, algorithm(s), service> triple. As per the GSS-
API specification, the mechanism MUST be identified with a
unique ISO object identifier (OID). The reason why the second
component of the triple is not necessarily a QOP value is that
GSS-API allows mechanisms much latitude in the mapping of the
algorithm used in the default quality of protection (See
sub<a href="#section-4.1">section 4.1</a>, "Issues with Kerberos V5 QOPs," for a detailed
discussion). With some mechanisms, the second component of the
triple will be a QOP. Internally, on the NFS implementation, it
is expected that the triple would use a QOP for the second
component.
The mapping registration SHOULD also contain:
* A reference to an RFC describing how the NFS protocol works
over the pseudo flavor(s), including the pseudo flavor
number(s), string name(s) for the flavor(s), and any other
issues, including how the registrant is interpreting the GSS-API
mechanism.
* A reference to the GSS-API mechanism used.
An example of a complete registration is provided in sub<a href="#section-4.2">section 4.2</a>,
"The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry."
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The NFS Protocol over Kerberos V5</span>
The NFS protocol uses Kerberos V5 security using the RPCSEC_GSS
security flavor. The GSS-API security mechanism for Kerberos V5 that
the NFS/RPCSEC_GSS protocol stack uses is described in the Kerberos
V5 GSS-API description [<a href="./rfc1964" title=""The Kerberos Version 5 GSS-API Mechanism"">RFC1964</a>].
<span class="grey">Eisler Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Issues with Kerberos V5 QOPs</span>
The Kerberos V5 GSS-API description defines three algorithms for
integrity:
* DES MAC MD5
* MD2.5
* DES-MAC
<a href="./rfc1964">RFC 1964</a> states that MD2.5 "may be significantly weaker than DES MAC
MD5." <a href="./rfc1964">RFC 1964</a> also states that DES-MAC "may not be present in all
implementations."
Thus the description of operation of NFS clients and servers over
Kerberos V5 is limited to the DES MAC MD5 integrity algorithm.
NFS clients and servers operating over Kerberos V5 MUST support the
DES MAC MD5 integrity algorithm. <a href="./rfc1964">RFC 1964</a> lists a single algorithm
for privacy: 56 bit DES. NFS clients and servers SHOULD support the
56 bit DES privacy algorithm.
GSS-API has the concept of a default QOP of zero which means
different integrity and privacy algorithms to different GSS-API
mechanisms. In Kerberos V5, the default QOP of zero means to use the
56 bit DES algorithm (when doing a GSS_Wrap() operation with the
conf_req_flag set to 1).
For Kerberos V5, the default QOP of zero means different integrity
algorithms to different implementations of Kerberos V5. Furthermore,
during the processing of a token in GSS_Unwrap(), and
GSS_VerifyMIC(), at least one reference implementation of the
Kerberos V5 GSS-API mechanism [<a href="#ref-MIT" title=""Kerberos: The Network Authentication Protocol."">MIT</a>], always returns a QOP of zero,
regardless of integrity algorithm encoded in the token. For such
implementations, it means that the caller of GSS_Unwrap() and
GSS_VerifyMIC() cannot know the actual integrity algorithm used.
Given that each integrity algorithm has a different degree of
security, this situation may not be acceptable to the user of GSS-
API. An implementation of Kerberos V5 under GSS-API for use under NFS
MUST NOT do this.
For the purposes of NFS, as a simplification, some Kerberos V5 GSS-
API mechanisms MAY map QOP 0 to always mean DES MAC MD5 integrity,
and when using GSS_VerifyMIC() and GSS_Unwrap(), always map the DES
MAC MD5 integrity that is specified to QOP 0.
<span class="grey">Eisler Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry</span>
Here are the pseudo flavor mappings for the NFS protocol using
Kerberos V5 security:
columns:
1 == number of pseudo flavor
2 == name of pseudo flavor
3 == mechanism's OID
4 == mechanism's algorithm(s)
5 == RPCSEC_GSS service
1 2 3 4 5
-----------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy
for integrity,
and 56 bit DES
for privacy.
An implementation of NFS over RPCSEC_GSS/GSS-API/Kerberos V5 that
maps the default QOP to DES MAC MD5 (and vice versa), would implement
a mapping of:
columns:
1 == number of pseudo flavor
2 == name of pseudo flavor
3 == mechanism's OID
4 == QOP
5 == RPCSEC_GSS service
1 2 3 4 5
-----------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy
The reference for the GSS-API mechanism with the above OID is
[<a href="./rfc1964" title=""The Kerberos Version 5 GSS-API Mechanism"">RFC1964</a>].
The reference for how the NFS protocol MUST work over Kerberos V5 is
this document.
<span class="grey">Eisler Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Version 3 of the MOUNT protocol is used to negotiate the security
flavor to be used by the NFS Version 3 client. If the NFS client uses
a weak security flavor like AUTH_SYS to query a Version 3 MOUNT
server, then the following attacks are possible by an attacker in the
middle:
* The attacker in the middle can coax the NFS client into using a
weaker form of security than what the real NFS server requires.
However, once the NFS client selects a security flavor when it
sends a request to real NFS server, if the flavor is
unacceptable, the NFS client's NFS request will be rejected. So
at worst, a denial of service attack is possible. In theory, the
NFS client could contact the MOUNT server using a stronger
security flavor, but this would require that the client know in
advance what security flavors the MOUNT server supports.
* If the client and server support a common set of security
flavors, such that the client considers one preferable to the
other (for example, one might have privacy and other not),
unless the client uses a strong security flavor in the MOUNT
protocol query, an attacker in the middle could cause the client
to use the weaker form of security. Again, a client could
contact the MOUNT server using a stronger form of security.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations [<a href="./rfc2434" title="">RFC2434</a>]</span>
This memorandum describes how NFS Version 2 and Version 3 work over
RPC's RPCSEC_GSS security flavor. This memorandum requires that
triples of { GSS-API mechanism OID, GSS-API mechanism algorithm,
RPCSEC_GSS security service } be mapped to a unique RPC security
flavor number, which is a pseudo flavor that does not appear in an
RPC protocol header. This memorandum also encourages that an ASCII
string name be registered with the triple.
Thus there are five different kinds of objects to consider guidelines
for.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Pseudo Flavor Number</span>
The considerations of assignment, allocation, and delegation of
pseudo flavor numbers are no different than that the considerations
for RPC security flavors, as both are assigned from the same number
space. IANA is already responsible for the assigned of RPC security
flavors, and because this memorandum does not specify the RPC
protocol [<a href="./rfc1831" title=""RPC: Remote Procedure Call Protocol Specification Version 2"">RFC1831</a>], it is beyond the scope of this memorandum to
guide IANA in the assignment of flavor numbers.
<span class="grey">Eisler Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. String Name of Pseudo Flavor</span>
This memorandum introduces the concept of a string name to be
associated with the RPC pseudo flavor number, and so it is within the
scope of this memorandum to provide guidance to IANA.
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Name Space Size</span>
There are no limits placed on the length of the unique string name by
this memorandum, so the size of the name space is infinite. However,
IANA may want to prevent the hoarding or reservation of names. The
simplest way to do this is by requiring the registrant to provide the
GSS-API mechanism OID, GSS-API quality of protection, the RPCSEC_GSS
security service, and flavor number, with the request for a flavor
name. If the registrant does not have a flavor number, then
guidelines for flavor number assignments will indirectly limit the
assignment of flavor names.
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. Delegation</span>
The simplest way to handle delegation is to delegate portions of the
RPC security flavor number space with the RPC flavor name space. The
guidelines for delegation of the flavor name space are thus
equivalent to guidelines for delegations of the flavor number space.
<span class="h4"><a class="selflink" id="section-6.2.3" href="#section-6.2.3">6.2.3</a>. Outside Review</span>
Because string names can be trademarks, IANA may want to seek legal
counsel to review a proposed pseudo flavor name. Other than that, no
outside review is necessary.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. GSS-API Mechanism OID</span>
This memorandum assumes that the mechanism OID associated with the
pseudo flavor has already been allocated. OIDs are allocated by the
International Standards Organization and the International
Telecommunication Union. Both organizations have delegated assignment
authority for subsets of the OID number space to other organizations.
Presumably, IANA has received authority to assign OIDs to GSS-API
mechanisms. Because this memorandum does not specify the GSS-API
protocol (see [<a href="./rfc2078" title=""Generic Security Service Application Program Interface, Version 2"">RFC2078</a>]) it is beyond the scope of this memorandum to
guide IANA in the assignment of GSS-API mechanism OIDs.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. GSS-API Mechanism Algorithm Values</span>
This memorandum assumes that the algorithm value for a given GSS-API
mechanism has already been allocated. Algorithm values are controlled
by the owner of the GSS-API mechanism, though the owner may delegate
<span class="grey">Eisler Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
assignment of algorithm values to a body such as IANA. Because this
memorandum does not specify GSS-API mechanisms, such as [<a href="./rfc1964" title=""The Kerberos Version 5 GSS-API Mechanism"">RFC1964</a>], it
is beyond the scope of this memorandum to guide IANA in the
assignment of a mechanism's algorithm value(s).
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. RPCSEC_GSS Security Service</span>
There are only three security services and they are enumerated and
described in [<a href="./rfc2203" title=""RPCSEC_GSS Protocol Specification"">RFC2203</a>]. No guideline to IANA is necessary.
References
[<a id="ref-RFC1094">RFC1094</a>] Sun Microsystems, Inc., "NFS: Network File System
Protocol Specification", <a href="./rfc1094">RFC 1094</a>, March 1989.
<a href="http://www.ietf.org/rfc/rfc1094.txt">http://www.ietf.org/rfc/rfc1094.txt</a>
[<a id="ref-Sandberg">Sandberg</a>]
Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon,
B. (1985). "Design and Implementation of the Sun Network
Filesystem," Proceedings of the 1985 Summer USENIX
Technical Conference.
[<a id="ref-RFC1813">RFC1813</a>] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS
Version 3 Protocol Specification", <a href="./rfc1813">RFC 1813</a>, June 1995.
<a href="http://www.ietf.org/rfc/rfc1813.txt">http://www.ietf.org/rfc/rfc1813.txt</a>
[<a id="ref-RFC1831">RFC1831</a>] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", <a href="./rfc1831">RFC 1831</a>, August 1995.
<a href="http://www.ietf.org/rfc/rfc1831.txt">http://www.ietf.org/rfc/rfc1831.txt</a>
[<a id="ref-RFC1832">RFC1832</a>] Srinivasan, R., "XDR: External Data Representation
Standard", <a href="./rfc1832">RFC 1832</a>, August 1995.
<a href="http://www.ietf.org/rfc/rfc1832.txt">http://www.ietf.org/rfc/rfc1832.txt</a>
[<a id="ref-Pawlowski">Pawlowski</a>]
Pawlowski, B., Juszczak, C., Staubach, P., Smith, C.,
Lebel, D. and D. Hitz, "NFS Version 3 Design and
Implementation", Proceedings of the USENIX Summer 1994
Technical Conference.
[<a id="ref-RFC2203">RFC2203</a>] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification", <a href="./rfc2203">RFC 2203</a>, September 1997.
<a href="http://www.ietf.org/rfc/rfc2203.txt">http://www.ietf.org/rfc/rfc2203.txt</a>
[<a id="ref-RFC2078">RFC2078</a>] Linn, J., "Generic Security Service Application
Program Interface, Version 2", <a href="./rfc2078">RFC 2078</a>, January 1997.
<a href="http://www.ietf.org/rfc/rfc2078.txt">http://www.ietf.org/rfc/rfc2078.txt</a>
<span class="grey">Eisler Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
[<a id="ref-RFC1057">RFC1057</a>] Sun Microsystems, Inc., "RPC: Remote Procedure Call
Protocol Specification Version 2", <a href="./rfc1057">RFC 1057</a>, June 1988.
This RFC is being referenced for its description of the
AUTH_DH (AUTH_DES) RPC security flavor.
<a href="http://www.ietf.org/rfc/rfc1057.txt">http://www.ietf.org/rfc/rfc1057.txt</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>, March 1997.
<a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
[<a id="ref-Callaghan">Callaghan</a>]
Callaghan, B., Singh, S. (1993). "The Autofs Automounter,"
Proceedings of the 1993 Summer USENIX Technical Conference.
[<a id="ref-RFC1964">RFC1964</a>] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism", <a href="./rfc1964">RFC 1964</a>, June 1996.
<a href="http://www.ietf.org/rfc/rfc1964.txt">http://www.ietf.org/rfc/rfc1964.txt</a>
[<a id="ref-RFC2054">RFC2054</a>] Callaghan, B., "WebNFS Client Specification", <a href="./rfc2054">RFC</a>
<a href="./rfc2054">2054</a>, October 1996.
<a href="http://www.ietf.org/rfc/rfc2054.txt">http://www.ietf.org/rfc/rfc2054.txt</a>
[<a id="ref-RFC2434">RFC2434</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC</a>
<a href="./rfc2434">2434</a>, October 1998.
<a href="http://www.ietf.org/rfc/rfc2434.txt">http://www.ietf.org/rfc/rfc2434.txt</a>
[<a id="ref-MIT">MIT</a>] Massachusetts Institute of Technology (1998). "Kerberos:
The Network Authentication Protocol." The Web site for
downloading MIT's implementation of Kerberos V5, including
implementations of <a href="./rfc1510">RFC 1510</a> and <a href="./rfc1964">RFC 1964</a>.
<a href="http://web.mit.edu/kerberos/www/index.html">http://web.mit.edu/kerberos/www/index.html</a>
Acknowledgments
The author thanks:
* Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve
Nahm, Joyce Reynolds, and David Robinson for their review
comments.
* John Linn, for his explanation of QOP handling in <a href="./rfc1964">RFC 1964</a>.
<span class="grey">Eisler Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
Author's Address
Address comments related to this memorandum to:
nfsv4-wg@sunroof.eng.sun.com
Mike Eisler
Sun Microsystems, Inc.
5565 Wilson Road
Colorado Springs, CO 80919
Phone: 1-719-599-9026
EMail: mre@eng.sun.com
<span class="grey">Eisler Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc2623">RFC 2623</a> NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999</span>
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of eveloping
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eisler Standards Track [Page 19]
</pre>
|
