요약

  • IDENT는 전역 디렉터리에 어떤 사람이 누구인지 묻지 않았다. 원격 서버가 상대 호스트의 TCP 포트 113을 열어 기존 TCP 연결의 정확한 로컬·외부 포트 쌍을 제출했다.
  • 프로토콜의 이름은 권한의 실체가 분명해지면서 좁아졌다. 1984년의 Authentication Service와 1985년의 Authentication Server Protocol은 1993년의 Identification Protocol이 되었고, 그 명세는 USERID 응답을 인가로 취급하는 것을 금지했다.
  • USERID, HIDDEN-USER, UNKNOWN-ERROR는 원격 호스트가 자체 정책에 따라 내놓은 보고였다. 이를 감사 기록을 풍부하게 하는 데 쓸 수는 있었지만, 호스트는 거짓말을 하거나 사용자를 숨기거나 아예 연결을 매핑하지 못할 수도 있었다.

하나의 대화가 두 번째 대화를 낳았다

호스트 A가 로컬 포트 6191에서 호스트 B의 Telnet 포트 23으로 TCP 연결을 열었다고 하자. 호스트 B는 그 연결을 보고 로그 옆에 붙일 계정 이름을 원한다. B는 Telnet에 필드를 추가하거나, 애플리케이션 텍스트를 들여다보거나, 중앙 신원 제공자에게 묻지 않는다. 대신 포트 113의 호스트 A 서비스로 새 TCP 연결을 되돌려 연다.

그 역방향 연결에서 B는6191, 23을 보낸다. 첫 번째 숫자는 질의에 답하는 기계인 A의 TCP 포트이고, 두 번째는 질의를 던지는 기계인 B의 포트다. 이제 A는 그 두 호스트와 그 두 엔드포인트를 잇는 연결을 찾을 수 있다. 찾으면 A가 선택한 운영체제 레이블과 식별자를 담은 USERID 응답을 반환할 수 있다.

RFC 1413에 명세된 이 안무는 이례적인 형태의 프로토콜 자기조망이었다. 데이터 연결 자신은 자신의 소유자를 식별하지 않았다. 두 번째 연결이 그 연결을 만든 호스트에게 로컬 상태를 들여다보라고 요청했다. 답은 네트워크를 건너갔지만, 귀속이라는 행위 자체는 최초의 기계 안에 남아 있었다.

이 기하 구조가 경계를 제공했다. 질의는 질의 연결과 동일한 두 IP 호스트 사이의 TCP 연결에만 적용되었다. A는 자기 시스템의 모든 사용자를 물을 수도, 무관한 흐름의 소유자를 물을 수도 없었다. 두 개의 주소는 역방향 연결에서, 두 개의 포트 번호는 요청에서 왔다. 함께 그것들은 A의 연결 테이블에서 후보 하나를 골라냈다.

인증이 최초의 야망이었다

닫힌 기록에서 가장 이른 문서는 더 강한 이름을 썼다. 1984년 9월에 발표된RFC 912는 포트 113의 "Authentication Service"를 묘사했다. 이 문서는 FTP 서버가 애플리케이션 대화에서 제공된 사용자 이름이 TCP 연결을 소유한 사용자와 일치하는지 검증하는 상상을 했다. 또한 특권 연산과 호스트 간 신뢰를 논의했다.

제안에는 이미 경고가 담겨 있었다. 그 유용성은 외부 호스트가 정직하게 보고하고 그 서비스를 로컬 조작으로부터 보호한다는 신뢰에 달려 있었다. 기계가 공급한 사용자 이름은 그 기계의 회계, 운영체제, 관리 규율만큼밖에 강하지 않았다.

RFC 931은 1985년 1월에 Authentication Server Protocol을 형식화했다. 여기서 익숙한 포트 쌍 질의와 USERID 또는 ERROR 응답이 등장했다. 이 문서는 접근 매핑도 다루었다. 서버가 보고된 식별자를 참고해 어떤 로컬 권한을 노출할지 결정할 수 있다는 것이었다.

이 어휘는 하나의 아키텍처적 희망을 드러냈다. 원격 시스템이 연결 뒤의 사용자를 이름으로 지목할 수 있다면, 애플리케이션은 더 이상 별도의 식별 교환을 필요로 하지 않을지도 모른다. 그러나 프로토콜은 그 사용자를 검증하지 않았고, 되돌아오는 경로를 보호하지도 않았으며, 그 이름이 무엇을 의미하는지에 대한 공유 정책도 수립하지 않았다. 다만 하나의 호스트에 자기 자신의 로컬 연관성을 보고하도록 요청했을 뿐이었다.

이름 바꾸기가 패킷이 애초에 가지지 못했던 권한을 제거했다

1993년 2월 IETF IDENT 작업반은 RFC 1413을 발표해 RFC 931을 대체하고 이름을 "Identification Protocol"으로 바꾸었다. 명세는 새 이름이 기능을 더 잘 반영한다고 말한다. 그 문장은 외관상의 정리가 아니다. 시스템의 이름이 담아낸 주장에 대한 교정이다.

