요약

  • RFC 927은 텔넷 옵션 26인TUID를 제안했다. 사용자를 인증한 호스트가 동의하는 목적지에 32비트 사용자 식별자를 보내 두 번째 로그인을 피하게 하는 규격이었다.
  • 식별자가 이동하기 전에WILL TUID와DO TUID로 합의가 성립해야 했고,WON'T와DON'T는 거부를 일반적인 프로토콜 결과로 남겼다.
  • 4옥텟 식별자는 발신 호스트가 주장하는 사용자를 지칭했다. 비밀번호 교환을 증명하지 못했고, 목적지 호스트에 대한 권한을 부여하지도 않았으며, 자체적으로 암호학적 보호를 제공하지도 않았고, 어떤 응용 동작이 성공했는지 보여주지도 않았다.

1984년 12월, BBN의 Brian A. Anderson은RFC 927,TACACS User Identification Telnet Option을 발표했다. 이 문서는 “이중 로그인 회피(double login avoidance)”를 위한 제안된 프로토콜을 기술했다. 예상 사례는 이미 TAC에 올바른 이름과 비밀번호를 제공한 사람을 대신해 터미널 액세스 컨트롤러(TAC)가 목적지 호스트로 텔넷 연결을 여는 경우였다. 자격 증명을 다시 요구하는 대신, 목적지는 첫 번째 인증을 받아들이기를 선택할 수 있었다.

이 문서는 이 협상에 작은 전송 형식을 부여했다. 옵션 이름은TUID였고 코드는 26이었다. 두 텔넷 종단이 이 옵션 사용에 동의한 뒤, 사용자 측이 RFC에서 사용자의 UUID로 지정한 32비트 이진 값을 보냈다. 4옥텟이 연결을 건너갔다. 비밀번호는 건너가지 않았다.

이 경제성은 경계를 생략하면 초기 범용 로그인 체계처럼 들릴 수 있다. RFC 927은 훨씬 적은 것을 약속했고, 바로 그 정밀성이 이 문서를 지금도 유용하게 만든다. 발신 종단은 인증 주장을 제시했다. 목적지 종단은 그것을 신뢰할지 스스로 결정했다. 그 숫자는 이 관계 안에서 주장된 신원을 실어 날랐을 뿐, 목적지에 대한 권한을 만들지 않았다.

비밀번호 확인이 다른 호스트의 진술로 바뀌었다

RFC 927의 동기는 텔넷 옵션 협상보다 앞선다. 문서에 따르면 TACACS에서 사용자는 그것을 경유해 연결하기 전에 TAC에 올바른 이름/비밀번호 쌍을 제시해야 했다. 따라서 TAC는 로컬 사실 하나를 보유하고 있었다. 자신의 인증 절차가 특정 식별자에 연관된 사용자를 수락했다는 사실이다.

TUID 옵션은 TAC 또는 다른 협력하는 사용자 호스트가 이 사실을 하류에서 활용 가능하게 만들어 주었다. 발신 측은 목적지가 다시 검사하도록 비밀번호를 전달하지 않았다. 실질적으로 이렇게 말한 것이다. 이 연결을 연 사용자를 내가 인증했으며, 이것이 그 사용자의 32비트 번호라고.

이로써 신뢰의 대상이 바뀌었다. 목적지는 반복을 피하려고 원래 비밀을 검사할 필요가 없어졌고, 대신 발신 호스트의 절차, 운영 관리, 진술이 신뢰할 만한 것인지를 판단해야 했다. 절약된 로그인 프롬프트의 대가는 새로운 호스트 간 신뢰 의존성이었다.

이 의존성은 숨겨져 있지 않았다. RFC 927은 호스트들이 TAC의 인증을 “받아들이거나 받아들이지 않을 수 있으며, 그 선택은 각자에게 있다”고 명시한다. 발신 측은 주장을 할 수 있었지만, 그 주장을 충분한 것으로 다루라고 목적지를 강제할 수 없었다. 목적지는 자신이 노출하는 서비스에 대해 계속 책임을 졌다.

동의가 4옥텟보다 먼저 왔다

이 메커니즘은 텔넷의 협상형 옵션 문법을 물려받았다.RFC 854는DO,DON'T,WILL,WON'T를 정의해 어느 종단이든 네트워크 가상 터미널 기본값을 넘어서는 동작을 요청, 수락 또는 거부할 수 있게 했다.RFC 855는 매개변수에 대한 규율을 더했다. 먼저 양측이 옵션을 논의하기로 합의해야 하고, 그 후에야 서브협상이 값을 실어 나른다.

