요약

  • RFC 3324는 행정적 멤버십과 운영상 신뢰를 분리했다. B가 A를 신뢰하려면 B와 A 사이에 보안 연결이 있고, A가 해당 도메인에 속한다고 명시하는 구성이 B 측에 있어야 했다.
  • 수신자가 신뢰하지 않는 노드에서 도착한 주장된 신원은 진위성이나 무결성에 대한 어떠한 보장도 갖지 못하며, 표시·전달·서비스 판단에서 반드시 제외되어야 했다.

도메인은 일괄 자격 증명이 아니었다

“신뢰 도메인”이라는 표현은 잘못된 심상을 불러일으킨다. 즉, 그 안의 모든 참여자가 서로를 믿을 수 있는 경계 안쪽 영역이라는 그림이다. RFC 3324는 그런 지름길을 거부했다. 노드가 도메인 T에 속한다는 것은Spec(T)라 불리는 합의된 규격과 구성 집합을 따른다고 알려져 있을 때 성립했다. 그 멤버십은 운영자들이 만들었다. 한 운영자는 자신의 장비를 알 수 있고, 여러 운영자는 쌍방 협약을 통해 도메인에 합류할 수 있었다. 그러나 그 어떤 것도 모든 노드가 다른 모든 노드와 보안이 확보되고 구성된 관계를 자동으로 갖게 해 주지 않았다.

문서는 더 좁은 명제를 정의했다. B가 A를 신뢰하는 조건은 B에서 두 가지가 참일 때뿐이었다. 노드들 사이에 보안 연결이 존재하고, B에 A를 도메인 멤버로 식별하는 구성이 있다는 것. 방향이 중요했다. B는 A를 신뢰하면서 A는 B를 신뢰하지 않을 수 있었다. 수신자는 자신이 도메인 바깥에 있더라도 직접적인 네트워크 중개자를 신뢰할 수 있었다. 이어서 RFC의 도표는 이 점을 부정하기 어렵게 만들었다. A, B, C가 모두 하나의 신뢰 도메인 안에 있었는데, A는 C를 신뢰하고 B를 신뢰하지 않았다.

이 구분은 신뢰를 국소적으로 검증 가능한 연결(edge)로 바꾸었다. 멤버십은 호환성 집합의 속성이었다. 수용은 특정 수신자가 특정 피어에 대해 내리는 판단이었다. 수신자는 도메인 안 모든 노드의 완전한 신뢰 상태를 담은 신탁(oracle)을 갖지 않았다. 그래서 RFC 3324는 “노드가 신뢰하는 노드로부터 정보를 수신할 때” 같은 문장을 거부했다. 더 정확한 표현인 “자신이 신뢰하는 다른 노드로부터 수신한 정보”만을 허용했다.

주장된 신원은 연결을 따라갔다

네트워크 주장 신원(Network Asserted Identity)은 SIP 네트워크 중개자가 수행하는 인증 과정에서 시작되었다. 그 결과로 나오는 신원은 담당 도메인 또는 번호 범위 안에서 의미를 갖는 SIP URI, 보안 SIP URI 또는 전화 URI일 수 있었다. 인증 방법과 최소한 그 신뢰도는Spec(T)의 일부였다. 사용자가 선호하는 신원을 제안할 수는 있었지만, 그 선호가 주장된 값에 반영되는지는 도메인 정책이 결정했다.

평범한 From 필드는 같은 증거를 제공하지 않았다. SIP는 사용자가 원하는 별칭을 내세우는 것을 허용했다. 의존하는 사용자 에이전트는 다른 사용자 에이전트를 직접 인증하는 데 필요한 키 재료가 없을 수 있었다. 그래서 단기 네트워크 메커니즘은 중개자가 신원을 도출하고, 같은 규칙을 이해하는 보안 연결된 노드들을 통해 그 신원을 전달하도록 했다.

