NOTE: This file was updated on 30 June 1994.  Your commserver/router may
	not support all the features disscussed in this document.  If you
	need to upgrade your system, please contact cisco TAC at
	tac@cisco.com or (800) 553-2447.
	
extended TACACS capability for accounting and auditing.

New commands (per system)

    tacacs-server extended
    tacacs-server notify enable
    tacacs-server notify connect|slip|logout [ always ]
	Notify causes a message to be transmitted to the tacacs server,
	with retransmition being performed by a background process for
	up to 5 minutes.  However, the user get the equivilent of an
	immediate "accepted" response.  The always option causes the slip
	notification message to get sent, even if the user has not logged 
	in (authenticated).
    tacacs authenticate enable
    tacacs authenticate connect [ always ]
    tacacs authenticate slip [ always ] [ access-lists ]
	Authenticate requires a repsonse from the server to indicate
	whether the user can prefer the indicated action.  The always
	option causes the slip authentication message to be sent even if
	the user has not logged in (authenticated).  The "access-lists"
	option causes the slip authetication to request a set of input and
	output access lists from the TACACS server.

New packet format:

    uchar version;		     /* NOTE: see below for an explanation 
					of the new version number scheme */
	XTA_VERSION             0x80
	XTA_MINOR_VERSION       0x01 /* current minor number for new queries */
	XTA_MAJOR_VERSION_MASK  0xf0
	XTA_MINOR_VERSION_MASK  0x0f
    uchar type;			/* Type of query/response */
	XTA_LOGIN	1
	XTA_ANSWER	2
	XTA_CHANGE	3
	XTA_FOLLOW	4
	XTA_CONNECT	5
	XTA_ENABLE	6
	XTA_LOGOUT	7
	XTA_RELOAD	8
	XTA_SLIPON	9
	XTA_SLIPOFF    10
	XTA_SLIPADDR   11
	XTA_ARAP_AUTH  12
	XTA_CHAP_AUTH  13
    ushort trans;		/* unique ID to associate query w reply */
    uchar namelen;		/* length of name */
    uchar pwlen;		/* length of password */
    uchar response;		/* response code */
	XTA_A_ACCEPTED	1
	XTA_A_REJECTED	2
    uchar reason;		/* reason for response or query */
	XTA_A_NONE	0
	XTA_A_EXPIRING	1
	XTA_A_PASSWORD	2
	XTA_A_DENIED	3
	XTA_A_NOROUTE   8	/* Dialup routing not permitted */
	XTA_A_LOGINREQ  9	/* Login required for requested action */
	/*
	 * The following are reasons for "logout" and "slipoff" 
	 */
	XTA_R_QUIT	4	/* user quit normally */
	XTA_R_IDLE	5	/* idle timeout */
	XTA_R_DROP	6	/* carrier dropped */
	XTA_R_BAD	7	/* too many bad passwords */

    ushort accesslist;		/* access list for user returned at login */
    ulong flags;		/* misc flags */
    ulong uuid;			/* user id code assigned. */
    ushort lport;		/* local line number */
    ulong dhost;		/* destination host */
    ushort dport;		/* destination port */
				/* user name */
				/* password */


