<?xml version="1.0" encoding="UTF-8"?> version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8907" category="info"
     docName="draft-ietf-opsawg-tacacs-18" ipr="pre5378Trust200902"> consensus="true"  ipr="pre5378Trust200902"
     obsoletes="" updates="" submissionType="IETF" xml:lang="en"
     tocInclude="true" symRefs="true" version="3" sortRefs="true">

  <front>
		<title>
			The TACACS+

    <title abbrev="TACACS+">The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol
    </title>
    <seriesInfo name="RFC" value="8907"/>
    <author initials="T." surname="Dahm" fullname="Thorsten Dahm">
      <organization>Google Inc</organization> Inc.</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
					<country>US</country>
          <country>United States of America</country>
        </postal>

				<phone />
        <phone/>
        <email>thorstendlux@google.com</email>
				<uri />
        <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>
          <country>United States of America</country>
        </postal>

				<phone />
        <phone/>
        <email>andrej@ota.si</email>
				<uri />
        <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>
          <country>United States of America</country>
        </postal>
        <email>dcmgash@cisco.com</email>
				<uri />
        <uri/>
      </address>
    </author>

    <author initials="D." surname="Carrel" fullname="David Carrel">
			<organization>vIPtela, Inc.</organization>
      <organization>IPsec Research</organization>
      <address>
				<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 />

        <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 day="20" month="March" year="2020" />  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 protocol, which is widely deployed today to provide
      Device Administration for routers, network access
				servers servers, and other
      networked computing devices via one or more centralized servers.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="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 Authorization, and Accounting (AAA) protocol. It is
      widely deployed today but is mainly confined for a specific subset of AAA:
      AAA called Device Administration, that is: which includes authenticating access to network
      devices, providing central authorization of operations, and audit auditing of
      those operations.</t>

      <t>
	A wide range of TACACS+ clients and servers are is already deployed in the
	field. The TACACS+ protocol they are based on is defined in a
				draft document
	that was originally intended for IETF publication, but was never
	standardized.  The draft document is known as "The Draft" <xref target="TheDraft">`The Draft'</xref>. target="THE-DRAFT"
	format="default"/>.
      </t>
      <t> This Draft was a product of its time, time and did not address all of the
      key security concerns which that are considered when designing modern
      standards. Deployment Therefore, deployment must therefore be executed with care. These
      concerns are addressed in the <xref target="TACACSSecurity">security section</xref>. target="TACACSSecurity"
      format="default"/>.
      </t>
      <t>
	The primary intent of this informational document is to clarify the
	subset of `The Draft' "The Draft", which is common to implementations supporting
	Device Administration.  It is intended that all implementations which that
	conform to this document will conform to `The Draft'. "The Draft". However, it is
	not intended that all implementations which that conform to 'The Draft' "The Draft" will
	conform to this document. The following features from `The Draft' "The Draft" have
	been removed:
					<list>
						<t>This
      </t>
      <ul empty="false" spacing="normal">
        <li>This document officially removes SENDPASS for security
							reasons.</t>
						<t>The
        reasons.</li>

        <li>The normative description of Legacy legacy features such as
							ARAP the Apple
        Remote Access Protocol (ARAP) and outbound authentication has been removed.</t>
						<t>The
        removed.</li>
        <li>The Support for forwarding to an alternative daemon
        (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated.</t>
					</list>
			</t> deprecated.</li>
      </ul>
      <t>The TACACS+ protocol allows for arbitrary length and content
      authentication
				exchanges, 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>
	The separation of authentication, authorization authorization, and accounting is a
	key element of the design of TACACS+ protocol. Essentially Essentially, it makes
	TACACS+ a suite of three protocols.  This document will address each
	one in separate sections. Although TACACS+ defines all three, an
	implementation or deployment is not required to employ all three.
	Separating the elements is useful for the Device Administration use
	case, specifically, for authorization and accounting of individual commands in a
	session.  Note that there is no provision made at the protocol level for
				association of an
				authentication
	to associate authentication requests with authorization requests.
      </t>

    </section>
    <section anchor="Conventions" title="Conventions">
			<t>The numbered="true" toc="default">
      <name>Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
				NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
				"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 [RFC2119] [RFC8174] BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
        </t>

    </section>
    <section anchor="TechnicalDefinitions" title="Technical Definitions"> numbered="true" toc="default">
      <name>Technical Definitions</name>
      <t>This section provides a few basic definitions that are applicable to
      this document</t> document.</t>
      <section anchor="Client" title="Client"> numbered="true" toc="default">
        <name>Client</name>
        <t>The client is any device which that initiates TACACS+ protocol requests
        to mediate access, mainly for the Device Administration use case.</t>
      </section>
      <section anchor="Server" title="Server"> numbered="true" toc="default">
        <name>Server</name>
        <t>The server receives TACACS+ protocol requests, requests and replies
        according to its business model, model in accordance with the flows defined
        in this document.</t>
      </section>
      <section anchor="Packet" title="Packet"> numbered="true" toc="default">
        <name>Packet</name>

        <t>All uses of the word packet in this document refer to TACACS+
        protocol data units unless explicitly noted otherwise. The informal
        term "Packet" "packet" has become an established part of the definition.</t>
      </section>
      <section anchor="Connection" title="Connection"> numbered="true" toc="default">
        <name>Connection</name>
        <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"> numbered="true" toc="default">
        <name>Session</name>
        <t>
					The concept of a session is used
					throughout this document. A TACACS+
					session is a single authentication
					sequence, a single authorization
					exchange, or a single accounting
					exchange.
        </t>
        <t>
					An accounting and authorization
					session will consist of a single pair
					of packets (the request and its
					reply). An authentication session may
					involve an arbitrary number of packets
					being exchanged.  The session is an
					operational concept that is maintained
					between the TACACS+ client and
					server. It does not necessarily
					correspond to a given user or user
					action.
        </t>
      </section>
      <section anchor="TreatmentOfEnumeratedValues" title="Treatment numbered="true" toc="default">
        <name>Treatment of Enumerated Protocol Values"> Values</name>
        <t>
					This document describes various
					enumerated values in the packet header
					and the headers for specific packet
					types. For example, in the
					Authentication
					authentication start packet type, this
					document defines the action field with
					three values values: TAC_PLUS_AUTHEN_LOGIN,
					TAC_PLUS_AUTHEN_CHPASS
					TAC_PLUS_AUTHEN_CHPASS, and
					TAC_PLUS_AUTHEN_SENDAUTH.
        </t>
        <t>If the server does not implement one of the defined 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 should 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
					incoming packet cannot be determined,
					a packet with the identical cleartext
					header but with a sequence number
					incremented by one and the length set
					to zero
					MUST <bcp14>MUST</bcp14> be
					returned to indicate an error.
        </t>
      </section>
      <section anchor="TextEncoding" title="Treatment numbered="true" toc="default">
        <name>Treatment of Text Strings"> Strings</name>
        <t>The TACACS+ protocol makes extensive use of text strings.
					The
					original draft "The
        Draft" intended that these strings would be treated as byte arrays
        where each byte would represent a US-ASCII character.
        </t>

        <t>More recently, server implementations have been extended to
        interwork with external identity services, and so a more nuanced
        approach is needed.  Usernames MUST <bcp14>MUST</bcp14> be encoded and
        handled using the UsernameCasePreserved Profile specified in <xref target="RFC8265">RFC 8265</xref>.
        target="RFC8265" format="default"/>. The security
        considerations in Section 8 of that RFC <xref target="RFC8265" sectionFormat="of"
	section="8" /> apply.
        </t>
        <t>Where specifically mentioned, data fields contain 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
					<bcp14>MUST</bcp14> be treated as
					printable byte arrays of US-ASCII as
					defined by <xref target="RFC0020">RFC 20</xref>. target="RFC0020"
					format="default"/>.  The term
					"printable" used here means the fields MUST
					<bcp14>MUST</bcp14> exclude the
					"Control Characters" defined in section
					5.2 of <xref target="RFC0020">RFC 20</xref>.
					target="RFC0020" sectionFormat="of"
					section="5.2"/>.
        </t>
      </section>

    </section>
    <section anchor="TACACSPacketsSessions" title="TACACS+ numbered="true" toc="default">
      <name>TACACS+ Packets and Sessions"> Sessions</name>
      <section anchor="TheTACACSPacketHeader" title="The numbered="true" toc="default">
        <name>The TACACS+ Packet Header"> Header</name>
        <t>
					All TACACS+ packets begin with the
					following 12-byte header. The header
					describes the remainder of the packet:
        </t>
				<figure>
					<artwork><![CDATA[
        <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
+----------------+----------------+----------------+----------------+
|major  | minor  |                |                |                |
|version| version|      type      |     seq_no     |   flags        |
+----------------+----------------+----------------+----------------+
|                                                                   |
|                            session_id                             |
+----------------+----------------+----------------+----------------+
|                                                                   |
|                              length                               |
+----------------+----------------+----------------+----------------+
                    ]]></artwork>
				</figure>
        <t>The following general rules apply to all TACACS+ packet types:
        </t>
				<t>
					<list>
						<t>
							-
        <ul empty="false" spacing="normal">
          <li>
	To signal that any variable length variable-length data fields are unused, the
	corresponding length values are set to zero. Such fields MUST
	<bcp14>MUST</bcp14> be ignored, and treated as if not present.
						</t>
						<t>
							- the
						</li>
          <li>
	The lengths of data and message fields in a packet are specified by
	their corresponding length fields, field (and are not null
							terminated.)
						</t>
						<t>
							- terminated).
						</li>

          <li>
	All length values are unsigned and in network byte order.
						</t>
					</list>
				</t>
						</li>
        </ul>

        <t>
					major_version
        </t>
<ul empty="true">
<li>
   <t>
					This is the major TACACS+ version number.
        </t>
				<t>
					<list>
						<t>
</li>
</ul>

        <ul empty="true" spacing="normal">
          <li>
							TAC_PLUS_MAJOR_VER := 0xc
						</t>
					</list>
				</t>
						</li>
        </ul>
        <t>
					minor_version
        </t>
<ul empty="true">
<li>
        <t>
					The
					This is the minor TACACS+ version number.
        </t>
				<t>
					<list>
						<t>
</li>

          <li>
							TAC_PLUS_MINOR_VER_DEFAULT := 0x0
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_MINOR_VER_ONE := 0x1
						</t>
					</list>
				</t>
						</li>
        </ul>
        <t>
					type
        </t>
<ul empty="true">
<li>
 <t>
   This is the packet type. Options are:
        </t>
				<t>
					<list>
						<t>
</li>
<li>Options are:
</li>

          <li>
							TAC_PLUS_AUTHEN := 0x01 (Authentication)
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHOR := 0x02 (Authorization)
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_ACCT := 0x03 (Accounting)
						</t>
					</list>
				</t>
						</li>
        </ul>
        <t>

					seq_no
        </t>
<ul empty="true">
<li>
        <t>
	This is the sequence number of the current packet. The first packet in
	a session
					MUST <bcp14>MUST</bcp14> have the sequence number
					1 1, and each
	subsequent packet will increment the sequence number by one.  TACACS+ Clients
	clients only send packets containing odd sequence numbers, and TACACS+
	servers only send packets containing even sequence numbers.
        </t>
</li>

<li>
        <t>
	The sequence number must never wrap i.e. wrap, i.e., if the sequence number
					2^8-1 2<sup>8</sup>-1
	is ever reached, that session must terminate and be restarted with a
	sequence number of 1.
        </t>
</li>
</ul>

        <t>
	flags
        </t>
<ul empty="true">
<li>
<t>
        This field contains various bitmapped flags.
        </t>
</li>
<li>
 <t>
	The flag bit:
        </t>
</li>

<li>

<t>
TAC_PLUS_UNENCRYPTED_FLAG := 0x01
</t>
</li>

    <li>
        <t>
					This flag indicates that the sender
					did not obfuscate the body of the
					packet. This option MUST NOT <bcp14>MUST
					NOT</bcp14> be used in production. The
					application of this flag will be
					covered in the
					security
					<xref target="TACACSSecurity">section</xref>. "Security Considerations"
					(<xref target="TACACSSecurity"
					format="default"/>).
        </t>
    </li>
<li>
<t>
		This flag SHOULD <bcp14>SHOULD</bcp14> be clear in all
		deployments. Modern network traffic tools support encrypted
		traffic when configured with the shared secret (see section
					below), "Shared Secrets" (<xref
		target="SharedSecrets" />)), so obfuscated mode can and SHOULD
		<bcp14>SHOULD</bcp14> be used even during test.
        </t>
</li>

<li>
        <t>
		The single-connection flag:
        </t>
</li>

<li>

        <t>
		TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04

     </t>
</li>
<li>
        <t>
		This flag is used to allow a client and server to negotiate <xref target="SingleConnectMode">Single
		"Single Connection Mode</xref>. Mode" (<xref target="SingleConnectMode"
		format="default"/>).
        </t>
</li>
<li>
     <t>
		All other bits MUST <bcp14>MUST</bcp14> be ignored when reading,
		and SHOULD <bcp14>SHOULD</bcp14> be set to zero when writing.
        </t>
</li>
</ul>
        <t>
		session_id
        </t>
