File: rfc8907.xml

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (3609 lines) | stat: -rw-r--r-- 191,442 bytes
parent folder | download | duplicates (2)
<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-opsawg-tacacs-18" indexInclude="true" ipr="pre5378Trust200902" number="8907" prepTime="2020-09-30T16:48:02" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-18" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8907" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="TACACS+">The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol</title>
    <seriesInfo name="RFC" value="8907" stream="IETF"/>
    <author initials="T." surname="Dahm" fullname="Thorsten Dahm">
      <organization showOnFrontPage="true">Google Inc.</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>thorstendlux@google.com</email>
        <uri/>
      </address>
    </author>
    <author initials="A." surname="Ota" fullname="Andrej Ota">
      <organization showOnFrontPage="true">Google Inc.</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>andrej@ota.si</email>
        <uri/>
      </address>
    </author>
    <author initials="D.C." surname="Medway Gash" fullname="Douglas C. Medway Gash">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>170 West Tasman Dr.</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>United States of America</country>
        </postal>
        <email>dcmgash@cisco.com</email>
        <uri/>
      </address>
    </author>
    <author initials="D." surname="Carrel" fullname="David Carrel">
      <organization showOnFrontPage="true">IPsec Research</organization>
      <address>
        <email>carrel@ipsec.org</email>
        <uri/>
      </address>
    </author>
    <author initials="L." surname="Grant" fullname="Lol Grant">
      <address>
        <email>lol.grant@gmail.com</email>
      </address>
    </author>
    <date month="09" year="2020"/>
    <area>Operations</area>
    <workgroup>Operations</workgroup>
    <keyword>TACACS+</keyword>
    <keyword>Protocol</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document describes the Terminal Access Controller Access-Control
      System Plus (TACACS+) protocol, which is widely deployed today to provide
      Device Administration for routers, network access servers, and other
      networked computing devices via one or more centralized servers.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8907" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
        <t indent="0" pn="section-boilerplate.2-3">
            This document may contain material from IETF Documents or IETF
            Contributions published or made publicly available before November
            10, 2008. The person(s) controlling the copyright in some of this
            material may not have granted the IETF Trust the right to allow
            modifications of such material outside the IETF Standards Process.
            Without obtaining an adequate license from the person(s)
            controlling the copyright in such materials, this document may not
            be modified outside the IETF Standards Process, and derivative
            works of it may not be created outside the IETF Standards Process,
            except to format it for publication as an RFC or to translate it
            into languages other than English.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions">Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-technical-definitions">Technical Definitions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client">Client</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-server">Server</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet">Packet</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-connection">Connection</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-session">Session</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-treatment-of-enumerated-pro">Treatment of Enumerated Protocol Values</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.7">
                <t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-treatment-of-text-strings">Treatment of Text Strings</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tacacs-packets-and-sessions">TACACS+ Packets and Sessions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-tacacs-packet-header">The TACACS+ Packet Header</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-tacacs-packet-body">The TACACS+ Packet Body</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-single-connection-mode">Single Connection Mode</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-session-completion">Session Completion</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-obfuscation">Data Obfuscation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication">Authentication</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-authentication-start-pa">The Authentication START Packet Body</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-authentication-reply-pa">The Authentication REPLY Packet Body</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-authentication-continue">The Authentication CONTINUE Packet Body</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-description-of-authenticati">Description of Authentication Process</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.4.2">
                  <li pn="section-toc.1-1.5.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.4.2.1.1"><xref derivedContent="5.4.1" format="counter" sectionFormat="of" target="section-5.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-version-behavior">Version Behavior</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.4.2.2.1"><xref derivedContent="5.4.2" format="counter" sectionFormat="of" target="section-5.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-common-authentication-flows">Common Authentication Flows</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.4.2.3.1"><xref derivedContent="5.4.3" format="counter" sectionFormat="of" target="section-5.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aborting-an-authentication-">Aborting an Authentication Session</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization">Authorization</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-authorization-request-p">The Authorization REQUEST Packet Body</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-authorization-reply-pac">The Authorization REPLY Packet Body</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-accounting">Accounting</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-account-request-packet-">The Account REQUEST Packet Body</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-accounting-reply-packet">The Accounting REPLY Packet Body</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-argument-value-pairs">Argument-Value Pairs</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-encoding">Value Encoding</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-arguments">Authorization Arguments</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-accounting-arguments">Accounting Arguments</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privilege-levels">Privilege Levels</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-security-of-the-pro">General Security of the Protocol</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-of-authentication-">Security of Authentication Sessions</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-of-authorization-s">Security of Authorization Sessions</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-of-accounting-sess">Security of Accounting Sessions</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.5">
                <t indent="0" pn="section-toc.1-1.10.2.5.1"><xref derivedContent="10.5" format="counter" sectionFormat="of" target="section-10.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tacacs-best-practices">TACACS+ Best Practices</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2.5.2">
                  <li pn="section-toc.1-1.10.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.10.2.5.2.1.1"><xref derivedContent="10.5.1" format="counter" sectionFormat="of" target="section-10.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-shared-secrets">Shared Secrets</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.10.2.5.2.2.1"><xref derivedContent="10.5.2" format="counter" sectionFormat="of" target="section-10.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-connections-and-obfuscation">Connections and Obfuscation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.5.2.3">
                    <t indent="0" pn="section-toc.1-1.10.2.5.2.3.1"><xref derivedContent="10.5.3" format="counter" sectionFormat="of" target="section-10.5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication-2">Authentication</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.5.2.4">
                    <t indent="0" pn="section-toc.1-1.10.2.5.2.4.1"><xref derivedContent="10.5.4" format="counter" sectionFormat="of" target="section-10.5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-2">Authorization</xref></t>
                  </li>
                  <li pn="section-toc.1-1.10.2.5.2.5">
                    <t indent="0" pn="section-toc.1-1.10.2.5.2.5.1"><xref derivedContent="10.5.5" format="counter" sectionFormat="of" target="section-10.5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-redirection-mechanism">Redirection Mechanism</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="Introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document describes the Terminal Access Controller Access-Control
      System Plus (TACACS+) protocol. It was conceived initially as a general
      Authentication, Authorization, and Accounting (AAA) protocol. It is
      widely deployed today but is mainly confined for a specific subset of
      AAA called Device Administration, which includes authenticating access to network
      devices, providing central authorization of operations, and auditing of
      those operations.</t>
      <t indent="0" pn="section-1-2">
	A wide range of TACACS+ clients and servers is already deployed in the
	field. The TACACS+ protocol they are based on is defined in a document
	that was originally intended for IETF publication, but was never
	standardized.  The document is known as "The Draft" <xref target="THE-DRAFT" format="default" sectionFormat="of" derivedContent="THE-DRAFT"/>.
      </t>
      <t indent="0" pn="section-1-3"> This Draft was a product of its time and did not address all of the
      key security concerns that are considered when designing modern
      standards. Therefore, deployment must be executed with care. These
      concerns are addressed in <xref target="TACACSSecurity" format="default" sectionFormat="of" derivedContent="Section 10"/>.
      </t>
      <t indent="0" pn="section-1-4">
	The primary intent of this informational document is to clarify the
	subset of "The Draft", which is common to implementations supporting
	Device Administration.  It is intended that all implementations that
	conform to this document will conform to "The Draft". However, it is
	not intended that all implementations that conform to "The Draft" will
	conform to this document. The following features from "The Draft" have
	been removed:
      </t>
      <ul empty="false" spacing="normal" bare="false" indent="3" pn="section-1-5">
        <li pn="section-1-5.1">This document officially removes SENDPASS for security
        reasons.</li>
        <li pn="section-1-5.2">The normative description of legacy features such as the Apple
        Remote Access Protocol (ARAP) and outbound authentication has been
        removed.</li>
        <li pn="section-1-5.3">The Support for forwarding to an alternative daemon
        (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated.</li>
      </ul>
      <t indent="0" pn="section-1-6">The TACACS+ protocol allows for arbitrary length and content
      authentication exchanges to support alternative authentication
      mechanisms. It is extensible to provide for site customization and
      future development features, and it uses TCP to ensure reliable
      delivery. The protocol allows the TACACS+ client to request fine-grained
      access control and allows the server to respond to each component of
      that request.</t>
      <t indent="0" pn="section-1-7">
	The separation of authentication, authorization, and accounting is a
	key element of the design of TACACS+ protocol. 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
	to associate authentication requests with authorization requests.
      </t>
    </section>
    <section anchor="Conventions" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions">Conventions</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t>
    </section>
    <section anchor="TechnicalDefinitions" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-technical-definitions">Technical Definitions</name>
      <t indent="0" pn="section-3-1">This section provides a few basic definitions that are applicable to
      this document.</t>
      <section anchor="Client" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-client">Client</name>
        <t indent="0" pn="section-3.1-1">The client is any device that initiates TACACS+ protocol requests
        to mediate access, mainly for the Device Administration use case.</t>
      </section>
      <section anchor="Server" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-server">Server</name>
        <t indent="0" pn="section-3.2-1">The server receives TACACS+ protocol requests and replies
        according to its business model in accordance with the flows defined
        in this document.</t>
      </section>
      <section anchor="Packet" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-packet">Packet</name>
        <t indent="0" pn="section-3.3-1">All uses of the word packet in this document refer to TACACS+
        protocol data units unless explicitly noted otherwise. The informal
        term "packet" has become an established part of the definition.</t>
      </section>
      <section anchor="Connection" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-connection">Connection</name>
        <t indent="0" pn="section-3.4-1">
	TACACS+ uses TCP for its transport.  TCP Server port 49 is allocated
	by IANA for TACACS+ traffic.
        </t>
      </section>
      <section anchor="Session" numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-session">Session</name>
        <t indent="0" pn="section-3.5-1">
					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 indent="0" pn="section-3.5-2">
					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" numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-treatment-of-enumerated-pro">Treatment of Enumerated Protocol Values</name>
        <t indent="0" pn="section-3.6-1">
					This document describes various
					enumerated values in the packet header
					and the headers for specific packet
					types. For example, in the
					authentication start packet type, this
					document defines the action field with
					three values: TAC_PLUS_AUTHEN_LOGIN,
					TAC_PLUS_AUTHEN_CHPASS, and
					TAC_PLUS_AUTHEN_SENDAUTH.
        </t>
        <t indent="0" pn="section-3.6-2">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 indent="0" pn="section-3.6-3">
					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 <bcp14>MUST</bcp14> be
					returned to indicate an error.
        </t>
      </section>
      <section anchor="TextEncoding" numbered="true" toc="include" removeInRFC="false" pn="section-3.7">
        <name slugifiedName="name-treatment-of-text-strings">Treatment of Text Strings</name>
        <t indent="0" pn="section-3.7-1">The TACACS+ protocol makes extensive use of text strings. "The
        Draft" intended that these strings would be treated as byte arrays
        where each byte would represent a US-ASCII character.
        </t>
        <t indent="0" pn="section-3.7-2">More recently, server implementations have been extended to
        interwork with external identity services, and so a more nuanced
        approach is needed.  Usernames <bcp14>MUST</bcp14> be encoded and
        handled using the UsernameCasePreserved Profile specified in <xref target="RFC8265" format="default" sectionFormat="of" derivedContent="RFC8265"/>. The security
        considerations in <xref target="RFC8265" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8265#section-8" derivedContent="RFC8265"/> apply.
        </t>
        <t indent="0" pn="section-3.7-3">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 indent="0" pn="section-3.7-4">
					All other text fields in TACACS+
					<bcp14>MUST</bcp14> be treated as
					printable byte arrays of US-ASCII as
					defined by <xref target="RFC0020" format="default" sectionFormat="of" derivedContent="RFC0020"/>.  The term
					"printable" used here means the fields
					<bcp14>MUST</bcp14> exclude the
					"Control Characters" defined in <xref target="RFC0020" sectionFormat="of" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc20#section-5.2" derivedContent="RFC0020"/>.
        </t>
      </section>
    </section>
    <section anchor="TACACSPacketsSessions" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-tacacs-packets-and-sessions">TACACS+ Packets and Sessions</name>
      <section anchor="TheTACACSPacketHeader" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-the-tacacs-packet-header">The TACACS+ Packet Header</name>
        <t indent="0" pn="section-4.1-1">
					All TACACS+ packets begin with the
					following 12-byte header. The header
					describes the remainder of the packet:
        </t>
        <artwork name="" type="" align="left" alt="" pn="section-4.1-2">
 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>
        <t indent="0" pn="section-4.1-3">The following general rules apply to all TACACS+ packet types:
        </t>
        <ul empty="false" spacing="normal" bare="false" indent="3" pn="section-4.1-4">
          <li pn="section-4.1-4.1">
	To signal that any variable-length data fields are unused, the
	corresponding length values are set to zero. Such fields
	<bcp14>MUST</bcp14> be ignored, and treated as if not present.
						</li>
          <li pn="section-4.1-4.2">
	The lengths of data and message fields in a packet are specified by
	their corresponding length field (and are not null terminated).
						</li>
          <li pn="section-4.1-4.3">
	All length values are unsigned and in network byte order.
						</li>
        </ul>
        <t indent="0" pn="section-4.1-5">
					major_version
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.1-6">
          <li pn="section-4.1-6.1">
            <t indent="0" pn="section-4.1-6.1.1">
					This is the major TACACS+ version number.
            </t>
          </li>
        </ul>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-4.1-7">
          <li pn="section-4.1-7.1">
							TAC_PLUS_MAJOR_VER := 0xc
						</li>
        </ul>
        <t indent="0" pn="section-4.1-8">
					minor_version
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.1-9">
          <li pn="section-4.1-9.1">
            <t indent="0" pn="section-4.1-9.1.1">
					This is the minor TACACS+ version number.
            </t>
          </li>
          <li pn="section-4.1-9.2">
							TAC_PLUS_MINOR_VER_DEFAULT := 0x0
						</li>
          <li pn="section-4.1-9.3">
							TAC_PLUS_MINOR_VER_ONE := 0x1
						</li>
        </ul>
        <t indent="0" pn="section-4.1-10">
					type
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.1-11">
          <li pn="section-4.1-11.1">
            <t indent="0" pn="section-4.1-11.1.1">
   This is the packet type.
            </t>
          </li>
          <li pn="section-4.1-11.2">Options are:
</li>
          <li pn="section-4.1-11.3">
							TAC_PLUS_AUTHEN := 0x01 (Authentication)
						</li>
          <li pn="section-4.1-11.4">
							TAC_PLUS_AUTHOR := 0x02 (Authorization)
						</li>
          <li pn="section-4.1-11.5">
							TAC_PLUS_ACCT := 0x03 (Accounting)
						</li>
        </ul>
        <t indent="0" pn="section-4.1-12">

					seq_no
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.1-13">
          <li pn="section-4.1-13.1">
            <t indent="0" pn="section-4.1-13.1.1">
	This is the sequence number of the current packet. The first packet in
	a session <bcp14>MUST</bcp14> have the sequence number 1, and each
	subsequent packet will increment the sequence number by one.  TACACS+
	clients only send packets containing odd sequence numbers, and TACACS+
	servers only send packets containing even sequence numbers.
            </t>
          </li>
          <li pn="section-4.1-13.2">
            <t indent="0" pn="section-4.1-13.2.1">
	The sequence number must never wrap, i.e., if the sequence number 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 indent="0" pn="section-4.1-14">
	flags
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.1-15">
          <li pn="section-4.1-15.1">
            <t indent="0" pn="section-4.1-15.1.1">
        This field contains various bitmapped flags.
            </t>
          </li>
          <li pn="section-4.1-15.2">
            <t indent="0" pn="section-4.1-15.2.1">
	The flag bit:
            </t>
          </li>
          <li pn="section-4.1-15.3">
            <t indent="0" pn="section-4.1-15.3.1">
TAC_PLUS_UNENCRYPTED_FLAG := 0x01
</t>
          </li>
          <li pn="section-4.1-15.4">
            <t indent="0" pn="section-4.1-15.4.1">
					This flag indicates that the sender
					did not obfuscate the body of the
					packet. This option <bcp14>MUST NOT</bcp14> be used in production. The
					application of this flag will be
					covered in "Security Considerations"
					(<xref target="TACACSSecurity" format="default" sectionFormat="of" derivedContent="Section 10"/>).
            </t>
          </li>
          <li pn="section-4.1-15.5">
            <t indent="0" pn="section-4.1-15.5.1">
		This flag <bcp14>SHOULD</bcp14> be clear in all
		deployments. Modern network traffic tools support encrypted
		traffic when configured with the shared secret (see "Shared Secrets" (<xref target="SharedSecrets" format="default" sectionFormat="of" derivedContent="Section 10.5.1"/>)), so obfuscated mode can and
		<bcp14>SHOULD</bcp14> be used even during test.
            </t>
          </li>
          <li pn="section-4.1-15.6">
            <t indent="0" pn="section-4.1-15.6.1">
		The single-connection flag:
            </t>
          </li>
          <li pn="section-4.1-15.7">
            <t indent="0" pn="section-4.1-15.7.1">
		TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04

            </t>
          </li>
          <li pn="section-4.1-15.8">
            <t indent="0" pn="section-4.1-15.8.1">
		This flag is used to allow a client and server to negotiate
		"Single Connection Mode" (<xref target="SingleConnectMode" format="default" sectionFormat="of" derivedContent="Section 4.3"/>).
            </t>
          </li>
          <li pn="section-4.1-15.9">
            <t indent="0" pn="section-4.1-15.9.1">
		All other bits <bcp14>MUST</bcp14> be ignored when reading,
		and <bcp14>SHOULD</bcp14> be set to zero when writing.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-16">
		session_id
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.1-17">
          <li pn="section-4.1-17.1">
            <t indent="0" pn="section-4.1-17.1.1">
		The Id for this TACACS+ session. This field does not change
		for the duration of the TACACS+ session. This number
		<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, refer to
		<xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/>.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-18">
					length
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.1-19">
          <li pn="section-4.1-19.1">
            <t indent="0" pn="section-4.1-19.1.1">
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" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-the-tacacs-packet-body">The TACACS+ Packet Body</name>
        <t indent="0" pn="section-4.2-1">
					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" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-single-connection-mode">Single Connection Mode</name>
        <t indent="0" pn="section-4.3-1">
					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 sessions on a
					single TCP connection.
        </t>
        <t indent="0" pn="section-4.3-2">
					The packet header contains the
					TAC_PLUS_SINGLE_CONNECT_FLAG used by
					the client and server to negotiate the
					use of Single Connection Mode.
        </t>
        <t indent="0" pn="section-4.3-3">
					The client sets this flag to indicate
					that it supports multiplexing TACACS+
					sessions over a single TCP
					connection. The client <bcp14>MUST NOT</bcp14> send a second packet on a
					connection until single-connect status
					has been established.
        </t>
        <t indent="0" pn="section-4.3-4">
					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 indent="0" pn="section-4.3-5">
					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; the client and server
					<bcp14>MUST</bcp14> ignore the flag
					after the second packet on a
					connection.
        </t>
        <t indent="0" pn="section-4.3-6">
					If 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 indent="0" pn="section-4.3-7">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 Connection Mode for
        a specific client, the server may close the connection. For example, a
        server <bcp14>MUST</bcp14> be configured to time out a Single
        Connection Mode TCP connection after a specific period of inactivity
        to preserve its resources. The client <bcp14>MUST</bcp14> accommodate
        such closures on a TCP session even after Single Connection Mode has
        been established.</t>
        <t indent="0" pn="section-4.3-8">The TCP connection underlying the Single Connection Mode will close
        eventually either because of the timeout from the server or from an
        intermediate link.  If a session is in progress when the client
        detects disconnect, then the client should handle it as described in
        "Session Completion" (<xref target="SessionCompletion" format="default" sectionFormat="of" derivedContent="Section 4.4"/>).  If a session is
        not in progress, then the client will need to detect this and restart
        the Single Connection Mode when it initiates the next session.
        </t>
      </section>
      <section anchor="SessionCompletion" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-session-completion">Session Completion</name>
        <t indent="0" pn="section-4.4-1">The REPLY packets defined for the packet types in the sections
        below (Authentication, 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, and FAIL, which indicate the last packet of a
        regular session (one that is not aborted).</t>
        <t indent="0" pn="section-4.4-2">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 that
        prompted the request to be sent to the server.</t>
        <t indent="0" pn="section-4.4-3">The server responds with an ERROR to indicate that the processing
        of the request did not complete. The client cannot apply the result,
        and it <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 or
        using local configuration to determine whether the action that
        prompted the request should be executed.</t>
        <t indent="0" pn="section-4.4-4">
	Refer to "Aborting an Authentication Session" (<xref target="AbortinganAuthenticationSession" format="default" sectionFormat="of" derivedContent="Section 5.4.3"/>) for details
	on handling additional status options.
        </t>
        <t indent="0" pn="section-4.4-5">When the session is complete, the TCP connection should be
        handled as follows, according to whether Single Connection Mode was
        negotiated:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4.4-6">
          <li pn="section-4.4-6.1">
            <t indent="0" pn="section-4.4-6.1.1">If Single Connection Mode was not negotiated, then the connection
        should be closed.</t>
          </li>
          <li pn="section-4.4-6.2">
            <t indent="0" pn="section-4.4-6.2.1">
	
					If Single Connection Mode was enabled,
					then the connection
					<bcp14>SHOULD</bcp14> be left open
					(see "Single Connection Mode" (<xref target="SingleConnectMode" format="default" sectionFormat="of" derivedContent="Section 4.3"/>)) but may still be
					closed after a timeout period to
					preserve deployment resources.
            </t>
          </li>
          <li pn="section-4.4-6.3">
            <t indent="0" pn="section-4.4-6.3.1">
					If Single Connection Mode was enabled,
					but an ERROR occurred due to
					connection issues (such as an
					incorrect secret (see <xref target="Obfuscation" format="default" sectionFormat="of" derivedContent="Section 4.5"/>)), then any further
					new sessions <bcp14>MUST NOT</bcp14>
					be accepted on the connection.  If
					there are any sessions that have
					already been established, then they
					<bcp14>MAY</bcp14> be completed. Once
					all active sessions are completed, then
					the connection <bcp14>MUST</bcp14> be
					closed.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-4.4-7">It is recommended that client implementations provide robust
        schemes for dealing with servers that cannot be connected to.  Options
        include providing a list of servers for redundancy and an option for
        a local fallback configuration if no servers can be reached. Details
        will be implementation specific.</t>
        <t indent="0" pn="section-4.4-8">
					The client should manage connections
					and handle the case of a server that
					establishes a connection but does not
					respond. The exact behavior is
					implementation specific. It is
					recommended that the client 
					close the connection after a
					configurable timeout.
        </t>
      </section>
      <section anchor="Obfuscation" numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-data-obfuscation">Data Obfuscation</name>
        <t indent="0" pn="section-4.5-1">
					The body of packets may be
					obfuscated. The following sections
					describe the obfuscation method that
					is supported in the protocol.  In "The
					Draft", this process was actually
					referred to as Encryption, but the
					algorithm would not meet modern
					standards and so will not be termed
					as encryption in this document.
        </t>
        <t indent="0" pn="section-4.5-2">
					The obfuscation mechanism relies on a
					secret key, a shared secret value that
					is known to both the client and the
					server.  The secret keys
					<bcp14>MUST</bcp14> remain secret.
        </t>
        <t indent="0" pn="section-4.5-3">Server implementations <bcp14>MUST</bcp14> allow a unique secret
        key to be associated with each client. It is a site-dependent decision
        as to whether or not the use of separate keys is appropriate.
        </t>
        <t indent="0" pn="section-4.5-4">


 The flag field <bcp14>MUST</bcp14> be configured with
 TAC_PLUS_UNENCRYPTED_FLAG set to 0 so that the packet body is obfuscated by
 XORing it bytewise with a pseudo-random pad:
</t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.5-5">
          <li pn="section-4.5-5.1">
            <t indent="0" pn="section-4.5-5.1.1">ENCRYPTED {data} = data <sup>pseudo_pad</sup>
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-4.5-6">The packet body can then be de-obfuscated by XORing it bytewise
  with a pseudo-random pad.
</t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.5-7">
          <li pn="section-4.5-7.1">
            <t indent="0" pn="section-4.5-7.1.1">
					data = ENCRYPTED {data} <sup>pseudo_pad</sup>
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-4.5-8">
					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.

					Whenever used in this document, MD5 refers to
					the "RSA Data
					Security, Inc.  MD5 Message-Digest
					Algorithm" as specified in
					<xref target="RFC1321" format="default" sectionFormat="of" derivedContent="RFC1321"/>.
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.5-9">
          <li pn="section-4.5-9.1">
            <t indent="0" pn="section-4.5-9.1.1">
					pseudo_pad = {MD5_1 [,MD5_2 [
					... ,MD5_n]]} truncated to len(data)
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-4.5-10">
					The first MD5 hash is generated by
					concatenating the session_id, the
					secret key, the version number, and the
					sequence number, and then running MD5
					over that stream. All of those input
					values are available in the packet
					header, except for the secret
					key, which
					is a shared secret between the TACACS+
					client and server.
        </t>
        <t indent="0" pn="section-4.5-11">
					The version number and session_id are extracted from the
					header.
        </t>
        <t indent="0" pn="section-4.5-12">
					Subsequent hashes are generated by
					using the same input stream but
					concatenating the previous hash value
					at the end of the input stream.
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.5-13">
          <li pn="section-4.5-13.1">
            <t indent="0" pn="section-4.5-13.1.1">
					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 indent="0" pn="section-4.5-14">
	  
					When a server detects that the
					secrets it has configured for the
					device do not match, it
					<bcp14>MUST</bcp14> return ERROR. For
					details of TCP connection handling on
					ERROR, refer to "Session Completion" (<xref target="SessionCompletion" format="default" sectionFormat="of" derivedContent="Section 4.4"/>).
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.5-15">
          <li pn="section-4.5-15.1">
            <t indent="0" pn="section-4.5-15.1.1">
					TAC_PLUS_UNENCRYPTED_FLAG == 0x1
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-4.5-16">
					This option is deprecated and
					<bcp14>MUST NOT</bcp14> be used in
					production. In this case, the entire
					packet body is in cleartext. A request
					<bcp14>MUST</bcp14> be dropped if
					TAC_PLUS_UNENCRYPTED_FLAG is set to
					true.
        </t>
        <t indent="0" pn="section-4.5-17">
					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 <bcp14>MUST</bcp14> be
					discarded and an ERROR signaled. For details of TCP connection
					handling on ERROR, refer to
					"Session Completion" (<xref target="SessionCompletion" format="default" sectionFormat="of" derivedContent="Section 4.4"/>).
        </t>
        <t indent="0" pn="section-4.5-18">
					Commonly, such failures are seen when
					the keys are mismatched between the
					client and the TACACS+ server.
        </t>
      </section>
    </section>
    <section anchor="Authentication" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-authentication">Authentication</name>
      <t indent="0" pn="section-5-1">Authentication is the action of determining who a user (or entity)
      is. Authentication can take many forms.  Traditional authentication
      employs a name and a fixed password. However, fixed passwords are
      vulnerable security, so many modern authentication mechanisms utilize
      "one-time" passwords or a challenge-response query. TACACS+ is designed
      to support all of these and be flexible enough to handle any future
      mechanisms.  Authentication generally takes place when the user first
      logs in to a machine or requests a service of it.</t>
      <t indent="0" pn="section-5-2">Authentication is not mandatory; it is a site-configured option.
      Some sites do not require it. Others require it only for certain
      services (see "Authorization" (<xref target="Authorization" format="default" sectionFormat="of" derivedContent="Section 6"/>)).  Authentication may also take place
      when a user attempts to gain extra privileges and must identify himself
      or herself as someone who possesses the required information (passwords,
      etc.) for those privileges.</t>
      <section anchor="TheAuthenticationSTARTPacketBody" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-the-authentication-start-pa">The Authentication START Packet Body</name>
        <artwork name="" type="" align="left" alt="" pn="section-5.1-1">
 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>
        <t indent="0" pn="section-5.1-2">
					Packet fields are as follows:
        </t>
        <t indent="0" pn="section-5.1-3">
		action
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.1-4">
          <li pn="section-5.1-4.1">
            <t indent="0" pn="section-5.1-4.1.1"> This indicates the authentication action. </t>
            <t indent="0" pn="section-5.1-4.1.2">
Valid values are:
            </t>
          </li>
          <li pn="section-5.1-4.2">
							TAC_PLUS_AUTHEN_LOGIN := 0x01
						</li>
          <li pn="section-5.1-4.3">
							TAC_PLUS_AUTHEN_CHPASS := 0x02
						</li>
          <li pn="section-5.1-4.4">
							TAC_PLUS_AUTHEN_SENDAUTH := 0x04
						</li>
        </ul>
        <t indent="0" pn="section-5.1-5">
					priv_lvl
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.1-6">
          <li pn="section-5.1-6.1">
            <t indent="0" pn="section-5.1-6.1.1"> This indicates the privilege level that the user is authenticating
as. Please refer to "Privilege Levels" (<xref target="PrivilegeLevel" format="default" sectionFormat="of" derivedContent="Section 9"/>).
</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.1-7">
authen_type
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.1-8">
          <li pn="section-5.1-8.1">
            <t indent="0" pn="section-5.1-8.1.1">
The type of authentication. Please see "Common Authentication Flows" (<xref target="CommonAuthenticationFlows" format="default" sectionFormat="of" derivedContent="Section 5.4.2"/>).
            </t>
          </li>
          <li pn="section-5.1-8.2">
            <t indent="0" pn="section-5.1-8.2.1">
Valid values are:
            </t>
          </li>
          <li pn="section-5.1-8.3">
							TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01
						</li>
          <li pn="section-5.1-8.4">
							TAC_PLUS_AUTHEN_TYPE_PAP := 0x02
						</li>
          <li pn="section-5.1-8.5">
							TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03
						</li>
          <li pn="section-5.1-8.6">
							TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05
						</li>
          <li pn="section-5.1-8.7">
							TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06
						</li>
        </ul>
        <t indent="0" pn="section-5.1-9">
					authen_service
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.1-10">
          <li pn="section-5.1-10.1">
            <t indent="0" pn="section-5.1-10.1.1">
					This is the service that is requesting
					the authentication. 
            </t>
          </li>
          <li pn="section-5.1-10.2">
            <t indent="0" pn="section-5.1-10.2.1">
Valid values are:
            </t>
          </li>
          <li pn="section-5.1-10.3">
							TAC_PLUS_AUTHEN_SVC_NONE := 0x00
						</li>
          <li pn="section-5.1-10.4">
							TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01
						</li>
          <li pn="section-5.1-10.5">
							TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02
						</li>
          <li pn="section-5.1-10.6">
							TAC_PLUS_AUTHEN_SVC_PPP := 0x03
						</li>
          <li pn="section-5.1-10.7">
							TAC_PLUS_AUTHEN_SVC_PT := 0x05
						</li>
          <li pn="section-5.1-10.8">
							TAC_PLUS_AUTHEN_SVC_RCMD := 0x06
						</li>
          <li pn="section-5.1-10.9">
							TAC_PLUS_AUTHEN_SVC_X25 := 0x07
						</li>
          <li pn="section-5.1-10.10">
							TAC_PLUS_AUTHEN_SVC_NASI := 0x08
						</li>
          <li pn="section-5.1-10.11">
							TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09
						</li>
          <li pn="section-5.1-10.12">
            <t indent="0" pn="section-5.1-10.12.1">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 indent="0" pn="section-5.1-10.12.2">The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as
        opposed to ENABLE) to a client device.</t>
          </li>
          <li pn="section-5.1-10.13">
            <t indent="0" pn="section-5.1-10.13.1">
					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;
					no requirements for previous
					authentications or authorizations are
					imposed by the protocol.
            </t>
          </li>
          <li pn="section-5.1-10.14">
            <t indent="0" pn="section-5.1-10.14.1">Other options are included for legacy/backwards compatibility.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.1-11">
					user, user_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.1-12">
          <li pn="section-5.1-12.1">
            <t indent="0" pn="section-5.1-12.1.1">
					The username is optional in this
					packet, depending upon the class of
					authentication. If it is absent, the
					client <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 indent="0" pn="section-5.1-13">
					port, port_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.1-14">
          <li pn="section-5.1-14.1">
            <t indent="0" pn="section-5.1-14.1.1">
					The name of the client port on which
					the authentication is taking place.
					The value of this field is free-format
					text and is client specific.  Examples
					of this argument include "tty10"
					to denote the tenth tty line, and
					"async10" to denote the tenth async
					interface. The client documentation
					<bcp14>SHOULD</bcp14> define the
					values and their meanings for this
					field.  For details of text encoding,
					see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).  The port_len indicates the
					length of the port field, in bytes.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-5.1-15">
					rem_addr, rem_addr_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.1-16">
          <li pn="section-5.1-16.1">
            <t indent="0" pn="section-5.1-16.1.1">
					A string indicating the remote
					location from which the user has
					connected to the client. For details
					of text encoding, see "Treatment of
					Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
          <li pn="section-5.1-16.2">
            <t indent="0" pn="section-5.1-16.2.1"> When TACACS+ was used for dial-up services, this value contained
        the caller ID.</t>
          </li>
          <li pn="section-5.1-16.3">
            <t indent="0" pn="section-5.1-16.3.1">
					When TACACS+ is used for Device
					Administration, the user is normally
					connected via a network, and in this
					case, the value is intended to hold a
					network address, IPv4 or IPv6. For
					IPv6 address text representation
					defined, please see <xref target="RFC5952" format="default" sectionFormat="of" derivedContent="RFC5952"/>.
            </t>
          </li>
          <li pn="section-5.1-16.4">
            <t indent="0" pn="section-5.1-16.4.1">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 indent="0" pn="section-5.1-17">
					data, data_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.1-18">
          <li pn="section-5.1-18.1">
            <t indent="0" pn="section-5.1-18.1.1">
	The data field is used to send data appropriate for the action and
	authen_type. It is described in more detail in "Common Authentication
	Flows" (<xref target="CommonAuthenticationFlows" format="default" sectionFormat="of" derivedContent="Section 5.4.2"/>). The data_len field indicates the length of the
	data field, in bytes.
            </t>
          </li>
        </ul>
      </section>
      <section anchor="TheAuthenticationREPLYPacketBody" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-the-authentication-reply-pa">The Authentication REPLY Packet Body</name>
        <t indent="0" pn="section-5.2-1">
					The TACACS+ server sends only one type
					of authentication packet (a REPLY
					packet) to the client.
        </t>
        <artwork name="" type="" align="left" alt="" pn="section-5.2-2">
 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>
        <t indent="0" pn="section-5.2-3">
					status
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.2-4">
          <li pn="section-5.2-4.1">
            <t indent="0" pn="section-5.2-4.1.1">
	The current status of the authentication.
            </t>
          </li>
          <li pn="section-5.2-4.2">Valid values are:
