요약

  • RFC 1492는 저자가 직접 열람할 수 없었던 원래 명세서와 호환 가능하다고 여겨지는 Cisco 구현을 바탕으로 TACACS를 문서화했으며, 나중에 그 원본 소스가 복구되면 오류가 드러날 수 있다고 명시적으로 경고했다.
  • 실행 코드는 재구성의 범위를 한정했지만, 빠진 문서를 증명하거나, Informational RFC를 표준으로 만들거나, 복사된 nonce를 인증하거나, 평문 자격 증명을 보호하거나, 데몬 응답이 완성된 연결로 이어졌음을 입증하지 못했다.
  • 유용한 증거 사슬은 여전히 분절되어 있다: 소스 보관 상태, 구현 동작, 공개된 설명, 요청 전송, 로컬 정책 결정, 터미널 서버의 조치, 그리고 그로 인한 세션 또는 계정 기록.

RFC 1492에서 가장 중요한 문장은 패킷 형식이 나오기 전에 등장한다. 저작권 문제 때문에 저자는 원래 TACACS 명세서를 열람할 수 없었고, 바로 그 접근 불가가 이 메모를 작성한 주된 이유였다. RFC는 보관 상태를 확신으로 대체하는 척하지 않았다. 이 문서는 Cisco Systems와 함께 준비되었고, 그 단순 구현이 원본과 호환 가능하다고 여겨졌으나, 나중에 원본을 찾게 되면 재구성의 일부가 틀렸음이 밝혀질 수 있다고 경고했다.

이는 보기 드물고 소중한 형태의 기술적 정직함이다. 코드는 회상보다 강한 증거가 될 수 있다: 코드는 필드, 분기, 관찰 가능한 응답을 드러낸다. 그러나 그 코드가 유래했을 수도 있는 문서와 동일한 객체는 아니다. 구현은 옵션을 생략하거나, 버그를 그대로 보존하거나, 로컬 확장을 추가하거나, 접근 불가능한 문서가 전혀 요구하지 않은 가정을 내포할 수 있다. RFC 1492는 실행 코드를 결함 없는 헌법이 아니라 증인으로 취급했다.

하나의 이름이 두 가지 프로토콜 형태를 가렸다

이 구분이 중요했던 이유는 “TACACS”가 하나의 깔끔한 산출물을 지칭하지 않았기 때문이다. RFC는 원래 역사적 명세서와의 호환이 여겨지는 단순 형태와, Cisco가 지원하고 미네소타 대학교의 분산 인증 시스템에서 사용된 확장 형태를 구분했다. 이 예시들은 명명된 환경에서의 유한한 동작을 증명할 뿐이다. 채택 현황 조사를 제공하거나, 모든 배포가 같은 방언을 사용했다는 것을 입증하지는 못한다.

공개 상태에도 두 번째 경계가 있었다. RFC 1492는 Informational이었고, 인터넷 표준을 규정하지 않는다는 점을 명시했다. 공개는 재구성을 검열 가능하고 인용 가능하게 만들었다. 그러나 접근 불가능한 원본을 인증하거나, 소유권을 정하거나, Cisco의 구현에 보편적 권위를 부여하지는 않았다.

인증과 권한 허가는 서로 다른 요청이었다

이 교환은 클라이언트 요청과 데몬 응답을 중심으로 구성되었다. 모든 요청에는 응답이 필요했고, 따라서 거부될 수 있었다. LOGIN 요청의 경우, 성공은 제공된 자격 증명을 인증하고 터미널 서버가 로그인 연결을 시작하도록 허용했다. CONNECT 요청은 이미 존재하는 연결 안에서 발생했다: 특정 목적지 주소와 포트로의 TCP 연결을 열어야 하는지를 물었다.

이 순서는 흔한 함축을 방지한다. 성공한 LOGIN이 모든 목적지에 대한 상시 권한은 아니었다. 성공한 CONNECT 응답이 목적지가 연결을 수락했다는 증명은 아니었다. 데몬은 결정을 제공했고, 터미널 서버는 여전히 그 결정을 집행해야 했고, 네트워크는 시도를 전달해야 했으며, 목적지는 응답해야 했다. 있는 경우 회계(accounting)는 또 하나의 별도 기록이었다.

이 RFC는 결정 로직을 로컬에 두는 것을 의도적으로 남겨두었다. 데몬 운영자는 요청을 수락하거나 거부하는 데 쓰이는 알고리즘과 데이터를 통제했다. 이 유연성 덕분에 각 사이트는 자체 비밀번호 저장소와 정책을 적용할 수 있었다. 동시에, 이는 서로 다른 두 개의 적합한 데몬이 비슷한 입력에 대해 다른 결정에 도달할 수 있음을 의미했다. 프로토콜이 정의한 응답 형식은 로컬 정책을 전역 규칙으로 만들지 않았다.

