요약

  • RFC 933은 텔넷 옵션 27인OUTMRK를 제안하여, 서버가 보안 배너를 한 번만 전송하면 사용자 측 텔넷이 이를 서버 애플리케이션과 독립적으로 유지할 수 있도록 했습니다.
  • WILL과DO가 옵션 사용을 확정했지만, 수신 측은 여전히 개별 배너에 대해ACK또는NAK로 응답하고 나머지 애플리케이션 영역의 배치 방식을 통제했습니다.
  • 눈에 보이는 표시가 그 뒤에 있는 보안 정책은 아니었습니다. 이 프로토콜은 레이블을 인증하거나, 접근을 허가하거나, 강제 통제를 집행하거나, 사용자 물리 화면에 실제로 무엇이 표시되었는지 증명하지 못했습니다.

1985년 1월, MITRE-Washington의 S. Silverman은RFC 933,Output Marking Telnet Option을 발표했습니다. 이 문서가 다룬 문제는 시각적·운영적 성격의 것이었습니다. 일부 군사 보안 아키텍처는 각 텔넷 연결에 보안 수준을 연관시키고 그에 대응하는 배너를 화면에 표시할 필요가 있었습니다. 서버들은 이미 애플리케이션 데이터의 모든 화면 분량마다 배너를 넣는 방식으로 이 문제를 해결하고 있었습니다.

그 접근 방식은 애플리케이션이 표시(프레젠테이션) 책임을 떠안게 만들었습니다. 매번 화면 갱신 시 표시를 반복해야 했습니다. 서버는 또한 원격 장치의 화면 크기를 충분히 이해하여 정확한 행 수를 예약해야 했습니다. RFC 933은 다른 역할 분담을 제안했습니다. 배너를 한 번 전송하고, 사용자 측 텔넷에게 이를 유지하도록 지시하며, 화면에 가장 가까운 엔드포인트가 배너 주위에 애플리케이션 출력을 배치하도록 하는 것입니다.

이 옵션의 이름은OUTMRK였습니다. 코드는 27로, 현재도IANA 텔넷 옵션 레지스트리에 기록되어 있습니다. 그러나 작은 숫자가 보안 수준을 정의한 것은 아니었습니다. 전달되는 바이트는 ASCII 배너 텍스트와 배치 플래그였습니다. 그 텍스트를 세션에 대한 올바른 설명으로 만든 근거는 다른 곳에 존재해야 했습니다.

표시에 대한 합의는 표시 내용의 수락에 선행했다

RFC 933은RFC 854의 옵션 협상 문법을 사용했습니다.WILL OUTMRK는 한 측이 출력 표시 정보를 보낼 의사가 있음을 뜻했습니다.DO OUTMRK는 상대 측이 이를 받을 의사가 있음을 뜻했습니다.WON'T와DON'T는 거부를 표현했으며, 거부가 기본값이었습니다.

이 첫 교환이 확립한 것은 기능(capability)과 관례였습니다. 실제 배너를 정한 것은 아니었습니다.WILL과DO가 맞춰진 후에 서버는IAC SB OUTMRK CNTL data IAC SE형식의 서브협상을 전송했습니다.CNTL은 위치를 선택했고,data는 ASCII 표시 내용을 제공했습니다.

수신하는 User-Telnet은 그다음 또 하나의 결정을 내려야 했습니다. 데이터가 만족스러우면IAC SB OUTMRK ACK IAC SE를 보냈으며, 여기서 ACK는 ASCII 6이었습니다. 반대 의사가 있으면 NAK, 즉 ASCII 21을 반환했습니다. RFC 933은 그다음 선택을 서버에게 남겨두었습니다. 더 수용 가능한 데이터로 다시 시도하거나, 다른 조치를 취하며, 필요하다면 연결을 끊는 것까지 가능했습니다.

이 두 단계 구조가 중요합니다.DO는 서버가 보낼지 모르는 어떤 문자열이든 표시하겠다는 사전 약속이 아니었습니다. 그것은 엔드포인트가 옵션을 이해하며 논의할 준비가 되어 있음을 뜻했습니다. 이후의 ACK는 특정 표시 제안에 적용되었습니다.RFC 855는 이 패턴을 일반적으로 설명합니다. 먼저 매개변수를 논의하기로 합의하고, 그다음 매개변수를SB와SE사이에 담아 전달하며, 어느 쪽이든 이후WON'T나DON'T로 참여를 종료할 수 있습니다.