</li>
        </ul>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-5.2-5">
          <li pn="section-5.2-5.1">
							TAC_PLUS_AUTHEN_STATUS_PASS := 0x01
						</li>
          <li pn="section-5.2-5.2">
							TAC_PLUS_AUTHEN_STATUS_FAIL :=
							0x02
						</li>
          <li pn="section-5.2-5.3">
							TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03
						</li>
          <li pn="section-5.2-5.4">
							TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04
						</li>
          <li pn="section-5.2-5.5">
							TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05
						</li>
          <li pn="section-5.2-5.6">
							TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06
						</li>
          <li pn="section-5.2-5.7">
							TAC_PLUS_AUTHEN_STATUS_ERROR
							:= 0x07
						</li>
          <li pn="section-5.2-5.8">
							TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21
						</li>
        </ul>
        <t indent="0" pn="section-5.2-6">
					flags
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.2-7">
          <li pn="section-5.2-7.1">
            <t indent="0" pn="section-5.2-7.1.1">
	Bitmapped flags that modify the action to be taken.  
            </t>
          </li>
          <li pn="section-5.2-7.2">The following values are defined:
</li>
        </ul>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-5.2-8">
          <li pn="section-5.2-8.1">
							TAC_PLUS_REPLY_FLAG_NOECHO := 0x01
						</li>
        </ul>
        <t indent="0" pn="section-5.2-9">
					server_msg, server_msg_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.2-10">
          <li pn="section-5.2-10.1">
            <t indent="0" pn="section-5.2-10.1.1">
	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 text encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-5.2-11">
					data, data_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.2-12">
          <li pn="section-5.2-12.1">
            <t indent="0" pn="section-5.2-12.1.1">
	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 "Common
	Authentication Flows" (<xref target="CommonAuthenticationFlows" format="default" sectionFormat="of" derivedContent="Section 5.4.2"/>). The data_len indicates the length of the data
	field, in bytes.
            </t>
          </li>
        </ul>
      </section>
      <section anchor="TheAuthenticationCONTINUEPacketBody" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-the-authentication-continue">The Authentication CONTINUE Packet Body</name>
        <t indent="0" pn="section-5.3-1">
	This packet is sent from the client to the server following the
	receipt of a REPLY packet.
        </t>
        <artwork name="" type="" align="left" alt="" pn="section-5.3-2">
 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>
        <t indent="0" pn="section-5.3-3">
					user_msg, user_msg_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.3-4">
          <li pn="section-5.3-4.1">
            <t indent="0" pn="section-5.3-4.1.1">
	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 indent="0" pn="section-5.3-5">
					data, data_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.3-6">
          <li pn="section-5.3-6.1">
            <t indent="0" pn="section-5.3-6.1.1">
	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 indent="0" pn="section-5.3-7">
					flags
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.3-8">
          <li pn="section-5.3-8.1">
            <t indent="0" pn="section-5.3-8.1.1">
	This holds the bitmapped flags that modify the action to be taken.
            </t>
          </li>
          <li pn="section-5.3-8.2">
            <t indent="0" pn="section-5.3-8.2.1">
	The following values are defined:
            </t>
          </li>
          <li pn="section-5.3-8.3">
							TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01
						</li>
        </ul>
      </section>
      <section anchor="DescriptionofAuthenticationProcess" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-description-of-authenticati">Description of Authentication Process</name>
        <t indent="0" pn="section-5.4-1">
	The action, authen_type, and authen_service fields (described above)
	combine to indicate what kind of authentication is to be performed.
	Every authentication START, REPLY, and CONTINUE packet includes a data
	field. The use of this field is dependent upon the kind of
	authentication.
        </t>
        <t indent="0" pn="section-5.4-2">
	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, or GETPASS) or a termination PASS, FAIL,
	ERROR, or RESTART. The actions and meanings when the server sends a
	RESTART or ERROR are common and are described further below.
        </t>
        <t indent="0" pn="section-5.4-3">
	When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA,
	TAC_PLUS_AUTHEN_STATUS_GETUSER, or TAC_PLUS_AUTHEN_STATUS_GETPASS, 
	authentication continues and the server <bcp14>SHOULD</bcp14> provide
	server_msg content for the client to prompt the user for more
	information. The client <bcp14>MUST</bcp14> then return a CONTINUE
	packet containing the requested information in the user_msg field.
        </t>
        <t indent="0" pn="section-5.4-4">
	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 indent="0" pn="section-5.4-5">If the information being requested by the server 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 <bcp14>MUST NOT</bcp14> be reflected in the user interface as
        it is entered.
        </t>
        <t indent="0" pn="section-5.4-6">
					The data field is only used in the REPLY
					where
					explicitly
					defined
					below.
        </t>
        <section anchor="VersionBehaviour" numbered="true" toc="include" removeInRFC="false" pn="section-5.4.1">
          <name slugifiedName="name-version-behavior">Version Behavior</name>
          <t indent="0" pn="section-5.4.1-1">
						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 Challenge
						Handshake
						Authentication
						Protocol (CHAP) and
						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>
          <table anchor="table_1" align="center" pn="table-1">
            <name slugifiedName="name-tacacs-protocol-versioning">TACACS+ Protocol Versioning</name>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1"/>
                <td align="left" colspan="1" rowspan="1">LOGIN</td>
                <td align="left" colspan="1" rowspan="1">CHPASS</td>
                <td align="left" colspan="1" rowspan="1">SENDAUTH</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">ASCII</td>
                <td align="left" colspan="1" rowspan="1">v0</td>
                <td align="left" colspan="1" rowspan="1">v0</td>
                <td align="left" colspan="1" rowspan="1">-</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">PAP</td>
                <td align="left" colspan="1" rowspan="1">v1</td>
                <td align="left" colspan="1" rowspan="1">-</td>
                <td align="left" colspan="1" rowspan="1">v1</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">CHAP</td>
                <td align="left" colspan="1" rowspan="1">v1</td>
                <td align="left" colspan="1" rowspan="1">-</td>
                <td align="left" colspan="1" rowspan="1">v1</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">MS-CHAPv1/2</td>
                <td align="left" colspan="1" rowspan="1">v1</td>
                <td align="left" colspan="1" rowspan="1">-</td>
                <td align="left" colspan="1" rowspan="1">v1</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-5.4.1-3">The '-' symbol represents that the option is not valid.</t>
          <t indent="0" pn="section-5.4.1-4">
		All authorization and accounting and ASCII authentication use
		minor_version 0.
          </t>
          <t indent="0" pn="section-5.4.1-5">
	PAP, 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 indent="0" pn="section-5.4.1-6"> The removal of SENDPASS was prompted by security concerns and
          is no longer considered part of the TACACS+ protocol.
          </t>
        </section>
        <section anchor="CommonAuthenticationFlows" numbered="true" toc="include" removeInRFC="false" pn="section-5.4.2">
          <name slugifiedName="name-common-authentication-flows">Common Authentication Flows</name>
          <t indent="0" pn="section-5.4.2-1">
	This section describes common authentication flows. If the server does
	not implement an option, it <bcp14>MUST</bcp14> respond with
	TAC_PLUS_AUTHEN_STATUS_FAIL.
          </t>
          <section anchor="ASCIILogin" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.4.2.1">
            <name slugifiedName="name-ascii-login">ASCII Login</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.4.2.1-1">
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
    minor_version = 0x0
							</artwork>
            <t indent="0" pn="section-5.4.2.1-2">
	This is a standard ASCII authentication. The START packet
	<bcp14>MAY</bcp14> contain the username. If the user does not include
	the username, then the server <bcp14>MUST</bcp14> obtain it from the
	client with a CONTINUE TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user
	does not provide a username, then the server can send another
	TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server
	<bcp14>MUST</bcp14> limit the number of retries that are 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; any content
	<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, or ERROR.
            </t>
          </section>
          <section anchor="PAPLogin" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.4.2.2">
            <name slugifiedName="name-pap-login">PAP Login</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.4.2.2-1">
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
    minor_version = 0x1
							</artwork>
            <t indent="0" pn="section-5.4.2.2-2">
	The entire exchange <bcp14>MUST</bcp14> consist of a single START
	packet and a single REPLY. The START packet <bcp14>MUST</bcp14>
	contain a username and the data field <bcp14>MUST</bcp14> contain the
	PAP ASCII password. A PAP authentication only consists of a username
	and password <xref target="RFC1334" format="default" sectionFormat="of" derivedContent="RFC1334"/> (Obsolete). The
	REPLY from the server <bcp14>MUST</bcp14> be either a PASS, FAIL, or
	ERROR.
            </t>
          </section>
          <section anchor="CHAPlogin" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.4.2.3">
            <name slugifiedName="name-chap-login">CHAP Login</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.4.2.3-1">
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP
    minor_version = 0x1
							</artwork>
            <t indent="0" pn="section-5.4.2.3-2">
	The entire exchange <bcp14>MUST</bcp14> consist of a single START
	packet and a single REPLY. The START packet <bcp14>MUST</bcp14>
	contain the username in the user field, and the data field is a
	concatenation of the PPP id, the challenge, and the response.
            </t>
            <t indent="0" pn="section-5.4.2.3-3">
	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 indent="0" pn="section-5.4.2.3-4">
