< draft-chiu-network-wnfs-sec-nego-00.txt   draft-chiu-network-wnfs-sec-nego-01.txt >
Network Working Group A. Chiu Network Working Group A. Chiu
Internet Draft M. Eisler Internet Draft M. Eisler
Category: Informational B. Callaghan Category: Informational B. Callaghan
Security Negotiation for WebNFS Security Negotiation for WebNFS
draft-chiu-network-wnfs-sec-nego-00.txt draft-chiu-network-wnfs-sec-nego-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts are draft documents valid for a maximum of six months.
This Internet-Draft expires on September 26, 1999. Internet-Drafts may be This Internet-Draft expires on April 4, 2000. Internet-Drafts may be
updated, replaced, or obsoleted by other documents at any time. It is not updated, replaced, or obsoleted by other documents at any time. It is not
appropriate to use Internet-Drafts as reference material or to cite them appropriate to use Internet-Drafts as reference material or to cite them
other than as "work in progress." other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the "1id- To view the entire list of current Internet-Drafts, please check the "1id-
abstracts.txt" listing contained in the Internet-Drafts Shadow Directories abstracts.txt" listing contained in the Internet-Drafts Shadow Directories
on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it
(Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
skipping to change at page 2, line 4 skipping to change at page 2, line 4
1. Introduction ................................................2 1. Introduction ................................................2
2. Security Negotiation Multi-component LOOKUP .................3 2. Security Negotiation Multi-component LOOKUP .................3
3 Overloaded Filehandle .......................................4 3 Overloaded Filehandle .......................................4
3.1 Overloaded NFS Version 2 Filehandle .......................5 3.1 Overloaded NFS Version 2 Filehandle .......................5
3.2 Overloaded NFS Version 3 Filehandle .......................5 3.2 Overloaded NFS Version 3 Filehandle .......................5
4. WebNFS Security Negotiation .................................6 4. WebNFS Security Negotiation .................................6
5. Security Considerations .....................................8 5. Security Considerations .....................................8
6. References ..................................................8 6. References ..................................................8
7. Acknowledgements ............................................9 7. Acknowledgements ............................................9
8. Authors' Addresses ..........................................9 8. Authors' Addresses ..........................................9
INTERNET-DRAFT Security Negotiation for WebNFS 26-March-99
INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
1. Introduction 1. Introduction
The MOUNT protocol is used by an NFS client to obtain the necessary The MOUNT protocol is used by an NFS client to obtain the necessary
filehandle for data access. MOUNT versions 1 and 2 [RFC1094] return NFS filehandle for data access. MOUNT versions 1 and 2 [RFC1094] return NFS
version 2 filehandles, whereas MOUNT version 3 [RFC1813] returns NFS version 2 filehandles, whereas MOUNT version 3 [RFC1813] returns NFS
version 3 filehandles. version 3 filehandles.
Among the existing versions of the MOUNT protocol, only the MOUNT v3 Among the existing versions of the MOUNT protocol, only the MOUNT v3
provides an RPC procedure (MOUNTPROC3_MNT) which facilitates security provides an RPC procedure (MOUNTPROC3_MNT) which facilitates security
skipping to change at page 3, line 4 skipping to change at page 3, line 4
- Must work seamlessly with NFS v2 and v3, and the WebNFS protocols - Must work seamlessly with NFS v2 and v3, and the WebNFS protocols
- Must be backward compatible with servers that do not support - Must be backward compatible with servers that do not support
this negotiation this negotiation
- Minimum number of network turnarounds (latency) - Minimum number of network turnarounds (latency)
This document describes the WebNFS security negotiation protocol developed This document describes the WebNFS security negotiation protocol developed
by Sun Microsystems, Inc. Terminology and definitions from RFCs 2054 and by Sun Microsystems, Inc. Terminology and definitions from RFCs 2054 and
INTERNET-DRAFT Security Negotiation for WebNFS 26-March-99
INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
2055 are used in this document. The reader is expected to be familiar with 2055 are used in this document. The reader is expected to be familiar with
them. them.
2. Security Negotiation Multi-component LOOKUP 2. Security Negotiation Multi-component LOOKUP
The goal of the WebNFS security negotiation is to allow a WebNFS client to 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 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 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 initiates the negotiation by sending the WebNFS server the path. The WebNFS
skipping to change at page 3, line 50 skipping to change at page 3, line 51
A multi-component path is either an ASCII string of slash separated 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 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 multi-component LOOKUP implies the use of the public filehandle in the
LOOKUP. LOOKUP.
Similar to the MCL request, a SNEGO-MCL request consists of a public Similar to the MCL request, a SNEGO-MCL request consists of a public
filehandle and a pathname. However, the pathname is uniquely composed, as filehandle and a pathname. However, the pathname is uniquely composed, as
described below, to distinguish it from other pathnames. described below, to distinguish it from other pathnames.
The pathname used in a SNEGO-MCL is the regular WebNFS mulit-component path 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 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. character, similar to the 0x80 non-ascii character for the native paths.
This octet represents client's indication to negotiate security mechanisms. This octet represents client's indication to negotiate security mechanisms.
It is followed by the security index octet which stores the current value 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 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 server. The security index always starts with one and gets incremented as
negotiation continues. It is then followed by the pathname, either an negotiation continues. It is then followed by the pathname, either an
INTERNET-DRAFT Security Negotiation for WebNFS 26-March-99
INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
ASCII string of slash separated canonical components or 0x80 and a native ASCII string of slash separated canonical components or 0x80 and a native
path. path.
A security negotiation multi-component LOOKUP request looks like this: A security negotiation multi-component LOOKUP request looks like this:
For Canonical Path: For Canonical Path:
LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c" LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c"
skipping to change at page 5, line 4 skipping to change at page 5, line 4
perform another SNEGO-MCL to get them. perform another SNEGO-MCL to get them.
To summarize, the response to a SNEGO-MCL request contains, in place of the 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 filehandle, the length field, the status field, and the array of security
mechanisms: mechanisms:
FH: length, status, {sec_1 sec_2 ... sec_n} FH: length, status, {sec_1 sec_2 ... sec_n}
The next two sub-sections describe how NFS v2 and v3 filehandles are 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 "overloaded" to carry the length and status fields and the array of
INTERNET-DRAFT Security Negotiation for WebNFS 26-March-99
INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
security mechanisms. security mechanisms.
3.1 Overloaded NFS Version 2 Filehandle 3.1 Overloaded NFS Version 2 Filehandle
A regular NFS v2 filehandle is defined in RFC1094 as an opaque value A regular NFS v2 filehandle is defined in RFC1094 as an opaque value
occupying 32 octets: occupying 32 octets:
1 2 3 4 32 1 2 3 4 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
skipping to change at page 6, line 4 skipping to change at page 6, line 4
1 4 1 4
+---+---+---+---+ +---+---+---+---+
| len | | len |
+---+---+---+---+ +---+---+---+---+
1 4 5 8 1 4 5 8
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+---+---+---+---+---+---+ +---+---+---+---+
| s | | | | sec_1 | ... | sec_n | | s | | | | sec_1 | ... | sec_n |
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+---+---+---+---+---+---+ +---+---+---+---+
INTERNET-DRAFT Security Negotiation for WebNFS 26-March-99
INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
Here, len = 4 * (n+1). Again, n is the number of security mechanisms Here, len = 4 * (n+1). Again, n is the number of security mechanisms
contained in the current overloaded filehandle. Three octets are padded contained in the current overloaded filehandle. Three octets are padded
after the status octet to meet the XDR four-octet alignment requirement. after the status octet to meet the XDR four-octet alignment requirement.
An overloaded NFS v3 filehandle can carry up to fifteen security An overloaded NFS v3 filehandle can carry up to fifteen security
mechanisms. mechanisms.
4. WebNFS Security Negotiation 4. WebNFS Security Negotiation
With the SNEGO-MCL request and the overloaded NFS v2 and v3 filehandles With the SNEGO-MCL request and the overloaded NFS v2 and v3 filehandles
skipping to change at page 7, line 4 skipping to change at page 7, line 4
Here is an example showing the WebNFS security negotiation protocol with 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 NFS v2. In the example it is assumed the server shares /export with 10
security mechanisms {0x3900 0x3901 0x3902 ... 0x3909} on the export, two security mechanisms {0x3900 0x3901 0x3902 ... 0x3909} on the export, two
SNEGO-MCL requests would be needed for the client to get the complete SNEGO-MCL requests would be needed for the client to get the complete
security information: security information:
LOOKUP FH=0x0, 0x81 0x01 "/export" LOOKUP FH=0x0, 0x81 0x01 "/export"
-----------> ----------->
<----------- <-----------
0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906} 0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906}
INTERNET-DRAFT Security Negotiation for WebNFS 26-March-99
INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
LOOKUP FH=0x0, 0x81 0x08 "/export" LOOKUP FH=0x0, 0x81 0x08 "/export"
-----------> ----------->
<----------- <-----------
0x0c, 0x00, {0x3907 0x3908 0x3909} 0x0c, 0x00, {0x3907 0x3908 0x3909}
The order of the security mechanisms returned in an overloaded filehandle The order of the security mechanisms returned in an overloaded filehandle
implies preferences, i.e., one is more recommended than those following it. 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 ordering is the same as that returned by the MOUNT v3 protocol.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
mechanism and the filehandle. mechanism and the filehandle.
The following depicts the scenario outlined above. It is assumed that the The following depicts the scenario outlined above. It is assumed that the
server shares /export/home as follows: server shares /export/home as follows:
share -o sec=sec_1:sec_2:sec_3,public /export/home share -o sec=sec_1:sec_2:sec_3,public /export/home
and AUTH_SYS is the client's default security mechanism and is not one of and AUTH_SYS is the client's default security mechanism and is not one of
{sec_1, sec_2, sec_3}. {sec_1, sec_2, sec_3}.
INTERNET-DRAFT Security Negotiation for WebNFS 26-March-99 INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
Client Server Client Server
------ ------ ------ ------
LOOKUP FH=0x0, "/export/home" LOOKUP FH=0x0, "/export/home"
AUTH_SYS AUTH_SYS
-----------> ----------->
<----------- <-----------
AUTH_TOOWEAK AUTH_TOOWEAK
skipping to change at page 8, line 34 skipping to change at page 8, line 34
-----------> ----------->
<----------- <-----------
FH = 0x01 FH = 0x01
NFS request with FH=0x01 NFS request with FH=0x01
sec_n 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.
5. Security Considerations 5. Security Considerations
The reader may note that no mandatory security mechsnisms are specified in The reader may note that no mandatory security mechsnisms are specified in
the protocol that the client must use in making SNEGO-MCL requests. the protocol that the client must use in making SNEGO-MCL requests.
INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
Normally, the client uses the default security mechanism configured on his Normally, the client uses the default security mechanism configured on his
system in the first SNEGO-MCL request. If the default security mechanism 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 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 server does not return the array of security mechanisms to the client.
The client can then make another SNEGO-MCL request using a stronger The client can then make another SNEGO-MCL request using a stronger
security mechanism. This continues until the client hits a valid one or security mechanism. This continues until the client hits a valid one or
has exhausted all the supported security mechanisms. has exhausted all the supported security mechanisms.
6. References 6. References
[RFC1094] Sun Microsystems, Inc., "Network Filesystem [RFC1094] Sun Microsystems, Inc., "Network Filesystem
Specification", RFC 1094, March 1989. NFS Specification", RFC 1094, March 1989. NFS
version 2 protocol specification. version 2 protocol specification.
http://www.internic.net/rfc/rfc1094.txt http://www.ietf.org/rfc/rfc1094.txt
INTERNET-DRAFT Security Negotiation for WebNFS 26-March-99
[RFC1813] Sun Microsystems, Inc., "NFS Version 3 Protocol [RFC1813] Sun Microsystems, Inc., "NFS Version 3 Protocol
Specification", RFC 1813, June 1995. NFS version Specification", RFC 1813, June 1995. NFS version
3 protocol specification. 3 protocol specification.
http://www.internic.net/rfc/rfc1813.txt http://www.ietf.org/rfc/rfc1813.txt
[RFC2054] Callaghan, B., "WebNFS Client Specification", [RFC2054] Callaghan, B., "WebNFS Client Specification",
RFC 2054, October 1996. RFC 2054, October 1996.
http://www.internic.net/rfc/rfc2054.txt http://www.ietf.org/rfc/rfc2054.txt
[RFC2055] Callaghan, B., "WebNFS Server Specification", [RFC2055] Callaghan, B., "WebNFS Server Specification",
RFC 2055, October 1996. RFC 2055, October 1996.
http://www.internic.net/rfc/rfc2055.txt http://www.ietf.org/rfc/rfc2055.txt
[RFC2203] Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS [RFC2203] Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS
Protocol Specification", RFC 2203, September 1997. Protocol Specification", RFC 2203, September 1997.
http://www.internic.net/rfc/rfc2203.txt http://www.ietf.org/rfc/rfc2203.txt
7. Acknowledgements 7. Acknowledgements
This specification was extensively brainstormed and reviewed by the NFS This specification was extensively brainstormed and reviewed by the NFS
group of Solaris Software Division. group of Solaris Software Division.
8. Authors' Addresses 8. Authors' Addresses
Alex Chiu Alex Chiu
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 901 San Antonio Road
Palo Alto, CA 94303 Palo Alto, CA 94303
Phone: +1 (650) 786-6465 Phone: +1 (650) 786-6465
E-mail: alex.chiu@Eng.sun.com E-mail: alex.chiu@Eng.sun.com
Mike Eisler Mike Eisler
Sun Microsystems, Inc. Sun Microsystems, Inc.
INTERNET-DRAFT Security Negotiation for WebNFS 4-October-99
901 San Antonio Road 901 San Antonio Road
Palo Alto, CA 94303 Palo Alto, CA 94303
Phone: +1 (719) 599-9026 Phone: +1 (719) 599-9026
E-mail: michael.eisler@Eng.sun.com E-mail: michael.eisler@Eng.sun.com
Brent Callaghan Brent Callaghan
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 901 San Antonio Road
 End of changes. 20 change blocks. 
17 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/