1.5 Authentication and Permission Checking
Connected: An Internet Encyclopedia
1.5 Authentication and Permission Checking
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1813
Up:
1. Introduction
Prev: 1.4 External Data Representation
Next: 1.6 Philosophy
1.5 Authentication and Permission Checking
1.5 Authentication and Permission Checking
The RPC protocol includes a slot for authentication parameters
on every call. The contents of the authentication 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. The AUTH_NONE flavor provides null
authentication, that is, no authentication information is
passed. The AUTH_UNIX flavor provides UNIX-style user ID, group
ID, and groups with each call. The AUTH_DES flavor provides
DES-encrypted authentication parameters based on a network-wide
name, with session keys exchanged via a public key scheme. The
AUTH_KERB flavor provides DES encrypted authentication
parameters based on a network-wide name with session keys
exchanged via Kerberos secret keys.
The NFS server checks permissions by taking the credentials from
the RPC authentication information in each remote request. For
example, using the AUTH_UNIX flavor of authentication, the
server gets the user's effective user ID, effective group ID and
groups on each call, and uses them to check access. Using user
ids and group ids implies that the client and server either
share the same ID list or do local user and group ID mapping.
Servers and clients must agree on the mapping from user to uid
and from group to gid, for those sites that do not implement a
consistent user ID and group ID space. In practice, such mapping
is typically performed on the server, following a static mapping
scheme or a mapping established by the user from a client at
mount time.
The AUTH_DES and AUTH_KERB style of authentication is based on a
network-wide name. It provides greater security through the use
of DES encryption and public keys in the case of AUTH_DES, and
DES encryption and Kerberos secret keys (and tickets) in the
AUTH_KERB 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
uid and gid mapping in AUTH_UNIX. Also, because the
authentication parameters are encrypted, a malicious user must
know another users 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.
The NULL procedure typically requires no authentication.
Next: 1.6 Philosophy
Connected: An Internet Encyclopedia
1.5 Authentication and Permission Checking
|