skip to content

In a TACACS+ authentication exchange, which side decides that another prompt is needed, and how does the network device learn what to ask?

level: middleimportance: must knowfreq 52%

answer

  1. the far end drives the turn
  2. three bodies, one session
  3. the status byte is an instruction
  4. GETUSER, GETPASS, GETDATA continue it
  5. server_msg is the prompt text

basics

~20 s

The device-administration server decides. Its REPLY carries a status — GETUSER, GETPASS or GETDATA — and a server_msg the network device displays as the prompt; the device answers with one CONTINUE and waits for the next REPLY.

solid answer

~40 s

A TACACS+ authentication session has exactly three body types. The network device — which is the TACACS+ client — opens it with a `START`. Only the server sends a `REPLY`, and only the device sends a `CONTINUE`. Every REPLY carries a status byte that is an instruction: `TAC_PLUS_AUTHEN_STATUS_PASS` or `_FAIL` end the sequence, while `_GETUSER`, `_GETPASS` and `_GETDATA` say the server wants one more value and the exchange continues. With those three the server SHOULD supply `server_msg`, the text the device prints; the device collects what the operator types and returns it as `user_msg` in a CONTINUE. `TAC_PLUS_REPLY_FLAG_NOECHO` tells the device not to display what is typed next, which is how a password prompt is marked. The device can walk away at any turn by setting `TAC_PLUS_CONTINUE_FLAG_ABORT`. The device never chooses the questions.

code

pseudocode · 26 lines
pseudocode
device -> server: AUTHEN START
    action         = TAC_PLUS_AUTHEN_LOGIN
    priv_lvl       = TAC_PLUS_PRIV_LVL_USER
    authen_type    = TAC_PLUS_AUTHEN_TYPE_ASCII
    authen_service = TAC_PLUS_AUTHEN_SVC_LOGIN
    user_len       = 0
    port           = "tty10"
    rem_addr       = "198.51.100.7"

server -> device: AUTHEN REPLY
    status     = TAC_PLUS_AUTHEN_STATUS_GETUSER
    server_msg = "Username: "

device -> server: AUTHEN CONTINUE
    user_msg = "deck-engineer"

server -> device: AUTHEN REPLY
    status     = TAC_PLUS_AUTHEN_STATUS_GETPASS
    flags      = TAC_PLUS_REPLY_FLAG_NOECHO
    server_msg = "Password: "

device -> server: AUTHEN CONTINUE
    user_msg = <what the operator typed>

server -> device: AUTHEN REPLY
    status = TAC_PLUS_AUTHEN_STATUS_PASS

go deeper

for a junior

Remember the shape: the device relays, the central server decides. The device sends one START, then answers whatever the server asks for, one value at a time.

for a middle

Be able to name the three bodies, say which side sends each, and explain that the REPLY status is an instruction — PASS and FAIL end it, GETUSER, GETPASS and GETDATA continue it with the prompt text in server_msg.

for a senior

Show that you have felt the cost: each prompt is a round trip, so a policy that asks for three values makes a slow link feel broken, and the number of turns is the server's choice, not the device's.

for a principal

The tradeoff to weigh is where the prompting policy lives. Centralising it means a device fleet you never touch when the policy changes, bought with a login path that fails whenever the central server is unreachable.