<ul empty="true">
<li>
   <t>
		The Id for this TACACS+ session. This field does not change
		for the duration of the TACACS+ session. This number MUST
		<bcp14>MUST</bcp14> be generated by a cryptographically strong
		random number generation method. Failure to do so will
		compromise security of the session. For more details details, refer to
		<xref target="RFC4086">RFC 4086</xref>. target="RFC4086" format="default"/>.
        </t>
</li>
</ul>

<t>
					length
        </t>
<ul empty="true">
     <li>   <t>
The total length of the packet body (not including
the header). Implementations <bcp14>MUST</bcp14> allow control over
maximum packet sizes accepted by TACACS+ Servers.
The recommended maximum packet size is 2<sup>16</sup>.

        </t>
   </li>
</ul>
   </section>
      <section anchor="TheTACACSPacketBody" title="The numbered="true" toc="default">
        <name>The TACACS+ Packet Body"> Body</name>
        <t>
					The TACACS+ body types are defined in
					the packet header. The next sections
					of this document will address the
					contents of the different TACACS+
					bodies.
        </t>
      </section>
      <section anchor="SingleConnectMode" title="Single numbered="true" toc="default">
        <name>Single Connection Mode"> Mode</name>
        <t>
					Single Connection Mode is intended to
					improve performance where there is a
					lot of traffic between a client and a
					server by allowing the client to
					multiplex multiple session sessions on a
					single TCP connection.
        </t>
        <t>
					The packet header contains the
					TAC_PLUS_SINGLE_CONNECT_FLAG used by
					the client and server to negotiate the
					use of Single Connect Connection Mode.
        </t>
        <t>
					The client sets this flag, flag to indicate
					that it supports multiplexing TACACS+
					sessions over a single TCP
					connection. The client MUST NOT <bcp14>MUST
					NOT</bcp14> send a second packet on a
					connection until single-connect status
					has been established.
        </t>
        <t>
					To indicate it will support Single
					Connection Mode, the server sets this
					flag in the first reply packet in
					response to the first request from a
					client. The server may set this flag
					even if the client does not set it,
					but the client may ignore the flag and
					close the connection after the session
					completes.
        </t>
        <t>
					The flag is only relevant for the
					first two packets on a connection, to
					allow the client and server to
					establish Single Connection Mode. No
					provision is made for changing Single
					Connection Mode after the first two packets:
					packets; the client and server MUST
					<bcp14>MUST</bcp14> ignore the flag
					after the second packet on a
					connection.
        </t>
        <t>
					If
					single Single Connection Mode has not been
					established in the first two packets
					of a TCP connection, then both the
					client and the server close the
					connection at the end of the first
					session.
        </t>
        <t>The client negotiates Single Connection Mode to improve
        efficiency. The server may refuse to allow Single Connection Mode for
        the client. For example, it may not be appropriate to allocate a
        long-lasting TCP connection to a specific client in some deployments.
        Even if the server is configured to permit single Single Connection Mode for
        a specific client, the server may close the connection. For
					example: example, a
        server MUST <bcp14>MUST</bcp14> be configured to time out a Single
        Connection Mode TCP Connection connection after a specific period of inactivity
        to preserve its resources. The client MUST <bcp14>MUST</bcp14> accommodate
        such closures on a TCP session even after Single Connection Mode has
        been established.</t>
        <t>The TCP connection underlying the Single Connection Mode will close eventually,
        eventually either because of the timeout from the server or from an
        intermediate link.  If a session is in progress when the client
        detects disconnect disconnect, then the client should handle it as described in <xref target="SessionCompletion"/>.
        "Session Completion" (<xref target="SessionCompletion" format="default"/>).  If a session is
        not in progress, then the client will need to detect this, this and restart
        the single connection mode Single Connection Mode when the it initiates the next session.
        </t>
      </section>
      <section anchor="SessionCompletion" title="Session Completion"> numbered="true" toc="default">
        <name>Session Completion</name>

        <t>The REPLY packets defined for the packets packet types in the sections
        below (Authentication, Authorization Authorization, and Accounting) contain a status
        field.  The complete set of options for this field depend upon the
        packet type, but all three REPLY packet types define values
        representing PASS, ERROR ERROR, and FAIL, which indicate the last packet of a
        regular session (one which that is not aborted).</t>
        <t>The server responds with a PASS or a FAIL to indicate that the
        processing of the request completed and that the client can apply the
        result (PASS or FAIL) to control the execution of the action which that
        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 client cannot apply the
					result result,
        and it MUST <bcp14>MUST</bcp14> behave as if the server could not be
        connected to. For example, the client tries alternative methods, if
        they are available, such as sending the request to a backup server, server or
        using local configuration to determine whether the action which that
        prompted the request should be executed.</t>
        <t>
	Refer to
					<xref target="AbortinganAuthenticationSession"/>
					on Aborting "Aborting an Authentication Sessions Session" (<xref target="AbortinganAuthenticationSession"
	format="default"/>) for details
	on handling additional status options.
        </t>
        <t>When the session is complete, then the TCP connection should be
        handled as follows, according to whether Single Connection Mode was
        negotiated:</t>
<ul>
<li>
        <t>If Single Connection Mode was not negotiated, then the connection
        should be closed</t> closed.</t>
</li>
<li>
<t>

					If Single Connection Mode was enabled,
					then the connection SHOULD
					<bcp14>SHOULD</bcp14> be left open
					(see
					<xref target="SingleConnectMode"/>), "Single Connection Mode" (<xref target="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 secret (see <xref target="Obfuscation"/>),
					target="Obfuscation"
					format="default"/>)), then any further
					new sessions MUST NOT <bcp14>MUST NOT</bcp14>
					be accepted on the connection.  If
					there are any sessions that have
					already been
					established established, then they
					MAY
					<bcp14>MAY</bcp14> be completed. Once
					all active sessions are
					completed completed, then
					the connection MUST <bcp14>MUST</bcp14> be
					closed.
        </t>
</li>
</ul>
     <t>It is recommended that client implementations provide robust
        schemes for dealing with servers which that cannot be connected to.  Options
        include providing a list of servers for redundancy, 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
					which that
					establishes a connection, connection but does not
					respond. The exact behavior is
					implementation specific. It is
					recommended that the client should
					close the connection after a
					configurable timeout.
        </t>
      </section>
      <section anchor="Obfuscation" title="Data 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' "The
					Draft", this process was actually
					referred to as Encryption, but the
					algorithm would not meet modern standards,
					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
					MUST
					<bcp14>MUST</bcp14> remain secret.
        </t>
        <t>Server implementations MUST <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 MUST <bcp14>MUST</bcp14> be configured with the following bit as follows:
				</t>
				<t>
 TAC_PLUS_UNENCRYPTED_FLAG = 0x0
				</t>
				<t>
					So set to 0 so that the packet body is obfuscated by
					XOR-ing
 XORing it
					byte-wise bytewise with a pseudo-random pad. pad:
</t>
				<t>
					ENCRYPTED

<ul empty="true">

<li>
<t>ENCRYPTED {data} = data ^ pseudo_pad <sup>pseudo_pad</sup>
</t>
				<t>
					The
</li>
</ul>

<t>The packet body can then be de-obfuscated by
					XOR-ing XORing it
					byte-wise bytewise
  with a pseudo random pseudo-random pad.
</t>

<ul empty="true">
<li>
     <t>
					data = ENCRYPTED {data} ^ pseudo_pad <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>
				<t>

					Whenever used in this document, MD5 refers to
					the "RSA Data
					Security, Inc. Inc.&nbsp; MD5 Message-Digest
					Algorithm" as specified in
					<xref target="RFC1321">RFC 1321</xref>. target="RFC1321" format="default"/>.
        </t>
<ul empty="true">
<li>
        <t>
					pseudo_pad = {MD5_1 [,MD5_2 [
					... ,MD5_n]]} truncated to len(data)
        </t>
</li>
</ul>

        <t>
					The first MD5 hash is generated by
					concatenating the session_id, the
					secret key, the version
					number number, and the
					sequence number number, and then running MD5
					over that stream. All of those input
					values are available in the packet
					header, except for the secret key
					key, which
					is a shared secret between the TACACS+
					client and server.
        </t>
        <t>
					The version number and session_id are extracted from the
					header
					header.
        </t>
        <t>
					Subsequent hashes are generated by
					using the same input stream, stream but
					concatenating the previous hash value
					at the end of the input stream.
        </t>

<ul empty="true">
<li>
     <t>
					MD5_1 = MD5{session_id, key, version,
					seq_no} MD5_2 = MD5{session_id, key,
					version, seq_no, MD5_1} ....  MD5_n =
					MD5{session_id, key, version, seq_no,
					MD5_n-1}
        </t>
</li>
</ul>

        <t>

					When a server detects that the secret(s)
					secrets it has configured for the
					device mismatch, do not match, it MUST
					<bcp14>MUST</bcp14> return ERROR. For
					details of TCP connection handling on
					ERROR, refer to
					<xref target="SessionCompletion"/>.
				</t> "Session Completion" (<xref
					target="SessionCompletion"
					format="default"/>).
        </t>
<ul empty="true">
<li>
        <t>
					TAC_PLUS_UNENCRYPTED_FLAG == 0x1
        </t>
</li>
</ul>
        <t>
					This option is deprecated and MUST NOT
					<bcp14>MUST NOT</bcp14> be used in
					production. In this case, the entire
					packet body is in cleartext. A request MUST
					<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
					component
					values
					in the packet are summed. If the sum is not
					identical to the
					cleartext
					datalength value from the header,
					the
					packet MUST <bcp14>MUST</bcp14> be
					discarded,
					discarded and an ERROR signaled. For details of TCP connection
					handling on ERROR, refer to
					<xref target="SessionCompletion"/>.
					"Session Completion" (<xref target="SessionCompletion" format="default"/>).
        </t>
        <t>
					Commonly
					Commonly, such failures are seen when
					the keys are mismatched between the
					client and the TACACS+ server.
        </t>

      </section>
    </section>
    <section anchor="Authentication" title="Authentication"> numbered="true" toc="default">
      <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, 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 below). "Authorization" (<xref target="Authorization"/>)).  Authentication may also take place
      when a user attempts to gain extra privileges, privileges and must identify himself
      or herself as someone who possesses the required information (passwords,
      etc.) for those privileges.</t>
      <section anchor="TheAuthenticationSTARTPacketBody" title="The numbered="true" toc="default">
        <name>The Authentication START Packet Body">
				<figure>
					<artwork><![CDATA[ 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
+----------------+----------------+----------------+----------------+
|    action      |    priv_lvl    |  authen_type   | authen_service |
+----------------+----------------+----------------+----------------+
|    user_len    |    port_len    |  rem_addr_len  |    data_len    |
+----------------+----------------+----------------+----------------+
|    user ...
+----------------+----------------+----------------+----------------+
|    port ...
+----------------+----------------+----------------+----------------+
|    rem_addr ...
+----------------+----------------+----------------+----------------+
|    data...
+----------------+----------------+----------------+----------------+
                                    ]]></artwork>
				</figure>
        <t>
					Packet fields are as follows:
        </t>
        <t>
		action
        </t>
<ul empty="true">
   <li> <t> This indicates the authentication action. Valid
					values
					are listed
					below. </t>
<t>
					<list>
						<t>
Valid values are:
        </t>
   </li>
          <li>
							TAC_PLUS_AUTHEN_LOGIN := 0x01
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_CHPASS := 0x02
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SENDAUTH := 0x04
						</t>
					</list>
				</t>
						</li>
        </ul>
        <t>
					priv_lvl
        </t>

<ul empty="true">
<li> <t> This indicates the privilege level that the user is authenticating
as. Please refer to the
					<xref target="PrivilegeLevel">Privilege Level section</xref>
					below. "Privilege Levels" (<xref target="PrivilegeLevel"
format="default"/>).
</t>
</li>
</ul>

 <t>
authen_type
        </t>
<ul empty="true">
<li>
   <t>
The type of authentication. Please see section
					<xref target="CommonAuthenticationFlows">Common "Common Authentication Flows</xref>. Flows" (<xref
target="CommonAuthenticationFlows" format="default"/>).
   </t>
  </li>
<li>
<t>
Valid values are:
        </t>
				<t>
					<list>
						<t>
</li>
          <li>
							TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_TYPE_PAP := 0x02
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06
						</t>
					</list>
				</t>
						</li>
    </ul>

        <t>
					authen_service
        </t>

<ul empty="true">
<li>
   <t>
					This is the service that is requesting
					the authentication.
					</t>
					</li>
<li>
<t>
Valid values are:
        </t>
				<t>
					<list>
						<t>
</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_NONE := 0x00
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_PPP := 0x03
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_PT := 0x05
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_RCMD := 0x06
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_X25 := 0x07
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_NASI := 0x08
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09
						</t>
					</list>
				</t>
						</li>
     <li>
        <t>The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the
        authorization application of this field that indicates that no
        authentication was performed by the device.</t>
        <t>The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as
        opposed to ENABLE) to a client device.</t>
     </li>

