요약

  • RFC 3329는 SIP 사용자 에이전트와 그 첫 홉 개체가 역량 목록을 교환하고, 가장 높은 선호도를 받은 공통 메커니즘을 활성화한 뒤, 선택된 보호 경로를 통해 서버의 완전한 정적 목록을 Security-Verify로 되돌려 보내도록 했다.
  • 이 설계는 최초 제안을 소급적으로 보호하지 않았고, 최신 최강 보안을 보장하지도 않았다. 목록 제거를 탐지할 수 있는지는 허용된 가장 약한 메커니즘이 선택된 후에도 유효한 무결성과 재전송 보호를 제공하는지에 달려 있었다.

보안을 고르기 전에 협상 자체에 보안이 필요했다

대규모 네트워크는 모든 단말을 동시에 업그레이드할 수 없다. 1세대 SIP 기기는 HTTP Digest만 이해할 수 있고, 더 신형 기기는 TLS나 IPsec도 지원할 수 있다. 각 측이 상대의 정확한 메커니즘을 미리 알아야 한다면 전환은 촘촘히 조율된 설정을 요구할 것이다. 단순히 성공할 때까지 메커니즘을 시도한다면, 위조된 실패 응답이 강한 옵션을 사용 불가능한 것처럼 보이게 만들 수 있었다.

명백한 해답은 협상이었다. 클라이언트가 지원 목록을 알리고, 서버가 자신이 지원하는 메커니즘에 순위를 매기고, 가장 좋은 공통 메커니즘을 고르는 것이다. 그러나 최초 요청과 챌린지는 그 선택이 활성화되기 전에 도착했다. 경로상 공격자는 제안에서 TLS를 지우고 Digest를 남겨둔 뒤, 양쪽 단말이 서로 암호화를 제안한 적이 없다고 믿게 만들 수 있었다. 프로토콜이 정상 작동하는 것처럼 보이는 이유는 바로 공격이 양측이 공동으로 지원하는 더 약한 선택을 보존했기 때문이다.

RFC 3329는 아직 존재하지 않는 보안으로 첫 교환을 보호한다는 허구를 만들지 않았다. 대신 협상을 시간축으로 나누었다. 클라이언트는 다음 홉 SIP 개체에Security-Client를 보낸다. 서버는 정적이고 선호 순서로 정렬된Security-Server목록과 메커니즘 시작에 필요한 정보로 응답한다. 클라이언트는 서버 선호도가 가장 높은 알려진 공통 메커니즘을 선택하고 활성화한 뒤, 받은 서버 목록의 복제본인Security-Verify를 담은 또 다른 요청을 보낸다. 서버는 그 반환 목록을 자신의 목록과 비교한다.

최종 비교는 중요한 차원에서 정확해야 했다. 같은 메커니즘이 같은 순서로, 일치하는 매개변수와 함께 나타나야 했다. 공격자가 보호되지 않은 서버 응답에서 가장 강한 항목을 제거했다면, 클라이언트는 축소된 목록을 반환한다. 서버는 여전히 자신의 4항목 정적 정책을 보유하고 있으므로 3항목 영수증을 보고 계속 진행을 거부하고 다시 챌린지를 보낸다.

공격자는 영수증까지 변조하려 할 수 있지만, 두 번째 요청은 이제 선택된 메커니즘으로 보호된다. 단순한 삭제였던 것이 실시간 무결성 보호 위조 시도로 바뀐 것이다. RFC 3329의 보안상 이득은 침투 불가능한 최초 제안이 아니라, 노출된 하나의 메시지를 편집하던 공격을 당사자들이 실제로 수립한 보호를 깨뜨려야 하는 공격으로 전환한 점이다.

정적 목록이 상태 없는 비교를 가능하게 했다

