요약

  • RFC 1446은 SNMPv2 파티가 응답을 생성하기 전에 자신의 비밀 키를 변경할 수 있게 했으므로, 그 응답은 책임 있는 관리자가 아직 채택하지 않은 값으로 인증될 수 있었다.
  • 응답의 부재는 요청이 도달하지 않았거나 변경이 성공했고 응답만 손실되었음을 의미할 수 있었다. 비밀 값을 읽어 들이는 것으로 둘을 판단할 수 없었다.
  • 이 프로토콜은 식별 가능한 공개 마커를 사용했고, 전환 해결까지 관리자가 이전 및 새 후보 비밀 키를 재부팅 이후에도 유지할 것을 요구했다.

확인 응답은 커밋 경계를 넘었다

RFC 1446에서 어려운 순간은 무작위 비밀 키의 생성이 아니었다. 그것은 두 기계가 비밀 키가 바뀌었다는 사실을 알게 되는 순서였다.

기존 SNMPv2 파티의 경우, 책임 있는 관리 스테이션이 새 값을 생성하여 보호된setRequest를 보냈다. 수신자는 요청을 처리하고, 응답을 구성하여 반환했다. 관리자는 그 응답을 받은 후에야 자신의 로컬 데이터베이스를 갱신했다. 일반적인 경로에서는 이 이벤트들이 하나의 작업처럼 보였다. 그러나 와이어 상에서는 신뢰할 수 없는 전송으로 분리된 별개의 커밋이었다.

자기 자신의 키를 변경하는 경우가 이 간극을 드러냈다. 파티가 자신의 개인 인증 값을 변경하면, 목적지는 응답을 생성하기 전에 자신의 데이터베이스를 변경했다. 따라서 그 응답은 새 비밀 키로 구성되었다. 관리자는 아직 그 값을 수락하지 않은 상태였다. 이 트랜잭션을 특별히 다루지 않으면, 관리자는 올바른 응답을 받고도 인증되지 않은 것으로 거부할 수 있었다.

유효한 설정, 로컬 커밋, 응답 생성, 응답 전달, 응답 수락은 서로 다른 다섯 가지 사실이었다. 이 사양은 그 순서를 “성공”이라는 단어 뒤에 숨기지 않았다.

침묵에는 서로 양립할 수 없는 두 가지 의미가 있었다

응답이 도착하지 않을 때 RFC 1446은 두 가지 원인을 명시했다. 요청이 목적지에 도달하지 않았을 수 있다. 또는 요청이 도착하여 비밀 키를 변경하고 응답을 생성했는데, 그 응답이 반환 경로에서 손실되었을 수 있다.

이 두 경로는 반대 상태를 남겼다. 첫 번째 경우 양쪽 모두 이전 값을 사용하고 있었다. 두 번째 경우 에이전트는 새 값을 사용하는 반면 관리자는 여전히 이전 값이 관계를 지배한다고 믿었다. 무턱대고 재시도하는 것은 이 구분을 지울 수 없었다. 이전 값으로 인증된 재시도는 첫 번째 명령이 성공했기 때문에 정확하게 실패할 수도 있었다.

개인 상태를 단순히 조회할 수는 없었다. 비밀 값은 읽을 수 없었다. 이 특성은 비밀 값을 노출로부터 보호했지만 가장 명백한 조정 방법을 제거했다. 보안이 제어 기록을 의도적으로 불투명하게 만들었으므로, 운영은 이제 별도의 관찰 가능한 증인을 필요로 했다.

RFC 편집기 기록은 이 문서를 Historic으로 분류한다. 이 상태는 중요하다. 이 메커니즘은 1993년 설계의 기록이며, 그 알고리즘을 배포하라는 현재의 권고가 아니다. 이 문서가 기술한 분열 상태 문제는 시퀀싱과 증거에서 비롯된 것이므로 분석적으로 여전히 유용하다.

공개 값이 비공개 변경을 목격했다

RFC 1446은 동일한 트랜잭션에서 대응하는 공개 필드를 식별 가능한 새로운 값으로 변경할 것을 제안했다. 인증 비밀 키 변경의 경우 관리자는 공개 인증 값을 변경했고, 프라이버시 비밀 키 변경의 경우 공개 프라이버시 값을 변경했다. 응답이 사라지면 관리자는 공개 필드를 읽고 마커가 도착했는지 물어볼 수 있었다.

파티 MIB는 파티 클록 및 수명과 함께 이러한 서로 다른 공개·비공개 필드를 제공했다. 공개 마커는 비밀 키를 노출하지 않았다. 그것은 트랜잭션 증거였다. 보이지 않는 상태 변경이 적용되었는지 보여주기 위해 설계된, 가시적 값이었다.

이 증거에도 경계가 있었다. 일치하는 마커는 목적지가 변경을 처리했다는 결론을 뒷받침했다. 그러나 관리자가 자신의 데이터베이스를 갱신했는지, 이후 인증된 요청이 작동했는지, 그 값이 크래시 이후에 살아남았는지, 의도된 네트워크 작업이 이어졌는지는 증명하지 않았다. 이들에는 각자의 관찰이 필요했다.

