요약
- RFC 3045는 LDAP 서버의 루트 DSE에 선택적
vendorName및vendorVersion속성을 정의하여, 클라이언트가 구현 식별 정보를 표시하거나 가능한 소프트웨어 이상을 인식할 수 있게 했다. - 이 문서는 명확한 프로토콜 경계를 그었다. 이 문자열들은 기능을 알아내는 데 사용되어서는 안 된다. 벤더 이름과 릴리스 레이블은 인증된 출처도 아니고, 이 서버나 세션에서 어떤 기능이 동작한다는 증명도 아니었다.
LDAP 클라이언트에는 이미 루트 DSA별 엔트리, 즉 루트 DSE를 살펴볼 이유가 있었다. 이 엔트리는 연결 반대편에 있는 특정 서버를 기술할 수 있었다. RFC 3045는 그 응답에 두 가지 단서를 추가할 수 있게 했다. 바로vendorName과vendorVersion이다. 2001년 1월에 발표된 이 Informational RFC는 서버가 자신의 코드를 누가 구현했는지와 제품의 릴리스 레이블을 노출할 수 있도록 허용했다. 이 속성들은 디렉터리 사용자가 임의로 편집할 수 있는 일반 필드가 아니라 단일 값 운영 데이터였다.
이 제안의 좁은 범위는 의도된 것이었다. 클라이언트는 운영자에게 벤더와 버전을 표시하거나, 알려진 이상과 관련된 릴리스를 인식해 우회 절차를 시도할 수 있었다. 그러나 RFC 3045는 같은 값으로 지원 기능을 추론하는 것을 금지했다. 제작자의 이름은 특정 서버가 어떤 컨트롤, 확장, 메커니즘을 받아들이는지 말해주지 않는다. 릴리스 레이블도 어떤 기능이 이 구성에서 활성화되어 있는지, 이 인증 세션에서 사용 가능한지, 제대로 동작하는지 말해주지 않는다. 기능 광고는 해당 기능 자체를 위해 정의된 메커니즘에 속하는 일이었다.
이 경계는 교환의 양쪽 모두를 매력적인 지름길로부터 보호했다. “벤더 X, 버전 Y”를 기능 협상으로 취급하는 클라이언트는 해당 기능을 위해 마련된 프로토콜 증거를 건너뛸 수 있었다. 그러면 서버가 지원하지 않는 작업을 활성화하거나, 반대로 지원하는 작업을 억제할 수도 있었다. RFC 3045는 대신 벤더 식별이 관찰을 둘러싼 맥락으로 기능하게 하고, 관찰을 대체하지 않도록 했다.
버전 문자열조차 과잉 정밀성에 대비해 설계되었다. RFC는vendorVersion값이 버전 간에 고유할 것만 요구했고, 문법이나 정렬 규칙은 두지 않았다. 매칭 규칙은 동등 비교였지 “보다 작음”이나 “보다 큼”이 아니었다. 우회 절차를 찾는 클라이언트는8.01이8.5보다 오래되었거나 새로운 것이라고 가정하는 대신, 이상과 연관된 정확한 문자열을 일치시킬 수 있었다. 제품 릴리스 레이블은 이름이며, 반드시 비교 가능한 척도 위의 숫자는 아니다.
그리고 정확히 일치하더라도 구현 전체를 기술하지는 않았다. RFC 3045는 같은 버전을 보고하는 인스턴스 중 일부에만 이상이 영향을 미칠 수 있다고 언급했다. 플랫폼, 구성 선택, 플러그인은 서로 다를 수 있다. 또한 반환된 이름이나 버전이 서버가 실제로 그 벤더에 의해 빌드되었거나 실제로 그 릴리스를 실행 중임을 보장하지 않는다고 경고했다. 다시 말해, 진실처럼 보이는 레이블조차 서버가 보고한 내용에 대한 증거일 뿐, 그 바이너리의 인증이나 동작에 대한 완전한 설명이 아니라는 것이다.
이 속성들은 선택 사항이기도 했다. 서버는 그 가시성을 제한할 수 있었고, 클라이언트는 이를 기대하지 않아야 했다. 벤더 문자열이 없다고 해서 서버가 고장이거나 클라이언트가 상호 운용을 거부할 수 있다는 뜻은 아니었다. 이것이 중요한 이유는 문제 해결에 유용한 정보가 적대자에게 소프트웨어 세부 사항을 노출할 수도 있기 때문이다. RFC 3045는 벤더 및 버전 데이터가 누군가 취약점을 찾는 데 도움이 될 수 있다는 위험을 명시적으로 지적했다.
이후의 LDAP 아키텍처도 식별과 기능 사이의 구분을 유지했다. RFC 4512는 루트 DSE를 서버별 운영 엔트리로 기술하고,supportedControl,supportedExtension,supportedFeatures같은 별도의 속성을 나열한다. 이들의 값은 세션 조건에 따라 달라질 수 있다. 현재 IANA LDAP 파라미터 레지스트리도vendorName과vendorVersion에 할당된 두 OID를 여전히 나열하고 있다. 이는 식별자를 확인할 뿐, 어떤 서버의 주장이나 능력을 확인해주는 것은 아니다. RFC 3045의 교훈은 역할 분담이다. 레이블은 운영자가 맥락을 인식하도록 돕게 하되, 연결이 실제로 사용할 수 있는 것이 무엇인지는 기능별 증거가 답하게 하라는 것이다.
출처
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