<li>
<t>
					The TAC_PLUS_AUTHEN_SVC_ENABLE option
					identifies the ENABLE authen_service,
					which refers to a service requesting
					authentication in order to grant the
					user different privileges. This is
					comparable to the Unix "su(1)"
					command, which substitutes the current
					user's identity with another. An
					authen_service value of NONE is only
					to be used when none of the other
					authen_service values are appropriate.
					ENABLE may be requested
					independently, independently;
					no requirements for previous
					authentications or authorizations are
					imposed by the protocol.
        </t>

</li>
<li>
        <t>Other options are included for legacy/backwards compatibility.</t>
</li>
</ul>
     <t>
					user, user_len
        </t>
<ul empty="true">
<li>
   <t>
					The username is optional in this
					packet, depending upon the class of
					authentication. If it is absent, the
					client MUST <bcp14>MUST</bcp14> set
					user_len to 0.  If included, the
					user_len indicates the length of the
					user field, in bytes.
        </t>
</li>
</ul>
        <t>
					port, port_len
        </t>
<ul empty="true">
<li>
 <t>
					The name of the client port on which
					the authentication is taking place.
					The value of this field is free format free-format
					text and is client specific.  Examples
					of this this argument include "tty10"
					to denote the tenth tty line line, and
					"async10" to denote the tenth async
					interface. The client documentation SHOULD
					<bcp14>SHOULD</bcp14> define the
					values and their meanings for this
					field.  For details of
					<xref target="TextEncoding">text text encoding, see</xref>.
					see "Treatment of Text Strings" (<xref
					target="TextEncoding"
					format="default"/>).  The port_len indicates the
					length of the port field, in bytes.
        </t>
</li>
</ul>

     <t>
					rem_addr, rem_addr_len
        </t>

<ul empty="true">
<li>
        <t>
					A string indicating the remote
					location from which the user has
					connected to the client. For details
					of
					<xref target="TextEncoding">text text encoding, see</xref>. see "Treatment of
					Text Strings" (<xref
					target="TextEncoding"
					format="default"/>).
        </t>

</li>
<li>
        <t> When TACACS+ was used for dial-up services, this value contained
        the caller ID</t> ID.</t>
</li>
<li>
   <t>
					When TACACS+ is used for Device
					Administration, the user is normally
					connected via a network, and in this case
					case, the value is intended to hold a
					network address, IPv4 or IPv6. For
					IPv6 address text representation
					defined
					defined, please see <xref target="RFC5952">RFC 5952</xref>.
					target="RFC5952" format="default"/>.
        </t>
</li>
<li>
        <t>This field is optional (since the information may not be
        available).  The rem_addr_len indicates the length of the user field,
        in bytes.
        </t>
</li>
</ul>
        <t>
					data, data_len
        </t>

<ul empty="true">
<li>
   <t>
					This
	The data field is used to send data appropriate for the action and
	authen_type. It is described in more detail in the section
					<xref target="CommonAuthenticationFlows">Common "Common Authentication flows</xref>.
	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" title="The numbered="true" toc="default">
        <name>The Authentication REPLY Packet Body"> Body</name>

 <t>
					The TACACS+ server sends only one type
					of authentication packet (a REPLY
					packet) to the client.
        </t>

				<figure>
					<artwork><![CDATA[

        <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
+----------------+----------------+----------------+----------------+
|     status     |      flags     |        server_msg_len           |
+----------------+----------------+----------------+----------------+
|           data_len              |        server_msg ...
+----------------+----------------+----------------+----------------+
|           data ...
+----------------+----------------+
                    ]]></artwork>
				</figure>
        <t>
					status
        </t>
<ul empty="true">
<li>
        <t>
	The current status of the authentication. Valid
        </t>
</li>
<li>Valid values are:
				</t>
				<t>
					<list>
						<t>
</li>
</ul>
        <ul empty="true" spacing="normal">
          <li>
							TAC_PLUS_AUTHEN_STATUS_PASS := 0x01
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_STATUS_FAIL :=
							0x02
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_STATUS_ERROR
							:= 0x07
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21
						</t>
					</list>
				</t>
						</li>
        </ul>
        <t>
					flags
        </t>
<ul empty="true">
<li>
   <t>
	Bitmapped flags that modify the action to be taken.
					The
        </t>
</li>
<li>The following values are defined:
				</t>
				<t>
					<list>
						<t>
</li>
</ul>
        <ul empty="true" spacing="normal">
          <li>
							TAC_PLUS_REPLY_FLAG_NOECHO := 0x01
						</t>
					</list>
				</t>
						</li>
        </ul>
        <t>
					server_msg, server_msg_len
        </t>
<ul empty="true">
<li> <t>
	A message to be displayed to the user. This field is optional.  The
	server_msg_len indicates the length of the server_msg field, in bytes.
	For details of
					<xref target="TextEncoding">text text encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding" format="default"/>).
        </t>
</li>
</ul>
    <t>
					data, data_len
        </t>
<ul empty="true">
<li>
        <t>
					This
	A field that holds data that is a part of the authentication exchange
	and is intended for client processing, not the user. It is not a
	printable text encoding. Examples of its use are shown in the section
					<xref target="CommonAuthenticationFlows">Common "Common
	Authentication flows</xref>. Flows" (<xref target="CommonAuthenticationFlows"
	format="default"/>). The data_len indicates the length of the data
	field, in bytes.
        </t>
</li>
</ul>
      </section>
      <section anchor="TheAuthenticationCONTINUEPacketBody" title="The numbered="true" toc="default">
        <name>The Authentication CONTINUE Packet Body"> Body</name>

        <t>
	This packet is sent from the client to the server following the
	receipt of a REPLY packet.
        </t>
				<figure>
					<artwork><![CDATA[
        <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
+----------------+----------------+----------------+----------------+
|          user_msg len           |            data_len             |
+----------------+----------------+----------------+----------------+
|     flags      |  user_msg ...
+----------------+----------------+----------------+----------------+
|    data ...
+----------------+
                    ]]></artwork>
				</figure>
        <t>
					user_msg, user_msg_len
        </t>
<ul empty="true">
<li>
   <t>
					This
	A field that is the string that the user entered, or the client
	provided on behalf of the user, in response to the server_msg from a
	REPLY packet. The user_len indicates the length of the user field, in
	bytes.
        </t>
</li>
</ul>
        <t>
					data, data_len
        </t>
<ul empty="true">

<li>
 <t>
	This field carries information that is specific to the action and the
	authen_type for this session. Valid uses of this field are described
	below. It is not a printable text encoding. The data_len indicates the
	length of the data field, in bytes.
        </t>
</li>
</ul>

     <t>
					flags
        </t>
<ul empty="true">
<li>
 <t>
	This holds the bitmapped flags that modify the action to be taken.
	</t>
	</li>
<li>
<t>
	The following values are defined:
        </t>
				<t>
					<list>
						<t>
</li>
          <li>
							TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01
						</t>
					</list>
				</t>
						</li>
        </ul>

 </section>
      <section anchor="DescriptionofAuthenticationProcess" title="Description numbered="true" toc="default">
        <name>Description of Authentication Process"> Process</name>
        <t>
	The action, authen_type authen_type, and authen_service fields (described above)
	combine to indicate what kind of authentication is to be performed.
	Every authentication START, REPLY REPLY, and CONTINUE packet includes a data
	field. The use of this field is dependent upon the kind of the
					Authentication.
	authentication.
        </t>
        <t>
	This document defines a core set of authentication flows to be
	supported by TACACS+.  Each authentication flow consists of a START
	packet.  The server responds either with a request for more
	information (GETDATA,
					GETUSER GETUSER, or GETPASS) or a termination PASS, FAIL, ERROR
	ERROR, or RESTART. The actions and meanings when the server sends a
	RESTART or ERROR are common and are described further below.
        </t>
        <t>
	When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA,
					TAC_PLUS_AUTHEN_STATUS_GETUSER
	TAC_PLUS_AUTHEN_STATUS_GETUSER, or TAC_PLUS_AUTHEN_STATUS_GETPASS,
					then
	authentication continues and the server SHOULD <bcp14>SHOULD</bcp14> provide
	server_msg content for the client to prompt the user for more
	information. The client MUST <bcp14>MUST</bcp14> then return a CONTINUE
	packet containing the requested information in the user_msg field.
        </t>
        <t>
	The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a
	request for a username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request
	for a password.  The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic
	request for more information to flexibly support future requirements.
        </t>
        <t>If the information being requested by the server form from 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 <bcp14>MUST NOT</bcp14> be reflected in the user interface as
        it is entered.
        </t>
        <t>
					The data field is only used in the REPLY
					where
					explicitly
					defined
					below.
        </t>
        <section anchor="VersionBehaviour" title="Version Behavior"> numbered="true" toc="default">
          <name>Version Behavior</name>
          <t>
						The TACACS+ protocol is
						versioned to allow revisions
						while maintaining backwards
						compatibility. The version
						number is in every packet
						header. The changes between
						minor_version 0 and 1 apply
						only to the authentication
						process, and all deal with the
						way that CHAP Challenge
						Handshake
						Authentication
						Protocol (CHAP) and PAP
						Password
						Authentication
						Protocol (PAP)
						authentications are
						handled. minor_version 1 may
						only be used for
						authentication kinds that
						explicitly call for it in the
						table below:
          </t>
					<figure>
						<artwork><![CDATA[
             LOGIN    CHPASS   SENDAUTH
ASCII          v0         v0       -
PAP            v1         -        v1
CHAP           v1         -        v1
MS-CHAPv1/2    v1         -        v1
                                        ]]>
						</artwork>
					</figure>

<table anchor="table_1">
  <name>TACACS+ Protocol Versioning</name>

  <tbody>
    <tr>
      <td></td>
      <td>LOGIN</td>
      <td>CHPASS</td>
      <td>SENDAUTH</td>
    </tr>
    <tr>
      <td>ASCII</td>
      <td>v0</td>
      <td>v0</td>
      <td>-</td>
    </tr>
    <tr>
      <td>PAP</td>
      <td>v1</td>
      <td>-</td>
      <td>v1</td>
    </tr>
    <tr>
      <td>CHAP</td>
      <td>v1</td>
      <td>-</td>
      <td>v1</td>
    </tr>
    <tr>
      <td>MS-CHAPv1/2</td>
      <td>v1</td>
      <td>-</td>
      <td>v1</td>
    </tr>
  </tbody>
</table>

          <t>The '-' symbol represents that the option is not valid.</t>

          <t>
		All authorization and accounting and ASCII authentication use
		minor_version number
						of 0.
          </t>

          <t>
					</t>
					<t>
	PAP, CHAP CHAP, and MS-CHAP login use minor_version 1.  The normal exchange
	is a single START packet from the client and a single REPLY from the
	server.
          </t>
          <t> The removal of SENDPASS was prompted by security concerns, concerns and
          is no longer considered part of the TACACS+ protocol.
          </t>
        </section>
        <section anchor="CommonAuthenticationFlows" title="Common numbered="true" toc="default">
          <name>Common Authentication Flows"> Flows</name>
          <t>
	This section describes common authentication flows. If the server does
	not implement an option, it MUST <bcp14>MUST</bcp14> respond with
	TAC_PLUS_AUTHEN_STATUS_FAIL.
          </t>
          <section anchor="ASCIILogin" title="ASCII Login">
						<figure>
							<artwork><![CDATA[ numbered="true" toc="default">
            <name>ASCII Login</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
    minor_version = 0x0
                                        ]]>
							</artwork>
						</figure>
							]]></artwork>
            <t>
	This is a standard ASCII authentication. The START packet MAY
	<bcp14>MAY</bcp14> contain the username. If the user does not include
	the username username, then the server MUST <bcp14>MUST</bcp14> obtain it from the
	client with a CONTINUE TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user
	does not provide a
							username username, then the server can send another
	TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server MUST
	<bcp14>MUST</bcp14> limit the number of retries that are permitted, permitted;
	the recommended limit is three attempts. When the server has the
	username, it will obtain the password using a continue with
	TAC_PLUS_AUTHEN_STATUS_GETPASS.  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, logins; any content MUST
	<bcp14>MUST</bcp14> be ignored.  The session is composed of a single
	START followed by zero or more pairs of REPLYs and CONTINUEs, followed
	by a final REPLY indicating PASS, FAIL FAIL, or ERROR.
            </t>
          </section>
          <section anchor="PAPLogin" title="PAP Login">
						<figure>
							<artwork><![CDATA[ numbered="true" toc="default">
            <name>PAP Login</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
    minor_version = 0x1
                                        ]]>
							</artwork>
						</figure>
							]]></artwork>
            <t>
	The entire exchange MUST <bcp14>MUST</bcp14> consist of a single START
	packet and a single REPLY. The START packet
							MUST <bcp14>MUST</bcp14>
	contain a username and the data field MUST <bcp14>MUST</bcp14> contain the
	PAP ASCII password. A PAP authentication only consists of a username
	and password <xref target="RFC1334">RFC 1334</xref> target="RFC1334" format="default"/> (Obsolete). The
	REPLY from the server MUST <bcp14>MUST</bcp14> be either a PASS, FAIL FAIL, or
	ERROR.
            </t>
          </section>
          <section anchor="CHAPlogin" title="CHAP login">
						<figure>
							<artwork><![CDATA[ numbered="true" toc="default">
            <name>CHAP Login</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP
    minor_version = 0x1
                                        ]]>
							</artwork>
						</figure>
							]]></artwork>
            <t>
	The entire exchange MUST <bcp14>MUST</bcp14> consist of a single START
	packet and a single REPLY. The START packet
							MUST <bcp14>MUST</bcp14>
	contain the username in the user
							field field, and the data field is a
	concatenation of the PPP id, the
							challenge challenge, and the response.
            </t>
            <t>
	The length of the challenge value can be determined from the length of
	the data field minus the length of the id (always 1 octet) and the
	length of the response field (always 16 octets).
            </t>
            <t>