서버 목록은 클라이언트 목록에서 계산될 수 없었다. 서버가 클라이언트가 광고하지 않은 옵션을 제거한다면, 공격자가Security-Client를 편집해 서버 응답에 영향을 주고 그래도 자기 일관적인 영수증을 만들 수 있었다. RFC 3329는 서버가 광고하는 목록이 관련 범위 내에서 정적으로 유지되도록 요구했다. 노드는 인터페이스별로 서로 다른 목록을 유지할 수 있지만, 각 목록은 들어오는 제안과 독립적으로 서 있어야 한다.

이 결정은 SIP 계층에서 합의를 상태 없이 유지하는 효과도 있었다. 서버는 클라이언트마다 맞춤 챌린지를 기억할 필요가 없다. 보호된 요청이 반환되면 서버는Security-Verify를 자신의 설정 목록과 비교한다. 선택된 하위 메커니즘은 여전히 상태를 가질 수 있다. TLS 연결이나 IPsec 연관체처럼 말이다. 그러나 목록 비교에 별도의 협상 데이터베이스는 필요하지 않았다.

선호도는 서로 다른q값으로 표현되었다. 클라이언트는 서버 선호도가 가장 높은 알려진 공통 메커니즘을 선택한다. 따라서 서버의 우선순위가 공통 역량 사이의 선택을 지배하면서도, 클라이언트는 자신의 실제 역량 집합에 대한 지식을 유지한다. 초기 클라이언트 목록을 변경하는 것은 여전히 시작 자료를 교란하거나 양측이 다르게 선택하게 만들 수 있다. 그 눈에 보이는 결과는 실패일 수 있으며, 문서는 이를 공격의 증거가 아니라 가능한 공격 조건으로 다룬다.

절차의 범위는 촘촘했다. 이 절차는 사용자 에이전트를 다음 홉 SIP 개체, 즉 보통 첫 홉 아웃바운드 프록시와 결합한다. 서버가 절차를 시작할 때는 Via 항목이 정확히 하나인지 확인해야 했다. Via 값이 여러 개라면 자신이 첫 홉이 아니므로 이 메커니즘을 적용해서는 안 된다. 이는 통화, 메시지 본문 또는 전체 프록시 체인에 대한 종단 간 보호가 아니었다.

421과 494는 서로 다른 지식 지점을 표현했다

클라이언트는 자신의 목록과 함께 Require 및 Proxy-Require에sec-agree옵션을 붙여 합의를 시작할 수 있다. 보호되지 않은 서버 응답은 목록에 공통 메커니즘이 없더라도 494 Security Agreement Required를 사용하고Security-Server를 반환한다.

서버는 로컬 정책으로 이 확장을 요구할 수도 있다. 보호되지 않은 요청이 지원을 표시하지 않으면 서버는 421 Extension Required를 반환한다. 클라이언트가sec-agree지원을 광고했지만 합의를 아직 완료하지 않았다면 서버는 494를 반환한다. 두 응답 모두 서버 목록과 서버가 선호하는 메커니즘을 시작하는 데 필요한 정보를 담는다.

이 상태 코드는 프로토콜 판단이지 감식 결과가 아니었다. 421은 구형 클라이언트, 분실된 옵션 태그 또는 호환되지 않는 정책을 의미할 수 있다. 494는 협상의 정상적인 첫 수순, 목록 불일치 또는 만료된 상태 이후의 복구일 수 있다. 어느 코드도 공격자를 식별하지 않는다. 유용한 기록에는 수신한 목록, 로컬 정적 목록, 선택된 메커니즘, 보호 결과, 비교 결과가 함께 담겨야 한다.

메커니즘 활성화 방식은 서로 달랐다. TLS는 보호된 연결을 필요로 하며 SIP 서버 위치 규칙을 사용했다. RFC 3329는 TLS가 선택되면 SIP URI를 조회 시점에 보안된 것으로 취급했다. Digest는 기존 인증 프레임워크를 재사용하면서 서버 목록을 덮는 검증 계산을 추가했다. IPsec-IKE는 IKE 연결을 시도했고, 수동 키 IPsec은 대역 외 키와 정책 지식에 의존했다. RFC 3310은 AKA 기반 Digest 이웃을 제공했지만 반환 목록 논리를 대체하지는 않았다.

