skip to content

Authentication Exchange

3 roadmaps5 questions

The START, REPLY and CONTINUE exchange that lets the server prompt for a username, then a password, then more, plus PAP, CHAP and enable escalation. Asked because RADIUS cannot hold that conversation.

on this pageshow

explore

questions

5

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
open as a page

A device-administration server answers a TACACS+ authentication START with status ERROR rather than FAIL — what changes for the network device?

level: seniorimportance: must knowfreq 44%

basics

~20 s

FAIL is an answer: processing completed and the login is refused. ERROR is the absence of one — the server could not complete, the device has no result to apply, and it must behave as if that server had never been reachable.

open as a page

In a TACACS+ authentication START, what does authen_type ASCII commit the exchange to that PAP does not?

level: middleimportance: should knowfreq 40%

basics

~20 s

ASCII commits the exchange to a conversation: the START need carry no credential at all, and the server collects each value over REPLY and CONTINUE turns. PAP carries username and password in the START, so one REPLY settles it.

open as a page

In TACACS+, how does a network device ask whether an operator may move to a higher privilege level?

level: seniorimportance: should knowfreq 36%

basics

~20 s

By opening a second authentication session. The device sends a fresh START with authen_service set to TAC_PLUS_AUTHEN_SVC_ENABLE and the level it wants in the header's priv_lvl field. The protocol requires no earlier successful login for it.

open as a page

What does a TACACS+ authentication REPLY with status RESTART ask of the network device, and what if it cannot comply?

level: seniorimportance: nice to knowfreq 24%

basics

~20 s

RESTART says the authentication type the device chose is unacceptable, and the sequence may begin again from a fresh START — typically with a different authen_type. A device that does not implement RESTART must process it as FAIL.

open as a page