File: rfc8907.html

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 (4571 lines) | stat: -rw-r--r-- 215,854 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8907: The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol</title>
<meta content="Thorsten Dahm" name="author">
<meta content="Andrej Ota" name="author">
<meta content="Douglas C. Medway Gash" name="author">
<meta content="David Carrel" name="author">
<meta content="Lol Grant" name="author">
<meta content="
       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.
       
    " name="description">
<meta content="xml2rfc 3.2.1" name="generator">
<meta content="TACACS+" name="keyword">
<meta content="Protocol" name="keyword">
<meta content="8907" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.2.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8907.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8907" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-18" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8907</td>
<td class="center">TACACS+</td>
<td class="right">September 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Dahm, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8907" class="eref">8907</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-09" class="published">September 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">T. Dahm</div>
<div class="org">Google Inc.</div>
</div>
<div class="author">
      <div class="author-name">A. Ota</div>
<div class="org">Google Inc.</div>
</div>
<div class="author">
      <div class="author-name">D.C. Medway Gash</div>
<div class="org">Cisco Systems, Inc.</div>
</div>
<div class="author">
      <div class="author-name">D. Carrel</div>
<div class="org">IPsec Research</div>
</div>
<div class="author">
      <div class="author-name">L. Grant</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8907</h1>
<h1 id="title">The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="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.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="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
            <span><a href="https://www.rfc-editor.org/info/rfc8907">https://www.rfc-editor.org/info/rfc8907</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-boilerplate.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions" class="xref">Conventions</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-technical-definitions" class="xref">Technical Definitions</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-client" class="xref">Client</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-server" class="xref">Server</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-packet" class="xref">Packet</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-connection" class="xref">Connection</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-session" class="xref">Session</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-treatment-of-enumerated-pro" class="xref">Treatment of Enumerated Protocol Values</a><a href="#section-toc.1-1.3.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.7">
                <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-treatment-of-text-strings" class="xref">Treatment of Text Strings</a><a href="#section-toc.1-1.3.2.7.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-tacacs-packets-and-sessions" class="xref">TACACS+ Packets and Sessions</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-the-tacacs-packet-header" class="xref">The TACACS+ Packet Header</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-the-tacacs-packet-body" class="xref">The TACACS+ Packet Body</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-single-connection-mode" class="xref">Single Connection Mode</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-session-completion" class="xref">Session Completion</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-data-obfuscation" class="xref">Data Obfuscation</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-authentication" class="xref">Authentication</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-the-authentication-start-pa" class="xref">The Authentication START Packet Body</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-the-authentication-reply-pa" class="xref">The Authentication REPLY Packet Body</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-the-authentication-continue" class="xref">The Authentication CONTINUE Packet Body</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-description-of-authenticati" class="xref">Description of Authentication Process</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4.2.1">
                    <p id="section-toc.1-1.5.2.4.2.1.1"><a href="#section-5.4.1" class="xref">5.4.1</a>.  <a href="#name-version-behavior" class="xref">Version Behavior</a><a href="#section-toc.1-1.5.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4.2.2">
                    <p id="section-toc.1-1.5.2.4.2.2.1"><a href="#section-5.4.2" class="xref">5.4.2</a>.  <a href="#name-common-authentication-flows" class="xref">Common Authentication Flows</a><a href="#section-toc.1-1.5.2.4.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4.2.3">
                    <p id="section-toc.1-1.5.2.4.2.3.1"><a href="#section-5.4.3" class="xref">5.4.3</a>.  <a href="#name-aborting-an-authentication-" class="xref">Aborting an Authentication Session</a><a href="#section-toc.1-1.5.2.4.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-authorization" class="xref">Authorization</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-the-authorization-request-p" class="xref">The Authorization REQUEST Packet Body</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-the-authorization-reply-pac" class="xref">The Authorization REPLY Packet Body</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-accounting" class="xref">Accounting</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-the-account-request-packet-" class="xref">The Account REQUEST Packet Body</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-the-accounting-reply-packet" class="xref">The Accounting REPLY Packet Body</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-argument-value-pairs" class="xref">Argument-Value Pairs</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-value-encoding" class="xref">Value Encoding</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-authorization-arguments" class="xref">Authorization Arguments</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-accounting-arguments" class="xref">Accounting Arguments</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-privilege-levels" class="xref">Privilege Levels</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-general-security-of-the-pro" class="xref">General Security of the Protocol</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-security-of-authentication-" class="xref">Security of Authentication Sessions</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-security-of-authorization-s" class="xref">Security of Authorization Sessions</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="xref">10.4</a>.  <a href="#name-security-of-accounting-sess" class="xref">Security of Accounting Sessions</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5">
                <p id="section-toc.1-1.10.2.5.1"><a href="#section-10.5" class="xref">10.5</a>.  <a href="#name-tacacs-best-practices" class="xref">TACACS+ Best Practices</a><a href="#section-toc.1-1.10.2.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5.2.1">
                    <p id="section-toc.1-1.10.2.5.2.1.1"><a href="#section-10.5.1" class="xref">10.5.1</a>.  <a href="#name-shared-secrets" class="xref">Shared Secrets</a><a href="#section-toc.1-1.10.2.5.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5.2.2">
                    <p id="section-toc.1-1.10.2.5.2.2.1"><a href="#section-10.5.2" class="xref">10.5.2</a>.  <a href="#name-connections-and-obfuscation" class="xref">Connections and Obfuscation</a><a href="#section-toc.1-1.10.2.5.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5.2.3">
                    <p id="section-toc.1-1.10.2.5.2.3.1"><a href="#section-10.5.3" class="xref">10.5.3</a>.  <a href="#name-authentication-2" class="xref">Authentication</a><a href="#section-toc.1-1.10.2.5.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5.2.4">
                    <p id="section-toc.1-1.10.2.5.2.4.1"><a href="#section-10.5.4" class="xref">10.5.4</a>.  <a href="#name-authorization-2" class="xref">Authorization</a><a href="#section-toc.1-1.10.2.5.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5.2.5">
                    <p id="section-toc.1-1.10.2.5.2.5.1"><a href="#section-10.5.5" class="xref">10.5.5</a>.  <a href="#name-redirection-mechanism" class="xref">Redirection Mechanism</a><a href="#section-toc.1-1.10.2.5.2.5.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="Introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="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.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="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" <span>[<a href="#THE-DRAFT" class="xref">THE-DRAFT</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="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 <a href="#TACACSSecurity" class="xref">Section 10</a>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="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:<a href="#section-1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-5.1">This document officially removes SENDPASS for security
        reasons.<a href="#section-1-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.2">The normative description of legacy features such as the Apple
        Remote Access Protocol (ARAP) and outbound authentication has been
        removed.<a href="#section-1-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.3">The Support for forwarding to an alternative daemon
        (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated.<a href="#section-1-5.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="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.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Conventions">
<section id="section-2">
      <h2 id="name-conventions">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions" class="section-name selfRef">Conventions</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="TechnicalDefinitions">
<section id="section-3">
      <h2 id="name-technical-definitions">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-technical-definitions" class="section-name selfRef">Technical Definitions</a>
      </h2>
<p id="section-3-1">This section provides a few basic definitions that are applicable to
      this document.<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="Client">
<section id="section-3.1">
        <h3 id="name-client">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-client" class="section-name selfRef">Client</a>
        </h3>
<p id="section-3.1-1">The client is any device that initiates TACACS+ protocol requests
        to mediate access, mainly for the Device Administration use case.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Server">
<section id="section-3.2">
        <h3 id="name-server">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-server" class="section-name selfRef">Server</a>
        </h3>
<p id="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.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Packet">
<section id="section-3.3">
        <h3 id="name-packet">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-packet" class="section-name selfRef">Packet</a>
        </h3>
<p id="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.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Connection">
<section id="section-3.4">
        <h3 id="name-connection">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-connection" class="section-name selfRef">Connection</a>
        </h3>
<p id="section-3.4-1">
 TACACS+ uses TCP for its transport.  TCP Server port 49 is allocated
 by IANA for TACACS+ traffic.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Session">
<section id="section-3.5">
        <h3 id="name-session">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-session" class="section-name selfRef">Session</a>
        </h3>
<p id="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.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="TreatmentOfEnumeratedValues">
<section id="section-3.6">
        <h3 id="name-treatment-of-enumerated-pro">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-treatment-of-enumerated-pro" class="section-name selfRef">Treatment of Enumerated Protocol Values</a>
        </h3>
<p id="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.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-3.6-2" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST</span> be
 returned to indicate an error.<a href="#section-3.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="TextEncoding">
<section id="section-3.7">
        <h3 id="name-treatment-of-text-strings">
<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-treatment-of-text-strings" class="section-name selfRef">Treatment of Text Strings</a>
        </h3>
<p id="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.<a href="#section-3.7-1" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST</span> be encoded and
        handled using the UsernameCasePreserved Profile specified in <span>[<a href="#RFC8265" class="xref">RFC8265</a>]</span>. The security
        considerations in <span><a href="https://www.rfc-editor.org/rfc/rfc8265#section-8" class="relref">Section 8</a> of [<a href="#RFC8265" class="xref">RFC8265</a>]</span> apply.<a href="#section-3.7-2" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-3.7-3" class="pilcrow">¶</a></p>
<p id="section-3.7-4">
 All other text fields in TACACS+
 <span class="bcp14">MUST</span> be treated as
 printable byte arrays of US-ASCII as
 defined by <span>[<a href="#RFC0020" class="xref">RFC0020</a>]</span>.  The term
 "printable" used here means the fields
 <span class="bcp14">MUST</span> exclude the
 "Control Characters" defined in <span><a href="https://www.rfc-editor.org/rfc/rfc20#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC0020" class="xref">RFC0020</a>]</span>.<a href="#section-3.7-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="TACACSPacketsSessions">
<section id="section-4">
      <h2 id="name-tacacs-packets-and-sessions">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-tacacs-packets-and-sessions" class="section-name selfRef">TACACS+ Packets and Sessions</a>
      </h2>
<div id="TheTACACSPacketHeader">
<section id="section-4.1">
        <h3 id="name-the-tacacs-packet-header">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-the-tacacs-packet-header" class="section-name selfRef">The TACACS+ Packet Header</a>
        </h3>
<p id="section-4.1-1">
 All TACACS+ packets begin with the
 following 12-byte header. The header
 describes the remainder of the packet:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.1-2">
<pre>
 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                               |
