RFC 3352, CLDAP을 Historic으로 밀어낸 보안 한계

요약

CLDAP은 UDP를 통해 제한된 LDAP 파생 연산 집합을 전송함으로써 간단한 디렉터리 조회의 연결 오버헤드를 줄였지만, 신뢰성·신선도·재시도는 끝단(엣지)에 남겨두었다.
RFC 3352는 단일 결함을 비난하거나 보편적 실패를 증명하지 않았다. 특히 무결성과 기밀성 결여를 포함한 ‘가능성 있는’ 한계 묶음을 기록한 뒤, 추가 실험이 계속되는 가운데 RFC 1798을 Historic으로 이동할 것을 권고했다.

더 좁은 약속을 담은 더 짧은 조회

CLDAP의 원래 명세는 실용적인 반론에서 출발했다. 디렉터리 읽기 자체는 작을 수 있지만, 그것을 둘러싼 기계 장치는 그렇지 않다는 것이다. RFC 1798은 X.500의 Directory Access Protocol과 일반 LDAP가 요구하는 교환 과정을 더 단순한 요청 경로와 비교했다. 하나의 엔트리에서 몇 개의 속성만 필요로 하는 애플리케이션에게는 연결 설정과 세션 작업이 조회 자체보다 더 많은 시간을 소모할 수 있었다. CLDAP은 바로 그 비용을 제거하려 했다.

그 거래 조건은 명시적이었다. CLDAP은 LDAP의 메시지 구조를 빌려 갖다 썼지만, 이를 UDP 또는 다른 비연결형 전송 계층으로 운반했고 제한된 연산 집합만 노출했다. RFC의 예시는 조회를 4개 패킷으로, 같은 호스트에 배치되거나 캐시된 경우에는 2개 패킷으로 줄였다. 이는 프로토콜 예시이지 벤치마크가 아니었다. 목표는 좁은 작업이었다. 연결 모드 기능이 불필요할 때 작은 답을 빠르게 돌려주는 것이다. RFC 1798은 이 프로토콜을 DAP과 LDAP의 대체물이 아니라 보완재라고 불렀다.RFC 1798

연결을 제거한다고 문제에서 상태가 사라지지는 않았다. 데이터그램은 손실될 수 있으므로 클라이언트는 자신의 운영 조건에 맞게 재시도와 타임아웃을 직접 선택해야 했다. RFC는 하나의 재시도 알고리즘을 규정하지 않기로 했다. 서버는 지연을 줄이기 위해 캐싱을 할 수 있었지만, 디렉터리 경로에는 캐시 무효화 프로토콜이나dontUseCopy제어가 없었다. 따라서 빠른 답은 두 번째 결정에 의존했다. 애플리케이션이 어느 정도의 오래된(stale) 데이터를 허용할 수 있는가. CLDAP은 이 신뢰성과 신선도의 선택을 세션 프로토콜 안에서 해결하는 대신 클라이언트와 배포 환경 쪽으로 밀어냈다.

가장 날카로운 경계는 신원과 보호였다. RFC 1798은 요청 인증을 제공하지 않았다. 편집 노트는 자격 증명을 추가하는 논의가 있었음을 기록하면서도, 왜 하나도 포함되지 않았는지를 설명한다. 인증 오버헤드가 비연결형의 장점을 상쇄할 수 있기 때문이다. 결론은 직접적이었다. 인증된 디렉터리 접근이 필요한 애플리케이션은 CLDAP을 사용해서는 안 된다. 보안 절역시 프로토콜 자체는 인증을 제공하지 않으며 익명 또는 단순·비밀번호 없는 서버 바인딩을 기대한다고 명시한다. 속도는 공짜가 아니었다. 그 연산이 안전하게 주장할 수 있는 범위를 좁히는 대가로 얻어진 것이었다.

표준 기록이 달라진 이유

2003년 3월에 발행된 RFC 3352는 1995년 6월에 발행된 RFC 1798을 돌아보았다. 그간의 7년 동안 CLDAP은 널리 배포되지 못했다고 보고했다. 이 표현이 중요하다. 이는 배포 인구조사도, 구현이 존재하지 않았다는 주장도, 현재 사용에 대한 측정도 아닌, RFC에 기록된 당시의 평가라는 것이다.

이 보고서는 증명된 순위가 아니라 여러 ‘가능성 있는’ 이유를 제시했다. CLDAP은 익명이고 읽기 전용이었고, 결과를 작은 크기로 제한했으며, 무결성과 기밀성 보호가 없었고, 국제화와 확장성이 부족했으며, 독립적으로 개발된 여러 구현이 없었다. 이 제약들은 서로를 강화한다. 작은 조회는 유용할 수 있지만, 자신의 요청을 보호하거나 검증할 수 없고 더 큰 결과를 반환할 수 없으며 독립 구현 기반이 얇은 프로토콜은 신뢰할 수 있는 공유 인터페이스로 발전시키기 더 어렵다. RFC는 어느 결함이 가장 중요했는지, 모든 배포가 모든 한계에 직면했는지를 확립하지 않는다.RFC 3352

