rfc8907xml2.original.xml   rfc8907.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes" ?>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes" ?>
<rfc category="info" docName="draft-ietf-opsawg-tacacs-18" ipr="pre5378Trust2009
02">
<front>
<title>
The TACACS+ Protocol
</title>
<author initials="T." surname="Dahm" fullname="Thorsten Dahm">
<organization>Google Inc</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street
>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<phone />
<email>thorstendlux@google.com</email>
<uri />
</address>
</author>
<author initials="A." surname="Ota" fullname="Andrej Ota">
<organization>Google Inc</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street
>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<phone />
<email>andrej@ota.si</email>
<uri />
</address>
</author>
<author initials="D.C." surname="Medway Gash" fullname="Douglas C
. Medway Gash">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>dcmgash@cisco.com</email>
<uri />
</address>
</author>
<author initials="D." surname="Carrel" fullname="David Carrel"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8907" category="info"
<organization>vIPtela, Inc.</organization> docName="draft-ietf-opsawg-tacacs-18" consensus="true" ipr="pre5378Trust20
0902"
obsoletes="" updates="" submissionType="IETF" xml:lang="en"
tocInclude="true" symRefs="true" version="3" sortRefs="true">
<address> <front>
<postal>
<street>1732 North First St.</street>
<city>San Jose</city>
<region>CA</region>
<code>95112</code>
<country>US</country>
</postal>
<email>dcarrel@viptela.com</email>
<uri />
</address>
</author>
<author initials="L." surname="Grant" fullname="Lol Grant"> <title abbrev="TACACS+">The Terminal Access Controller Access-Control System
<address> Plus (TACACS+) Protocol
<email>lol.grant@gmail.com</email> </title>
</address> <seriesInfo name="RFC" value="8907"/>
</author> <author initials="T." surname="Dahm" fullname="Thorsten Dahm">
<organization>Google Inc.</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>United States of America</country>
</postal>
<phone/>
<email>thorstendlux@google.com</email>
<uri/>
</address>
</author>
<author initials="A." surname="Ota" fullname="Andrej Ota">
<organization>Google Inc</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>United States of America</country>
</postal>
<phone/>
<email>andrej@ota.si</email>
<uri/>
</address>
</author>
<author initials="D.C." surname="Medway Gash" fullname="Douglas C. Medway Ga
sh">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>United States of America</country>
</postal>
<email>dcmgash@cisco.com</email>
<uri/>
</address>
</author>
<date day="20" month="March" year="2020" /> <author initials="D." surname="Carrel" fullname="David Carrel">
<area>Operations</area> <organization>IPsec Research</organization>
<workgroup>Operations</workgroup> <address>
<keyword>TACACS+</keyword>
<keyword>Protocol</keyword>
<abstract>
<t>This document describes the Terminal Access Controller
Access-Control System Plus (TACACS+)
protocol which is widely deployed today to provid
e Device Administration for routers, network
access
servers and
other networked computing devices via
one or more
centralized servers.
</t>
</abstract>
</front> <email>carrel@ipsec.org</email>
<uri/>
</address>
</author>
<author initials="L." surname="Grant" fullname="Lol Grant">
<address>
<email>lol.grant@gmail.com</email>
</address>
</author>
<date month="September" year="2020"/>
<area>Operations</area>
<workgroup>Operations</workgroup>
<keyword>TACACS+</keyword>
<keyword>Protocol</keyword>
<abstract>
<t>This document describes the Terminal Access Controller Access-Control
System Plus (TACACS+) protocol, which is widely deployed today to provide
Device Administration for routers, network access servers, and other
networked computing devices via one or more centralized servers.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>This document describes the Terminal Access Controller Access-Control
System Plus (TACACS+) protocol. It was conceived initially as a general
Authentication, Authorization, and Accounting (AAA) protocol. It is
widely deployed today but is mainly confined for a specific subset of
AAA called Device Administration, which includes authenticating access to
network
devices, providing central authorization of operations, and auditing of
those operations.</t>
<middle> <t>
<section anchor="Introduction" title="Introduction"> A wide range of TACACS+ clients and servers is already deployed in the
<t>This document describes the Terminal Access Controller field. The TACACS+ protocol they are based on is defined in a document
Access-Control System Plus (TACACS+) protocol. It that was originally intended for IETF publication, but was never
was conceived initially as a general Authenticati standardized. The document is known as "The Draft" <xref target="THE-DRA
on, Authorization FT"
and Accounting (AAA) protocol. It is widely deplo format="default"/>.
yed today but is mainly confined for a specific subset of AAA: Device </t>
Administration, that is: <t> This Draft was a product of its time and did not address all of the
authenticating access to network devices, providi key security concerns that are considered when designing modern
ng standards. Therefore, deployment must be executed with care. These
central concerns are addressed in <xref target="TACACSSecurity"
authorization of format="default"/>.
operations, and audit of those operations.</t> </t>
<t> <t>
A wide range of TACACS+ clients and servers are a The primary intent of this informational document is to clarify the
lready subset of "The Draft", which is common to implementations supporting
deployed Device Administration. It is intended that all implementations that
in conform to this document will conform to "The Draft". However, it is
the field. The TACACS+ protocol they are not intended that all implementations that conform to "The Draft" will
based on is defined in a conform to this document. The following features from "The Draft" have
draft document that was been removed:
originally intended for IETF publication, but was </t>
never standardized. <ul empty="false" spacing="normal">
The draft document <li>This document officially removes SENDPASS for security
is known as reasons.</li>
<xref target="TheDraft">`The Draft'</xref>.
</t>
<t> This Draft was a product of its time, and did not add
ress all of the
key security concerns which are
considered when designing modern
standards. Deployment must therefore be executed
with care. These concerns are addressed
in the
<xref target="TACACSSecurity">security section</x
ref>.
</t>
<t>
The primary intent of this informational document
is to clarify the
subset of `The Draft' which is common to implemen
tations supporting
Device Administration.
It is intended that all implementations which
conform to this
document will conform to `The Draft'. However, it
is not intended that all
implementations which conform to 'The Draft' will
conform to this
document. The following features from `The Draft'
have been removed:
<list>
<t>This document officially remov
es SENDPASS for
security
reasons.</t>
<t>The normative description of L
egacy features
such as
ARAP and
outbound authentication h
as been removed.</t>
<t>The Support for forwarding to
an alternative daemon
(TAC_PLUS_AUTHEN_STATUS_F
OLLOW) has been deprecated.</t>
</list>
</t>
<t>The TACACS+ protocol allows for arbitrary
length and
content
authentication
exchanges, to
support alternative authentication
mechanisms. 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
fine-grained
access
control and
allows
the server to
respond to each
component of that request.</t>
<t> <li>The normative description of legacy features such as the Apple
The separation of authentication, authorization a Remote Access Protocol (ARAP) and outbound authentication has been
nd removed.</li>
accounting is <li>The Support for forwarding to an alternative daemon
a (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated.</li>
key element of the design of </ul>
TACACS+ protocol. Essentially it makes <t>The TACACS+ protocol allows for arbitrary length and content
TACACS+ a suite of three protocols. authentication exchanges to support alternative authentication
This document will mechanisms. It is extensible to provide for site customization and
address each future development features, and it uses TCP to ensure reliable
one delivery. The protocol allows the TACACS+ client to request fine-grained
in separate sections. Although TACACS+ defines access control and allows the server to respond to each component of
all that request.</t>
three, <t>
an The separation of authentication, authorization, and accounting is a
implementation or deployment is not required key element of the design of TACACS+ protocol. Essentially, it makes
to TACACS+ a suite of three protocols. This document will address each
employ all three. one in separate sections. Although TACACS+ defines all three, an
Separating the elements is useful for Device Admi implementation or deployment is not required to employ all three.
nistration Separating the elements is useful for the Device Administration use
use case, case, specifically, for authorization and accounting of individual comman
specifically, for authorization of individual com ds in a
mands in a session. Note that there is no provision made at the protocol level
session. to associate authentication requests with authorization requests.
Note that there is no provision </t>
made at the protocol level for
association of an
authentication to authorization requests.
</t>
</section> </section>
<section anchor="Conventions" numbered="true" toc="default">
<name>Conventions</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<section anchor="Conventions" title="Conventions"> </section>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", <section anchor="TechnicalDefinitions" numbered="true" toc="default">
"SHALL <name>Technical Definitions</name>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT <t>This section provides a few basic definitions that are applicable to
RECOMMENDED", this document.</t>
"MAY", and "OPTIONAL" in this document are to be <section anchor="Client" numbered="true" toc="default">
interpreted as <name>Client</name>
described in BCP 14 [RFC2119] [RFC8174] when, and <t>The client is any device that initiates TACACS+ protocol requests
only when, they to mediate access, mainly for the Device Administration use case.</t>
appear in all capitals, as shown here. </section>
</t> <section anchor="Server" numbered="true" toc="default">
</section> <name>Server</name>
<t>The server receives TACACS+ protocol requests and replies
according to its business model in accordance with the flows defined
in this document.</t>
</section>
<section anchor="Packet" numbered="true" toc="default">
<name>Packet</name>
<section anchor="TechnicalDefinitions" title="Technical Definitio <t>All uses of the word packet in this document refer to TACACS+
ns"> protocol data units unless explicitly noted otherwise. The informal
<t>This section provides a few basic definitions that are term "packet" has become an established part of the definition.</t>
applicable </section>
to this document</t> <section anchor="Connection" numbered="true" toc="default">
<section anchor="Client" title="Client"> <name>Connection</name>
<t>The client is any device which initiates TACAC <t>
S+ protocol TACACS+ uses TCP for its transport. TCP Server port 49 is allocated
requests by IANA for TACACS+ traffic.
to mediate access, mainly for the Device </t>
Administration use case.</t> </section>
</section> <section anchor="Session" numbered="true" toc="default">
<section anchor="Server" title="Server"> <name>Session</name>
<t>The server receives TACACS+ protocol requests, <t>
and The concept of a session is used
replies throughout this document. A TACACS+
according to its business model, in accor
dance
with the flows
defined
in this document.</t>
</section>
<section anchor="Packet" title="Packet">
<t>All uses of the word packet in this document r
efer to
TACACS+
protocol data units unless explicitly not
ed
otherwise. The informal
term "Packet" has become an established p
art of the definition.</t>
</section>
<section anchor="Connection" title="Connection">
<t>
TACACS+ uses TCP for its transport.
TCP Server port 49 is
allocated by IANA
for
TACACS+ traffic.
</t>
</section>
<section anchor="Session" title="Session">
<t>
The concept of a session is used througho
ut this
document. A
TACACS+
session is a single authentication session is a single authentication
sequence, a single sequence, a single authorization
authorization exchange, or a single accounting
exchange, or a single exchange.
accounting exchange. </t>
</t> <t>
<t> An accounting and authorization
An accounting and authorization session w session will consist of a single pair
ill consist of packets (the request and its
of a single reply). An authentication session may
pair of packets (the request and its involve an arbitrary number of packets
reply). An authentication being exchanged. The session is an
session may involve an operational concept that is maintained
arbitrary number of packets being exchang between the TACACS+ client and
ed. server. It does not necessarily
The correspond to a given user or user
session is an operational concept that is action.
maintained </t>
between </section>
the <section anchor="TreatmentOfEnumeratedValues" numbered="true" toc="default
TACACS+ client and server. It does not ">
necessarily correspond to <name>Treatment of Enumerated Protocol Values</name>
a <t>
given user or user action. This document describes various
</t> enumerated values in the packet header
</section> and the headers for specific packet
<section anchor="TreatmentOfEnumeratedValues" title="Trea types. For example, in the
tment of Enumerated Protocol Values"> authentication start packet type, this
<t> document defines the action field with
This document describes various enumerate three values: TAC_PLUS_AUTHEN_LOGIN,
d values in the packet TAC_PLUS_AUTHEN_CHPASS, and
header TAC_PLUS_AUTHEN_SENDAUTH.
and the headers for specific packet types </t>
. For example, in <t>If the server does not implement one of the defined options in a
the packet that it receives, or it encounters an option that is not listed
Authentication start packet type, this do in this document for a header field, then it should respond with an
cument defines the ERROR and terminate the session. This will allow the client to try a
action different option.
field with three values TAC_PLUS_AUTHEN_L </t>
OGIN, <t>
TAC_PLUS_AUTHEN_CHPASS and TAC_PLUS_AUTHE
N_SENDAUTH.
</t>
<t>If the server does not implement one of the de
fined options in a
packet that it receives, or it encounters
an option that is not
listed in this
document for a header field, then it shou
ld respond
with an ERROR and terminate the session.
This
will allow the client
to try a different option.
</t>
<t>
If an error occurs but the type of the If an error occurs but the type of the
incoming packet incoming packet cannot be determined,
cannot be a packet with the identical cleartext
determined, a packet header but with a sequence number
with the incremented by one and the length set
identical cleartext header to zero <bcp14>MUST</bcp14> be
but returned to indicate an error.
with a </t>
sequence number incremented by one and th </section>
e <section anchor="TextEncoding" numbered="true" toc="default">
length set <name>Treatment of Text Strings</name>
to <t>The TACACS+ protocol makes extensive use of text strings. "The
zero Draft" intended that these strings would be treated as byte arrays
MUST be where each byte would represent a US-ASCII character.
returned to indicate an </t>
error.
</t>
</section>
<section anchor="TextEncoding" title="Treatment of Text S
trings">
<t>The TACACS+ protocol makes extensive use of te
xt strings.
The
original draft intended that these string
s would be treated as
byte
arrays where each byte would represent a
US-ASCII character.
</t>
<t>More recently, server implementations have bee
n extended to
interwork with external identity services
,
and so a more nuanced
approach is needed.
Usernames MUST be encoded and handled usi
ng the
UsernameCasePreserved Profile specified i
n
<xref target="RFC8265">RFC 8265</xref>. T
he security
considerations in Section 8 of that RFC a
pply.
</t>
<t>Where specifically mentioned, data fields cont
ain arrays of
arbitrary bytes as required for protocol
processing. These are not
intended to be made visible through user
interface to users.</t>
<t>
All other text fields in TACACS+ MUST be
treated as printable byte
arrays
of US-ASCII as defined by
<xref target="RFC0020">RFC 20</xref>.
The term "printable" used
here means the fields MUST exclude the
"Control Characters" defined in section
5.2 of
<xref target="RFC0020">RFC 20</xref>.
</t>
</section> <t>More recently, server implementations have been extended to
</section> interwork with external identity services, and so a more nuanced
<section anchor="TACACSPacketsSessions" title="TACACS+ Packets an approach is needed. Usernames <bcp14>MUST</bcp14> be encoded and
d Sessions"> handled using the UsernameCasePreserved Profile specified in <xref
<section anchor="TheTACACSPacketHeader" title="The TACACS target="RFC8265" format="default"/>. The security
+ Packet Header"> considerations in <xref target="RFC8265" sectionFormat="of"
<t> section="8" /> apply.
All TACACS+ packets begin with the follow </t>
ing <t>Where specifically mentioned, data fields contain arrays of
12-byte arbitrary bytes as required for protocol processing. These are not
header. The intended to be made visible through user interface to users.</t>
header describes the remainder <t>
of All other text fields in TACACS+
the <bcp14>MUST</bcp14> be treated as
packet: printable byte arrays of US-ASCII as
</t> defined by <xref target="RFC0020"
<figure> format="default"/>. The term
<artwork><![CDATA[ "printable" used here means the fields
<bcp14>MUST</bcp14> exclude the
"Control Characters" defined in <xref
target="RFC0020" sectionFormat="of"
section="5.2"/>.
</t>
</section>
</section>
<section anchor="TACACSPacketsSessions" numbered="true" toc="default">
<name>TACACS+ Packets and Sessions</name>
<section anchor="TheTACACSPacketHeader" numbered="true" toc="default">
<name>The TACACS+ Packet Header</name>
<t>
All TACACS+ packets begin with the
following 12-byte header. The header
describes the remainder of the packet:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
|major | minor | | | | |major | minor | | | |
|version| version| type | seq_no | flags | |version| version| type | seq_no | flags |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | | |
| session_id | | session_id |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | | |
| length | | length |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
]]></artwork> ]]></artwork>
</figure> <t>The following general rules apply to all TACACS+ packet types:
<t>The </t>
following general rules apply to all <ul empty="false" spacing="normal">
TACACS+ packet <li>
types: To signal that any variable-length data fields are unused, the
</t> corresponding length values are set to zero. Such fields
<t> <bcp14>MUST</bcp14> be ignored, and treated as if not present.
<list> </li>
<t> <li>
- To signal that any vari The lengths of data and message fields in a packet are specified by
able length data fields are their corresponding length field (and are not null terminated).
unused, </li>
the corresponding length
values are set to zero. Such fields MUST be ignored, <li>
and treated as if not pre All length values are unsigned and in network byte order.
sent. </li>
</t> </ul>
<t>
- the lengths of data and <t>
message fields in a packet are
specified by their corres
ponding length fields, (and are not null
terminated.)
</t>
<t>
- All length values are u
nsigned and in
network
byte
order.
</t>
</list>
</t>
<t>
major_version major_version
</t> </t>
<t> <ul empty="true">
<li>
<t>
This is the major TACACS+ version number. This is the major TACACS+ version number.
</t> </t>
<t> </li>
<list> </ul>
<t>
<ul empty="true" spacing="normal">
<li>
TAC_PLUS_MAJOR_VER := 0xc TAC_PLUS_MAJOR_VER := 0xc
</t> </li>
</list> </ul>
</t> <t>
<t>
minor_version minor_version
</t> </t>
<t> <ul empty="true">
The minor TACACS+ version number. <li>
</t> <t>
<t> This is the minor TACACS+ version number.
<list> </t>
<t> </li>
<li>
TAC_PLUS_MINOR_VER_DEFAUL T := 0x0 TAC_PLUS_MINOR_VER_DEFAUL T := 0x0
</t> </li>
<t> <li>
TAC_PLUS_MINOR_VER_ONE := 0x1 TAC_PLUS_MINOR_VER_ONE := 0x1
</t> </li>
</list> </ul>
</t> <t>
<t>
type type
</t> </t>
<t> <ul empty="true">
This is the packet type. Options are: <li>
</t> <t>
<t> This is the packet type.
<list> </t>
<t> </li>
<li>Options are:
</li>
<li>
TAC_PLUS_AUTHEN := 0x01 ( Authentication) TAC_PLUS_AUTHEN := 0x01 ( Authentication)
</t> </li>
<t> <li>
TAC_PLUS_AUTHOR := 0x02 ( Authorization) TAC_PLUS_AUTHOR := 0x02 ( Authorization)
</t> </li>
<t> <li>
TAC_PLUS_ACCT := 0x03 (Ac counting) TAC_PLUS_ACCT := 0x03 (Ac counting)
</t> </li>
</list> </ul>
</t> <t>
<t>
seq_no seq_no
</t> </t>
<t> <ul empty="true">
This is the sequence number of the curren <li>
t packet. The first <t>
packet in a session This is the sequence number of the current packet. The first packet in
MUST have the a session <bcp14>MUST</bcp14> have the sequence number 1, and each
sequence subsequent packet will increment the sequence number by one. TACACS+
number clients only send packets containing odd sequence numbers, and TACACS+
1 servers only send packets containing even sequence numbers.
and each subsequent </t>
packet will increment the sequence </li>
number by
one. <li>
TACACS+ Clients only <t>
send The sequence number must never wrap, i.e., if the sequence number 2<sup>8
packets containing odd </sup>-1
sequence is ever reached, that session must terminate and be restarted with a
numbers, sequence number of 1.
and </t>
TACACS+ servers only </li>
send </ul>
packets
containing <t>
even sequence flags
numbers. </t>
</t> <ul empty="true">
<t> <li>
The sequence number must never wrap i.e. <t>
if the This field contains various bitmapped flags.
sequence number </t>
2^8-1 </li>
is <li>
ever reached, that session <t>
must terminate and be restarted The flag bit:
with a </t>
sequence number </li>
of 1.
</t> <li>
<t>
flags <t>
</t> TAC_PLUS_UNENCRYPTED_FLAG := 0x01
<t> </t>
This field contains various bitmapped fla </li>
gs.
</t> <li>
<t> <t>
The flag bit: This flag indicates that the sender
</t> did not obfuscate the body of the
<t> packet. This option <bcp14>MUST
TAC_PLUS_UNENCRYPTED_FLAG := 0x01 NOT</bcp14> be used in production. The
</t> application of this flag will be
<t> covered in "Security Considerations"
This flag indicates that the sender did n (<xref target="TACACSSecurity"
ot obfuscate the body of format="default"/>).
the packet. This option MUST NOT be used </t>
in production. The application of this flag will be covered in the </li>
security <li>
<xref target="TACACSSecurity">section</xr <t>
ef>. This flag <bcp14>SHOULD</bcp14> be clear in all
</t> deployments. Modern network traffic tools support encrypted
<t> traffic when configured with the shared secret (see "Shared Secre
This flag SHOULD be clear in all deployme ts" (<xref
nts. Modern target="SharedSecrets" />)), so obfuscated mode can and
network <bcp14>SHOULD</bcp14> be used even during test.
traffic tools support </t>
encrypted traffic when </li>
configured with
the <li>
shared secret (see section <t>
below), so The single-connection flag:
obfuscated mode can and SHOULD </t>
be </li>
used even during test.
</t> <li>
<t>
The single-connection flag: <t>
</t> TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04
<t>
TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 </t>
</t> </li>
<t> <li>
This flag is used to allow a client and s <t>
erver to This flag is used to allow a client and server to negotiate
negotiate <xref target="SingleConnectMode "Single Connection Mode" (<xref target="SingleConnectMode"
">Single format="default"/>).
Connection Mode</xref>. </t>
</t> </li>
<t> <li>
All other bits MUST be ignored when readi <t>
ng, and SHOULD be set to All other bits <bcp14>MUST</bcp14> be ignored when reading,
zero when writing. and <bcp14>SHOULD</bcp14> be set to zero when writing.
</t> </t>
<t> </li>
session_id </ul>
</t> <t>
<t> session_id
The Id for this TACACS+ session. This fie </t>
ld does not change <ul empty="true">
for the <li>
duration of the TACACS+ <t>
session. This number MUST be generated by The Id for this TACACS+ session. This field does not change
a for the duration of the TACACS+ session. This number
cryptographically strong random number ge <bcp14>MUST</bcp14> be generated by a cryptographically strong
neration method. Failure random number generation method. Failure to do so will
to do so will compromise security of the compromise security of the session. For more details, refer to
session. For more details <xref target="RFC4086" format="default"/>.
refer to </t>
<xref target="RFC4086">RFC 4086</xref>. </li>
</t> </ul>
<t>
<t>
length length
</t> </t>
<t> <ul empty="true">
The total length of the packet body (not <li> <t>
including The total length of the packet body (not including
the header). the header). Implementations <bcp14>MUST</bcp14> allow control over
</t> maximum packet sizes accepted by TACACS+ Servers.
</section> The recommended maximum packet size is 2<sup>16</sup>.
<section anchor="TheTACACSPacketBody" title="The TACACS+
Packet Body"> </t>
<t> </li>
The TACACS+ body types are defined in the </ul>
packet </section>
header. The <section anchor="TheTACACSPacketBody" numbered="true" toc="default">
next <name>The TACACS+ Packet Body</name>
sections <t>
of this document will address The TACACS+ body types are defined in
the contents of the the packet header. The next sections
different of this document will address the
TACACS+ contents of the different TACACS+
bodies. bodies.
</t> </t>
</section> </section>
<section anchor="SingleConnectMode" title="Single Connect <section anchor="SingleConnectMode" numbered="true" toc="default">
ion Mode"> <name>Single Connection Mode</name>
<t> <t>
Single Connection Mode is intended to imp Single Connection Mode is intended to
rove performance where there is a lot of traffic between a client and a server b improve performance where there is a
y lot of traffic between a client and a
allowing the client to multiplex multiple server by allowing the client to
session on a single TCP multiplex multiple sessions on a
connection. single TCP connection.
</t> </t>
<t> <t>
The packet header contains the TAC_PLUS_S The packet header contains the
INGLE_CONNECT_FLAG used TAC_PLUS_SINGLE_CONNECT_FLAG used by
by the client and the client and server to negotiate the
server to negotiate the use of Single Con use of Single Connection Mode.
nect </t>
Mode. <t>
</t> The client sets this flag to indicate
<t> that it supports multiplexing TACACS+
The client sets this flag, to indicate th sessions over a single TCP
at it connection. The client <bcp14>MUST
supports NOT</bcp14> send a second packet on a
multiplexing TACACS+ sessions over a sing connection until single-connect status
le
TCP
connection. The
client MUST NOT send a second
packet on a connection until
single-connect status
has been established. has been established.
</t> </t>
<t> <t>
To indicate it will support To indicate it will support Single
Single Connection Mode, the server Connection Mode, the server sets this
sets flag in the first reply packet in
this flag in the first reply packet in re response to the first request from a
sponse to the first client. The server may set this flag
request from a client. The server even if the client does not set it,
may set this flag even if the but the client may ignore the flag and
client close the connection after the session
does not set it, but the client
may ignore the flag and close
the
connection after the session
completes. completes.
</t> </t>
<t> <t>
The flag is only relevant for the first t The flag is only relevant for the
wo packets first two packets on a connection, to
on a allow the client and server to
connection, to allow the client and serve establish Single Connection Mode. No
r to provision is made for changing Single
establish Single Connection Mode after the first two
Connection Mode. No provision is made for packets; the client and server
changing Single Connection <bcp14>MUST</bcp14> ignore the flag
Mode after the first two packets: the cli after the second packet on a
ent and server MUST ignore connection.
the flag after the second packet on a con </t>
nection. <t>
</t> If Single Connection Mode has not been
<t> established in the first two packets
If of a TCP connection, then both the
single Connection Mode has not been client and the server close the
established in connection at the end of the first
the
first two
packets of a TCP connection, then both th
e client and the server
close the connection at the end of the fi
rst
session. session.
</t> </t>
<t>The client negotiates Single Connection Mode t <t>The client negotiates Single Connection Mode to improve
o improve efficiency. The server may refuse to allow Single Connection Mode for
efficiency. The server may refuse to allo the client. For example, it may not be appropriate to allocate a
w Single Connection Mode long-lasting TCP connection to a specific client in some deployments.
for the client. For example, it may not b Even if the server is configured to permit Single Connection Mode for
e appropriate a specific client, the server may close the connection. For example, a
to allocate a server <bcp14>MUST</bcp14> be configured to time out a Single
long-lasting TCP connection to a specific Connection Mode TCP connection after a specific period of inactivity
client in some to preserve its resources. The client <bcp14>MUST</bcp14> accommodate
deployments. such closures on a TCP session even after Single Connection Mode has
Even if the server is configured to permi been established.</t>
t single <t>The TCP connection underlying the Single Connection Mode will close
Connection Mode eventually either because of the timeout from the server or from an
for a specific client, the server may clo intermediate link. If a session is in progress when the client
se the detects disconnect, then the client should handle it as described in
connection. For "Session Completion" (<xref target="SessionCompletion" format="default"/
example: a server MUST be >). If a session is
configured to time out a not in progress, then the client will need to detect this and restart
Single Connection the Single Connection Mode when it initiates the next session.
Mode TCP Connection after </t>
a specific period of </section>
inactivity to <section anchor="SessionCompletion" numbered="true" toc="default">
preserve its resources. The <name>Session Completion</name>
client MUST accommodate
such closures
on
a TCP session even after
Single Connection Mode has
been
established.</t>
<t>The TCP connection underlying the Sing
le Connection Mode will close eventually, either because of the timeout from the
server or from an intermediate link.
If a session is in progress when the clie
nt detects disconnect then the client should handle it as described in <xref tar
get="SessionCompletion"/>.
If a session is not in progress, then the
client will need to detect this, and restart the single connection mode when th
e it initiates the next session.
</t>
</section>
<section anchor="SessionCompletion" title="Session Comple
tion">
<t>The REPLY packets defined for the packets type
s in the sections
below (Authentication, Authorization and
Accounting) contain a
status field.
The complete set of options for this fiel
d depend upon
the packet
type, but
all three REPLY packet types define value
s
representing
PASS, ERROR and FAIL, which indicate the
last packet of
a
regular session (one which is not aborted
).</t>
<t>The server responds with a PASS or a FAIL to i
ndicate that the
processing of the request completed and t
he client can apply the
result (PASS or FAIL) to control the exec
ution of the action which
prompted the
request to be sent to the server.</t>
<t>The server responds with an ERROR to indicate
that the processing
of the request did not complete. The clie
nt cannot apply the
result and it MUST behave as if the serve
r could not be connected
to. For
example, the client tries alternative met
hods, if they are
available,
such as sending the request to a backup s
erver, or using
local
configuration to determine whether the ac
tion which prompted
the
request should be executed.</t>
<t>
Refer to
<xref target="AbortinganAuthenticationSes
sion"/>
on Aborting Authentication Sessions for d
etails on handling
additional status options.
</t>
<t>When the session is complete, then the TCP con <t>The REPLY packets defined for the packet types in the sections
nection should be below (Authentication, Authorization, and Accounting) contain a status
handled as follows, according to whether field. The complete set of options for this field depend upon the
Single Connection Mode was packet type, but all three REPLY packet types define values
negotiated:</t> representing PASS, ERROR, and FAIL, which indicate the last packet of a
<t>If Single Connection Mode was not negotiated, regular session (one that is not aborted).</t>
then the connection <t>The server responds with a PASS or a FAIL to indicate that the
should be closed</t> processing of the request completed and that the client can apply the
<t> result (PASS or FAIL) to control the execution of the action that
If Single Connection Mode was enabled, th prompted the request to be sent to the server.</t>
en the connection SHOULD <t>The server responds with an ERROR to indicate that the processing
be left open (see of the request did not complete. The client cannot apply the result,
<xref target="SingleConnectMode"/>), but and it <bcp14>MUST</bcp14> behave as if the server could not be
may still be closed after a timeout period connected to. For example, the client tries alternative methods, if
to preserve they are available, such as sending the request to a backup server or
deployment resources. using local configuration to determine whether the action that
</t> prompted the request should be executed.</t>
<t> <t>
If Single Connection Mode was enabled, bu Refer to "Aborting an Authentication Session" (<xref target="AbortinganAu
t an ERROR occurred due to thenticationSession"
connection issues (such as an incorrect s format="default"/>) for details
ecret, see on handling additional status options.
<xref target="Obfuscation"/>), then any f </t>
urther new <t>When the session is complete, the TCP connection should be
sessions MUST NOT be accepted on the handled as follows, according to whether Single Connection Mode was
connection. negotiated:</t>
If there are any sessions that have alrea <ul>
dy been <li>
established then they <t>If Single Connection Mode was not negotiated, then the connection
MAY be completed. Once all active session should be closed.</t>
s are </li>
completed then the <li>
connection MUST be closed. <t>
</t>
<t>It is recommended that client implementations
provide robust
schemes for dealing with servers which ca
nnot be connected to.
Options
include providing a list of servers for r
edundancy, and an
option for
a local fallback configuration if no serv
ers can be
reached. Details
will be implementation specific.</t>
<t>
The client should manage connections and
handle the case of a
server
which establishes a connection, but does
not respond. The
exact
behavior is implementation specific. It i
s recommended that
the
client should close the connection after
a configurable timeout.
</t>
</section> If Single Connection Mode was enabled,
<section anchor="Obfuscation" title="Data Obfuscation"> then the connection
<bcp14>SHOULD</bcp14> be left open
(see "Single Connection Mode" (<xref targ
et="SingleConnectMode"
format="default"/>)) but may still be
closed after a timeout period to
preserve deployment resources.
</t>
</li>
<li>
<t>
If Single Connection Mode was enabled,
but an ERROR occurred due to
connection issues (such as an
incorrect secret (see <xref
target="Obfuscation"
format="default"/>)), then any further
new sessions <bcp14>MUST NOT</bcp14>
be accepted on the connection. If
there are any sessions that have
already been established, then they
<bcp14>MAY</bcp14> be completed. Once
all active sessions are completed, then
the connection <bcp14>MUST</bcp14> be
closed.
</t>
</li>
</ul>
<t>It is recommended that client implementations provide robust
schemes for dealing with servers that cannot be connected to. Options
include providing a list of servers for redundancy and an option for
a local fallback configuration if no servers can be reached. Details
will be implementation specific.</t>
<t>
The client should manage connections
and handle the case of a server that
establishes a connection but does not
respond. The exact behavior is
implementation specific. It is
recommended that the client
close the connection after a
configurable timeout.
</t>
</section>
<section anchor="Obfuscation" numbered="true" toc="default">
<name>Data Obfuscation</name>
<t>
The body of packets may be
obfuscated. The following sections
describe the obfuscation method that
is supported in the protocol. In "The
Draft", this process was actually
referred to as Encryption, but the
algorithm would not meet modern
standards and so will not be termed
as encryption in this document.
</t>
<t>
The obfuscation mechanism relies on a
secret key, a shared secret value that
is known to both the client and the
server. The secret keys
<bcp14>MUST</bcp14> remain secret.
</t>
<t>Server implementations <bcp14>MUST</bcp14> allow a unique secret
key to be associated with each client. It is a site-dependent decision
as to whether or not the use of separate keys is appropriate.
</t>
<t>
The flag field <bcp14>MUST</bcp14> be configured with
TAC_PLUS_UNENCRYPTED_FLAG set to 0 so that the packet body is obfuscated by
XORing it bytewise with a pseudo-random pad:
</t>
<ul empty="true">
<li>
<t>ENCRYPTED {data} = data <sup>pseudo_pad</sup>
</t>
</li>
</ul>
<t>The packet body can then be de-obfuscated by XORing it bytewise
with a pseudo-random pad.
</t>
<ul empty="true">
<li>
<t>
data = ENCRYPTED {data} <sup>pseudo_pad</
sup>
</t>
</li>
</ul>
<t>
The pad is generated by concatenating
a series of MD5 hashes (each 16 bytes
long) and truncating it to the length
of the input data.
<t>
The body of packets may be obfuscated. Th
e
following sections
describe
the obfuscation
method that is supported in the protocol.
In
'The Draft' this process was actually ref
erred to as Encryption,
but the algorithm would not meet modern s
tandards, and so will not
be termed as encryption in this document.
</t>
<t>
The obfuscation mechanism relies on a sec
ret
key, a shared secret
value
that is known to both the
client
and the
server.
The secret keys
MUST remain secret.
</t>
<t>Server implementations MUST allow a unique sec
ret key to be
associated with each client. It
is a
site-dependent decision as to
whether the
use of
separate keys is
appropriate.
</t>
<t>
The flag field MUST be configured with th
e following bit as follows:
</t>
<t>
TAC_PLUS_UNENCRYPTED_FLAG = 0x0
</t>
<t>
So that the packet body is obfuscated by
XOR-ing it
byte-wise
with a pseudo-random pad.
</t>
<t>
ENCRYPTED {data} = data ^ pseudo_pad
</t>
<t>
The packet body can then be de-obfuscated
by
XOR-ing it
byte-wise
with a pseudo random pad.
</t>
<t>
data = ENCRYPTED {data} ^ pseudo_pad
</t>
<t>
The pad is generated by concatenating a s
eries of
MD5 hashes
(each
16 bytes long) and truncating it
to the length of the input
data.
</t>
<t>
Whenever used in this document, MD5 refer s to Whenever used in this document, MD5 refer s to
the "RSA Data the "RSA Data
Security, Inc. MD5 Message-Digest Security, Inc.&nbsp; MD5 Message-Digest
Algorithm" as specified in Algorithm" as specified in
<xref target="RFC1321">RFC 1321</xref>. <xref target="RFC1321" format="default"/>
</t> .
<t> </t>
pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n] <ul empty="true">
]} <li>
truncated to <t>
len(data) pseudo_pad = {MD5_1 [,MD5_2 [
</t> ... ,MD5_n]]} truncated to len(data)
<t> </t>
The first MD5 hash is generated by concat </li>
enating </ul>
the session_id,
the secret key, the version <t>
number and the sequence number and The first MD5 hash is generated by
then concatenating the session_id, the
running secret key, the version number, and the
MD5 over that stream. All of those input sequence number, and then running MD5
values over that stream. All of those input
are values are available in the packet
available header, except for the secret
in the packet header, except for key, which
the secret key which is is a shared secret between the TACACS+
a shared client and server.
secret between </t>
the TACACS+ client and server. <t>
</t>
<t>
The version number and session_id are ext racted from the The version number and session_id are ext racted from the
header header.
</t> </t>
<t> <t>
Subsequent hashes are generated by using Subsequent hashes are generated by
the same using the same input stream but
input stream, concatenating the previous hash value
but concatenating the previous hash at the end of the input stream.
value at the end of the input </t>
stream.
</t> <ul empty="true">
<t> <li>
MD5_1 = MD5{session_id, key, version, seq <t>
_no} MD5_1 = MD5{session_id, key, version,
MD5_2 = seq_no} MD5_2 = MD5{session_id, key,
version, seq_no, MD5_1} .... MD5_n =
MD5{session_id, key, version, seq_no, MD5{session_id, key, version, seq_no,
MD5_1} MD5_n-1}
.... </t>
MD5_n = </li>
MD5{session_id, key, version, </ul>
seq_no, MD5_n-1}
</t> <t>
<t>
When a server detects that the secret(s) When a server detects that the
it has configured for secrets it has configured for the
the device do not match, it
device mismatch, it MUST return ERROR. Fo <bcp14>MUST</bcp14> return ERROR. For
r details of TCP details of TCP connection handling on
connection handling on ERROR, refer to ERROR, refer to "Session Completion" (<xr
<xref target="SessionCompletion"/>. ef
</t> target="SessionCompletion"
<t> format="default"/>).
</t>
<ul empty="true">
<li>
<t>
TAC_PLUS_UNENCRYPTED_FLAG == 0x1 TAC_PLUS_UNENCRYPTED_FLAG == 0x1
</t> </t>
<t> </li>
This option is deprecated and MUST NOT be </ul>
used in production. In this case, the entire packet body is in <t>
cleartext. A This option is deprecated and
request MUST be dropped if <bcp14>MUST NOT</bcp14> be used in
TAC_PLUS_UNENCRYPTED_FLAG is set to true. production. In this case, the entire
</t> packet body is in cleartext. A request
<t> <bcp14>MUST</bcp14> be dropped if
TAC_PLUS_UNENCRYPTED_FLAG is set to
true.
</t>
<t>
After a packet body is de-obfuscated, the lengths of the After a packet body is de-obfuscated, the lengths of the
component component
values values
in the packet are summed. If the sum is n ot in the packet are summed. If the sum is n ot
identical to the identical to the
cleartext cleartext
datalength value from the header, datalength value from the header,
the the
packet MUST be packet <bcp14>MUST</bcp14> be
discarded, and an ERROR signaled. For det discarded and an ERROR signaled. For deta
ails of TCP connection ils of TCP connection
handling on ERROR, refer to handling on ERROR, refer to
<xref target="SessionCompletion"/>. "Session Completion" (<xref target="Sessi
</t> onCompletion" format="default"/>).
<t> </t>
Commonly <t>
such failures are seen when the keys are Commonly, such failures are seen when
mismatched the keys are mismatched between the
between the client and the TACACS+ server client and the TACACS+ server.
. </t>
</t>
</section>
</section>
<section anchor="Authentication" title="Authentication">
<t>Authentication is the action of determining who a user
(or entity)
is. Authentication can take many forms.
Traditional authentication
employs a name and a fixed
password. However, fixed passwords are
vulnerable security, so many modern
authentication mechanisms utilize
"one-time" passwords
or a
challenge-response query. TACACS+ is
designed to
support all of
these, and be flexible enough to
handle any
future
mechanisms.
Authentication generally
takes place when the user
first
logs in to a
machine or
requests a service of it.</t>
<t>Authentication is not mandatory; it is a site-configur
ed
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
himself or
herself as someone who possesses the required
information
(passwords, etc.) for those privileges.</t>
<section anchor="TheAuthenticationSTARTPacketBody" title= </section>
"The Authentication START Packet Body"> </section>
<figure> <section anchor="Authentication" numbered="true" toc="default">
<artwork><![CDATA[ <name>Authentication</name>
<t>Authentication is the action of determining who a user (or entity)
is. Authentication can take many forms. Traditional authentication
employs a name and a fixed password. However, fixed passwords are
vulnerable security, so many modern authentication mechanisms utilize
"one-time" passwords or a challenge-response query. TACACS+ is designed
to support all of these and be flexible enough to handle any future
mechanisms. Authentication generally takes place when the user first
logs in to a machine or requests a service of it.</t>
<t>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" (<xref target="Authorization"/>)). Authenti
cation may also take place
when a user attempts to gain extra privileges and must identify himself
or herself as someone who possesses the required information (passwords,
etc.) for those privileges.</t>
<section anchor="TheAuthenticationSTARTPacketBody" numbered="true" toc="de
fault">
<name>The Authentication START Packet Body</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| action | priv_lvl | authen_type | authen_service | | action | priv_lvl | authen_type | authen_service |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user_len | port_len | rem_addr_len | data_len | | user_len | port_len | rem_addr_len | data_len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user ... | user ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| port ... | port ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| rem_addr ... | rem_addr ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| data... | data...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
]]></artwork> ]]></artwork>
</figure> <t>
<t>
Packet fields are as follows: Packet fields are as follows:
</t> </t>
<t> <t>
action action
</t> </t>
<t> <ul empty="true">
This indicates the authentication action. <li> <t> This indicates the authentication action. </t>
Valid <t>
values Valid values are:
are listed </t>
below. </li>
</t> <li>
<t>
<list>
<t>
TAC_PLUS_AUTHEN_LOGIN := 0x01 TAC_PLUS_AUTHEN_LOGIN := 0x01
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_CHPASS := 0x02 TAC_PLUS_AUTHEN_CHPASS := 0x02
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SENDAUTH := 0x04 TAC_PLUS_AUTHEN_SENDAUTH := 0x04
</t> </li>
</list> </ul>
</t> <t>
<t>
priv_lvl priv_lvl
</t> </t>
<t>
This indicates the privilege level that t <ul empty="true">
he user is <li> <t> This indicates the privilege level that the user is authenticating
authenticating as. Please refer to "Privilege Levels" (<xref target="PrivilegeLevel"
as. Please refer to the format="default"/>).
<xref target="PrivilegeLevel">Privilege L </t>
evel section</xref> </li>
below. </ul>
</t>
<t> <t>
authen_type authen_type
</t> </t>
<t> <ul empty="true">
The type of authentication. Please see se <li>
ction <t>
<xref target="CommonAuthenticationFlows"> The type of authentication. Please see "Common Authentication Flows" (<xref
Common Authentication Flows</xref>. Valid values target="CommonAuthenticationFlows" format="default"/>).
are: </t>
</t> </li>
<t> <li>
<list> <t>
<t> Valid values are:
</t>
</li>
<li>
TAC_PLUS_AUTHEN_TYPE_ASCI I := 0x01 TAC_PLUS_AUTHEN_TYPE_ASCI I := 0x01
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_TYPE_MSCH AP := 0x05 TAC_PLUS_AUTHEN_TYPE_MSCH AP := 0x05
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_TYPE_MSCH APV2 := 0x06 TAC_PLUS_AUTHEN_TYPE_MSCH APV2 := 0x06
</t> </li>
</list> </ul>
</t>
<t> <t>
authen_service authen_service
</t> </t>
<t>
This is the service that is requesting th <ul empty="true">
e <li>
authentication. Valid <t>
values This is the service that is requesting
are: the authentication.
</t> </t>
<t> </li>
<list> <li>
<t> <t>
Valid values are:
</t>
</li>
<li>
TAC_PLUS_AUTHEN_SVC_NONE := 0x00 TAC_PLUS_AUTHEN_SVC_NONE := 0x00
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SVC_ENABL E := 0x02 TAC_PLUS_AUTHEN_SVC_ENABL E := 0x02
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SVC_PPP : = 0x03 TAC_PLUS_AUTHEN_SVC_PPP : = 0x03
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SVC_PT := 0x05 TAC_PLUS_AUTHEN_SVC_PT := 0x05
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SVC_X25 : = 0x07 TAC_PLUS_AUTHEN_SVC_X25 : = 0x07
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SVC_NASI := 0x08 TAC_PLUS_AUTHEN_SVC_NASI := 0x08
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_SVC_FWPRO XY := 0x09 TAC_PLUS_AUTHEN_SVC_FWPRO XY := 0x09
</t> </li>
</list> <li>
</t> <t>The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the
<t>The TAC_PLUS_AUTHEN_SVC_NONE option is intende authorization application of this field that indicates that no
d for the authentication was performed by the device.</t>
authorization application of this field t <t>The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as
hat indicates that no opposed to ENABLE) to a client device.</t>
authentication was performed by the devic </li>
e.</t>
<t>The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates <li>
regular login <t>
(as The TAC_PLUS_AUTHEN_SVC_ENABLE option
opposed to ENABLE) to a client device.</t identifies the ENABLE authen_service,
> which refers to a service requesting
<t> authentication in order to grant the
The TAC_PLUS_AUTHEN_SVC_ENABLE option ide user different privileges. This is
ntifies the ENABLE comparable to the Unix "su(1)"
authen_service, which refers to a service command, which substitutes the current
requesting user's identity with another. An
authentication authen_service value of NONE is only
in to be used when none of the other
order authen_service values are appropriate.
to grant the user different ENABLE may be requested independently;
privileges. This is comparable no requirements for previous
to authentications or authorizations are
the Unix imposed by the protocol.
"su(1)" </t>
command, which substitutes the current us
er's </li>
identity with another. An authen_service <li>
value of NONE is only to <t>Other options are included for legacy/backwards compatibility.</t>
be </li>
used </ul>
when none <t>
of the other authen_service values are
appropriate.
ENABLE
may be requested
independently, no requirements for previo
us
authentications or
authorizations are imposed by the protoco
l.
</t>
<t>Other options are included for legacy/backward
s compatibility.</t>
<t>
user, user_len user, user_len
</t> </t>
<t> <ul empty="true">
The username is <li>
optional in this <t>
packet, The username is optional in this
depending upon the packet, depending upon the class of
class of authentication. If it is absent, the
authentication. If it is absent, the clie client <bcp14>MUST</bcp14> set
nt MUST set user_len to 0. user_len to 0. If included, the
If included, user_len indicates the length of the
the user_len indicates the length of the user field, in bytes.
user field, in </t>
bytes. </li>
</t> </ul>
<t> <t>
port, port_len port, port_len
</t> </t>
<t> <ul empty="true">
The name of the client port on which the <li>
authentication <t>
is The name of the client port on which
taking the authentication is taking place.
place. The value of this field is free-format
The value of text and is client specific. Examples
this of this argument include "tty10"
field is free format text and is client s to denote the tenth tty line, and
pecific. "async10" to denote the tenth async
Examples of this this argument include "t interface. The client documentation
ty10" to denote the tenth tty line and "async10" to <bcp14>SHOULD</bcp14> define the
denote the tenth async interface. The client values and their meanings for this
documentation SHOULD define the values and their meanings for this field. field. For details of text encoding,
For details of see "Treatment of Text Strings" (<xref
<xref target="TextEncoding">text encoding target="TextEncoding"
, see</xref>. format="default"/>). The port_len indica
port_len indicates the length of the port tes the
field, in length of the port field, in bytes.
bytes. </t>
</t> </li>
<t> </ul>
<t>
rem_addr, rem_addr_len rem_addr, rem_addr_len
</t> </t>
<t>
A string indicating the <ul empty="true">
remote <li>
location from <t>
which the A string indicating the remote
user location from which the user has
has connected to the client. For details
connected to the client. For details of of text encoding, see "Treatment of
<xref target="TextEncoding">text encoding Text Strings" (<xref
, see</xref>. target="TextEncoding"
</t> format="default"/>).
<t> When TACACS+ was used for dial-up services, t </t>
his value contained
the caller ID</t> </li>
<t> <li>
When TACACS+ is used for Device Administr <t> When TACACS+ was used for dial-up services, this value contained
ation, the user is the caller ID.</t>
normally connected via a network, and in </li>
this case the value <li>
is <t>
intended to hold a When TACACS+ is used for Device
network Administration, the user is normally
address, IPv4 or IPv6. For IPv6 address connected via a network, and in this
text representation case, the value is intended to hold a
defined please see network address, IPv4 or IPv6. For
<xref target="RFC5952">RFC 5952</xref>. IPv6 address text representation
</t> defined, please see <xref
<t>This target="RFC5952" format="default"/>.
field </t>
is optional </li>
(since the <li>
information may not be <t>This field is optional (since the information may not be
available). available). The rem_addr_len indicates the length of the user field,
The in bytes.
rem_addr_len indicates the </t>
length of the user field, in bytes. </li>
</t> </ul>
<t> <t>
data, data_len data, data_len
</t> </t>
<t>
This field is used to send data appropria
te for the
action and
authen_type. It is described in more
detail in the section
<xref target="CommonAuthenticationFlows">
Common Authentication flows</xref>. The data_len indicates the length of the dat
a field, in
bytes.
</t>
</section>
<section anchor="TheAuthenticationREPLYPacketBody" title=
"The Authentication REPLY Packet Body">
<t>
The TACACS+ server sends only one type of
authentication packet
(a
REPLY packet) to the client.
</t>
<figure> <ul empty="true">
<artwork><![CDATA[ <li>
<t>
The data field is used to send data appropriate for the action and
authen_type. It is described in more detail in "Common Authentication
Flows" (<xref target="CommonAuthenticationFlows"
format="default"/>). The data_len field indicates the length of the
data field, in bytes.
</t>
</li>
</ul>
</section>
<section anchor="TheAuthenticationREPLYPacketBody" numbered="true" toc="de
fault">
<name>The Authentication REPLY Packet Body</name>
<t>
The TACACS+ server sends only one type
of authentication packet (a REPLY
packet) to the client.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| status | flags | server_msg_len | | status | flags | server_msg_len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| data_len | server_msg ... | data_len | server_msg ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| data ... | data ...
+----------------+----------------+ +----------------+----------------+
]]></artwork> ]]></artwork>
</figure> <t>
<t>
status status
</t> </t>
<t> <ul empty="true">
The current status of the authentication. <li>
Valid <t>
values are: The current status of the authentication.
</t> </t>
<t> </li>
<list> <li>Valid values are:
<t> </li>
</ul>
<ul empty="true" spacing="normal">
<li>
TAC_PLUS_AUTHEN_STATUS_PA SS := 0x01 TAC_PLUS_AUTHEN_STATUS_PA SS := 0x01
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_STATUS_FA IL := TAC_PLUS_AUTHEN_STATUS_FA IL :=
0x02 0x02
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_STATUS_GE TDATA := 0x03 TAC_PLUS_AUTHEN_STATUS_GE TDATA := 0x03
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_STATUS_GE TUSER := 0x04 TAC_PLUS_AUTHEN_STATUS_GE TUSER := 0x04
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_STATUS_GE TPASS := 0x05 TAC_PLUS_AUTHEN_STATUS_GE TPASS := 0x05
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_STATUS_RE START := 0x06 TAC_PLUS_AUTHEN_STATUS_RE START := 0x06
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_STATUS_ER ROR TAC_PLUS_AUTHEN_STATUS_ER ROR
:= 0x07 := 0x07
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_STATUS_FO LLOW := 0x21 TAC_PLUS_AUTHEN_STATUS_FO LLOW := 0x21
</t> </li>
</list> </ul>
</t> <t>
<t>
flags flags
</t> </t>
<t> <ul empty="true">
Bitmapped flags that modify the action to <li>
be taken. <t>
The Bitmapped flags that modify the action to be taken.
following </t>
values are </li>
defined: <li>The following values are defined:
</t> </li>
<t> </ul>
<list> <ul empty="true" spacing="normal">
<t> <li>
TAC_PLUS_REPLY_FLAG_NOECH O := 0x01 TAC_PLUS_REPLY_FLAG_NOECH O := 0x01
</t> </li>
</list> </ul>
</t> <t>
<t>
server_msg, server_msg_len server_msg, server_msg_len
</t> </t>
<t> <ul empty="true">
A message to be displayed to the user. Th <li> <t>
is field is A message to be displayed to the user. This field is optional. The
optional. server_msg_len indicates the length of the server_msg field, in bytes.
The For details of text encoding, see "Treatment of Text Strings" (<xref targ
server_msg_len et="TextEncoding" format="default"/>).
indicates the length </t>
of the </li>
server_msg field, in bytes. </ul>
For details of <t>
<xref target="TextEncoding">text encoding
, see</xref>.
</t>
<t>
data, data_len data, data_len
</t> </t>
<t> <ul empty="true">
This field holds data that is a part of t <li>
he <t>
authentication A field that holds data that is a part of the authentication exchange
exchange and is intended for client processing, not the user. It is not a
and printable text encoding. Examples of its use are shown in "Common
is intended for Authentication Flows" (<xref target="CommonAuthenticationFlows"
client processing, not the user. It is no format="default"/>). The data_len indicates the length of the data
t a field, in bytes.
printable text encoding. Examples of its </t>
use are </li>
shown </ul>
in the section </section>
<xref target="CommonAuthenticationFlows"> <section anchor="TheAuthenticationCONTINUEPacketBody" numbered="true" toc=
Common Authentication flows</xref>. The data_len indicates the length of the dat "default">
a field, in <name>The Authentication CONTINUE Packet Body</name>
bytes.
</t>
</section> <t>
<section anchor="TheAuthenticationCONTINUEPacketBody" tit This packet is sent from the client to the server following the
le="The Authentication CONTINUE Packet Body"> receipt of a REPLY packet.
<t> </t>
This packet is sent from the client to th <artwork name="" type="" align="left" alt=""><![CDATA[
e server
following the
receipt
of a REPLY packet.
</t>
<figure>
<artwork><![CDATA[
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user_msg len | data_len | | user_msg len | data_len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| flags | user_msg ... | flags | user_msg ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| data ... | data ...
+----------------+ +----------------+
]]></artwork> ]]></artwork>
</figure> <t>
<t>
user_msg, user_msg_len user_msg, user_msg_len
</t> </t>
<t> <ul empty="true">
This field is the string that the user en <li>
tered, or <t>
the client A field that is the string that the user entered, or the client
provided provided on behalf of the user, in response to the server_msg from a
on behalf of the user, in response REPLY packet. The user_len indicates the length of the user field, in
to the server_msg from bytes.
a </t>
REPLY </li>
packet. The user_len indicates the length </ul>
of the user <t>
field, in
bytes.
</t>
<t>
data, data_len data, data_len
</t> </t>
<t> <ul empty="true">
This field carries information that is sp
ecific to <li>
the action <t>
and This field carries information that is specific to the action and the
the authen_type for this session. Valid uses of this field are described
authen_type for this session. Valid below. It is not a printable text encoding. The data_len indicates the
uses of this field are length of the data field, in bytes.
described below. It is not a printable te </t>
xt encoding. The data_len </li>
indicates the length of the data </ul>
field, in bytes.
</t> <t>
<t>
flags flags
</t> </t>
<t> <ul empty="true">
This holds the bitmapped flags that modif <li>
y the action <t>
to be This holds the bitmapped flags that modify the action to be taken.
taken. </t>
The </li>
following values are defined: <li>
</t> <t>
<t> The following values are defined:
<list> </t>
<t> </li>
<li>
TAC_PLUS_CONTINUE_FLAG_AB ORT := 0x01 TAC_PLUS_CONTINUE_FLAG_AB ORT := 0x01
</t> </li>
</list> </ul>
</t>
</section> </section>
<section anchor="DescriptionofAuthenticationProcess" titl <section anchor="DescriptionofAuthenticationProcess" numbered="true" toc="
e="Description of Authentication Process"> default">
<t> <name>Description of Authentication Process</name>
The action, authen_type and authen_servic <t>
e fields (described The action, authen_type, and authen_service fields (described above)
above) combine to indicate what kind of authentication is to be performed.
combine to indicate what kind of authenti Every authentication START, REPLY, and CONTINUE packet includes a data
cation is to be field. The use of this field is dependent upon the kind of
performed. authentication.
Every authentication START, REPLY and CON </t>
TINUE packet <t>
includes a This document defines a core set of authentication flows to be
data field. The use of this field is depe supported by TACACS+. Each authentication flow consists of a START
ndent upon the packet. The server responds either with a request for more
kind of the information (GETDATA, GETUSER, or GETPASS) or a termination PASS, FAIL,
Authentication. ERROR, or RESTART. The actions and meanings when the server sends a
</t> RESTART or ERROR are common and are described further below.
<t> </t>
This document defines a core set of <t>
authentication flows to be When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA,
supported by TACACS+. TAC_PLUS_AUTHEN_STATUS_GETUSER, or TAC_PLUS_AUTHEN_STATUS_GETPASS,
Each authentication flow authentication continues and the server <bcp14>SHOULD</bcp14> provide
consists of a START server_msg content for the client to prompt the user for more
packet. information. The client <bcp14>MUST</bcp14> then return a CONTINUE
The packet containing the requested information in the user_msg field.
server responds either </t>
with a request <t>
for more information The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a
(GETDATA, request for a username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request
GETUSER for a password. The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic
or GETPASS) or a termination request for more information to flexibly support future requirements.
PASS, FAIL, ERROR or </t>
RESTART. The <t>If the information being requested by the server from the client is
actions and sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
meanings when flag. When the client queries the user for the information, the
the server sends a response <bcp14>MUST NOT</bcp14> be reflected in the user interface as
RESTART or it is entered.
ERROR are </t>
common <t>
and are
described
further below.
</t>
<t>
When the REPLY status equals
TAC_PLUS_AUTHEN_STATUS_GETDATA,
TAC_PLUS_AUTHEN_STATUS_GETUSER or
TAC_PLUS_AUTHEN_STATUS_GETPASS,
then authentication
continues and the server SHOULD provide
server_msg
content for
the
client to prompt the user for more
information. The
client MUST
then
return a CONTINUE packet containing
the requested
information
in the
user_msg field.
</t>
<t>
The client should interpret TAC_PLUS_AUTH
EN_STATUS_GETUSER as a
request for username and TAC_PLUS_AUTHEN_
STATUS_GETPASS as a
request for password.
The TAC_PLUS_AUTHEN_STATUS_GETDATA is
the
generic
request
for
more information to flexibly support futu
re
requirements.
</t>
<t>If the information being requested by the serv
er form the client
is sensitive, then the server should set
the
TAC_PLUS_REPLY_FLAG_NOECHO flag.
When the client queries the
user for
the information, the response MUST NOT be
reflected in the user
interface as it is
entered.
</t>
<t>
The data field is only used in the REPLY The data field is only used in the REPLY
where where
explicitly explicitly
defined defined
below. below.
</t> </t>
<section anchor="VersionBehaviour" title="Version <section anchor="VersionBehaviour" numbered="true" toc="default">
Behavior"> <name>Version Behavior</name>
<t> <t>
The TACACS+ protocol is versioned The TACACS+ protocol is
to allow versioned to allow revisions
revisions while while maintaining backwards
maintaining backwards
compatibility. The version compatibility. The version
number is in number is in every packet
every header. The changes between
packet header. The changes betwee minor_version 0 and 1 apply
n minor_version only to the authentication
0 and 1 process, and all deal with the
apply only way that Challenge
to the authentication process, Handshake
and all deal with the Authentication
way that CHAP Protocol (CHAP) and
and PAP Password
authentications are handled. mino Authentication
r_version Protocol (PAP)
1 authentications are
may handled. minor_version 1 may
only be used only be used for
for authentication kinds that authentication kinds that
explicitly call explicitly call for it in the
for it in the table table below:
below: </t>
</t>
<figure> <table anchor="table_1">
<artwork><![CDATA[ <name>TACACS+ Protocol Versioning</name>
LOGIN CHPASS SENDAUTH
ASCII v0 v0 - <tbody>
PAP v1 - v1 <tr>
CHAP v1 - v1 <td></td>
MS-CHAPv1/2 v1 - v1 <td>LOGIN</td>
]]> <td>CHPASS</td>
</artwork> <td>SENDAUTH</td>
</figure> </tr>
<t>The '-' symbol represents that the opt <tr>
ion is not valid.</t> <td>ASCII</td>
<t> <td>v0</td>
All authorization and accounting <td>v0</td>
and ASCII <td>-</td>
authentication </tr>
use <tr>
minor_version number <td>PAP</td>
of 0. <td>v1</td>
</t> <td>-</td>
<t> <td>v1</td>
</t> </tr>
<t> <tr>
PAP, CHAP and MS-CHAP login use m <td>CHAP</td>
inor_version 1. <td>v1</td>
The normal <td>-</td>
exchange is a single START packet <td>v1</td>
from the client and a single </tr>
REPLY from the server. <tr>
</t> <td>MS-CHAPv1/2</td>
<t> The removal of <td>v1</td>
SENDPASS was prompted by security <td>-</td>
concerns, <td>v1</td>
and </tr>
is </tbody>
no longer </table>
considered part of the TACACS+
protocol. <t>The '-' symbol represents that the option is not valid.</t>
</t>
</section> <t>
<section anchor="CommonAuthenticationFlows" title All authorization and accounting and ASCII authentication use
="Common Authentication Flows"> minor_version 0.
<t> </t>
This section describes common aut
hentication flows. If the <t>
server does not implement an opti PAP, CHAP, and MS-CHAP login use minor_version 1. The normal exchange
on, it MUST respond with is a single START packet from the client and a single REPLY from the
TAC_PLUS_AUTHEN_STATUS_FAIL. server.
</t> </t>
<section anchor="ASCIILogin" title="ASCII <t> The removal of SENDPASS was prompted by security concerns and
Login"> is no longer considered part of the TACACS+ protocol.
<figure> </t>
<artwork><![CDATA[ </section>
<section anchor="CommonAuthenticationFlows" numbered="true" toc="default
">
<name>Common Authentication Flows</name>
<t>
This section describes common authentication flows. If the server does
not implement an option, it <bcp14>MUST</bcp14> respond with
TAC_PLUS_AUTHEN_STATUS_FAIL.
</t>
<section anchor="ASCIILogin" numbered="true" toc="default">
<name>ASCII Login</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
minor_version = 0x0 minor_version = 0x0
]]> ]]></artwork>
</artwork> <t>
</figure> This is a standard ASCII authentication. The START packet
<t> <bcp14>MAY</bcp14> contain the username. If the user does not include
This is a standard ASCII the username, then the server <bcp14>MUST</bcp14> obtain it from the
authentication. The client with a CONTINUE TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user
START packet MAY does not provide a username, then the server can send another
contain TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server
the username. If the user <bcp14>MUST</bcp14> limit the number of retries that are permitted;
does not include the username the recommended limit is three attempts. When the server has the
then the server MUST obta username, it will obtain the password using a continue with
in it from the client with a CONTINUE TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII login uses the user_msg field
TAC_PLUS_AUTHEN_STATUS_GE for both the username and password. The data fields in both the START
TUSER. If the user does not provide a and CONTINUE packets are not used for ASCII logins; any content
username then the server <bcp14>MUST</bcp14> be ignored. The session is composed of a single
can send another START followed by zero or more pairs of REPLYs and CONTINUEs, followed
TAC_PLUS_AUTHEN_STATUS_GE by a final REPLY indicating PASS, FAIL, or ERROR.
TUSER request, </t>
but the server MUST limit </section>
the number of retries tha <section anchor="PAPLogin" numbered="true" toc="default">
t are permitted, <name>PAP Login</name>
recommended limit is <artwork name="" type="" align="left" alt=""><![CDATA[
three attempts. When the
server has the
username,
it will obtain
the password using a cont
inue with
TAC_PLUS_AUTHEN_STATUS_GE
TPASS.
ASCII login uses the user
_msg
field
for both the username and
password. The data fields in both
the
START and
CONTINUE packets are not
used for ASCII logins, any
content MUST be ignored.
The session is composed o
f
a single START
followed by zero or more
pairs of REPLYs
and
CONTINUEs, followed by
a
final REPLY indicating PA
SS, FAIL or ERROR.
</t>
</section>
<section anchor="PAPLogin" title="PAP Log
in">
<figure>
<artwork><![CDATA[
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_PAP authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
minor_version = 0x1 minor_version = 0x1
]]> ]]></artwork>
</artwork> <t>
</figure> The entire exchange <bcp14>MUST</bcp14> consist of a single START
<t> packet and a single REPLY. The START packet <bcp14>MUST</bcp14>
The entire exchange MUST contain a username and the data field <bcp14>MUST</bcp14> contain the
consist of a single PAP ASCII password. A PAP authentication only consists of a username
START packet and a and password <xref target="RFC1334" format="default"/> (Obsolete). The
single REPLY. The START p REPLY from the server <bcp14>MUST</bcp14> be either a PASS, FAIL, or
acket ERROR.
MUST contain a username a </t>
nd the </section>
data <section anchor="CHAPlogin" numbered="true" toc="default">
field MUST <name>CHAP Login</name>
contain the PAP ASCII pas <artwork name="" type="" align="left" alt=""><![CDATA[
sword. A PAP
authentication only
consists of a username an
d
password
<xref target="RFC1334">RF
C 1334</xref>
(Obsolete). The REPLY fro
m the server MUST be either a
PASS, FAIL
or ERROR.
</t>
</section>
<section anchor="CHAPlogin" title="CHAP l
ogin">
<figure>
<artwork><![CDATA[
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP
minor_version = 0x1 minor_version = 0x1
]]> ]]></artwork>
</artwork> <t>
</figure> The entire exchange <bcp14>MUST</bcp14> consist of a single START
<t> packet and a single REPLY. The START packet <bcp14>MUST</bcp14>
The entire exchange MUST contain the username in the user field, and the data field is a
consist of a single concatenation of the PPP id, the challenge, and the response.
START packet and a </t>
single REPLY. The START p <t>
acket The length of the challenge value can be determined from the length of
MUST contain the the data field minus the length of the id (always 1 octet) and the
username in the length of the response field (always 16 octets).
user </t>
field and <t>
the data field is a conca To perform the authentication, the server calculates the PPP hash as defined
tenation of the in PPP Authentication <xref target="RFC1334" format="default"/> and then
PPP compares that value with the response. The MD5 algorithm option is always
id, the used. The REPLY from the server <bcp14>MUST</bcp14> be a PASS, FAIL, or
challenge and the respons ERROR.
e. </t>
</t> <t>
<t> The selection of the challenge and its length are not an aspect of the
The length of the challen TACACS+ protocol. However, it is strongly recommended that the
ge value can be client/endstation interaction be configured with a secure
determined from the challenge. The TACACS+ server can help by rejecting authentications
length where the challenge is below a minimum length (minimum recommended is
of the data field minus 8 bytes).
the length of the id (alw </t>
ays 1 </section>
octet) <section anchor="MS-CHAPv1login" numbered="true" toc="default">
and <name>MS-CHAP v1 Login</name>
the <artwork name="" type="" align="left" alt=""><![CDATA[
length of the response fi
eld (always 16 octets).
</t>
<t>
To perform the authentica
tion, the server calculates the PPP hash
as defined in the PPP
Authentication
<xref target="RFC1334">RF
C 1334</xref>
and then compares that va
lue with the response. The MD5 algorithm
option is always used.
The REPLY from
the
server MUST be a PASS,
FAIL
or ERROR.
</t>
<t>
The selection of the chal
lenge and its
length
are not an aspect
of the TACACS+ protocol.
However, it is
strongly
recommended that
the client/endstation
interaction is
configured
with a secure
challenge. The
TACACS+ server can help b
y
rejecting authentications
where the
challenge is below a mini
mum
length (Minimum recommend
ed
is 8 bytes).
</t>
</section>
<section anchor="MS-CHAPv1login" title="M
S-CHAP v1 login">
<figure>
<artwork><![CDATA[
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP
minor_version = 0x1 minor_version = 0x1
]]> ]]></artwork>
</artwork> <t>
</figure> The entire exchange <bcp14>MUST</bcp14> consist of a single START packet and a
<t> single REPLY. The START packet <bcp14>MUST</bcp14> contain the username in the
The entire exchange MUST user field, and the data field will be a concatenation of the PPP id, the
consist of a single MS-CHAP challenge, and the MS-CHAP response.
START packet and a </t>
single REPLY. The START p <t>
acket The length of the challenge value can be determined from the length of the
MUST contain the data field minus the length of the id (always 1 octet) and the length of the
username in the response field (always 49 octets).
user </t>
field and <t>
the data field will be a To perform the authentication, the server will use a combination of MD4 and
concatenation of the DES on the user's secret and the challenge, as defined in <xref
PPP target="RFC2433" format="default"/>, and then compare the
id, resulting value with the response. The REPLY from the server
the <bcp14>MUST</bcp14> be a PASS or FAIL.
MS-CHAP challenge and the </t>
MS-CHAP <t>
response. For best practices, please refer to <xref target="RFC2433"
</t> format="default"/>. The TACACS+ server <bcp14>MUST</bcp14> reject
<t> authentications where the challenge deviates from 8 bytes as defined
The length of the challen in the RFC.
ge value can be </t>
determined from the </section>
length <section anchor="MS-CHAPv2login" numbered="true" toc="default">
of the data field minus <name>MS-CHAP v2 Login</name>
the length of the id (alw <artwork name="" type="" align="left" alt=""><![CDATA[
ays 1
octet)
and
the
length of the response fi
eld (always 49 octets).
</t>
<t>
To perform the authentica
tion, the server will
use a combination
of
MD4 and DES on the user's
secret and the challenge,
as
defined
in
<xref target="RFC2433">RF
C 2433</xref>
and then compare the resu
lting value with the
response. The
REPLY
from the server MUST be a
PASS
or FAIL.
</t>
<t>
For best practices, pleas
e refer to
<xref target="RFC2433">RF
C 2433</xref>. The
TACACS+ server MUST rejec
t authentications where the
challenge deviates from 8
bytes as defined in the RFC.
</t>
</section>
<section anchor="MS-CHAPv2login" title="M
S-CHAP v2 login">
<figure>
<artwork><![CDATA[
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2
minor_version = 0x1 minor_version = 0x1
]]> ]]></artwork>
</artwork> <t>
</figure> The entire exchange <bcp14>MUST</bcp14> consist of a single START packet and a
<t> single REPLY. The START packet <bcp14>MUST</bcp14> contain the username in the
The entire exchange MUST user field, and the data field will be a concatenation of the PPP id, the
consist of a single MS-CHAP challenge, and the MS-CHAP response.
START packet and a </t>
single REPLY. The START p <t>
acket The length of the challenge value can be determined from the length of the
MUST contain the data field minus the length of the id (always 1 octet) and the length of the
username in the response field (always 49 octets).
user </t>
field and <t>
the data field will be a To perform the authentication, the server will use the algorithm specified
concatenation of the <xref target="RFC2759" format="default"/> on the user's secret and challenge,
PPP and then compare the resulting value with the response. The REPLY from the
id, server <bcp14>MUST</bcp14> be a PASS or FAIL.
the </t>
MS-CHAP challenge and the <t>
MS-CHAP For best practices for MS-CHAP v2, please refer to <xref target="RFC2759"
response. format="default">RFC2759</xref>. The TACACS+ server <bcp14>MUST</bcp14> reject
</t> authentications where the challenge deviates from 16 bytes as defined in the
<t> RFC.
The length of the challen </t>
ge value can be </section>
determined from the <section anchor="EnableRequests" numbered="true" toc="default">
length <name>Enable Requests</name>
of the data field minus <artwork name="" type="" align="left" alt=""><![CDATA[
the length of the id (alw
ays 1
octet)
and
the
length of the response fi
eld (always 49 octets).
</t>
<t>
To perform the authentica
tion, the server will
use the algorithm
specified
<xref target="RFC2759">RF
C 2759</xref>
on the user's secret and
challenge
and then
compare the resulting
value with the response.
The
REPLY
from the server MUST be a
PASS or
FAIL.
</t>
<t>
For best practices for MS
-CHAP v2, please refer to
<xref target="RFC2759">RF
C2759</xref>. The
TACACS+ server MUST rejec
t authentications where the
challenge deviates from 1
6 bytes as defined in the RFC.
</t>
</section>
<section anchor="EnableRequests" title="E
nable Requests">
<figure>
<artwork><![CDATA[
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
priv_lvl = implementation dependent priv_lvl = implementation dependent
authen_type = not used authen_type = not used
service = TAC_PLUS_AUTHEN_SVC_ENABLE service = TAC_PLUS_AUTHEN_SVC_ENABLE
]]> ]]></artwork>
</artwork> <t>
</figure> This is an "ENABLE" request, used to change the current running
<t> privilege level of a user. The exchange <bcp14>MAY</bcp14> consist of
This is an ENABLE request multiple messages while the server collects the information it
, used to change the requires in order to allow changing the principal's privilege
current running level. This exchange is very similar to an ASCII login (<xref target="ASC
privilege level of a user IILogin"
. format="default"/>).
The exchange MAY </t>
consist of <t>
multiple In order to readily distinguish "ENABLE" requests from other types of request,
messages the value of the authen_service field <bcp14>MUST</bcp14> be set to
while the server collects TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It <bcp14>MUST
the information it NOT</bcp14> be set to this value when requesting any other operation.
requires in </t>
order to allow changing t </section>
he <section anchor="ASCIIchangepasswordrequest" numbered="true" toc="defa
principal's privilege ult">
level. This <name>ASCII Change Password Request</name>
exchange is <artwork name="" type="" align="left" alt=""><![CDATA[
very similar to an
<xref target="ASCIILogin"
>ASCII login</xref>.
</t>
<t>
In order to readily disti
nguish enable requests
from other
types
of
request, the value of the
authen_service field MUST
be set to
TAC_PLUS_AUTHEN_SVC_ENABL
E when requesting an
ENABLE. It MUST
NOT
be
set to this value when
requesting any other oper
ation.
</t>
</section>
<section anchor="ASCIIchangepasswordreque
st" title="ASCII change password request">
<figure>
<artwork><![CDATA[
action = TAC_PLUS_AUTHEN_CHPASS action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
]]> ]]></artwork>
</artwork> <t>
</figure> This exchange consists of multiple messages while the server collects
<t> the information it requires in order to change the user's password. It
This exchange consists of is very similar to an ASCII login. The status value
multiple messages while TAC_PLUS_AUTHEN_STATUS_GETPASS <bcp14>MUST</bcp14> only be used when
the server requesting the "new" password. It <bcp14>MAY</bcp14> be sent multiple
collects times. When requesting the "old" password, the status value
the information it requir <bcp14>MUST</bcp14> be set to TAC_PLUS_AUTHEN_STATUS_GETDATA.
es in </t>
order to change the user' </section>
s </section>
password. It is very <section anchor="AbortinganAuthenticationSession" numbered="true" toc="d
similar to an ASCII login efault">
. The status value <name>Aborting an Authentication Session</name>
TAC_PLUS_AUTHEN_STATUS_GE <t>
TPASS MUST only be used
when requesting The client may prematurely terminate a session by setting the
the "new" password. It MA TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this flag is
Y be set, the data portion of the message may contain a text explaining the reason
sent multiple times. When for the abort. This text will be handled by the server according to the
requesting requirements of the deployment. For details of text encoding, see "Treatment
the "old" of Text Strings" (<xref target="TextEncoding" format="default"/>). For more
password, the status valu details about session termination, refer to "Session Completion" (<xref target="
e MUST be set to SessionCompletion"
TAC_PLUS_AUTHEN_STATUS_GE format="default"/>).
TDATA.
</t> </t>
</section> <t>
</section> In cases of PASS, FAIL, or ERROR, the server can insert a message into
<section anchor="AbortinganAuthenticationSession" server_msg to be displayed to the user.
title="Aborting an Authentication Session"> </t>
<t> <t>
The client may prematurely termin "The Draft" <xref target="THE-DRAFT" format="default"></xref>
ate a session by defined a mechanism to direct authentication requests to an
setting the alternative server. This mechanism is regarded as insecure, is
TAC_PLUS_CONTINUE_FLAG_ABORT flag deprecated, and is not covered here. The client should treat
in TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
the </t>
CONTINUE message. If <t>
this If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is
flag is set, the data indicating that it is experiencing an unrecoverable error and the
portion of the message may contai authentication will proceed as if that host could not be contacted.
n a The data field may contain a message to be printed on an
message administrative console or log.
explaining the reason for the abo </t>
rt. For details of <t>
<xref target="TextEncoding">text If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the
encoding, see</xref>. This information will authentication sequence is restarted with a new START packet from the
be handled by the server client, with a new session Id and seq_no set to 1. This REPLY packet
according to the indicates that the current authen_type value (as specified in the
requirements of the START packet) is not acceptable for this session. The client may try
deployment. The an alternative authen_type.
session is </t>
terminated, for more <t>
details about If a client does not implement the TAC_PLUS_AUTHEN_STATUS_RESTART option,
session termination, refer to then it <bcp14>MUST</bcp14> process the response as if the status was
<xref target="SessionCompletion"/ TAC_PLUS_AUTHEN_STATUS_FAIL.
>. </t>
</t> </section>
<t> </section>
In cases of PASS, FAIL or ERROR, </section>
the server can insert a
message <section anchor="Authorization" numbered="true" toc="default">
into <name>Authorization</name>
server_msg to be displayed to the <t>In the TACACS+ protocol, authorization is the action of determining
user. what a user is allowed to do. Generally, authentication precedes
</t> authorization, though it is not mandatory that a client use the same
<t> service for authentication that it will use for authorization. An
The Draft authorization request may indicate that the user is not authenticated
<xref target="TheDraft">`The Draf (we don't know who they are). In this case, it is up to the server to
t'</xref> determine, according to its configuration, if an unauthenticated user is
defined a mechanism to direct aut allowed the services in question.</t>
hentication requests <t>
to an Authorization does not merely provide yes or no answers, but it may also
alternative server. This mechanis customize the service for the particular user. A common use of authorization
m is regarded as insecure, is is to provision a shell session when a user first logs into a device to
deprecated, and not covered here. administer it. The TACACS+ server might respond to the request by allowing the
The client should treat service, but placing a time restriction on the login shell. For a list of
TAC_PLUS_AUTHEN_STATUS_FOLLOW as common arguments used in authorization, see "Authorization Arguments" (<xref
TAC_PLUS_AUTHEN_STATUS_FAIL target="AuthorizationAttributes" format="default"></xref>).
</t> </t>
<t> <t>
If the status equals In the TACACS+ protocol, an authorization is always a single pair of messages:
TAC_PLUS_AUTHEN_STATUS_ERROR, the a REQUEST from the client followed by a REPLY from the server.
n the </t>
host <t>
is The authorization REQUEST message contains a fixed set of fields that indicate
indicating that it is experiencin how the user was authenticated and a variable set of arguments that describe
g an the services and options for which authorization is requested.
unrecoverable error </t>
and <t>
the The REPLY contains a variable set of response arguments (argument-value pairs)
authentication will that can restrict or modify the client's actions.
proceed as if that host could not </t>
be
contacted. <section anchor="TheAuthorizationREQUESTPacketBody" numbered="true" toc="d
The data field may contain a mess efault">
age to be <name>The Authorization REQUEST Packet Body</name>
printed on <artwork name="" type="" align="left" alt=""><![CDATA[
an
administrative console or log.
</t>
<t>
If the status equals
TAC_PLUS_AUTHEN_STATUS_RESTART, t
hen the
authentication sequence is restar
ted with
a new START
packet
from the
client, with new session Id, and
seq_no set to 1. This REPLY
packet indicates that the
current
authen_type
value (as specified in
the START packet) is
not
acceptable for this
session. The client may
try an alternative authen_type.
</t>
<t>
If a client does not implement TA
C_PLUS_AUTHEN_STATUS_RESTART
option, then it MUST process the
response as if the status was
TAC_PLUS_AUTHEN_STATUS_FAIL.
</t>
</section>
</section>
</section>
<section anchor="Authorization" title="Authorization">
<t>In the TACACS+ Protocol, authorization is the action o
f
determining what a user is allowed to
do. Generally,
authentication
precedes authorization, though it is not mandator
y that a client use
the same service for authentication that it will
use for
authorization. An authorization request may indic
ate
that the user
is
not authenticated (we don't know who
they are). In
this case it
is
up to
the server
to determine, according to its configuration, if
an
unauthenticated
user
is allowed
the services in question.</t>
<t>
Authorization does not merely provide yes or
no answers,
but it may
also customize the service for the
particular user.
A common use of
authorization is to provision a shell session whe
n a user
first logs
into a device to administer it. The
TACACS+
server might respond to
the request by allowing the
service, but placing a time restriction
on the login
shell. For a list of common
arguments used in
authorization, see
the
<xref target="AuthorizationAttributes">Authorizat
ion Arguments section</xref>.
</t>
<t>
In the TACACS+ protocol an
authorization is always a
single pair of
messages: a REQUEST from the client
followed by a REPLY from the
server.
</t>
<t>
The authorization REQUEST message contains a fixe
d set of
fields
that
indicate how the user was authenticated and a
variable
set
of
arguments that describe the
services and options for
which
authorization is requested.
</t>
<t>
The REPLY contains a variable set of response
arguments
(argument-value pairs) that can restrict or
modify the
client's
actions.
</t>
<section anchor="TheAuthorizationREQUESTPacketBody" title
="The Authorization REQUEST Packet Body">
<figure>
<artwork><![CDATA[
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| authen_method | priv_lvl | authen_type | authen_service | | authen_method | priv_lvl | authen_type | authen_service |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user_len | port_len | rem_addr_len | arg_cnt | | user_len | port_len | rem_addr_len | arg_cnt |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_1_len | arg_2_len | ... | arg_N_len | | arg_1_len | arg_2_len | ... | arg_N_len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user ... | user ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
skipping to change at line 1977 skipping to change at line 1678
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_1 ... | arg_1 ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_2 ... | arg_2 ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| ... | ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_N ... | arg_N ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
]]></artwork> ]]></artwork>
</figure> <t>
<t>
authen_method authen_method
</t> </t>
<t> <ul empty="true">
This filed allows the <li>
client to indicate the authentication met
hod used by the <t>
acquire This field allows the client to indicate the authentication method used to
the user information. acquire user information.
</t> </t>
<t> </li>
<list> <li>
<t>
TAC_PLUS_AUTHEN_METH_NOT_ SET := 0x00 TAC_PLUS_AUTHEN_METH_NOT_ SET := 0x00
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_NONE := TAC_PLUS_AUTHEN_METH_NONE :=
0x01 0x01
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_LINE := TAC_PLUS_AUTHEN_METH_LINE :=
0x03 0x03
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_ENAB LE := 0x04 TAC_PLUS_AUTHEN_METH_ENAB LE := 0x04
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_LOCA L TAC_PLUS_AUTHEN_METH_LOCA L
:= 0x05 := 0x05
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_TACA CSPLUS := 0x06 TAC_PLUS_AUTHEN_METH_TACA CSPLUS := 0x06
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_GUES T := 0x08 TAC_PLUS_AUTHEN_METH_GUES T := 0x08
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_RADI US := TAC_PLUS_AUTHEN_METH_RADI US :=
0x10 0x10
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11
</t> </li>
<t> <li>
TAC_PLUS_AUTHEN_METH_RCMD := TAC_PLUS_AUTHEN_METH_RCMD :=
0x20 0x20
</t> </li>
</list>
</t> <li>
<t> As this information is not always
subject to <t> As this information is not always subject to verification, it <bcp14
verification, it is recommended that this >MUST
field is NOT</bcp14> be used in policy evaluation. LINE refers to a
in policy evaluastion. fixed password associated with the terminal line used to gain access.
LINE LOCAL is a client local user database. ENABLE is a command that
refers to a authenticates in order to grant new privileges. TACACSPLUS is, of
fixed course, TACACS+. GUEST is an unqualified guest authentication. RADIUS
password associated with the terminal lin is the RADIUS authentication protocol. RCMD refers to authentication
e provided via the R-command protocols from Berkeley Unix.
used to gain access.
LOCAL KRB5 <xref
is a target="RFC4120"/> and KRB4 <xref target="KERB"/>
client local user are Kerberos versions 5 and 4.</t>
database. ENABLE is a command that
authenticates </li>
in <li> <t> As mentioned above, this field is used by the client to indicate how
order to grant new privileges. TACACSPLUS it performed the authentication. One of the options
is, of (TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06) is TACACS+ itself, and so the detail
course, of how the client performed this option is given in "Authentication" (<xref
TACACS+. target="Authentication" format="default"></xref>). For all other options,
GUEST is an unqualified guest such as KRB and RADIUS, the TACACS+ protocol did not play any part in the
authentication. RADIUS authentication phase; as those interactions were not conducted using the
is TACACS+ protocol, they will not be documented here. For implementers of
the Radius authentication clients who need details of the other protocols, please refer to the
protocol. respective Kerberos <xref target="RFC4120" format="default"></xref> and RADIUS
RCMD <xref target="RFC3579" format="default"></xref> RFCs. </t></li>
refers to </ul>
authentication <t>
provided via the R-command
protocols
from
Berkeley
Unix. KRB5 and KRB4 are Kerberos version
5 and 4.
</t>
<t>
As mentioned above, this field is used
by the client to indicate how it performe
d the authentication. One of the
options (TAC_PLUS_AUTHEN_METH_TACACSPLUS
:= 0x06)
is TACACS+ itself, and so the detail of h
ow the client performed this
option is given in
<xref target="Authentication">Authenticat
ion Section</xref>.
For all other options, such as KRB and RA
DIUS, then
TACACS+ protocol did not play any part in
the authentication phase; as those interactions were not conducted using
the TACACS+ protocol they will not be doc
umented here. For
implementers of clients who need details
of the other protocols, please
refer to the respective <xref target="RFC
4120">Kerberos</xref> and <xref target="RFC3579">RADIUS</xref> RFCs.
</t>
<t>
priv_lvl priv_lvl
</t> </t>
<t> <ul empty="true">
This field is used in the same way as the <li>
priv_lvl field in <t>
authentication request and This field is used in the same way as the priv_lvl field in authentication
is described in the request and is described in "Privilege Levels" (<xref target="PrivilegeLevel"
<xref target="PrivilegeLevel">Privilege L format="default"></xref>). It indicates the user's
evel section</xref> current privilege level.
below. It indicates the users current pri </t>
vilege </li>
level. </ul>
</t> <t>
<t>
authen_type authen_type
</t> </t>
<t> <ul empty="true">
This field corresponds to the authen_type
field in the <li> <t> This field corresponds to the authen_type field in "Authentication" (<x
<xref target="Authentication">authenticat ref
ion section</xref> target="Authentication" format="default"></xref>). It indicates
above. It indicates the type of authentic the type of authentication that was performed. If this information is not
ation that available, then the client will set authen_type to
was TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. This value is valid only in
performed. If authorization and accounting requests.
this information is not available, then t </t>
he client will </li>
set </ul>
authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_ <t>
SET := 0x00. This
value is
valid only in authorization and accountin
g requests.
</t>
<t>
authen_service authen_service
</t> </t>
<t> <ul empty="true">
This field is the same as the authen_serv <li>
ice field in the <t>
<xref target="Authentication">authenticat This field is the same as the authen_service field in "Authentication" (<xref
ion section</xref> target="Authentication" format="default"></xref>). It indicates
above. It indicates the service through w the service through which the user authenticated.
hich the </t>
user </li>
authenticated. </ul>
</t>
<t> <t>
user, user_len user, user_len
</t> </t>
<t> <ul empty="true">
This field contains the user's account na <li>
me. The user_len MUST <t>
indicate the length of the user field, in This field contains the user's account name. The user_len <bcp14>MUST</bcp14>
bytes. indicate the length of the user field, in bytes.
</t> </t>
<t> </li>
</ul>
<t>
port, port_len port, port_len
</t> </t>
<t>
This field matches the port field in the <ul empty="true">
<xref target="Authentication">authenticat <li>
ion section</xref> <t>
above. The port_len indicates the length This field matches the port field in "Authentication" (<xref
of the port field, in target="Authentication" format="default"></xref>). The port_len
bytes. indicates the length of the port field, in bytes.
</t> </t>
<t> </li>
</ul>
<t>
rem_addr, rem_addr_len rem_addr, rem_addr_len
</t> </t>
<t>
This field matches the rem_addr field in <ul empty="true">
the <li>
<xref target="Authentication">authenticat <t>
ion section</xref> This field matches the rem_addr field in "Authentication" (<xref target="
above. The rem_addr_len indicates the len Authentication"
gth of the port field, format="default"></xref>). The rem_addr_len indicates the
in length of the port field, in bytes.
bytes. </t>
</t> </li>
<t> </ul>
<t>
arg_cnt arg_cnt
</t> </t>
<t> <ul empty="true">
The number of authorization arguments to <li>
follow <t>
</t> This represents the number of authorizati
<t> on arguments to follow.
</t>
</li>
</ul>
<t>
arg_1 ... arg_N, arg_1_len .... arg_N_len arg_1 ... arg_N, arg_1_len .... arg_N_len
</t> </t>
<t> <ul empty="true">
The arguments are the primary elements of <li>
the authorization
interaction. In the request packet, they <t>
describe the specifics of These arguments are the primary elements of the authorization
the authorization that is being requested interaction. In the request packet, they describe the specifics of the
. authorization that is being requested. Each argument is encoded in
Each argument is encoded the packet as a single arg field (arg_1... arg_N) with a
in the packet as a single corresponding length field (which indicates the length of each
arg field (arg_1... argument in bytes).
arg_N) with a </t>
corresponding length fields </li>
(which
indicates the length <li> <t>
of each The authorization arguments in both the REQUEST and the REPLY are
argument in bytes). argument-value pairs. The argument and the value are in a single
</t> string and are separated by either a "=" (0X3D) or a "*" (0X2A). The
<t> equals sign indicates a mandatory argument. The asterisk indicates an
The authorization arguments in both the R optional one. For details of text encoding, see "Treatment of Text String
EQUEST and s" (<xref target="TextEncoding"
the REPLY format="default"/>).
are </t>
argument-value pairs. The argument </li>
and the value are in a <li>
single
string and are <t>
separated by either a "=" (0X3D) An argument name <bcp14>MUST NOT</bcp14> contain either of the
or a separators. An argument value <bcp14>MAY</bcp14> contain the
"*" separators. This means that the arguments must be parsed until the
(0X2A). The first separator is encountered; all characters in the argument, after
equals sign indicates a mandatory argumen this separator, are interpreted as the argument value.
t. The </t>
asterisk </li>
indicates an <li>
optional one. For details of <t>
<xref target="TextEncoding">text encoding Optional arguments are ones that may be disregarded by either client
, see</xref>. or server. Mandatory arguments require that the receiving side can
</t> handle the argument, that is, its implementation and configuration
<t> includes the details of how to act on it. If the client receives a
An argument name MUST NOT contain either mandatory argument that it cannot handle, it <bcp14>MUST</bcp14>
of the consider the authorization to have failed. The value part of an
separators. An argument-value pair may be empty, that is, the length of the value may
argument value MAY contain the be zero.
separators. This means that the </t>
arguments must be parsed until the </li>
first separator is encountered, <li>
all characters in the argument, <t>
after this separator, are Argument-value strings are not NULL terminated; rather, their length
interpreted as the argument value. value indicates their end. The maximum length of an argument-value
</t> string is 255 characters. The minimum is two characters (one
<t> name-value character and the separator).
Optional arguments are ones that may be d </t>
isregarded </li>
by either <li>
client or <t>
server. Mandatory arguments Though the arguments allow extensibility, a common core set of authorization
require that the receiving arguments <bcp14>SHOULD</bcp14> be supported by clients and servers; these are
side listed in "Authorization Arguments" (<xref target="AuthorizationAttributes"
can handle the argument, that is: its imp format="default"></xref>).
lementation and </t>
configuration includes the details of how </li>
to act on it. If the </ul>
client </section>
receives <section anchor="TheAuthorizationREPLYPacketBody" numbered="true" toc="def
a mandatory argument that it cannot handl ault">
e, it <name>The Authorization REPLY Packet Body</name>
MUST <artwork name="" type="" align="left" alt=""><![CDATA[
consider the authorization to
have failed. The value part of an
argument-value pair may be empty, that is
: the length of the value
may be zero.
</t>
<t>
Argument-value strings are not NULL termi
nated,
rather their
length value
indicates their end. The
maximum length of an
argument-value
string is 255
characters. The minimum is two
characters (one name-value character and
the separator)
</t>
<t>
Though the arguments allow extensibility,
a common core set of
authorization arguments SHOULD be support
ed by clients and
servers, these are listed in the
<xref target="AuthorizationAttributes">Au
thorization Arguments</xref>
section below.
</t>
</section>
<section anchor="TheAuthorizationREPLYPacketBody" title="
The Authorization REPLY Packet Body">
<figure>
<artwork><![CDATA[
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| status | arg_cnt | server_msg len | | status | arg_cnt | server_msg len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
+ data_len | arg_1_len | arg_2_len | + data_len | arg_1_len | arg_2_len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| ... | arg_N_len | server_msg ... | ... | arg_N_len | server_msg ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| data ... | data ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_1 ... | arg_1 ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_2 ... | arg_2 ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| ... | ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_N ... | arg_N ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
]]></artwork> ]]></artwork>
</figure> <t>
<t>
status This field indicates the authoriza status
tion status </t>
</t> <ul empty="true" spacing="normal">
<t>
<list>
<t>
TAC_PLUS_AUTHOR_STATUS_PA
SS_ADD := 0x01
</t>
<t>
TAC_PLUS_AUTHOR_STATUS_PA
SS_REPL := 0x02
</t>
<t>
TAC_PLUS_AUTHOR_STATUS_FA
IL := 0x10
</t>
<t>
TAC_PLUS_AUTHOR_STATUS_ER
ROR :=
0x11
</t>
<t>
TAC_PLUS_AUTHOR_STATUS_FO
LLOW := 0x21
</t>
</list>
</t>
<t>
server_msg, server_msg_len <li>
</t> <t>This field indicates the authorization status.
<t> </t>
This is a string that may be presented to </li>
the <li>
user. The <t>TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01</t>
server_msg_len indicates the length of th <t indent="4"> If the status equals
e server_msg TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the arguments specified
field, in in the request are authorized and the arguments in the
bytes. For details of response <bcp14>MUST</bcp14> be applied according to the rules
<xref target="TextEncoding">text encoding described above.
, see</xref>. </t>
</t> <t indent="4">To approve the authorization with no modifications,
<t> the
server sets the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and
the arg_cnt to 0.</t>
</li>
<li>
<t>TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02</t>
<t indent="4">If the status equals
TAC_PLUS_AUTHOR_STATUS_PASS_REPL, then the client
<bcp14>MUST</bcp14> use the authorization argument-value pairs
(if any) in the response instead of the authorization
argument-value pairs from the request.
</t>
</li>
<li>
<t>TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10</t>
<t indent="4">If the status equals
TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested authorization
<bcp14>MUST</bcp14> be denied.
</t>
</li>
<li>
<t>TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11</t>
<t indent="4">A status of TAC_PLUS_AUTHOR_STATUS_ERROR
indicates an error occurred on the server. For the differences
between ERROR and FAIL, refer to "Session Completion" (<xref
target="SessionCompletion" format="default"></xref>). None of
the arg values have any relevance if an ERROR is set and must
be ignored.
</t>
</li>
<li>
<t>TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21</t>
<t indent="4">When the status equals
TAC_PLUS_AUTHOR_STATUS_FOLLOW, the arg_cnt <bcp14>MUST</bcp14>
be 0. In that case, the actions to be taken and the contents
of the data field are identical to the
TAC_PLUS_AUTHEN_STATUS_FOLLOW status for authentication.
</t>
</li>
</ul>
<t>
server_msg, server_msg_len
</t>
<ul empty="true">
<li>
<t>
This is a string that may be presented to the user. The server_msg_len
indicates the length of the server_msg field, in bytes. For details of
text encoding, see "Treatment of Text Strings" (<xref
target="TextEncoding" format="default"/>).
</t>
</li>
</ul>
<t>
data, data_len data, data_len
</t> </t>
<t> <ul empty="true">
This is a string that may be presented on <li>
an <t>
administrative
display, This is a string that may be presented on an administrative display, console,
console or log. The or log. The decision to present this message is client specific. The data_len
decision indicates the length of the data field, in bytes. For details of text
to present encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="d
this efault"/>).
message is </t>
client specific. </li>
The data_len indicates the length of </ul>
the <t>
data field, in bytes. For
details of
<xref target="TextEncoding">text encoding
, see</xref>.
</t>
<t>
arg_cnt arg_cnt
</t> </t>
<t> <ul empty="true">
The number of authorization arguments to <li>
follow. <t>
</t> This represents the number of authorization arguments to follow.
<t> </t>
</li>
</ul>
<t>
arg_1 ... arg_N, arg_1_len .... arg_N_len arg_1 ... arg_N, arg_1_len .... arg_N_len
</t> </t>
<t> <ul empty="true">
The arguments describe the specifics of <li>
the authorization that is <t>
being requested. For details of the The arguments describe the specifics of the authorization that is
content of the args, refer to: being requested. For details of the content of the args, refer to
<xref target="AuthorizationAttributes">Au "Authorization Arguments" (<xref target="AuthorizationAttributes"
thorization Arguments</xref> format="default"></xref>). Each argument is encoded in the packet as a
section below. single arg field (arg_1... arg_N) with a corresponding length field
Each argument is encoded in the packet as (which indicates the length of each argument in bytes).
a single </t>
arg field (arg_1... arg_N) with a corresp
onding length fields
(which
indicates the length of each argument in
bytes).
</t>
<t>
If the status equals TAC_PLUS_AUTHOR_STAT
US_FAIL,
then the
requested authorization MUST be denied.
</t>
<t>
If the status equals TAC_PLUS_AUTHOR_STAT
US_PASS_ADD,
then the
arguments specified in the request are
authorized
and the
arguments
in
the response MUST be applied according to
the rules described
above.
</t>
<t>
If the status equals TAC_PLUS_AUTHOR_STAT
US_PASS_REPL
then the
client MUST use the authorization argumen
t-value pairs (if any) in
the response,
instead of the authorization argument-val
ue pairs
from the request.
</t>
<t>
To approve the
authorization with no
modifications, the server sets
the status to
TAC_PLUS_AUTHOR_STATUS_PASS_ADD and
the arg_cnt
to
0.
</t>
<t>
A status of TAC_PLUS_AUTHOR_STATUS_ERROR
indicates an
error
occurred
on the server. For the differences betwee
n ERROR and FAIL,
refer to
<xref target="SessionCompletion">Session
Completion</xref>. None of
the
arg values have any
relevance if an
ERROR is set, and
must be
ignored.
</t>
<t>
When the status equals TAC_PLUS_AUTHOR_ST
ATUS_FOLLOW,
then the
arg_cnt
MUST be 0. In that case, the actions
to be taken and the
contents
of the data field are
identical to the
TAC_PLUS_AUTHEN_STATUS_FOLLOW status
for Authentication.
</t> </li>
</section> </ul>
</section>
<section anchor="Accounting" title="Accounting"> </section>
<t> </section>
Accounting is typically the third action after <section anchor="Accounting" numbered="true" toc="default">
authentication and <name>Accounting</name>
authorization. But again, neither <t>
authentication nor authorization Accounting is typically the third action after authentication and
is authorization. But again, neither authentication nor authorization is
required. Accounting required. Accounting is the action of recording what a user is doing
is the action of recording what a user is and/or has done. Accounting in TACACS+ can serve two purposes: it may
doing, be used as an auditing tool for security services, and it may also be
and/or used to account for services used such as in a billing
has done. Accounting in TACACS+ can serve environment. To this end, TACACS+ supports three types of accounting
two records: Start records indicate that a service is about to begin, Stop
purposes: It records indicate that a service has just terminated, and Update
may be records are intermediate notices that indicate that a service is still
used as an auditing tool for security services. being performed. TACACS+ accounting records contain all the
It may also be used information used in the authorization records and also contain
to account for services used, such accounting-specific information such as start and stop times (when
as in a appropriate) and resource usage information. A list of accounting
billing environment. To arguments is defined in "Accounting Arguments" (<xref target="AccountingA
this end, TACACS+ ttributes"
supports three types of format="default"/>).
accounting records. Start </t>
records <section anchor="TheAccountREQUESTPacketBody" numbered="true" toc="default
indicate that a ">
service is about <name>The Account REQUEST Packet Body</name>
to begin. Stop records <artwork name="" type="" align="left" alt=""><![CDATA[
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 arguments is
defined in the
<xref target="Accounting">accounting section</xre
f>.
</t>
<section anchor="TheAccountREQUESTPacketBody" title="The
Account REQUEST Packet Body">
<figure>
<artwork><![CDATA[
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 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 | | flags | authen_method | priv_lvl | authen_type |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| authen_service | user_len | port_len | rem_addr_len | | authen_service | user_len | port_len | rem_addr_len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_cnt | arg_1_len | arg_2_len | ... | | arg_cnt | arg_1_len | arg_2_len | ... |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_N_len | user ... | arg_N_len | user ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
skipping to change at line 2464 skipping to change at line 2096
| arg_1 ... | arg_1 ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_2 ... | arg_2 ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| ... | ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_N ... | arg_N ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
]]></artwork> ]]></artwork>
</figure> <t>
<t>
flags flags
</t> </t>
<t>
<ul empty="true" spacing="normal">
<li>
<t>
This holds bitmapped flags. This holds bitmapped flags.
</t> </t>
<t> </li>
<list> <li>
<t> <t>Valid values are:
</t>
</li>
<li>
TAC_PLUS_ACCT_FLAG_START := 0x02 TAC_PLUS_ACCT_FLAG_START := 0x02
</t> </li>
<t> <li>
TAC_PLUS_ACCT_FLAG_STOP : = 0x04 TAC_PLUS_ACCT_FLAG_STOP : = 0x04
</t> </li>
<t> <li>
TAC_PLUS_ACCT_FLAG_WATCHD OG := 0x08 TAC_PLUS_ACCT_FLAG_WATCHD OG := 0x08
</t> </li>
</list> </ul>
</t> <t>
<t> All other fields are defined in "Authentication" (<xref
All other fields are defined in the autho target="Authentication"></xref>) and "Authorization" (<xref
rization and target="Authorization"></xref>) and have the same
authentication semantics. They provide details for the conditions on the client, and
sections above and have the same authentication context, so that these details may be logged for
semantics. They accounting purposes.
provide details for the conditions on the </t>
client, and
authentication context, so that these det <t>
ails may be logged for See "Accounting Arguments" (<xref target="AccountingAttributes" format="d
accounting purposes. efault"></xref>) for
</t> the dictionary of arguments relevant to accounting.
<t> </t>
See the </section>
<xref target="AccountingAttributes">Accountin <section anchor="TheAccountingREPLYPacketBody" numbered="true" toc="defaul
g Arguments section</xref> for t">
the <name>The Accounting REPLY Packet Body</name>
dictionary <t>
of The purpose of accounting is to record the action that has occurred on
arguments relevant to accounting. the client. The server <bcp14>MUST</bcp14> reply with success only
</t> when the accounting request has been recorded. If the server did not
</section> record the accounting request, then it <bcp14>MUST</bcp14> reply with
<section anchor="TheAccountingREPLYPacketBody" title="The ERROR.
Accounting REPLY Packet Body"> </t>
<t> <artwork name="" type="" align="left" alt=""><![CDATA[
The purpose of accounting is to record th
e action that has
occurred on the client.
The server
MUST
reply with success
only when
the accounting request
has been recorded.
If the server did not
record the accounting
request then it MUST
reply with ERROR.
</t>
<figure>
<artwork><![CDATA[
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 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 | | server_msg len | data_len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| status | server_msg ... | status | server_msg ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| data ... | data ...
+----------------+ +----------------+
]]></artwork> ]]></artwork>
</figure> <t>
status
<t> </t>
status <ul empty="true" spacing="normal">
</t> <li>
<t> <t>
This is the return status. Values are: This is the return status.
</t> </t>
<t> </li>
<list> <li>
<t> <t>
Values are:
</t>
</li>
<li>
TAC_PLUS_ACCT_STATUS_SUCC ESS := 0x01 TAC_PLUS_ACCT_STATUS_SUCC ESS := 0x01
</t> </li>
<t> <li>
TAC_PLUS_ACCT_STATUS_ERRO R := TAC_PLUS_ACCT_STATUS_ERRO R :=
0x02 0x02
</t> </li>
<t> <li>
TAC_PLUS_ACCT_STATUS_FOLL <t>TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21</t
OW := 0x21 >
</t> <t indent="4">When the status equals
</list> TAC_PLUS_ACCT_STATUS_FOLLOW, the
</t> actions to be taken and the contents
<t> of the data field are identical to the
server_msg, server_msg_len TAC_PLUS_AUTHEN_STATUS_FOLLOW status
</t> for authentication.
<t> </t>
This is a string that may be presented to </li>
the </ul>
user. The <t>
server_msg_len indicates the length of th server_msg, server_msg_len
e server_msg </t>
field, in <ul empty="true">
bytes. For details of <li>
<xref target="TextEncoding">text encoding <t>
, see</xref>. This is a string that may be presented to the user. The server_msg_len
</t> indicates the length of the server_msg field, in bytes. For details of
<t> text encoding, see "Treatment of Text Strings" (<xref target="TextEncodin
g" format="default"/>).
</t>
</li>
</ul>
<t>
data, data_len data, data_len
</t> </t>
<t> <ul empty="true">
This is a string that may be presented on <li>
an <t>
administrative This is a string that may be presented on an administrative display,
display, console, or log. The decision to present this message is client
console or log. The decision specific. The data_len indicates the length of the data field, in
to present bytes. For details of text encoding, see "Treatment of Text Strings" (<xr
this ef target="TextEncoding"
message is format="default"/>).
client </t>
specific. The data_len indicates the leng </li>
th of </ul>
the
data field, in <t>
bytes. For details of TACACS+ accounting is intended to record various types of events on clients,
<xref target="TextEncoding">text encoding for example: login sessions, command entry, and others as required by the
, see</xref>. client implementation. These events are collectively referred to in "The
</t> Draft" <xref target="THE-DRAFT" format="default"/> as "tasks".
<t> </t>
When the status equals TAC_PLUS_ACCT_STAT <t>
US_FOLLOW, The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start
then the accounting message. Start messages will only be sent once when a task
actions to is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is a stop
be taken and the contents of the record and that the task has terminated. The
data field are TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record.
identical </t>
to the
TAC_PLUS_AUTHEN_STATUS_FOLLOW status for <table anchor="accounting-packets">
Authentication. <name>Summary of Accounting Packets</name>
</t> <thead>
<t> <tr>
TACACS+ accounting is intended to record <th>Watchdog</th>
various types of events <th>Stop</th>
on <th>Start</th>
clients, for example: login sessions, com <th>Flags &amp; 0xE</th>
mand entry, and others <th>Meaning</th>
as </tr>
required by the client implementation. Th </thead>
ese events are <tbody>
collectively referred to in <tr>
<xref target="TheDraft">`The Draft'</xref <td>0</td>
> <td>0</td>
as "tasks". <td>0</td>
</t> <td>0</td>
<t> <td>INVALID</td>
The TAC_PLUS_ACCT_FLAG_START flag indicat </tr>
es that this <tr>
is a start <td>0</td>
accounting message. Start messages will <td>0</td>
only be <td>1</td>
sent once when <td>2</td>
a <td>Start Accounting Record</td>
task </tr>
is started. The <tr>
TAC_PLUS_ACCT_FLAG_STOP indicates that th <td>0</td>
is <td>1</td>
is <td>0</td>
a <td>4</td>
stop <td>Stop Accounting Record</td>
record and that the task has terminated. </tr>
The <tr>
TAC_PLUS_ACCT_FLAG_WATCHDOG flag means th <td>0</td>
at this is <td>1</td>
an update <td>1</td>
record. <td>6</td>
</t> <td>INVALID</td>
<t> </tr>
Summary of Accounting Packets <tr>
<figure> <td>1</td>
<artwork><![CDATA[ <td>0</td>
+----------+-------+-------+-------------+-------------------------+ <td>0</td>
| Watchdog | Stop | Start | Flags & 0xE | Meaning | <td>8</td>
+----------+-------+-------+-------------+-------------------------+ <td>Watchdog, no update</td>
| 0 | 0 | 0 | 0 | INVALID | </tr>
| 0 | 0 | 1 | 2 | Start Accounting Record |
| 0 | 1 | 0 | 4 | Stop Accounting Record | <tr>
| 0 | 1 | 1 | 6 | INVALID | <td>1</td>
| 1 | 0 | 0 | 8 | Watchdog, no update | <td>0</td>
| 1 | 0 | 1 | A | Watchdog, with update | <td>1</td>
| 1 | 1 | 0 | C | INVALID | <td>A</td>
| 1 | 1 | 1 | E | INVALID | <td>Watchdog, with update</td>
+----------+-------+-------+-------------+-------------------------+ </tr>
]]></artwork> <tr>
</figure> <td>1</td>
The START and STOP flags are mutually exc <td>1</td>
lusive. <td>0</td>
</t> <td>C</td>
<t>The WATCHDOG flag is used by the client to com <td>INVALID</td>
municate ongoing </tr>
status of a long-running task. Update rec
ords are sent at the <tr>
client's discretion. The frequency of the <td>1</td>
update depends upon the <td>1</td>
intended application: A watchdog to provi <td>1</td>
de progress indication <td>E</td>
will require higher frequency than a dail <td>INVALID</td>
y keep-alive. </tr>
When the
WATCHDOG </tbody>
flag is set along with the START </table>
flag, it indicates that the
update <t>
record provides additional or updated arg The START and STOP flags are mutually
uments from the exclusive.
original START record. If the </t>
START <t>The WATCHDOG flag is used by the client to communicate ongoing
flag status of a long-running task. Update records are sent at the client's
is not set, then this discretion. The frequency of the update depends upon the intended
indicates application: a watchdog to provide progress indication will require
only that higher frequency than a daily keep-alive. When the WATCHDOG flag is
task is still running, and no new informa set along with the START flag, it indicates that the update record
tion is provides additional or updated arguments from the original START
provided (servers MUST ignore any argumen record. If the START flag is not set, then this indicates only that
ts). The task is still running, and no new information is provided (servers
STOP flag MUST NOT <bcp14>MUST</bcp14> ignore any arguments). The STOP flag <bcp14>MUST
be set in NOT</bcp14> be set in conjunction with the WATCHDOG flag.
conjunction </t>
with the <t>
WATCHDOG flag. The server <bcp14>MUST</bcp14> respond
</t> with TAC_PLUS_ACCT_STATUS_ERROR if the
<t>
The Server MUST respond with TAC_PLUS_ACC
T_STATUS_ERROR if the
client requests an INVALID option. client requests an INVALID option.
</t> </t>
</section> </section>
</section> </section>
<section anchor="AttributeValuePairs" title="Argument-Value Pairs <section anchor="AttributeValuePairs" numbered="true" toc="default">
"> <name>Argument-Value Pairs</name>
<t> <t>
TACACS+ is intended to be an extensible protocol. TACACS+ is intended to be an extensible
The protocol. The arguments used in Authorization
arguments and Accounting are not limited by this
used in document. Some arguments are defined below
Authorization and Accounting are not for common use cases. Clients
limited by this document. <bcp14>MUST</bcp14> use these arguments when
Some arguments supporting the corresponding use cases.
are </t>
defined below for common use <section anchor="ValueEncoding" numbered="true" toc="default">
cases, clients MUST <name>Value Encoding</name>
use these <t>
arguments when supporting All argument values are encoded as strings. For details of text
the corresponding use cases. encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" fo
</t> rmat="default"/>). The
<section anchor="ValueEncoding" title="Value Encoding"> following type representations <bcp14>SHOULD</bcp14> be followed.
<t> </t>
All argument values are encoded as string <t>Numeric</t>
s. For details of
<xref target="TextEncoding">text encoding
, see</xref>.
The following type representations SHOULD
be followed
</t>
<t>Numeric</t> <ul empty="true">
<t> <li>
All numeric values in an argument-value s <t>
tring are All numeric values in an argument-value string are provided as decimal
provided as numbers, unless otherwise stated. All arguments include a length
decimal field, and TACACS+ implementations <bcp14>MUST</bcp14> verify that
numbers, unless otherwise they can accommodate the lengths of numeric arguments before
stated. All arguments include a length fi attempting to process them. If the length cannot be accommodated, then
eld, and the argument <bcp14>MUST</bcp14> be regarded as not handled and the
TACACS+ implementations MUST verify that logic in "Authorization" (<xref target="TheAuthorizationREQUESTPacketBody
they can accommodate the lengths of numeric "
arguments before attempting to process th format="default"></xref>) regarding the processing
em. of arguments <bcp14>MUST</bcp14> be applied.
If the length cannot be accommodated then </t>
the argument MUST be regarded as not handled and the </li>
logic in <xref target="TheAuthorizationRE </ul>
QUESTPacketBody">authorization section</xref> regarding the processing of argum
ents MUST be applied. <t>Boolean</t>
</t> <ul empty="true">
<t>Boolean</t> <li>
<t> <t>
All Boolean arguments are encoded with All Boolean arguments are encoded with
values "true" or values "true" or "false".
"false".
</t> </t>
<t>IP-Address</t> </li>
<t> </ul>
It is recommended that hosts be specified <t>IP-Address</t>
as a IP <ul empty="true">
address so <li>
as <t>
to It is recommended that hosts be specified as an IP address so as to avoid any
avoid any ambiguities. For details of ambiguities. For details of text encoding, see "Treatment of Text Strings" (<xre
<xref target="TextEncoding">text encoding f target="TextEncoding"
, see</xref>. IPv4 address are specified as octet format="default"/>). IPv4 addresses are specified as octet numerics separated by
numerics separated dots ('.'). IPv6 address text representation is defined in <xref target="RFC5952
by dots "
('.'), IPv6 address text representation format="default"/>.
defined in </t>
<xref target="RFC5952">RFC 5952</xref>. </li>
</t> </ul>
<t>Date Time</t> <t>Date Time</t>
<t> <ul empty="true">
Absolute date/times are specified in seco <li>
nds since the <t>
epoch, Absolute date/times are specified in seconds since the epoch, 12:00am,
12:00am Jan January 1, 1970. The time zone <bcp14>MUST</bcp14> be UTC
1 unless a time zone
1970. The timezone MUST be UTC unless argument is specified.
a timezone </t>
argument is </li>
specified. </ul>
</t> <t>String</t>
<t>String</t> <ul empty="true">
<t>Many values have no specific type representati <li>
on and are <t>Many values have no specific type representation and are
interpreted as plain strings.</t> interpreted as plain strings.</t>
<t>Empty Values</t> </li>
<t> </ul>
Arguments may be submitted with no value, <t>Empty Values</t>
in which case they <ul empty="true">
consist of the name and the mandatory or <li>
optional separator. For <t>
example, the argument "cmd" which has no Arguments may be submitted with no value, in which case they consist of the
value is transmitted as a name and the mandatory or optional separator. For example, the argument "cmd",
string of four characters "cmd=" which has no value, is transmitted as a string of four characters "cmd=".
</t> </t>
</section> </li>
<section anchor="AuthorizationAttributes" title="Authoriz </ul>
ation Arguments"> </section>
<t>
<section anchor="AuthorizationAttributes" numbered="true" toc="default">
<name>Authorization Arguments</name>
<t>
service (String) service (String)
</t> </t>
<t> <ul empty="true">
The primary service. Specifying a service <li>
argument <t>
indicates The primary service. Specifying a service argument indicates that this is a
that request for authorization or accounting of that service. For example:
this is a request for authorization or "shell", "tty-server", "connection", "system" and "firewall"; others may be
accounting of that chosen for the required application. This argument <bcp14>MUST</bcp14> always
service. be included.
For example: "shell", "tty-server", </t>
"connection", "system" </li>
and </ul>
"firewall", others may be chosen for the <t>
required application. This
argument MUST always
be
included.
</t>
<t>
protocol (String) protocol (String)
</t> </t>
<t> <ul empty="true">
the protocol field may be used to indicat <li>
e a subset of a service. <t>A field that may be used to indicate a subset of a service.
</t> </t>
<t> </li>
</ul>
<t>
cmd (String) cmd (String)
</t> </t>
<t> <ul empty="true">
a shell (exec) command. This indicates th <li>
e command <t>
name of the A shell (exec) command. This indicates the command name of the command that is
command that is to be run. The "cmd" argu to be run. The "cmd" argument <bcp14>MUST</bcp14> be specified if service
ment MUST be specified equals "shell".
if </t>
service equals "shell". </li>
</t> <li>
<t>Authorization of shell commands is a common us <t>Authorization of shell commands is a common use case for the
e-case for the TACACS+ protocol. Command Authorization generally takes one of two
TACACS+ protocol. Command Authorization g forms: session based or command based.
enerally takes one of two </t>
forms: session-based and command-based. </li>
</t> <li>
<t>For session-based shell authorization, the "cm <t>For session-based shell authorization, the "cmd" argument will have
d" an empty value. The client determines which commands are allowed in a
argument will session according to the arguments present in the authorization.
have an empty </t>
value. The client determines </li>
which commands are allowed <li>
in a session according to the arguments <t>In command-based authorization, the client requests that the server
present in the determine whether a command is allowed by making an authorization
authorization. request for each command. The "cmd" argument will have the command
</t> name as its value.</t>
<t>In command-based authorization, the client req </li>
uests that </ul>
the <t>
server determine whether a command is all
owed by making an
authorization request for each command. T
he "cmd" argument will
have the command name as its value.</t>
<t>
cmd-arg (String) cmd-arg (String)
</t> </t>
<t> <ul empty="true">
an argument to a shell (exec) command. Th <li>
is indicates <t>
an An argument to a shell (exec) command. This indicates an argument for
argument the shell command that is to be run. Multiple cmd-arg arguments may
for be specified, and they are order dependent.
the shell command that is to be run. </t>
Multiple cmd-arg </li>
arguments </ul>
may be specified, and they <t>
are order dependent.
</t>
<t>
acl (Numeric) acl (Numeric)
</t> </t>
<t> <ul empty="true">
a number representing a connection access <li>
list. <t>
Applicable A number representing a connection access list. Applicable only to
only to session-based shell authorization. For details of text encoding, see
session-based shell authorization. For de "Treatment of Text Strings" (<xref target="TextEncoding"
tails of format="default"/>).
<xref target="TextEncoding">text encoding </t>
, see</xref>. </li>
</t> </ul>
<t> <t>
inacl (String) inacl (String)
</t> </t>
<t> <ul empty="true">
identifier (name) of an interface input a <li>
ccess <t>
list. For details of The identifier (name) of an interface input access list. For details of text
<xref target="TextEncoding">text encoding encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="d
, see</xref>. efault"/>).
</t> </t>
<t> </li>
</ul>
<t>
outacl (String) outacl (String)
</t> </t>
<t> <ul empty="true">
identifier (name) of an interface output <li>
access <t>
list. For details of The identifier (name) of an interface output access list. For details of text
<xref target="TextEncoding">text encoding encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="d
, see</xref>. efault"/>).
</t> </t>
<t> </li>
</ul>
<t>
addr (IP-Address) addr (IP-Address)
</t> </t>
<t> <ul empty="true">
a network address <li>
</t> <t>
<t> A network address.
</t>
</li>
</ul>
<t>
addr-pool (String) addr-pool (String)
</t> </t>
<t> <ul empty="true">
The identifier of an address pool from wh <li>
ich the <t>
client can The identifier of an address pool from which the client can assign an
assign address.
an address. </t>
</t> </li>
<t> </ul>
<t>
timeout (Numeric) timeout (Numeric)
</t> </t>
<t> <ul empty="true">
an absolute timer for the connection (in <li>
minutes). A <t>
value of An absolute timer for the connection (in minutes). A value of zero
zero indicates no timeout.
indicates no timeout. </t>
</t> </li>
<t> </ul>
<t>
idletime (Numeric) idletime (Numeric)
</t> </t>
<t> <ul empty="true">
an idle-timeout for the connection (in mi <li>
nutes). A <t>
value of zero An idle-timeout for the connection (in minutes). A value of zero
indicates no timeout. indicates no timeout.
</t> </t>
<t> </li>
</ul>
<t>
autocmd (String) autocmd (String)
</t> </t>
<t> <ul empty="true">
an auto-command to run. Applicable only t <li>
o session-based shell <t>
authorization. An auto-command to run. Applicable only to session-based shell authorization.
</t> </t>
<t> </li>
</ul>
<t>
noescape (Boolean) noescape (Boolean)
</t> </t>
<t> <ul empty="true">
Prevents user from using an escape <li>
character. Applicable <t>
only to Prevents the user from using an escape character. Applicable only to
session-based shell authorization. session-based shell authorization.
</t> </t>
<t> </li>
</ul>
<t>
nohangup (Boolean) nohangup (Boolean)
</t> </t>
<t> <ul empty="true">
Boolean. Do not disconnect after an autom <li>
atic command. <t>
Applicable Boolean. Do not disconnect after an automatic command. Applicable
only to session-based shell authorization only to session-based shell authorization.
. </t>
</t> </li>
<t> </ul>
<t>
priv-lvl (Numeric) priv-lvl (Numeric)
</t> </t>
<t> <ul empty="true">
privilege level to be assigned. Please re <li>
fer to the <t>
<xref target="PrivilegeLevel">Privilege L The privilege level to be assigned. Please refer to "Privilege Levels" (<xref
evel section</xref> target="PrivilegeLevel" format="default"></xref>).
below. </t>
</t> </li>
</section> </ul>
<section anchor="AccountingAttributes" title="Accounting
Arguments"> </section>
<t> <section anchor="AccountingAttributes" numbered="true" toc="default">
The following arguments are defined for T <name>Accounting Arguments</name>
ACACS+ <t>
accounting The following arguments are defined for TACACS+ accounting only. They
only. <bcp14>MUST</bcp14> precede any argument-value pairs that are defined
They MUST precede any in "Authorization" (<xref target="Authorization" format="default"></xref>
argument-value pairs that ).
are </t>
defined <t>
in
the
<xref target="Authorization">authorizatio
n section</xref>
above.
</t>
<t>
task_id (String) task_id (String)
</t> </t>
<t> <ul empty="true">
Start and stop records for the same event <li>
MUST have
matching <t>
task_id Start and stop records for the same event <bcp14>MUST</bcp14> have
argument values. The client MUST ensure t matching task_id argument values. The client <bcp14>MUST</bcp14>
hat active ensure that active task_ids are not duplicated; a client <bcp14>MUST
task_ids are not duplicated: a client MUS NOT</bcp14> reuse a task_id in a start record until it has sent a stop
T NOT reuse record for that task_id. Servers <bcp14>MUST NOT</bcp14> make
a task_id a assumptions about the format of a task_id.
start record until it </t>
has sent a stop record for that </li>
task_id. </ul>
Servers MUST NOT make assumptions about t <t>
he format of a task_id.
</t>
<t>
start_time (Date Time) start_time (Date Time)
</t> </t>
<t> <ul empty="true">
The time the action started (in seconds s <li>
ince the <t>
epoch.). The time the action started (in seconds since the epoch).
</t> </t>
<t> </li>
</ul>
<t>
stop_time (Date Time) stop_time (Date Time)
</t> </t>
<t> <ul empty="true">
The time the action stopped (in seconds s <li>
ince the <t>
epoch.) The time the action stopped (in seconds since the epoch).
</t> </t>
<t> </li>
</ul>
<t>
elapsed_time (Numeric) elapsed_time (Numeric)
</t> </t>
<t> <ul empty="true">
<li>
<t>
The elapsed time in seconds for the actio n. The elapsed time in seconds for the actio n.
</t> </t>
<t> </li>
</ul>
<t>
timezone (String) timezone (String)
</t> </t>
<t> <ul empty="true">
The timezone abbreviation for all timesta <li>
mps included <t>
in this The time zone abbreviation for all timestamps included in this packet. A
packet. A database of timezones is mainta database of time zones is maintained in <xref target="TZDB"
ined here: format="default">TZDB</xref>.
<xref target="TZDB">TZDB</xref>. </t>
</t> </li>
<t> </ul>
<t>
event (String) event (String)
</t> </t>
<t> <ul empty="true">
Used only when "service=system". Current <li>
values are <t>
"net_acct", Used only when "service=system". Current values are "net_acct", "cmd_acct",
"cmd_acct", "conn_acct", "shell_acct" "conn_acct", "shell_acct", "sys_acct", and "clock_change". These indicate
"sys_acct" and system-level changes. The flags field <bcp14>SHOULD</bcp14> indicate whether
"clock_change". the service started or stopped.
These indicate system-level changes. </t>
The flags </li>
field SHOULD indicate </ul>
whether <t>
the service started or stopped.
</t>
<t>
reason (String) reason (String)
</t> </t>
<t> <ul empty="true">
Accompanies an event argument. It describ <li>
es why the <t>
event Accompanies an event argument. It describes why the event occurred.
occurred. </t>
</t> </li>
<t> </ul>
<t>
bytes (Numeric) bytes (Numeric)
</t> </t>
<t> <ul empty="true">
The number of bytes transferred by this a <li>
ction <t>
</t> The number of bytes transferred by this action.
<t> </t>
</li>
</ul>
<t>
bytes_in (Numeric) bytes_in (Numeric)
</t> </t>
<t> <ul empty="true">
The number of bytes transferred by this a <li>
ction from the <t>
endstation to the client port The number of bytes transferred by this action from the endstation to
</t> the client port.
<t> </t>
</li>
</ul>
<t>
bytes_out (Numeric) bytes_out (Numeric)
</t> </t>
<t> <ul empty="true">
The number of bytes transferred by this a <li>
ction from the client to <t>
the endstation The number of bytes transferred by this action from the client
port to the endstation port.
</t> </t>
<t> </li>
</ul>
<t>
paks (Numeric) paks (Numeric)
</t> </t>
<t> <ul empty="true">
<li>
<t>
The number of packets transferred by this action. The number of packets transferred by this action.
</t> </t>
<t> </li>
</ul>
<t>
paks_in (Numeric) paks_in (Numeric)
</t> </t>
<t>
The number of input packets transferred b <ul empty="true">
y this <li>
action from the <t>
endstation to the client The number of input packets transferred by this action from the endstation to
port. the client port.
</t> </t>
<t> </li>
</ul>
<t>
paks_out (Numeric) paks_out (Numeric)
</t> </t>
<t> <ul empty="true">
The number of output packets transferred <li>
by this <t>
action from the The number of output packets transferred by this action from the client port
client to the endstation.
port to the endstation. </t>
</t> </li>
<t> </ul>
<t>
err_msg (String) err_msg (String)
</t> </t>
<t> <ul empty="true">
string describing the status of the <li>
action. For details of <t>
<xref target="TextEncoding">text encoding A string describing the status of the action. For details of text
, see</xref>. encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" fo
</t> rmat="default"/>).
</section> </t>
</section> </li>
<section anchor="PrivilegeLevel" title="Privilege Levels"> </ul>
<t> <t>Where the TACACS+ deployment is used to support the Device Administration
The TACACS+ Protocol supports flexible authorizat use case, it is often required to log all commands entered into client
ion devices. To support this mode of operation, TACACS+ client devices <bcp14>MUST</
schemes bcp14> be
through the extensible arguments. configured to send an accounting start packet for every command entered,
</t> irrespective of how the commands were authorized. These “Command Accounting”
<t>One packets <bcp14>MUST</bcp14> include the “service” and “cmd” arguments, and if ne
scheme is eded, the
built into the “cmd-arg” arguments detailed in <xref target="AuthorizationAttributes"/>.
protocol and has been extensively used </t>
for Session-based shell authorization: Privilege </section>
Levels. </section>
Privilege <section anchor="PrivilegeLevel" numbered="true" toc="default">
Levels are ordered values from <name>Privilege Levels</name>
0 <t>
to 15 with each level The TACACS+ protocol supports flexible
being a authorization schemes through the extensible
superset arguments.
of the </t>
next lower value.
Configuration and implementation of the
client will map actions (such as the
permission to execute of
specific commands) to different privilege levels.
The allocation of
commands to privilege levels is highly dependent
upon the
deployment. Common allocations are as follows:
</t>
<t>
<list>
<t>
TAC_PLUS_PRIV_LVL_MIN := 0x00. Th
e level normally allocated to
an unauthenticated session.
</t>
<t>
TAC_PLUS_PRIV_LVL_USER := 0x01. T
he level normally allocated to
a regular authenticated session
</t>
<t>
TAC_PLUS_PRIV_LVL_ROOT := 0x0f. T
he level normally allocated to
a session authenticated by a high
ly privileged user to allow
commands with significant system
impact.
</t>
<t>
TAC_PLUS_PRIV_LVL_MAX := 0x0f. Th
e highest privilege level.
</t>
</list>
</t>
<t>
A Privilege level can be assigned to a shell (EXE
C) session when
it starts. The client
will
permit the actions associated with this
level to be executed.
This
privilege level is returned by the Server
in a session-based
shell
authorization
(when "service"
equals "shell"
and
"cmd" is empty).
When a
user required to perform actions that are
mapped to a higher
privilege level, then
an ENABLE type
reauthentication can
be initiated
by the client.
The client will insert
the required privilege level
into
the authentication header for
enable
authentication request.
</t>
<t>
The use of Privilege levels to determine session-
based
access to
commands and resources is not mandatory for
clients. Although the
privilege level scheme is widely supported, its l
ack of flexibility
in requiring a single monotonic hierarchy of perm
issions means that
other
session-based command authorization schemes
have evolved. However, it is still
common enough that it SHOULD be supported by
servers.
</t>
</section>
<section anchor="TACACSSecurity" title="Security Considerations">
<t> <t> The privilege levels scheme is built into the protocol and has been
The original TACACS+ Draft extensively used as an option for Session-based shell authorization.
<xref target="TheDraft">`The Draft'</xref>
from 1998 did not address all of the
key security concerns which are
considered when designing modern
standards. This section addresses
known limitations and concerns
which will impact overall security of
the protocol and systems where
this protocol is deployed to manage
central authentication,
authorization or accounting for network
device administration.
</t> Privilege levels are ordered values from 0 to 15 with each level being a
<t> superset of the next lower value. Configuration and implementation of the
client will map actions (such as the permission to execute specific commands)
to different privilege levels. The allocation of commands to privilege levels
is highly dependent upon the deployment. Common allocations are as follows:
</t>
<ul empty="true" spacing="normal">
<li>
TAC_PLUS_PRIV_LVL_MIN :=
0x00. The level normally
allocated to an
unauthenticated session.
</li>
<li>
TAC_PLUS_PRIV_LVL_USER :=
0x01. The level normally
allocated to a regular
authenticated session.
</li>
<li>
TAC_PLUS_PRIV_LVL_ROOT :=
0x0f. The level normally
allocated to a session
authenticated by a highly
privileged user to allow
commands with significant
system impact.
</li>
<li>
TAC_PLUS_PRIV_LVL_MAX :=
0x0f. The highest privilege
level.
</li>
</ul>
<t>
Multiple implementations of the protocol describe A privilege level can be assigned to a shell (exec) session when it
d in the original starts. The client will permit the actions associated with this level to be
TACACS+ Draft executed. This privilege level is returned by the server in a session-based
<xref target="TheDraft">`The Draft'</xref> shell authorization (when "service" equals "shell" and "cmd" is empty). When
have been a user is required to perform actions that are mapped to a higher privilege
deployed. As the protocol was never standardized, level, an ENABLE-type reauthentication can be initiated by the client.
current The client will insert the required privilege level into the authentication
implementations may be incompatible in non-obviou header for ENABLE authentication requests.
s ways, giving rise </t>
to additional security risks. This section does n
ot claim to
enumerate all possible security
vulnerabilities.
</t> <t>
<section anchor="SecurityofTheProtocol" title="General Se The use of privilege levels to determine session-based access to
curity of the Protocol"> commands and resources is not mandatory for clients. Although the
<t> privilege-level scheme is widely supported, its lack of flexibility in
TACACS+ protocol does not include a secur requiring a single monotonic hierarchy of permissions means that other
ity mechanism that would session-based command authorization schemes have evolved. However, it
meet is still common enough that it <bcp14>SHOULD</bcp14> be supported by
modern-day requirements. These security m servers.
echanisms would be </t>
best referred to </section>
as “obfuscation” and not “encryption” sin <section anchor="TACACSSecurity" numbered="true" toc="default">
ce they <name>Security Considerations</name>
provide no <t>
meaningful "The Draft" <xref target="THE-DRAFT"
integrity, privacy or replay protection. format="default"/> from 1998 did not address all of the key security concerns
An that are considered when designing modern standards. This section addresses
attacker with access to the data known limitations and concerns that will impact overall security of the
stream should be assumed to be able protocol and systems where this protocol is deployed to manage central
to read and modify all TACACS+ authentication, authorization, or accounting for network Device
packets. Administration.
Without mitigation, a range
of risks such as the following are possib
le:
</t>
<t>
<list>
<t>
Accounting information ma
y be modified by the man-in-the-middle
attacker,
making such logs unsuitab
le and not trustable for
auditing
purposes.
</t>
<t>
Invalid or misleading val
ues may be inserted by the
man-in-the-middle attacke
r
in various fields at know
n offsets to
try and circumvent the
authentication or
authorization checks even
inside the obfuscated bod
y.
</t>
</list>
</t>
<t>
While the protocol provides some measure
of transport privacy, it
is
vulnerable to at least the following atta
cks:
</t>
<t>
<list>
<t> </t>
Brute force attacks explo <t>
iting increased efficiency of MD5
digest
computation.
</t>
<t>
Known plaintext attacks w
hich may decrease the cost of brute
force
attack.
</t>
<t>
Chosen plaintext attacks
which may decrease the cost of a brute
force
attack.
</t>
<t>
No forward secrecy.
</t>
</list>
</t>
<t>
Even though, to the best knowledge of aut
hors, this method of
encryption
wasn’t rigorously tested, enough
information is
available
that it is best referred to as
“obfuscation” and not
“encryption”.
</t>
<t>
For these reasons, users deploying TACACS
+ protocol in their
environments
MUST limit access to known clients and MU
ST control the
security of
the entire transmission path. Attackers w
ho can guess
the
key or
otherwise break the obfuscation will gain
unrestricted and
undetected
access to all TACACS+ traffic. Ensuring t
hat a
centralized AAA system like TACACS+ is de
ployed on a secured
transport is essential to managing the se
curity risk of such
an
attack.
</t>
<t>
The following parts of this section enume
rate only the
session-specific
risks which are in addition to general ri
sk
associated with bare
obfuscation and lack of integrity checkin
g.
</t> Multiple implementations of the protocol described in
"The Draft" <xref target="THE-DRAFT" format="default"/>
have been deployed. As the protocol was never standardized, current
implementations may be incompatible in non-obvious ways, giving rise
to additional security risks. This section does not claim to enumerate
all possible security vulnerabilities.
</section> </t>
<section anchor="SecurityofAuthenticationSessions" title= <section anchor="SecurityofTheProtocol" numbered="true" toc="default">
"Security of Authentication Sessions"> <name>General Security of the Protocol</name>
<t>
The TACACS+ protocol does not include a security mechanism that would mee
t
modern-day requirements. These security mechanisms would be best
referred to as "obfuscation" and not "encryption", since they provide
no meaningful integrity, privacy, or replay protection. An attacker
with access to the data stream should be assumed to be able to read
and modify all TACACS+ packets. Without mitigation, a range of risks
such as the following are possible:
</t>
<ul empty="false" spacing="normal">
<li>
Accounting information may be modified by the man-in-the-middle
attacker, making such logs unsuitable and not trustable for auditing
purposes.
</li>
<li>
Invalid or misleading values may be inserted by the man-in-the-middle
attacker in various fields at known offsets to try and circumvent the
authentication or authorization checks even inside the obfuscated
body.
</li>
</ul>
<t>
While the protocol provides some measure of transport privacy, it is
vulnerable to at least the following attacks:
</t>
<ul empty="false" spacing="normal">
<li>
Brute-force attacks exploiting increased efficiency of MD5 digest computation.
</li>
<li>
Known plaintext attacks that may decrease the cost of brute-force
attacks.
</li>
<li>
Chosen plaintext attacks that may decrease the cost of a brute-force
attacks.
</li>
<li>
No forward secrecy.
</li>
</ul>
<t>
Even though, to the best knowledge of the authors, this method of encryption
wasn't rigorously tested, enough information is available that it is best
referred to as "obfuscation" and not "encryption".
</t>
<t>
For these reasons, users deploying the TACACS+ protocol in their
environments <bcp14>MUST</bcp14> limit access to known clients and
<bcp14>MUST</bcp14> control the security of the entire transmission
path. Attackers who can guess the key or otherwise break the
obfuscation will gain unrestricted and undetected access to all
TACACS+ traffic. Ensuring that a centralized AAA system like TACACS+
is deployed on a secured transport is essential to managing the
security risk of such an attack.
</t>
<t>
The following parts of this section
enumerate only the session-specific
risks that are in addition to general
risk associated with bare obfuscation
and lack of integrity checking.
<t> </t>
Authentication sessions SHOULD be used vi </section>
a a secure transport (see <section anchor="SecurityofAuthenticationSessions" numbered="true" toc="de
<xref target="Bestpractices">Best Practic fault">
es section</xref>) <name>Security of Authentication Sessions</name>
as <t>
the Authentication sessions <bcp14>SHOULD</bcp14> be used via a secure
man-in-the-middle attack may completely s transport (see "TACACS+ Best Practices" (<xref target="Bestpractices"
ubvert them. Even format="default"></xref>)) as the man-in-the-middle attack may
CHAP, completely subvert them. Even CHAP, which may be considered resistant to
which may be considered resistant to pass password
word interception, is interception, is unsafe as it does not protect the username from a
unsafe trivial man-in-the-middle attack.
as it does not protect the username from </t>
a trivial <t>
man-in-the-middle This document deprecates the redirection mechanism using the
attack. TAC_PLUS_AUTHEN_STATUS_FOLLOW option, which was included in "The Draft". As
</t> part of this process, the secret key for a new server was sent to the
<t> client. This public exchange of secret keys means that once one session is
This document deprecates the redirection broken, it may be possible to leverage that key to attacking connections to
mechanism using the other servers.&nbsp; This mechanism <bcp14>MUST NOT</bcp14> be used in modern
TAC_PLUS_AUTHEN_STATUS_FOLLOW option whic deployments. It <bcp14>MUST NOT</bcp14> be used outside a secured deployment.
h was included in the </t>
original draft. As part of this process, </section>
the secret key for a new <section anchor="SecurityofAuthorizationSessions" numbered="true" toc="def
server was ault">
sent to the client. This public exchange <name>Security of Authorization Sessions</name>
of secret keys <t>
means that once Authorization sessions <bcp14>SHOULD</bcp14> be used via a secure
one session is broken, it may be possible transport (see "TACACS+ Best Practices" (<xref target="Bestpractices"
to format="default"></xref>)) as it's trivial to execute a successful
leverage that key to man-in-the-middle attack that changes well-known plaintext in either
attacking connections to other servers.  requests or responses.
This </t>
mechanism MUST NOT be used in <t>
modern deployments. It MUST NOT be As an example, take the field "authen_method". It's not unusual in
used outside a secured deployment. actual deployments to authorize all commands received via the device
</t> local serial port (a console port), as that one is usually considered
</section> secure by virtue of the device located in a physically secure
<section anchor="SecurityofAuthorizationSessions" title=" location. If an administrator would configure the authorization system
Security of Authorization Sessions"> to allow all commands entered by the user on a local console to aid in
<t> troubleshooting, that would give all access to all commands to any
Authorization sessions SHOULD be used via attacker that would be able to change the "authen_method" from
a secure transport (see TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In this
<xref target="Bestpractices">Best Practic regard, the obfuscation provided by the protocol itself wouldn't help
es section</xref>) much, because:
as </t>
it’s <ul empty="false" spacing="normal">
trivial to execute a successful man-in-th <li>
e-middle attacks A lack of integrity means that any byte in the payload may be changed
that without either side detecting the change.
changes </li>
well-known plaintext in either requests o <li>
r responses. Known plaintext means that an attacker would know with certainty which
</t> octet is the target of the attack (in this case, first octet after the
<t> header).
As an example, take the field “authen_met </li>
hod”. It’s not unusual <li>
in In combination with known plaintext, the attacker can determine with
actual deployments to authorize all comma certainty the value of the crypto-pad octet used to obfuscate the
nds received via the original octet.
device
local serial port (a console port) as tha
t one is usually
considered
secure by virtue of the device located in
a physically
secure
location. If an administrator would confi
gure the
authorization
system to allow all commands entered by t
he user on a
local console
to aid in troubleshooting, that would giv
e all access
to all
commands
to any attacker that would be able to cha
nge the
“authen_method” from
TAC_PLUS_AUTHEN_METH_TACACSPLUS to
TAC_PLUS_AUTHEN_METH_LINE. In
this
regard, the obfuscation provided
by the protocol itself wouldn’t help
much, because:
</t>
<t>
<list>
<t>
Lack of integrity means t
hat any byte in the payload may be
changed
without
either side detecting the
change.
</t>
<t>
Known plaintext means tha
t an attacker would know with
certainty which
octet is the target of th
e attack (in this case,
1st octet after
the
header).
</t>
<t>
In combination with known
plaintext, the attacker can determine
with
certainty the value of th
e crypto-pad octet used to obfuscate
the
original octet.
</t> </li>
</list> </ul>
</t> </section>
</section> <section anchor="SecurityofAccountingSessions" numbered="true" toc="defaul
<section anchor="SecurityofAccountingSessions" title="Sec t">
urity of Accounting Sessions"> <name>Security of Accounting Sessions</name>
<t>Accounting sessions SHOULD be used via a secur <t>Accounting sessions <bcp14>SHOULD</bcp14> be used via a secure
e transport (see transport (see "TACACS+ Best Practices" (<xref
Best Practices section (Section 10.5). Al target="Bestpractices"></xref>)). Although Accounting sessions are not
though Accounting sessions directly involved in authentication or authorizing operations on the
are not directly involved in authenticati device, man-in-the-middle attackers may do any of the following:
on </t>
or <ul empty="false" spacing="normal">
authorizing operations <li>
on the device, man-in-the-middle
attacker may do any of the
following:
</t>
<t>
<list>
<t>
Replace accounting data w
ith new valid or garbage which
can
confuse auditors or hide
information related to
their
authentication
and/or authorization atta
ck attempts.
</t>
<t>
Try and poison accounting
log with entries designed to make
systems
behave in unintended ways
(which includes TACACS+ server
and any
other systems that would
manage accounting entries).
</t>
</list>
</t>
<t>
In addition to these direct manipulations
, different client
implementations pass different fidelity o
f accounting data. Some
vendors have been observed in the wild th
at pass sensitive data
like
passwords, encryption keys and similar as
part of the
accounting log.
Due to lack of strong encryption with per
fect
forward secrecy, this
data may be revealed in future, leading t
o a
security incident.
</t> Replace accounting data with new valid values or garbage that can confuse
</section> auditors or hide information related to their authentication and/or
authorization attack attempts.
</li>
<li>
<section anchor="Bestpractices" title="TACACS+ Best Pract Try and poison an accounting log with entries designed to make systems
ices"> behave in unintended ways (these systems could be TACACS+ servers and any
other
systems that would manage accounting entries).
</li>
</ul>
<t>
In addition to these direct manipulations, different client
implementations pass a different fidelity of accounting data. Some
vendors have been observed in the wild that pass sensitive data like
passwords, encryption keys, and the like as part of the accounting log.
Due to a lack of strong encryption with perfect forward secrecy, this
data may be revealed in the future, leading to a security incident.
<t>With respect to the observations about the sec </t>
urity issues </section>
described above, a network administrator <section anchor="Bestpractices" numbered="true" toc="default">
MUST NOT rely on the <name>TACACS+ Best Practices</name>
obfuscation of the TACACS+ protocol. TACA <t>With respect to the observations about the security issues
CS+ MUST be used within a secure deployment: TACACS+ MUST be deployed described above, a network administrator <bcp14>MUST NOT</bcp14>
over networks which ensure privacy and in rely on the obfuscation of the TACACS+ protocol. TACACS+
tegrity of the <bcp14>MUST</bcp14> be used within a secure deployment; TACACS+
communication, and MUST be deployed over <bcp14>MUST</bcp14> be deployed over networks that ensure privacy and
a network which is separated integrity of the communication and <bcp14>MUST</bcp14> be deployed
from over a network that is separated from other traffic. Failure to do
other traffic. so will impact overall network security.</t>
Failure to do so will impact overall netw <t>The following recommendations impose restrictions on how the
ork security.</t> protocol is applied. These restrictions were not imposed in "The
Draft". New implementations, and upgrades of current implementations,
<bcp14>MUST</bcp14> implement these recommendations. Vendors
<bcp14>SHOULD</bcp14> provide mechanisms to assist the administrator
to achieve these best practices.</t>
<t>The following recommendations impose restricti <section anchor="SharedSecrets" numbered="true" toc="default">
ons on how the
protocol is applied. These restrictions w
ere not imposed in the
original draft. New implementations, and
upgrades of current
implementations, MUST implement these rec
ommendations. Vendors
SHOULD provide mechanisms to assist the a
dministrator to achieve
these best practices.</t>
<section anchor="SharedSecrets" title="Shared Sec <name>Shared Secrets</name>
rets"> <t>TACACS+ servers and clients <bcp14>MUST</bcp14> treat shared
secrets as sensitive data to be managed securely, as would be
expected for other sensitive data such as identity credential
information. TACACS+ servers <bcp14>MUST NOT</bcp14> leak sensitive
data.
</t>
<t>
For example:
</t>
<t>TACACS+ servers and clients MUST treat <ul>
shared secrets as <li>
sensitive data to be managed secu <t> TACACS+ servers <bcp14>MUST NOT</bcp14> expose shared secrets in
rely, as would be expected for logs.
other sensitive data such as iden </t>
tity credential information.
TACACS+ servers MUST NOT leak sen
sitive data. For example, TACACS+
servers MUST NOT expose shared se
crets in logs.
</t>
<t>TACACS+ servers MUST allow a dedicated </li>
secret key to be defined <li>
<t>TACACS+ servers <bcp14>MUST</bcp14> allow a dedicated secret key to
be defined
for each client. for each client.
</t> </t>
</li>
<t>TACACS+ server management systems MUST <li>
provide a mechanism to track secret <t>TACACS+ server management systems <bcp14>MUST</bcp14> provide a
key lifetimes and notify administrator mechanism to track secret key lifetimes and notify administrators to
s to update them periodically. TACACS+ update them periodically. TACACS+ server administrators
server administrators SHOULD change se <bcp14>SHOULD</bcp14> change secret keys at regular intervals. </t>
cret keys at regular intervals. </t> </li>
<li>
<t>TACACS+ servers SHOULD warn administra
tors if secret keys are
not unique per client.</t>
<t>TACACS+ server administrators SHOULD a
lways define a secret for
each client.</t>
<t>TACACS+ servers and clients MUST suppo <t>TACACS+ servers <bcp14>SHOULD</bcp14> warn administrators if
rt shared keys that are at secret keys are not unique per client.</t>
</li>
<li>
<t>TACACS+ server administrators <bcp14>SHOULD</bcp14> always define
a secret for each client.</t>
</li>
<li>
<t>TACACS+ servers and clients <bcp14>MUST</bcp14> support shared keys
that are at
least 32 characters long. least 32 characters long.
</t> </t>
</li>
<t>TACACS+ servers MUST support policy to <li>
define minimum complexity <t>TACACS+ servers <bcp14>MUST</bcp14> support policy to define
for shared keys. minimum complexity for shared keys.
</t> </t>
</li>
<t>TACACS+ clients SHOULD NOT allow serve <li>
rs to be configured <t>TACACS+ clients <bcp14>SHOULD NOT</bcp14> allow servers to be
without shared secret key, or sha configured without a shared secret key or shared key that is less
red key that is less than 16 than 16 characters long.</t>
characters long.</t> </li>
<li>
<t>TACACS+ server administrators SHOULD c
onfigure secret keys of
minimum 16 characters length.</t>
</section>
<section anchor="Connections" title="Connections
and Obfuscation">
<t>TACACS+ servers MUST allow the definit
ion of individual clients.
The servers MUST only accept netw
ork connection attempts from
these defined, known clients.</t>
<t>TACACS+ servers MUST reject connection
s with
TAC_PLUS_UNENCRYPTED_FLAG set. Th
ere MUST always be a shared secret set
on the server for the client requ
esting the connection.</t>
<t>If an invalid shared secret is detecte
d when processing packets
for a client, TACACS+ servers MUS
T NOT accept any new sessions on
that connection. TACACS+ servers
MUST terminate the connection on
completion of any sessions that w
ere previously established with a
valid shared secret on that conne
ction.</t>
<t>TACACS+ clients MUST NOT set TAC_PLUS_
UNENCRYPTED_FLAG. Clients MUST be implemented in a way that
requires explicit configuration t
o enable the use of
TAC_PLUS_UNENCRYPTED_FLAG, this o
ption MUST NOT be used when the client is in production </t>
<t>When a TACACS+ client receives respons
es from servers where:</t>
<t>
<list>
<t> the response packet w
as received from the server configured
with shared
key, but the pack
et has TAC_PLUS_UNENCRYPTED_FLAG
set.
</t>
<t> the response packet w
as received from the server configured
not to use
obfuscation, but
the packet has
TAC_PLUS_UNENCRYP
TED_FLAG not set.
</t>
</list>
</t>
<t>then the TACACS+ client MUST close TCP
session, and process the
response in the same
way that a TAC_PLUS_AUTHEN_STATUS
_FAIL
(authentication sessions)
or TAC_PLUS_AUTHOR_STATUS_FAIL
(authorization sessions) was
received.</t>
</section>
<section anchor="AuthenticationRecommendations" t
itle="Authentication">
<t>To help TACACS+ administrators select
less weak
authentication
options,
TACACS+ servers MUST allow the ad
ministrator
to configure
the
server to
only accept challenge/response op
tions for
authentication
(TAC_PLUS_AUTHEN_TYPE_CHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for
authen_type).</t>
<t>TACACS+ server administrators SHOULD e
nable the option mentioned
in the previous paragraph. TACACS
+ Server deployments SHOULD ONLY
enable other options (such as TAC
_PLUS_AUTHEN_TYPE_ASCII or
TAC_PLUS_AUTHEN_TYPE_PAP) when un
avoidable due to requirements of
identity/password systems.</t>
<t>TACACS+ server administrators SHOULD N
OT allow the same
credentials to be applied in chal
lenge-based
(TAC_PLUS_AUTHEN_TYPE_CHAP or TAC
_PLUS_AUTHEN_TYPE_MSCHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) an
d non challenge-based authen_type
options as the insecurity of the
latter will compromise the
security of the former.</t>
<t>TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_
AUTHEN_SENDPASS options
mentioned in the original draft S
HOULD NOT be used, due to their
security implications. TACACS+ se
rvers SHOULD NOT implement them.
If they must be implemented, the
servers MUST default to the
options being disabled and MUST w
arn the administrator that these
options are not secure.</t>
</section>
<section anchor="AuthorizationRecommendations" ti
tle="Authorization">
<t>The authorization and accounting featu
res are intended to
provide extensibility and flexibi
lity. There is a base dictionary
defined in this document, but it
may be extended in deployments by
using new argument names. The cos
t of the flexibility is that
administrators and implementers M
UST ensure that the argument and
value pairs shared between the cl
ients and servers have consistent
interpretation.</t>
<t>TACACS+ clients that receive an unreco <t>TACACS+ server administrators <bcp14>SHOULD</bcp14> configure
gnized mandatory argument secret keys of a minimum of 16 characters in length.</t>
MUST evaluate server response as </li>
if they received </ul>
TAC_PLUS_AUTHOR_STATUS_FAIL.</t>
</section> </section>
<section anchor="Connections" numbered="true" toc="default">
<name>Connections and Obfuscation</name>
<t>TACACS+ servers <bcp14>MUST</bcp14> allow the definition of
individual clients. The servers <bcp14>MUST</bcp14> only accept
network connection attempts from these defined known clients.</t>
<t>TACACS+ servers <bcp14>MUST</bcp14> reject connections
that have
TAC_PLUS_UNENCRYPTED_FLAG set. There <bcp14>MUST</bcp14> always be a
shared secret set on the server for the client requesting the
connection.</t>
<t>If an invalid shared secret is detected when processing packets
for a client, TACACS+ servers <bcp14>MUST NOT</bcp14> accept any new
sessions on that connection. TACACS+ servers <bcp14>MUST</bcp14>
terminate the connection on completion of any sessions that were
previously established with a valid shared secret on that
connection.</t>
<t>TACACS+ clients <bcp14>MUST NOT</bcp14> set
TAC_PLUS_UNENCRYPTED_FLAG. Clients <bcp14>MUST</bcp14> be
implemented in a way that requires explicit configuration to enable
the use of TAC_PLUS_UNENCRYPTED_FLAG. This option <bcp14>MUST
NOT</bcp14> be used when the client is in production.</t>
<section anchor="RedirectionMechanism" title="Red <t>When a TACACS+ client receives responses from servers where:</t>
irection Mechanism"> <ul empty="false" spacing="normal">
<li>the response packet was received from the server configured
with a shared key, but the packet has TAC_PLUS_UNENCRYPTED_FLAG
set, and
<t>The original draft described a redirec </li>
tion mechanism <li>the response packet was received from the server configured
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). not to use obfuscation, but the packet has
This feature is difficult to TAC_PLUS_UNENCRYPTED_FLAG not set,
secure. The option to send secret
keys in the server list is
particularly insecure, as it can
reveal client shared secrets.</t>
<t>TACACS+ servers MUST deprecate the red </li>
irection mechanism.</t> </ul>
<t>the TACACS+ client <bcp14>MUST</bcp14> close the TCP
session, and process the response in the same way that a
TAC_PLUS_AUTHEN_STATUS_FAIL (authentication sessions) or
TAC_PLUS_AUTHOR_STATUS_FAIL (authorization sessions) was
received.</t>
</section>
<section anchor="AuthenticationRecommendations" numbered="true" toc="def
ault">
<name>Authentication</name>
<t>To help TACACS+ administrators select stronger authentication
options, TACACS+ servers <bcp14>MUST</bcp14> allow the administrator
to configure the server to only accept challenge/response options
for authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for
authen_type).</t>
<t>TACACS+ server administrators <bcp14>SHOULD</bcp14> enable the
option mentioned in the previous paragraph.
<t>If the redirection mechanism is implem TACACS+ server deployments <bcp14>SHOULD</bcp14> only enable other
ented then TACACS+ servers options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or
MUST disable it by default, and M TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of
UST warn TACACS+ server identity/password systems.</t>
administrators that it must only <t>TACACS+ server administrators <bcp14>SHOULD NOT</bcp14> allow the
be enabled within a secure same credentials to be applied in challenge-based
deployment due to the risks of re (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or
vealing shared secrets.</t> TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non-challenge-based authen_type
options, as the insecurity of the latter will compromise the security
of the former.</t>
<t>TACACS+ clients SHOULD deprecate this <t>TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options
feature by treating mentioned in "The Draft" <bcp14>SHOULD
NOT</bcp14> be used due to their security implications. TACACS+
servers <bcp14>SHOULD NOT</bcp14> implement them. If they must be
implemented, the servers <bcp14>MUST</bcp14> default to the options
being disabled and <bcp14>MUST</bcp14> warn the administrator that
these options are not secure.</t>
</section>
<section anchor="AuthorizationRecommendations" numbered="true" toc="defa
ult">
<name>Authorization</name>
<t>The authorization and accounting features are intended to provide
extensibility and flexibility. There is a base dictionary defined in
this document, but it may be extended in deployments by using new
argument names. The cost of the flexibility is that administrators
and implementers <bcp14>MUST</bcp14> ensure that the argument and
value pairs shared between the clients and servers have consistent
interpretation.</t>
<t>TACACS+ clients that receive an unrecognized mandatory argument
<bcp14>MUST</bcp14> evaluate server response as if they received
TAC_PLUS_AUTHOR_STATUS_FAIL.</t>
</section>
<section anchor="RedirectionMechanism" numbered="true" toc="default">
<name>Redirection Mechanism</name>
<t>"The Draft" described a redirection mechanism
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to
secure. The option to send secret keys in the server list is
particularly insecure, as it can reveal client shared secrets.</t>
<t>TACACS+ servers <bcp14>MUST</bcp14> deprecate the redirection mecha
nism.</t>
<t>If the redirection mechanism is implemented, then TACACS+ servers
<bcp14>MUST</bcp14> disable it by default and <bcp14>MUST</bcp14>
warn TACACS+ server administrators that it must only be enabled
within a secure deployment due to the risks of revealing shared
secrets.</t>
<t>TACACS+ clients <bcp14>SHOULD</bcp14> deprecate this feature by tre
ating
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
</t> </t>
</section>
</section> </section>
</section>
</section> <section anchor="IANAConsiderations" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<section anchor="IANAConsiderations" title="IANA Considerations"> <t>This document has no IANA actions.
<t>This informational document describes TACACS+ protocol </t>
and its
common
deployments. There is no further consideration re
quired from
IANA.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the following reviewer
s whose
comments and contributions made considerable impr
ovements to the
document: Alan DeKok, Alexander Clouter, Chris Ja
nicki, Tom Petch,
Robert Drake, John Heasley, among many others.
</t>
<t>
The authors would particularly like to thank Alan
DeKok, who
provided significant insights and recommendations
on all aspects of
the document and the protocol. Alan DeKok has ded
icated considerable
time and effort
to help improve
the
document, identifying weaknesses
and providing remediation.
</t>
<t>The authors would also like to thank the support from
the OPSAWG
Chairs and advisors, especially Joe Clarke.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC0020" target="https://www.rfc-edito
r.org/info/rfc20">
<front>
<title>ASCII format for network interchan
ge</title>
<author initials="V.G." surname="Cerf" fu
llname="V.G. Cerf">
<organization />
</author>
<date year="1969" month="October" />
</front>
<seriesInfo name="STD" value="80" />
<seriesInfo name="RFC" value="20" />
<seriesInfo name="DOI" value="10.17487/RFC0020" /
>
</reference>
<reference anchor='RFC1321'>
<front>
<title abbrev='MD5 Message-Digest Algorit
hm'>The MD5 Message-Digest Algorithm</title>
<author initials='R.' surname='Rivest' fu
llname='Ronald L. Rivest'>
<organization>Massachusetts Insti
tute of
Technology, (MIT)
Laboratory for Computer
Science</organization>
<address>
<postal>
<street>545 Techn
ology Square</street>
<street>NE43-324<
/street>
<city>Cambridge</
city>
<region>MA</regio
n>
<code>02139-1986<
/code>
<country>US</coun
try>
</postal>
<phone>+1 617 253 5880</p
hone>
<email>rivest@theory.lcs.
mit.edu</email>
</address>
</author>
<date year='1992' month='April' />
</front>
<seriesInfo name='RFC' value='1321' />
<format type='TXT' octets='35222'
target='http://www.rfc-editor.org/rfc/rfc
1321.txt' />
</reference>
<reference anchor="RFC1334" target="http://www.rfc-editor
.org/info/rfc1334">
<front>
<title>PPP Authentication Protocols</titl
e>
<author initials="B." surname="Lloyd" ful
lname="B. Lloyd">
<organization />
</author>
<author initials="W." surname="Simpson" f
ullname="W. Simpson">
<organization />
</author>
<date year="1992" month="October" />
<abstract>
<t>This document defines two prot
ocols for
Authentication: the
Password Authentication
Protocol and the Challeng
e-Handshake
Authentication Protocol.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1334" />
<seriesInfo name="DOI" value="10.17487/RFC1334" /
>
<format type="ASCII" octets="33248" />
</reference>
<reference anchor='RFC2119' target='https://www.rfc-edito
r.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indic
ate Requirement Levels</title>
<author initials='S.' surname='Bradner' f
ullname='S. Bradner'>
<organization />
</author>
<date year='1997' month='March' />
<abstract>
<t>In many standards track docume
nts several words are used to
signify the requirements
in the specification. These words are
often capitalized. This d
ocument defines these words as they
should be interpreted in
IETF documents. This document specifies
an Internet Best Current
Practices for the Internet Community,
and requests discussion a
nd suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<seriesInfo name='DOI' value='10.17487/RFC2119' /
>
</reference>
<reference anchor="RFC2433" target="http://www.rfc-editor </section>
.org/info/rfc2433">
<front>
<title>Microsoft PPP CHAP Extensions</tit
le>
<author initials="G." surname="Zorn" full
name="G. Zorn">
<organization />
</author>
<author initials="S." surname="Cobb" full
name="S. Cobb">
<organization />
</author>
<date year="1998" month="October" />
<abstract>
<t>The Point-to-Point Protocol (P
PP) provides a
standard method
for
transporting
multi-protocol datagrams
over point-to-point
links.
PPP defines an extensible
Link Control
Protocol and a
family of
Network Control
Protocols (NCPs) for esta
blishing and
configuring
different network-layer
protocols. This memo prov
ides
information
for
the Internet community.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="2433" />
<seriesInfo name="DOI" value="10.17487/RFC2433" /
>
<format type="ASCII" octets="34502" />
</reference>
<reference anchor="RFC2759" target="http://www.rfc-editor </middle>
.org/info/rfc2759"> <back>
<front>
<title>Microsoft PPP CHAP Extensions, Ver
sion 2</title>
<author initials="G." surname="Zorn" full
name="G. Zorn">
<organization />
</author>
<date year="2000" month="January" />
<abstract>
<t>This document describes versio
n two of
Microsoft's PPP CHAP
dialect (MS-CHAP-V2).
MS-CHAP-V2 is similar to,
but incompatible
with, MS-CHAP version one
(MS-CHAP-V1). This
memo provides
information for the Inter
net
community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2759" />
<seriesInfo name="DOI" value="10.17487/RFC2759" /
>
<format type="ASCII" octets="34178" />
</reference>
<reference anchor="RFC3579" target="https://www.rfc-edito <displayreference target="KERB" to="1"/>
r.org/info/rfc3579">
<front>
<title>
RADIUS (Remote Authentication Dia
l In User Service) Support For Extensible
Authentication Protocol (EAP)
</title>
<author initials="B." surname="Aboba" ful
lname="B. Aboba">
<organization />
</author>
<author initials="P." surname="Calhoun" f
ullname="P. Calhoun">
<organization />
</author>
<date year="2003" month="September" />
<abstract>
<t>
This document defines Rem
ote Authentication Dial In User Service
(RADIUS) support for the
Extensible Authentication Protocol (EAP),
an authentication framewo
rk which supports multiple authentication
mechanisms. In the propos
ed scheme, the Network Access Server (NAS)
forwards EAP packets to a
nd from the RADIUS server, encapsulated
within EAP-Message attrib
utes. This has the advantage of allowing
the NAS to support any EA
P authentication method, without the need
for method- specific code
, which resides on the RADIUS server. While
EAP was originally develo
ped for use with PPP, it is now also in use
with IEEE 802. This memo
provides information for the Internet
community.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3579" />
<seriesInfo name="DOI" value="10.17487/RFC3579" /
>
</reference>
<reference anchor="RFC4086" target="http://www.rfc-editor <references>
.org/info/rfc4086"> <name>References</name>
<front> <references>
<title>Randomness Requirements for Securi <name>Normative References</name>
ty</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="D." surname="Eastlake 3 FC.0020.xml"/>
rd" fullname="D. Eastlake 3rd"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization /> FC.1321.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="S." surname="Crocker" f FC.1334.xml"/>
ullname="S. Crocker"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization /> FC.8174.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="J." surname="Schiller" FC.2119.xml"/>
fullname="J. Schiller"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization /> FC.2433.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date year="2005" month="June" /> FC.2759.xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>Security systems are built on FC.3579.xml"/>
strong cryptographic algorithms <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
that foil pattern analysi FC.4086.xml"/>
s attempts. However, the security of <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
these systems is dependen FC.4120.xml"/>
t on generating secret quantities <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
for FC.5952.xml"/>
passwords, cryptographic <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
keys, and similar quantities. FC.8265.xml"/>
The use of </references>
pseudo-random processes t <references>
o generate secret <name>Informative References</name>
quantities can result
in pseudo-security. A sop
histicated
attacker may find it easi
er to
reproduce the environment
that
produced the secret quant
ities and
to search the resulting
small set of possibilitie
s than to locate
the quantities in
the whole of the potentia
l number space.
Choosing random
quantities to foil a reso
urceful and motivated
adversary is
surprisingly difficult. T
his document points out many
pitfalls in using poor en
tropy sources or traditional
pseudo-random number gene
ration techniques for generating
such
quantities. It recommends
the use of truly random
hardware
techniques and shows that
the existing hardware on
many systems
can be used for this purp
ose. It provides
suggestions to
ameliorate the problem wh
en a hardware
solution is not available
,
and it gives examples of
how
large such quantities nee
d to be for
some applications. This
document specifies an Int
ernet Best
Current Practices for
the Internet Community, a
nd requests
discussion and
suggestions for improveme
nts.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4086" />
<seriesInfo name="DOI" value="10.17487/RFC4086" /
>
<format type="ASCII" octets="25082" />
</reference>
<reference anchor="RFC4120" target="https://www.rfc-edito
r.org/info/rfc4120">
<front>
<title>The Kerberos Network Authenticatio
n Service (V5)</title>
<author initials="C." surname="Neuman" fu
llname="C. Neuman">
<organization />
</author>
<author initials="T." surname="Yu" fullna
me="T. Yu">
<organization />
</author>
<author initials="S." surname="Hartman" f
ullname="S. Hartman">
<organization />
</author>
<author initials="K." surname="Raeburn" f
ullname="K. Raeburn">
<organization />
</author>
<date year="2005" month="July" />
<abstract>
<t>
This document provides an
overview and specification of Version 5 of the
Kerberos protocol, and it
obsoletes RFC 1510 to clarify aspects of
the protocol and its inte
nded use that require more detailed or
clearer explanation than
was provided in RFC 1510. This document is
intended to provide a det
ailed description of the protocol, suitable
for implementation, toget
her with descriptions of the appropriate
use of protocol messages
and fields within those messages.
[STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4120" />
<seriesInfo name="DOI" value="10.17487/RFC4120" /
>
</reference>
<reference anchor="RFC5952" target="https://www.rfc-edito <reference anchor='THE-DRAFT' target="https://tools.ietf.org/html/draft-grant-ta
r.org/info/rfc5952"> cacs-02">
<front> <front>
<title>A Recommendation for IPv6 Address <title>The TACACS+ Protocol Version 1.78</title>
Text Representation</title> <author initials="D." surname="Carrel" fullname="D. Carrel"/>
<author initials="S." surname="Kawamura" <author initials="L." surname="Grant" fullname="Lol Grant"/>
fullname="S. Kawamura"> <date month="January" year="1997"/>
<organization /> </front>
</author> <seriesInfo name='Internet-Draft' value='draft-grant-tacacs-02' />
<author initials="M." surname="Kawashima" </reference>
fullname="M. Kawashima">
<organization />
</author>
<date year="2010" month="August" />
<abstract>
<t>As IPv6 deployment increases,
there will be a dramatic increase
in the need to use IPv6 a
ddresses in text. While the IPv6 address
architecture in Section 2
.2 of RFC 4291 describes a flexible
model for text representa
tion of an IPv6 address, this
flexibility has been caus
ing problems for operators, system
engineers, and users. Thi
s document defines a canonical textual
representation format. It
does not define a format for internal
storage, such as within a
n application or database. It is
expected that the canonic
al format will be followed by humans and
systems when representing
IPv6 addresses as text, but all
implementations must acce
pt and be able to handle any legitimate
RFC 4291 format. [STANDAR
DS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5952" />
<seriesInfo name="DOI" value="10.17487/RFC5952" /
>
</reference>
<reference anchor="RFC8265" target="https://www.rfc-edito <reference anchor="TZDB" target="https://www.iana.org/time-zones">
r.org/info/rfc8265"> <front>
<front> <title>Sources for Time Zone and Daylight Saving Time Data</title>
<title>Preparation, Enforcement, and Comp <author initials="P." surname="Eggert" fullname="Paul Eggert"/>
arison of <author initials="A." surname="Olson" fullname="Arthur Olson"/>
Internationalized Strings Represe <date year="1987"/>
nting Usernames and Passwords</title> </front>
<author initials="P." surname="Saint-Andr </reference>
e" fullname="P. Saint-Andre">
<organization />
</author>
<author initials="A." surname="Melnikov"
fullname="A. Melnikov">
<organization />
</author>
<date year="2017" month="October" />
<abstract>
<t>This document describes update
d methods for handling Unicode
strings representing user
names and passwords. The previous
approach was known as SAS
Lprep (RFC 4013) and was based on
Stringprep (RFC 3454). Th
e methods specified in this document
provide a more sustainabl
e approach to the handling of
internationalized usernam
es and passwords. This document
obsoletes RFC 7613.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8265" />
<seriesInfo name="DOI" value="10.17487/RFC8265" /
>
</reference>
</references> <reference anchor="KERB">
<references title="Informative References"> <front>
<reference anchor="TheDraft" <title>Section E.2.1: Kerberos Authentication and Authorization System</title>
target="https://tools.ietf.org/html/draft-grant-t <author initials="S." surname="Miller" fullname="Steven Miller"/>
acacs-02"> <author initials="C." surname="Neuman" fullname="Clifford Neuman"/>
<front> <author initials="J." surname="Schiller" fullname="Jeffrey Schiller"/>
<title>The TACACS+ Protocol Version 1.78< <author initials="J." surname="Saltzer" fullname="Jerry Saltzer"/>
/title>
<author initials="D." surname="Carrel" fu
llname="D. Carrel" />
<author initials="L." surname="Grant" ful <date month="December" year="1987"/>
lname="Lol Grant" /> </front>
<refcontent>MIT Project Athena</refcontent>
<refcontent>Cambridge, Massachusetts</refcontent>
<date month="June" year="1997" /> </reference>
</front>
</reference>
<reference anchor="TZDB" target="https://www.iana.org/tim </references>
e-zones"> </references>
<front>
<title>Sources for Time Zone and
Daylight Saving Time Data</title>
<author initials="P." surname="Eggert" fu
llname="D. Carrel" />
<author initials="A." surname="Olson" ful
lname="Lol Grant" />
<date year="1987" />
</front>
</reference>
</references> <section anchor="Acknowledgements" numbered="false" toc="default">
</back> <name>Acknowledgements</name>
<t>The authors would like to thank the following reviewers whose
comments and contributions made considerable improvements to this
document: <contact fullname="Alan DeKok"/>, <contact fullname="Alexander
Clouter"/>, <contact fullname="Chris Janicki"/>, <contact fullname="Tom Pe
tch"/>,
<contact fullname="Robert Drake"/>, and <contact fullname="John Heasley"/>
, among many others.
</t>
<t>
The authors would particularly like to thank
<contact fullname="Alan DeKok"/>, who provided
significant insights and recommendations on
all aspects of the document and the
protocol. <contact fullname="Alan DeKok"/> has
dedicated considerable time and effort to help
improve the document, identifying weaknesses
and providing remediation.
</t>
<t>The authors would also like to thank the support from the OPSAWG
Chairs and advisors, especially <contact fullname="Joe Clarke"/>.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 209 change blocks. 
4495 lines changed or deleted 3025 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/