## The three bodies of one authentication session TACACS+ splits authentication, authorization and accounting into separate exchanges. The authentication exchange is a conversation, and it is built from exactly three packet bodies: - **START** — sent only by the network device, which in TACACS+ is the client: any device that initiates protocol requests. It opens one authentication session and carries `action`, `priv_lvl`, `authen_type`, `authen_service`, and the `user`, `port`, `rem_addr` and `data` fields with their lengths. - **REPLY** — sent only by the device-administration server. It carries a `status` byte, a flags byte, `server_msg` and `data`. - **CONTINUE** — sent only by the device. It carries `user_msg`, `data` and its own flags byte. The operator is not a party to the protocol. The human types at a terminal line on the device; the device relays. Nothing in the exchange lets the device decide, on its own authority, that a password should be asked for next. ## The status byte is an instruction, not a report Everything about who speaks next is encoded in one byte of the REPLY. It falls into three groups: | REPLY status | What it says | Does the exchange continue? | |---|---|---| | `TAC_PLUS_AUTHEN_STATUS_PASS` | The operator is authenticated | No — the sequence is over | | `TAC_PLUS_AUTHEN_STATUS_FAIL` | Processing completed; the answer is no | No | | `TAC_PLUS_AUTHEN_STATUS_GETUSER` | Send me a username | Yes, in a CONTINUE | | `TAC_PLUS_AUTHEN_STATUS_GETPASS` | Send me a password | Yes, in a CONTINUE | | `TAC_PLUS_AUTHEN_STATUS_GETDATA` | Send me some other value | Yes, in a CONTINUE | | `TAC_PLUS_AUTHEN_STATUS_RESTART` | The chosen `authen_type` is unacceptable; begin again | Not this sequence | | `TAC_PLUS_AUTHEN_STATUS_ERROR` | Processing did not complete | No — and it is not an answer | | `TAC_PLUS_AUTHEN_STATUS_FOLLOW` | Deprecated redirection | Treat it as a refusal | The three `GET*` values are what makes this protocol a conversation. The server may ask for a username, then a password, then something else again, and the device cannot predict the sequence — that is the point. A second-factor value, a changed password, a challenge response: all of them arrive through the same loop, and the device needs no knowledge of what the server's policy is. ## How one login actually runs 1. The device sends a START with `action` set to `TAC_PLUS_AUTHEN_LOGIN`, `authen_service` set to `TAC_PLUS_AUTHEN_SVC_LOGIN` and `authen_type` set to `TAC_PLUS_AUTHEN_TYPE_ASCII`. The username is optional here: the device may set the user field's length to zero and let the server ask. 2. The server replies `GETUSER` with `server_msg` holding the prompt text. 3. The device prints that text verbatim, reads a line, and returns it as `user_msg` in a CONTINUE. 4. The server replies `GETPASS`, setting `TAC_PLUS_REPLY_FLAG_NOECHO` in the REPLY's flags so the device does not display what is typed. 5. The device returns the typed value in another CONTINUE. 6. The server replies `PASS` or `FAIL`. That is three round trips for one login, and the server may spend more. On a satellite link to a vessel at sea, where a round trip is measured in hundreds of milliseconds, the flexibility that makes the protocol useful is also what the operator feels as a slow login. The number of turns is a property of the server's policy, not of the device. ## Prompt text, echo, and giving up Two details carry more weight than their size suggests: - **`server_msg` is the prompt.** The device is expected to display it rather than substitute wording of its own, which is how a server can ask for something the device has no name for. - **`TAC_PLUS_REPLY_FLAG_NOECHO` is a REPLY flag**, distinct from the header's flags byte and from the CONTINUE flags. It asks the device not to echo the operator's next input to the terminal. It is a display instruction and nothing more: it does not change how the value travels. - **`TAC_PLUS_CONTINUE_FLAG_ABORT`** lets the device end the sequence from its side — the operator pressed the interrupt key, or the terminal line dropped. The `data` field of that CONTINUE carries the reason. ## What this exchange does not settle The 12-byte header these bodies travel in, the sequence numbering and the `session_id` that names the session belong to the wire-format subject. How the body is protected on the way — and whether that protection deserves the word encryption — belongs to the payload-protection subject. And a `PASS` says only that the operator is who they claim to be: what they are then allowed to type is decided by a separate authorization exchange, with its own REQUEST, its own REPLY and its own status enumeration.

  • What stops the exchange from prompting an operator forever?
    Nothing in the status enumeration bounds it — the server may keep answering with `GETDATA`. The limit is on the device's side: it ends the sequence by sending a CONTINUE with `TAC_PLUS_CONTINUE_FLAG_ABORT` set, carrying a reason in the data field, which is also what an interrupt key or a dropped terminal line produces.
  • Does the device learn why the server asked for another value?
    Only through `server_msg`, which it displays verbatim. The status distinguishes a username from a password from some other value, and nothing more: `GETDATA` covers a second-factor code, a challenge response or a new password alike. The device carries no model of the server's policy, which is exactly why the policy can change without touching the device.
  • If the operator's credential is disabled mid-shift, does this exchange end their shell session on the device?
    No. The authentication exchange runs once, at the front of the login, and only the device may open it — there is no server-initiated message in it. An established shell session is untouched. Whether the next command the operator types is still permitted is decided by the separate per-command authorization exchange, not here.

The network device is a speaking tube, not a gatekeeper: it relays whatever the far end asks for and reads back what is typed, without ever knowing which question is coming next.

saying these in an interview costs you the question

  • Says the network device decides which prompts to display
  • Thinks the username and password always travel in the START
  • Calls each prompt a new authentication session
  • Assumes any REPLY ends the sequence
  • Treats server_msg as a value the device must parse rather than print