To perform the authentication, the server calculates the PPP hash as defined
in the PPP Authentication <xref target="RFC1334">RFC 1334</xref> target="RFC1334" format="default"/> and then
compares that value with the response. The MD5 algorithm option is always
used.  The REPLY from the server MUST <bcp14>MUST</bcp14> be a PASS,
							FAIL FAIL, or
ERROR.
            </t>
            <t>
	The selection of the challenge and its length are not an aspect of the
	TACACS+ protocol. However, it is strongly recommended that the
	client/endstation interaction is be configured with a secure
	challenge. The TACACS+ server can help by rejecting authentications
	where the challenge is below a minimum length (Minimum (minimum recommended is
	8 bytes).
            </t>
          </section>
          <section anchor="MS-CHAPv1login" title="MS-CHAP numbered="true" toc="default">
            <name>MS-CHAP v1 login">
						<figure>
							<artwork><![CDATA[ Login</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP
    minor_version = 0x1
                                        ]]>
							</artwork>
						</figure>
							]]></artwork>
            <t>
The entire exchange MUST <bcp14>MUST</bcp14> consist of a single START packet and a
single REPLY. The START packet
							MUST <bcp14>MUST</bcp14> contain the username in the
user
							field field, and the data field will be a concatenation of the PPP id, the
MS-CHAP challenge challenge, and the MS-CHAP response.
            </t>
            <t>
The length of the challenge value can be determined from the length of the
data field minus the length of the id (always 1 octet) and the length of the
response field (always 49 octets).
            </t>
            <t>
To perform the authentication, the server will use a combination of MD4 and
DES on the user's secret and the challenge, as defined in <xref target="RFC2433">RFC 2433</xref>
target="RFC2433" format="default"/>, and then compare the
resulting value with the response. The REPLY from the server MUST
<bcp14>MUST</bcp14> be a PASS or FAIL.
            </t>
            <t>
	For best practices, please refer to <xref target="RFC2433">RFC 2433</xref>. target="RFC2433"
	format="default"/>. The TACACS+ server MUST <bcp14>MUST</bcp14> reject
	authentications where the challenge deviates from 8 bytes as defined
	in the RFC.
            </t>
          </section>
          <section anchor="MS-CHAPv2login" title="MS-CHAP numbered="true" toc="default">
            <name>MS-CHAP v2 login">
						<figure>
							<artwork><![CDATA[ Login</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2
    minor_version = 0x1
                                        ]]>
							</artwork>
						</figure>
							]]></artwork>
            <t>
The entire exchange MUST <bcp14>MUST</bcp14> consist of a single START packet and a
single REPLY. The START packet
							MUST <bcp14>MUST</bcp14> contain the username in the
user
							field field, and the data field will be a concatenation of the PPP id, the
MS-CHAP challenge challenge, and the MS-CHAP response.
            </t>
            <t>
The length of the challenge value can be determined from the length of the
data field minus the length of the id (always 1 octet) and the length of the
response field (always 49 octets).
            </t>
            <t>
To perform the authentication, the server will use the algorithm specified
<xref target="RFC2759">RFC 2759</xref> target="RFC2759" format="default"/> on the user's secret and challenge challenge,
and then compare the resulting value with the response.  The REPLY from the
server MUST <bcp14>MUST</bcp14> be a PASS or FAIL.
            </t>
            <t>
For best practices for MS-CHAP v2, please refer to <xref target="RFC2759">RFC2759</xref>. target="RFC2759"
format="default">RFC2759</xref>. The TACACS+ server MUST <bcp14>MUST</bcp14> reject
authentications where the challenge deviates from 16 bytes as defined in the
RFC.
            </t>
          </section>
          <section anchor="EnableRequests" title="Enable Requests">
						<figure>
							<artwork><![CDATA[ numbered="true" toc="default">
            <name>Enable Requests</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    action = TAC_PLUS_AUTHEN_LOGIN
    priv_lvl = implementation dependent
    authen_type = not used
    service = TAC_PLUS_AUTHEN_SVC_ENABLE
                                        ]]>
							</artwork>
						</figure>
							]]></artwork>
            <t>
	This is an ENABLE "ENABLE" request, used to change the current running
	privilege level of a user.  The exchange MAY <bcp14>MAY</bcp14> consist of
	multiple messages while the server collects the information it
	requires in order to allow changing the principal's privilege
	level. This exchange is very similar to an
							<xref target="ASCIILogin">ASCII login</xref>. ASCII login (<xref target="ASCIILogin"
	format="default"/>).
            </t>
            <t>
In order to readily distinguish enable "ENABLE" requests from other types of request,
the value of the authen_service field MUST <bcp14>MUST</bcp14> be set to
TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST
							NOT <bcp14>MUST
NOT</bcp14> be set to this value when requesting any other operation.
            </t>
          </section>
          <section anchor="ASCIIchangepasswordrequest" title="ASCII change password request">
						<figure>
							<artwork><![CDATA[ numbered="true" toc="default">
            <name>ASCII Change Password Request</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
                                        ]]>
							</artwork>
						</figure>
							]]></artwork>
            <t>
	This exchange consists of multiple messages while the server collects
	the information it requires in order to change the user's password. It
	is very similar to an ASCII login. The status value
	TAC_PLUS_AUTHEN_STATUS_GETPASS MUST <bcp14>MUST</bcp14> only be used when
	requesting the "new" password. It MAY <bcp14>MAY</bcp14> be sent multiple
	times. When requesting the "old" password, the status value MUST
	<bcp14>MUST</bcp14> be set to TAC_PLUS_AUTHEN_STATUS_GETDATA.
            </t>
          </section>
        </section>
        <section anchor="AbortinganAuthenticationSession" title="Aborting numbered="true" toc="default">
          <name>Aborting an Authentication Session"> Session</name>
          <t>

The client may prematurely terminate a session by setting the
TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message.  If this flag is
set, the data portion of the message may contain a
						message text explaining the reason
for the abort. For details of
						<xref target="TextEncoding">text encoding, see</xref>. This information text will be handled by the server according to the
requirements of the deployment. The
						session is
						terminated, for For details of text encoding, see "Treatment