+----------------+----------------+----------------+----------------+
</pre><a href="#section-4.1-2" class="pilcrow">¶</a>
</div>
<p id="section-4.1-3">The following general rules apply to all TACACS+ packet types:<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="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
 <span class="bcp14">MUST</span> be ignored, and treated as if not present.<a href="#section-4.1-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="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).<a href="#section-4.1-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-4.3">
 All length values are unsigned and in network byte order.<a href="#section-4.1-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-5">
 major_version<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.1-6.1">
            <p id="section-4.1-6.1.1">
 This is the major TACACS+ version number.<a href="#section-4.1-6.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.1-7.1">
 TAC_PLUS_MAJOR_VER := 0xc<a href="#section-4.1-7.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-8">
 minor_version<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.1-9.1">
            <p id="section-4.1-9.1.1">
 This is the minor TACACS+ version number.<a href="#section-4.1-9.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-9.2">
 TAC_PLUS_MINOR_VER_DEFAULT := 0x0<a href="#section-4.1-9.2" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-4.1-9.3">
 TAC_PLUS_MINOR_VER_ONE := 0x1<a href="#section-4.1-9.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-10">
 type<a href="#section-4.1-10" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.1-11.1">
            <p id="section-4.1-11.1.1">
   This is the packet type.<a href="#section-4.1-11.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-11.2">Options are:<a href="#section-4.1-11.2" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-4.1-11.3">
 TAC_PLUS_AUTHEN := 0x01 (Authentication)<a href="#section-4.1-11.3" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-4.1-11.4">
 TAC_PLUS_AUTHOR := 0x02 (Authorization)<a href="#section-4.1-11.4" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-4.1-11.5">
 TAC_PLUS_ACCT := 0x03 (Accounting)<a href="#section-4.1-11.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-12">

 seq_no<a href="#section-4.1-12" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.1-13.1">
            <p id="section-4.1-13.1.1">
 This is the sequence number of the current packet. The first packet in
 a session <span class="bcp14">MUST</span> 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.<a href="#section-4.1-13.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-13.2">
            <p id="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.<a href="#section-4.1-13.2.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-4.1-14">
 flags<a href="#section-4.1-14" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.1-15.1">
            <p id="section-4.1-15.1.1">
        This field contains various bitmapped flags.<a href="#section-4.1-15.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-15.2">
            <p id="section-4.1-15.2.1">
 The flag bit:<a href="#section-4.1-15.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-15.3">
            <p id="section-4.1-15.3.1">
TAC_PLUS_UNENCRYPTED_FLAG := 0x01<a href="#section-4.1-15.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-15.4">
            <p id="section-4.1-15.4.1">
 This flag indicates that the sender
 did not obfuscate the body of the
 packet. This option <span class="bcp14">MUST NOT</span> be used in production. The
 application of this flag will be
 covered in "Security Considerations"
 (<a href="#TACACSSecurity" class="xref">Section 10</a>).<a href="#section-4.1-15.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-15.5">
            <p id="section-4.1-15.5.1">
 This flag <span class="bcp14">SHOULD</span> be clear in all
 deployments. Modern network traffic tools support encrypted
 traffic when configured with the shared secret (see "Shared Secrets" (<a href="#SharedSecrets" class="xref">Section 10.5.1</a>)), so obfuscated mode can and
 <span class="bcp14">SHOULD</span> be used even during test.<a href="#section-4.1-15.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-15.6">
            <p id="section-4.1-15.6.1">
 The single-connection flag:<a href="#section-4.1-15.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-15.7">
            <p id="section-4.1-15.7.1">
 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04<a href="#section-4.1-15.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-15.8">
            <p id="section-4.1-15.8.1">
 This flag is used to allow a client and server to negotiate
 "Single Connection Mode" (<a href="#SingleConnectMode" class="xref">Section 4.3</a>).<a href="#section-4.1-15.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-4.1-15.9">
            <p id="section-4.1-15.9.1">
 All other bits <span class="bcp14">MUST</span> be ignored when reading,
 and <span class="bcp14">SHOULD</span> be set to zero when writing.<a href="#section-4.1-15.9.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-4.1-16">
 session_id<a href="#section-4.1-16" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.1-17.1">
            <p id="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
 <span class="bcp14">MUST</span> 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
 <span>[<a href="#RFC4086" class="xref">RFC4086</a>]</span>.<a href="#section-4.1-17.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-4.1-18">
 length<a href="#section-4.1-18" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.1-19.1">
            <p id="section-4.1-19.1.1">
The total length of the packet body (not including
the header). Implementations <span class="bcp14">MUST</span> allow control over
maximum packet sizes accepted by TACACS+ Servers. 
The recommended maximum packet size is 2<sup>16</sup>.<a href="#section-4.1-19.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</section>
</div>
<div id="TheTACACSPacketBody">
<section id="section-4.2">
        <h3 id="name-the-tacacs-packet-body">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-the-tacacs-packet-body" class="section-name selfRef">The TACACS+ Packet Body</a>
        </h3>
<p id="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.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SingleConnectMode">
<section id="section-4.3">
        <h3 id="name-single-connection-mode">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-single-connection-mode" class="section-name selfRef">Single Connection Mode</a>
        </h3>
<p id="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.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">
 The client sets this flag to indicate
 that it supports multiplexing TACACS+
 sessions over a single TCP
 connection. The client <span class="bcp14">MUST NOT</span> send a second packet on a
 connection until single-connect status
 has been established.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<p id="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
 <span class="bcp14">MUST</span> ignore the flag
 after the second packet on a
 connection.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-4.3-6" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST</span> be configured to time out a Single
        Connection Mode TCP connection after a specific period of inactivity
        to preserve its resources. The client <span class="bcp14">MUST</span> accommodate
        such closures on a TCP session even after Single Connection Mode has
        been established.<a href="#section-4.3-7" class="pilcrow">¶</a></p>
<p id="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" (<a href="#SessionCompletion" class="xref">Section 4.4</a>).  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.<a href="#section-4.3-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SessionCompletion">
<section id="section-4.4">
        <h3 id="name-session-completion">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-session-completion" class="section-name selfRef">Session Completion</a>
        </h3>
<p id="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).<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST</span> 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.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">
 Refer to "Aborting an Authentication Session" (<a href="#AbortinganAuthenticationSession" class="xref">Section 5.4.3</a>) for details
 on handling additional status options.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="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:<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-6.1">
            <p id="section-4.4-6.1.1">If Single Connection Mode was not negotiated, then the connection
        should be closed.<a href="#section-4.4-6.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="section-4.4-6.2">
            <p id="section-4.4-6.2.1">
 
 If Single Connection Mode was enabled,
 then the connection
 <span class="bcp14">SHOULD</span> be left open
 (see "Single Connection Mode" (<a href="#SingleConnectMode" class="xref">Section 4.3</a>)) but may still be
 closed after a timeout period to
 preserve deployment resources.<a href="#section-4.4-6.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="section-4.4-6.3">
            <p id="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 <a href="#Obfuscation" class="xref">Section 4.5</a>)), then any further
 new sessions <span class="bcp14">MUST NOT</span>
 be accepted on the connection.  If
 there are any sessions that have
 already been established, then they
 <span class="bcp14">MAY</span> be completed. Once
 all active sessions are completed, then
 the connection <span class="bcp14">MUST</span> be
 closed.<a href="#section-4.4-6.3.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="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.<a href="#section-4.4-7" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-4.4-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Obfuscation">
<section id="section-4.5">
        <h3 id="name-data-obfuscation">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-data-obfuscation" class="section-name selfRef">Data Obfuscation</a>
        </h3>
<p id="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.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="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
 <span class="bcp14">MUST</span> remain secret.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
<p id="section-4.5-3">Server implementations <span class="bcp14">MUST</span> 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.<a href="#section-4.5-3" class="pilcrow">¶</a></p>
<p id="section-4.5-4">


 The flag field <span class="bcp14">MUST</span> 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:<a href="#section-4.5-4" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.5-5.1">
            <p id="section-4.5-5.1.1">ENCRYPTED {data} = data <sup>pseudo_pad</sup><a href="#section-4.5-5.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-4.5-6">The packet body can then be de-obfuscated by XORing it bytewise
  with a pseudo-random pad.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.5-7.1">
            <p id="section-4.5-7.1.1">
 data = ENCRYPTED {data} <sup>pseudo_pad</sup><a href="#section-4.5-7.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="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
 <span>[<a href="#RFC1321" class="xref">RFC1321</a>]</span>.<a href="#section-4.5-8" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.5-9.1">
            <p id="section-4.5-9.1.1">
 pseudo_pad = {MD5_1 [,MD5_2 [
 ... ,MD5_n]]} truncated to len(data)<a href="#section-4.5-9.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="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.<a href="#section-4.5-10" class="pilcrow">¶</a></p>
<p id="section-4.5-11">
 The version number and session_id are extracted from the
 header.<a href="#section-4.5-11" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-4.5-12" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.5-13.1">
            <p id="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}<a href="#section-4.5-13.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-4.5-14">
   
 When a server detects that the
 secrets it has configured for the
 device do not match, it
 <span class="bcp14">MUST</span> return ERROR. For
 details of TCP connection handling on
 ERROR, refer to "Session Completion" (<a href="#SessionCompletion" class="xref">Section 4.4</a>).<a href="#section-4.5-14" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-4.5-15.1">
            <p id="section-4.5-15.1.1">
 TAC_PLUS_UNENCRYPTED_FLAG == 0x1<a href="#section-4.5-15.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-4.5-16">
 This option is deprecated and
 <span class="bcp14">MUST NOT</span> be used in
 production. In this case, the entire
 packet body is in cleartext. A request
 <span class="bcp14">MUST</span> be dropped if
 TAC_PLUS_UNENCRYPTED_FLAG is set to
 true.<a href="#section-4.5-16" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST</span> be
 discarded and an ERROR signaled. For details of TCP connection
 handling on ERROR, refer to
 "Session Completion" (<a href="#SessionCompletion" class="xref">Section 4.4</a>).<a href="#section-4.5-17" class="pilcrow">¶</a></p>
<p id="section-4.5-18">
 Commonly, such failures are seen when
 the keys are mismatched between the
 client and the TACACS+ server.<a href="#section-4.5-18" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Authentication">
<section id="section-5">
      <h2 id="name-authentication">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-authentication" class="section-name selfRef">Authentication</a>
      </h2>
<p id="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.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="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" (<a href="#Authorization" class="xref">Section 6</a>)).  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.<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="TheAuthenticationSTARTPacketBody">
<section id="section-5.1">
        <h3 id="name-the-authentication-start-pa">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-the-authentication-start-pa" class="section-name selfRef">The Authentication START Packet Body</a>
        </h3>
<div class="artwork art-text alignLeft" id="section-5.1-1">
<pre>
 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...
+----------------+----------------+----------------+----------------+
</pre><a href="#section-5.1-1" class="pilcrow">¶</a>
</div>
<p id="section-5.1-2">
 Packet fields are as follows:<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">
 action<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.1-4.1">
            <p id="section-5.1-4.1.1"> This indicates the authentication action.<a href="#section-5.1-4.1.1" class="pilcrow">¶</a></p>
<p id="section-5.1-4.1.2">
Valid values are:<a href="#section-5.1-4.1.2" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-4.2">
 TAC_PLUS_AUTHEN_LOGIN := 0x01<a href="#section-5.1-4.2" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-4.3">
 TAC_PLUS_AUTHEN_CHPASS := 0x02<a href="#section-5.1-4.3" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-4.4">
 TAC_PLUS_AUTHEN_SENDAUTH := 0x04<a href="#section-5.1-4.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-5">
 priv_lvl<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.1-6.1">
            <p id="section-5.1-6.1.1"> This indicates the privilege level that the user is authenticating
