요약

  • RFC 3494는 RFC 1777을 그대로 따르는 독립 개발 LDAPv2 구현체는 기존 구현체들과 상호 운용되지 않을 것이라고 밝혔다. 배포된 문법과 의미가 문서에서 벗어나 있었기 때문이다.
  • LDAPv2와 그 의존 사양을 Historic 등급으로 이전한 것은 표준 커뮤니티의 권고를 바꾼 것이었다. 이는 배포된 엔드포인트를 끄지 않았고, LDAPv3를 선택하는 것만으로 인증, 무결성, 기밀성이 확보되지도 않았다.

적합성(conformance)은 보통 만남의 장소를 약속한다. 두 엔지니어가 같은 공개 문서를 근거로 각자 독립적으로 구현하고, 자신들의 시스템이 의미 있는 메시지를 주고받으리라 기대할 수 있다. RFC 3494는 그 역을 기록했다. 2003년 3월까지 LDAPv2 문서와 실제 설치된 시스템 집단은 서로 다른 좌표가 되어 있었다. 구형 좌표를 정밀하게 따르는 것은 더 이상 실제 존재하는 네트워크로 가는 안전한 경로가 아니었다.

이 분열은 이론으로 제시되지 않았다. RFC 1777은LDAPString문자를 IA5로 제한했고, RFC 1778은 T.61을 포함한 관련 문법 규칙을 제공했다. RFC 3494는 배포된 제품들이 그 한계를 흔히 지키지 않았다고 보고했다. 어떤 제품은 ISO 8859-1을, 어떤 제품은 UCS-2를, 어떤 제품은 UTF-8을, 또 어떤 제품은 그 기기의 현재 로컬 문자 집합을 사용했다. 따라서 "LDAPv2 텍스트"는 단일한 운영 문자 집합을 가리키지 않았다. 실험실 구현체는 RFC가 허용하는 모든 값을 받아들일 수 있어도, 의도한 피어가 내보내는 이름들을 거부할 수 있었다.

두 번째 예는 더 작아서, 그래서 더 많은 것을 드러냈다. RFC 1777은 속성 타입이 X.500 텍스트 이름을 사용해야 한다고 규정했다. 객체 식별자 2.5.4.10은organizationName이었지o가 아니었다. 그런데 기존 LDAPv2 제품들은 흔히 LDAPv3 스키마의 짧은NAME을 사용했다. 명목상의 전임자가 은퇴하기도 전에 배포 생태계는 후속 버전에서 규칙을 들여왔다.

어느 토큰도 그 자체로 하위 디렉터리 객체를 식별하지 못했다. 긴 이름, 짧은 이름, 숫자 OID는 같은 속성 타입을 가리킬 수 있었지만, 파서는 여전히 합의된 매핑이 필요했다. 스키마 수용, 접근 제어, 반환되는 값, 애플리케이션의 판단은 모두 그 사슬 더 아래에 있었다.o를 무해한 약어로 다루는 것은 타이포그래피처럼 보이는 곳에 상호 운용성 선택을 숨겼다.

이것이 RFC 3494의 표현이 중요한 이유다. 그 문서는 기존 LDAPv2 시스템 쌍마다 모두 실패한다고 주장하지 않았다. 같은 추가 규칙을 공유하는 제품들은 서로 통신할 수 있었다. 문서가 말한 것은 사양이 일반적으로 지켜지지 않았으며, 그 사양을 새로 독립적으로 구현한 구현체는 기존 구현체들과 상호 운용되지 않으리라는 것이었다. 운영상의 호환성은 계보 의존적이 되어 있었다. 익숙한 코드의 동작을 모방하는 편이 표준을 읽는 것보다 더 잘 작동할 수 있었다.

이런 조건은 인센티브를 바꾼다. 설치 고객을 유지하는 벤더는 그들의 편차를 보존하는 데서 보상받는다. 새 진입자는 형식적 정확성 때문에 벌을 받는다. 지배적인 제품들을 중심으로 작성된 테스트 스위트는 RFC를 전혀 바꾸지 않고도 그 편차를 사실상의 규칙으로 바꿀 수 있다. 공개 사양은 여전히 열려 있지만, 실질적 진입은 문서화되지 않은 지식에 의존한다.

보안이 떠나야 할 두 번째 이유를 제공했다. LDAPv2에는 데이터 무결성이나 기밀성을 위한 메커니즘이 없었고, RFC 3494는 DIGEST-MD5, Kerberos V, X.509 공개 키 기반의 현대적 인증을 지원하지 않는다고 밝혔다. RFC 1777의 단순 바인드는 평문 비밀번호를 전송했고, 그 Kerberos 선택지는 버전 4에 속했다. RFC 3377로 식별되는 LDAPv3 표준 번들은 앞선 IESG 우려를 다룬 인증 및 전송 보안 작업을 포함했다.

그러나 "LDAPv3"조차 보안 영수증은 아니었다. RFC 4510은 이후 그 스위트를 재편했고, RFC 4513은 그 메커니즘과 요구 사항을 서술한다. 배포는 방식을 선택하고, 자격 증명을 검증하고, 보호된 채널을 수립하고, 인가를 올바르게 적용해야 한다. Bind의 버전 번호는 요청된 프로토콜 버전을 증명할 뿐, 무결성·기밀성·강한 신원이 달성되었음을 증명하지 않는다.

은퇴는 의존성을 통해서도 전파되었다. RFC 1781은 RFC 2253이 더 이상 담지 않는 명명 문법에 의존했다. RFC 2559는 PKIX 저장소를 위한 LDAPv2 프로파일로서 RFC 1777에 의존하면서 RFC 1778을 갱신했다. 따라서 RFC 3494는 이 문서들, LDAPv2 핵심, 이미 대체된 RFC 1484 시대의 조상 문서들이 함께 Historic으로 이동할 것을 권고했다.

Historic은 표준 계층의 조치였다. RFC 2026은 대체되었거나 그 외에도 쓸모없다고 간주되는 사양에 이 등급을 부여한다. RFC 2400은 한 단어짜리 상태는 지시일 뿐이며 더 완전한 적용성 진술이 중요하다고 경고했다. 이 조치는 개발자들에게 RFC 1777로 새 LDAPv2 구현체를 만들지 말라고, 배포자들에게 LDAPv3를 선호하라고 전했다. 소프트웨어를 제거하거나, 389 포트를 닫거나, 세션을 끊거나, 버전 2 트래픽이 얼마나 남았는지 측정하지는 않았다.

이 구분은 실패뿐 아니라 역사적 성취도 보존한다. LDAP은 X.500 디렉터리에 접근하는 비용을 낮추었고 디렉터리 애플리케이션의 확산을 도왔다. 그런 다음 설치된 관례들은 문서화된 계약보다 빠르게 움직였고, 보안 모델은 늙어갔다. RFC 3494는 그 계보를 지우지 않았다. 미래의 조율이 수렴해야 할 목표를 바꾼 것이다.

지속 가능한 감사는 사다리다: 문서 상태, 구현 동작, 활성화된 구성, 협상된 버전, 선택된 문자 및 스키마 규칙, 선택된 보안 메커니즘, 성공적인 교환, 인가, 애플리케이션 결과. 각 단계는 자체 영수증이 필요하다. Historic 레이블은 첫 단계를 정리할 수 있다. 나머지를 조용히 대신해 줄 수는 없다.

출처