of Text Strings" (<xref target="TextEncoding" format="default"/>). For more
details about session termination, refer to
						<xref target="SessionCompletion"/>. "Session Completion" (<xref target="SessionCompletion"
format="default"/>).

          </t>
          <t>
	In cases of PASS, FAIL FAIL, or ERROR, the server can insert a message into
	server_msg to be displayed to the user.
          </t>
          <t>
						The Draft
	"The Draft" <xref target="TheDraft">`The Draft'</xref> target="THE-DRAFT" format="default"></xref>
	defined a mechanism to direct authentication requests to an
	alternative server. This mechanism is regarded as insecure, is
	deprecated, and is not covered here. The client should treat
	TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL TAC_PLUS_AUTHEN_STATUS_FAIL.
          </t>
          <t>
	If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is
	indicating that it is experiencing an unrecoverable error and the
	authentication will proceed as if that host could not be contacted.
	The data field may contain a message to be printed on an
	administrative console or log.
          </t>
          <t>
	If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the
	authentication sequence is restarted with a new START packet from the
	client, with a new session Id, 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 the TAC_PLUS_AUTHEN_STATUS_RESTART option,
	then it MUST <bcp14>MUST</bcp14> process the response as if the status was
	TAC_PLUS_AUTHEN_STATUS_FAIL.
          </t>
        </section>
      </section>
    </section>

    <section anchor="Authorization" title="Authorization"> numbered="true" toc="default">
      <name>Authorization</name>
      <t>In the TACACS+ Protocol, protocol, authorization is the action of determining
      what a user is allowed to do. Generally, authentication precedes
      authorization, though it is not mandatory that a client use the same
      service for authentication that it will use for authorization. An
      authorization request may indicate that the user is not authenticated
      (we don't know who they are). In this case 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 when 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">Authorization Arguments section</xref>. "Authorization Arguments" (<xref
target="AuthorizationAttributes" format="default"></xref>).
      </t>
      <t>
In the TACACS+ protocol 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 fixed 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 numbered="true" toc="default">
        <name>The Authorization REQUEST Packet Body">
				<figure>
					<artwork><![CDATA[ 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
+----------------+----------------+----------------+----------------+
|  authen_method |    priv_lvl    |  authen_type   | authen_service |
+----------------+----------------+----------------+----------------+
|    user_len    |    port_len    |  rem_addr_len  |    arg_cnt     |
+----------------+----------------+----------------+----------------+
|   arg_1_len    |   arg_2_len    |      ...       |   arg_N_len    |
+----------------+----------------+----------------+----------------+
|   user ...
+----------------+----------------+----------------+----------------+
|   port ...
+----------------+----------------+----------------+----------------+
|   rem_addr ...
+----------------+----------------+----------------+----------------+
|   arg_1 ...
+----------------+----------------+----------------+----------------+
|   arg_2 ...
+----------------+----------------+----------------+----------------+
|   ...
+----------------+----------------+----------------+----------------+
|   arg_N ...
+----------------+----------------+----------------+----------------+
                    ]]></artwork>
				</figure>
        <t>
					authen_method
        </t>
<ul empty="true">
<li>

<t>
This filed field allows the client to indicate the authentication method used by the to
acquire
					the user information.
        </t>
				<t>
					<list>
						<t>
</li>
          <li>
							TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_NONE :=
							0x01
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_KRB5 := 0x02
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_LINE :=
							0x03
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_ENABLE := 0x04
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_LOCAL
							:= 0x05
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_GUEST := 0x08
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_RADIUS :=
							0x10
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_KRB4 := 0x11
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_AUTHEN_METH_RCMD :=
							0x20
						</t>
					</list>
				</t>
						</li>

						<li>

        <t> As this information is not always subject to verification, it is recommended that this field is <bcp14>MUST
	NOT</bcp14> be used in policy evaluastion. evaluation.  LINE refers to a
        fixed password associated with the terminal line used to gain access.
        LOCAL is a client local user database. ENABLE is a command that
        authenticates in order to grant new privileges. TACACSPLUS is, of
        course, TACACS+.  GUEST is an unqualified guest authentication. RADIUS
        is the Radius RADIUS authentication protocol.  RCMD refers to authentication
        provided via the R-command protocols from Berkeley Unix.

	KRB5 <xref
	target="RFC4120"/> and KRB4 <xref target="KERB"/>
        are Kerberos version versions 5 and 4.
				</t> 4.</t>

     </li>
<li> <t> As mentioned above, this field is used by the client to indicate how
it performed the authentication. One of the options
(TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06) is TACACS+ itself, and so the detail
of how the client performed this option is given in
					<xref target="Authentication">Authentication Section</xref>. "Authentication" (<xref
target="Authentication" format="default"></xref>).  For all other options,
such as KRB and RADIUS, then the TACACS+ protocol did not play any part in the
authentication phase; as those interactions were not conducted using the
TACACS+ protocol protocol, they will not be documented here. For implementers of
clients who need details of the other protocols, please refer to the
respective Kerberos <xref target="RFC4120">Kerberos</xref> target="RFC4120" format="default"></xref> and RADIUS
<xref target="RFC3579">RADIUS</xref> target="RFC3579" format="default"></xref> RFCs.
				</t>  </t></li>
</ul>
        <t>
					priv_lvl
        </t>
<ul empty="true">
<li>
   <t>
This field is used in the same way as the priv_lvl field in authentication
request and is described in the
					<xref target="PrivilegeLevel">Privilege Level section</xref>
					below. "Privilege Levels" (<xref target="PrivilegeLevel"
format="default"></xref>). It indicates the users user's
current privilege level.
        </t>
</li>
</ul>
        <t>
					authen_type
        </t>
<ul empty="true">

<li> <t> This field corresponds to the authen_type field in the
					<xref target="Authentication">authentication section</xref>
					above. "Authentication" (<xref
target="Authentication" format="default"></xref>). It indicates
the type of authentication that was performed. If this information is not
available, then the client will set authen_type to: to
TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. This value is valid only in
authorization and accounting requests.
        </t>
</li>
</ul>
        <t>
					authen_service
        </t>
<ul empty="true">
<li>
   <t>
This field is the same as the authen_service field in the
					<xref target="Authentication">authentication section</xref>
					above. "Authentication" (<xref
target="Authentication" format="default"></xref>). It indicates
the service through which the user authenticated.
        </t>
</li>
</ul>

<t>
					user, user_len
        </t>
<ul empty="true">
<li>
        <t>
This field contains the user's account name. The user_len MUST <bcp14>MUST</bcp14>
indicate the length of the user field, in bytes.
        </t>
</li>
</ul>
     <t>
					port, port_len
        </t>

<ul empty="true">
<li>
   <t>
	This field matches the port field in the
					<xref target="Authentication">authentication section</xref>
					above. "Authentication" (<xref
	target="Authentication" format="default"></xref>). The port_len
	indicates the length of the port field, in bytes.
        </t>
</li>
</ul>

<t>
					rem_addr, rem_addr_len
        </t>

<ul empty="true">
<li>
        <t>
	This field matches the rem_addr field in the
					<xref target="Authentication">authentication section</xref>
					above. "Authentication" (<xref target="Authentication"
	format="default"></xref>). The rem_addr_len indicates the
	length of the port field, in bytes.
        </t>
</li>
</ul>
     <t>
					arg_cnt
        </t>
<ul empty="true">
<li>
   <t>
					The
					This represents the number of authorization arguments to follow follow.
        </t>
</li>
</ul>
        <t>
					arg_1 ... arg_N, arg_1_len .... arg_N_len
        </t>
<ul empty="true">
<li>

 <t>
					The
	These arguments are the primary elements of the authorization
	interaction. In the request packet, they describe the specifics of the
	authorization that is being requested.  Each argument is encoded in
	the packet as a single arg field (arg_1...  arg_N) with a
	corresponding length fields field (which indicates the length of each
	argument in bytes).
        </t>
</li>

<li>    <t>
	The authorization arguments in both the REQUEST and the REPLY are
	argument-value pairs. The argument and the value are in a single
	string and are separated by either a "=" (0X3D) or a "*" (0X2A). The
	equals sign indicates a mandatory argument. The asterisk indicates an
	optional one. For details of
					<xref target="TextEncoding">text text encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding"
	format="default"/>).
        </t>
</li>
<li>

        <t>
	An argument name MUST NOT <bcp14>MUST NOT</bcp14> contain either of the
	separators. An argument value MAY <bcp14>MAY</bcp14> contain the
	separators. This means that the arguments must be parsed until the
	first separator is encountered, encountered; all characters in the argument, after
	this separator, are interpreted as the argument value.
        </t>
</li>
<li>
     <t>
        Optional arguments are ones that may be disregarded by either client
        or server. Mandatory arguments require that the receiving side can
        handle the argument, that is: is, its implementation and configuration
        includes the details of how to act on it. If the client receives a
        mandatory argument that it cannot handle, it
					MUST <bcp14>MUST</bcp14>
        consider the authorization to have failed. The value part of an
        argument-value pair may be empty, that is: is, the length of the value may
        be zero.
        </t>
</li>
<li>
     <t>
	Argument-value strings are not NULL terminated,
					rather terminated; 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) separator).
        </t>
</li>
<li>
     <t>
Though the arguments allow extensibility, a common core set of authorization
arguments SHOULD <bcp14>SHOULD</bcp14> be supported by clients and
					servers, servers; these are
listed in the
					<xref target="AuthorizationAttributes">Authorization Arguments</xref>
					section below. "Authorization Arguments" (<xref target="AuthorizationAttributes"
format="default"></xref>).
        </t>
</li>
</ul>
      </section>
      <section anchor="TheAuthorizationREPLYPacketBody" title="The numbered="true" toc="default">
        <name>The Authorization REPLY Packet Body">
				<figure>
					<artwork><![CDATA[ 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
+----------------+----------------+----------------+----------------+
|    status      |     arg_cnt    |         server_msg len          |
+----------------+----------------+----------------+----------------+
+            data_len             |    arg_1_len   |    arg_2_len   |
+----------------+----------------+----------------+----------------+
|      ...       |   arg_N_len    |         server_msg ...
+----------------+----------------+----------------+----------------+
|   data ...
+----------------+----------------+----------------+----------------+
|   arg_1 ...
+----------------+----------------+----------------+----------------+
|   arg_2 ...
+----------------+----------------+----------------+----------------+
|   ...
+----------------+----------------+----------------+----------------+
|   arg_N ...
+----------------+----------------+----------------+----------------+
                    ]]></artwork>
				</figure>
        <t>

	status This
        </t>
        <ul empty="true" spacing="normal">

<li>
<t>This field indicates the authorization status.
</t>
</li>
          <li>
		<t>TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01</t>
                <t indent="4"> If the status equals
                TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the arguments specified
                in the request are authorized and the arguments in the
                response <bcp14>MUST</bcp14> be applied according to the rules
                described above.
		</t>
				<t>
					<list>
						<t>
		<t indent="4">To approve the authorization with no modifications, the
		server sets the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01
						</t>
						<t>
							TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 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>
						<t>
							TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10
						</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>
						<t>
						</li>
          <li>
		<t>TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11</t>
		<t indent="4">A status of TAC_PLUS_AUTHOR_STATUS_ERROR :=
							0x11
						</t>
						<t>
							TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21
		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>
					</list>
						</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
					<xref target="TextEncoding">text
	text encoding, see</xref>. see "Treatment of Text Strings" (<xref
	target="TextEncoding" format="default"/>).
        </t>
</li>
</ul>
        <t>
					data, data_len
        </t>
<ul empty="true">
<li>
   <t>

This is a string that may be presented on an administrative display,
					console console,
or log. The decision to present this message is client specific.  The data_len
indicates the length of the data field, in bytes. For details of
					<xref target="TextEncoding">text text
encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding" format="default"/>).
        </t>
</li>
</ul>
        <t>
					arg_cnt
        </t>
<ul empty="true">
<li>
   <t>
					The
	This represents the number of authorization arguments to follow.
        </t>
</li>
</ul>
        <t>
					arg_1 ... arg_N, arg_1_len .... arg_N_len
        </t>
<ul empty="true">
<li>
   <t>
	The arguments describe the specifics of the authorization that is
	being requested. For details of the content of the args, refer to:
					<xref target="AuthorizationAttributes">Authorization Arguments</xref>
					section below. to
	"Authorization Arguments" (<xref target="AuthorizationAttributes"
	format="default"></xref>).  Each argument is encoded in the packet as a
	single arg field (arg_1... arg_N) with a corresponding length fields field
	(which indicates the length of each argument in bytes).
        </t>
				<t>
					If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL,
					then the
					requested authorization MUST be denied.
				</t>
				<t>
					If the status equals TAC_PLUS_AUTHOR_STATUS_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_STATUS_PASS_REPL
					then the
					client MUST use the authorization argument-value pairs (if any) in
					the response,
					instead of the authorization argument-value 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 between 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_STATUS_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>
</ul>

      </section>
    </section>
    <section anchor="Accounting" title="Accounting"> numbered="true" toc="default">
      <name>Accounting</name>
      <t>
	Accounting is typically the third action after authentication and
	authorization. But again, neither authentication nor authorization is
	required. Accounting is the action of recording what a user is
				doing, doing
	and/or has done. Accounting in TACACS+ can serve two purposes: It it may
	be used as an auditing tool for security services.
				It services, and it may also be
	used to account for services used, used such as in a billing
	environment. To this end, TACACS+ supports three types of accounting records.
	records: Start records indicate that a service is about to begin. begin, Stop
	records indicate that a service has just terminated, and Update
	records are intermediate notices that indicate that a service is still
	being performed. TACACS+ accounting records contain all the
	information used in the authorization records, records and also contain accounting
				specific
	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</xref>. "Accounting Arguments" (<xref target="AccountingAttributes"
	format="default"/>).
      </t>
      <section anchor="TheAccountREQUESTPacketBody" title="The numbered="true" toc="default">
        <name>The Account REQUEST Packet Body">
				<figure>
					<artwork><![CDATA[ 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
+----------------+----------------+----------------+----------------+
|      flags     |  authen_method |    priv_lvl    |  authen_type   |
+----------------+----------------+----------------+----------------+
| authen_service |    user_len    |    port_len    |  rem_addr_len  |
+----------------+----------------+----------------+----------------+
|    arg_cnt     |   arg_1_len    |   arg_2_len    |      ...       |
+----------------+----------------+----------------+----------------+
|   arg_N_len    |    user ...
+----------------+----------------+----------------+----------------+
|   port ...
+----------------+----------------+----------------+----------------+
|   rem_addr ...
+----------------+----------------+----------------+----------------+
|   arg_1 ...
+----------------+----------------+----------------+----------------+
|   arg_2 ...
+----------------+----------------+----------------+----------------+
|   ...
+----------------+----------------+----------------+----------------+
|   arg_N ...
+----------------+----------------+----------------+----------------+

                    ]]></artwork>
				</figure>
        <t>
					flags
        </t>

        <ul empty="true" spacing="normal">
<li>
        <t>
					This holds bitmapped flags.
        </t>
				<t>
					<list>
						<t>
</li>
<li>
<t>Valid values are:
</t>
</li>
          <li>
							TAC_PLUS_ACCT_FLAG_START := 0x02
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_ACCT_FLAG_STOP := 0x04
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08
						</t>
					</list>

				</t>
						</li>
        </ul>

        <t>
	All other fields are defined in the authorization and
					authentication
					sections above "Authentication" (<xref
	target="Authentication"></xref>) and "Authorization" (<xref
	target="Authorization"></xref>) and have the same
	semantics. They provide details for the conditions on the client, and
	authentication context, so that these details may be logged for
	accounting purposes.
        </t>

        <t>
	See the
				    <xref target="AccountingAttributes">Accounting Arguments section</xref> "Accounting Arguments" (<xref target="AccountingAttributes" format="default"></xref>) for
	the dictionary of arguments relevant to accounting.
        </t>
      </section>
      <section anchor="TheAccountingREPLYPacketBody" title="The numbered="true" toc="default">
        <name>The Accounting REPLY Packet Body"> Body</name>
        <t>
	The purpose of accounting is to record the action that has occurred on
	the client.  The server
					MUST <bcp14>MUST</bcp14> reply with success only
	when the accounting request has been recorded.  If the server did not
	record the accounting
					request request, then it MUST <bcp14>MUST</bcp14> reply with
	ERROR.
        </t>
				<figure>
					<artwork><![CDATA[
        <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
+----------------+----------------+----------------+----------------+
|         server_msg len          |            data_len             |
+----------------+----------------+----------------+----------------+
|     status     |         server_msg ...
+----------------+----------------+----------------+----------------+
|     data ...
+----------------+
                    ]]></artwork>
				</figure>
        <t>
	status
        </t>
        <ul empty="true" spacing="normal">
<li>
<t>
					This is the return status.
</t>
</li>
<li>
<t>
Values are:
        </t>
				<t>
					<list>
						<t>
</li>
          <li>
							TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01
						</t>
						<t>
						</li>
          <li>
							TAC_PLUS_ACCT_STATUS_ERROR :=
							0x02
						</li>
          <li>
					<t>TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21</t>
					<t indent="4">When the status equals
					TAC_PLUS_ACCT_STATUS_FOLLOW, 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>
						<t>
							TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21
						</t>
					</list>
				</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
					<xref target="TextEncoding">text
	text encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding" format="default"/>).
        </t>
</li>
</ul>
     <t>
					data, data_len
        </t>
<ul empty="true">
<li>
 <t>
	This is a string that may be presented on an administrative display,
					console
	console, or log. The decision to present this message is client
	specific. The data_len indicates the length of the data field, in
	bytes. For details of
					<xref target="TextEncoding">text text encoding, see</xref>.
				</t>
				<t>
					When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW,
					then the
					actions to
					be taken and the contents see "Treatment of the
					data field are
					identical
					to the
					TAC_PLUS_AUTHEN_STATUS_FOLLOW status for
					Authentication. Text Strings" (<xref target="TextEncoding"
	format="default"/>).
        </t>
</li>
</ul>

        <t>
TACACS+ accounting is intended to record various types of events on clients,
for example: login sessions, command entry, and others as required by the
client implementation. These events are collectively referred to in "The
Draft" <xref target="TheDraft">`The Draft'</xref> target="THE-DRAFT" format="default"/> as "tasks".
        </t>
        <t>
	The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start
	accounting message. Start messages will only be sent once when a task
	is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is a stop
	record and that the task has terminated. The
	TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record.
        </t>
				<t>
					Summary

<table anchor="accounting-packets">
  <name>Summary of Accounting Packets
					<figure>
						<artwork><![CDATA[
+----------+-------+-------+-------------+-------------------------+
| Watchdog | Stop  | Start | Flags & 0xE | Meaning                 |
+----------+-------+-------+-------------+-------------------------+
|    0     |   0   |   0   |      0      | INVALID                 |
|    0     |   0   |   1   |      2      | Start Packets</name>
  <thead>
    <tr>
      <th>Watchdog</th>
      <th>Stop</th>
      <th>Start</th>
      <th>Flags &amp; 0xE</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>0</td>
      <td>0</td>
      <td>0</td>
      <td>INVALID</td>
    </tr>
    <tr>
      <td>0</td>
      <td>0</td>
      <td>1</td>
      <td>2</td>
      <td>Start Accounting Record |
|    0     |   1   |   0   |      4      | Stop Record</td>
    </tr>
    <tr>
      <td>0</td>
      <td>1</td>
      <td>0</td>
      <td>4</td>
      <td>Stop Accounting Record  |
|    0     |   1   |   1   |      6      | INVALID                 |
|    1     |   0   |   0   |      8      | Watchdog, Record</td>
    </tr>
    <tr>
      <td>0</td>
      <td>1</td>
      <td>1</td>
      <td>6</td>
      <td>INVALID</td>
    </tr>
    <tr>
      <td>1</td>
      <td>0</td>
      <td>0</td>
      <td>8</td>
      <td>Watchdog, no update     |
|    1     |   0   |   1   |      A      | Watchdog, with update   |
|    1     |   1   |   0   |      C      | INVALID                 |
|    1     |   1   |   1   |      E      | INVALID                 |
+----------+-------+-------+-------------+-------------------------+
                    ]]></artwork>
					</figure> update</td>
    </tr>

    <tr>
      <td>1</td>
      <td>0</td>
      <td>1</td>
      <td>A</td>
      <td>Watchdog, with update</td>
    </tr>
    <tr>
      <td>1</td>
      <td>1</td>
      <td>0</td>
      <td>C</td>
      <td>INVALID</td>
    </tr>

    <tr>
      <td>1</td>
      <td>1</td>
      <td>1</td>
      <td>E</td>
      <td>INVALID</td>
    </tr>

  </tbody>
