TACACS user identification Telnet option
Extracted elements (10)
Under TACACS, a user must authenticate to a TAC before connecting to a host. To avoid requiring a second authentication at the target host, the TAC passes the user's proven identity (UUID) to the target host using this option. Target hosts may accept or reject the TAC's authentication at their discretion.
Although the TUID option is intended primarily for TAC-to-host connections under TACACS, it can be used between any two cooperating hosts for double login avoidance, such as between hosts at the same site (e.g., all BBN hosts TELNETing to one another).
The default for the TUID option is WON'T TUID on the user side and DON'T TUID on the server side. A TELNET user host not implementing or using TUID will reply WON'T TUID to a DO TUID; a TELNET server host will reply DON'T TUID to a WILL TUID.
IAC WILL TUID: sent by the TELNET user to propose authenticating the user and sending the identifying UUID, or to agree to do so. IAC WON'T TUID: sent by the TELNET user to refuse authentication. IAC DO TUID: sent by the TELNET server to request UUID authentication. IAC DON'T TUID: sent by the TELNET server to refuse accepting UUID authentication.
The TUID Telnet option is assigned option code 26. It enables a TELNET user host to authenticate a user and transmit the user's UUID to the TELNET server host, facilitating double login avoidance.
Two negotiation orderings both produce successful UUID authentication: (Case 1) server sends DO TUID first, user replies WILL TUID then sends subnegotiation; (Case 2) user sends WILL TUID first, server replies DO TUID, then user sends subnegotiation. Both result in the UUID being delivered.
Target hosts may accept or decline the TUID-based authentication at their option; there is no obligation to trust a TAC's assertion of user identity. The option relies entirely on mutual consent between cooperating hosts and provides no cryptographic verification of the UUID or the authenticating host's identity.
Successful negotiation requires both sides to agree: the server sends DO TUID and the user responds WILL TUID (or vice versa), after which the user sends IAC SB TUID <uuid> IAC SE. If either side refuses (WON'T or DON'T), no UUID is transmitted and double login avoidance does not occur.
IAC escaping within the 32-bit UUID subnegotiation payload: any byte with value 255 must be sent as two consecutive IAC bytes (IAC IAC). For example, a UUID of all-ones (0xFFFFFFFF) is transmitted as IAC SB TUID IAC IAC IAC IAC IAC IAC IAC IAC IAC SE (eight IAC bytes for four UUID octets plus framing).
The UUID is transmitted via subnegotiation as IAC SB TUID <uuid> IAC SE, where <uuid> is a 32-bit binary number (4 octets). Any octet with value 255 (IAC) within the UUID must be doubled (sent as IAC IAC) to escape it within the subnegotiation stream.