skip to content

Why must a TACACS+ server's authorization policy not branch on the authen_method value in the REQUEST?

level: seniorimportance: nice to knowfreq 24%

answer

  1. one octet, filled in by the device
  2. an assertion, not evidence
  3. the server never saw that authentication
  4. specification says not for policy
  5. fine for diagnosis, not for decisions

basics

~20 s

Because authen_method is the network device's own unverified claim about how the user was authenticated. RFC 8907 states the information is not always subject to verification and MUST NOT be used in policy evaluation; the server has no way to confirm it.

solid answer

~30 s

The authorization REQUEST's fixed part carries `authen_method`, an enumeration saying how the device believes the user was authenticated — `TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06`, `TAC_PLUS_AUTHEN_METH_LOCAL := 0x05`, `TAC_PLUS_AUTHEN_METH_LINE := 0x03`, `TAC_PLUS_AUTHEN_METH_ENABLE := 0x04`, `TAC_PLUS_AUTHEN_METH_KRB5 := 0x02`, `TAC_PLUS_AUTHEN_METH_RADIUS := 0x10` and others. It is informational: the device fills it in, nothing in the exchange corroborates it, and RFC 8907 says that because the information is not always subject to verification it MUST NOT be used in policy evaluation. A server that grants more to a session claiming `TACACSPLUS` than to one claiming `LINE` is trusting a field it cannot check.

go deeper

for a junior

Know that the field exists, that it says how the device believes the user was authenticated, and that it is informational.

for a middle

Explain that the device fills it in and nothing in the two-packet exchange corroborates it, which is why the specification keeps it out of policy evaluation.

for a senior

Recognise policy that branches on it as a finding, and be able to propose what to key on instead — the identity, the request's arguments, and the server's own record.

for a principal

Generalise the habit: in an estate, ask of every field who asserted it and who verified it, and keep decisions on the verified ones.

## What the field carries Every TACACS+ authorization REQUEST begins with `authen_method`, one octet describing **how the device says this user was authenticated** before the request was made. The enumeration is: - `TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00` - `TAC_PLUS_AUTHEN_METH_NONE := 0x01` - `TAC_PLUS_AUTHEN_METH_KRB5 := 0x02` - `TAC_PLUS_AUTHEN_METH_LINE := 0x03` - `TAC_PLUS_AUTHEN_METH_ENABLE := 0x04` - `TAC_PLUS_AUTHEN_METH_LOCAL := 0x05` - `TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06` - `TAC_PLUS_AUTHEN_METH_GUEST := 0x08` - `TAC_PLUS_AUTHEN_METH_RADIUS := 0x10` - `TAC_PLUS_AUTHEN_METH_KRB4 := 0x11` - `TAC_PLUS_AUTHEN_METH_RCMD := 0x20` Read the list and the range of trust it spans is obvious: at one end a session the device says it authenticated against this very server, at the other a session it says was let in on a line password, or with no authentication at all. ## Why the specification forbids policy on it RFC 8907 is explicit: because the information is **not always subject to verification**, `authen_method` MUST NOT be used in policy evaluation. The reasoning is structural rather than cryptographic: 1. **The device fills the field in.** It is an assertion by one party about its own earlier behaviour. 2. **Nothing in this exchange corroborates it.** Authorization is a two-packet exchange with no callback and no reference to an authentication session, so the server cannot tie the claim to anything it saw. 3. **Some of the values describe events the server never witnessed at all.** A session the device says was authenticated locally, or by a different protocol entirely, leaves no trace the server can check. Even the most reassuring value is only a claim: `TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06` says the device believes it authenticated the user against a device-administration server, and a server reading that value is reading a sentence, not a proof. ## What a policy should key on instead - **The identity and the request.** The user, the `service`, the `cmd` and `cmd-arg` values, and the privilege level the session carries — the things the decision is actually about. - **Which device is asking.** The request arrives on a connection the server has already associated with a configured client, so the server's own view of which box this is does not depend on anything inside the body. - **The server's own record of what it authenticated.** If a deployment wants "only sessions this server authenticated may run destructive commands", the honest way is for the server to know it authenticated them, not to read the device's claim that it did. ## The neighbouring field with the same smell `authen_type` sits beside it and carries the same caution in a smaller way. The value `TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00` is **valid only in authorization and accounting requests** — the protocol explicitly allows a device to say nothing here. A policy that expects a meaningful authentication type in every authorization request is expecting something the specification does not require the device to supply. ## What the field is good for Not nothing. It is useful for **understanding** an estate — reading which of your devices claim which method, spotting a box that reports `NONE` when every other one reports otherwise, noticing a fleet that never moved off a line password. That is diagnosis, and diagnosis is allowed to work from unverified claims as long as it treats them as claims. The prohibition is specifically on letting the value change an access decision. ## Why this is a differentiator rather than a must-know Most candidates never read past the argument list, and nothing in day-to-day operation makes the field's status visible: a policy that branches on `authen_method` works perfectly, right up until the claim is not what the server assumed. A candidate who can say *this field is an assertion by the party being governed, and the specification says so* has demonstrated the habit that matters across the whole branch — asking who asserted each value and whether anyone checked it.

  • Is `TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06` any more trustworthy than the other values?
    No. It is still the device's statement about an exchange this authorization request does not reference. The reassuring value and the alarming one arrive by the same route, with the same amount of corroboration behind them, which is none.
  • May a server use `authen_method` for anything at all?
    For understanding rather than deciding. Reading it to see which devices report which methods, or to notice one box claiming something unusual, is fine — the prohibition is on letting the value change an authorization outcome.
  • What does `TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00` mean in an authorization REQUEST?
    That the device is not stating an authentication type. The value is valid only in authorization and accounting requests, so policy cannot assume every authorization request names a type it can reason about.

saying these in an interview costs you the question

  • Grants more privilege to a session claiming a stronger method
  • Calls authen_method proof of how the user authenticated
  • Thinks the server sets authen_method and reads it back
  • Assumes every authorization request names an authentication type
  • Says the field is useless and should be ignored entirely