이후의 RFC는 그 정보가 아무리 좋아도 감사에 유용할 뿐이라고 밝힌다. 접근 제어 식별자로 사용해서는 안 된다. 어떤 사이트가 USERID 응답이alice라고 말했다는 이유로 접근을 허가한다면, 침해되었거나 의도적으로 기만적인 원격 호스트는 그저alice를 반환하면 그만이다. 그 추가 조회는 애플리케이션 자격 증명을 상대측이 통제하는 주장으로 바꾸어 놓았을 것이다.

여기서 식별이란 TCP 연결과 로컬 식별자 사이의 주장된 연관성을 뜻했다. 네트워크가 인간을 인증했다는 뜻도, 두 사이트가 같은 문자열에 같은 의미를 부여했다는 뜻도, 반환된 주체가 요청된 연산에 대해 인가되었다는 뜻도 아니었다.

이 한계는 프로토콜의 정직한 사용을 오히려 강화했다. 메일, 채팅 또는 터미널 서버는 보고된 이름을 주소, 포트, 시각 옆에 기록할 수 있었다. 사건이 발생하면 원격 관리자는 그 기록을 로컬 로그인 및 프로세스 증거와 대조할 수 있었다. 그 결과는 두 운영자가 같은 사건을 찾는 데 도움이 될 수 있었다. 그러나 그 자체로 사건을 확정할 수는 없었다.

두 포트의 순서도 근거의 일부였다

포트 쌍 구문은 방향이 바뀌기 전까지는 사소해 보인다. 각 측은 자기 엔드포인트를 "로컬"이라고 부른다. 따라서 IDENT 질의를 만드는 서버는 원래 연결에서 관찰한 쌍을 뒤집어야 했다.

A:6191에서 B:23으로의 연결에서 B는 로컬 포트 23과 외부 포트 6191을 관찰한다. 그러나 A에 보내는 질의에서는6191, 23을 보낸다. 질의는 답하는 호스트의 관점에서 정렬되기 때문이다. 이 필드를 잘못 뒤집으면 서로 다른 튜플에 대한 질문이 되어 INVALID-PORT나 쓸모없는 답이 나올 것이다.

IP 주소는 질의 문자열에 반복되지 않았다. RFC 1413은 질의를 실어 나르는 TCP 연결로부터 그 주소를 도출했다. 이 선택은 모호성을 줄였지만 암호학적 결합을 만들지는 않았다. 패킷은 여전히 평범한 네트워크를 통과했고, 질의받은 호스트는 여전히 응답의 내용을 생성했다.

이 정확한 튜플이 운영상 중요했던 이유는 포트가 임시적이고 재사용 가능하기 때문이었다. 질의 시각이 없는 기록은 우연히 같은 번호를 재사용한 나중 연결에 맞춰질 수 있었다. 따라서 감사 시스템에는 원래 연결의 주소, 포트, 방향, 시각에 IDENT 교환 자체까지 필요했다. 사용자 이름은 하나의 관찰일 뿐, 포트의 시간을 초월한 속성이 아니었다.

USERID는 로컬 네임스페이스를 경계 너머로 실어 날랐다

성공적인 응답은 에코된 포트 쌍, 응답 유형 USERID, 운영체제 유형, 그리고 문자열을 담았다. 운영체제 필드는 수신자에게 식별자를 어떻게 해석할지 알려 주었다. 선택적 문자 집합 매개변수는 두 번째 문제를 다루었다. 양측이 이름이 반환되었다는 데 동의하더라도, 그 인코딩에 대해 합의할 필요가 있었다.

RFC 1413은 운영체제 값OTHER도 허용했다. 이 경우 응답은 전통적인 사용자 이름이 아니라 형식 없는 토큰일 수 있었다. 이는 프로토콜이 호스트가 정의한 식별자를 운반한다는 명시적인 일깨움이었다. 수신자는 유닉스 계정 이름, 전 세계적으로 유일한 인물, 안정적인 직원 기록이라고 가정할 권리가 없었다.

서버에는 프로세스나 명령에 대한 불필요한 세부 정보가 아니라 관리자에게 유용한 식별자를 반환하도록 권고되었다. 이 구분이 공개 범위를 제한했다. 프로토콜의 목적은 소켓 뒤의 모든 것을 원격으로 검사하는 것이 아니라, 답하는 시스템과의 상관이었다.

오류는 실패인 동시에 정책이었다

오류 어휘는 비공개가 의도적일 수 있음을 보여 주었다. INVALID-PORT는 질의가 변형되었거나 유효 범위를 벗어났다는 뜻이었다. NO-USER는 호스트가 지정된 연결에 대한 사용자를 식별할 수 없다는 뜻이었다. HIDDEN-USER는 알지만 정책상 공개할 수 없다는 뜻이었다. UNKNOWN-ERROR는 구현이 내부 상태를 노출하지 않도록 피할 수 있는 길을 열어 주었다. 응답 전에 연결이 닫힌 경우에도 같은 방식으로 처리하기로 했다.