</table>

        <t>
					The START and STOP flags are mutually
					exclusive.
        </t>
        <t>The WATCHDOG flag is used by the client to communicate ongoing
        status of a long-running task. Update records are sent at the client's
        discretion. The frequency of the update depends upon the intended
        application: A a watchdog to provide progress indication will require
        higher frequency than a daily keep-alive.  When the WATCHDOG flag is
        set along with the START flag, it indicates that the update record
        provides additional or updated arguments from the original START
        record. If the START flag is not set, then this indicates only that
        task is still running, and no new information is provided (servers MUST
        <bcp14>MUST</bcp14> ignore any arguments). The STOP flag MUST NOT <bcp14>MUST
        NOT</bcp14> be set in conjunction with the WATCHDOG flag.
        </t>
        <t>
					The Server MUST server <bcp14>MUST</bcp14> respond
					with TAC_PLUS_ACCT_STATUS_ERROR if the
					client requests an INVALID option.
        </t>
      </section>
    </section>
    <section anchor="AttributeValuePairs" title="Argument-Value Pairs"> numbered="true" toc="default">
      <name>Argument-Value Pairs</name>
      <t>
				TACACS+ is intended to be an extensible
				protocol. The arguments used in Authorization
				and Accounting are not limited by this
				document.  Some arguments are defined below
				for common use
				cases, clients MUST cases. Clients
				<bcp14>MUST</bcp14> use these arguments when
				supporting the corresponding use cases.
      </t>
      <section anchor="ValueEncoding" title="Value Encoding"> numbered="true" toc="default">
        <name>Value Encoding</name>
        <t>
	All argument values are encoded as strings. For details of
					<xref target="TextEncoding">text text
	encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding" format="default"/>).  The
	following type representations SHOULD <bcp14>SHOULD</bcp14> be followed followed.
        </t>
        <t>Numeric</t>

<ul empty="true">
<li>
 <t>
	All numeric values in an argument-value string are provided as decimal
	numbers, unless otherwise stated. All arguments include a length
	field, and TACACS+ implementations MUST <bcp14>MUST</bcp14> verify that
	they can accommodate the lengths of numeric arguments before
	attempting to process them.  If the length cannot be accommodated accommodated, then
	the argument MUST <bcp14>MUST</bcp14> be regarded as not handled and the
	logic in <xref target="TheAuthorizationREQUESTPacketBody">authorization section</xref> "Authorization" (<xref target="TheAuthorizationREQUESTPacketBody"
	format="default"></xref>) regarding the processing
	of arguments MUST <bcp14>MUST</bcp14> be applied.
        </t>
</li>
</ul>

        <t>Boolean</t>
<ul empty="true">
     <li>
   <t>
					All Boolean arguments are encoded with
					values "true" or "false".

        </t>
     </li>
</ul>
        <t>IP-Address</t>
<ul empty="true">
<li>
 <t>
It is recommended that hosts be specified as a an IP address so as to avoid any
ambiguities. For details of
					<xref target="TextEncoding">text text encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding"
format="default"/>). IPv4 address addresses are specified as octet numerics separated by
dots
					('.'), ('.'). IPv6 address text representation is defined in <xref target="RFC5952">RFC 5952</xref>. target="RFC5952"
format="default"/>.
        </t>
</li>
</ul>
        <t>Date Time</t>
<ul empty="true">
<li>
 <t>
	Absolute date/times are specified in seconds since the epoch,
					12:00am Jan
					1 12:00am,
	January 1, 1970. The timezone MUST time zone <bcp14>MUST</bcp14> be UTC
	unless a timezone time zone
	argument is specified.
        </t>
</li>
</ul>
        <t>String</t>
<ul empty="true">
<li>
   <t>Many values have no specific type representation and are
        interpreted as plain strings.</t>
</li>
</ul>
        <t>Empty Values</t>
<ul empty="true">
<li>
        <t>
Arguments may be submitted with no value, in which case they consist of the
name and the mandatory or optional separator. For example, the argument "cmd" "cmd",
which has no value value, is transmitted as a string of four characters "cmd=" "cmd=".
        </t>
</li>
</ul>
      </section>

    <section anchor="AuthorizationAttributes" title="Authorization Arguments"> numbered="true" toc="default">
        <name>Authorization Arguments</name>
        <t>
					service (String)
        </t>
<ul empty="true">
<li>
        <t>
The primary service. Specifying a service argument indicates that this is a
request for authorization or accounting of that service.  For example:
"shell", "tty-server", "connection", "system" and
					"firewall", "firewall"; others may be
chosen for the required application. This argument MUST <bcp14>MUST</bcp14> always
be included.
        </t>
</li>
</ul>
<t>
					protocol (String)
        </t>
				<t>
					the protocol
<ul empty="true">
<li>
<t>A field that may be used to indicate a subset of a service.
        </t>
</li>
</ul>
        <t>
					cmd (String)
        </t>
<ul empty="true">
<li>
   <t>
					a
A shell (exec) command. This indicates the command name of the command that is
to be run. The "cmd" argument MUST <bcp14>MUST</bcp14> be specified if service
equals "shell".
        </t>
</li>
<li>
        <t>Authorization of shell commands is a common use-case use case for the
        TACACS+ protocol. Command Authorization generally takes one of two
        forms: session-based and command-based. session based or command based.
        </t>
</li>
<li>
   <t>For session-based shell authorization, the "cmd" argument will have
        an empty value. The client determines which commands are allowed in a
        session according to the arguments present in the authorization.
        </t>
</li>
<li>
        <t>In command-based authorization, the client requests that the server
        determine whether a command is allowed by making an authorization
        request for each command. The "cmd" argument will have the command
        name as its value.</t>
</li>
</ul>
        <t>
					cmd-arg (String)
        </t>
<ul empty="true">
<li>
 <t>
					an
	An argument to a shell (exec) command. This indicates an argument for
	the shell command that is to be run.  Multiple cmd-arg arguments may
	be specified, and they are order dependent.
        </t>
</li>
</ul>
        <t>
					acl (Numeric)
        </t>
<ul empty="true">
<li>
   <t>
					a
A number representing a connection access list.  Applicable only to
session-based shell authorization. For details of
					<xref target="TextEncoding">text text encoding, see</xref>. see
"Treatment of Text Strings" (<xref target="TextEncoding"
format="default"/>).
        </t>
</li>
</ul>
        <t>
					inacl (String)
        </t>
<ul empty="true">
<li>
   <t>
The identifier (name) of an interface input access list. For details of
					<xref target="TextEncoding">text text
encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding" format="default"/>).
        </t>
</li>
</ul>
    <t>
					outacl (String)
        </t>
<ul empty="true">
<li>
        <t>
The identifier (name) of an interface output access list. For details of
					<xref target="TextEncoding">text text
encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding" format="default"/>).
        </t>
</li>
</ul>
        <t>
					addr (IP-Address)
        </t>
<ul empty="true">
<li>
   <t>
					a
		A network address address.
        </t>
</li>
</ul>
        <t>
					addr-pool (String)
        </t>
<ul empty="true">
<li>
   <t>
	The identifier of an address pool from which the client can assign an
	address.
        </t>
</li>
</ul>
     <t>
					timeout (Numeric)
        </t>
<ul empty="true">
<li>
 <t>
					an
	An absolute timer for the connection (in minutes). A value of zero
	indicates no timeout.
        </t>
</li>
</ul>
     <t>
					idletime (Numeric)
        </t>
<ul empty="true">
<li>
 <t>
					an
	An idle-timeout for the connection (in minutes). A value of zero
	indicates no timeout.
        </t>
</li>
</ul>
        <t>
					autocmd (String)
        </t>
<ul empty="true">
<li>
 <t>
					an
An auto-command to run. Applicable only to session-based shell authorization.
        </t>
</li>
</ul>
        <t>
					noescape (Boolean)
        </t>
<ul empty="true">
<li>
   <t>
	Prevents the user from using an escape character. Applicable only to
	session-based shell authorization.
        </t>
</li>
</ul>
    <t>
					nohangup (Boolean)
        </t>
<ul empty="true">
<li>
   <t>
	Boolean. Do not disconnect after an automatic command.  Applicable
	only to session-based shell authorization.
        </t>
</li>
</ul>
     <t>
					priv-lvl (Numeric)
        </t>
<ul empty="true">
<li>
   <t>
The privilege level to be assigned. Please refer to the
					<xref target="PrivilegeLevel">Privilege Level section</xref>
					below. "Privilege Levels" (<xref
target="PrivilegeLevel" format="default"></xref>).
        </t>
</li>
</ul>

      </section>
      <section anchor="AccountingAttributes" title="Accounting Arguments"> numbered="true" toc="default">
        <name>Accounting Arguments</name>
        <t>
	The following arguments are defined for TACACS+ accounting only.  They MUST
	<bcp14>MUST</bcp14> precede any argument-value pairs that are defined
	in
					the
					<xref target="Authorization">authorization section</xref>
					above. "Authorization" (<xref target="Authorization" format="default"></xref>).
        </t>
        <t>
					task_id (String)
        </t>
<ul empty="true">
<li>

 <t>
	Start and stop records for the same event MUST <bcp14>MUST</bcp14> have
	matching task_id argument values. The client MUST <bcp14>MUST</bcp14>
	ensure that active task_ids are not duplicated: duplicated; a client MUST NOT <bcp14>MUST
	NOT</bcp14> reuse a task_id in a start record until it has sent a stop
	record for that task_id.  Servers MUST NOT <bcp14>MUST NOT</bcp14> make
	assumptions about the format of a task_id.
        </t>
</li>
</ul>
     <t>
					start_time (Date Time)
        </t>
<ul empty="true">
<li>
   <t>
	The time the action started (in seconds since the
					epoch.). epoch).
        </t>
</li>
</ul>
        <t>
					stop_time (Date Time)
        </t>
<ul empty="true">
<li>
   <t>
	The time the action stopped (in seconds since the
					epoch.) epoch).
        </t>
</li>
</ul>
     <t>
					elapsed_time (Numeric)
        </t>
<ul empty="true">
<li>
   <t>
					The elapsed time in seconds for the action.
        </t>
</li>
</ul>
    <t>
					timezone (String)
        </t>
<ul empty="true">
<li>
   <t>
The timezone time zone abbreviation for all timestamps included in this packet. A
database of timezones time zones is maintained here: in <xref target="TZDB">TZDB</xref>. target="TZDB"
format="default">TZDB</xref>.
        </t>
</li>
</ul>
        <t>
					event (String)
        </t>
<ul empty="true">
<li>
   <t>
Used only when "service=system". Current values are "net_acct", "cmd_acct",
"conn_acct", "shell_acct"
					"sys_acct" "shell_acct", "sys_acct", and "clock_change".  These indicate
system-level changes.  The flags field SHOULD <bcp14>SHOULD</bcp14> indicate whether
the service started or stopped.
        </t>
</li>
</ul>
        <t>
					reason (String)
        </t>
<ul empty="true">
<li>
   <t>
Accompanies an event argument. It describes why the event occurred.
        </t>
</li>
</ul>
        <t>
					bytes (Numeric)
        </t>
<ul empty="true">
<li>
   <t>
	The number of bytes transferred by this action action.
        </t>
</li>
</ul>
     <t>
					bytes_in (Numeric)
        </t>
<ul empty="true">
<li>
   <t>
	The number of bytes transferred by this action from the endstation to
	the client port port.
        </t>
</li>
</ul>
     <t>
					bytes_out (Numeric)
        </t>
<ul empty="true">
<li>
   <t>
		The number of bytes transferred by this action from the client
		to the endstation
					port port.
        </t>
</li>
</ul>
        <t>
					paks (Numeric)
        </t>
<ul empty="true">
<li>
<t>
					The number of packets transferred by this action.
        </t>
</li>
</ul>
    <t>
					paks_in (Numeric)
        </t>

<ul empty="true">
<li>
   <t>
The number of input packets transferred by this action from the endstation to
the client port.
        </t>
</li>
</ul>
     <t>
					paks_out (Numeric)
        </t>
<ul empty="true">
<li>
 <t>
