요약

  • P-Preferred-Identity는 인증된 주체의 유효한 신원들 가운데 하나를 고르는 힌트였으며, 프록시는 재전송되는 모든 메시지에서 이를 제거해야 했다.
  • 신뢰할 수 없는 출처에서 온 P-Asserted-Identity는 인증 후 구성된 신원으로 교체되거나 제거되어야 했다. 헤더 이름 자체는 어떤 권한도 부여하지 않았기 때문이다.

선택은 들어가고, 증거는 나간다

SIP의 From 필드는 상대방이 원하는 별칭을 제시할 수 있게 했다. 이 동작은 대화에 도움이 되었지만, 발신자 신원을 제공하고 출처를 추적하며, 수신자에게는 신원을 숨긴 채 일부 기능을 유지하려던 전화망들의 요구를 충족하기에는 부족했다. RFC 3325는 어휘상 가까워 오히려 권한의 차이를 가릴 수 있는 두 개의 사신(private) 필드를 추가했다.

P-Preferred-Identity는 사용자 에이전트에서 온다. 프록시에게 이렇게 말한다: 인증 후 실제로 나에게 속한 신원들 중에서 이것을 선호한다. P-Asserted-Identity는 신뢰망에서 온다. 어떤 중간자가 출처를 인증했거나 신뢰하는 피어의 결과를 수용했다고 말한다. 따라서 From, 선호, 주장은 같은 이름의 세 단계 버전이 아니라 서로 다른 권위에 귀속된 세 가지 행위였다.

프록시가 자신이 신뢰하지 않는 주체로부터 선호를 받으면, 그것은 힌트로만 사용할 수 있었다. 프록시는 이 값을 인증된 사용자에게 알려진 유효 신원들의 집합과 비교해야 했다. 일치하는 것이 없으면 다른 주장을 생성하거나 요청을 거부할 수 있었다. 단순 복사로 희망을 사실로 바꿀 수는 없었다.

결정 후 프록시는 재전송하는 모든 메시지에서 사용자가 제공한 P-Preferred-Identity를 제거해야 했다. 이 삭제가 출처(provenance)를 지켰다. 하류에는 네트워크가 주장한 신원만 남았고, 선택에 참여한 제안은 남지 않았다. 둘 다 남아 있다면, 나중에 아카이브나 서비스가 같은 정보를 두 번 세어 버릴 수 있었다. 한 번은 선호로, 한 번은 확인으로.

거짓 주장은 재구성되어야 했다

신뢰할 수 없는 요소로부터 받은 P-Asserted-Identity에 대한 규칙은 더 엄격했다. 프록시가 주장을 추가하려면 먼저 발신자를 인증하고 그 인증에서 얻은 신원을 사용해야 했다. 필드 이름을 정확히 쓸 줄 아는 사용자가 권위가 되는 것은 아니었다.

신뢰할 수 없는 입력에 이미 SIP 또는 SIPS 신원이 있으면, 프록시는 그것을 자신이 구성한 단일 SIP 또는 SIPS 값으로 교체하거나 필드를 제거해야 했다. 전화 형식의 값에도 같은 규칙이 적용됐다. 해법은 값을 남겨 두고 신뢰 표시를 덧붙이는 것이 아니었다. 옛 권위는 파괴되거나, 프록시가 통제하는 요소들로부터 완전히 새로 만들어져야 했다.

반대로 프록시가 신뢰하는 노드가 보낸 주장은 프록시가 직접 사용자를 인증한 것처럼 사용할 수 있었다. 이 지름길은 RFC 3324에서 이어진 것으로, 안전한 연결, 구성된 멤버십, 그리고 인증, 보안, 멤버, 개인정보 정책 및 컴플라이언스를 기술하는Spec(T)를 전제했다. 그러나 이는 필드를 종단 간 암호 인증서로 바꾸지는 않았다.

적용 가능성 선언은 이를 숨기지 않고 인정했다. 주장된 신원들은 암호학적으로 인증되지 않았고, 정확히 어느 행위자가 주장했는지 밝혀 주지 않으므로 주장은 도메인에 귀속시켜야 했다. 선언된 아키텍처 밖에서는 위조, 재전송 공격, 사칭에 노출된 채였다. 이 메커니즘은 인터넷을 위한 일반 모델이 아니었다.

기밀성은 두 번째 삭제를 요구했다

입력 단계의 재구성 후, 각 프록시는 다음 홉을 판단해야 했다. 신뢰할 수 있는 노드로는 자신이 만들었거나 신뢰할 수 있는 출처에서 받은 주장을 유지했다. 신뢰할 수 없는 노드로는 Privacy를 검토했다.

id값은 전송 전에 모든 P-Asserted-Identity를 제거하도록 강제했다. 반대 값인none은 이 삭제를 금지했다. Privacy 필드가 없으면Spec(T)가 정책을 정해야 했다. RFC 3325는 서비스 실패를 피하려고 원칙적으로 신원을 유지할 것을 권장했지만, 기밀 서비스에 접근할 수 없을 때 신원 전송이 사용자가 요청하지도, 막을 수단도 없는 정보를 드러낼 수 있다고 경고했다.

주장된 신원은 하나 또는 둘 존재할 수 있었다. 둘일 때 하나는 SIP 또는 SIPS이고 다른 하나는 전화 형식이어야 했다. 기밀성이 적용되면 모두 사라져야 했다. 하나의 표현만 제거하면 같은 주체가 다른 형태로 새어 나갈 수 있었다.

사용자 서버도 같은 규율을 유지했다. 메시지가 신뢰할 수 없는 선행 요소로부터 온 것이면 P-Asserted-Identity를 어떤 식으로도 사용해서는 안 되었다. 적절한 도메인에서는 서비스가 표시를 선택할 수 있었고, RFC는 여러 개의 형식이 지정된 값을 어떻게 해결할지 강제하지 않았다.

이후 RFC 5876이 이 메커니즘을 갱신했다. RFC 4474, RFC 8224, RFC 8225는 다른 형태의 인증된 신원과 PASSporT를 발전시켰고, RFC 4916은 연결된 신원(connected identity)을 다뤘다. 이 후속 문서들도 초기 교훈을 바꾸지 않는다. 권위는 필드의 철자에 있지 않았고, 검증 가능한 삭제가 수반되는 통제된 변환에 있었다.

이처럼 RFC 3325는 정당한 입력이 결정에 영향을 주면서도 스스로 증거가 되지 않을 수 있음을 보여 준다. 프록시는 사용자의 희망이 자기 결과인 것처럼 살아남는 것을 거부할 때만 주장을 만들어 냈다.

출처