as. Please refer to "Privilege Levels" (<a href="#PrivilegeLevel" class="xref">Section 9</a>).<a href="#section-5.1-6.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-5.1-7">
authen_type<a href="#section-5.1-7" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.1-8.1">
            <p id="section-5.1-8.1.1">
The type of authentication. Please see "Common Authentication Flows" (<a href="#CommonAuthenticationFlows" class="xref">Section 5.4.2</a>).<a href="#section-5.1-8.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-8.2">
            <p id="section-5.1-8.2.1">
Valid values are:<a href="#section-5.1-8.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-8.3">
 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01<a href="#section-5.1-8.3" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-8.4">
 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02<a href="#section-5.1-8.4" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-8.5">
 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03<a href="#section-5.1-8.5" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-8.6">
 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05<a href="#section-5.1-8.6" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-8.7">
 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06<a href="#section-5.1-8.7" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-9">
 authen_service<a href="#section-5.1-9" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.1-10.1">
            <p id="section-5.1-10.1.1">
 This is the service that is requesting
 the authentication.<a href="#section-5.1-10.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.2">
            <p id="section-5.1-10.2.1">
Valid values are:<a href="#section-5.1-10.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.3">
 TAC_PLUS_AUTHEN_SVC_NONE := 0x00<a href="#section-5.1-10.3" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.4">
 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01<a href="#section-5.1-10.4" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.5">
 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02<a href="#section-5.1-10.5" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.6">
 TAC_PLUS_AUTHEN_SVC_PPP := 0x03<a href="#section-5.1-10.6" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.7">
 TAC_PLUS_AUTHEN_SVC_PT := 0x05<a href="#section-5.1-10.7" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.8">
 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06<a href="#section-5.1-10.8" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.9">
 TAC_PLUS_AUTHEN_SVC_X25 := 0x07<a href="#section-5.1-10.9" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.10">
 TAC_PLUS_AUTHEN_SVC_NASI := 0x08<a href="#section-5.1-10.10" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.11">
 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09<a href="#section-5.1-10.11" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.12">
            <p id="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.<a href="#section-5.1-10.12.1" class="pilcrow">¶</a></p>
<p id="section-5.1-10.12.2">The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as
        opposed to ENABLE) to a client device.<a href="#section-5.1-10.12.2" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.13">
            <p id="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.<a href="#section-5.1-10.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-10.14">
            <p id="section-5.1-10.14.1">Other options are included for legacy/backwards compatibility.<a href="#section-5.1-10.14.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-5.1-11">
 user, user_len<a href="#section-5.1-11" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.1-12.1">
            <p id="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 <span class="bcp14">MUST</span> set
 user_len to 0.  If included, the
 user_len indicates the length of the
 user field, in bytes.<a href="#section-5.1-12.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-5.1-13">
 port, port_len<a href="#section-5.1-13" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.1-14.1">
            <p id="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
 <span class="bcp14">SHOULD</span> define the
 values and their meanings for this
 field.  For details of text encoding,
 see "Treatment of Text Strings" (<a href="#TextEncoding" class="xref">Section 3.7</a>).  The port_len indicates the
 length of the port field, in bytes.<a href="#section-5.1-14.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-5.1-15">
 rem_addr, rem_addr_len<a href="#section-5.1-15" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.1-16.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-5.1-16.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-16.2">
            <p id="section-5.1-16.2.1"> When TACACS+ was used for dial-up services, this value contained
        the caller ID.<a href="#section-5.1-16.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-16.3">
            <p id="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 <span>[<a href="#RFC5952" class="xref">RFC5952</a>]</span>.<a href="#section-5.1-16.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.1-16.4">
            <p id="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.<a href="#section-5.1-16.4.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-5.1-17">
 data, data_len<a href="#section-5.1-17" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.1-18.1">
            <p id="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" (<a href="#CommonAuthenticationFlows" class="xref">Section 5.4.2</a>). The data_len field indicates the length of the
 data field, in bytes.<a href="#section-5.1-18.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</section>
</div>
<div id="TheAuthenticationREPLYPacketBody">
<section id="section-5.2">
        <h3 id="name-the-authentication-reply-pa">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-the-authentication-reply-pa" class="section-name selfRef">The Authentication REPLY Packet Body</a>
        </h3>
<p id="section-5.2-1">
 The TACACS+ server sends only one type
 of authentication packet (a REPLY
 packet) to the client.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-5.2-2">
<pre>
 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 ...
+----------------+----------------+
</pre><a href="#section-5.2-2" class="pilcrow">¶</a>
</div>
<p id="section-5.2-3">
 status<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.2-4.1">
            <p id="section-5.2-4.1.1">
 The current status of the authentication.<a href="#section-5.2-4.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.2-4.2">Valid values are:<a href="#section-5.2-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.2-5.1">
 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01<a href="#section-5.2-5.1" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.2-5.2">
 TAC_PLUS_AUTHEN_STATUS_FAIL :=
 0x02<a href="#section-5.2-5.2" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.2-5.3">
 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03<a href="#section-5.2-5.3" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.2-5.4">
 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04<a href="#section-5.2-5.4" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.2-5.5">
 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05<a href="#section-5.2-5.5" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.2-5.6">
 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06<a href="#section-5.2-5.6" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.2-5.7">
 TAC_PLUS_AUTHEN_STATUS_ERROR
 := 0x07<a href="#section-5.2-5.7" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-5.2-5.8">
 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21<a href="#section-5.2-5.8" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.2-6">
 flags<a href="#section-5.2-6" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.2-7.1">
            <p id="section-5.2-7.1.1">
 Bitmapped flags that modify the action to be taken.<a href="#section-5.2-7.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.2-7.2">The following values are defined:<a href="#section-5.2-7.2" class="pilcrow">¶</a>
</li>
        </ul>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.2-8.1">
 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01<a href="#section-5.2-8.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.2-9">
 server_msg, server_msg_len<a href="#section-5.2-9" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.2-10.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-5.2-10.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-5.2-11">
 data, data_len<a href="#section-5.2-11" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.2-12.1">
            <p id="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" (<a href="#CommonAuthenticationFlows" class="xref">Section 5.4.2</a>). The data_len indicates the length of the data
 field, in bytes.<a href="#section-5.2-12.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</section>
</div>
<div id="TheAuthenticationCONTINUEPacketBody">
<section id="section-5.3">
        <h3 id="name-the-authentication-continue">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-the-authentication-continue" class="section-name selfRef">The Authentication CONTINUE Packet Body</a>
        </h3>
<p id="section-5.3-1">
 This packet is sent from the client to the server following the
 receipt of a REPLY packet.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-5.3-2">
<pre>
 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 ...
+----------------+
</pre><a href="#section-5.3-2" class="pilcrow">¶</a>
</div>
<p id="section-5.3-3">
 user_msg, user_msg_len<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.3-4.1">
            <p id="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.<a href="#section-5.3-4.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-5.3-5">
 data, data_len<a href="#section-5.3-5" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.3-6.1">
            <p id="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.<a href="#section-5.3-6.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-5.3-7">
 flags<a href="#section-5.3-7" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.3-8.1">
            <p id="section-5.3-8.1.1">
 This holds the bitmapped flags that modify the action to be taken.<a href="#section-5.3-8.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.3-8.2">
            <p id="section-5.3-8.2.1">
 The following values are defined:<a href="#section-5.3-8.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-5.3-8.3">
 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01<a href="#section-5.3-8.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="DescriptionofAuthenticationProcess">
<section id="section-5.4">
        <h3 id="name-description-of-authenticati">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-description-of-authenticati" class="section-name selfRef">Description of Authentication Process</a>
        </h3>
<p id="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.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">SHOULD</span> provide
 server_msg content for the client to prompt the user for more
 information. The client <span class="bcp14">MUST</span> then return a CONTINUE
 packet containing the requested information in the user_msg field.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5.4-4" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST NOT</span> be reflected in the user interface as
        it is entered.<a href="#section-5.4-5" class="pilcrow">¶</a></p>
<p id="section-5.4-6">
 The data field is only used in the REPLY
 where
 explicitly
 defined
 below.<a href="#section-5.4-6" class="pilcrow">¶</a></p>
<div id="VersionBehaviour">
<section id="section-5.4.1">
          <h4 id="name-version-behavior">
<a href="#section-5.4.1" class="section-number selfRef">5.4.1. </a><a href="#name-version-behavior" class="section-name selfRef">Version Behavior</a>
          </h4>
<p id="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:<a href="#section-5.4.1-1" class="pilcrow">¶</a></p>
<span id="name-tacacs-protocol-versioning"></span><div id="table_1">
<table class="center" id="table-1">
            <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-tacacs-protocol-versioning" class="selfRef">TACACS+ Protocol Versioning</a>
            </caption>
<tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">LOGIN</td>
                <td class="text-left" rowspan="1" colspan="1">CHPASS</td>
                <td class="text-left" rowspan="1" colspan="1">SENDAUTH</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">ASCII</td>
                <td class="text-left" rowspan="1" colspan="1">v0</td>
                <td class="text-left" rowspan="1" colspan="1">v0</td>
                <td class="text-left" rowspan="1" colspan="1">-</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">PAP</td>
                <td class="text-left" rowspan="1" colspan="1">v1</td>
                <td class="text-left" rowspan="1" colspan="1">-</td>
                <td class="text-left" rowspan="1" colspan="1">v1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CHAP</td>
                <td class="text-left" rowspan="1" colspan="1">v1</td>
                <td class="text-left" rowspan="1" colspan="1">-</td>
                <td class="text-left" rowspan="1" colspan="1">v1</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MS-CHAPv1/2</td>
                <td class="text-left" rowspan="1" colspan="1">v1</td>
                <td class="text-left" rowspan="1" colspan="1">-</td>
                <td class="text-left" rowspan="1" colspan="1">v1</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-5.4.1-3">The '-' symbol represents that the option is not valid.<a href="#section-5.4.1-3" class="pilcrow">¶</a></p>
<p id="section-5.4.1-4">
 All authorization and accounting and ASCII authentication use
 minor_version 0.<a href="#section-5.4.1-4" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5.4.1-5" class="pilcrow">¶</a></p>
<p id="section-5.4.1-6"> The removal of SENDPASS was prompted by security concerns and
          is no longer considered part of the TACACS+ protocol.<a href="#section-5.4.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="CommonAuthenticationFlows">
<section id="section-5.4.2">
          <h4 id="name-common-authentication-flows">
<a href="#section-5.4.2" class="section-number selfRef">5.4.2. </a><a href="#name-common-authentication-flows" class="section-name selfRef">Common Authentication Flows</a>
          </h4>
<p id="section-5.4.2-1">
 This section describes common authentication flows. If the server does
 not implement an option, it <span class="bcp14">MUST</span> respond with
 TAC_PLUS_AUTHEN_STATUS_FAIL.<a href="#section-5.4.2-1" class="pilcrow">¶</a></p>
<div id="ASCIILogin">
<section id="section-5.4.2.1">
            <h5 id="name-ascii-login">
<a href="#section-5.4.2.1" class="section-number selfRef">5.4.2.1. </a><a href="#name-ascii-login" class="section-name selfRef">ASCII Login</a>
            </h5>
