tacacs/draft-1

                         The TACACS+ Protocol
                             Version 1.78

Status of This Memo

  This memo provides information for the Internet community.  This memo
  does not specify an Internet standard of any kind.  Distribution of
  this memo is unlimited.

  This document is an Internet-Draft.  Internet-Drafts are working
  documents of the Internet Engineering Task Force (IETF), its areas,
  and its working groups.  Note that other groups may also distribute
  working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet- Drafts as reference
  material or to cite them other than as ``work in progress.''

  To learn the current status of any Internet-Draft, please check the
  ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  ftp.isi.edu (US West Coast).

Abstract

  TACACS+ provides access control for routers, network access servers
  and other networked computing devices via one or more centralized
  servers.  TACACS+ provides separate authentication, authorization and
  accounting services.  This document describes the protocol that is
  used by TACACS+.

  1.  Introduction

  The TACACS+ protocol is the latest generation of TACACS. TACACS is a
  simple UDP based access control protocol originally developed by BBN
  for the MILNET. Cisco has enhanced (extended) TACACS several times,
  and Cisco's implementation, based on the original TACACS, is referred

  to as XTACACS. The TACACS protocol is described in [].

  TACACS+ improves on TACACS and XTACACS by separating the functions of
  Authentication, Authorization and Accounting and by encrypting all
  traffic between the NAS and the daemon.  It allows for arbitrary
  length and content authentication exchanges which will allow any
  authentication mechanism to be utilized with TACACS+ clients.  It is
  extensible to provide for site customization and future development
  features, and it uses TCP to ensure reliable delivery. The protocol
  allows the TACACS+ client to request very fine grained access control
  and allows the daemon to respond to each component of that request.

  The separation of authentication, authorization and accounting is a
  fundamental component of the design of TACACS+. The distinction
  between them is very important so this document will address each one
  separately. It is important to note that TACACS+ provides for all
  three, but an implementation or configuration is not required to
  employ all three. Each one serves a unique purpose that alone is use-
  ful, and together can be quite powerful. A very important benefit to
  separating authentication from authorization is that authorization
  (and per-user profiles) can be a dynamic process. Instead of a one-
  shot user profile, TACACS+ can be integrated with other negotiations,
  such as a PPP negotiation, for far greater flexibility. The account-
  ing portion can serve to provide security auditing or accounting/
  billing services.

  TACACS+ uses TCP for its transport. The daemon should listen at port
  49 which is the "LOGIN" port assigned for the TACACS protocol. This
  port is reserved in the assigned numbers RFC for both UDP and TCP.
  Current TACACS and extended TACACS implementations use port 49.

  2.  Technical Definitions

  This section provides a few basic definitions that are applicable to
  this document.

Authentication

  Authentication is the action of determining who a user (or entity)
  is. Authentication can take many forms. Traditional authentication
  utilizes a name and a fixed password. Most computers work this way,
  and TACACS+ can also work this way. However, fixed passwords have
  limitations, mainly in the area of security. Many modern authentica-
  tion mechanisms utilize "one-time" passwords or a challenge-response
  query. TACACS+ is designed to support all of these, and should be
  powerful enough to handle any future mechanisms. Authentication gen-
  erally takes place when the user first logs in to a machine or
  requests a service of it.

  Authentication is not mandatory, it is a site configured option. Some
  sites do not require it. Others require it only for certain services
  (see authorization below). Authentication may also take place when a
  user attempts to gain extra privileges, and must identify themselves
  as someone who possesses the required information (passwords, etc.)
  for those privileges.

Authorization

  It is important to distinguish Authorization from Authentication.
  Authorization is the action of determining what a user is allowed to
  do. Generally authentication precedes authorization, but again, this
  is not required. An authorization request may indicate that the user
  is not authenticated (we don't know who they are). In this case it is
  up to the authorization agent to determine if an unauthenticated user
  is allowed the services in question.

  In TACACS+, authorization does not merely provide yes or no answers,
  but it may also customize the service for the particular user. Exam-
  ples of when authorization would be performed are: When a user first
  logs in and wants to start a shell, or when a user starts PPP and
  wants to use IP over PPP with a particular IP address. The TACACS+
  daemon might respond to these requests by allowing the service, but
  placing a time restriction on the login shell, or by requiring IP
  access lists on the PPP connection. For a list of authorization
  attributes, see the authorization section below.

Accounting

  Accounting is typically the third action after authentication and
  authorization. But again, neither authentication nor authorization
  are required. Accounting is the action of recording what a user is
  doing, and/or has done. Accounting in TACACS+ can serve two purposes:
  It may be used to account for services used, such as in a billing
  environment. It may also be used as an auditing tool for security
  services. To this end, TACACS+ supports three types of accounting
  records. Start records indicate that a service is about to begin.
  Stop records indicate that a service has just terminated, and Update
  records are intermediate notices that indicate that a service is
  still being performed. TACACS+ accounting records contain all the
  information used in the authorization records, and also contain
  accounting specific information such as start and stop times (when
  appropriate) and resource usage information. A list of accounting
  attributes is defined in the accounting section.

Session

  The concept of a session is used throughout this document. A TACACS+
  session is a single authentication sequence, a single authorization
  exchange, or a single accounting exchange.

  The session concept is important because a session identifier is used
  as a part of the encryption, and it is used by both ends to distin-
  guish between packets belonging to multiple sessions.

  Multiple sessions may be supported simultaneously and/or consecu-
  tively on a single TCP connection if both the daemon and client sup-
  port this.  If multiple sessions are not being multiplexed over a
  single tcp connection, a new connection should be opened for each
  TACACS+ session and closed at the end of that session. For accounting
  and authorization, this implies just a single pair of packets
  exchanged over the connection (the request and its reply). For
  authentication, a single session may involve an arbitrary number of
  packets being exchanged.

  The session is an operational concept that is maintained between the
  TACACS+ client and daemon. It does not necessarily correspond to a
  given user or user action.

NAS

  A NAS is a Network Access Server. This is any device that provides
  access services. Nowadays, a NAS is typically more than just a termi-
  nal server. Terminal servers usually provide a character mode front
  end and then allow the user to telnet or rlogin to another host. A
  NAS may also support protocol based access services and may support
  PPP, ARAP, LAT, XREMOTE, and others.

MUST

  This word means that the definition is an absolute requirement of the
  specification.

MUST NOT

  This phrase means that the definition is an absolute prohibition of
  the specification.

SHOULD

  This word, or the adjective "recommended", means that there may exist
  valid reasons in particular circumstances to ignore this item, but
  the full implications should be understood and carefully weighed

  before choosing a different course.

MAY

  This word, or the adjective "optional", means that this item is one
  of an allowed set of alternatives. An implementation which does not
  include this option MUST be prepared to interoperate with another
  implementation which does include the option.