Printable Version: RFC1831.PDF
RFC 1831 Remote Procedure Call Protocol Version 2 August 1995
APPENDIX A: SYSTEM AUTHENTICATION
The client may wish to identify itself, for example, as it is
identified on a UNIX(tm) system. The flavor of the client credential
is "AUTH_SYS". The opaque data constituting the credential encodes
the following structure:
struct authsys_parms {
unsigned int stamp;
string machinename<255>;
unsigned int uid;
unsigned int gid;
unsigned int gids<16>;
};
The "stamp" is an arbitrary ID which the caller machine may generate.
The "machinename" is the name of the caller's machine (like
"krypton"). The "uid" is the caller's effective user ID. The "gid"
is the caller's effective group ID. The "gids" is a counted array of
groups which contain the caller as a member. The verifier
accompanying the credential should have "AUTH_NONE" flavor value
(defined above). Note this credential is only unique within a
particular domain of machine names, uids, and gids.
The flavor value of the verifier received in the reply message from
the server may be "AUTH_NONE" or "AUTH_SHORT". In the case of
"AUTH_SHORT", the bytes of the reply verifier's string encode an
opaque structure. This new opaque structure may now be passed to the
server instead of the original "AUTH_SYS" flavor credential. The
server may keep a cache which maps shorthand opaque structures
(passed back by way of an "AUTH_SHORT" style reply verifier) to the
original credentials of the caller. The caller can save network
bandwidth and server cpu cycles by using the shorthand credential.
The server may flush the shorthand opaque structure at any time. If
this happens, the remote procedure call message will be rejected due
to an authentication error. The reason for the failure will be
"AUTH_REJECTEDCRED". At this point, the client may wish to try the
original "AUTH_SYS" style of credential.
It should be noted that use of this flavor of authentication does not
guarantee any security for the users or providers of a service, in
itself. The authentication provided by this scheme can be considered
legitimate only when applications using this scheme and the network
can be secured externally, and privileged transport addresses are
used for the communicating end-points (an example of this is the use
of privileged TCP/UDP ports in Unix systems - note that not all
systems enforce privileged transport address mechanisms).
Srinivasan Standards Track [Page 16]