AUTH(4) BSD Programmer's Manual AUTH(4)NAMEauth - remote authentication protocol
DESCRIPTION
The authsrv(8) and login_auth(8) programs communicate via the remote au-
thentication protocol. Data sent between the client and server is always
encrypted. (See ENCRYPTION below). The protocol consists of lines of
ASCII text. Each line of text consists of a directive, a single space,
the data for the directive, and a terminating newline. For directives
which take arbitrary text (indicated below), the C function strvisx(3) is
used with the VIS_WHITE and VIS_CSTYLE flags to encode the text. If a
directive is not allowed arbitrary text then all text must be within the
set of characters defined by the isgraph(3) function. By convention, all
directives end with a colon (:).
The protocol starts by the client sending a series of directives describ-
ing the request to the server. These directives are:
CLASS: The class of the user. This information is not used by
authsrv directly. It is simply passed the the appropri-
ate authentication script.
SERVICE: The type of service being requested. This information
is not used by authsrv directly. It is simply passed
the the appropriate authentication script via the -s
flag.
STYLE: The style of authentication. This is determined by
striping the leading login_ from the name of the client
(i.e., if the client was called as login_rpasswd then
the style would be rpasswd). The server will call the
login script /usr/libexec/login_style. The exception is
that the special style of auth implies the server should
use the default style for remote authentication. (See
authsrv(8).) This directive must be provided before the
actual authentication may begin.
USER: The user being authenticated. This information is not
used by authsrv directly. It is simply passed the the
appropriate authentication script. This directive must
be provided before the actual authentication may begin.
VARG: The data, which may be arbitrary text, is passed to the
authentication script via the -v flag. This directive
may be used multiple times to add addition -v parame-
ters.
Once the above information is provided, the client requests the server to
begin authentication via:
START: Actually start the authentication. No further direc-
tives describing the request may be sent.
After requesting the server to begin authentication, the following direc-
tives are allowed:
FD0: The data, which may be arbitrary text, should be provid-
ed to the authentication script as if it had been typed
by the user. If no data is provided the authentication
script should be provided an EOF.
FD3: The data, which may be arbitrary text, should be provid-
ed to the authentication script on the back channel
(file descriptor 3).
Typically these directives simply pass data read from client program.
The server may send the following directives at any time:
ECHO: If the data is the string "OFF" then echo should be
turned off on the users terminal, otherwise echo should
be turned on.
EXIT: The data should be the decimal representation of a num-
ber which is to be passed to exit(3). If no data is
provided the client will exit with a value of 1. In any
case, this directive should cause the client to termi-
nate.
FD1: The client should write the data, which may be arbitrary
text, to standard output.
FD2: The client should write the data, which may be arbitrary
text, to standard error.
FD3: The client should write the data, which may be arbitrary
text, to the back channel (file descriptor 3).
ENCRYPTION
All data between the client and server must be encrypted, with the excep-
tion that the server will send a single null terminated string to the
client indicating what encryption type is to be used. The shared secret
is know to both the client and the server prior to the session being es-
tablished (see auth-keyx(8)). Currently the only form of encryption
available is:
DES Data Encryption Standard. The session is initiated with
the following steps:
o Client generates a random key, which will become the
session key, encrypts it with the shared secret and
sends it to Server.
o Server decrypts the session key from Client. Server
increments the 8th byte of the session key, encrypts
the result, and sends it back to Client. (The actual
session key is not incremented).
o Client decrypts the response from Server and verifies
it is in fact the session key with the 8th byte incre-
mented.
o Client generates a random 8 byte vector and sends it
to Server.
o Server generates a random 8 byte vector and sends it
to Client.
Once the key exchange is finished and both sides know the
others vector, session data may be transferred. This vec-
tor is used to generate a stream of random data to XOR into
the data stream. Since each session starts with known
clear text, the clear text may be infused with random data,
increasing its size by up to a factor of 2. The NUL char-
acter in the clear text stream implies random data follows.
The byte after the NUL contains the number of random bytes
to follow. Up to 127 random bytes may be present. While
the clear text protocol does not allow for a NUL, it may
still be sent by duplicating it (e.g., NUL NUL).
The generation of random data is weighted to the start of a
block of data being sent. Typically a block of data will
start with a large amount of random data, followed by a
single character, followed by a lesser amount of random da-
ta, and so on. Typically the tail end of the block will
have no random data infused.
Since the vector is initially sent in the clear, it must be
encrypted with the session key prior to use. Each byte of
the augmented clear text is XOR-ed into the corresponding
byte of the vector and then sent. Once all 8 bytes of the
vector have been used the (modified) vector is once again
encrypted with the session key to produce a vector for the
next 8 bytes of data. This process is repeated as often as
needed.
The authentication mode specific data stored in the
/etc/authsrv.keys/... file consists of 16 hexadecimal dig-
its which make up the shared DES key.
SEE ALSOauth-keyx(8), authsrv(8), login_auth(8)BSDI BSD/OS May 16, 1997 3