요약

  • RFC 3083은 DOCSIS 1.0 베이스라인 프라이버시(Baseline Privacy)를 관리 정보 베이스를 통해 관측 가능하고 부분적으로 변경 가능하게 만들었다. 운영자는 인가 및 트래픽 키 상태를 검사한 뒤 타이머를 조정하고, 유한 상태 기계를 재설정하고, 멀티캐스트 인가를 제어할 수 있었다.
  • 케이블 경로의 암호화가 관리 경로를 자동으로 보호해 주지는 않았다. 이 RFC는 무단 쓰기가 서비스 거부 또는 서비스 절도 공격으로 이어질 수 있다고 경고하며, 별도의 신원·접근 제어 계층을 위해 SNMPv3 USM과 VACM을 권고했다.

보호받는 트래픽 위에는 제어 장치가 있었다

고객 트래픽이 암호화 경로를 통해 흐르고 있는 케이블 모뎀을 상상해 보라. 베이스라인 프라이버시 설정은 활성화되어 있고, 인가 상태는authorized로 보고된다. 현재 트래픽 암호화 키는 아직 만료되지 않았다.

이번에는 어떤 관리 주체가 유효하게 인코딩된 SNMP 쓰기 명령으로 인가 상태 기계를 재설정하는 상황을 상상해 보라.

이 두 장면은 인접한 시점에 동시에 참일 수 있다. 첫 번째는 데이터 평면의 현재 상태를 묘사한다. 두 번째는 그 상태를 만들어 낸 기계 장치에 대한 권한을 행사한다. 암호화가 관리 쓰기를 정당하게 만들어 주지는 않았고, 보이는 상태가 고객의 다음 패킷이 같은 보호를 유지할 것임을 증명하지도 않았다.

2001년 3월에 정보성(Informational) RFC로 공개된 RFC 3083은 DOCSIS 1.0 베이스라인 프라이버시 인터페이스를 위한 SMIv2 관리 정보 베이스를 정의했다. 이는 RFC 2670의 DOCSIS RF 인터페이스 MIB를 확장한 것이다. CableLabs는 BPI를 구현하는 DOCSIS 1.0 케이블 모뎀의 인증 전제 조건으로 프라이버시 MIB의 이전 버전을 요구했다.

이 역사에는 문법상의 주의가 필요하다. MIB 요구는 적합성 의무의 형태를 증명했을 뿐이다. 특정 모뎀이 인증을 받았다는 것, 운영자가 접근을 안전하게 구성했다는 것, 키가 유효하다는 것, 가입자가 보호 서비스를 받고 있다는 것을 증명하지는 않았다.

관측은 상태 기계 안까지 이르렀다

이 MIB는 프라이버시 시스템을 읽을 수 있게 만들었다. 관리자는 프라이버시 활성화 여부, RSA 공개 키, 현재 인가 및 TEK 유한 상태 기계의 상태, 키 시퀀스 번호, 만료 시각, 유예 시간, 재시도 타임아웃, 요청·응답 카운터, 거부, 유효하지 않은 메시지, 오류 기록을 볼 수 있었다.

공개 키 객체는 비밀 키 노출이 아니었다. 더 중요한 점은 증거 경계였다.authorized라는 값은 하나의 상태 기계에서 나온 한 번의 관측이었을 뿐이다. 그것은 패킷 트레이스가 아니었고, 해당 서비스 식별자가 유효한 TEK를 갖고 있다는 증명도, 그 관리 질의 자체가 신뢰할 수 있다는 증거도, 고객 애플리케이션으로부터의 영수증도 아니었다.

RFC 3083은 시간도 노출했다. 키 수명, 재키 유예 기간, 대기 타임아웃은 시스템이 언제 갱신·거부·재시도할지를 결정했다. 만료 타임스탬프는 진단에 도움이 되었지만, 에이전트가 표시하는 시계가 인가부터 암호화 전달, 유용한 서비스에 이르는 전체 체인을 증명할 수는 없었다.

확인된 정오표 334는 이 문서상 경계를 유난히 드러나게 만들었다. 공표된docsBpiCmAuthState열거값은authWait(2)와authorized(3)앞에start(1)을 누락하고 있었다. 정오표는 명세를 수리했다. 그러나 어떤 배포된 에이전트, 관리 도구 또는 로컬 사본이 이 수정을 반영했는지는 밝히지 않았다.

진단 인터페이스는 동시에 명령도 실었다

일부 객체는 관측이 아니었다.docsBpiCmAuthReset을 true로 설정하면 재인가(Reauthorize) 이벤트가 발생하며, 이 객체를 읽으면 항상 false가 반환된다. CMTS에서docsBpiCmtsTEKReset은 활성 트래픽 암호화 키를 무효화하고, 해당 서비스 식별자에 대한 새 TEK를 생성하며, 동기화를 촉진하기 위해 요청되지 않은 TEK Invalid 메시지를 보낼 수 있었다.