유지 보수 문제도 있었다. RFC 3352는 구식 명세들, 이를테면 오래된 X.500 자료와 RFC 1487에 대한 규범적 참조를 언급했다. 갱신 없이는 이 참조들이 RFC 1798을 Standards Track에 계속 머물게 할 수 없었다. LDAP 확장 작업 그룹(LDAP Extensions Working Group)은 1997년 LDAP 확장 작업을 위해 charter되었으나, RFC 3352는 그 그룹이 CLDAP 갱신 없이 마무리되고 있으며 그 시점에 남아 있는 CLDAP 표준화 노력은 없다고 밝혔다. 이 문서는 구현상의 약점을 문서 유지 보수와 연결한다. 그 격차를 메우거나 의존 관계를 새로 고칠 수 있는 활성 개정 경로가 없었던 것이다.

그 결과는 대체 프로토콜이 아니라 RFC 1798을 Historic으로 이동하라는 권고였다. RFC 3352는 비연결형 디렉터리 접근에 대한 관심이 여전히 남아 있지만, 운영 경험상 특히 보안을 중심으로 더 많은 실험이 필요하다고 말한다. 이 문서는 독자를 LDAP-over-UDP 초안이라는 진행 중인 작업과 다른 가능한 대안들로 안내하며, 그 초안이 후속 표준이 되었다고 주장하지는 않는다. RFC 1777로 명세된 LDAPv2의 Historic 이동은 별개로 RFC 3494에서 이루어졌다. RFC 3352는 CLDAP에 관한 것이며, 이를 LDAP 전체의 은퇴로 환원해서는 안 된다. 이후의 LDAPv3 문서들, RFC 3377과 이어서 RFC 4510–4513은 서로 다른 연결 지향 표준 맥락을 제공한다. 그 존재가 CLDAP 제품들이 실제로 무엇을 했는지를 증명하지는 않는다.

상태 레이블은 프로세스 정지 명령이 아니다

‘Historic’은 표준 기록에 관한 질문에 답한다. 이 명세는 더 이상 현재 표준 트랙의 목적지로 취급되어서는 안 된다는 뜻이다. 그것 자체만으로 서버에서 코드를 제거하거나, 오래된 로컬 설치를 무효화하거나, 모든 운영자가 사용을 중단했다는 것을 증명하지는 않는다. RFC 3352 자체의 표현은 신중하다. 상태 권고를 하고, 당시의 배포 판단을 서술하며, 은퇴가 인터넷 보안에 영향을 주지 않을 것이라고 말한다. 마지막 문장은 RFC 저자의 평가이지, CLDAP이 안전했다는 증거도 로컬 위험이 없었다는 증거도 아니다.

따라서 이 역사는 단순한 ‘구식 프로토콜의 이야기’보다 더 많은 것을 알려준다. CLDAP은 조회의 초기 비용을 최소화하려 했다. 이후의 기록은 그 좁은 설계가 프로토콜을 신뢰할 수 있게 만드는 공유 요구 사항들, 즉 충분한 보안, 사용 가능한 국제화, 확장성, 독립 구현, 유지 가능한 참조를 여전히 충족할 수 있는지를 묻는다. 설계자들은 인증 트레이드오프를 숨기지 않았고, RFC 1798이 이를 밝혔다. RFC 3352가 추가한 것은 전체 제안이 그 제약들 속에서 생존 가능한 경로를 개발하지 못했다는 수명 주기 판단이다.

여기서의 편집 렌즈는 의도적으로 제한되어 있다. Lu Heng의 ‘Minimum Initial Specification’과 ‘Running-Code Primarity’ 논증은 독자에게 발행된 조율 아티팩트와 채택된 운영 현실을 구분하고, 선언된 설계와 실행 중인 시스템의 증거를 구분하도록 요청한다. 이들은 IETF의 판정이 아니며 CLDAP의 채택을 확립하지 않는다. 질문으로 적용하면 세 가지 기록을 분리하는 데 도움이 된다. RFC 1798이 명세한 것, RFC 3352가 커뮤니티가 학습했다고 믿은 것, 개별 운영자가 계속 실행했을 수 있는 것이다.

교훈은 비연결형 디렉터리 접근이 본질적으로 결함이 있었다는 것도, 표준 기구가 문서에 레이블을 다시 붙여 배포된 소프트웨어를 사라지게 할 수 있다는 것도 아니다. 더 좁은 교훈은 이것이다. 하나의 보이는 비용을 줄이는 지름길은 보안, 신뢰성, 신선도, 유지 보수 비용을 미해결로 남길 수 있다. 그 비용을 떠안을 활성 개정 노력이나 독립 구현 기반이 없을 때, 표준 트랙 레이블은 기록이 뒷받침하는 것보다 더 많은 성숙도를 약속할 수 있다. 명세를 Historic으로 이동한 것은, 발행·상태·권고를 채택과 동일한 것처럼 가장하지 않으면서 그 한계를 읽을 수 있게 만들었다.