이 상태들은 서로 바꿔 쓸 수 있는 근거가 아니었다. NO-USER는 익명 사용을 증명하지 않았다. HIDDEN-USER는 부정 행위를 증명하지 않았다. UNKNOWN-ERROR는 매핑이 존재하지 않는다는 것을 입증하지 않았다. 각각은 답하는 서비스가 그 시점에 반환할 의향이 있거나 능력이 있는 것이 무엇이었는지를 서술했다.

RFC 1413은 이 프라이버시 문제를 CallerID나 Finger 같은 서비스와 비교했다. 하나의 호스트 안에서는 평범한 사용자 이름이, 연결을 받는 임의의 원격 서버가 이를 물을 수 있게 되는 순간 새로운 공개가 된다. 사이트는 서비스를 비활성화하거나, 선택된 사용자를 숨기거나, 토큰을 반환할 수 있었지만, 각 선택은 원격 로그의 가치와 해석을 바꾸었다.

따라서 프라이버시는 그 외에 객관적인 조회에 덧붙인 부가물이 아니었다. 프라이버시는 관찰 가능한 결과 자체를 형성했다. 침묵, 은폐, 로컬 별칭은 모두 서로 다른 정책 아래서 정당한 결과였다.

MIB도 같은 경계를 비추었다

RFC 1414는 Identification Protocol을 위한 Management Information Base를 정의했다. 그 테이블은 로컬 주소, 로컬 포트, 원격 주소, 원격 포트를 인덱스로 사용하고 사용자 식별자와 상태를 노출했다. 이 모델은 포트 113 교환이 아니라 관리 시스템 안에서 같은 네 부분으로 된 연결 기하 구조를 반복했다.

MIB는 현재 Historic로 분류되어 있고, RFC 1413은 RFC Editor에서 Proposed Standard로 목록에 올라 있다. 이 상태 차이를 현재의 배포 상태에 대한 주장으로 바꾸어서는 안 된다. 이 문서들은 명세의 역사와 권한 경계를 확립할 뿐, 현재 호스트들의 인구조사가 아니다.

MIB는 같은 경고도 반복했다. ident 응답은 권위적이지 않으며 접근 제어에 사용해서는 안 된다. 값을 구조화된 관리 데이터로 옮기는 것이 그 증명을 개선하지는 않았다. 컬럼은 보고를 조회하기 쉽게 만들 수는 있어도 더 진실하게 만들지는 못했다.

등록은 문을 표준화했지, 답을 표준화하지 않았다

현재의IANA Service Name and Transport Protocol Port Number Registry는 TCP 포트 113에 대해ident와 더 오래된auth이름을 모두 기록하고 있다. 레지스트리는 구현들이 서비스가 어디에 귀를 기울이는지 합의하게 하고 역사적 별칭을 보존한다.

레지스트리는 응답에 이름이 올라 있는 사용자를 인증하지 않는다. 포트 등록은 만남 지점을 조율할 뿐, 그 지점 뒤의 운영체제, 계정 데이터베이스, 프라이버시 정책, 관리자를 통제하지 않는다. 이것이 바로 이름 바꾸기가 명시적으로 만든 구분이다. 공유된 프로토콜 문법은 질문을 표준화할 수 있지만, 모든 답의 진실을 중앙화할 수는 없다.

사용자 이름은 인가할 권한을 잃음으로써 유용해졌다

IDENT의 지속적인 교훈은 모든 서비스가 TCP 연결의 소유자를 물어야 한다는 것이 아니다. 이름 같은 값을 공유하더라도 귀속과 인가는 서로 다른 연산으로 남아야 한다는 것이다.

질의에는 정확한 범위가 있었다. 포트의 순서 있는 쌍으로 선택된, 두 호스트 사이의 하나의 연결을 지칭했다. 응답은 관련 로컬 상태를 보유한 호스트에서 왔다. 오류 모델은 불능과 거부를 인정했다. 프라이버시 옵션은 관찰에 비용이 있음을 인정했다. 보안 절은 기만을 인정했다.

그 한계 안에서 응답은 상관 작업의 부담을 줄일 수 있었다. 그 밖에서는 위험한 지름길이 되었다. 원격 시스템이 보고한 로컬 사용자 이름은 그 시스템이 무엇을 말했는지에 대한 증거일 뿐, 사용자가 제시한 자격 증명도 아니고 수신 서비스에 대한 임무 위임도 아니었다.

프로토콜은 이름 안에 인증을 담고 시작해 제목 안에 식별로 끝났다. 그 물러남은 실패가 아니었다. 실제 권한 사슬에 명세가 따라 잡은 것이다.

출처와 증거의 한계

이 출처들은 연이은 프로토콜, 관리 모델, 등록된 서비스 이름을 정의한다. 이 출처들은 현재의 배포, 응답 정확도, 프라이버시 관행 또는 공격 빈도를 측정하지 않는다. 따라서 이 글은 IDENT가 오늘날 널리 활성화되어 있다고 주장하지 않으며, 닫힌 출처 집합이 문서화하지 않은 주소 변환기, 프록시 또는 컨테이너에서의 동작을 추론하지 않는다.