RFC 927은 각 TUID 명령에 구체적 책임을 부여했다.

  • IAC WILL TUID는 사용자 측 텔넷이 사용자를 인증하고 식별 UUID를 보낼 것을 제안하거나 동의한다는 뜻이었다.
  • IAC DO TUID는 서버 측 텔넷이 UUID로 식별되는 사용자에 대해 사용자 측의 인증을 받아들이기를 제안하거나 동의한다는 뜻이었다.
  • IAC WON'T TUID는 발신 측 역할을 거부했다.
  • IAC DON'T TUID는 목적지 측 수락을 거부했다.

WILL과DO가 일치한 뒤에야IAC SB TUID <uuid> IAC SE가 4옥텟 값을 실어 날랐다. 어느 쪽이든 교환을 시작할 수 있었다. RFC 927은 성공적인 두 순서(서버 요청 우선, 사용자 제안 우선)와WON'T또는DON'T로 끝나는 실패한 두 순서를 모두 보여주었다.

기본 동작이 중요했다. TUID를 구현하지 않는 사용자 텔넷은DO에WON'T로 답했고, 이를 구현하지 않는 서버 텔넷은WILL에DON'T로 답했다. 따라서 무지가 조용한 신뢰로 변하지 않았다. 연결은 평범한 텔넷으로 남아 목적지가 요구하는 로컬 로그인 동작을 그대로 사용할 수 있었다.

UUID는 4옥텟이지 자체 증명 신원이 아니었다

UUID라는 글자는 이후의 정신 모델을 불러온다. 큰 이름공간에서 충돌 가능성을 낮추기 위해 설계된, 익숙한 텍스트 형식의 128비트 값 말이다. RFC 927이 정의한 것은 더 좁다. “32비트 이진수”이다. 문서의 예제는 값 1, 255, 모든 비트가 1인 값을 텔넷 서브협상에 직접 넣는다.

텔넷은 옥텟 255를IAC로 예약했기 때문에 그 값을 갖는 데이터 옥텟은 두 번 반복해야 했다. 수치상 255인 UUID는 3개의 0 옥텟 뒤에IAC IAC로 전송되었고, 모든 비트가 1인 값은IAC SE앞에IAC IAC쌍 4개를 요구했다. 이것은 바이트 투명성이지 암호화나 인증이 아니었다.

RFC는 32비트 이름공간이 어떻게 할당되는지, 충돌이 어떻게 방지되는지, 값이 얼마나 유효한지, 사용자가 그것을 어떻게 복구하는지, 목적지가 그것을 로컬 계정에 어떻게 대응시키는지 정의하지 않았다. 논스, 타임스탬프, 서명, 메시지 인증 코드, 채널 바인딩도 포함하지 않았다. 그 값을 UUID라고 부른 것은 이 체계 안에서의 역할을 기술했을 뿐, 그 값을 비밀, 신선, 자가 검증 가능한 것으로 만들지 않았다.

유효한 TUID 서브협상을 담은 패킷 추적은 옵션이 활성화된 뒤 어떤 종단이 4옥텟을 사용자 식별자로 제시했다는 사실을 보여줄 수 있다. 그것만으로 사람이 올바른 비밀번호를 입력했는지, 발신 측이 자신의 정책을 올바르게 구현했는지, 목적지의 계정 데이터베이스가 그 번호에 같은 의미를 부여했는지는 보여줄 수 없다.

인증은 권한 부여 직전에서 멈췄다

RFC 927은 수락에 대해서는 명시적이지만 그 이후 일어날 수 있는 모든 일에 대해서는 간략하다. 이 침묵을 현대적 가정으로 채워서는 안 된다. 다른 호스트의 인증을 수락한다는 것은 하나의 한정된 질문에 답한다. 목적지가 발신 측의 진술을 이 연결이 대표하는 대상에 대한 충분한 근거로 다룰 것인가?

그것은 사용자가 어떤 명령을 실행할 수 있는지, 어떤 파일을 읽을 수 있는지, 어떤 계정 속성이 적용되는지, 특권 모드에 진입할 수 있는지, 요청된 동작이 실제로 일어났는지에는 답하지 않는다. 이것들은 목적지 호스트와 응용의 결정이다.

이후 문서들은 1984년 프로토콜을 바꾸지 않고 이 구분에 이름을 붙이기 쉽게 해 준다.RFC 1492, 즉 1993년 TACACS의 정보성 재구성은 터미널 액세스 클라이언트가 데몬에게 로그인 수락 또는 거부를 요청하는 방식을 기술했다. 또한 기존 로그인 맥락 안에서 특정 주소와 포트로의 연결을 열어야 하는지 묻는 이후의 요청으로CONNECT를 기술했다. 인증과 목적지 결정은 같은 사건이 아니었다.

RFC 1492는 신중하게 사용해야 한다. 저자는 저작권 문제로 원래 TACACS 규격을 입수할 수 없었고, 이후의 정보가 오류를 드러낼 수 있다고 경고했다. 이 한계는 지워질 각주가 아니라 증거의 일부다.