The number of output packets transferred by this action from the client port
to the endstation.
        </t>
</li>
</ul>
       <t>
					err_msg (String)
        </t>
<ul empty="true">
<li>
 <t>
	A string describing the status of the action. For details of
					<xref target="TextEncoding">text text
	encoding, see</xref>. see "Treatment of Text Strings" (<xref target="TextEncoding" format="default"/>).
        </t>
			</section>
		</section>
		<section anchor="PrivilegeLevel" title="Privilege Levels">
			<t>
				The TACACS+ Protocol supports flexible authorization
				schemes
				through
</li>
</ul>
<t>Where the extensible arguments.
			</t>
			<t>One
				scheme TACACS+ deployment is
				built into the
				protocol and has been extensively used
				for to support the Device Administration
use case, it is often required to log all commands entered into client
devices. To support this mode of operation, TACACS+ client devices <bcp14>MUST</bcp14> be
configured to send an accounting start packet for every command entered,
irrespective of how the commands were authorized. These “Command Accounting”
packets <bcp14>MUST</bcp14> include the “service” and “cmd” arguments, and if needed, the
“cmd-arg” arguments detailed in <xref target="AuthorizationAttributes"/>.
</t>
   </section>
    </section>
    <section anchor="PrivilegeLevel" numbered="true" toc="default">
      <name>Privilege Levels</name>
      <t>
				The TACACS+ protocol supports flexible
				authorization schemes through the extensible
				arguments.
      </t>

<t> The privilege levels scheme is built into the protocol and has been
extensively used as an option for Session-based shell authorization: Privilege Levels. authorization.

Privilege
				Levels levels are ordered values from 0 to 15 with each level being a
superset of the 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>
      <ul empty="true" spacing="normal">
        <li>
						TAC_PLUS_PRIV_LVL_MIN :=
						0x00. The level normally
						allocated to an
						unauthenticated session.
					</t>
					<t>
					</li>
        <li>
						TAC_PLUS_PRIV_LVL_USER :=
						0x01. The level normally
						allocated to a regular
						authenticated session
					</t>
					<t> 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.
					</t>
					<t>
					</li>
        <li>
						TAC_PLUS_PRIV_LVL_MAX :=
						0x0f. The highest privilege
						level.
					</t>
				</list>
			</t>
					</li>
      </ul>
      <t>

A Privilege privilege level can be assigned to a shell (EXEC) (exec) 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 server in a session-based
shell authorization (when "service" equals "shell" and "cmd" is empty).  When
a user is required to perform actions that are mapped to a higher privilege
level, then an ENABLE type ENABLE-type reauthentication can be initiated by the client.
The client will insert the required privilege level into the authentication
header for
				enable ENABLE authentication request. requests.
      </t>

      <t>
	The use of Privilege privilege levels to determine session-based access to
	commands and resources is not mandatory for clients. Although the
				privilege level
	privilege-level scheme is widely supported, its lack of flexibility in
	requiring a single monotonic hierarchy of permissions means that other
	session-based command authorization schemes have evolved.  However, it
	is still common enough that it SHOULD <bcp14>SHOULD</bcp14> be supported by
	servers.
      </t>
    </section>
    <section anchor="TACACSSecurity" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
				The original TACACS+ Draft
 "The Draft" <xref target="TheDraft">`The Draft'</xref> target="THE-DRAFT"
format="default"/> from 1998 did not address all of the key security concerns which
that are considered when designing modern standards. This section addresses
known limitations and concerns
				which that will impact overall security of the
protocol and systems where this protocol is deployed to manage central
authentication,
				authorization authorization, or accounting for network
				device administration. Device
Administration.

      </t>
      <t>

	Multiple implementations of the protocol described in the original
				TACACS+ Draft
 "The Draft" <xref target="TheDraft">`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.

      </t>
      <section anchor="SecurityofTheProtocol" title="General numbered="true" toc="default">
        <name>General Security of the Protocol"> Protocol</name>
        <t>
	The TACACS+ protocol does not include a security mechanism that would meet
	modern-day requirements. These security mechanisms would be best
	referred to as “obfuscation” "obfuscation" and not “encryption” "encryption", since they provide
	no meaningful integrity, privacy 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>
				<t>
					<list>
						<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.
						</t>
						<t>
						</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.
						</t>
					</list>
				</t>
						</li>
        </ul>
        <t>
While the protocol provides some measure of transport privacy, it is
vulnerable to at least the following attacks:
        </t>
				<t>
					<list>

						<t>
							Brute force
        <ul empty="false" spacing="normal">
          <li>
Brute-force attacks exploiting increased efficiency of MD5 digest computation.
						</t>
						<t>
						</li>
          <li>
	Known plaintext attacks which that may decrease the cost of brute
							force
							attack.
						</t>
						<t> brute-force
	attacks.
						</li>
          <li>
	Chosen plaintext attacks which that may decrease the cost of a brute
							force
							attack.
						</t>
						<t> brute-force
	attacks.
						</li>
          <li>
No forward secrecy.
						</t>
					</list>
				</t>
						</li>
        </ul>
        <t>
Even though, to the best knowledge of the authors, this method of encryption
					wasn’t
wasn't rigorously tested, enough information is available that it is best
referred to as
					“obfuscation” "obfuscation" and not
					“encryption”. "encryption".
        </t>
        <t>
	For these reasons, users deploying the TACACS+ protocol in their
	environments
					MUST <bcp14>MUST</bcp14> limit access to known clients and MUST
	<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 which that are in addition to general
					risk associated with bare obfuscation
					and lack of integrity checking.

        </t>
      </section>
      <section anchor="SecurityofAuthenticationSessions" title="Security numbered="true" toc="default">
        <name>Security of Authentication Sessions"> Sessions</name>
        <t>
	Authentication sessions SHOULD <bcp14>SHOULD</bcp14> be used via a secure
	transport (see
					<xref target="Bestpractices">Best Practices section</xref>) "TACACS+ Best Practices" (<xref target="Bestpractices"
	format="default"></xref>)) as the man-in-the-middle attack may
	completely subvert them. Even CHAP, which may be considered resistant to password
	interception, is unsafe as it does not protect the username from a
	trivial man-in-the-middle attack.
        </t>
        <t>
This document deprecates the redirection mechanism using the
TAC_PLUS_AUTHEN_STATUS_FOLLOW option option, which was included in the
					original draft. "The Draft". As