<div class="artwork art-text alignLeft" id="section-5.4.2.1-1">
<pre>
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
    minor_version = 0x0
</pre><a href="#section-5.4.2.1-1" class="pilcrow">¶</a>
</div>
<p id="section-5.4.2.1-2">
 This is a standard ASCII authentication. The START packet
 <span class="bcp14">MAY</span> contain the username. If the user does not include
 the username, then the server <span class="bcp14">MUST</span> 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
 <span class="bcp14">MUST</span> 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
 <span class="bcp14">MUST</span> 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.<a href="#section-5.4.2.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="PAPLogin">
<section id="section-5.4.2.2">
            <h5 id="name-pap-login">
<a href="#section-5.4.2.2" class="section-number selfRef">5.4.2.2. </a><a href="#name-pap-login" class="section-name selfRef">PAP Login</a>
            </h5>
<div class="artwork art-text alignLeft" id="section-5.4.2.2-1">
<pre>
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
    minor_version = 0x1
</pre><a href="#section-5.4.2.2-1" class="pilcrow">¶</a>
</div>
<p id="section-5.4.2.2-2">
 The entire exchange <span class="bcp14">MUST</span> consist of a single START
 packet and a single REPLY. The START packet <span class="bcp14">MUST</span>
 contain a username and the data field <span class="bcp14">MUST</span> contain the
 PAP ASCII password. A PAP authentication only consists of a username
 and password <span>[<a href="#RFC1334" class="xref">RFC1334</a>]</span> (Obsolete). The
 REPLY from the server <span class="bcp14">MUST</span> be either a PASS, FAIL, or
 ERROR.<a href="#section-5.4.2.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="CHAPlogin">
<section id="section-5.4.2.3">
            <h5 id="name-chap-login">
<a href="#section-5.4.2.3" class="section-number selfRef">5.4.2.3. </a><a href="#name-chap-login" class="section-name selfRef">CHAP Login</a>
            </h5>
<div class="artwork art-text alignLeft" id="section-5.4.2.3-1">
<pre>
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP
    minor_version = 0x1
</pre><a href="#section-5.4.2.3-1" class="pilcrow">¶</a>
</div>
<p id="section-5.4.2.3-2">
 The entire exchange <span class="bcp14">MUST</span> consist of a single START
 packet and a single REPLY. The START packet <span class="bcp14">MUST</span>
 contain the username in the user field, and the data field is a
 concatenation of the PPP id, the challenge, and the response.<a href="#section-5.4.2.3-2" class="pilcrow">¶</a></p>
<p id="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).<a href="#section-5.4.2.3-3" class="pilcrow">¶</a></p>
<p id="section-5.4.2.3-4">
To perform the authentication, the server calculates the PPP hash as defined
in PPP Authentication <span>[<a href="#RFC1334" class="xref">RFC1334</a>]</span> and then
compares that value with the response. The MD5 algorithm option is always
used.  The REPLY from the server <span class="bcp14">MUST</span> be a PASS, FAIL, or
ERROR.<a href="#section-5.4.2.3-4" class="pilcrow">¶</a></p>
<p id="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).<a href="#section-5.4.2.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="MS-CHAPv1login">
<section id="section-5.4.2.4">
            <h5 id="name-ms-chap-v1-login">
<a href="#section-5.4.2.4" class="section-number selfRef">5.4.2.4. </a><a href="#name-ms-chap-v1-login" class="section-name selfRef">MS-CHAP v1 Login</a>
            </h5>
<div class="artwork art-text alignLeft" id="section-5.4.2.4-1">
<pre>
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP
    minor_version = 0x1
</pre><a href="#section-5.4.2.4-1" class="pilcrow">¶</a>
</div>
<p id="section-5.4.2.4-2">
The entire exchange <span class="bcp14">MUST</span> consist of a single START packet and a
single REPLY. The START packet <span class="bcp14">MUST</span> 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.<a href="#section-5.4.2.4-2" class="pilcrow">¶</a></p>
<p id="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).<a href="#section-5.4.2.4-3" class="pilcrow">¶</a></p>
<p id="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 <span>[<a href="#RFC2433" class="xref">RFC2433</a>]</span>, and then compare the
resulting value with the response. The REPLY from the server
<span class="bcp14">MUST</span> be a PASS or FAIL.<a href="#section-5.4.2.4-4" class="pilcrow">¶</a></p>
<p id="section-5.4.2.4-5">
 For best practices, please refer to <span>[<a href="#RFC2433" class="xref">RFC2433</a>]</span>. The TACACS+ server <span class="bcp14">MUST</span> reject
 authentications where the challenge deviates from 8 bytes as defined
 in the RFC.<a href="#section-5.4.2.4-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="MS-CHAPv2login">
<section id="section-5.4.2.5">
            <h5 id="name-ms-chap-v2-login">
<a href="#section-5.4.2.5" class="section-number selfRef">5.4.2.5. </a><a href="#name-ms-chap-v2-login" class="section-name selfRef">MS-CHAP v2 Login</a>
            </h5>
<div class="artwork art-text alignLeft" id="section-5.4.2.5-1">
<pre>
    action = TAC_PLUS_AUTHEN_LOGIN
    authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2
    minor_version = 0x1
</pre><a href="#section-5.4.2.5-1" class="pilcrow">¶</a>
</div>
<p id="section-5.4.2.5-2">
The entire exchange <span class="bcp14">MUST</span> consist of a single START packet and a
single REPLY. The START packet <span class="bcp14">MUST</span> 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.<a href="#section-5.4.2.5-2" class="pilcrow">¶</a></p>
<p id="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).<a href="#section-5.4.2.5-3" class="pilcrow">¶</a></p>
<p id="section-5.4.2.5-4">
To perform the authentication, the server will use the algorithm specified
<span>[<a href="#RFC2759" class="xref">RFC2759</a>]</span> on the user's secret and challenge,
and then compare the resulting value with the response.  The REPLY from the
server <span class="bcp14">MUST</span> be a PASS or FAIL.<a href="#section-5.4.2.5-4" class="pilcrow">¶</a></p>
<p id="section-5.4.2.5-5">
For best practices for MS-CHAP v2, please refer to <span>[<a href="#RFC2759" class="xref">RFC2759</a>]</span>. The TACACS+ server <span class="bcp14">MUST</span> reject
authentications where the challenge deviates from 16 bytes as defined in the
RFC.<a href="#section-5.4.2.5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EnableRequests">
<section id="section-5.4.2.6">
            <h5 id="name-enable-requests">
<a href="#section-5.4.2.6" class="section-number selfRef">5.4.2.6. </a><a href="#name-enable-requests" class="section-name selfRef">Enable Requests</a>
            </h5>
<div class="artwork art-text alignLeft" id="section-5.4.2.6-1">
<pre>
    action = TAC_PLUS_AUTHEN_LOGIN
    priv_lvl = implementation dependent
    authen_type = not used
    service = TAC_PLUS_AUTHEN_SVC_ENABLE
</pre><a href="#section-5.4.2.6-1" class="pilcrow">¶</a>
</div>
<p id="section-5.4.2.6-2">
 This is an "ENABLE" request, used to change the current running
 privilege level of a user.  The exchange <span class="bcp14">MAY</span> 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 (<a href="#ASCIILogin" class="xref">Section 5.4.2.1</a>).<a href="#section-5.4.2.6-2" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST</span> be set to
TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It <span class="bcp14">MUST NOT</span> be set to this value when requesting any other operation.<a href="#section-5.4.2.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ASCIIchangepasswordrequest">
<section id="section-5.4.2.7">
            <h5 id="name-ascii-change-password-reque">
<a href="#section-5.4.2.7" class="section-number selfRef">5.4.2.7. </a><a href="#name-ascii-change-password-reque" class="section-name selfRef">ASCII Change Password Request</a>
            </h5>
<div class="artwork art-text alignLeft" id="section-5.4.2.7-1">
<pre>
action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
</pre><a href="#section-5.4.2.7-1" class="pilcrow">¶</a>
</div>
<p id="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 <span class="bcp14">MUST</span> only be used when
 requesting the "new" password. It <span class="bcp14">MAY</span> be sent multiple
 times. When requesting the "old" password, the status value
 <span class="bcp14">MUST</span> be set to TAC_PLUS_AUTHEN_STATUS_GETDATA.<a href="#section-5.4.2.7-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="AbortinganAuthenticationSession">
<section id="section-5.4.3">
          <h4 id="name-aborting-an-authentication-">
<a href="#section-5.4.3" class="section-number selfRef">5.4.3. </a><a href="#name-aborting-an-authentication-" class="section-name selfRef">Aborting an Authentication Session</a>
          </h4>
<p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>). For more
details about session termination, refer to "Session Completion" (<a href="#SessionCompletion" class="xref">Section 4.4</a>).<a href="#section-5.4.3-1" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5.4.3-2" class="pilcrow">¶</a></p>
<p id="section-5.4.3-3">
 "The Draft" <span>[<a href="#THE-DRAFT" class="xref">THE-DRAFT</a>]</span>
 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.<a href="#section-5.4.3-3" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5.4.3-4" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-5.4.3-5" class="pilcrow">¶</a></p>
<p id="section-5.4.3-6">
 If a client does not implement the TAC_PLUS_AUTHEN_STATUS_RESTART option,
 then it <span class="bcp14">MUST</span> process the response as if the status was
 TAC_PLUS_AUTHEN_STATUS_FAIL.<a href="#section-5.4.3-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="Authorization">
<section id="section-6">
      <h2 id="name-authorization">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-authorization" class="section-name selfRef">Authorization</a>
      </h2>
<p id="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.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="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" (<a href="#AuthorizationAttributes" class="xref">Section 8.2</a>).<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
The REPLY contains a variable set of response arguments (argument-value pairs)
that can restrict or modify the client's actions.<a href="#section-6-5" class="pilcrow">¶</a></p>
<div id="TheAuthorizationREQUESTPacketBody">
<section id="section-6.1">
        <h3 id="name-the-authorization-request-p">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-the-authorization-request-p" class="section-name selfRef">The Authorization REQUEST Packet Body</a>
        </h3>
<div class="artwork art-text alignLeft" id="section-6.1-1">
<pre>
  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 ...
+----------------+----------------+----------------+----------------+
</pre><a href="#section-6.1-1" class="pilcrow">¶</a>
</div>
<p id="section-6.1-2">
 authen_method<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-3.1">
            <p id="section-6.1-3.1.1">