To perform the authentication, the server calculates the PPP hash as defined
in PPP Authentication <xref target="RFC1334" format="default" sectionFormat="of" derivedContent="RFC1334"/> and then
compares that value with the response. The MD5 algorithm option is always
used.  The REPLY from the server <bcp14>MUST</bcp14> be a PASS, FAIL, or
ERROR.
            </t>
            <t indent="0" pn="section-5.4.2.3-5">
	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 be configured with a secure
	challenge. The TACACS+ server can help by rejecting authentications
	where the challenge is below a minimum length (minimum recommended is
	8 bytes).
            </t>
          </section>
          <section anchor="MS-CHAPv1login" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.4.2.4">
            <name slugifiedName="name-ms-chap-v1-login">MS-CHAP v1 Login</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.4.2.4-1">
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP
    minor_version = 0x1
							</artwork>
            <t indent="0" pn="section-5.4.2.4-2">
The entire exchange <bcp14>MUST</bcp14> consist of a single START packet and a
single REPLY. The START packet <bcp14>MUST</bcp14> contain the username in the
user field, and the data field will be a concatenation of the PPP id, the
MS-CHAP challenge, and the MS-CHAP response.
            </t>
            <t indent="0" pn="section-5.4.2.4-3">
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 indent="0" pn="section-5.4.2.4-4">
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" format="default" sectionFormat="of" derivedContent="RFC2433"/>, and then compare the
resulting value with the response. The REPLY from the server
<bcp14>MUST</bcp14> be a PASS or FAIL.
            </t>
            <t indent="0" pn="section-5.4.2.4-5">
	For best practices, please refer to <xref target="RFC2433" format="default" sectionFormat="of" derivedContent="RFC2433"/>. The TACACS+ server <bcp14>MUST</bcp14> reject
	authentications where the challenge deviates from 8 bytes as defined
	in the RFC.
            </t>
          </section>
          <section anchor="MS-CHAPv2login" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.4.2.5">
            <name slugifiedName="name-ms-chap-v2-login">MS-CHAP v2 Login</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.4.2.5-1">
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2
    minor_version = 0x1
							</artwork>
            <t indent="0" pn="section-5.4.2.5-2">
