tacacs/draft-5

  13.  Accounting

  TACACS+ accounting is very similar to authorization. The packet for-
  mat is also similar. There is a fixed portion and an extensible por-
  tion. The extensible portion uses all the same attribute-value pairs
  that authorization uses, and adds several more.

  13.1.  The account REQUEST packet body

        1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8

       +----------------+----------------+----------------+----------------+
       |      flags     |  authen_method |    priv_lvl    |  authen_type   |
       +----------------+----------------+----------------+----------------+
       | authen_service |    user len    |    port len    |  rem_addr len  |
       +----------------+----------------+----------------+----------------+
       |    arg_cnt     |   arg 1 len    |   arg 2 len    |      ...       |
       +----------------+----------------+----------------+----------------+
       |   arg N len    |    user ...
       +----------------+----------------+----------------+----------------+
       |   port ...
       +----------------+----------------+----------------+----------------+
       |   rem_addr ...
       +----------------+----------------+----------------+----------------+
       |   arg 1 ...
       +----------------+----------------+----------------+----------------+
       |   arg 2 ...
       +----------------+----------------+----------------+----------------+
       |   ...
       +----------------+----------------+----------------+----------------+
       |   arg N ...
       +----------------+----------------+----------------+----------------+

flags

  This holds bitmapped flags.

  TAC_PLUS_ACCT_FLAG_MORE     := 0x01 (deprecated)

  TAC_PLUS_ACCT_FLAG_START    := 0x02

  TAC_PLUS_ACCT_FLAG_STOP     := 0x04

  TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08

  All other fields are defined in the authorization and authentication
  sections above and have the same semantics.

  The following new attributes are defined for TACACS+ accounting only.
  When these attribute-value pairs are included in the argument list,
  they should precede any attribute-value pairs that are defined in the
  authorization section above.

Table 2: Accounting Attribute-value Pairs

task_id

  Start and stop records for the same event MUST have matching (unique)
  task_id's

start_time

  The time the action started (in seconds since the epoch, 12:00am Jan
  1 1970).

stop_time

  The time the action stopped (in seconds since the epoch.)

elapsed_time

  The elapsed time in seconds for the action. Useful when the device
  does not keep real time.

timezone

  The timezone abbreviation for all timestamps included in this packet.

event

  Used only when "service=system". Current values are "net_acct",
  "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change".
  These indicate system level changes. The flags field SHOULD indicate
  whether the service started or stopped.

reason

  Accompanies an event attribute. It describes why the event occurred.

bytes

  The number of bytes transferred by this action

bytes_in

  The number of input bytes transferred by this action

bytes_out

  The number of output bytes transferred by this action

paks

  The number of packets transferred by this action.

paks_in

  The number of input packets transferred by this action.

paks_out

  The number of output packets transferred by this action.

status

  The numeric status value associated with the action. This is a signed
  four (4) byte word in network byte order. 0 is defined as success.
  Negative numbers indicate errors. Positive numbers indicate non-error
  failures. The exact status values may be defined by the client.

err_msg

  An ascii string describing the status of the action.

  NOTE: All numeric values in an attribute-value string are provided as
  decimal ASCII numbers.

  13.2.  The accounting REPLY packet body

  The response to an accounting message is used to  indicate  that  the
  accounting   function  on  the  daemon  has  completed  and  securely
  committed the record. This provides  the  client  the  best  possible
  guarantee that the data is indeed logged.

        1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8  1 2 3 4 5 6 7 8

       +----------------+----------------+----------------+----------------+
       |         server_msg len          |            data len             |
       +----------------+----------------+----------------+----------------+
       |     status     |         server_msg ...
       +----------------+----------------+----------------+----------------+
       |     data ...
       +----------------+

status

  This is the return status. Values are:
  TAC_PLUS_ACCT_STATUS_SUCCESS    := 0x01

  TAC_PLUS_ACCT_STATUS_ERROR      := 0x02

  TAC_PLUS_ACCT_STATUS_FOLLOW     := 0x21

server_msg

  This is an ASCII string that may be presented to the user. The deci-
  sion to present this message is client specific.