논스(nonce)는 응답과 대응했을 뿐, 신원을 만들지 않았다

역사적 UDP 인코딩은 포트 49를 사용했으며, 데몬이 응답에 그대로 복사해 넣는 nonce를 포함했다. 그 목적은 상관(correlation)이었다: 클라이언트는 반환된 데이터그램을 처리 중인 요청과 연관지을 수 있었다. 이 수신 확인은 유용하지만 매우 좁다. 복사된 nonce는 사용자를 인증하지 않았고, 응답이 의도된 서버에서 왔다는 것을 확립하지 않았으며, 패킷을 변경으로부터 보호하지 않았고, 요청된 동작이 올바른 정책 하에서 승인되었음을 증명하지 않았다.

타임아웃은 또 다른 경계를 드러냈다. UDP 클라이언트는 재시도할 수 있었다. 서버는 재시도하지 않았고, RFC는 요청이 실제로 멱등적이지 않았음에도 설계상 멱등적인 요청이 함의된다고 지적했다. 상태가 변경된 이후 첫 응답이 유실되었다면, 더 큰 연결에 관한 질문을 반복하는 것은 의미가 있을 수 있다. 따라서 두 개의 동일한 데이터그램을 보여주는 캡처를 자동으로 하나의 무해한 논리적 사건으로 환원할 수는 없다. 조사자는 요청 식별자, 타이밍, 서버 상태, 터미널 서버의 조치 기록이 필요하다.

평문은 각주가 아니라 운영상의 사실이었다

UDP와 TCP 인코딩 모두 사용자 이름과 비밀번호 자료를 평문으로 전달했다. 이에 따라 RFC 1492의 보안 논의는 네트워크 모니터가 사용자 이름/비밀번호 쌍을 수집할 수 있으며, 이 서비스가 탐색(probing) 표면을 노출한다고 경고했다. 성공적인 응답은 그 이전의 노출을 복구할 수 없다. 행정적으로 통제된 네트워크에서의 운영이 평문을 암호학적 보호로 바꾸지도 않는다.

TCP 인코딩은 다른 문제를 해결했다. 이는 명시적으로 역사적 TACACS와 호환되지 않았고, 예약된 UDP 서비스와의 호환성을 포기하는 대신 더 단순한 프레이밍, TCP가 관리하는 전달, 더 넓은 응답 공간을 얻었다. 신뢰할 수 있는 바이트 전달은 어느 쪽 끝점도 인증하지 않았고, 자격 증명을 암호화하지 않았으며, 정책 집행을 증명하지 않았다. 전송 계층은 수신 확인 하나를 개선했을 뿐 나머지는 그대로 별도로 남겨두었다.

이후의 TACACS+는 1993년을 다시 쓸 수 없다

RFC 8907은 이후 인증, 권한 부여, 회계를 분리하는 스위트로 TACACS+를 문서화했다. 또한 프로토콜 세션이 사용자나 사용자 행위와 반드시 대응하는 것은 아니며, 인증 요청이 권한 부여 요청과 자동으로 연관되지 않는다고 경고했다. 이후의 이러한 구분은 고질적인 증거 문제를 비추지만, RFC 1492가 현대의 TACACS+를 규정한 것처럼 과거로 소급 투영될 수는 없다.

RFC 927은 더 이른 유한한 비교이다: 텔넷 터미널 사용자 신원 인계(handoff)를 기술했다. RFC 1492는 다른 메커니즘을 다룬다—저자의 접근 범위에서 소스 명세서가 빠져 있던 데몬 프로토콜의 재구성이다. 한쪽에서 다른 쪽으로 이어지는 선은 단일한 표준화된 제품사가 아니다. 신원과 접근 결정을 네트워크 경계를 넘어 이동시키려 한 서로 다른 시도들의 기록이다.

역사적 교훈은 실행 코드에 권위가 없다는 것이 아니다. 권위를 정확히 명명해야 한다는 것이다. 코드는 하나의 구현이 관찰된 입력 하에서 무엇을 했는지 증명할 수 있다. 공개된 재구성은 그 동작을 논의 가능하게 만든다. 데몬은 로컬 결정을 내린다. 터미널 서버는 그것을 적용한다. 그러나 이러한 수취 증표 중 어느 것 하나만으로도, 빠진 원본, 모든 참여자의 진위, 또는 세상에서의 최종 효과를 증명할 수는 없다.

출처