그러나 이 주장은 경로로부터 자유롭게 떠다니지 않았다. 수신자에서 그 값이 유효하기 위해서는 직접 보낸 쪽이 수신자가 신뢰하는 노드여야 했다. 신원이 신뢰하지 않는 노드에서 도착했다면, RFC 3324는 그것이Spec(T)에 따라 생성·전송되었음을 수신자가 알 수 없으므로 진위성이나 무결성에 대한 어떤 보장도 갖지 않는다고 말했다. 그 결과는 놀랄 만큼 구체적이었다. 그 정보는 표시되어서도, 계속 전달되어서도, 서비스 입력으로 사용되어서도 안 된다.

이것은 보안 채널이 상류의 모든 사실을 증명한다는 주장이 아니었다. 채널은 제3자에 의한 열람과 감지되지 않는 변경으로부터 보호하고, B가 A를 보낸 쪽으로 식별하도록 허용했다. A를 합의된 도메인에 연결한 것은 수신자의 올바른 구성이었다. 최초 인증에 대한 신뢰는 여전히Spec(T), 신원을 도출한 중개자, 실제로 수행된 절차에 의존했다. 각 수신은 서로 다른 질문에 답했다.

호환성 집합이지 인터넷 전역 신원이 아니었다

RFC 3324는 자기 목표를 거듭 한정했다. 그 요구사항은 공통 규칙을 따른다고 알려진 장비들의 공동체 안에서의 교환, 그리고 그런 노드에서 자신을 신뢰하는 바깥의 수신자로 이어지는 보안 직접 연결을 다루었다. 임의의 인터넷 호스트들 사이에서 네트워크 주장 신원을 일반적으로 전송하는 것은 범위 밖이었다. 보안 절은 다른 용도에 심각한 결함이 있다고 경고했다. 수신 측에는 그 정보가 변경되지 않았다는 보장도, 애초에 올바르다는 보장도 없었다.

Spec(T)는 표준 문서 인용보다 더 미묘했다. 반드시 하나의 작성된 문서일 필요는 없었다. 그것은 참여자들이 무엇이 주장되는지, 어떻게 결정되는지, 인증 강도가 어느 정도인지, 무결성이 어떻게 보호되는지, 어떤 프라이버시 정책이 적용되는지를 이해하는 데 사용하는 합의된 정보였다. 그런 운영 합의 없이는 헤더 이름만으로는 불완전한 증거였다.

프라이버시도 이 연결을 제약했다. 메시지는 주장된 신원을 다른 사용자에게 전달해서는 안 된다고 표시할 수 있었다. 별도의 표시는 사용자 본인의 요청을 기록할 수 있었다. 도메인 정책이 사용자 의도와 다른 법적 또는 운영상 이유를 구분할 수 있기 때문이다. 신원은 신뢰된 네트워크 안에서는 유지되면서 바깥 사용자에게는 제공되지 않을 수 있었다. 이는 RFC 3323의 관찰자 기준 프라이버시 모델과 양립했지만, 같은 메커니즘이나 같은 주장은 아니었다.

이후 RFC 3325는 주장된 신원을 위한 사설 SIP 확장을 제공했고, RFC 5876이 그 메커니즘을 갱신했다. RFC 4474, RFC 8224, RFC 8225는 인증된 신원과 PASSporT에 대한 서로 다른 접근을 발전시켰다. 이 문서들이 존재한다고 해서 RFC 3324가 소급하여 보편적 증명이 되는 것은 아니다. RFC 3324가 여전히 가치 있는 이유는 네트워크 주장 밑에 숨어 있던 전제를 드러냈다는 점이다. 수신자는 피어를 이름으로 지정하고, 채널을 검증하고, 멤버십 구성을 알고, 그 주장을 만들어낸 규칙 집합을 이해해야 한다.

역사적 교훈은 정확하다. 도메인 경계는 호환 가능한 행동을 정리할 수 있었지만, 모든 참여자를 대신하여 검증을 수행할 수는 없었다. 신뢰는 주변에 흥성히 존재하는 것이 아니었다. 존재한다면, 수신자가 설명할 수 있는 방향성 연결을 따라 도착했다.

출처