RFC 2755 (rfc2755) - Page 3 of 12
Security Negotiation for WebNFS
Alternative Format: Original Text Document
RFC 2755 Security Negotiation for WebNFS January 2000
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.
2. Security Negotiation Multi-component LOOKUP
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 [RFC 2055]. 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 [RFC 2055] is composed of a public
filehandle and a multi-component path:
For Canonical Path:
LOOKUP FH=0x0, "/a/b/c"
Chiu, et al. Informational