The entire exchange <bcp14>MUST</bcp14> consist of a single START packet and a
single REPLY. The START packet <bcp14>MUST</bcp14> contain the username in the
user field, and the data field will be a concatenation of the PPP id, the
MS-CHAP challenge, and the MS-CHAP response.
            </t>
            <t indent="0" pn="section-5.4.2.5-3">
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 indent="0" pn="section-5.4.2.5-4">
To perform the authentication, the server will use the algorithm specified
<xref target="RFC2759" format="default" sectionFormat="of" derivedContent="RFC2759"/> on the user's secret and challenge,
and then compare the resulting value with the response.  The REPLY from the
server <bcp14>MUST</bcp14> be a PASS or FAIL.
            </t>
            <t indent="0" pn="section-5.4.2.5-5">
For best practices for MS-CHAP v2, please refer to <xref target="RFC2759" format="default" sectionFormat="of" derivedContent="RFC2759">RFC2759</xref>. The TACACS+ server <bcp14>MUST</bcp14> reject
authentications where the challenge deviates from 16 bytes as defined in the
RFC.
            </t>
          </section>
          <section anchor="EnableRequests" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.4.2.6">
            <name slugifiedName="name-enable-requests">Enable Requests</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.4.2.6-1">
    action = TAC_PLUS_AUTHEN_LOGIN
    priv_lvl = implementation dependent
    authen_type = not used
    service = TAC_PLUS_AUTHEN_SVC_ENABLE
							</artwork>
            <t indent="0" pn="section-5.4.2.6-2">
	This is an "ENABLE" request, used to change the current running
	privilege level of a user.  The exchange <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 ASCII login (<xref target="ASCIILogin" format="default" sectionFormat="of" derivedContent="Section 5.4.2.1"/>).
            </t>
            <t indent="0" pn="section-5.4.2.6-3">
In order to readily distinguish "ENABLE" requests from other types of request,
the value of the authen_service field <bcp14>MUST</bcp14> be set to
TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It <bcp14>MUST NOT</bcp14> be set to this value when requesting any other operation.
            </t>
          </section>
          <section anchor="ASCIIchangepasswordrequest" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.4.2.7">
            <name slugifiedName="name-ascii-change-password-reque">ASCII Change Password Request</name>
            <artwork name="" type="" align="left" alt="" pn="section-5.4.2.7-1">
action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
							</artwork>
            <t indent="0" pn="section-5.4.2.7-2">
	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 <bcp14>MUST</bcp14> only be used when
	requesting the "new" password. It <bcp14>MAY</bcp14> be sent multiple
	times. When requesting the "old" password, the status value
	<bcp14>MUST</bcp14> be set to TAC_PLUS_AUTHEN_STATUS_GETDATA.
            </t>
          </section>
        </section>
        <section anchor="AbortinganAuthenticationSession" numbered="true" toc="include" removeInRFC="false" pn="section-5.4.3">
          <name slugifiedName="name-aborting-an-authentication-">Aborting an Authentication Session</name>
          <t indent="0" pn="section-5.4.3-1">

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 text explaining the reason
for the abort. This text will be handled by the server according to the
requirements of the deployment. For details of text encoding, see "Treatment
of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>). For more
details about session termination, refer to "Session Completion" (<xref target="SessionCompletion" format="default" sectionFormat="of" derivedContent="Section 4.4"/>).


          </t>
          <t indent="0" pn="section-5.4.3-2">
	In cases of PASS, FAIL, or ERROR, the server can insert a message into
	server_msg to be displayed to the user.
          </t>
          <t indent="0" pn="section-5.4.3-3">
	"The Draft" <xref target="THE-DRAFT" format="default" sectionFormat="of" derivedContent="THE-DRAFT"/>
	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.
          </t>
          <t indent="0" pn="section-5.4.3-4">
	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 indent="0" pn="section-5.4.3-5">
	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 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 indent="0" pn="section-5.4.3-6">
	If a client does not implement the TAC_PLUS_AUTHEN_STATUS_RESTART option,
	then it <bcp14>MUST</bcp14> process the response as if the status was
	TAC_PLUS_AUTHEN_STATUS_FAIL.
          </t>
        </section>
      </section>
    </section>
    <section anchor="Authorization" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-authorization">Authorization</name>
      <t indent="0" pn="section-6-1">In the TACACS+ 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, it is up to the server to
      determine, according to its configuration, if an unauthenticated user is
      allowed the services in question.</t>
      <t indent="0" pn="section-6-2">
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 "Authorization Arguments" (<xref target="AuthorizationAttributes" format="default" sectionFormat="of" derivedContent="Section 8.2"/>).
      </t>
      <t indent="0" pn="section-6-3">
In the TACACS+ protocol, an authorization is always a single pair of messages:
a REQUEST from the client followed by a REPLY from the server.
      </t>
      <t indent="0" pn="section-6-4">
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 indent="0" pn="section-6-5">
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" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-the-authorization-request-p">The Authorization REQUEST Packet Body</name>
        <artwork name="" type="" align="left" alt="" pn="section-6.1-1">
  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>
        <t indent="0" pn="section-6.1-2">
					authen_method
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-3">
          <li pn="section-6.1-3.1">
            <t indent="0" pn="section-6.1-3.1.1">
