auth man page on BSDi

Man page or keyword search:  
man Server   6284 pages
apropos Keyword Search (all sections)
Output format
BSDi logo
[printable version]

AUTH(4)			    BSD Programmer's Manual		       AUTH(4)

NAME
     auth - 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 ALSO
     auth-keyx(8),  authsrv(8),	 login_auth(8)

BSDI BSD/OS			 May 16, 1997				     3
[top]

List of man pages available for BSDi

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net