RFC 8907은 훨씬 나중의 TACACS+ 프로토콜을 기술한다. 이 문서는 인증, 권한 부여, 계정 관리를 별개의 요소로 다루며, 프로토콜이 인증 요청과 권한 부여 요청을 연관시키지 않는다고 명시한다. TACACS+는 RFC 927의 프로토콜이 아니므로 그 필드를 과거로 투영할 수 없다. 다만 그 어휘은 오래된 범주 오류를 드러낸다. 어떤 신원이 주장되었는지 아는 것과 그 신원이 무엇을 할 수 있는지 결정하는 것은 같지 않다.

목적지의 거부는 상호운용성의 일부였다

TUID는 한 호스트의 신원 체계를 다른 호스트에 강제할 중앙 권한을 요구하지 않았다. 두 호스트가 협력할 수 있었고, RFC는 한 사이트의 호스트들을 예로 들었지만, 각 목적지는 자신의 수락 결정을 유지했다. 공유 표준은 제안, 수락, 거부, 4옥텟 매개변수를 위한 문법을 제공했다. 발신 호스트를 목적지의 주체로 임명하지 않았다.

이것이 최소 사양의 중요한 형태다. 공통 문법이 없다면 목적지는 발신 측이 인증 주장을 하려는 것인지, 어떤 바이트가 식별자를 담는지 신뢰할 수 있게 판단할 수 없었다. 로컬 재량이 없다면 문법은 권한 이전이 되었을 것이다. RFC 927은 대화를 표준화하면서 결과를 초래하는 신뢰 결정은 그 부담을 지는 운영자에게 남겼다.

IANA 텔넷 옵션 레지스트리는 지금도 코드 26을 TACACS User Identification으로 등록하고 RFC 927을 가리킨다. 이 기록은 매개변수 할당을 확인하고 코드 26이 서로 무관한 여러 의미로 쓰이는 것을 막는다. 그러나 이것은 TUID가 1984년에 널리 구현되었거나 지금도 배포 중이거나 어떤 측정된 집단에서 제안된 절약을 실현했다는 것을 입증하지 않는다.

깔끔한 로그인 경험은 비용을 증거 쪽으로 옮겼다

두 번째 비밀번호 프롬프트를 피하는 것은 사용자에게 즉각 이익이 된다. 반복적인 비밀 노출을 줄이고 발신 측 인증 절차를 중앙화할 수도 있다. 그러나 목적지는 다른 운영 부담을 떠안는다. 어떤 발신지를 신뢰하는지, 각 발신지가 어떤 이름공간을 쓰는지, 4바이트 값을 로컬에서 어떻게 대응시키는지, 그 신뢰가 언제 만료되어야 하는지 알아야 한다.

“로그인 성공”만 기록하는 로그는 이 협상을 지워버린다. 이후 조사자는 목적지가 비밀번호를 검사했는지, TAC의 TUID를 수락했는지, 식별자를 로컬 계정에 대응시켰는지, 별도의 권한 부여 규칙을 적용했는지, 아니면 단지 전송 연결을 열었는지 판단할 수 없다. 인터페이스의 효율성은 감사 기록의 모호성이 될 수 있다.

따라서 증거 체계는 별개의 사건들을 보존해야 한다. 발신 측 인증 결과, 텔넷WILL/DO합의, 정확한 TUID 값과 이름공간, 목적지의 신뢰 정책 결정, 로컬 계정 대응, 각 권한 부여 결정, 그 결과의 응용 동작. 어느 하나의 사건도 다음 사건의 권한을 물려받아서는 안 된다.

RFC 927의 역사적 기여는 재사용 가능한 디지털 신원 문제가 해결되었다는 증명이 아니다. 그것은 실제 협상의 압축된 실연이다. 한 호스트가 자신이 수행한 인증을 대변할 의사가 있고 다른 호스트가 귀 기울일 의사가 있을 때 반복을 제거할 수 있었다. UUID는 연결을 건너갔다. 그것을 신뢰할 책임은 건너가지 않았다.

출처와 한계

이 글은 RFC 854, 855, 927, IANA 텔넷 옵션 레지스트리, 그리고 RFC 1492와 8907의 이후 한정된 비교에 의존한다. 이들은 프로토콜 문법, 명시된 동기, 레지스트리 할당, 이후의 구분을 확립한다. 그러나 배포 보편성, 현대 페더레이션 로그인으로의 직접적 계보, 암호학적 보호, 또는 실제 세션의 성공을 입증하지는 않는다.

“증명된 신원(proven identity)”이라는 표현이 RFC 927의 동기 부분에 등장하지만, 전송 값 자체는 증명이 아니다. 증명, 그것이 무엇이든, 발신 호스트의 인증 절차와 그 절차를 신뢰하기로 한 목적지의 결정 안에 남아 있었다. 4옥텟 숫자는 신뢰 협정 안에서의 증거였지, 협정 없는 권한이 아니었다.