new xtacacsd.c documentation:

	xtacacsd [-s] [-d] [-l] [-f/etc/tacpasswd] [-w/var/log/tacacs.wtmp]

	-s	standalone mode - the server runs continuously.
		Recomended for extended use.

	-d	Debugging.

	-l	Log events to syslog local6 file.  All events are logged:
		system reload from server
		xlogin from server ttyNN for user(gcos) accepted|rejected
		xconnect from server ttyNN for user(uuid) to host:port
		xlogout from server ttyNN for user(uuid) reason
		xslipon from server SLIPNN for user(uuid) address slipaddress
		xslipoff from server SLIPNN for user(uuid) address slipaddress
		slipaddress from server ttyNN for host(gcos) accepted|rejected

	-w<wtmpfile> log on/off events in a wtmp format file.
		In theory, this makes it possible to keep track of per-user
		connect times, and print them using the "ac" unix utility.
		Events logged:
		-  System reload.  "~" in name field, servername in host field
		-  Login / Logout  username, "TTYnn", slipaddress
		-  SlipOn / SlipOff username, "SLIPnn", slipaddress
		If a user logs in and issues a SLIP command, the following
		sequence should appear in the wtmp file:
		login TTYnn username servername
		    time passes
		slipon SLIPnn username slipname
		logout TTYnn username servername
		    time passes
		slipoff SLIPnn username slipname

		A potential problem exists: data for all servers is stored
		in the same wtmp file, the differences being noted by the
		ut_host field in the wtmp entries.  The "ac" program may
		not look at this field for determining matching entries.
		Thus having the same user log in on more than one terminal
		server at the same time may result in invalid final reports.

	-f<passwd-file>	file to find password information.  If not given,
		/etc/passwd is used, and the following features are not used:
		-  The user id is used as the uuid.
		-  The group ID field is used as the access list.
		-  An expiration data for the account is stored in the shell
		   field of the entry.

	-F<supplementary_information_file>
		There is no default for this.  If the option is not given,
		then none of the features that rely on the file will be
		enabled.  The file contains lines of colon (`:') separated
		fields.  A line delineates a single entry.  The first field
		is the match field.  For the code provided by cisco, this
		field is always used to find a user name.  However, you may
		wish to change the code to match on something else such as
		an IP address or line number or ...
		The values after the match field are discussed below.


New version numbers
	In previous versions of TACACS the version number 0x80 was used to
	represent "extended TACACS".  In order to enhance extended TACACS,
	but maintain as much compatibility as possible, a new scheme was
	implemented.  The byte used to hold the version number has been
	broken into two nibbles (4 bits or one hex character).  The most
	significant nibble is the MAJOR version.  The least significant
	nibble is the MINOR version.  For extended TACACS, the major number
	will remain 0x8.  So for Major number 0x8 and minor number 0x0, the
	version number would be 0x80.  If the minor number becomes 0x1,
	then the version number becomes 0x81.

	Compatibility is maintained because commands use the lowest minor
	version number that they are compatible with.  So an XTA_LOGIN
	request will still use a version number of 0x80.  But a
	XTA_CHAP_AUTH request is new and is incompatible with older
	implementations of TACACS so it will arrive with a version number
	of 0x81.  If your TACACS server is complaining of receiving invalid
	version numbers, then you probably need to get the latest/greatest
	version of xtacacsd from cisco.  (NOTE: you will only ever need to
	upgrade xtacacsd in order to get NEW functionality.)

The Supplementary File
	This file stores values which will not fit in the standard password
	file.  It also stores some values which require greater security
	than do the values in the passwd file (see CHAP and ARAP below).
	An entry in the supplementary file looks like this:

	carrel:101:102:arap secret:chap secret
	skippy:101:102:arap secret::
	stimpy:113:114::chap secret:

	Currently there are only four fields defined in the file.  These are
		XTA_SUP_IPACLIN         1	/* input ACL for IP */
		XTA_SUP_IPACLOUT        2	/* output ACL for IP */
		XTA_SUP_ARAP_SEC        3	/* An ARAP secret */
		XTA_SUP_CHAP_SEC        4	/* A CHAP secret */
	The field positions are defined in tacacs.h.  Simple changes may be
	done by editing this file.  For example to use the same secret for
	CHAP and ARAP, simply change the value of XTA_SUP_CHAP_SEC to be
	equal to XTA_SUP_ARAP_SEC.

Access Lists
	You may now specify per user access lists for IP interfaces.  To do
	this, you must have a supplementary file (see above) and fill in
	the two fields for each user.  The access lists are requested as
	part of the SLIPON message.  TACACS is configured on the commserver
	to request access lists with the following config command:
		tacacs-server authenticate slip access-lists [ always ]
	In this case the commserver makes a normal SLIPON request, but it
	increments the minor version number in the version number field of
	the request packet.  The server must send a response with the
	version number set to the same value as the one received, the
	namelen field set to 0 and the pwlen field set to 
	sizeof(struct xta_slip_acl).  Then the appropriate xta_slip_acl
	structure is appended to the return packet.

ARAP and CHAP secrets
	WARNING: This is important!!  CHAP and ARAP secrets must be stored
	in clear text.  This is a result of the cryptography that is used.
	Make sure to provide for the security of this file!!!

	ARAP requests send an extended tacacs packet with the user name
	immediately following the xtacacstype structure and it's length is
	specified in the namelen field.  Following that are two ARAP
	challenges.  One from the remote client and one from the
	commserver.  Both are 8 bytes long and the pwlen value must be 16
	bytes.  Both challenge values are DES encrypted using the users
	secret and the resulting two values are sent back.  Both response
	values are 8 bytes long.  They are appended after the xtacacstype
	structure (in the respective order that they were recieved in).
	The version field must be the same as one in the received packet.
	The namelen must be set to 0 and the pwlen must be set to 16.

	CHAP requests come with a user name value with the length specified
	in the namelen field.  In the password field there is a single byte
	id value followed by a challenge.  The id is from the CHAP message
	that the commserver recieved, or is preparing to send.  The
	challenge value is a stream of bytes that the commserver recieved
	or is preparing to send.  The length of the challenge is pwlen - 1.
	(The -1 is for the id byte.)  TACACS must create a new stream of
	bytes that looks like:
		<id><user secret><challenge>
	and perform an MD5 hash of that stream.  The return packet must
	have the same version number that was received, namelen set to 0,
	pwlen set to 16 (the size of an MD5 hash) and the xtacacstype
	structure is immediately followed by the MD5 hash.  CHAP requests
	may arrive when a remote user is trying to authenticate to the
	commserver, or when the commserver has been asked to authenticate
	to the remote node.  In the latter case, the username in the
	request will be the name of the commserver.
