skip to content

Why can TACACS+ authorize each command an operator types while RADIUS decides once at admission?

level: middleimportance: should knowfreq 48%

answer

  1. three exchanges against one
  2. when is the question asked
  3. attributes on an accept, once
  4. a fresh exchange per typed command
  5. only the server reopens a RADIUS decision

basics

~20 s

TACACS+ keeps authentication, authorization and accounting as separate exchanges, so a device can open a fresh authorization exchange per command. RADIUS merges the first two: one Access-Request, one Access-Accept, and the authorization arrives as attributes on the accept.

solid answer

~50 s

The split is the reason. In TACACS+ an authorization exchange is its own request and response with its own `session_id`, unrelated to the authentication that preceded it, so a device configured for command authorization can open one whenever it likes — in practice before running each command the operator types, carrying `service=shell`, `cmd` and `cmd-arg` pairs and applying the `PASS_ADD` or `FAIL` it gets back. RADIUS merges authentication and authorization: the `Access-Request` is answered by an `Access-Accept` whose attributes *are* the authorization, fixed for the session, or by an `Access-Reject` (with `Access-Challenge` available when the authentication itself needs another round trip). After that, the only way the RADIUS server revisits the decision is the **RFC 5176** dynamic-authorization exchange — a `CoA-Request` or a `Disconnect-Request` it initiates — which changes or ends the session rather than answering a per-action question.

code

pseudocode · 16 lines
pseudocode
// TACACS+ - a fresh authorization exchange for each command, when the device is configured for it
operator asks to read the interface list
  device  -> authorization REQUEST  { service=shell, cmd=show, cmd-arg=interfaces }
  server  -> authorization RESPONSE { status = PASS_ADD }        // permitted
  device runs it

operator asks to enter a configuration mode
  device  -> authorization REQUEST  { service=shell, cmd=configure }
  server  -> authorization RESPONSE { status = FAIL }            // refused
  device declines to run it

// RADIUS - one decision at admission, then attributes describe the whole session
  device  -> Access-Request  { User-Name, NAS-IP-Address, ... }
  server  -> Access-Accept   { Filter-Id, Session-Timeout, ... }
  // no further question is asked; the server may only revisit the session by
  // sending a CoA-Request or a Disconnect-Request of its own (RFC 5176)

go deeper

for a junior

Recall the difference in when the question is asked: once at login for RADIUS, and potentially once per command for TACACS+. Knowing that the separate exchanges are what make the second possible is enough at this stage.

for a middle

Explain the mechanism both ways — an authorization exchange that stands alone against authorization carried as attributes on an accept — and know that the dynamic-authorization exchange is the coarse way RADIUS revisits a live session.

for a senior

Bring the cost. Latency and load that scale with typing, a much larger record volume, the server sitting on the critical path of every action, and command sets that drift away from what operators actually type.

for a principal

Frame it as where you want policy to live and how much availability you are willing to spend on it. Per-action central decisions buy an audit story and cost you a hard runtime dependency on a plane that must then be engineered for it.