This field allows the client to indicate the authentication method used to
acquire user information.
            </t>
          </li>
          <li pn="section-6.1-3.2">
							TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00
						</li>
          <li pn="section-6.1-3.3">
							TAC_PLUS_AUTHEN_METH_NONE :=
							0x01
						</li>
          <li pn="section-6.1-3.4">
							TAC_PLUS_AUTHEN_METH_KRB5 := 0x02
						</li>
          <li pn="section-6.1-3.5">
							TAC_PLUS_AUTHEN_METH_LINE :=
							0x03
						</li>
          <li pn="section-6.1-3.6">
							TAC_PLUS_AUTHEN_METH_ENABLE := 0x04
						</li>
          <li pn="section-6.1-3.7">
							TAC_PLUS_AUTHEN_METH_LOCAL
							:= 0x05
						</li>
          <li pn="section-6.1-3.8">
							TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06
						</li>
          <li pn="section-6.1-3.9">
							TAC_PLUS_AUTHEN_METH_GUEST := 0x08
						</li>
          <li pn="section-6.1-3.10">
							TAC_PLUS_AUTHEN_METH_RADIUS :=
							0x10
						</li>
          <li pn="section-6.1-3.11">
							TAC_PLUS_AUTHEN_METH_KRB4 := 0x11
						</li>
          <li pn="section-6.1-3.12">
							TAC_PLUS_AUTHEN_METH_RCMD :=
							0x20
						</li>
          <li pn="section-6.1-3.13">
            <t indent="0" pn="section-6.1-3.13.1"> As this information is not always subject to verification, it <bcp14>MUST NOT</bcp14> be used in policy 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 authentication protocol.  RCMD refers to authentication
        provided via the R-command protocols from Berkeley Unix.

	KRB5 <xref target="RFC4120" format="default" sectionFormat="of" derivedContent="RFC4120"/> and KRB4 <xref target="KRB4" format="default" sectionFormat="of" derivedContent="KRB4"/>
        are Kerberos versions 5 and 4.</t>
          </li>
          <li pn="section-6.1-3.14">
            <t indent="0" pn="section-6.1-3.14.1"> 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 "Authentication" (<xref target="Authentication" format="default" sectionFormat="of" derivedContent="Section 5"/>).  For all other options,
such as KRB and RADIUS, the TACACS+ protocol did not play any part in the
authentication phase; as those interactions were not conducted using the
TACACS+ protocol, they will not be documented here. For implementers of
clients who need details of the other protocols, please refer to the
respective Kerberos <xref target="RFC4120" format="default" sectionFormat="of" derivedContent="RFC4120"/> and RADIUS
<xref target="RFC3579" format="default" sectionFormat="of" derivedContent="RFC3579"/> RFCs.  </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-4">
					priv_lvl
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-5">
          <li pn="section-6.1-5.1">
            <t indent="0" pn="section-6.1-5.1.1">
This field is used in the same way as the priv_lvl field in authentication
request and is described in "Privilege Levels" (<xref target="PrivilegeLevel" format="default" sectionFormat="of" derivedContent="Section 9"/>). It indicates the user's
current privilege level.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-6">
					authen_type
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-7">
          <li pn="section-6.1-7.1">
            <t indent="0" pn="section-6.1-7.1.1"> This field corresponds to the authen_type field in "Authentication" (<xref target="Authentication" format="default" sectionFormat="of" derivedContent="Section 5"/>). It indicates
the type of authentication that was performed. If this information is not
available, then the client will set authen_type to
TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. This value is valid only in
authorization and accounting requests.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-8">
					authen_service
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-9">
          <li pn="section-6.1-9.1">
            <t indent="0" pn="section-6.1-9.1.1">
This field is the same as the authen_service field in "Authentication" (<xref target="Authentication" format="default" sectionFormat="of" derivedContent="Section 5"/>). It indicates
the service through which the user authenticated.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-10">
					user, user_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-11">
          <li pn="section-6.1-11.1">
            <t indent="0" pn="section-6.1-11.1.1">
This field contains the user's account name. The user_len <bcp14>MUST</bcp14>
indicate the length of the user field, in bytes.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-12">
					port, port_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-13">
          <li pn="section-6.1-13.1">
            <t indent="0" pn="section-6.1-13.1.1">
	This field matches the port field in "Authentication" (<xref target="Authentication" format="default" sectionFormat="of" derivedContent="Section 5"/>). The port_len
	indicates the length of the port field, in bytes.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-14">
					rem_addr, rem_addr_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-15">
          <li pn="section-6.1-15.1">
            <t indent="0" pn="section-6.1-15.1.1">
	This field matches the rem_addr field in "Authentication" (<xref target="Authentication" format="default" sectionFormat="of" derivedContent="Section 5"/>). The rem_addr_len indicates the
	length of the port field, in bytes.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-16">
					arg_cnt
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-17">
          <li pn="section-6.1-17.1">
            <t indent="0" pn="section-6.1-17.1.1">
					This represents the number of authorization arguments to follow.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.1-18">
					arg_1 ... arg_N, arg_1_len .... arg_N_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.1-19">
          <li pn="section-6.1-19.1">
            <t indent="0" pn="section-6.1-19.1.1">
	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 field (which indicates the length of each
	argument in bytes).
            </t>
          </li>
          <li pn="section-6.1-19.2">
            <t indent="0" pn="section-6.1-19.2.1">
	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 text encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
          <li pn="section-6.1-19.3">
            <t indent="0" pn="section-6.1-19.3.1">
	An argument name <bcp14>MUST NOT</bcp14> contain either of the
	separators. An argument value <bcp14>MAY</bcp14> contain the
	separators. This means that the arguments must be parsed until the
	first separator is encountered; all characters in the argument, after
	this separator, are interpreted as the argument value.
            </t>
          </li>
          <li pn="section-6.1-19.4">
            <t indent="0" pn="section-6.1-19.4.1">
        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, 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 <bcp14>MUST</bcp14>
        consider the authorization to have failed. The value part of an
        argument-value pair may be empty, that is, the length of the value may
        be zero.
            </t>
          </li>
          <li pn="section-6.1-19.5">
            <t indent="0" pn="section-6.1-19.5.1">
	Argument-value strings are not NULL 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).
            </t>
          </li>
          <li pn="section-6.1-19.6">
            <t indent="0" pn="section-6.1-19.6.1">
Though the arguments allow extensibility, a common core set of authorization
arguments <bcp14>SHOULD</bcp14> be supported by clients and servers; these are
listed in "Authorization Arguments" (<xref target="AuthorizationAttributes" format="default" sectionFormat="of" derivedContent="Section 8.2"/>).
            </t>
          </li>
        </ul>
      </section>
      <section anchor="TheAuthorizationREPLYPacketBody" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-the-authorization-reply-pac">The Authorization REPLY Packet Body</name>
        <artwork name="" type="" align="left" alt="" pn="section-6.2-1">
 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>
        <t indent="0" pn="section-6.2-2">


	status
        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.2-3">
          <li pn="section-6.2-3.1">
            <t indent="0" pn="section-6.2-3.1.1">This field indicates the authorization status.
</t>
          </li>
          <li pn="section-6.2-3.2">
            <t indent="0" pn="section-6.2-3.2.1">TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01</t>
            <t indent="4" pn="section-6.2-3.2.2"> 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 indent="4" pn="section-6.2-3.2.3">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>
          </li>
          <li pn="section-6.2-3.3">
            <t indent="0" pn="section-6.2-3.3.1">TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02</t>
            <t indent="4" pn="section-6.2-3.3.2">If the status equals
		TAC_PLUS_AUTHOR_STATUS_PASS_REPL, then the client
		<bcp14>MUST</bcp14> use the authorization argument-value pairs
		(if any) in the response instead of the authorization
		argument-value pairs from the request.
            </t>
          </li>
          <li pn="section-6.2-3.4">
            <t indent="0" pn="section-6.2-3.4.1">TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10</t>
            <t indent="4" pn="section-6.2-3.4.2">If the status equals
		TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested authorization
		<bcp14>MUST</bcp14> be denied.
            </t>
          </li>
          <li pn="section-6.2-3.5">
            <t indent="0" pn="section-6.2-3.5.1">TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11</t>
            <t indent="4" pn="section-6.2-3.5.2">A status of TAC_PLUS_AUTHOR_STATUS_ERROR
		indicates an error occurred on the server. For the differences
		between ERROR and FAIL, refer to "Session Completion" (<xref target="SessionCompletion" format="default" sectionFormat="of" derivedContent="Section 4.4"/>). None of
		the arg values have any relevance if an ERROR is set and must
		be ignored.
            </t>
          </li>
          <li pn="section-6.2-3.6">
            <t indent="0" pn="section-6.2-3.6.1">TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21</t>
            <t indent="4" pn="section-6.2-3.6.2">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 indent="0" pn="section-6.2-4">

server_msg, server_msg_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.2-5">
          <li pn="section-6.2-5.1">
            <t indent="0" pn="section-6.2-5.1.1">
	This is a string that may be presented to the user. The server_msg_len
	indicates the length of the server_msg field, in bytes. For details of
	text encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.2-6">
					data, data_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.2-7">
          <li pn="section-6.2-7.1">
            <t indent="0" pn="section-6.2-7.1.1">

This is a string that may be presented on an administrative display, 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 text
encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.2-8">
					arg_cnt
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.2-9">
          <li pn="section-6.2-9.1">
            <t indent="0" pn="section-6.2-9.1.1">
	This represents the number of authorization arguments to follow.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-6.2-10">
					arg_1 ... arg_N, arg_1_len .... arg_N_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-6.2-11">
          <li pn="section-6.2-11.1">
            <t indent="0" pn="section-6.2-11.1.1">
	The arguments describe the specifics of the authorization that is
	being requested. For details of the content of the args, refer to
	"Authorization Arguments" (<xref target="AuthorizationAttributes" format="default" sectionFormat="of" derivedContent="Section 8.2"/>).  Each argument is encoded in the packet as a
	single arg field (arg_1... arg_N) with a corresponding length field
	(which indicates the length of each argument in bytes).
            </t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="Accounting" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-accounting">Accounting</name>
      <t indent="0" pn="section-7-1">
	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
	and/or has done. Accounting in TACACS+ can serve two purposes: it may
	be used as an auditing tool for security services, and it may also be
	used to account for services used such as in a billing
	environment. To this end, TACACS+ supports three types of accounting
	records: Start records indicate that a service is about to begin, Stop
	records indicate that a service has just terminated, and Update
	records are intermediate notices that indicate that a service is still
	being performed. TACACS+ accounting records contain all the
	information used in the authorization records and also contain
	accounting-specific information such as start and stop times (when
	appropriate) and resource usage information. A list of accounting
	arguments is defined in "Accounting Arguments" (<xref target="AccountingAttributes" format="default" sectionFormat="of" derivedContent="Section 8.3"/>).
      </t>
      <section anchor="TheAccountREQUESTPacketBody" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-the-account-request-packet-">The Account REQUEST Packet Body</name>
        <artwork name="" type="" align="left" alt="" pn="section-7.1-1">
 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>
        <t indent="0" pn="section-7.1-2">
					flags
        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-7.1-3">
          <li pn="section-7.1-3.1">
            <t indent="0" pn="section-7.1-3.1.1">
					This holds bitmapped flags.
            </t>
          </li>
          <li pn="section-7.1-3.2">
            <t indent="0" pn="section-7.1-3.2.1">Valid values are:
</t>
          </li>
          <li pn="section-7.1-3.3">
							TAC_PLUS_ACCT_FLAG_START := 0x02
						</li>
          <li pn="section-7.1-3.4">
							TAC_PLUS_ACCT_FLAG_STOP := 0x04
						</li>
          <li pn="section-7.1-3.5">
							TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08
						</li>
        </ul>
        <t indent="0" pn="section-7.1-4">
	All other fields are defined in "Authentication" (<xref target="Authentication" format="default" sectionFormat="of" derivedContent="Section 5"/>) and "Authorization" (<xref target="Authorization" format="default" sectionFormat="of" derivedContent="Section 6"/>) 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 indent="0" pn="section-7.1-5">
	See "Accounting Arguments" (<xref target="AccountingAttributes" format="default" sectionFormat="of" derivedContent="Section 8.3"/>) for
	the dictionary of arguments relevant to accounting.
        </t>
      </section>
      <section anchor="TheAccountingREPLYPacketBody" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-the-accounting-reply-packet">The Accounting REPLY Packet Body</name>
        <t indent="0" pn="section-7.2-1">
	The purpose of accounting is to record the action that has occurred on
	the client.  The server <bcp14>MUST</bcp14> reply with success only
	when the accounting request has been recorded.  If the server did not
	record the accounting request, then it <bcp14>MUST</bcp14> reply with
	ERROR.
        </t>
        <artwork name="" type="" align="left" alt="" pn="section-7.2-2">
 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>
        <t indent="0" pn="section-7.2-3">
	status
        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-7.2-4">
          <li pn="section-7.2-4.1">
            <t indent="0" pn="section-7.2-4.1.1">
					This is the return status. 
