Summary

  • RFC 927 proposed Telnet option 26, TUID, so a host that had authenticated a user could send a 32-bit user identifier to a consenting target and spare the person a second login.
  • WILL TUID and DO TUID had to establish agreement before the identifier moved; WON'T and DON'T preserved refusal as an ordinary protocol result.
  • The four-octet identifier named the user claimed by the source host. It did not prove the password exchange, grant target-host authorization, protect itself cryptographically or show that any application action succeeded.

In December 1984, Brian A. Anderson of BBN published RFC 927, TACACS User Identification Telnet Option. It described a proposed protocol for “double login avoidance.” The expected case was a Terminal Access Controller, or TAC, opening a Telnet connection to a target host on behalf of someone who had already supplied a correct name and password to the TAC. Instead of asking for those credentials again, the target could choose to accept the first authentication.

The document gave this bargain a small wire shape. The option was called TUID; its code was 26. After the two Telnet endpoints agreed to use it, the user side sent a 32-bit binary value identified in the RFC as the user's UUID. Four octets crossed the connection. The password did not.

That economy can sound like an early universal login system if its boundaries are omitted. RFC 927 promised much less, and its precision is why it remains useful. The source endpoint offered an authentication claim. The target endpoint decided whether to rely on it. The number carried the claimed identity inside that relationship; it did not create authority over the target.

A password check became a statement by another host

RFC 927's motivation begins before Telnet option negotiation. Under TACACS, it says, a user had to give a correct name/password pair to a TAC before connecting through it. The TAC therefore possessed a local fact: its authentication procedure had accepted a user associated with a particular identifier.

The TUID option let the TAC or another cooperating user host make that fact usable downstream. The source was not forwarding a password for the target to test again. It was saying, in effect: I authenticated the user on whose behalf I opened this connection, and this is the user's 32-bit number.

That changed the object of trust. The target no longer needed to inspect the original secret to avoid repetition; it needed to decide whether the source host's procedure, administration and assertion deserved reliance. A saved login prompt was paid for by a new inter-host trust dependency.

The dependency was not hidden. RFC 927 says that hosts may accept the TAC's authentication “or not, at their option.” The source could make a claim, but it could not compel the target to treat the claim as sufficient. The target remained responsible for the service it exposed.

Consent preceded the four octets

The mechanism inherited Telnet's negotiated-option grammar. RFC 854 defined DO, DON'T, WILL and WON'T so either endpoint could request, accept or reject behavior beyond the Network Virtual Terminal default. RFC 855 added the discipline for parameters: first both parties agree to discuss an option; only then does subnegotiation carry its values.

RFC 927 assigned each TUID command a particular responsibility:

  • IAC WILL TUID meant that the user-side Telnet proposed, or agreed, to authenticate the user and send the identifying UUID.
  • IAC DO TUID meant that the server-side Telnet proposed, or agreed, to accept the user side's authentication for the user identified by the UUID.
  • IAC WON'T TUID refused the source-side role.
  • IAC DON'T TUID refused the target-side acceptance.

Only after WILL and DO aligned did IAC SB TUID <uuid> IAC SE carry the four-octet value. Either side could begin the exchange. RFC 927 showed both successful orders—server request first or user offer first—and two unsuccessful orders ending in WON'T or DON'T.

The defaults mattered. A user Telnet not implementing TUID answered WON'T to DO; a server Telnet not implementing it answered DON'T to WILL. Ignorance therefore did not become silent trust. The connection could remain ordinary Telnet and use whatever local login behavior the target required.

The UUID was four octets, not a self-proving identity

The letters UUID now invite a later mental model: a 128-bit value in a familiar textual format, designed to make collisions unlikely across large namespaces. RFC 927 defines something narrower—“a 32 bit binary number.” Its examples put values 1, 255 and all ones directly into the Telnet subnegotiation.

Telnet reserved octet 255 as IAC, so a data octet with that value had to be doubled. A UUID of numeric value 255 travelled as three zero octets followed by IAC IAC; a value of all ones required four doubled IAC pairs before IAC SE. This was byte transparency, not encryption or authentication.