This field allows the client to indicate the authentication method used to
acquire user information.<a href="#section-6.1-3.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.2">
 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00<a href="#section-6.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.3">
 TAC_PLUS_AUTHEN_METH_NONE :=
 0x01<a href="#section-6.1-3.3" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.4">
 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02<a href="#section-6.1-3.4" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.5">
 TAC_PLUS_AUTHEN_METH_LINE :=
 0x03<a href="#section-6.1-3.5" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.6">
 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04<a href="#section-6.1-3.6" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.7">
 TAC_PLUS_AUTHEN_METH_LOCAL
 := 0x05<a href="#section-6.1-3.7" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.8">
 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06<a href="#section-6.1-3.8" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.9">
 TAC_PLUS_AUTHEN_METH_GUEST := 0x08<a href="#section-6.1-3.9" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.10">
 TAC_PLUS_AUTHEN_METH_RADIUS :=
 0x10<a href="#section-6.1-3.10" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.11">
 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11<a href="#section-6.1-3.11" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.12">
 TAC_PLUS_AUTHEN_METH_RCMD :=
 0x20<a href="#section-6.1-3.12" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.13">
            <p id="section-6.1-3.13.1"> As this information is not always subject to verification, it <span class="bcp14">MUST NOT</span> 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 <span>[<a href="#RFC4120" class="xref">RFC4120</a>]</span> and KRB4 <span>[<a href="#KRB4" class="xref">KRB4</a>]</span>
        are Kerberos versions 5 and 4.<a href="#section-6.1-3.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.14">
            <p id="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" (<a href="#Authentication" class="xref">Section 5</a>).  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 <span>[<a href="#RFC4120" class="xref">RFC4120</a>]</span> and RADIUS
<span>[<a href="#RFC3579" class="xref">RFC3579</a>]</span> RFCs.<a href="#section-6.1-3.14.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.1-4">
 priv_lvl<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-5.1">
            <p id="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" (<a href="#PrivilegeLevel" class="xref">Section 9</a>). It indicates the user's
current privilege level.<a href="#section-6.1-5.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.1-6">
 authen_type<a href="#section-6.1-6" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-7.1">
            <p id="section-6.1-7.1.1"> This field corresponds to the authen_type field in "Authentication" (<a href="#Authentication" class="xref">Section 5</a>). 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.<a href="#section-6.1-7.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.1-8">
 authen_service<a href="#section-6.1-8" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-9.1">
            <p id="section-6.1-9.1.1">
This field is the same as the authen_service field in "Authentication" (<a href="#Authentication" class="xref">Section 5</a>). It indicates
the service through which the user authenticated.<a href="#section-6.1-9.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.1-10">
 user, user_len<a href="#section-6.1-10" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-11.1">
            <p id="section-6.1-11.1.1">
This field contains the user's account name. The user_len <span class="bcp14">MUST</span>
indicate the length of the user field, in bytes.<a href="#section-6.1-11.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.1-12">
 port, port_len<a href="#section-6.1-12" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-13.1">
            <p id="section-6.1-13.1.1">
 This field matches the port field in "Authentication" (<a href="#Authentication" class="xref">Section 5</a>). The port_len
 indicates the length of the port field, in bytes.<a href="#section-6.1-13.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.1-14">
 rem_addr, rem_addr_len<a href="#section-6.1-14" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-15.1">
            <p id="section-6.1-15.1.1">
 This field matches the rem_addr field in "Authentication" (<a href="#Authentication" class="xref">Section 5</a>). The rem_addr_len indicates the
 length of the port field, in bytes.<a href="#section-6.1-15.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.1-16">
 arg_cnt<a href="#section-6.1-16" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-17.1">
            <p id="section-6.1-17.1.1">
 This represents the number of authorization arguments to follow.<a href="#section-6.1-17.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.1-18">
 arg_1 ... arg_N, arg_1_len .... arg_N_len<a href="#section-6.1-18" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-19.1">
            <p id="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).<a href="#section-6.1-19.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.1-19.2">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-6.1-19.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.1-19.3">
            <p id="section-6.1-19.3.1">
 An argument name <span class="bcp14">MUST NOT</span> contain either of the
 separators. An argument value <span class="bcp14">MAY</span> 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.<a href="#section-6.1-19.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.1-19.4">
            <p id="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 <span class="bcp14">MUST</span>
        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.<a href="#section-6.1-19.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.1-19.5">
            <p id="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).<a href="#section-6.1-19.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.1-19.6">
            <p id="section-6.1-19.6.1">
Though the arguments allow extensibility, a common core set of authorization
arguments <span class="bcp14">SHOULD</span> be supported by clients and servers; these are
listed in "Authorization Arguments" (<a href="#AuthorizationAttributes" class="xref">Section 8.2</a>).<a href="#section-6.1-19.6.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</section>
</div>
<div id="TheAuthorizationREPLYPacketBody">
<section id="section-6.2">
        <h3 id="name-the-authorization-reply-pac">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-the-authorization-reply-pac" class="section-name selfRef">The Authorization REPLY Packet Body</a>
        </h3>
<div class="artwork art-text alignLeft" id="section-6.2-1">
<pre>
 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 ...
+----------------+----------------+----------------+----------------+
</pre><a href="#section-6.2-1" class="pilcrow">¶</a>
</div>
<p id="section-6.2-2">


 status<a href="#section-6.2-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.2-3.1">
            <p id="section-6.2-3.1.1">This field indicates the authorization status.<a href="#section-6.2-3.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.2-3.2">
            <p id="section-6.2-3.2.1">TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01<a href="#section-6.2-3.2.1" class="pilcrow">¶</a></p>
<p style="margin-left: 2.0em" id="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 <span class="bcp14">MUST</span> be applied according to the rules
                described above.<a href="#section-6.2-3.2.2" class="pilcrow">¶</a></p>
<p style="margin-left: 2.0em" id="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.<a href="#section-6.2-3.2.3" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.2-3.3">
            <p id="section-6.2-3.3.1">TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02<a href="#section-6.2-3.3.1" class="pilcrow">¶</a></p>
<p style="margin-left: 2.0em" id="section-6.2-3.3.2">If the status equals
 TAC_PLUS_AUTHOR_STATUS_PASS_REPL, then the client
 <span class="bcp14">MUST</span> use the authorization argument-value pairs
 (if any) in the response instead of the authorization
 argument-value pairs from the request.<a href="#section-6.2-3.3.2" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.2-3.4">
            <p id="section-6.2-3.4.1">TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10<a href="#section-6.2-3.4.1" class="pilcrow">¶</a></p>
<p style="margin-left: 2.0em" id="section-6.2-3.4.2">If the status equals
 TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested authorization
 <span class="bcp14">MUST</span> be denied.<a href="#section-6.2-3.4.2" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.2-3.5">
            <p id="section-6.2-3.5.1">TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11<a href="#section-6.2-3.5.1" class="pilcrow">¶</a></p>
<p style="margin-left: 2.0em" id="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" (<a href="#SessionCompletion" class="xref">Section 4.4</a>). None of
 the arg values have any relevance if an ERROR is set and must
 be ignored.<a href="#section-6.2-3.5.2" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-6.2-3.6">
            <p id="section-6.2-3.6.1">TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21<a href="#section-6.2-3.6.1" class="pilcrow">¶</a></p>
<p style="margin-left: 2.0em" id="section-6.2-3.6.2">When the status equals
 TAC_PLUS_AUTHOR_STATUS_FOLLOW, the arg_cnt <span class="bcp14">MUST</span>
 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.<a href="#section-6.2-3.6.2" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.2-4">

server_msg, server_msg_len<a href="#section-6.2-4" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.2-5.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-6.2-5.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.2-6">
 data, data_len<a href="#section-6.2-6" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.2-7.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-6.2-7.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.2-8">
 arg_cnt<a href="#section-6.2-8" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.2-9.1">
            <p id="section-6.2-9.1.1">
 This represents the number of authorization arguments to follow.<a href="#section-6.2-9.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-6.2-10">
 arg_1 ... arg_N, arg_1_len .... arg_N_len<a href="#section-6.2-10" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.2-11.1">
            <p id="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" (<a href="#AuthorizationAttributes" class="xref">Section 8.2</a>).  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).<a href="#section-6.2-11.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="Accounting">
<section id="section-7">
      <h2 id="name-accounting">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-accounting" class="section-name selfRef">Accounting</a>
      </h2>
<p id="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" (<a href="#AccountingAttributes" class="xref">Section 8.3</a>).<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="TheAccountREQUESTPacketBody">
<section id="section-7.1">
        <h3 id="name-the-account-request-packet-">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-the-account-request-packet-" class="section-name selfRef">The Account REQUEST Packet Body</a>
        </h3>
<div class="artwork art-text alignLeft" id="section-7.1-1">
<pre>
 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 ...
+----------------+----------------+----------------+----------------+

</pre><a href="#section-7.1-1" class="pilcrow">¶</a>
</div>
<p id="section-7.1-2">
 flags<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-7.1-3.1">
            <p id="section-7.1-3.1.1">
 This holds bitmapped flags.<a href="#section-7.1-3.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-7.1-3.2">
            <p id="section-7.1-3.2.1">Valid values are:<a href="#section-7.1-3.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-7.1-3.3">
 TAC_PLUS_ACCT_FLAG_START := 0x02<a href="#section-7.1-3.3" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-7.1-3.4">
 TAC_PLUS_ACCT_FLAG_STOP := 0x04<a href="#section-7.1-3.4" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-7.1-3.5">
 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08<a href="#section-7.1-3.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.1-4">
 All other fields are defined in "Authentication" (<a href="#Authentication" class="xref">Section 5</a>) and "Authorization" (<a href="#Authorization" class="xref">Section 6</a>) 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.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
<p id="section-7.1-5">
 See "Accounting Arguments" (<a href="#AccountingAttributes" class="xref">Section 8.3</a>) for
 the dictionary of arguments relevant to accounting.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="TheAccountingREPLYPacketBody">
<section id="section-7.2">
        <h3 id="name-the-accounting-reply-packet">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-the-accounting-reply-packet" class="section-name selfRef">The Accounting REPLY Packet Body</a>
        </h3>
<p id="section-7.2-1">
 The purpose of accounting is to record the action that has occurred on
 the client.  The server <span class="bcp14">MUST</span> reply with success only
 when the accounting request has been recorded.  If the server did not
 record the accounting request, then it <span class="bcp14">MUST</span> reply with
 ERROR.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-7.2-2">
<pre>
 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 ...
+----------------+
</pre><a href="#section-7.2-2" class="pilcrow">¶</a>
</div>
<p id="section-7.2-3">
 status<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-7.2-4.1">
            <p id="section-7.2-4.1.1">
 This is the return status.<a href="#section-7.2-4.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-7.2-4.2">
            <p id="section-7.2-4.2.1">
Values are:<a href="#section-7.2-4.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-7.2-4.3">
 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01<a href="#section-7.2-4.3" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-7.2-4.4">
 TAC_PLUS_ACCT_STATUS_ERROR :=
 0x02<a href="#section-7.2-4.4" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-7.2-4.5">
            <p id="section-7.2-4.5.1">TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21<a href="#section-7.2-4.5.1" class="pilcrow">¶</a></p>
<p style="margin-left: 2.0em" id="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.<a href="#section-7.2-4.5.2" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-7.2-5">
 server_msg, server_msg_len<a href="#section-7.2-5" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-7.2-6.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-7.2-6.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-7.2-7">
 data, data_len<a href="#section-7.2-7" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-7.2-8.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-7.2-8.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="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" <span>[<a href="#THE-DRAFT" class="xref">THE-DRAFT</a>]</span> as "tasks".<a href="#section-7.2-9" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-7.2-10" class="pilcrow">¶</a></p>