심지어 ACK에도 좁은 범위가 있었습니다. ACK는 User-Telnet이 출력 표시용 배너 데이터를 수락했음을 기록한 것입니다. 서버가 세션을 올바르게 분류했다는 것, 사용자가 권한(clerance)을 보유했다는 것, 애플리케이션 명령이 허용되었다는 것, 또는 모니터가 모든 문자를 충실히 렌더링했다는 것을 입증하지 않았습니다.

수신 측은 레이아웃 엔진이 되었다

배너를 수락한 후 User-Telnet은 한 줄의 텍스트를 메모리에 보관하는 것 이상을 해야 했습니다. RFC 933은 커서 제어를 사용하는 명령을 변환하여 애플리케이션 데이터가 화면의 애플리케이션 영역에 매핑되도록 요구했습니다. 눈에 보이는 터미널은 표시 공간과 애플리케이션 공간이라는 두 개의 조율된 영역이 되었습니다.

제어 플래그는 이 인터페이스가 얼마나 미완성이었는지를 드러냈습니다.D는 배치를 User-Telnet에 맡겼으며 대부분의 상호작용을 커버할 것으로 기대되었습니다.T와B는 위 또는 아래를 요청했습니다.L과R은 왼쪽과 오른쪽을 가리켰지만, RFC는 이들의 정확한 의미가 아직 정의되지 않았다고 밝혔습니다. 공유된 옵션 코드가 화면 형상의 차이를 제거하지는 못했습니다.

배너 데이터는 줄 사이에 CRLF를 포함할 수 있었습니다. 여러 표시를 하나의 서브협상에 담을 수도 있었으며, ASCII 그룹 구분자로 서로 분리되고 각각 고유의 제어 플래그가 앞에 붙었습니다. 모두를 배치하는 책임은 엔드포인트에 있었습니다.

바로 여기서 겉보기에 단순한 레이블이 상태(state)가 됩니다. 창 크기 변경, 터미널 모드 전환, 커서 주소 지정 시퀀스 또는 클라이언트 결함으로 인해 애플리케이션 영역이 표시 영역과 겹칠 수 있었습니다. 패킷 추적에는 유효한 ACK가 기록되더라도, 실제 화면에서는 나중에 배너가 사라질 수 있었습니다. 회선상의 합의와 시각적 지속성은 연관되어 있었지만 동일한 증거는 아니었습니다.

RFC 933은 중단 경로도 제공했습니다. 서버는WON'T OUTMRK를 전송하여 표시를 종료할 수 있었습니다. 사용자 측은DO로 이 관례를 시작할 수 있었고,WILL/DO교환 뒤에 배너 데이터가 따르지 않으면DON'T를 보낼 수 있었습니다. 필요한 경우 사용자 측은 새로운 유효 페이지 크기를 서버에 통지할 수도 있었습니다. 표시 권한은 서버의 제안과 클라이언트의 화면 처리 메커니즘 사이에 분산되어 있었습니다.

레이블은 정책을 서술했을 뿐, 정책을 수행하지 않았다

RFC 933은 미국 국방부 신뢰 컴퓨터 시스템 평가 기준(Department of Defense Trusted Computer System Evaluation Criteria)의 사람이 읽을 수 있는 출력에 대한 레이블링 요구 사항을 인용했습니다. 후속 1985년DoD 5200.28-STD의 공식 NIST 보관본은 중요한 구분을 보존하고 있습니다. 그 출력 레이블링 조항은 사람이 읽을 수 있는 표시가 민감도를 나타내도록 요구하고, 재정의(override)가 감사 가능하도록 합니다. 별도의 강제 접근 통제(mandatory access control) 조항이 주체, 객체 및 장치 사이의 결정을 규율합니다.

두 문서는 서로 교환할 수 없습니다. RFC 933은 제안된 텔넷 표시 관례이지 신뢰 컴퓨팅 표준 전체의 구현이 아니었습니다. 1985년 12월판 기준은 RFC보다 이후에 나왔으며, RFC가 인용한 1983년 기준을 대체했습니다. 이 문서가 여기서 유용한 이유는 범주의 경계를 보여주기 때문입니다. 출력 표시와 접근 통제는 서로 관련된 요구 사항이지만 하나의 작업은 아니었습니다.