</t>
          </li>
          <li pn="section-7.2-4.2">
            <t indent="0" pn="section-7.2-4.2.1">
Values are:
            </t>
          </li>
          <li pn="section-7.2-4.3">
							TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01
						</li>
          <li pn="section-7.2-4.4">
							TAC_PLUS_ACCT_STATUS_ERROR :=
							0x02
						</li>
          <li pn="section-7.2-4.5">
            <t indent="0" pn="section-7.2-4.5.1">TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21</t>
            <t indent="4" pn="section-7.2-4.5.2">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>
          </li>
        </ul>
        <t indent="0" pn="section-7.2-5">
	server_msg, server_msg_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-7.2-6">
          <li pn="section-7.2-6.1">
            <t indent="0" pn="section-7.2-6.1.1">
	This is a string that may be presented to the user. The server_msg_len
	indicates the length of the server_msg field, in bytes. For details of
	text encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-7.2-7">
					data, data_len
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-7.2-8">
          <li pn="section-7.2-8.1">
            <t indent="0" pn="section-7.2-8.1.1">
	This is a string that may be presented on an administrative display,
	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 text encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-7.2-9">
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="THE-DRAFT" format="default" sectionFormat="of" derivedContent="THE-DRAFT"/> as "tasks".
        </t>
        <t indent="0" pn="section-7.2-10">
	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>
        <table anchor="accounting-packets" align="center" pn="table-2">
          <name slugifiedName="name-summary-of-accounting-packe">Summary of Accounting Packets</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Watchdog</th>
              <th align="left" colspan="1" rowspan="1">Stop</th>
              <th align="left" colspan="1" rowspan="1">Start</th>
              <th align="left" colspan="1" rowspan="1">Flags &amp; 0xE</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">INVALID</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">2</td>
              <td align="left" colspan="1" rowspan="1">Start Accounting Record</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">Stop Accounting Record</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">6</td>
              <td align="left" colspan="1" rowspan="1">INVALID</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">8</td>
              <td align="left" colspan="1" rowspan="1">Watchdog, no update</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">A</td>
              <td align="left" colspan="1" rowspan="1">Watchdog, with update</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">C</td>
              <td align="left" colspan="1" rowspan="1">INVALID</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">E</td>
              <td align="left" colspan="1" rowspan="1">INVALID</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-7.2-12">
					The START and STOP flags are mutually
					exclusive.
        </t>
        <t indent="0" pn="section-7.2-13">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 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
        <bcp14>MUST</bcp14> ignore any arguments). The STOP flag <bcp14>MUST NOT</bcp14> be set in conjunction with the WATCHDOG flag.
        </t>
        <t indent="0" pn="section-7.2-14">
					The server <bcp14>MUST</bcp14> respond
					with TAC_PLUS_ACCT_STATUS_ERROR if the
					client requests an INVALID option.
        </t>
      </section>
    </section>
    <section anchor="AttributeValuePairs" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-argument-value-pairs">Argument-Value Pairs</name>
      <t indent="0" pn="section-8-1">
				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
				<bcp14>MUST</bcp14> use these arguments when
				supporting the corresponding use cases.
      </t>
      <section anchor="ValueEncoding" numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-value-encoding">Value Encoding</name>
        <t indent="0" pn="section-8.1-1">
	All argument values are encoded as strings. For details of text
	encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).  The
	following type representations <bcp14>SHOULD</bcp14> be followed.
        </t>
        <t indent="0" pn="section-8.1-2">Numeric</t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.1-3">
          <li pn="section-8.1-3.1">
            <t indent="0" pn="section-8.1-3.1.1">
	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 <bcp14>MUST</bcp14> verify that
	they can accommodate the lengths of numeric arguments before
	attempting to process them.  If the length cannot be accommodated, then
	the argument <bcp14>MUST</bcp14> be regarded as not handled and the
	logic in "Authorization" (<xref target="TheAuthorizationREQUESTPacketBody" format="default" sectionFormat="of" derivedContent="Section 6.1"/>) regarding the processing
	of arguments <bcp14>MUST</bcp14> be applied.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.1-4">Boolean</t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.1-5">
          <li pn="section-8.1-5.1">
            <t indent="0" pn="section-8.1-5.1.1">
					All Boolean arguments are encoded with
					values "true" or "false".

            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.1-6">IP-Address</t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.1-7">
          <li pn="section-8.1-7.1">
            <t indent="0" pn="section-8.1-7.1.1">