<span id="name-summary-of-accounting-packe"></span><div id="accounting-packets">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-summary-of-accounting-packe" class="selfRef">Summary of Accounting Packets</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Watchdog</th>
              <th class="text-left" rowspan="1" colspan="1">Stop</th>
              <th class="text-left" rowspan="1" colspan="1">Start</th>
              <th class="text-left" rowspan="1" colspan="1">Flags &amp; 0xE</th>
              <th class="text-left" rowspan="1" colspan="1">Meaning</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">INVALID</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Start Accounting Record</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">Stop Accounting Record</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">INVALID</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">8</td>
              <td class="text-left" rowspan="1" colspan="1">Watchdog, no update</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">A</td>
              <td class="text-left" rowspan="1" colspan="1">Watchdog, with update</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">C</td>
              <td class="text-left" rowspan="1" colspan="1">INVALID</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">E</td>
              <td class="text-left" rowspan="1" colspan="1">INVALID</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-7.2-12">
 The START and STOP flags are mutually
 exclusive.<a href="#section-7.2-12" class="pilcrow">¶</a></p>
<p id="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
        <span class="bcp14">MUST</span> ignore any arguments). The STOP flag <span class="bcp14">MUST NOT</span> be set in conjunction with the WATCHDOG flag.<a href="#section-7.2-13" class="pilcrow">¶</a></p>
<p id="section-7.2-14">
 The server <span class="bcp14">MUST</span> respond
 with TAC_PLUS_ACCT_STATUS_ERROR if the
 client requests an INVALID option.<a href="#section-7.2-14" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="AttributeValuePairs">
<section id="section-8">
      <h2 id="name-argument-value-pairs">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-argument-value-pairs" class="section-name selfRef">Argument-Value Pairs</a>
      </h2>
<p id="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
 <span class="bcp14">MUST</span> use these arguments when
 supporting the corresponding use cases.<a href="#section-8-1" class="pilcrow">¶</a></p>
<div id="ValueEncoding">
<section id="section-8.1">
        <h3 id="name-value-encoding">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-value-encoding" class="section-name selfRef">Value Encoding</a>
        </h3>
<p id="section-8.1-1">
 All argument values are encoded as strings. For details of text
 encoding, see "Treatment of Text Strings" (<a href="#TextEncoding" class="xref">Section 3.7</a>).  The
 following type representations <span class="bcp14">SHOULD</span> be followed.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">Numeric<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.1-3.1">
            <p id="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 <span class="bcp14">MUST</span> verify that
 they can accommodate the lengths of numeric arguments before
 attempting to process them.  If the length cannot be accommodated, then
 the argument <span class="bcp14">MUST</span> be regarded as not handled and the
 logic in "Authorization" (<a href="#TheAuthorizationREQUESTPacketBody" class="xref">Section 6.1</a>) regarding the processing
 of arguments <span class="bcp14">MUST</span> be applied.<a href="#section-8.1-3.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.1-4">Boolean<a href="#section-8.1-4" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.1-5.1">
            <p id="section-8.1-5.1.1">
 All Boolean arguments are encoded with
 values "true" or "false".<a href="#section-8.1-5.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.1-6">IP-Address<a href="#section-8.1-6" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.1-7.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>). IPv4 addresses are specified as octet numerics separated by
dots ('.'). IPv6 address text representation is defined in <span>[<a href="#RFC5952" class="xref">RFC5952</a>]</span>.<a href="#section-8.1-7.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.1-8">Date Time<a href="#section-8.1-8" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.1-9.1">
            <p id="section-8.1-9.1.1">
 Absolute date/times are specified in seconds since the epoch, 12:00am,
 January 1, 1970. The time zone <span class="bcp14">MUST</span> be UTC
 unless a time zone
 argument is specified.<a href="#section-8.1-9.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.1-10">String<a href="#section-8.1-10" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.1-11.1">
            <p id="section-8.1-11.1.1">Many values have no specific type representation and are
        interpreted as plain strings.<a href="#section-8.1-11.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.1-12">Empty Values<a href="#section-8.1-12" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.1-13.1">
            <p id="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=".<a href="#section-8.1-13.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</section>
</div>
<div id="AuthorizationAttributes">
<section id="section-8.2">
        <h3 id="name-authorization-arguments">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-authorization-arguments" class="section-name selfRef">Authorization Arguments</a>
        </h3>
<p id="section-8.2-1">
 service (String)<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-2.1">
            <p id="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 <span class="bcp14">MUST</span> always
be included.<a href="#section-8.2-2.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-3">
 protocol (String)<a href="#section-8.2-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-4.1">
            <p id="section-8.2-4.1.1">A field that may be used to indicate a subset of a service.<a href="#section-8.2-4.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-5">
 cmd (String)<a href="#section-8.2-5" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-6.1">
            <p id="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 <span class="bcp14">MUST</span> be specified if service
equals "shell".<a href="#section-8.2-6.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-8.2-6.2">
            <p id="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.<a href="#section-8.2-6.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-8.2-6.3">
            <p id="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.<a href="#section-8.2-6.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty normal" id="section-8.2-6.4">
            <p id="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.<a href="#section-8.2-6.4.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-7">
 cmd-arg (String)<a href="#section-8.2-7" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-8.1">
            <p id="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.<a href="#section-8.2-8.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-9">
 acl (Numeric)<a href="#section-8.2-9" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-10.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-8.2-10.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-11">
 inacl (String)<a href="#section-8.2-11" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-12.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-8.2-12.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-13">
 outacl (String)<a href="#section-8.2-13" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-14.1">
            <p id="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" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-8.2-14.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-15">
 addr (IP-Address)<a href="#section-8.2-15" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-16.1">
            <p id="section-8.2-16.1.1">
 A network address.<a href="#section-8.2-16.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-17">
 addr-pool (String)<a href="#section-8.2-17" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-18.1">
            <p id="section-8.2-18.1.1">
 The identifier of an address pool from which the client can assign an
 address.<a href="#section-8.2-18.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-19">
 timeout (Numeric)<a href="#section-8.2-19" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-20.1">
            <p id="section-8.2-20.1.1">
 An absolute timer for the connection (in minutes). A value of zero
 indicates no timeout.<a href="#section-8.2-20.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-21">
 idletime (Numeric)<a href="#section-8.2-21" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-22.1">
            <p id="section-8.2-22.1.1">
 An idle-timeout for the connection (in minutes). A value of zero
 indicates no timeout.<a href="#section-8.2-22.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-23">
 autocmd (String)<a href="#section-8.2-23" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-24.1">
            <p id="section-8.2-24.1.1">
An auto-command to run. Applicable only to session-based shell authorization.<a href="#section-8.2-24.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-25">
 noescape (Boolean)<a href="#section-8.2-25" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-26.1">
            <p id="section-8.2-26.1.1">
 Prevents the user from using an escape character. Applicable only to
 session-based shell authorization.<a href="#section-8.2-26.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-27">
 nohangup (Boolean)<a href="#section-8.2-27" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-28.1">
            <p id="section-8.2-28.1.1">
 Boolean. Do not disconnect after an automatic command.  Applicable
 only to session-based shell authorization.<a href="#section-8.2-28.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.2-29">
 priv-lvl (Numeric)<a href="#section-8.2-29" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.2-30.1">
            <p id="section-8.2-30.1.1">
The privilege level to be assigned. Please refer to "Privilege Levels" (<a href="#PrivilegeLevel" class="xref">Section 9</a>).<a href="#section-8.2-30.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</section>
</div>
<div id="AccountingAttributes">
<section id="section-8.3">
        <h3 id="name-accounting-arguments">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-accounting-arguments" class="section-name selfRef">Accounting Arguments</a>
        </h3>
<p id="section-8.3-1">
 The following arguments are defined for TACACS+ accounting only.  They
 <span class="bcp14">MUST</span> precede any argument-value pairs that are defined
 in "Authorization" (<a href="#Authorization" class="xref">Section 6</a>).<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<p id="section-8.3-2">
 task_id (String)<a href="#section-8.3-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-3.1">
            <p id="section-8.3-3.1.1">
 Start and stop records for the same event <span class="bcp14">MUST</span> have
 matching task_id argument values. The client <span class="bcp14">MUST</span>
 ensure that active task_ids are not duplicated; a client <span class="bcp14">MUST NOT</span> reuse a task_id in a start record until it has sent a stop
 record for that task_id.  Servers <span class="bcp14">MUST NOT</span> make
 assumptions about the format of a task_id.<a href="#section-8.3-3.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-4">
 start_time (Date Time)<a href="#section-8.3-4" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-5.1">
            <p id="section-8.3-5.1.1">
 The time the action started (in seconds since the epoch).<a href="#section-8.3-5.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-6">
 stop_time (Date Time)<a href="#section-8.3-6" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-7.1">
            <p id="section-8.3-7.1.1">
 The time the action stopped (in seconds since the epoch).<a href="#section-8.3-7.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-8">
 elapsed_time (Numeric)<a href="#section-8.3-8" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-9.1">
            <p id="section-8.3-9.1.1">
 The elapsed time in seconds for the action.<a href="#section-8.3-9.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-10">
 timezone (String)<a href="#section-8.3-10" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-11.1">
            <p id="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 <span>[<a href="#TZDB" class="xref">TZDB</a>]</span>.<a href="#section-8.3-11.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-12">
 event (String)<a href="#section-8.3-12" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-13.1">
            <p id="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 <span class="bcp14">SHOULD</span> indicate whether
the service started or stopped.<a href="#section-8.3-13.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-14">
 reason (String)<a href="#section-8.3-14" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-15.1">
            <p id="section-8.3-15.1.1">
Accompanies an event argument. It describes why the event occurred.<a href="#section-8.3-15.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-16">
 bytes (Numeric)<a href="#section-8.3-16" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-17.1">
            <p id="section-8.3-17.1.1">
 The number of bytes transferred by this action.<a href="#section-8.3-17.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-18">
 bytes_in (Numeric)<a href="#section-8.3-18" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-19.1">
            <p id="section-8.3-19.1.1">
 The number of bytes transferred by this action from the endstation to
 the client port.<a href="#section-8.3-19.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-20">
 bytes_out (Numeric)<a href="#section-8.3-20" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-21.1">
            <p id="section-8.3-21.1.1">
 The number of bytes transferred by this action from the client
 to the endstation port.<a href="#section-8.3-21.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-22">
 paks (Numeric)<a href="#section-8.3-22" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-23.1">
            <p id="section-8.3-23.1.1">
 The number of packets transferred by this action.<a href="#section-8.3-23.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-24">
 paks_in (Numeric)<a href="#section-8.3-24" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-25.1">
            <p id="section-8.3-25.1.1">
The number of input packets transferred by this action from the endstation to
the client port.<a href="#section-8.3-25.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-26">
 paks_out (Numeric)<a href="#section-8.3-26" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-27.1">
            <p id="section-8.3-27.1.1">
The number of output packets transferred by this action from the client port
to the endstation.<a href="#section-8.3-27.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="section-8.3-28">
 err_msg (String)<a href="#section-8.3-28" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-8.3-29.1">
            <p id="section-8.3-29.1.1">
 A string describing the status of the action. For details of text
 encoding, see "Treatment of Text Strings" (<a href="#TextEncoding" class="xref">Section 3.7</a>).<a href="#section-8.3-29.1.1" class="pilcrow">¶</a></p>
