Summary

  • RFC 933 proposed Telnet option 27, OUTMRK, so a server could send a security banner once and a user-side Telnet could preserve it independently of the server application.
  • WILL and DO established use of the option; the receiver still answered the particular banner with ACK or NAK and controlled how the remaining application area was laid out.
  • A visible marking was not the security policy behind it. The protocol did not authenticate the label, grant access, enforce mandatory controls or prove what appeared on the user's physical screen.

In January 1985, S. Silverman of MITRE-Washington published RFC 933, Output Marking Telnet Option. Its problem was visual and operational. Some military security architectures associated a security level with each Telnet connection and needed a corresponding banner on the display. Servers were already solving the problem by placing the banner inside every screenful of application data.

That approach made the application carry a presentation duty. Each refresh had to repeat the marking. The server also needed to understand the dimensions of a remote device well enough to reserve the correct rows. RFC 933 proposed a different division of labour: transmit the banner once, instruct the user-side Telnet to maintain it, and let the endpoint closest to the screen place application output around it.

The option was named OUTMRK. Its code was 27, an assignment still recorded in the IANA Telnet Options registry. But the small number did not define a security level. The bytes carried ASCII banner text and a placement flag. Whatever made that text a correct description of the session had to exist elsewhere.

Agreement to mark came before acceptance of the marking

RFC 933 used the option-negotiation grammar of RFC 854. WILL OUTMRK meant that one side was willing to send output-marking information. DO OUTMRK meant that the other side was willing to receive it. WON'T and DON'T expressed refusal, and refusal was the default.

That first exchange established a capability and a convention. It did not settle the actual banner. After WILL and DO aligned, the server sent a subnegotiation of the form IAC SB OUTMRK CNTL data IAC SE. CNTL selected a position; data supplied the ASCII marking.

The receiving User-Telnet then had another decision. If the data was satisfactory, it sent IAC SB OUTMRK ACK IAC SE, where ACK was ASCII 6. If it objected, it returned NAK, ASCII 21. RFC 933 left the next choice with the server: try again with more acceptable data, or take another action, possibly ending the connection.

This two-stage structure matters. A DO was not an advance promise to display any string a server might send. It meant the endpoint understood the option and was prepared to discuss it. The later ACK applied to a particular marking proposal. RFC 855 describes this pattern generally: agree first to discuss parameters, then carry the parameters within SB and SE; either party can later end participation with WON'T or DON'T.

Even ACK had a narrow scope. It recorded that User-Telnet accepted the banner data for output marking. It did not attest that the server had classified the session correctly, that the user possessed a clearance, that an application command was allowed, or that a monitor had rendered every character faithfully.

The receiver became a layout engine

Once it acknowledged the banner, User-Telnet had to do more than keep a line of text in memory. RFC 933 required it to translate commands using cursor controls so application data would map into the application portion of the screen. The visible terminal became two coordinated regions: marking space and application space.

The control flag exposed how unfinished that interface still was. D left placement to User-Telnet and was expected to cover most interactions. T and B requested the top or bottom. L and R named the left and right, but the RFC said their precise meaning remained to be defined. A shared option code did not remove differences in display geometry.

Banner data could contain CRLF between lines. Multiple markings could be packed into one subnegotiation, separated by ASCII Group Separator and each preceded by its own control flag. The endpoint was responsible for positioning all of them.

This is where an apparently simple label became state. A window resize, terminal-mode change, cursor-addressing sequence or client defect could cause the application area to overlap the marking. A packet trace might show a valid ACK while the actual screen later lost the banner. Wire agreement and visual persistence were related, but they were not the same evidence.

RFC 933 provided a stop path. The server could transmit WON'T OUTMRK to terminate marking. The user side could initiate the convention with DO, and if a WILL/DO exchange was not followed by banner data, it could send DON'T. If necessary, the user side could also notify the server of the new effective page size. Presentation authority remained distributed between the server's proposal and the client's display mechanics.

A label described policy; it did not perform policy

RFC 933 cited the Department of Defense Trusted Computer System Evaluation Criteria's requirement for labeling human-readable output. An official NIST archival copy of the later 1985 DoD 5200.28-STD preserves an important distinction. Its output-labeling provision requires human-readable markings to represent sensitivity and makes overrides auditable. A separate mandatory-access-control provision governs decisions among subjects, objects and devices.

The documents are not interchangeable. RFC 933 was a proposed Telnet display convention, not an implementation of the whole trusted-computing standard. The December 1985 edition of the criteria also postdates the RFC and superseded the 1983 criteria it cited. It is useful here only because it makes the category boundary visible: marking output and controlling access were related requirements, not one operation.

A banner saying that a session occupied a particular security context could help a user avoid mixing material, recognize an unexpected level or understand a device boundary. But ASCII text could not create the context it named. The label needed a source, a security-level assignment, an association with the correct session and trusted display handling. The application still needed independent access decisions.

Nor did the option protect its own bytes cryptographically. RFC 933 defined no signature, message-authentication code, authenticated channel binding, freshness value or label namespace. A valid OUTMRK sequence established protocol syntax. Its truth depended on the systems and controls that produced and received it.

Efficiency moved custody to the client

Sending the banner once was attractive because it removed repetition. The server application no longer needed to insert a heading into every screen or know how many lines a workstation could show. Yet that saving did not eliminate work; it relocated work to User-Telnet.

The receiving client had to retain the marking, reserve space, translate cursor behavior, handle multiple banners, respond to unacceptable data and survive changes in geometry. If operators logged only that OUTMRK had been negotiated, they lost the evidence that mattered most: which banner was proposed, which one was accepted, how it was placed, whether it stayed visible and which access decisions followed.

The complete chain therefore has several events. A security authority assigns a context. A server turns that context into banner text. Telnet endpoints negotiate capability. The client accepts or rejects the proposed data. A local display engine renders and preserves it. Separately, trusted controls decide what the user and application may do. The user finally sees—or fails to see—the result.

Collapsing those events creates two opposite mistakes. One treats a visible label as permission: if the screen says it, the action must be allowed. The other treats any display defect as proof that the underlying access policy failed. Both conclusions skip necessary evidence.

RFC 933 never became proof that remote security marking was solved. It captured a more durable engineering truth. When a central system wants a human-facing constraint to persist on a remote surface, sending the text is only the first handoff. The receiver must accept a particular presentation, maintain it under local conditions and leave the consequential policy decision with the controls that actually enforce it.

Sources and limits

This analysis uses RFC 933, RFC 854, RFC 855, the IANA Telnet Options registry, and the official NIST archival copy of DoD 5200.28-STD. They establish the proposed grammar, institutional motivation and distinction between output labels and access control. They do not establish deployment, current support, product conformance, correct rendering, user comprehension, a real classified session or any operational outcome.