The RFC did not define how the 32-bit namespace was allocated, how collisions were prevented, how long a value remained valid, how a user recovered it, or how a target mapped it to a local account. It did not include a nonce, timestamp, signature, message-authentication code or channel binding. Calling the value a UUID described its role in that system. It did not make the value secret, fresh or self-verifying.

A trace containing a valid TUID subnegotiation can show that an endpoint presented four octets as the user's identifier after the option had been enabled. It cannot, by itself, show that a human supplied the right password, that the source implemented its policy correctly, or that the target's account database gave the number the same meaning.

Authentication stopped before authorization

RFC 927 is explicit about acceptance but sparse about everything that could happen after it. That silence must not be filled with modern assumptions. Accepting another host's authentication answers one bounded question: will the target treat the source's statement as sufficient evidence of who the connection represents?

It does not answer which commands the user may run, which files may be read, which account attributes apply, whether a privileged mode may be entered, or whether a requested operation actually occurred. Those are target-host and application decisions.

Later documents make the separation easier to name without changing the 1984 protocol. RFC 1492, a 1993 informational reconstruction of TACACS, described a terminal access client asking a daemon to accept or deny a login. It also described CONNECT as a later request, inside an existing login context, asking whether a connection to a specified address and port should be opened. Authentication and a destination decision were not the same event.

RFC 1492 must be used cautiously: its author could not obtain the original TACACS specification because of copyright issues and warned that later information might reveal errors. That limitation is part of the evidence, not a footnote to erase.

RFC 8907 describes the much later TACACS+ protocol. It treats authentication, authorization and accounting as separate elements and notes that the protocol does not associate an authentication request with an authorization request. TACACS+ is not the protocol of RFC 927, so its fields cannot be projected backward. Its vocabulary simply exposes the enduring category error: knowing which identity was asserted is not the same as deciding what that identity may do.

The target's refusal was part of interoperability

TUID did not require a central authority to force one host's identity system upon another. Two hosts could cooperate, and the RFC mentioned hosts at one site as an example, but each target kept its own acceptance decision. The shared standard supplied syntax for an offer, acceptance, refusal and four-octet parameter. It did not appoint the source host as principal for the target.

This is an important form of minimal specification. Without common syntax, a target could not reliably tell whether a source intended to make an authentication assertion or which bytes held the identifier. Without local discretion, the syntax would become an authority transfer. RFC 927 standardized the conversation while leaving the consequential trust decision with the operator who bore it.

The IANA Telnet Options registry still lists code 26 as TACACS User Identification and points to RFC 927. That record confirms parameter assignment and prevents code 26 from meaning several unrelated things. It does not establish that TUID was widely implemented in 1984, remains deployed now or achieved the proposed savings in any measured population.

A clean login experience moved cost into evidence

Avoiding a second password prompt benefits the user immediately. It can also reduce repeated secret exposure and centralize a source-side authentication procedure. The target, however, acquires a different operational burden: it must know which sources it trusts, which namespace each source uses, how the four-byte value maps locally and when that trust should expire.

Logs that record only “login succeeded” erase the bargain. A later investigator cannot tell whether the target checked a password, accepted TUID from a TAC, mapped the identifier to a local account, applied a separate authorization rule or merely opened a transport connection. Efficiency at the interface can become ambiguity in the audit trail.

The evidence chain should therefore preserve distinct events: the source's authentication result; the Telnet WILL/DO agreement; the exact TUID value and namespace; the target's trust-policy decision; the local account mapping; each authorization decision; and the resulting application action. No one event should inherit the authority of the next.

RFC 927's historical contribution is not proof that reusable digital identity had been solved. It is a compact demonstration of the real bargain. Repetition could be removed when one host was willing to speak for an authentication it had performed and another host was willing to listen. The UUID crossed the connection. Responsibility for trusting it did not.

Sources and limits

This account relies on RFCs 854, 855 and 927, the IANA Telnet Options registry, and the later bounded comparisons in RFCs 1492 and 8907. They establish protocol syntax, stated motivation, registry assignment and later distinctions. They do not establish deployment prevalence, direct lineage to modern federated login, cryptographic protection, or the success of any real session.

The phrase “proven identity” appears in RFC 927's motivation, but the wire value is not proof on its own. The proof, such as it was, remained in the source host's authentication process and the target's decision to rely on that process. A four-octet number was evidence inside a trust arrangement, not authority without one.