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
|
<pre>Network Working Group A. Chiu
Request for Comments: 2755 M. Eisler
Category: Informational B. Callaghan
Sun Microsystems
January 2000
<span class="h1">Security Negotiation for WebNFS</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes a protocol for a WebNFS client [<a href="./rfc2054" title=""WebNFS Client Specification"">RFC2054</a>] to
negotiate the desired security mechanism with a WebNFS server
[<a href="./rfc2055" title=""WebNFS Server Specification"">RFC2055</a>] before the WebNFS client falls back to the MOUNT v3
protocol [<a href="./rfc1813" title=""NFS Version 3 Protocol Specification"">RFC1813</a>]. This document 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-2">2</a>. Security Negotiation Multi-component LOOKUP ............... <a href="#page-3">3</a>
<a href="#section-3">3</a> Overloaded Filehandle ..................................... <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a> Overloaded NFS Version 2 Filehandle ..................... <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a> Overloaded NFS Version 3 Filehandle ..................... <a href="#page-6">6</a>
<a href="#section-4">4</a>. WebNFS Security Negotiation ............................... <a href="#page-6">6</a>
<a href="#section-5">5</a>. Security Considerations ................................... <a href="#page-10">10</a>
<a href="#section-6">6</a>. References ................................................ <a href="#page-10">10</a>
<a href="#section-7">7</a>. Acknowledgements .......................................... <a href="#page-10">10</a>
<a href="#section-8">8</a>. Authors' Addresses ........................................ <a href="#page-11">11</a>
<a href="#section-9">9</a>. Full Copyright Statement .................................. <a href="#page-12">12</a>
<span class="grey">Chiu, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The MOUNT protocol is used by an NFS client to obtain the necessary
filehandle for data access. MOUNT versions 1 and 2 [<a href="./rfc1094" title=""NFS: Network File System Protocol Specification"">RFC1094</a>] return
NFS version 2 filehandles, whereas MOUNT version 3 [<a href="./rfc1813" title=""NFS Version 3 Protocol Specification"">RFC1813</a>] returns
NFS version 3 filehandles.
Among the existing versions of the MOUNT protocol, only the MOUNT v3
provides an RPC procedure (MOUNTPROC3_MNT) which facilitates security
negotiation between an NFS v3 client and an NSF v3 server. When this
RPC procedure succeeds (MNT3_OK) the server returns to the client an
array of security mechanisms it supports for the specified pathname,
in addition to an NFS v3 filehandle.
A security mechanism referred to in this document is a generalized
security flavor which can be an RPC authentication flavor [<a href="./rfc1831">RFC1831</a>]
or a security flavor referred to in the RPCSEC_GSS protocol
[<a href="./rfc2203" title=""RPCSEC_GSS Protocol Specification"">RFC2203</a>]. A security mechanism is represented as a four-octet
integer.
No RPC procedures are available for security negotiation in versions
1 or 2 of the MOUNT protocol.
The NFS mount command provides a "sec=" option for an NFS client to
specify the desired security mechanism to use for NFS transactions.
If this mount option is not specified, the default action is to use
the default security mechanism over NFS v2 mounts, or to negotiate a
security mechanism via the MOUNTPROC3_MNT procedure of MOUNT v3 and
use it over NFS v3 mounts. In the latter, the client picks the first
security mechanism in the array returned from the server that is also
supported on the client.
As specified in <a href="./rfc2054">RFC 2054</a>, a WebNFS client first assumes that the
server supports WebNFS and uses the publsc filehandle as the initial
filehandle for data access, eliminating the need for the MOUNT
protocol. The WebNFS client falls back to MOUNT if the server does
not support WebNFS.
Since a WebNFS client does not use MOUNT initially, the
MOUNTPROC3_MNT procedure of MOUNT v3 is not available for security
negotiation until the WebNFS client falls back to MOUNT. A viable
protocol needs to be devised for the WebNFS client to negotiate
security mechanisms with the server in the absence of the
MOUNTPROC3_MNT procedure.
<span class="grey">Chiu, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
The WebNFS security negotiation protocol must meet the following
requirements:
- Must work seamlessly with NFS v2 and v3, and the WebNFS
protocols
- Must be backward compatible with servers that do not support
this negotiation
- Minimum number of network turnarounds (latency)
This document describes the WebNFS security negotiation protocol
developed by Sun Microsystems, Inc. Terminology and definitions from
RFCs 2054 and 2055 are used in this document. The reader is expected
to be familiar with them.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Security Negotiation Multi-component LOOKUP</span>
The goal of the WebNFS security negotiation is to allow a WebNFS
client to identify a security mechanism which is used by the WebNFS
server to protect a specified path and is also supported by the
client. The WebNFS client initiates the negotiation by sending the
WebNFS server the path. The WebNFS server responds with the array of
security mechanisms it uses to secure the specified path. From the
array of security mechanisms the WebNFS client selects the first one
that it also supports.
Without introducing a new WebNFS request, the WebNFS security
negotiation is achieved by modifying the request and response of the
existing multi-component LOOKUP (MCL) operation [<a href="./rfc2055" title=""WebNFS Server Specification"">RFC2055</a>]. Note that
the MCL operation is accomplished using the LOOKUP procedure
(NFSPROC3_LOOKUP for NFS v3 and NFSPROC_LOOKUP for NFS v2). This and
the next sections describe how the MCL request and response are
modified to facilitate WebNFS security negotiation.
For ease of reference, the modified MCL request is henceforth
referred to as SNEGO-MCL (security negotiation multi-component
LOOKUP) request.
A multi-component LOOKUP request [<a href="./rfc2055" title=""WebNFS Server Specification"">RFC2055</a>] is composed of a public
filehandle and a multi-component path:
For Canonical Path:
LOOKUP FH=0x0, "/a/b/c"
<span class="grey">Chiu, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
For Native Path:
LOOKUP FH=0x0, 0x80 "a:b:c"
A multi-component path is either an ASCII string of slash separated
components or a 0x80 character followed by a native path. Note that
a multi-component LOOKUP implies the use of the public filehandle in
the LOOKUP.
Similar to the MCL request, a SNEGO-MCL request consists of a public
filehandle and a pathname. However, the pathname is uniquely
composed, as described below, to distinguish it from other pathnames.
The pathname used in a SNEGO-MCL is the regular WebNFS multi-
component path prefixed with two octets. The first prefixed octet is
the 0x81 non-ascii character, similar to the 0x80 non-ascii character
for the native paths. This octet represents client's indication to
negotiate security mechanisms. It is followed by the security index
octet which stores the current value of the index into the array of
security mechanisms to be returned from the server. The security
index always starts with one and gets incremented as negotiation
continues. It is then followed by the pathname, either an ASCII
string of slash separated canonical components or 0x80 and a native
path.
A security negotiation multi-component LOOKUP request looks like
this:
For Canonical Path:
LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c"
For Native Path:
LOOKUP FH=0x0, 0x81 <sec-index> 0x80 "a:b:c"
In the next section we will see how the MCL response is modified for
WebNFS security negotiation.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Overloaded Filehandle</span>
As described in <a href="./rfc2054">RFC2054</a>, if a multi-component LOOKUP request
succeeds, the server responds with a valid filehandle:
LOOKUP FH=0x0, "a/b/c"
----------->
<-----------
FH=0x3
<span class="grey">Chiu, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
NFS filehandles are used to uniquely identify a particular file or
directory on the server and are opaque to the client. The client
neither examines a filehandle nor has any knowledge of its contents.
Thus, filehandles make an ideal repository for the server to return
the array of security mechanisms to the client in response to a
SNEGO-MCL request.
To a successful SNEGO-MCL request the server responds, in place of
the filehandle, with an array of integers that represents the valid
security mechanisms the client must use to access the given path. A
length field is introduced to store the size (in octets) of the array
of integers.
As the filehandles are limited in size (32 octets for NFS v2 and up
to 64 octets for NFS v3), it can happen that there are more security
mechanisms than the filehandles can accommodate. To circumvent this
problem, a one-octet status field is introduced which indicates
whether there are more security mechanisms (1 means yes, 0 means no)
that require the client to perform another SNEGO-MCL to get them.
To summarize, the response to a SNEGO-MCL request contains, in place
of the filehandle, the length field, the status field, and the array
of security mechanisms:
FH: length, status, {sec_1 sec_2 ... sec_n}
The next two sub-sections describe how NFS v2 and v3 filehandles are
"overloaded" to carry the length and status fields and the array of
security mechanisms.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Overloaded NFS Version 2 Filehandle</span>
A regular NFS v2 filehandle is defined in <a href="./rfc1094">RFC1094</a> as an opaque value
occupying 32 octets:
1 2 3 4 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
| | | | | | | | | ... | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
An overloaded NFS v2 filehandle looks like this:
1 2 3 4 5 8 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
| l | s | | | sec_1 | ... | sec_n | ... | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
<span class="grey">Chiu, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
Note that the first four octets of an overloaded NFS v2 filehandle
contain the length octet, the status octet, and two padded octets to
make them XDR four-octet aligned. The length octet l = 4 * n, where
n is the number of security mechanisms sent in the current overloaded
filehandle. Apparently, an overloaded NFS v2 filehandle can carry up
to seven security mechanisms.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Overloaded NFS Version 3 Filehandle</span>
A regular NFS v3 filehandle is defined in <a href="./rfc1813">RFC1813</a> as a variable
length opaque value occupying up to 64 octets. The length of the
filehandle is indicated by an integer value contained in a four octet
value which describes the number of valid octets that follow:
1 4
+---+---+---+---+
| len |
+---+---+---+---+
1 4 up to 64
+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
| | | | | | | | | | | | | ... | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
An overloaded NFS v3 filehandle looks like the following:
1 4
+---+---+---+---+
| len |
+---+---+---+---+
1 4 5 8
+---+---+---+---+---+---+---+---+ +---+---+---+---+
| s | | | | sec_1 | ... | sec_n |
+---+---+---+---+---+---+---+---+ +---+---+---+---+
Here, len = 4 * (n+1). Again, n is the number of security mechanisms
contained in the current overloaded filehandle. Three octets are
padded after the status octet to meet the XDR four-octet alignment
requirement. An overloaded NFS v3 filehandle can carry up to fifteen
security mechanisms.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. WebNFS Security Negotiation</span>
With the SNEGO-MCL request and the overloaded NFS v2 and v3
filehandles defined above, the following diagram depicts the WebNFS
security negotiation protocol:
<span class="grey">Chiu, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
Client Server
------ ------
LOOKUP FH=0x0, 0x81 <sec-index> "path"
----------->
<-----------
FH: length, status, {sec_1 sec_2 ... sec_n}
where
0x81 represents client's indication to negotiate security
mechanisms with the server,
path is either an ASCII string of slash separated components or
0x80 and a native path,
sec-index, one octet, contains the index into the array of
security mechanisms the server uses to protect the specified path,
status, one octet, indicates whether there are more security
mechanisms (1 means yes, 0 means no) that require the client to
perform another SNEGO-MCL to get them,
length (one octet for NFS v2 and four octets for NFS v3) describes
the number of valid octets that follow,
{sec_1 sec_2 ... sec_n} represents the array of security
mechanisms. As noted earlier, each security mechanism is
represented by a four-octet integer.
Here is an example showing the WebNFS security negotiation protocol
with NFS v2. In the example it is assumed the server shares /export
with 10 security mechanisms {0x3900 0x3901 0x3902 ... 0x3909} on the
export, two SNEGO-MCL requests would be needed for the client to get
the complete security information:
LOOKUP FH=0x0, 0x81 0x01 "/export"
----------->
<-----------
0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906}
LOOKUP FH=0x0, 0x81 0x08 "/export"
----------->
<-----------
0x0c, 0x00, {0x3907 0x3908 0x3909}
<span class="grey">Chiu, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
The order of the security mechanisms returned in an overloaded
filehandle implies preferences, i.e., one is more recommended than
those following it. The ordering is the same as that returned by the
MOUNT v3 protocol.
The following shows a typical scenario which illustrates how the
WebNFS security negotiation is accomplished in the course of
accessing publicly shared filesystems.
Normally, a WebNFS client first makes a regular multi-component
LOOKUP request using the public filehandle to obtain the filehandle
for the specified path. Since the WebNFS client does not have any
prior knowledge as to how the path is protected by the server the
default security mechanism is used in this first multi-component
LOOKUP. If the default security mechanism does not meet server's
requirements, the server replies with the AUTH_TOOWEAK RPC
authentication error, indicating that the default security mechanism
is not valid and the WebNFS client needs to use a stronger one.
Upon receiving the AUTH_TOOWEAK error, to find out what security
mechanisms are required to access the specified path the WebNFS
client sends a SNEGO-qMCL request, using the default security
mechanism.
If the SNEGO-MCL request succeeds the server responds with the
filehandle overloaded with the array of security mechanisms required
for the specified path. If the server does not support WebNFS
security negotiation, the SNEGO-MCL request fails with NFSERR_IO for
NFS v2 or NFS3ERR_IO for NFS v3 [<a href="./rfc2055" title=""WebNFS Server Specification"">RFC2055</a>].
Depending on the size of the array of security mechanisms, the WebNFS
client may have to make more SNEGO-MCL requests to get the complete
array.
For successful SNEGO-MCL requests, the WebNFS client retrieves the
array of security mechanisms from the overloaded filehandle, selects
an appropriate one, and issues a regular multi-component LOOKUP using
the selected security mechanism to acquire the filehandle.
All subsequent NFS requests are then made using the selected security
mechanism and the filehandle.
The following depicts the scenario outlined above. It is assumed
that the server shares /export/home as follows:
share -o sec=sec_1:sec_2:sec_3,public /export/home
<span class="grey">Chiu, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
and AUTH_SYS is the client's default security mechanism and is not
one of {sec_1, sec_2, sec_3}.
Client Server
------ ------
LOOKUP FH=0x0, "/export/home"
AUTH_SYS
----------->
<-----------
AUTH_TOOWEAK
LOOKUP FH=0x0, 0x81 0x01 "/export/home"
AUTH_SYS
----------->
<-----------
overloaded FH: length, status, {sec_1 sec_2 sec_3}
LOOKUP FH=0x0, "/export/home"
sec_n
----------->
<-----------
FH = 0x01
NFS request with FH=0x01
sec_n
----------->
<-----------
...
In the above scenario, the first request is a regular multi-component
LOOKUP which fails with the AUTH_TOOWEAK error. The client then
issues a SNEGO-MCL request to get the security information.
There are WebNFS implementations that allow the public filehandle to
work with NFS protocol procedures other than LOOKUP. For those
WebNFS implementations, if the first request is not a regular multi-
component LOOKUP and it fails with AUTH_TOOWEAK, the client should
issue a SNEGO-MCL with
0x81 0x01 "."
as the path to get the security information.
<span class="grey">Chiu, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The reader may note that no mandatory security mechanisms are
specified in the protocol that the client must use in making SNEGO-
MCL requests. Normally, the client uses the default security
mechanism configured on his system in the first SNEGO-MCL request.
If the default security mechanism is not valid the server replies
with the AUTH_TOOWEAK error. In this case the server does not return
the array of security mechanisms to the client. The client can then
make another SNEGO-MCL request using a stronger security mechanism.
This continues until the client hits a valid one or has exhausted all
the supported security mechanisms.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
[<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-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-RFC2054">RFC2054</a>] Callaghan, B., "WebNFS Client Specification", <a href="./rfc2054">RFC 2054</a>,
October 1996. <a href="http://www.ietf.org/rfc/rfc2054.txt">http://www.ietf.org/rfc/rfc2054.txt</a>
[<a id="ref-RFC2055">RFC2055</a>] Callaghan, B., "WebNFS Server Specification", <a href="./rfc2055">RFC 2055</a>,
October 1996. <a href="http://www.ietf.org/rfc/rfc2055.txt">http://www.ietf.org/rfc/rfc2055.txt</a>
[<a id="ref-RFC2203">RFC2203</a>] Eisler, M., Chiu, A. and Ling, L., "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>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
This specification was extensively brainstormed and reviewed by the
NFS group of Solaris Software Division.
<span class="grey">Chiu, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Authors' Addresses</span>
Alex Chiu
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
Phone: +1 (650) 786-6465
EMail: alex.chiu@Eng.sun.com
Mike Eisler
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
Phone: +1 (719) 599-9026
EMail: michael.eisler@Eng.sun.com
Brent Callaghan
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
Phone: +1 (650) 786-5067
EMail: brent.callaghan@Eng.sun.com
<span class="grey">Chiu, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2755">RFC 2755</a> Security Negotiation for WebNFS January 2000</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2000). 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 implementation 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
developing 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.
Chiu, et al. Informational [Page 12]
</pre>
|