세션이 특정 보안 맥락에 속한다고 말하는 배너는 사용자가 자료를 섞지 않도록 돕고, 예상치 못한 수준을 인식하게 하며, 장치 경계를 이해하게 할 수 있었습니다. 그러나 ASCII 텍스트는 그것이 이름 붙인 맥락을 만들어 낼 수 없었습니다. 레이블에는 발신 근거, 보안 수준 배정, 올바른 세션과의 연관, 신뢰할 수 있는 화면 처리가 필요했습니다. 애플리케이션은 여전히 독립적인 접근 결정을 내려야 했습니다.

또한 이 옵션은 자신의 바이트를 암호학적으로 보호하지도 않았습니다. RFC 933은 서명, 메시지 인증 코드, 인증된 채널 바인딩, 신선도 값(freshness value) 또는 레이블 네임스페이스를 정의하지 않았습니다. 유효한 OUTMRK 시퀀스가 확립한 것은 프로토콜 문법이었습니다. 그 진위는 그것을 생성하고 수신한 시스템과 통제에 달려 있었습니다.

효율성은 보관 책임을 클라이언트로 옮겼다

배너를 한 번만 보내는 방식은 반복을 없애기 때문에 매력적이었습니다. 서버 애플리케이션은 더 이상 모든 화면마다 제목을 넣거나 워크스테이션이 몇 줄을 표시할 수 있는지 알 필요가 없었습니다. 그러나 그 절약이 작업을 없앤 것은 아니었습니다. 작업을 User-Telnet으로 옮긴 것입니다.

수신 클라이언트는 표시를 보존하고, 공간을 예약하고, 커서 동작을 변환하고, 여러 배너를 처리하고, 수용 불가능한 데이터에 응답하고, 화면 형상 변화를 견뎌야 했습니다. 운영자가 OUTMRK가 협상되었다는 사실만 기록한다면, 가장 중요한 증거를 잃게 됩니다. 어떤 배너가 제안되었는지, 어떤 것이 수락되었는지, 어떻게 배치되었는지, 화면에 유지되었는지, 그리고 이후 어떤 접근 결정이 내려졌는지입니다.

따라서 완전한 연쇄에는 여러 이벤트가 있습니다. 보안 당국이 맥락을 배정합니다. 서버가 그 맥락을 배너 텍스트로 바꿉니다. 텔넷 엔드포인트가 기능을 협상합니다. 클라이언트가 제안된 데이터를 수락하거나 거부합니다. 로컬 화면 엔진이 이를 렌더링하고 유지합니다. 별도로, 신뢰 통제가 사용자와 애플리케이션이 무엇을 할 수 있는지 결정합니다. 사용자는 마지막에 그 결과를 보거나, 보지 못합니다.

이 이벤트들을 하나로 합쳐버리면 서로 반대되는 두 가지 실수가 생깁니다. 하나는 눈에 보이는 레이블을 허가로 취급하는 것입니다. 화면에 그렇게 나와 있다면 그 행위가 허용된 것이어야 한다는 논리입니다. 다른 하나는 어떤 화면 결함이든 그 아래 접근 정책의 실패를 증명하는 것으로 취급하는 것입니다. 두 결론 모두 필요한 증거를 건너뜁니다.

RFC 933은 원격 보안 표시가 해결되었다는 증거가 되지 못했습니다. 그것은 더 오래 지속되는 엔지니어링 진리를 포착했습니다. 중앙 시스템이 사람이 마주하는 제약을 원격 화면에서 유지되도록 하려 할 때, 텍스트를 보내는 것은 첫 번째 인수 전달일 뿐입니다. 수신 측은 특정 표시를 수락하고, 로컬 조건 아래에서 이를 유지하며, 실질적인 정책 결정은 실제로 이를 집행하는 통제에 남겨두어야 합니다.

출처와 한계

이 분석은RFC 933,RFC 854,RFC 855,IANA 텔넷 옵션 레지스트리, 그리고DoD 5200.28-STD의 공식 NIST 보관본을 사용합니다. 이 문서들은 제안된 문법, 제도적 동기, 그리고 출력 레이블과 접근 통제 사이의 구분을 확립합니다. 그러나 배포 현황, 현재 지원 여부, 제품 적합성, 올바른 렌더링, 사용자 이해도, 실제 기밀 세션 또는 어떤 운영 결과도 확립하지 않습니다.