skip to content

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

level: middleimportance: should knowfreq 40%

answer

  1. one field decides the conversation's length
  2. ASCII may start with no username
  3. a credential in the START ends the asking
  4. GET statuses only reach an ASCII sequence
  5. the restriction is a server MUST

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.

solid answer

~40 s

`authen_type` in the START says what kind of credential the sequence will use, and it decides how many packets the sequence takes. With `TAC_PLUS_AUTHEN_TYPE_ASCII` the device may send the user field's length as zero and let the server ask: the server drives with `GETUSER`, `GETPASS` and `GETDATA`, and can extend the conversation as far as its policy needs. With `TAC_PLUS_AUTHEN_TYPE_PAP` the username is in the user field and the password is already in the START's `data` field, so the server has nothing left to ask for and answers. `TAC_PLUS_AUTHEN_TYPE_CHAP`, `_MSCHAP` and `_MSCHAPV2` are the same shape — the challenge and the response arrive together in `data`. RFC 8907 requires a server to let an administrator restrict which of these it will accept.

code

pseudocode · 13 lines
pseudocode
# ASCII: the START may carry nothing but context
device -> server: AUTHEN START
    authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
    user_len    = 0
    data_len    = 0
# -> server replies GETUSER, then GETPASS, then decides

# PAP: the START already carries the credential
device -> server: AUTHEN START
    authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
    user        = "deck-engineer"
    data        = <password>
# -> server replies PASS or FAIL; there is nothing to ask for

go deeper

for a junior

Hold on to one contrast: with ASCII the device starts with almost nothing and the far end asks for what it needs; with PAP the device hands over the username and password at once.

for a middle

Explain that the field fixes the packet count. ASCII leaves the GET statuses available to the server; PAP and the challenge/response types deliver the credential in the START's data field, so one REPLY ends it.

for a senior

Know what the specification obliges: the server must offer a way to restrict the accepted types, the administrator should turn it on, and one credential should not be usable in both a challenge-based and a non-challenge-based type.

for a principal

The estate-level question is whether narrowing the accepted set is worth the devices it strands. Every appliance that can only present the weaker form has to be replaced, re-homed or exempted, and the exemption is where the policy quietly dies.

## What authen_type actually selects The `authen_type` field in an authentication START names the credential form the sequence will use. The values a device-administration server meets are: - `TAC_PLUS_AUTHEN_TYPE_NOT_SET` — unset; - `TAC_PLUS_AUTHEN_TYPE_ASCII` — an inband login the server conducts as a conversation; - `TAC_PLUS_AUTHEN_TYPE_PAP` — a username and a cleartext password supplied up front; - `TAC_PLUS_AUTHEN_TYPE_CHAP`, `TAC_PLUS_AUTHEN_TYPE_MSCHAP`, `TAC_PLUS_AUTHEN_TYPE_MSCHAPV2` — challenge and response supplied up front. The field is chosen by the device before the server has said anything, and it is a commitment. It fixes not only what the credential looks like but **who gets to speak during the sequence**. ## ASCII: the server drives, and may keep driving Under ASCII the START is allowed to be almost empty. The user field's length may be set to zero, meaning the device has not collected a username yet and is content for the server to ask. What follows is the prompt loop: 1. The server answers `GETUSER` with the prompt text in `server_msg`. 2. The device prints it, reads a line, returns it as `user_msg` in a CONTINUE. 3. The server answers `GETPASS`, usually with `TAC_PLUS_REPLY_FLAG_NOECHO` set. 4. The device returns the typed value in another CONTINUE. 5. The server may answer `GETDATA` and ask for something else again, or finish with `PASS` or `FAIL`. Because the server can insert a turn, a policy change — a second value, a forced password change — costs nothing on the device. The device already knows how to print a string and return a line. ## PAP, CHAP and MS-CHAP: the credential arrives with the request The other types put everything in the START. PAP puts the username in the user field and the password in `data`. The challenge/response types put their material in `data` too. In every case the server has the whole credential the moment the START lands, and the sequence is one exchange: a REPLY of `PASS` or `FAIL` (or `ERROR`, or `RESTART`). | | `_ASCII` | `_PAP` | `_CHAP` / `_MSCHAP` / `_MSCHAPV2` | |---|---|---|---| | Username in the START | Optional; may be absent | Present in the user field | Present in the user field | | Credential in the START | Absent | Cleartext password in `data` | Challenge and response in `data` | | Packets to a verdict | Three or more | One START, one REPLY | One START, one REPLY | | Server may ask for more | Yes, via the GET statuses | No | No | | Prompt text under the server's control | Yes, in `server_msg` | Not applicable | Not applicable | The last two rows are the whole answer. A server that wants a second value from a PAP sequence has no way to ask for it; the only lever it has left is to refuse, or to send `RESTART` and hope the device begins again with a type that can be extended. ## Where the specification tells you to narrow the choice RFC 8907 is unusually direct about this field, and it is worth quoting at the right strength rather than a stronger one: - A server **MUST** give an administrator a way to restrict `authen_type` to the challenge/response options. - An administrator **SHOULD** enable that restriction. - An administrator **SHOULD NOT** allow one credential to be used in both a challenge-based type and a non-challenge-based type. That last line is the one candidates miss. If the same stored credential can be presented either as a challenge response or as a cleartext value in a PAP `data` field, the weaker presentation sets the bar for both, and the stronger one buys nothing. Note the asymmetry of the language: the obligation on the implementation is a MUST, and the obligations on the operator are SHOULDs. An answer that promotes those SHOULDs to MUSTs teaches a certainty the document does not carry. ## What the choice does not settle Which type is safer on the wire is not decided here. Every one of these bodies travels the same way and is protected the same way, and the argument about how good that protection is — including why a challenge/response type is less of an improvement than it looks when other fields of the same packet are exposed — belongs to the payload-protection subject. This field decides the **shape of the conversation**: how many turns it takes, who may ask for more, and whether the device can hand the whole credential over before the server has spoken.

  • A server wants a second value from a PAP sequence. What can it do?
    Not much inside that sequence. PAP has no way to carry another prompt, so the server's options are to refuse with `FAIL`, or to answer `RESTART`, which tells the device the chosen `authen_type` is unacceptable and it may begin a fresh sequence — typically choosing ASCII, which can be extended.
  • Why does the specification warn against using one credential under both a challenge-based and a non-challenge-based type?
    Because the weaker presentation sets the bar. If the same stored value may arrive either as a challenge response or as a cleartext PAP password, anything the challenge form was supposed to buy is available to whoever can elicit the other form. It is a SHOULD NOT addressed to the administrator, not an implementation MUST.

saying these in an interview costs you the question

  • Thinks authen_type only names a hashing algorithm
  • Says every authentication START must carry a username
  • Believes the server can prompt during a PAP sequence
  • Reads the restriction guidance as a MUST on administrators
  • Assumes the type changes how the body is protected