Summary

  • RFC 1492 documented TACACS from a Cisco implementation believed compatible with an original specification that its author could not inspect; it explicitly warned that later recovery of that source might reveal errors.
  • Running code bounded the reconstruction, but did not prove the missing text, turn an Informational RFC into a standard, authenticate a copied nonce, secure clear-text credentials or prove that a daemon response became a completed connection.
  • The useful evidence chain remains segmented: source custody, implementation behavior, published description, request transport, local policy decision, terminal-server action and any resulting session or accounting record.

The most important sentence in RFC 1492 appears before any packet layout. The original TACACS specification was unavailable to the author because of copyright issues, and that lack of access was the principal reason for writing the memo. The RFC did not pretend to replace custody with confidence. It was prepared with Cisco Systems, whose simple implementation was believed compatible with the original, yet the document warned that finding the original later could make parts of the reconstruction known to be incorrect.

That is a rare and valuable form of technical honesty. Code can be stronger evidence than recollection: it exposes fields, branches and observable replies. It is still not the same object as the document from which it may have descended. An implementation can omit options, preserve bugs, add local extensions or embody assumptions that the inaccessible text never required. RFC 1492 treated running code as a witness, not as an infallible constitution.

One name covered two protocol forms

The distinction mattered because “TACACS” did not describe a single clean artifact. The RFC separated a simple form, for which compatibility with the historical specification was believed, from an extended form supported by Cisco and used in the University of Minnesota's distributed authentication system. Those examples prove bounded operation in named settings. They do not provide an adoption census or establish that every deployment spoke the same dialect.

The publication status carried a second boundary. RFC 1492 was Informational and expressly did not specify an Internet Standard. Publication made a reconstruction inspectable and citable. It did not certify the inaccessible source, settle ownership or confer universal authority on Cisco's implementation.

Authentication and permission were different requests

The exchange was built around a client request and a daemon response. Every request required a response and could therefore be denied. For a LOGIN request, success authenticated the supplied credentials and allowed the terminal server to begin a login connection. A CONNECT request happened inside an already existing connection: it asked whether a TCP connection to a particular destination address and port should be opened.

That sequencing prevents a common compression. A successful LOGIN was not standing permission for every destination. A successful CONNECT reply was not proof that the destination accepted a connection. The daemon supplied a decision; the terminal server still had to enforce it, the network had to carry the attempt and the destination had to respond. Accounting, where present, was another record again.

The RFC deliberately left decision logic local. The daemon operator controlled the algorithms and data used to accept or reject requests. This flexibility let sites apply their own password stores and policy. It also meant that two conforming daemons could reach different decisions on similar inputs. A protocol-defined response format did not make local policy a global rule.

The nonce matched a reply; it did not create identity

The historical UDP encoding used port 49 and included a nonce that the daemon copied into its response. Its purpose was correlation: the client could associate a returned datagram with an outstanding request. That receipt is useful, but narrow. A copied nonce did not authenticate the user, establish that the reply came from the intended server, protect the packet against alteration or prove that the requested action was authorized under the right policy.

Timeouts exposed another boundary. A UDP client could retry. The server did not retry, and the RFC observed that the design implied idempotent requests even though the requests were not actually idempotent. Repeating a question about a larger connection can matter if the first reply was lost after state changed. A capture showing two identical datagrams therefore cannot be reduced automatically to one harmless logical event. Investigators need request identifiers, timing, server state and the terminal server's action record.

Clear text was an operational fact, not a footnote

Both the UDP and TCP encodings carried username and password material in clear text. RFC 1492's security discussion accordingly warned that a network monitor could collect username/password pairs and that the service exposed a probing surface. A successful reply cannot repair that earlier disclosure. Nor does operation on an administratively controlled network turn clear text into cryptographic protection.

The TCP encoding solved a different problem. It was explicitly incompatible with historical TACACS, abandoned compatibility with the reserved UDP service in exchange for simpler framing, TCP-managed delivery and more room for responses. Reliable byte delivery did not authenticate either endpoint, encrypt credentials or prove policy enforcement. Transport improved one receipt while leaving the others separate.

Later TACACS+ cannot rewrite 1993

RFC 8907 later documented TACACS+ as a suite separating authentication, authorization and accounting. It also cautioned that a protocol session need not correspond to a user or user action, and that authentication requests are not automatically associated with authorization requests. Those later distinctions illuminate the enduring evidence problem, but they cannot be projected backward as if RFC 1492 had specified modern TACACS+.

RFC 927 is an earlier bounded comparison: it described a TELNET terminal-user identification handoff. RFC 1492 owns a different mechanism—the reconstruction of a daemon protocol whose source specification was missing from the author's reach. The line from one to the other is not a single standardized product history. It is a record of distinct attempts to move identity and access decisions across network boundaries.

The historical lesson is not that running code lacks authority. It is that authority must be named precisely. Code can prove what one implementation did under observed inputs. A published reconstruction can make that behavior discussable. A daemon can render a local decision. A terminal server can apply it. None of those receipts, alone, proves the missing original, the authenticity of every participant or the final effect in the world.

Sources