## Three exchanges against one The letters in *AAA* stand for three things, and the two protocols disagree about whether they are three conversations or one. TACACS+ treats them as three. Authentication, authorization and accounting each have their own packet family and their own exchange, each identified by its own `session_id`. An authorization exchange is not a continuation of an authentication; it is a new question, asked whenever the device has something to ask about. RADIUS merges authentication and authorization into a single transaction. A network access server sends one `Access-Request`; the server answers `Access-Accept` or `Access-Reject`, and when it needs more input from the user first it answers `Access-Challenge` and the conversation continues toward the same single verdict. Accounting is its own exchange on its own port, but the decision itself is one round trip. ## What per-command authorization looks like Because an authorization exchange stands alone, a device can be configured to run one before executing each command it is given. The request carries argument-value pairs naming what is being attempted — a `service`, a `cmd`, and the `cmd-arg` values belonging to it — and the response is a status the device applies: permit it, or refuse it. Three consequences follow directly: - **The policy lives centrally and is about actions.** What an operator may do is expressed as command sets on the server, not as a number handed to the device once. - **The record is per action.** Because accounting is also its own exchange, a record can be written for each command rather than for each login. - **The server is on the critical path of every action**, not just of the login. That is the bill. ## Where RADIUS puts the same decision In RADIUS the authorization *is* the set of attributes on the `Access-Accept`: what the session may reach, how long it may last, what profile applies. It is computed once, at the moment of admission, from what the server knew then. Nothing in the protocol asks a second question, because there is no second question to ask — the accept described the session, and the session proceeds under that description. ## The one way RADIUS reopens it **RFC 5176** adds dynamic authorization, and it is the answer to 'so RADIUS can never change its mind?'. The RADIUS server sends a `CoA-Request` to change an existing session's attributes, or a `Disconnect-Request` to terminate it; each is answered with an ACK or a NAK. Two things about it matter for this comparison: 1. **The roles reverse.** The server initiates and the network access server answers, which is the opposite of the admission exchange. 2. **It is coarse.** It reauthorizes or ends *a session*. It does not answer 'may this particular action proceed?', which is what a per-command exchange answers. ## Side by side | | TACACS+ | RADIUS | |---|---|---| | Authentication and authorization | separate exchanges | merged into one transaction | | Where authorization is expressed | argument-value pairs in its own exchange | attributes on the Access-Accept | | When the decision is taken | whenever the device asks, possibly per command | once, at admission | | Revisiting it later | ask again | only a server-initiated CoA-Request or Disconnect-Request | | Granularity of a later change | one action | the whole session | | Who initiates the later change | the device | the server | ## What the fine granularity costs A candidate who only sells the benefit has not finished the answer. Per-command authorization means: - **A round trip before every command**, so operator-visible latency and server load scale with typing rather than with logins. - **Far more traffic and far more records**, which is the point for audit and a real capacity question for the server estate. - **A dependency at the worst moment.** When a server stops answering, the question is no longer 'can someone log in' but 'can someone who is already logged in do anything', and the device needs a defined behaviour for that case. - **A larger policy surface.** Command sets drift, and a set written for one generation of a platform quietly stops matching what operators actually type. ## The shape of a good answer Say that the split is the enabling mechanism, not a feature bolted on; say where RADIUS puts the same information instead; name the dynamic-authorization exchange as the genuine, coarse counter-example rather than claiming RADIUS is frozen after the accept; and finish with the cost, because an interviewer asking this on a device-administration leaf is usually deciding whether you have run it rather than read about it.

  • What does per-command authorization cost that an admission-time decision does not?
    A round trip to the server before every command, so latency and load scale with typing rather than with logins; a much larger volume of records; a policy expressed as command sets that must be maintained; and a hard dependency, because the server is now on the critical path of every action rather than only of the login.
  • Can a RADIUS server change a decision after the session is up?
    Yes, but only on its own initiative. RFC 5176 defines a `CoA-Request` to change the session's attributes and a `Disconnect-Request` to end it, each answered with an ACK or a NAK, with the roles reversed from the admission exchange. It is session-scoped: reauthorize or drop, not a per-action verdict.
  • What is an Access-Challenge, and does it split authorization into its own exchange?
    It is the RADIUS server asking the network access server to collect more from the user and send another `Access-Request`. It extends the authentication conversation toward one eventual accept or reject; it does not make authorization a separate exchange, so the merged model is unchanged.

saying these in an interview costs you the question

  • Says RADIUS cannot do authorization at all
  • Claims the device decides each command locally from a privilege number
  • Believes an Access-Challenge is a separate authorization exchange
  • Assumes a CoA-Request can approve or refuse a single command
  • Thinks three exchanges implies three separate servers
  • Treats per-command authorization as free once the connection is open