이 설계는 흔한 자동화 오류, 즉 응답을 변경의 유일한 증명으로 취급하는 오류를 예상했다. 여기서는 응답 자체가 손실되거나, 자신이 확인하려던 키의 채택을 확인하려는 응답이 바로 그 키로 도착할 수 있었다. 마커는 독립적인 읽기 경로를 만들었다.

관리자는 두 가지 가능한 미래를 짊어졌다

전송과 확인 사이에서 RFC 1446은 관리 스테이션이 이전 비밀 키와 새 비밀 키를 모두 유지할 것을 요구했다. 그 지연이 네트워크 장애에서 비롯될 수 있고 연장될 수 있음을 경고했다. 스테이션은 재부팅 후에도 두 값을 유지할 준비를 해야 했다.

이 지시는 일시적 재시도 문제를 지속 상태 의무로 바꾸었다. 컨트롤러는 자신이 선호하는 미래만 영속화할 수 없었다. 해결되지 않은 분기, 즉 요청이 손실된 경우의 이전 값과 응답만 손실된 경우의 새 값을 영속화해야 했다. 재시작 시 어느 한 후보를 지우면 복구가 불가능해질 수 있었다.

크래시 복구도 같은 규율을 확장했다. 문서의 모델에서 파티 신원, 인증 클록, 개인 인증 및 프라이버시 키는 비휘발성이며 손상되지 않는 표현을 요구했다. 클록은 우연한 부수 정보가 아니었다. 클록의 단조성은 인증된 메시지가 최근 것인지 판단하는 데 도움을 주었으므로, 클록의 손실이나 되돌림은 보안과 관리 가능성을 모두 깨뜨릴 수 있었다.

이 프로토콜은 중단 이후 에이전트의 클록이 더 이상 안전하게 진행할 수 없을 때 책임 있는 관리자의 개입까지 기술했다. 프로세스의 재부팅은 관계의 복원과 동등하지 않았다. 복구란 양쪽 끝에서 신원, 시간, 비밀 키, 수명을 조정하는 것이었다.

인증은 세계의 순서를 정하지 않았다

RFC 1446은 출처와 무결성을 위해 공유 비밀 키 다이제스트를 사용하고, 과도한 지연과 재전송 공격을 제한하기 위해 파티별 클록과 수명을 사용했다. 또한 이 메커니즘이 하지 않는 일도 밝혔다. 시간 제약은 삭제나 차단을 막지 못했다. 인증된 응답의 부재는 에이전트나 네트워크 장애의 결정적 증거가 아니었다. 인증 실패 트랩조차 클록 오차나 불일치하는 비밀 키로 인해 손실되거나 억제될 수 있었다.

상태 변경 메시지에는 또 다른 한계가 있었다. SNMP는 일반적인 메시지 순서를 강제하지 않았고, 메시지는 손실되거나 재정렬될 수 있었다. 이 메모는 관리자에게 이전 상태 변경에 대한 긍정적 확인을 받거나 그 메시지가 만료될 때까지 후속 상태 변경을 지연하도록 권고했다.SNMPv2 MIB의 별개의snmpSetSerialNo객체는 설정 처리를 직렬화하는 데 도움을 줄 수 있었다. 그러나 특정 개인 값이 영속했는지나 의도된 운영 효과가 발생했는지는 증명하지 못했다.

관리 모델은 이 교환들을 파티, 컨텍스트 및 접근 정책 안에 배치했다. 이것도 또 하나의 필요한 분리였다. 다이제스트는 공유 비밀 키 모델 하에서 메시지 출처와 무결성을 뒷받침할 수 있었다. 그러나 그것만으로 요청된 모든 객체가 승인되었는지, 변경이 영속적이었는지, 네트워크가 이후 의도대로 동작했는지를 결정하지 못했다.

증인은 파티 모델보다 오래 살아남았다

파티 기반 보안 프레임워크가 SNMP 보안의 최종 형태가 되지는 못했다. 실험적인RFC 1910은 사용자, 에이전트 신원, 부팅 카운트, 엔진 시간, 시간 창, 명시적 접근 정책 쪽으로 이동했다.RFC 2574와 이어서RFC 3414는 SNMPv3를 위한 사용자 기반 보안 모델을 정의했다.

이후 설계는 신원과 키 유도를 바꾸었지만 확인 문제는 그대로 드러낸 채 남겨두었다. 그KeyChange객체는 읽을 수 없는 키를 단방향 작업으로 갱신했다. 스핀 락이 동시 변경을 보호했다. 쓰기 가능한usmUserPublic값이 무작위 마커를 전달했다. 성공 응답이 도착하면 새 키가 활성 상태였다. 응답이 도착하지 않으면 관리자는 공개 마커를 읽어 손실된 요청과 손실된 응답을 구분했다.

이 연속성은 신중하게 읽어야 한다. 이것이 RFC 1446의 MD5와 DES 선택이 현재 유효하다는 뜻이 아니다. 신뢰할 수 없는 관리 채널을 통한 비밀 키 교체가 1993년의 특정 알고리즘과 무관한 상태 조정 문제를 만든다는 것을 보여준다.

출처