part of this process, the secret key for a new server was sent to the
client. This public exchange of secret keys means that once one session is
broken, it may be possible to leverage that key to attacking connections to
other servers.  servers.&nbsp; This mechanism MUST NOT <bcp14>MUST NOT</bcp14> be used in modern
deployments. It MUST NOT <bcp14>MUST NOT</bcp14> be used outside a secured deployment.
        </t>
      </section>
      <section anchor="SecurityofAuthorizationSessions" title="Security numbered="true" toc="default">
        <name>Security of Authorization Sessions"> Sessions</name>
        <t>
	Authorization sessions SHOULD <bcp14>SHOULD</bcp14> be used via a secure
	transport (see
					<xref target="Bestpractices">Best Practices section</xref>) "TACACS+ Best Practices" (<xref target="Bestpractices"
	format="default"></xref>)) as
					it’s it's trivial to execute a successful
	man-in-the-middle attacks attack that changes well-known plaintext in either
	requests or responses.
        </t>
        <t>
	As an example, take the field “authen_method”. It’s "authen_method". It's not unusual in
	actual deployments to authorize all commands received via the device
	local serial port (a console port) port), as that one is usually considered
	secure by virtue of the device located in a physically secure
	location. If an administrator would configure the authorization system
	to allow all commands entered by the user on a local console to aid in
	troubleshooting, that would give all access to all commands to any
	attacker that would be able to change the
					“authen_method” "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 wouldn't help
	much, because:
        </t>
				<t>
					<list>
						<t>
							Lack
        <ul empty="false" spacing="normal">
          <li>
	A lack of integrity means that any byte in the payload may be changed
	without either side detecting the change.
						</t>
						<t>
						</li>
          <li>
	Known plaintext means that an attacker would know with certainty which
	octet is the target of the attack (in this case,
							1st first octet after the
	header).
						</t>
						<t>
						</li>
          <li>
	In combination with known plaintext, the attacker can determine with
	certainty the value of the crypto-pad octet used to obfuscate the
	original octet.

						</t>
					</list>
				</t>

						</li>
        </ul>
      </section>
      <section anchor="SecurityofAccountingSessions" title="Security numbered="true" toc="default">
        <name>Security of Accounting Sessions"> Sessions</name>
        <t>Accounting sessions SHOULD <bcp14>SHOULD</bcp14> be used via a secure
        transport (see "TACACS+ Best Practices section (Section 10.5). Practices" (<xref
        target="Bestpractices"></xref>)). Although Accounting sessions are not
        directly involved in authentication or authorizing operations on the
        device, man-in-the-middle
					attacker attackers may do any of the following:
        </t>
				<t>
					<list>
						<t>
        <ul empty="false" spacing="normal">
          <li>

	Replace accounting data with new valid values or garbage which that can confuse
	auditors or hide information related to their authentication and/or
	authorization attack attempts.
						</t>
						<t>
						</li>
						<li>

	Try and poison an accounting log with entries designed to make systems
	behave in unintended ways (which includes (these systems could be TACACS+ server servers and any other
	systems that would manage accounting entries).
						</t>
					</list>
				</t>
						</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 keys, and similar 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>
      </section>
      <section anchor="Bestpractices" title="TACACS+ numbered="true" toc="default">
        <name>TACACS+ Best Practices"> Practices</name>
        <t>With respect to the observations about the security issues
        described above, a network a network administrator MUST NOT <bcp14>MUST NOT</bcp14>
        rely on the obfuscation of the TACACS+ protocol. TACACS+ MUST protocol. TACACS+
        <bcp14>MUST</bcp14> be used within a secure deployment: deployment; TACACS+ MUST
        <bcp14>MUST</bcp14> be deployed over networks which that ensure privacy and
        integrity of the
					communication, communication and MUST <bcp14>MUST</bcp14> be deployed
        over a network which that is separated from other traffic.  Failure to do
        so will impact overall network security.</t>
        <t>The following recommendations impose restrictions on how the
        protocol is applied. These restrictions were not imposed in the
					original draft. "The
        Draft". New implementations, and upgrades of current implementations, MUST
        <bcp14>MUST</bcp14> implement these recommendations. Vendors
					SHOULD
        <bcp14>SHOULD</bcp14> provide mechanisms to assist the administrator
        to achieve these best practices.</t>

        <section anchor="SharedSecrets" title="Shared Secrets"> numbered="true" toc="default">

          <name>Shared Secrets</name>
          <t>TACACS+ servers and clients MUST <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 MUST NOT <bcp14>MUST NOT</bcp14> leak sensitive
          data.
</t>
<t>
For example, example:
</t>

<ul>
<li>
<t> TACACS+ servers MUST NOT <bcp14>MUST NOT</bcp14> expose shared secrets in
logs.
          </t>

</li>
<li>
          <t>TACACS+ servers MUST <bcp14>MUST</bcp14> allow a dedicated secret key to be defined
						for each client.
          </t>
</li>
<li>
      <t>TACACS+ server management systems MUST <bcp14>MUST</bcp14> provide a
          mechanism to track secret key lifetimes and notify administrators to
          update them periodically. TACACS+ server administrators SHOULD
          <bcp14>SHOULD</bcp14> change secret keys at regular intervals. </t>
</li>
<li>

       <t>TACACS+ servers SHOULD <bcp14>SHOULD</bcp14> warn administrators if
          secret keys are not unique per client.</t>
</li>
<li>
       <t>TACACS+ server administrators SHOULD <bcp14>SHOULD</bcp14> always define
          a secret for each client.</t>
</li>
<li>
          <t>TACACS+ servers and clients MUST <bcp14>MUST</bcp14> support shared keys that are at
						least 32 characters long.
          </t>
</li>
<li>
          <t>TACACS+ servers MUST <bcp14>MUST</bcp14> support policy to define
          minimum complexity for shared keys.
          </t>
</li>
     <li>
     <t>TACACS+ clients SHOULD NOT <bcp14>SHOULD NOT</bcp14> allow servers to be
          configured without a shared secret key, key or shared key that is less
          than 16 characters long.</t>
     </li>
<li>

          <t>TACACS+ server administrators SHOULD <bcp14>SHOULD</bcp14> configure
          secret keys of a minimum of 16 characters in length.</t>
</li>
</ul>

        </section>
        <section anchor="Connections" title="Connections numbered="true" toc="default">
          <name>Connections and Obfuscation"> Obfuscation</name>
          <t>TACACS+ servers MUST <bcp14>MUST</bcp14> allow the definition of
          individual clients.  The servers MUST <bcp14>MUST</bcp14> only accept
          network connection attempts from these defined, defined known clients.</t>
          <t>TACACS+ servers MUST <bcp14>MUST</bcp14> reject connections with
	  that have
          TAC_PLUS_UNENCRYPTED_FLAG set. There MUST <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 MUST NOT <bcp14>MUST NOT</bcp14> accept any new
          sessions on that connection. TACACS+ servers MUST <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 MUST NOT <bcp14>MUST NOT</bcp14> set
          TAC_PLUS_UNENCRYPTED_FLAG. Clients MUST <bcp14>MUST</bcp14> be
          implemented in a way that requires explicit configuration to enable
          the use of
						TAC_PLUS_UNENCRYPTED_FLAG, this TAC_PLUS_UNENCRYPTED_FLAG. This option MUST NOT <bcp14>MUST
          NOT</bcp14> be used when the client is in production </t> production.</t>

          <t>When a TACACS+ client receives responses from servers where:</t>
					<t>
						<list>
							<t> the
          <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.

							</t>
							<t> the
	    set, and

							</li>
            <li>the response packet was received from the server configured
            not to use obfuscation, but the packet has
            TAC_PLUS_UNENCRYPTED_FLAG not set.

							</t>
						</list>
					</t>
					<t>then the set,

							</li>
          </ul>
          <t>the TACACS+ client MUST <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" title="Authentication"> numbered="true" toc="default">
          <name>Authentication</name>
          <t>To help TACACS+ administrators select less weak stronger authentication
          options, TACACS+ servers MUST <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 SHOULD <bcp14>SHOULD</bcp14> enable the
          option mentioned in the previous paragraph.

	  TACACS+ Server server deployments SHOULD ONLY <bcp14>SHOULD</bcp14> only enable other
	  options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or
	  TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of
	  identity/password systems.</t>
          <t>TACACS+ server administrators SHOULD NOT <bcp14>SHOULD NOT</bcp14> allow the
          same credentials to be applied in challenge-based
          (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or
          TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non challenge-based non-challenge-based authen_type
						options
          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 SHOULD NOT "The Draft" <bcp14>SHOULD
          NOT</bcp14> be used, used due to their security implications. TACACS+
          servers SHOULD NOT <bcp14>SHOULD NOT</bcp14> implement them.  If they must be
          implemented, the servers MUST <bcp14>MUST</bcp14> default to the options
          being disabled and MUST <bcp14>MUST</bcp14> warn the administrator that
          these options are not secure.</t>
        </section>
        <section anchor="AuthorizationRecommendations" title="Authorization"> numbered="true" toc="default">
          <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 MUST <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
						MUST
          <bcp14>MUST</bcp14> evaluate server response as if they received
          TAC_PLUS_AUTHOR_STATUS_FAIL.</t>
        </section>
        <section anchor="RedirectionMechanism" title="Redirection Mechanism">

					<t>The original draft 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 MUST <bcp14>MUST</bcp14> deprecate the redirection mechanism.</t>
          <t>If the redirection mechanism is implemented implemented, then TACACS+ servers
						MUST
          <bcp14>MUST</bcp14> disable it by default, default and MUST <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 SHOULD <bcp14>SHOULD</bcp14> deprecate this feature by treating
						TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
          </t>
        </section>
      </section>
    </section>
    <section anchor="IANAConsiderations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This informational document describes TACACS+ protocol and its
				common
				deployments. There is has no further consideration required from
				IANA. IANA actions.
      </t>

    </section>

  </middle>
  <back>

<displayreference target="KERB" to="1"/>

 <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1334.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2433.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2759.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3579.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4120.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8265.xml"/>
      </references>
      <references>
        <name>Informative References</name>

<reference anchor='THE-DRAFT' target="https://tools.ietf.org/html/draft-grant-tacacs-02">
<front>
<title>The TACACS+ Protocol Version 1.78</title>
 <author initials="D." surname="Carrel" fullname="D. Carrel"/>
            <author initials="L." surname="Grant" fullname="Lol Grant"/>
            <date month="January" year="1997"/>
</front>
<seriesInfo name='Internet-Draft' value='draft-grant-tacacs-02' />
</reference>

        <reference anchor="TZDB" target="https://www.iana.org/time-zones">
          <front>
            <title>Sources for Time Zone and Daylight Saving Time Data</title>
            <author initials="P." surname="Eggert" fullname="Paul Eggert"/>
            <author initials="A." surname="Olson" fullname="Arthur Olson"/>
            <date year="1987"/>
          </front>
        </reference>

<reference anchor="KERB">
<front>
<title>Section E.2.1: Kerberos Authentication and Authorization System</title>
<author initials="S." surname="Miller" fullname="Steven Miller"/>
<author initials="C." surname="Neuman" fullname="Clifford Neuman"/>
<author initials="J." surname="Schiller" fullname="Jeffrey Schiller"/>
<author initials="J." surname="Saltzer" fullname="Jerry Saltzer"/>

<date month="December" year="1987"/>
</front>
<refcontent>MIT Project Athena</refcontent>
<refcontent>Cambridge, Massachusetts</refcontent>

</reference>

      </references>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank the following reviewers whose
      comments and contributions made considerable improvements to the this
      document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch,
				Robert Drake, John Heasley, <contact fullname="Alan DeKok"/>, <contact fullname="Alexander
      Clouter"/>, <contact fullname="Chris Janicki"/>, <contact fullname="Tom Petch"/>,
      <contact fullname="Robert Drake"/>, and <contact fullname="John Heasley"/>, among many others.
      </t>
      <t>
				The authors would particularly like to thank Alan DeKok,
				<contact fullname="Alan DeKok"/>, who provided
				significant insights and recommendations on
				all aspects of the document and the
				protocol. Alan DeKok <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 Joe Clarke.</t> <contact fullname="Joe Clarke"/>.</t>
    </section>
	</middle>

	<back>
		<references title="Normative References">
			<reference anchor="RFC0020" target="https://www.rfc-editor.org/info/rfc20">
				<front>
					<title>ASCII format for network interchange</title>
					<author initials="V.G." surname="Cerf" fullname="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 Algorithm'>The MD5 Message-Digest Algorithm</title>
					<author initials='R.' surname='Rivest' fullname='Ronald L. Rivest'>
						<organization>Massachusetts Institute of
							Technology, (MIT)
							Laboratory for Computer
							Science</organization>
						<address>
							<postal>
								<street>545 Technology Square</street>
								<street>NE43-324</street>
								<city>Cambridge</city>
								<region>MA</region>
								<code>02139-1986</code>
								<country>US</country>
							</postal>
							<phone>+1 617 253 5880</phone>
							<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/rfc1321.txt' />
			</reference>

			<reference anchor="RFC1334" target="http://www.rfc-editor.org/info/rfc1334">
				<front>
					<title>PPP Authentication Protocols</title>
					<author initials="B." surname="Lloyd" fullname="B. Lloyd">
						<organization />
					</author>
					<author initials="W." surname="Simpson" fullname="W. Simpson">
						<organization />
					</author>
					<date year="1992" month="October" />
					<abstract>
						<t>This document defines two protocols for
							Authentication: the
							Password Authentication
							Protocol and the Challenge-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-editor.org/info/rfc2119'>
				<front>
					<title>Key words for use in RFCs to Indicate Requirement Levels</title>
					<author initials='S.' surname='Bradner' fullname='S. Bradner'>
						<organization />
					</author>
					<date year='1997' month='March' />
					<abstract>
						<t>In many standards track documents several words are used to
							signify the requirements in the specification. These words are
							often capitalized. This document 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 and 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.org/info/rfc2433">
				<front>
					<title>Microsoft PPP CHAP Extensions</title>
					<author initials="G." surname="Zorn" fullname="G. Zorn">
						<organization />
					</author>
					<author initials="S." surname="Cobb" fullname="S. Cobb">
						<organization />
					</author>
					<date year="1998" month="October" />
					<abstract>
						<t>The Point-to-Point Protocol (PPP) 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 establishing and
							configuring
							different network-layer
							protocols. This memo provides
							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.org/info/rfc2759">
				<front>
					<title>Microsoft PPP CHAP Extensions, Version 2</title>
					<author initials="G." surname="Zorn" fullname="G. Zorn">
						<organization />
					</author>
					<date year="2000" month="January" />
					<abstract>
						<t>This document describes version 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 Internet
							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-editor.org/info/rfc3579">
				<front>
					<title>
						RADIUS (Remote Authentication Dial In User Service) Support For Extensible
						Authentication Protocol (EAP)
					</title>
					<author initials="B." surname="Aboba" fullname="B. Aboba">
						<organization />
					</author>
					<author initials="P." surname="Calhoun" fullname="P. Calhoun">
						<organization />
					</author>
					<date year="2003" month="September" />
					<abstract>
						<t>
							This document defines Remote Authentication Dial In User Service
							(RADIUS) support for the Extensible Authentication Protocol (EAP),
							an authentication framework which supports multiple authentication
							mechanisms. In the proposed scheme, the Network Access Server (NAS)
							forwards EAP packets to and from the RADIUS server, encapsulated
							within EAP-Message attributes. This has the advantage of allowing
							the NAS to support any EAP authentication method, without the need
							for method- specific code, which resides on the RADIUS server. While
							EAP was originally developed 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.org/info/rfc4086">
				<front>
					<title>Randomness Requirements for Security</title>
					<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
						<organization />
					</author>
					<author initials="S." surname="Crocker" fullname="S. Crocker">
						<organization />
					</author>
					<author initials="J." surname="Schiller" fullname="J. Schiller">
						<organization />
					</author>
					<date year="2005" month="June" />
					<abstract>
						<t>Security systems are built on strong cryptographic algorithms
							that foil pattern analysis attempts. However, the security of
							these systems is dependent on generating secret quantities
							for
							passwords, cryptographic keys, and similar quantities.
							The use of
							pseudo-random processes to generate secret
							quantities can result
							in pseudo-security. A sophisticated
							attacker may find it easier to
							reproduce the environment that
							produced the secret quantities and
							to search the resulting
							small set of possibilities than to locate
							the quantities in
							the whole of the potential number space.
							Choosing random
							quantities to foil a resourceful and motivated
							adversary is
							surprisingly difficult. This document points out many
							pitfalls in using poor entropy sources or traditional
							pseudo-random number generation 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 purpose. It provides
							suggestions to
							ameliorate the problem when a hardware
							solution is not available,
							and it gives examples of how
							large such quantities need to be for
							some applications. This
							document specifies an Internet Best
							Current Practices for
							the Internet Community, and requests
							discussion and
							suggestions for improvements.</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-editor.org/info/rfc4120">
				<front>
					<title>The Kerberos Network Authentication Service (V5)</title>
					<author initials="C." surname="Neuman" fullname="C. Neuman">
						<organization />
					</author>
					<author initials="T." surname="Yu" fullname="T. Yu">
						<organization />
					</author>
					<author initials="S." surname="Hartman" fullname="S. Hartman">
						<organization />
					</author>
					<author initials="K." surname="Raeburn" fullname="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 intended use that require more detailed or
							clearer explanation than was provided in RFC 1510. This document is
							intended to provide a detailed description of the protocol, suitable
							for implementation, together 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-editor.org/info/rfc5952">
				<front>
					<title>A Recommendation for IPv6 Address Text Representation</title>
					<author initials="S." surname="Kawamura" fullname="S. Kawamura">
						<organization />
					</author>
					<author initials="M." surname="Kawashima" 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 addresses in text. While the IPv6 address
							architecture in Section 2.2 of RFC 4291 describes a flexible
							model for text representation of an IPv6 address, this
							flexibility has been causing problems for operators, system
							engineers, and users. This document defines a canonical textual
							representation format. It does not define a format for internal
							storage, such as within an application or database. It is
							expected that the canonical format will be followed by humans and
							systems when representing IPv6 addresses as text, but all
							implementations must accept and be able to handle any legitimate
							RFC 4291 format. [STANDARDS-TRACK]</t>
					</abstract>
				</front>
				<seriesInfo name="RFC" value="5952" />
				<seriesInfo name="DOI" value="10.17487/RFC5952" />
			</reference>

			<reference anchor="RFC8265" target="https://www.rfc-editor.org/info/rfc8265">
				<front>
					<title>Preparation, Enforcement, and Comparison of
						Internationalized Strings Representing Usernames and Passwords</title>
					<author initials="P." surname="Saint-Andre" 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 updated methods for handling Unicode
							strings representing usernames and passwords. The previous
							approach was known as SASLprep (RFC 4013) and was based on
							Stringprep (RFC 3454). The methods specified in this document
							provide a more sustainable approach to the handling of
							internationalized usernames and passwords. This document
							obsoletes RFC 7613.</t>
					</abstract>
				</front>
				<seriesInfo name="RFC" value="8265" />
				<seriesInfo name="DOI" value="10.17487/RFC8265" />
			</reference>

		</references>
		<references title="Informative References">
			<reference anchor="TheDraft"
				target="https://tools.ietf.org/html/draft-grant-tacacs-02">
				<front>
					<title>The TACACS+ Protocol Version 1.78</title>
					<author initials="D." surname="Carrel" fullname="D. Carrel" />

					<author initials="L." surname="Grant" fullname="Lol Grant" />

					<date month="June" year="1997" />
				</front>
			</reference>

			<reference anchor="TZDB" target="https://www.iana.org/time-zones">
				<front>
					<title>Sources for Time Zone and
						Daylight Saving Time Data</title>
					<author initials="P." surname="Eggert" fullname="D. Carrel" />
					<author initials="A." surname="Olson" fullname="Lol Grant" />
					<date year="1987" />
				</front>
			</reference>

		</references>

  </back>
</rfc>