보안 연관체의 수명 역시 메커니즘별로 남았다. TLS 연결을 닫으면 재협상이 강제된다. IKE는 자체 수명을 갖는다. Digest는 자격 증명이 만료되면 새 챌린지를 유발할 수 있다. 수동 IPsec은 이를 공급하는 대역 외 시스템에 의존한다. 따라서 '합의 성공'은 연관체 식별자와 만료 또는 종료 영수증이 없으면 불완전하다.

수용 가능한 가장 약한 메커니즘이 바닥을 정했다

보안 고려사항은 한계를 분명히 밝혔다. 제안된 가장 약한 메커니즘이라도 반환되는 목록에 대해 최소한 무결성과 재전송 보호를 제공해야 한다. 공격자가 그 메커니즘을 깨뜨릴 수 있다면, 애초에 제안해서는 안 된다. 협상은 강한 것에서 약한 것으로의 손쉬운 다운그레이드를 막을 수는 있지만, 깨진 약한 옵션을 튼튼한 기초로 바꿀 수는 없다.

합의가 기밀성을 의미하지도 않았다. Digest는 SIP 내용을 암호화하지 않으면서 선택된 값을 인증하고 보호할 수 있다. TLS는 그 홉을 보호할 수 있지만, 그 홉을 넘어서는 종단 간 기밀성을 제공하지 않는다. IPsec의 속성은 실제로 수립된 연관체와 정책에 달려 있다. 헤더의 동일성은 서버의 설정 목록과 반환된 영수증이 한 비교 지점에서 일치함을 증명할 뿐이다. 이는 나열된 각 알고리즘의 현대적 강도, 이후 모든 홉의 신원, 세션의 기밀성을 증명하지 않는다.

시간은 기준을 바꾸었다. RFC 3329는 2003년 1월에 발표되었다. RFC 8996은 이후 TLS 1.0과 TLS 1.1의 협상을 금지하며 이를 갱신했다. RFC 8446은 TLS 1.3을 정의하고, RFC 7616은 HTTP Digest를 현대화했다. 이 문서들은 역사적 영수증 메커니즘을 바꾸지 않지만, 'tls' 같은 2003년 토큰이 과거 그 토큰에 결부된 모든 버전에 대한 현재의 승인으로 읽히는 것을 막는다.

정오표 기록은 또 하나의 근거 경계를 추가한다. 두 예시 구절은 ACK에 Security-Verify가 담겼다고 말하는 반면, 규범적 헤더 사용 표는 해당 헤더를 ACK에 적용 불가로 표시한다. 이 수정은 문서 갱신을 위해 보류 중이다. 확인된 정오표 하나는ipsec-3gppSPI 문법을 정확히 10자리에서 1자리부터 10자리로 변경한다. 구현자와 역사가는 규범적 규칙, 예시 텍스트, 후속 수정을 구분해야 한다.

IANA SIP 파라미터 레지스트리는 메커니즘 이름과sec-agree할당을 보존한다. 등록은 토큰이 표준화된 소유자와 참조 문서를 갖는다는 것을 증명할 뿐이다. 운영자가 이를 배포했는지, 구현이 이를 따르는지, 메커니즘이 여전히 안전한지를 증명하지 않는다.

RFC 3329의 지속적 기여는 보호가 가능해진 뒤 보호되지 않은 주장을 검증하는 방법이었다. 취약한 순간을 지우지 않았다. 최초 제안을 영수증으로 이어 받으며 정확한 비교를 요구했다. 이 설계 패턴은 역량 협상이 그것을 방어할 채널보다 먼저 일어나는 모든 곳에서 여전히 유용하다. 무엇이 제안되었는지 기억하고, 보호가 활성화되면 그것을 반환하고, 온전한 영수증을 강한 정책과 혼동하지 말라.

출처