data

  This is an ASCII string that may be presented on an administrative
  display, console or log. The decision to present this message is
  client specific.

  When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions
  to be taken and the contents of the data field are identical to the

  TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication.

  The daemon MUST terminate the session after sending a REPLY.

  The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start
  accounting message. Start messages should only be sent once when a
  task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is a
  stop record and that the task has terminated. The
  TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record.
  Update records are sent at the client's discretion when the task is
  still running.

  The START and STOP flags are mutually exclusive. When the WATCHDOG
  flag is set along with the START flag, it indicates that the update
  record is a duplicate of the original START record. If the START flag
  is not set, then this indicates a minimal record indicating only that
  task is still running. The STOP flag MUST NOT be set in conjunction
  with the WATCHDOG flag.

  14.  Compatibility between Minor Versions 0 and 1

  Whenever a TACACS+ daemon receives a packet with a minor_version that
  it does not support, it should return an ERROR status with the
  minor_version set to the supported value closest to the requested
  value.

  The changes between minor_version 0 and 1 all deal with the way that
  CHAP, ARAP and PAP authentications are handled.

  In minor_version 0, CHAP, ARAP and outbound PAP authentications were
  performed by the NAS sending a SENDPASS packet to the daemon. The
  SENDPASS requested a copy of the user's plaintext password so that
  the NAS could complete the authentication. The CHAP hashing and ARAP
  encryption were all performed on the NAS. Inbound PAP performed a
  normal LOGIN, sending the username in the START packet and then wait-
  ing for a GETPASS and sending the password in a CONTINUE packet.

  In minor_version 1, CHAP, ARAP and inbound PAP use LOGIN to perform
  inbound authentication and the exchanges use the data field so that
  the NAS only sends a single START packet and expects to receive a
  PASS or FAIL. SENDPASS has been deprecated and SENDAUTH introduced,
  so that the NAS can request authentication credentials for authenti-
  cating to a remote peer. SENDAUTH is only used for PPP when perform-
  ing outbound authentication.

  NOTE: Only those requests which have changed from their minor_version
  0 implementation (i.e. ARAP, CHAP and PAP) should use the new

  minor_version number of 1. All other requests (whose implementation
  has not changed) MUST continue to use the same minor_version number
  of 0 that they have always used.

  If a daemon or NAS implementation desires to provide support for
  minor_number 0 TACACS+ hosts, it MUST pay attention to the
  minor_version in the TACACS+ header (as it should anyway) and be
  prepared to support the SENDPASS operation.

  The removal of SENDPASS was prompted by security concerns, and imple-
  mentors should think very carefully about how they wish to provide
  this service. On a NAS, the minor_version 0 compatibility can be lay-
  ered such that higher layers only need to understand the
  minor_version 1 methodology, with the compatibility layer translating
  requests appropriately when contacting an older daemon.

  On a TACACS+ server, when detecting minor_number 0, the daemon should
  allow for PAP authentications that do not send the password in the
  data field, but instead expect to read the PAP password from a subse-
  quent CONTINUE packet.

  If the daemon supports SENDPASS, then it should be prepared to handle
  such requests for CHAP and ARAP and even PAP, when outbound authenti-
  cation takes place.

  15.  Notes to Implementors

  For those interested in integrating one-time password support into
  TACACS+ daemons, there are some subtleties to consider.  TACACS+ is
  designed to make this straightforward, but two cases require some
  extra care.

  One-time password support with ARAP and PPP's CHAP authentication
  protocols is NOT straightforward, but there are work arounds. The
  problem lies in the nature of ARAP and CHAP authentication. Both
  employ a challenge-response protocol that requires a copy of the
  cleartext password to be stored at both ends. Unfortunately, due to
  their cryptographic nature, one-time password systems can rarely pro-
  vide the cleartext version of the next password.

  A simple workaround is to have the user enter their username as a
  combination of the username and the one-time password, separated by a
  special character, and a fixed password can be used in the password
  field. The fixed password can be assigned on a per user basis or as a
  single site-wide password.

  For the separator character, Cisco Systems has been using the `*'

  (asterisk) character. After some deliberation, it was decided that it
  was the least likely character to be found in a username.