It is recommended that hosts be specified as an IP address so as to avoid any
ambiguities. For details of text encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>). IPv4 addresses are specified as octet numerics separated by
dots ('.'). IPv6 address text representation is defined in <xref target="RFC5952" format="default" sectionFormat="of" derivedContent="RFC5952"/>.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.1-8">Date Time</t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.1-9">
          <li pn="section-8.1-9.1">
            <t indent="0" pn="section-8.1-9.1.1">
	Absolute date/times are specified in seconds since the epoch, 12:00am,
	January 1, 1970. The time zone <bcp14>MUST</bcp14> be UTC
	unless a time zone
	argument is specified.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.1-10">String</t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.1-11">
          <li pn="section-8.1-11.1">
            <t indent="0" pn="section-8.1-11.1.1">Many values have no specific type representation and are
        interpreted as plain strings.</t>
          </li>
        </ul>
        <t indent="0" pn="section-8.1-12">Empty Values</t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.1-13">
          <li pn="section-8.1-13.1">
            <t indent="0" pn="section-8.1-13.1.1">
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",
which has no value, is transmitted as a string of four characters "cmd=".
            </t>
          </li>
        </ul>
      </section>
      <section anchor="AuthorizationAttributes" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-authorization-arguments">Authorization Arguments</name>
        <t indent="0" pn="section-8.2-1">
					service (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-2">
          <li pn="section-8.2-2.1">
            <t indent="0" pn="section-8.2-2.1.1">
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"; others may be
chosen for the required application. This argument <bcp14>MUST</bcp14> always
be included.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-3">
					protocol (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-4">
          <li pn="section-8.2-4.1">
            <t indent="0" pn="section-8.2-4.1.1">A field that may be used to indicate a subset of a service.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-5">
					cmd (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-6">
          <li pn="section-8.2-6.1">
            <t indent="0" pn="section-8.2-6.1.1">
A shell (exec) command. This indicates the command name of the command that is
to be run. The "cmd" argument <bcp14>MUST</bcp14> be specified if service
equals "shell".
            </t>
          </li>
          <li pn="section-8.2-6.2">
            <t indent="0" pn="section-8.2-6.2.1">Authorization of shell commands is a common use case for the
        TACACS+ protocol. Command Authorization generally takes one of two
        forms: session based or command based.
            </t>
          </li>
          <li pn="section-8.2-6.3">
            <t indent="0" pn="section-8.2-6.3.1">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 pn="section-8.2-6.4">
            <t indent="0" pn="section-8.2-6.4.1">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 indent="0" pn="section-8.2-7">
					cmd-arg (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-8">
          <li pn="section-8.2-8.1">
            <t indent="0" pn="section-8.2-8.1.1">
	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 indent="0" pn="section-8.2-9">
					acl (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-10">
          <li pn="section-8.2-10.1">
            <t indent="0" pn="section-8.2-10.1.1">
A number representing a connection access list.  Applicable only to
session-based shell authorization. For details of text encoding, see
"Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-11">
					inacl (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-12">
          <li pn="section-8.2-12.1">
            <t indent="0" pn="section-8.2-12.1.1">
The identifier (name) of an interface input access list. For details of text
encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-13">
					outacl (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-14">
          <li pn="section-8.2-14.1">
            <t indent="0" pn="section-8.2-14.1.1">
The identifier (name) of an interface output access list. For details of text
encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-15">
					addr (IP-Address)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-16">
          <li pn="section-8.2-16.1">
            <t indent="0" pn="section-8.2-16.1.1">
		A network address.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-17">
					addr-pool (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-18">
          <li pn="section-8.2-18.1">
            <t indent="0" pn="section-8.2-18.1.1">
	The identifier of an address pool from which the client can assign an
	address.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-19">
					timeout (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-20">
          <li pn="section-8.2-20.1">
            <t indent="0" pn="section-8.2-20.1.1">
	An absolute timer for the connection (in minutes). A value of zero
	indicates no timeout.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-21">
					idletime (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-22">
          <li pn="section-8.2-22.1">
            <t indent="0" pn="section-8.2-22.1.1">
	An idle-timeout for the connection (in minutes). A value of zero
	indicates no timeout.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-23">
					autocmd (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-24">
          <li pn="section-8.2-24.1">
            <t indent="0" pn="section-8.2-24.1.1">
An auto-command to run. Applicable only to session-based shell authorization.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-25">
					noescape (Boolean)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-26">
          <li pn="section-8.2-26.1">
            <t indent="0" pn="section-8.2-26.1.1">
	Prevents the user from using an escape character. Applicable only to
	session-based shell authorization.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-27">
					nohangup (Boolean)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-28">
          <li pn="section-8.2-28.1">
            <t indent="0" pn="section-8.2-28.1.1">
	Boolean. Do not disconnect after an automatic command.  Applicable
	only to session-based shell authorization.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.2-29">
					priv-lvl (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-30">
          <li pn="section-8.2-30.1">
            <t indent="0" pn="section-8.2-30.1.1">
The privilege level to be assigned. Please refer to "Privilege Levels" (<xref target="PrivilegeLevel" format="default" sectionFormat="of" derivedContent="Section 9"/>).
            </t>
          </li>
        </ul>
      </section>
      <section anchor="AccountingAttributes" numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-accounting-arguments">Accounting Arguments</name>
        <t indent="0" pn="section-8.3-1">
	The following arguments are defined for TACACS+ accounting only.  They
	<bcp14>MUST</bcp14> precede any argument-value pairs that are defined
	in "Authorization" (<xref target="Authorization" format="default" sectionFormat="of" derivedContent="Section 6"/>).
        </t>
        <t indent="0" pn="section-8.3-2">
					task_id (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-3">
          <li pn="section-8.3-3.1">
            <t indent="0" pn="section-8.3-3.1.1">
	Start and stop records for the same event <bcp14>MUST</bcp14> have
	matching task_id argument values. The client <bcp14>MUST</bcp14>
	ensure that active task_ids are not duplicated; a client <bcp14>MUST NOT</bcp14> reuse a task_id in a start record until it has sent a stop
	record for that task_id.  Servers <bcp14>MUST NOT</bcp14> make
	assumptions about the format of a task_id.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-4">
					start_time (Date Time)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-5">
          <li pn="section-8.3-5.1">
            <t indent="0" pn="section-8.3-5.1.1">
	The time the action started (in seconds since the epoch).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-6">
					stop_time (Date Time)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-7">
          <li pn="section-8.3-7.1">
            <t indent="0" pn="section-8.3-7.1.1">
	The time the action stopped (in seconds since the epoch).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-8">
					elapsed_time (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-9">
          <li pn="section-8.3-9.1">
            <t indent="0" pn="section-8.3-9.1.1">
					The elapsed time in seconds for the action.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-10">
					timezone (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-11">
          <li pn="section-8.3-11.1">
            <t indent="0" pn="section-8.3-11.1.1">
The time zone abbreviation for all timestamps included in this packet. A
database of time zones is maintained in <xref target="TZDB" format="default" sectionFormat="of" derivedContent="TZDB">TZDB</xref>.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-12">
					event (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-13">
          <li pn="section-8.3-13.1">
            <t indent="0" pn="section-8.3-13.1.1">
Used only when "service=system". Current values are "net_acct", "cmd_acct",
"conn_acct", "shell_acct", "sys_acct", and "clock_change".  These indicate
system-level changes.  The flags field <bcp14>SHOULD</bcp14> indicate whether
the service started or stopped.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-14">
					reason (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-15">
          <li pn="section-8.3-15.1">
            <t indent="0" pn="section-8.3-15.1.1">
Accompanies an event argument. It describes why the event occurred.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-16">
					bytes (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-17">
          <li pn="section-8.3-17.1">
            <t indent="0" pn="section-8.3-17.1.1">
	The number of bytes transferred by this action.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-18">
					bytes_in (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-19">
          <li pn="section-8.3-19.1">
            <t indent="0" pn="section-8.3-19.1.1">
	The number of bytes transferred by this action from the endstation to
	the client port.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-20">
					bytes_out (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-21">
          <li pn="section-8.3-21.1">
            <t indent="0" pn="section-8.3-21.1.1">
		The number of bytes transferred by this action from the client
		to the endstation port.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-22">
					paks (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-23">
          <li pn="section-8.3-23.1">
            <t indent="0" pn="section-8.3-23.1.1">
					The number of packets transferred by this action.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-24">
					paks_in (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-25">
          <li pn="section-8.3-25.1">
            <t indent="0" pn="section-8.3-25.1.1">
The number of input packets transferred by this action from the endstation to
the client port.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-26">
					paks_out (Numeric)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-27">
          <li pn="section-8.3-27.1">
            <t indent="0" pn="section-8.3-27.1.1">
The number of output packets transferred by this action from the client port
to the endstation.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-28">
					err_msg (String)
        </t>
        <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.3-29">
          <li pn="section-8.3-29.1">
            <t indent="0" pn="section-8.3-29.1.1">
	A string describing the status of the action. For details of text
	encoding, see "Treatment of Text Strings" (<xref target="TextEncoding" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-8.3-30">Where the TACACS+ deployment is used 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" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.
</t>
      </section>
    </section>
    <section anchor="PrivilegeLevel" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-privilege-levels">Privilege Levels</name>
      <t indent="0" pn="section-9-1">
				The TACACS+ protocol supports flexible
				authorization schemes through the extensible
				arguments.
      </t>
      <t indent="0" pn="section-9-2"> The privilege levels scheme is built into the protocol and has been
extensively used as an option for Session-based shell authorization.

Privilege 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 specific commands)
to different privilege levels.  The allocation of commands to privilege levels
is highly dependent upon the deployment. Common allocations are as follows:
      </t>
      <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-9-3">
        <li pn="section-9-3.1">
						TAC_PLUS_PRIV_LVL_MIN :=
						0x00. The level normally
						allocated to an
						unauthenticated session.
					</li>
        <li pn="section-9-3.2">
						TAC_PLUS_PRIV_LVL_USER :=
						0x01. The level normally
						allocated to a regular
						authenticated session.
					</li>
        <li pn="section-9-3.3">
						TAC_PLUS_PRIV_LVL_ROOT :=
						0x0f. The level normally
						allocated to a session
						authenticated by a highly
						privileged user to allow
						commands with significant
						system impact.
					</li>
        <li pn="section-9-3.4">
						TAC_PLUS_PRIV_LVL_MAX :=
						0x0f. The highest privilege
						level.
					</li>
      </ul>
      <t indent="0" pn="section-9-4">
	
A privilege level can be assigned to a shell (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 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, an ENABLE-type reauthentication can be initiated by the client.
The client will insert the required privilege level into the authentication
header for ENABLE authentication requests.
      </t>
      <t indent="0" pn="section-9-5">
	The use of privilege levels to determine session-based access to
	commands and resources is not mandatory for clients. Although the
	privilege-level scheme is widely supported, its 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 <bcp14>SHOULD</bcp14> be supported by
	servers.
      </t>
    </section>
    <section anchor="TACACSSecurity" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-10-1">
 "The Draft" <xref target="THE-DRAFT" format="default" sectionFormat="of" derivedContent="THE-DRAFT"/> from 1998 did not address all of the key security concerns
that are considered when designing modern standards. This section addresses
known limitations and concerns that will impact overall security of the
protocol and systems where this protocol is deployed to manage central
authentication, authorization, or accounting for network Device
Administration.
 
      </t>
      <t indent="0" pn="section-10-2">

	Multiple implementations of the protocol described in
 "The Draft" <xref target="THE-DRAFT" format="default" sectionFormat="of" derivedContent="THE-DRAFT"/>
	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" numbered="true" toc="include" removeInRFC="false" pn="section-10.1">
        <name slugifiedName="name-general-security-of-the-pro">General Security of the Protocol</name>
        <t indent="0" pn="section-10.1-1">
	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" and not "encryption", since they provide
	no meaningful integrity, privacy, or replay protection. An attacker
	with access to the data stream should be assumed to be able to read
	and modify all TACACS+ packets.  Without mitigation, a range of risks
	such as the following are possible:
        </t>
        <ul empty="false" spacing="normal" bare="false" indent="3" pn="section-10.1-2">
          <li pn="section-10.1-2.1">
	Accounting information may be modified by the man-in-the-middle
	attacker, making such logs unsuitable and not trustable for auditing
	purposes.
						</li>
          <li pn="section-10.1-2.2">
	Invalid or misleading values may be inserted by the man-in-the-middle
	attacker in various fields at known offsets to try and circumvent the
	authentication or authorization checks even inside the obfuscated
	body.
						</li>
        </ul>
        <t indent="0" pn="section-10.1-3">
While the protocol provides some measure of transport privacy, it is
vulnerable to at least the following attacks:
        </t>
        <ul empty="false" spacing="normal" bare="false" indent="3" pn="section-10.1-4">
          <li pn="section-10.1-4.1">
Brute-force attacks exploiting increased efficiency of MD5 digest computation.
						</li>
          <li pn="section-10.1-4.2">
	Known plaintext attacks that may decrease the cost of brute-force
	attacks.
						</li>
          <li pn="section-10.1-4.3">
	Chosen plaintext attacks that may decrease the cost of a brute-force
	attacks.
						</li>
          <li pn="section-10.1-4.4">
No forward secrecy.
						</li>
        </ul>
        <t indent="0" pn="section-10.1-5">
Even though, to the best knowledge of the authors, this method of encryption
wasn't rigorously tested, enough information is available that it is best
referred to as "obfuscation" and not "encryption".
        </t>
        <t indent="0" pn="section-10.1-6">
	For these reasons, users deploying the TACACS+ protocol in their
	environments <bcp14>MUST</bcp14> limit access to known clients and
	<bcp14>MUST</bcp14> control the security of the entire transmission
	path. Attackers who can guess the key or otherwise break the
	obfuscation will gain unrestricted and undetected access to all
	TACACS+ traffic. Ensuring that a centralized AAA system like TACACS+
	is deployed on a secured transport is essential to managing the
	security risk of such an attack.
        </t>
        <t indent="0" pn="section-10.1-7">
					The following parts of this section
					enumerate only the session-specific
					risks that are in addition to general
					risk associated with bare obfuscation
					and lack of integrity checking.

        </t>
      </section>
      <section anchor="SecurityofAuthenticationSessions" numbered="true" toc="include" removeInRFC="false" pn="section-10.2">
        <name slugifiedName="name-security-of-authentication-">Security of Authentication Sessions</name>
        <t indent="0" pn="section-10.2-1">
	Authentication sessions <bcp14>SHOULD</bcp14> be used via a secure
	transport (see "TACACS+ Best Practices" (<xref target="Bestpractices" format="default" sectionFormat="of" derivedContent="Section 10.5"/>)) 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 indent="0" pn="section-10.2-2">
This document deprecates the redirection mechanism using the
TAC_PLUS_AUTHEN_STATUS_FOLLOW option, which was included in "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.  This mechanism <bcp14>MUST NOT</bcp14> be used in modern
deployments. It <bcp14>MUST NOT</bcp14> be used outside a secured deployment.
        </t>
      </section>
      <section anchor="SecurityofAuthorizationSessions" numbered="true" toc="include" removeInRFC="false" pn="section-10.3">
        <name slugifiedName="name-security-of-authorization-s">Security of Authorization Sessions</name>
        <t indent="0" pn="section-10.3-1">
	Authorization sessions <bcp14>SHOULD</bcp14> be used via a secure
	transport (see "TACACS+ Best Practices" (<xref target="Bestpractices" format="default" sectionFormat="of" derivedContent="Section 10.5"/>)) as it's trivial to execute a successful
	man-in-the-middle attack that changes well-known plaintext in either
	requests or responses.
        </t>
        <t indent="0" pn="section-10.3-2">
	As an example, take the field "authen_method". It's not unusual in
	actual deployments to authorize all commands received via the device
	local serial port (a console 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" from
	TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In this
	regard, the obfuscation provided by the protocol itself wouldn't help
	much, because:
        </t>
        <ul empty="false" spacing="normal" bare="false" indent="3" pn="section-10.3-3">
          <li pn="section-10.3-3.1">
	A lack of integrity means that any byte in the payload may be changed
	without either side detecting the change.
						</li>
          <li pn="section-10.3-3.2">
	Known plaintext means that an attacker would know with certainty which
	octet is the target of the attack (in this case, first octet after the
	header).
						</li>
          <li pn="section-10.3-3.3">
	In combination with known plaintext, the attacker can determine with
	certainty the value of the crypto-pad octet used to obfuscate the
	original octet.

						</li>
        </ul>
      </section>
      <section anchor="SecurityofAccountingSessions" numbered="true" toc="include" removeInRFC="false" pn="section-10.4">
        <name slugifiedName="name-security-of-accounting-sess">Security of Accounting Sessions</name>
        <t indent="0" pn="section-10.4-1">Accounting sessions <bcp14>SHOULD</bcp14> be used via a secure
        transport (see "TACACS+ Best Practices" (<xref target="Bestpractices" format="default" sectionFormat="of" derivedContent="Section 10.5"/>)). Although Accounting sessions are not
        directly involved in authentication or authorizing operations on the
        device, man-in-the-middle attackers may do any of the following:
        </t>
        <ul empty="false" spacing="normal" bare="false" indent="3" pn="section-10.4-2">
          <li pn="section-10.4-2.1">
	    
	Replace accounting data with new valid values or garbage that can confuse
	auditors or hide information related to their authentication and/or
	authorization attack attempts.
						</li>
          <li pn="section-10.4-2.2">
						  
	Try and poison an accounting log with entries designed to make systems
	behave in unintended ways (these systems could be TACACS+ servers and any other
	systems that would manage accounting entries).
						</li>
        </ul>
        <t indent="0" pn="section-10.4-3">
	In addition to these direct manipulations, different client
	implementations pass a different fidelity of accounting data. Some
	vendors have been observed in the wild that pass sensitive data like
	passwords, encryption keys, and the like as part of the accounting log.
	Due to a lack of strong encryption with perfect forward secrecy, this
	data may be revealed in the future, leading to a security incident.

        </t>
      </section>
      <section anchor="Bestpractices" numbered="true" toc="include" removeInRFC="false" pn="section-10.5">
        <name slugifiedName="name-tacacs-best-practices">TACACS+ Best Practices</name>
        <t indent="0" pn="section-10.5-1">With respect to the observations about the security issues
        described above, a network administrator <bcp14>MUST NOT</bcp14>
        rely on the obfuscation of the TACACS+ protocol. TACACS+
        <bcp14>MUST</bcp14> be used within a secure deployment; TACACS+
        <bcp14>MUST</bcp14> be deployed over networks that ensure privacy and
        integrity of the communication and <bcp14>MUST</bcp14> be deployed
        over a network that is separated from other traffic.  Failure to do
        so will impact overall network security.</t>
        <t indent="0" pn="section-10.5-2">The following recommendations impose restrictions on how the
        protocol is applied. These restrictions were not imposed in "The
        Draft". New implementations, and upgrades of current implementations,
        <bcp14>MUST</bcp14> implement these recommendations. Vendors
        <bcp14>SHOULD</bcp14> provide mechanisms to assist the administrator
        to achieve these best practices.</t>
        <section anchor="SharedSecrets" numbered="true" toc="include" removeInRFC="false" pn="section-10.5.1">
          <name slugifiedName="name-shared-secrets">Shared Secrets</name>
          <t indent="0" pn="section-10.5.1-1">TACACS+ servers and clients <bcp14>MUST</bcp14> treat shared
          secrets as sensitive data to be managed securely, as would be
          expected for other sensitive data such as identity credential
          information.  TACACS+ servers <bcp14>MUST NOT</bcp14> leak sensitive
          data. 
</t>
          <t indent="0" pn="section-10.5.1-2">
For example:
</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-10.5.1-3">
            <li pn="section-10.5.1-3.1">
              <t indent="0" pn="section-10.5.1-3.1.1"> TACACS+ servers <bcp14>MUST NOT</bcp14> expose shared secrets in
logs.
              </t>
            </li>
            <li pn="section-10.5.1-3.2">
              <t indent="0" pn="section-10.5.1-3.2.1">TACACS+ servers <bcp14>MUST</bcp14> allow a dedicated secret key to be defined
						for each client.
              </t>
            </li>
            <li pn="section-10.5.1-3.3">
              <t indent="0" pn="section-10.5.1-3.3.1">TACACS+ server management systems <bcp14>MUST</bcp14> provide a
          mechanism to track secret key lifetimes and notify administrators to
          update them periodically. TACACS+ server administrators
          <bcp14>SHOULD</bcp14> change secret keys at regular intervals. </t>
            </li>
            <li pn="section-10.5.1-3.4">
              <t indent="0" pn="section-10.5.1-3.4.1">TACACS+ servers <bcp14>SHOULD</bcp14> warn administrators if
          secret keys are not unique per client.</t>
            </li>
            <li pn="section-10.5.1-3.5">
              <t indent="0" pn="section-10.5.1-3.5.1">TACACS+ server administrators <bcp14>SHOULD</bcp14> always define
          a secret for each client.</t>
            </li>
            <li pn="section-10.5.1-3.6">
              <t indent="0" pn="section-10.5.1-3.6.1">TACACS+ servers and clients <bcp14>MUST</bcp14> support shared keys that are at
						least 32 characters long.
              </t>
            </li>
            <li pn="section-10.5.1-3.7">
              <t indent="0" pn="section-10.5.1-3.7.1">TACACS+ servers <bcp14>MUST</bcp14> support policy to define
          minimum complexity for shared keys.
              </t>
            </li>
            <li pn="section-10.5.1-3.8">
              <t indent="0" pn="section-10.5.1-3.8.1">TACACS+ clients <bcp14>SHOULD NOT</bcp14> allow servers to be
          configured without a shared secret key or shared key that is less
          than 16 characters long.</t>
            </li>
            <li pn="section-10.5.1-3.9">
              <t indent="0" pn="section-10.5.1-3.9.1">TACACS+ server administrators <bcp14>SHOULD</bcp14> configure
          secret keys of a minimum of 16 characters in length.</t>
            </li>
          </ul>
        </section>
        <section anchor="Connections" numbered="true" toc="include" removeInRFC="false" pn="section-10.5.2">
          <name slugifiedName="name-connections-and-obfuscation">Connections and Obfuscation</name>
          <t indent="0" pn="section-10.5.2-1">TACACS+ servers <bcp14>MUST</bcp14> allow the definition of
          individual clients.  The servers <bcp14>MUST</bcp14> only accept
          network connection attempts from these defined known clients.</t>
          <t indent="0" pn="section-10.5.2-2">TACACS+ servers <bcp14>MUST</bcp14> reject connections
	  that have
          TAC_PLUS_UNENCRYPTED_FLAG set. There <bcp14>MUST</bcp14> always be a
          shared secret set on the server for the client requesting the
          connection.</t>
          <t indent="0" pn="section-10.5.2-3">If an invalid shared secret is detected when processing packets
          for a client, TACACS+ servers <bcp14>MUST NOT</bcp14> accept any new
          sessions on that connection. TACACS+ servers <bcp14>MUST</bcp14>
          terminate the connection on completion of any sessions that were
          previously established with a valid shared secret on that
          connection.</t>
          <t indent="0" pn="section-10.5.2-4">TACACS+ clients <bcp14>MUST NOT</bcp14> set
          TAC_PLUS_UNENCRYPTED_FLAG. Clients <bcp14>MUST</bcp14> be
          implemented in a way that requires explicit configuration to enable
          the use of TAC_PLUS_UNENCRYPTED_FLAG. This option <bcp14>MUST NOT</bcp14> be used when the client is in production.</t>
          <t indent="0" pn="section-10.5.2-5">When a TACACS+ client receives responses from servers where:</t>
          <ul empty="false" spacing="normal" bare="false" indent="3" pn="section-10.5.2-6">
            <li pn="section-10.5.2-6.1">the response packet was received from the server configured
            with a shared key, but the packet has TAC_PLUS_UNENCRYPTED_FLAG
	    set, and

							</li>
            <li pn="section-10.5.2-6.2">the response packet was received from the server configured
            not to use obfuscation, but the packet has
            TAC_PLUS_UNENCRYPTED_FLAG not set,

							</li>
          </ul>
          <t indent="0" pn="section-10.5.2-7">the TACACS+ client <bcp14>MUST</bcp14> close the TCP
          session, and process the response in the same way that a
          TAC_PLUS_AUTHEN_STATUS_FAIL (authentication sessions) or
          TAC_PLUS_AUTHOR_STATUS_FAIL (authorization sessions) was
          received.</t>
        </section>
        <section anchor="AuthenticationRecommendations" numbered="true" toc="include" removeInRFC="false" pn="section-10.5.3">
          <name slugifiedName="name-authentication-2">Authentication</name>
          <t indent="0" pn="section-10.5.3-1">To help TACACS+ administrators select stronger authentication
          options, TACACS+ servers <bcp14>MUST</bcp14> allow the administrator
          to configure the server to only accept challenge/response options
          for authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or
          TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for
          authen_type).</t>
          <t indent="0" pn="section-10.5.3-2">TACACS+ server administrators <bcp14>SHOULD</bcp14> enable the
          option mentioned in the previous paragraph.

	  TACACS+ server deployments <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 indent="0" pn="section-10.5.3-3">TACACS+ server administrators <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 authen_type
          options, as the insecurity of the latter will compromise the security
          of the former.</t>
          <t indent="0" pn="section-10.5.3-4">TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options
          mentioned in "The Draft" <bcp14>SHOULD NOT</bcp14> be used due to their security implications. TACACS+
          servers <bcp14>SHOULD NOT</bcp14> implement them.  If they must be
          implemented, the servers <bcp14>MUST</bcp14> default to the options
          being disabled and <bcp14>MUST</bcp14> warn the administrator that
          these options are not secure.</t>
        </section>
        <section anchor="AuthorizationRecommendations" numbered="true" toc="include" removeInRFC="false" pn="section-10.5.4">
          <name slugifiedName="name-authorization-2">Authorization</name>
          <t indent="0" pn="section-10.5.4-1">The authorization and accounting features are intended to provide
          extensibility and flexibility. There is a base dictionary defined in
          this document, but it may be extended in deployments by using new
          argument names. The cost of the flexibility is that administrators
          and implementers <bcp14>MUST</bcp14> ensure that the argument and
          value pairs shared between the clients and servers have consistent
          interpretation.</t>
          <t indent="0" pn="section-10.5.4-2">TACACS+ clients that receive an unrecognized mandatory argument
          <bcp14>MUST</bcp14> evaluate server response as if they received
          TAC_PLUS_AUTHOR_STATUS_FAIL.</t>
        </section>
        <section anchor="RedirectionMechanism" numbered="true" toc="include" removeInRFC="false" pn="section-10.5.5">
          <name slugifiedName="name-redirection-mechanism">Redirection Mechanism</name>
          <t indent="0" pn="section-10.5.5-1">"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 indent="0" pn="section-10.5.5-2">TACACS+ servers <bcp14>MUST</bcp14> deprecate the redirection mechanism.</t>
          <t indent="0" pn="section-10.5.5-3">If the redirection mechanism is implemented, then TACACS+ servers
          <bcp14>MUST</bcp14> disable it by default and <bcp14>MUST</bcp14>
          warn TACACS+ server administrators that it must only be enabled
          within a secure deployment due to the risks of revealing shared
          secrets.</t>
          <t indent="0" pn="section-10.5.5-4">TACACS+ clients <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" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-11-1">This document has no IANA actions.
      </t>
    </section>
  </middle>
  <back>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC0020" target="https://www.rfc-editor.org/info/rfc20" quoteTitle="true" derivedAnchor="RFC0020">
          <front>
            <title>ASCII format for network interchange</title>
            <author initials="V.G." surname="Cerf" fullname="V.G. Cerf">
              <organization showOnFrontPage="true"/>
            </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" target="https://www.rfc-editor.org/info/rfc1321" quoteTitle="true" derivedAnchor="RFC1321">
          <front>
            <title>The MD5 Message-Digest Algorithm</title>
            <author initials="R." surname="Rivest" fullname="R. Rivest">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1992" month="April"/>
            <abstract>
              <t indent="0">This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input.  This memo provides information for the Internet community.  It does not specify an Internet standard.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1321"/>
          <seriesInfo name="DOI" value="10.17487/RFC1321"/>
        </reference>
        <reference anchor="RFC1334" target="https://www.rfc-editor.org/info/rfc1334" quoteTitle="true" derivedAnchor="RFC1334">
          <front>
            <title>PPP Authentication Protocols</title>
            <author initials="B." surname="Lloyd" fullname="B. Lloyd">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Simpson" fullname="W. Simpson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1992" month="October"/>
            <abstract>
              <t indent="0">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"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">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="https://www.rfc-editor.org/info/rfc2433" quoteTitle="true" derivedAnchor="RFC2433">
          <front>
            <title>Microsoft PPP CHAP Extensions</title>
            <author initials="G." surname="Zorn" fullname="G. Zorn">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Cobb" fullname="S. Cobb">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1998" month="October"/>
            <abstract>
              <t indent="0">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"/>
        </reference>
        <reference anchor="RFC2759" target="https://www.rfc-editor.org/info/rfc2759" quoteTitle="true" derivedAnchor="RFC2759">
          <front>
            <title>Microsoft PPP CHAP Extensions, Version 2</title>
            <author initials="G." surname="Zorn" fullname="G. Zorn">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="January"/>
            <abstract>
              <t indent="0">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"/>
        </reference>
        <reference anchor="RFC3579" target="https://www.rfc-editor.org/info/rfc3579" quoteTitle="true" derivedAnchor="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 showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Calhoun" fullname="P. Calhoun">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="September"/>
            <abstract>
              <t indent="0">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="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schiller" fullname="J. Schiller">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Crocker" fullname="S. Crocker">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="June"/>
            <abstract>
              <t indent="0">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.</t>
              <t indent="0">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="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC4120" target="https://www.rfc-editor.org/info/rfc4120" quoteTitle="true" derivedAnchor="RFC4120">
          <front>
            <title>The Kerberos Network Authentication Service (V5)</title>
            <author initials="C." surname="Neuman" fullname="C. Neuman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Yu" fullname="T. Yu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Hartman" fullname="S. Hartman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Raeburn" fullname="K. Raeburn">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="July"/>
            <abstract>
              <t indent="0">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" quoteTitle="true" derivedAnchor="RFC5952">
          <front>
            <title>A Recommendation for IPv6 Address Text Representation</title>
            <author initials="S." surname="Kawamura" fullname="S. Kawamura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Kawashima" fullname="M. Kawashima">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="August"/>
            <abstract>
              <t indent="0">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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8265" target="https://www.rfc-editor.org/info/rfc8265" quoteTitle="true" derivedAnchor="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 showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Melnikov" fullname="A. Melnikov">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="October"/>
            <abstract>
              <t indent="0">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 pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="KRB4" quoteTitle="true" derivedAnchor="KRB4">
          <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>
        <reference anchor="THE-DRAFT" target="https://tools.ietf.org/html/draft-grant-tacacs-02" quoteTitle="true" derivedAnchor="THE-DRAFT">
          <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"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="TZDB" target="https://www.iana.org/time-zones" quoteTitle="true" derivedAnchor="TZDB">
          <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>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank the following reviewers whose
      comments and contributions made considerable improvements to this
      document: <contact fullname="Alan DeKok"/>, <contact fullname="Alexander       Clouter"/>, <contact fullname="Chris Janicki"/>, <contact fullname="Tom Petch"/>,
      <contact fullname="Robert Drake"/>, and <contact fullname="John Heasley"/>, among many others.
      </t>
      <t indent="0" pn="section-appendix.a-2">
				The authors would particularly like to thank
				<contact fullname="Alan DeKok"/>, who provided
				significant insights and recommendations on
				all aspects of the document and the
				protocol. <contact fullname="Alan DeKok"/> has
				dedicated considerable time and effort to help
				improve the document, identifying weaknesses
				and providing remediation.
      </t>
      <t indent="0" pn="section-appendix.a-3">The authors would also like to thank the support from the OPSAWG
      Chairs and advisors, especially <contact fullname="Joe Clarke"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="T." surname="Dahm" fullname="Thorsten Dahm">
        <organization showOnFrontPage="true">Google Inc.</organization>
        <address>
          <postal>
            <street>1600 Amphitheatre Parkway</street>
            <city>Mountain View</city>
            <region>CA</region>
            <code>94043</code>
            <country>United States of America</country>
          </postal>
          <phone/>
          <email>thorstendlux@google.com</email>
          <uri/>
        </address>
      </author>
      <author initials="A." surname="Ota" fullname="Andrej Ota">
        <organization showOnFrontPage="true">Google Inc.</organization>
        <address>
          <postal>
            <street>1600 Amphitheatre Parkway</street>
            <city>Mountain View</city>
            <region>CA</region>
            <code>94043</code>
            <country>United States of America</country>
          </postal>
          <phone/>
          <email>andrej@ota.si</email>
          <uri/>
        </address>
      </author>
      <author initials="D.C." surname="Medway Gash" fullname="Douglas C. Medway Gash">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street>170 West Tasman Dr.</street>
            <city>San Jose</city>
            <region>CA</region>
            <code>95134</code>
            <country>United States of America</country>
          </postal>
          <email>dcmgash@cisco.com</email>
          <uri/>
        </address>
      </author>
      <author initials="D." surname="Carrel" fullname="David Carrel">
        <organization showOnFrontPage="true">IPsec Research</organization>
        <address>
          <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>
    </section>
  </back>
</rfc>