</li>
        </ul>
<p id="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 <span class="bcp14">MUST</span> be
configured to send an accounting start packet for every command entered,
irrespective of how the commands were authorized. These "Command Accounting"
packets <span class="bcp14">MUST</span> include the "service" and "cmd" arguments, and if needed, the
"cmd-arg" arguments detailed in <a href="#AuthorizationAttributes" class="xref">Section 8.2</a>.<a href="#section-8.3-30" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="PrivilegeLevel">
<section id="section-9">
      <h2 id="name-privilege-levels">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-privilege-levels" class="section-name selfRef">Privilege Levels</a>
      </h2>
<p id="section-9-1">
 The TACACS+ protocol supports flexible
 authorization schemes through the extensible
 arguments.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="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:<a href="#section-9-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-9-3.1">
 TAC_PLUS_PRIV_LVL_MIN :=
 0x00. The level normally
 allocated to an
 unauthenticated session.<a href="#section-9-3.1" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty normal" id="section-9-3.2">
 TAC_PLUS_PRIV_LVL_USER :=
 0x01. The level normally
 allocated to a regular
 authenticated session.<a href="#section-9-3.2" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty normal" id="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.<a href="#section-9-3.3" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty normal" id="section-9-3.4">
 TAC_PLUS_PRIV_LVL_MAX :=
 0x0f. The highest privilege
 level.<a href="#section-9-3.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="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.<a href="#section-9-4" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">SHOULD</span> be supported by
 servers.<a href="#section-9-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="TACACSSecurity">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1">
 "The Draft" <span>[<a href="#THE-DRAFT" class="xref">THE-DRAFT</a>]</span> 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.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">

 Multiple implementations of the protocol described in
 "The Draft" <span>[<a href="#THE-DRAFT" class="xref">THE-DRAFT</a>]</span>
 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.<a href="#section-10-2" class="pilcrow">¶</a></p>
<div id="SecurityofTheProtocol">
<section id="section-10.1">
        <h3 id="name-general-security-of-the-pro">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-general-security-of-the-pro" class="section-name selfRef">General Security of the Protocol</a>
        </h3>
<p id="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:<a href="#section-10.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="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.<a href="#section-10.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="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.<a href="#section-10.1-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-10.1-3">
While the protocol provides some measure of transport privacy, it is
vulnerable to at least the following attacks:<a href="#section-10.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.1-4.1">
Brute-force attacks exploiting increased efficiency of MD5 digest computation.<a href="#section-10.1-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.1-4.2">
 Known plaintext attacks that may decrease the cost of brute-force
 attacks.<a href="#section-10.1-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.1-4.3">
 Chosen plaintext attacks that may decrease the cost of a brute-force
 attacks.<a href="#section-10.1-4.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.1-4.4">
No forward secrecy.<a href="#section-10.1-4.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="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".<a href="#section-10.1-5" class="pilcrow">¶</a></p>
<p id="section-10.1-6">
 For these reasons, users deploying the TACACS+ protocol in their
 environments <span class="bcp14">MUST</span> limit access to known clients and
 <span class="bcp14">MUST</span> 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.<a href="#section-10.1-6" class="pilcrow">¶</a></p>
<p id="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.<a href="#section-10.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SecurityofAuthenticationSessions">
<section id="section-10.2">
        <h3 id="name-security-of-authentication-">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-security-of-authentication-" class="section-name selfRef">Security of Authentication Sessions</a>
        </h3>
<p id="section-10.2-1">
 Authentication sessions <span class="bcp14">SHOULD</span> be used via a secure
 transport (see "TACACS+ Best Practices" (<a href="#Bestpractices" class="xref">Section 10.5</a>)) 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.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
<p id="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 <span class="bcp14">MUST NOT</span> be used in modern
deployments. It <span class="bcp14">MUST NOT</span> be used outside a secured deployment.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SecurityofAuthorizationSessions">
<section id="section-10.3">
        <h3 id="name-security-of-authorization-s">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-security-of-authorization-s" class="section-name selfRef">Security of Authorization Sessions</a>
        </h3>
<p id="section-10.3-1">
 Authorization sessions <span class="bcp14">SHOULD</span> be used via a secure
 transport (see "TACACS+ Best Practices" (<a href="#Bestpractices" class="xref">Section 10.5</a>)) as it's trivial to execute a successful
 man-in-the-middle attack that changes well-known plaintext in either
 requests or responses.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
<p id="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:<a href="#section-10.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="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.<a href="#section-10.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="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).<a href="#section-10.3-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="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.<a href="#section-10.3-3.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="SecurityofAccountingSessions">
<section id="section-10.4">
        <h3 id="name-security-of-accounting-sess">
<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-security-of-accounting-sess" class="section-name selfRef">Security of Accounting Sessions</a>
        </h3>
<p id="section-10.4-1">Accounting sessions <span class="bcp14">SHOULD</span> be used via a secure
        transport (see "TACACS+ Best Practices" (<a href="#Bestpractices" class="xref">Section 10.5</a>)). 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:<a href="#section-10.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="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.<a href="#section-10.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="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).<a href="#section-10.4-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="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.<a href="#section-10.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Bestpractices">
<section id="section-10.5">
        <h3 id="name-tacacs-best-practices">
<a href="#section-10.5" class="section-number selfRef">10.5. </a><a href="#name-tacacs-best-practices" class="section-name selfRef">TACACS+ Best Practices</a>
        </h3>
<p id="section-10.5-1">With respect to the observations about the security issues
        described above, a network administrator <span class="bcp14">MUST NOT</span>
        rely on the obfuscation of the TACACS+ protocol. TACACS+
        <span class="bcp14">MUST</span> be used within a secure deployment; TACACS+
        <span class="bcp14">MUST</span> be deployed over networks that ensure privacy and
        integrity of the communication and <span class="bcp14">MUST</span> be deployed
        over a network that is separated from other traffic.  Failure to do
        so will impact overall network security.<a href="#section-10.5-1" class="pilcrow">¶</a></p>
<p id="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,
        <span class="bcp14">MUST</span> implement these recommendations. Vendors
        <span class="bcp14">SHOULD</span> provide mechanisms to assist the administrator
        to achieve these best practices.<a href="#section-10.5-2" class="pilcrow">¶</a></p>
<div id="SharedSecrets">
<section id="section-10.5.1">
          <h4 id="name-shared-secrets">
<a href="#section-10.5.1" class="section-number selfRef">10.5.1. </a><a href="#name-shared-secrets" class="section-name selfRef">Shared Secrets</a>
          </h4>
<p id="section-10.5.1-1">TACACS+ servers and clients <span class="bcp14">MUST</span> 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 <span class="bcp14">MUST NOT</span> leak sensitive
          data.<a href="#section-10.5.1-1" class="pilcrow">¶</a></p>
<p id="section-10.5.1-2">
For example:<a href="#section-10.5.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.5.1-3.1">
              <p id="section-10.5.1-3.1.1"> TACACS+ servers <span class="bcp14">MUST NOT</span> expose shared secrets in
logs.<a href="#section-10.5.1-3.1.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-10.5.1-3.2">
              <p id="section-10.5.1-3.2.1">TACACS+ servers <span class="bcp14">MUST</span> allow a dedicated secret key to be defined
 for each client.<a href="#section-10.5.1-3.2.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-10.5.1-3.3">
              <p id="section-10.5.1-3.3.1">TACACS+ server management systems <span class="bcp14">MUST</span> provide a
          mechanism to track secret key lifetimes and notify administrators to
          update them periodically. TACACS+ server administrators
          <span class="bcp14">SHOULD</span> change secret keys at regular intervals.<a href="#section-10.5.1-3.3.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-10.5.1-3.4">
              <p id="section-10.5.1-3.4.1">TACACS+ servers <span class="bcp14">SHOULD</span> warn administrators if
          secret keys are not unique per client.<a href="#section-10.5.1-3.4.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-10.5.1-3.5">
              <p id="section-10.5.1-3.5.1">TACACS+ server administrators <span class="bcp14">SHOULD</span> always define
          a secret for each client.<a href="#section-10.5.1-3.5.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-10.5.1-3.6">
              <p id="section-10.5.1-3.6.1">TACACS+ servers and clients <span class="bcp14">MUST</span> support shared keys that are at
 least 32 characters long.<a href="#section-10.5.1-3.6.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-10.5.1-3.7">
              <p id="section-10.5.1-3.7.1">TACACS+ servers <span class="bcp14">MUST</span> support policy to define
          minimum complexity for shared keys.<a href="#section-10.5.1-3.7.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-10.5.1-3.8">
              <p id="section-10.5.1-3.8.1">TACACS+ clients <span class="bcp14">SHOULD NOT</span> allow servers to be
          configured without a shared secret key or shared key that is less
          than 16 characters long.<a href="#section-10.5.1-3.8.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-10.5.1-3.9">
              <p id="section-10.5.1-3.9.1">TACACS+ server administrators <span class="bcp14">SHOULD</span> configure
          secret keys of a minimum of 16 characters in length.<a href="#section-10.5.1-3.9.1" class="pilcrow">¶</a></p>
</li>
          </ul>
</section>
</div>
<div id="Connections">
<section id="section-10.5.2">
          <h4 id="name-connections-and-obfuscation">
<a href="#section-10.5.2" class="section-number selfRef">10.5.2. </a><a href="#name-connections-and-obfuscation" class="section-name selfRef">Connections and Obfuscation</a>
          </h4>
<p id="section-10.5.2-1">TACACS+ servers <span class="bcp14">MUST</span> allow the definition of
          individual clients.  The servers <span class="bcp14">MUST</span> only accept
          network connection attempts from these defined known clients.<a href="#section-10.5.2-1" class="pilcrow">¶</a></p>
<p id="section-10.5.2-2">TACACS+ servers <span class="bcp14">MUST</span> reject connections
   that have
          TAC_PLUS_UNENCRYPTED_FLAG set. There <span class="bcp14">MUST</span> always be a
          shared secret set on the server for the client requesting the
          connection.<a href="#section-10.5.2-2" class="pilcrow">¶</a></p>
<p id="section-10.5.2-3">If an invalid shared secret is detected when processing packets
          for a client, TACACS+ servers <span class="bcp14">MUST NOT</span> accept any new
          sessions on that connection. TACACS+ servers <span class="bcp14">MUST</span>
          terminate the connection on completion of any sessions that were
          previously established with a valid shared secret on that
          connection.<a href="#section-10.5.2-3" class="pilcrow">¶</a></p>
<p id="section-10.5.2-4">TACACS+ clients <span class="bcp14">MUST NOT</span> set
          TAC_PLUS_UNENCRYPTED_FLAG. Clients <span class="bcp14">MUST</span> be
          implemented in a way that requires explicit configuration to enable
          the use of TAC_PLUS_UNENCRYPTED_FLAG. This option <span class="bcp14">MUST NOT</span> be used when the client is in production.<a href="#section-10.5.2-4" class="pilcrow">¶</a></p>