이것들은 장애 관리, 가입자 프로비저닝 해제, 보안 사고 대응을 위한 정당한 운영자 도구였다. 동시에 기술(記述)에서 개입으로 넘어가는 지점이기도 했다. 성공한 SET는 에이전트가 명령을 수락했음을 보여줄 뿐이다. 상태 기계가 의도한 상태에 도달했는지, 모뎀이 새 키 재료를 받았는지, 서비스가 회복되었는지는 보여주지 않는다.

멀티캐스트 테이블도 비슷한 권한을 실었다. 한 테이블은 다운스트림 멀티캐스트 주소 프리픽스를 멀티캐스트 서비스 식별자에 매핑했다. 다른 테이블은 각 멀티캐스트 SID에 대해 어떤 케이블 모뎀이 인가되었는지를 제어했다. 모뎀은 자신이 인가된 멀티캐스트 SID에 한해서만 해당 TEK를 받았다. 따라서 행(row)을 바꾸는 일은 대시보드만 바꾸는 것이 아니라 도달 범위를 바꾸는 일이었다.

프라이버시 관리에는 그 자체의 프라이버시와 권한이 필요했다

RFC 3083의 보안 고려 사항은 이 MIB를 무해한 메타데이터로 다루지 않았다. 상태 기계를 재설정하고, 키 수명과 유예 시간을 바꾸고, 멀티캐스트 트래픽을 제어하는 읽기-쓰기 객체들을 명시했다. 무단 수정은 서비스 거부 또는 서비스 절도 공격을 가능하게 할 수 있었다.

선호되는 보호 수단은 SNMPv3 프레임워크였다. 즉, 뒤이어 RFC 3414로 명세된 사용자 기반 보안 모델(USM)과 RFC 3415의 뷰 기반 접근 제어 모델(VACM)이었다. USM은 인증되고 보호된 관리 메시지를 다루었고, VACM은 어떤 주체가 어떤 관리 뷰와 연산에 도달할 수 있는지를 결정했다. 보안 전송과 인가된 객체 접근은 별개의 과제였다.

RFC 3083은 더 약한 제어도 기록했다. DOCSIS 장치는 부팅 구성을 통해 관리 스테이션을 주소로 제한하거나 SNMP SET 연산을 비활성화할 수 있었다. 문서는 주소 기반 보호가 소스 스푸핑에 취약할 수 있다고 경고했다. 허용된 주소에서 도착하는 패킷은 최소 권한의 올바른 뷰를 쥔 인증된 주체라는 사실과 동일하지 않았다.

호환성은 오래된 이음새를 남겨 두었다

작업 그룹은 구식DisplayString규약을 쓰는 여덟 개 객체와 바람직하지 않은IpAddress규약을 쓰는 한 개 객체를 알고서도 남겨 두었다. 그 이유는 이전 MIB 버전을 구현한 DOCSIS 1.0 모뎀과의 상호 운용성이었다.

이 선택이 그 규약들을 칭찬한 것은 아니었다. 이는 기설치된 자산 기반의 비용을 특정 지점에 국지화한 것이다. 더 깔끔한 새 스키마는 추상적 설계를 개선할 수 있었지만, 이미 인증된 장비와 관리 소프트웨어 속에 자리 잡은 작동 중인 조정 체계를 깨뜨렸을 것이다.

이 모델은 계속 진화했다. RFC 4131은 베이스라인 프라이버시 플러스(Baseline Privacy Plus)를 위해 이를 확장하며 케이블 모뎀 및 다운로드 소프트웨어 인증을 추가하면서 원래 구조를 대체로 유지했다. RFC 9141은 MIB 유지 관리가 CableLabs로 이동한 뒤 연락처, 참조, 설명 자료를 갱신했고, 관리 객체 자체는 명시적으로 바꾸지 않았다. 프로토콜 역량, 문서 관리, 배포된 운영 상태는 서로 다른 세 개의 계층으로 남았다.

RFC 3083의 오래 지속되는 교훈은 관리 기능이 프라이버시를 약하게 만든다는 것이 아니다. 보안 기계 장치는 작동 가능해지는 순간 새로운 권한 표면이 된다는 것이다. 데이터 경로가 암호화되어 있어도 그 타이머, 재설정, 멤버십 결정은 다른 제어 시스템에 노출될 수 있다. 증거는 두 경로를 모두 따라가야 한다.

출처

  1. https://www.rfc-editor.org/info/rfc3083
  2. https://www.rfc-editor.org/rfc/rfc3083.html
  3. https://datatracker.ietf.org/doc/rfc3083/
  4. https://www.rfc-editor.org/errata/rfc3083
  5. https://www.rfc-editor.org/rfc/rfc2669.html
  6. https://www.rfc-editor.org/rfc/rfc2670.html
  7. https://www.rfc-editor.org/rfc/rfc3414.html
  8. https://www.rfc-editor.org/rfc/rfc3415.html
  9. https://www.rfc-editor.org/rfc/rfc4131.html
  10. https://www.rfc-editor.org/rfc/rfc9141.html
  11. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/