<p id="section-10.5.2-5">When a TACACS+ client receives responses from servers where:<a href="#section-10.5.2-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="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<a href="#section-10.5.2-6.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="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,<a href="#section-10.5.2-6.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-10.5.2-7">the TACACS+ client <span class="bcp14">MUST</span> 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.<a href="#section-10.5.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="AuthenticationRecommendations">
<section id="section-10.5.3">
          <h4 id="name-authentication-2">
<a href="#section-10.5.3" class="section-number selfRef">10.5.3. </a><a href="#name-authentication-2" class="section-name selfRef">Authentication</a>
          </h4>
<p id="section-10.5.3-1">To help TACACS+ administrators select stronger authentication
          options, TACACS+ servers <span class="bcp14">MUST</span> 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).<a href="#section-10.5.3-1" class="pilcrow">¶</a></p>
<p id="section-10.5.3-2">TACACS+ server administrators <span class="bcp14">SHOULD</span> enable the
          option mentioned in the previous paragraph.

   TACACS+ server deployments <span class="bcp14">SHOULD</span> 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.<a href="#section-10.5.3-2" class="pilcrow">¶</a></p>
<p id="section-10.5.3-3">TACACS+ server administrators <span class="bcp14">SHOULD NOT</span> 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.<a href="#section-10.5.3-3" class="pilcrow">¶</a></p>
<p id="section-10.5.3-4">TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options
          mentioned in "The Draft" <span class="bcp14">SHOULD NOT</span> be used due to their security implications. TACACS+
          servers <span class="bcp14">SHOULD NOT</span> implement them.  If they must be
          implemented, the servers <span class="bcp14">MUST</span> default to the options
          being disabled and <span class="bcp14">MUST</span> warn the administrator that
          these options are not secure.<a href="#section-10.5.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="AuthorizationRecommendations">
<section id="section-10.5.4">
          <h4 id="name-authorization-2">
<a href="#section-10.5.4" class="section-number selfRef">10.5.4. </a><a href="#name-authorization-2" class="section-name selfRef">Authorization</a>
          </h4>
<p id="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 <span class="bcp14">MUST</span> ensure that the argument and
          value pairs shared between the clients and servers have consistent
          interpretation.<a href="#section-10.5.4-1" class="pilcrow">¶</a></p>
<p id="section-10.5.4-2">TACACS+ clients that receive an unrecognized mandatory argument
          <span class="bcp14">MUST</span> evaluate server response as if they received
          TAC_PLUS_AUTHOR_STATUS_FAIL.<a href="#section-10.5.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="RedirectionMechanism">
<section id="section-10.5.5">
          <h4 id="name-redirection-mechanism">
<a href="#section-10.5.5" class="section-number selfRef">10.5.5. </a><a href="#name-redirection-mechanism" class="section-name selfRef">Redirection Mechanism</a>
          </h4>
<p id="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.<a href="#section-10.5.5-1" class="pilcrow">¶</a></p>
<p id="section-10.5.5-2">TACACS+ servers <span class="bcp14">MUST</span> deprecate the redirection mechanism.<a href="#section-10.5.5-2" class="pilcrow">¶</a></p>
<p id="section-10.5.5-3">If the redirection mechanism is implemented, then TACACS+ servers
          <span class="bcp14">MUST</span> disable it by default and <span class="bcp14">MUST</span>
          warn TACACS+ server administrators that it must only be enabled
          within a secure deployment due to the risks of revealing shared
          secrets.<a href="#section-10.5.5-3" class="pilcrow">¶</a></p>
<p id="section-10.5.5-4">TACACS+ clients <span class="bcp14">SHOULD</span> deprecate this feature by treating
 TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.<a href="#section-10.5.5-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="IANAConsiderations">
<section id="section-11">
      <h2 id="name-iana-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-11-1">This document has no IANA actions.<a href="#section-11-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-12">
      <h2 id="name-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-normative-references">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC0020">[RFC0020]</dt>
        <dd>
<span class="refAuthor">Cerf, V.</span>, <span class="refTitle">"ASCII format for network interchange"</span>, <span class="seriesInfo">STD 80</span>, <span class="seriesInfo">RFC 20</span>, <span class="seriesInfo">DOI 10.17487/RFC0020</span>, <time datetime="1969-10" class="refDate">October 1969</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc20">https://www.rfc-editor.org/info/rfc20</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1321">[RFC1321]</dt>
        <dd>
<span class="refAuthor">Rivest, R.</span>, <span class="refTitle">"The MD5 Message-Digest Algorithm"</span>, <span class="seriesInfo">RFC 1321</span>, <span class="seriesInfo">DOI 10.17487/RFC1321</span>, <time datetime="1992-04" class="refDate">April 1992</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1321">https://www.rfc-editor.org/info/rfc1321</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1334">[RFC1334]</dt>
        <dd>
<span class="refAuthor">Lloyd, B.</span><span class="refAuthor"> and W. Simpson</span>, <span class="refTitle">"PPP Authentication Protocols"</span>, <span class="seriesInfo">RFC 1334</span>, <span class="seriesInfo">DOI 10.17487/RFC1334</span>, <time datetime="1992-10" class="refDate">October 1992</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1334">https://www.rfc-editor.org/info/rfc1334</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2433">[RFC2433]</dt>
        <dd>
<span class="refAuthor">Zorn, G.</span><span class="refAuthor"> and S. Cobb</span>, <span class="refTitle">"Microsoft PPP CHAP Extensions"</span>, <span class="seriesInfo">RFC 2433</span>, <span class="seriesInfo">DOI 10.17487/RFC2433</span>, <time datetime="1998-10" class="refDate">October 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2433">https://www.rfc-editor.org/info/rfc2433</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2759">[RFC2759]</dt>
        <dd>
<span class="refAuthor">Zorn, G.</span>, <span class="refTitle">"Microsoft PPP CHAP Extensions, Version 2"</span>, <span class="seriesInfo">RFC 2759</span>, <span class="seriesInfo">DOI 10.17487/RFC2759</span>, <time datetime="2000-01" class="refDate">January 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2759">https://www.rfc-editor.org/info/rfc2759</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3579">[RFC3579]</dt>
        <dd>
<span class="refAuthor">Aboba, B.</span><span class="refAuthor"> and P. Calhoun</span>, <span class="refTitle">"RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)"</span>, <span class="seriesInfo">RFC 3579</span>, <span class="seriesInfo">DOI 10.17487/RFC3579</span>, <time datetime="2003-09" class="refDate">September 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3579">https://www.rfc-editor.org/info/rfc3579</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4086">[RFC4086]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor">, Schiller, J.</span><span class="refAuthor">, and S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4120">[RFC4120]</dt>
        <dd>
<span class="refAuthor">Neuman, C.</span><span class="refAuthor">, Yu, T.</span><span class="refAuthor">, Hartman, S.</span><span class="refAuthor">, and K. Raeburn</span>, <span class="refTitle">"The Kerberos Network Authentication Service (V5)"</span>, <span class="seriesInfo">RFC 4120</span>, <span class="seriesInfo">DOI 10.17487/RFC4120</span>, <time datetime="2005-07" class="refDate">July 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4120">https://www.rfc-editor.org/info/rfc4120</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5952">[RFC5952]</dt>
        <dd>
<span class="refAuthor">Kawamura, S.</span><span class="refAuthor"> and M. Kawashima</span>, <span class="refTitle">"A Recommendation for IPv6 Address Text Representation"</span>, <span class="seriesInfo">RFC 5952</span>, <span class="seriesInfo">DOI 10.17487/RFC5952</span>, <time datetime="2010-08" class="refDate">August 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5952">https://www.rfc-editor.org/info/rfc5952</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8265">[RFC8265]</dt>
      <dd>
<span class="refAuthor">Saint-Andre, P.</span><span class="refAuthor"> and A. Melnikov</span>, <span class="refTitle">"Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords"</span>, <span class="seriesInfo">RFC 8265</span>, <span class="seriesInfo">DOI 10.17487/RFC8265</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8265">https://www.rfc-editor.org/info/rfc8265</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-12.2">
        <h3 id="name-informative-references">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="KRB4">[KRB4]</dt>
        <dd>
<span class="refAuthor">Miller, S.</span><span class="refAuthor">, Neuman, C.</span><span class="refAuthor">, Schiller, J.</span><span class="refAuthor">, and J. Saltzer</span>, <span class="refTitle">"Section E.2.1: Kerberos Authentication and Authorization System"</span>, <span class="refContent">MIT Project Athena</span>, <span class="refContent">Cambridge, Massachusetts</span>, <time datetime="1987-12" class="refDate">December 1987</time>. </dd>
<dd class="break"></dd>
<dt id="THE-DRAFT">[THE-DRAFT]</dt>
        <dd>
<span class="refAuthor">Carrel, D.</span><span class="refAuthor"> and L. Grant</span>, <span class="refTitle">"The TACACS+ Protocol Version 1.78"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-grant-tacacs-02</span>, <time datetime="1997-01" class="refDate">January 1997</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-grant-tacacs-02">https://tools.ietf.org/html/draft-grant-tacacs-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="TZDB">[TZDB]</dt>
      <dd>
<span class="refAuthor">Eggert, P.</span><span class="refAuthor"> and A. Olson</span>, <span class="refTitle">"Sources for Time Zone and Daylight Saving Time Data"</span>, <time datetime="1987" class="refDate">1987</time>, <span>&lt;<a href="https://www.iana.org/time-zones">https://www.iana.org/time-zones</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">The authors would like to thank the following reviewers whose
      comments and contributions made considerable improvements to this
      document: <span class="contact-name">Alan DeKok</span>, <span class="contact-name">Alexander       Clouter</span>, <span class="contact-name">Chris Janicki</span>, <span class="contact-name">Tom Petch</span>,
      <span class="contact-name">Robert Drake</span>, and <span class="contact-name">John Heasley</span>, among many others.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">
 The authors would particularly like to thank
 <span class="contact-name">Alan DeKok</span>, who provided
 significant insights and recommendations on
 all aspects of the document and the
 protocol. <span class="contact-name">Alan DeKok</span> has
 dedicated considerable time and effort to help
 improve the document, identifying weaknesses
 and providing remediation.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">The authors would also like to thank the support from the OPSAWG
      Chairs and advisors, especially <span class="contact-name">Joe Clarke</span>.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Thorsten Dahm</span></div>
<div dir="auto" class="left"><span class="org">Google Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">1600 Amphitheatre Parkway</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>, <span class="region">CA</span> <span class="postal-code">94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:thorstendlux@google.com" class="email">thorstendlux@google.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Andrej Ota</span></div>
<div dir="auto" class="left"><span class="org">Google Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">1600 Amphitheatre Parkway</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>, <span class="region">CA</span> <span class="postal-code">94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:andrej@ota.si" class="email">andrej@ota.si</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Douglas C. Medway Gash</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">170 West Tasman Dr.</span></div>
<div dir="auto" class="left">
<span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95134</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:dcmgash@cisco.com" class="email">dcmgash@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">David Carrel</span></div>
<div dir="auto" class="left"><span class="org">IPsec Research</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:carrel@ipsec.org" class="email">carrel@ipsec.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Lol Grant</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:lol.grant@gmail.com" class="email">lol.grant@gmail.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>