요약

  • RFC 10020은 CoAP 그룹, 애플리케이션 그룹, 보안 그룹을 서로 다른 집합으로 정의한다. 이들 관계는 다대다, 일대다, 다대일 또는 일대일이 될 수 있으며, 정렬 방식은 프로토콜이 아니라 배포 환경이 결정한다.
  • Group OSCORE는 보호된 요청을 보낸 특정 보안 그룹 멤버를 인증할 수 있다. 이 RFC는 그 멤버십을 애플리케이션 리소스 사용 권한과 명시적으로 분리한다. 따라서 유용한 통제 기록은 세 개의 명부와 키 에포크, 그리고 별도의 권한 부여 결정을 결합해야 한다.

요청은 유효하게 보호되어 있었고 발신자도 식별 가능했다. 의도된 모든 서버는 그 메시지가 OSCORE 그룹 멤버로부터 온 것임을 검증할 수 있었다. 그러나 한 수신 장치는 그 명령이 통제해야 했던 운영 집단에 더 이상 속하지 않았다. 그 장치는 여전히 멀티캐스트 주소를 수신 대기 중이었고, 여전히 최신 그룹 자료를 보유하고 있었으며, 여전히 일치하는 리소스를 노출하고 있었다.

암호학적 판정에는 그 비즈니스 불일치를 표현할 방법이 없었다. 메시지는 진짜였다. 멤버십도 실재했다. 권한만이 흔들려 있었다.

바로 이 구분이RFC 10020, 즉 2026년 7월의 Constrained Application Protocol 그룹 통신 표준 트랙 사양의 핵심에 놓여 있다. 이 문서는 RFC 7390을 폐기하고RFC 7252와RFC 7641을 갱신하며, UDP/IP 멀티캐스트를 CoAP 그룹 요청의 기본 전송 방식으로 지정한다. 거버넌스 관점에서 더 중요한 것은, 이 문서가 ‘그 그룹’을 단일한 사실로 기술하기를 거부한다는 점이다.

세 가지 멤버십, 세 가지 질문

CoAP 그룹은 연관된 IP 멀티캐스트 주소와 UDP 포트로 전송되는 그룹 메시지를 수신하도록 구성된 엔드포인트 집합이다. 그 질문은 네트워크 도달성에 관한 것이다: 어떤 엔드포인트가 여기서 수신 대기하는가? 그룹 URI에는 멀티캐스트 주소나 그룹 호스트명이 들어갈 수 있고, 필요하다면 CoAP 기본 UDP 포트 5683 이외의 포트도 포함될 수 있다.

애플리케이션 그룹은 CoAP 리소스를 통해 애플리케이션 수준 기능을 공유하는 서버 엔드포인트 집합이다. 그 질문은 기능에 관한 것이다: 어떤 서버들이 이 요청이 가리키는 리소스 동작을 구현하는가? 애플리케이션 그룹은 URI 경로에 명시되거나 요청 및 배포 맥락으로부터 추론될 수 있다.

보안 그룹은 메시지를 보호하고 검증하기 위한 공유 보안 자료를 보유한 엔드포인트들을 담는다. 그 질문은 암호학적 참여에 관한 것이다: 어떤 엔드포인트가 이 보안 컨텍스트 하에서 유효하게 트래픽을 주고받거나 처리할 수 있는가? 하나의 엔드포인트는 여러 그러한 그룹에 속할 수 있다.

이 집합들은 서로를 상속하지 않는다. RFC 10020은 그 사이의 모든 카디널리티를 허용한다: 다대다, 일대다, 다대일, 일대일. 여러 애플리케이션 그룹이 하나의 보안 그룹을 공유해 저장소와 갱신 비용을 줄일 수 있다. 하나의 애플리케이션 그룹이 클라이언트가 서로 다른 알고리즘 스위트를 지원하기 때문에 여러 보안 그룹을 사용할 수도 있다. 매핑은 배포에 맞춰 구성 주체가 설정한다.

발신 측도 별개다. RFC 10020은 UDP/IP 멀티캐스트를 Any-Source Multicast로 한정한다. 발신자는 대상 멀티캐스트 그룹의 멤버일 수도, 아닐 수도 있으며, 프로토콜은 발신자 수를 제한하지 않는다. 수신 명부를 발신 권한 명부로 표시하는 대시보드는 이미 서로 다른 두 사실을 하나로 합쳐버린 것이다.

인증은 권한 부여 이전에서 멈춘다

보안된 CoAP 그룹 통신은RFC 10021에서 규정되고RFC 8613의 OSCORE를 기반으로 만들어진 Group OSCORE를 사용한다. 애플리케이션 계층에서 메시지는RFC 9052를 비롯한 문서에서 정의된 COSE 프레임워크를 통해 기밀성과 무결성 보호를 받는다. 그룹 모드는 발신자 서명을 사용하고, pairwise 모드는 일대일 교환용 키를 파생한다.

그 결과로 얻어지는 보장은 정확히 정의된다. 수신자는 보호된 메시지가 OSCORE 그룹에 속한 특정, 식별된 엔드포인트에서 시작되었음을 검증할 수 있다. 공유 대칭 자료만으로는 그룹 수준 인증만 제공되지만, Group OSCORE는 발신자 인증을 추가한다. 다만 그것은 패킷의 출발 IP 주소나 UDP 포트까지는 인증하지 않는다.

또한 그것은 애플리케이션 그룹에 대한 일반적 권한을 부여하지도 않는다. RFC 10020은 보안 그룹이 하나의 애플리케이션 그룹 내에서 서로 다른 접근 정책을 표현하도록 설계되지 않았음을 명시한다. 멤버십은 보호된 메시지를 주고받고 그룹 멤버를 인증하는 능력을 부여할 뿐이다. 리소스 사용 권한은 별도의 보안 도메인에 속하며, 리소스 속성이나 전용 접근 제어 자격 증명으로 강제되어야 한다.

이것이 결정적인 경계다. ‘서명 검증됨’은 보안 에포크 안에서 누가 요청을 보냈는지에 답한다. ‘리소스 승인됨’은 그 발신자가 지금, 이 애플리케이션 집단에 대해, 이 경로에서 이 메서드를 호출할 수 있는지에 답한다. 두 번째 결정을 첫 번째로 대체하면 보안 전송 그룹이 우연히 만들어진 권한 체계가 되어버린다.

RFC 9200의 ACE 프레임워크는 엔드포인트가 Group Manager를 통해 보안 그룹에 가입할 때 권한 부여를 지원할 수 있다. 그러나 그룹 자료를 얻을 권한이 자동으로 그것이 보호하는 모든 리소스에 대한 권한과 동일하지는 않다. 가입 권한, 메시지 진정성, 리소스 권한은 각각 별도의 근거를 필요로 한다.

멤버십 드리프트는 배포 이전에 시작된다

RFC 10020은 ‘configuring 주체(구성 주체)’라는 중립적 용어를 사용하는데, 세 그룹을 모두 만드는 주체가 단일 운영자일 필요가 없기 때문이다. 애플리케이션, 사용자, 개발자, 클라우드 서비스, 셋업 도구 또는 다른 주체가 그룹을 만들 수 있다. 구성은 소프트웨어 제작 중, 공장에서, 판매 시점에서, 초기 설치 중, 또는 이후 재구성 시에 이루어질 수 있다.

이 문서는 서로 다른 구성 주체들이 최소한의 조율만으로, 혹은 조율 없이, 그 단계들을 수행할 수 있음을 지적한다. 이 관찰은 깔끔한 프로토콜 다이어그램을 수명 주기 문제로 바꾼다. 공장이 보안 신원을 적재하고, 설치자가 멀티캐스트 주소를 지정하고, 애플리케이션 서비스가 리소스 집단을 정의하며, 이후 유지보수 팀이 셋 중 하나만 바꿀 수 있다.

그룹 유지관리는 그에 맞춰 넓다. 멤버의 가입과 탈퇴, 보안 자료 교체, IP 멀티캐스트 주소나 UDP 포트 변경, 그룹 URI 변경, 애플리케이션 그룹 이름 변경, 그룹 분할과 병합이 모두 포함된다. ‘장치를 그룹에서 제거함’이라고만 적힌 변경 티켓은 불완전하다: 어떤 그룹에서, 어떤 통제 지점에서, 그리고 나머지 둘에 어떤 영향을 미치는가?

보안 자료에는 고유한 시간 경계가 있다. OSCORE 그룹은 폐기와 갱신을 위해 재키잉(rekeying)을 요구한다. 교체가 빈번하고 재키잉이 느릴 때, 운영자는 가입·탈퇴마다 재키잉하기보다 변경을 신중히 묶어 처리할 수 있다. 이 트레이드오프는 명시적이다. 다음 재키잉까지 최근에 탈퇴한 엔드포인트는 기존 자료 하의 통신에 접근할 수 있으며, 정책에 따라 신규 멤버는 이전에 보호된 트래픽에 접근할 수 있다.

따라서 ‘멤버’에는 에포크가 필요하다. 키 버전과 재키잉 완료 상태가 없는 보안 명부는 탈퇴한 장치와 현재 신뢰되는 장치를 마치 권한이 동일한 것처럼 보고할 수 있다.

침묵은 부정적 수신 확인이 아니다

그룹 통신은 관찰자가 응답으로부터 추론할 수 있는 것도 바꾼다. 클라이언트는 멀티캐스트로 요청을 하나 보내고, 개별 서버는 보통 유니캐스트로 응답을 돌려보낸다. 혼잡과 응답 폭주를 피하기 위해 그룹 요청은 Non-confirmable이며, 서버는 무작위 Leisure 구간만큼 응답을 지연한다. NSTART와 PROBING_RATE 같은 혼잡 제어는 여전히 중요하다.

서버는 응답을 억제할 수 있다. RFC 10020은 애플리케이션 정책이 요구하지 않는 한, 오류나 기여할 것이 없는 응답은 억제해야 한다고 말한다. 클라이언트는 No-Response 옵션을 사용해 억제에 영향을 줄 수 있으되, 그 선택이 해당 리소스에 적절하다고 이미 판단된 경우에만 그렇다.

결과적으로 응답이 없다는 것이 실행되지 않았음을 증명하지는 않는다. 요청이 유실되었거나, 수신자가 애플리케이션 그룹과 일치하지 않거나, 리소스가 메서드를 거부했거나, 정책이 오류를 억제했거나, 응답이 지연되었거나, 응답이 유실되었음을 뜻할 수 있다. 요청을 반복하면 첫 사본을 처리한 서버가 새 메시지를 다시 처리할 수도 있다. 수신된 응답만으로 구축된 감사는 수신자 집합을 신뢰 있게 재구성할 수 없다.

바로 여기서루헝(Lu Heng)의 러닝코드 원칙이 중요해진다. 선언된 멤버십은 의도된 경계를 기술한다. 관찰된 수신자 행동은 배포된 시스템이 실제로 한 일을 보여준다. 어느 쪽도 다른 쪽을 대체하지 않는다. 통제 시스템에는 매핑과 실행 증거가 함께 필요하다.

세 명부 권한 부여 접수증

세 명부 권한 부여 접수증(three-roster authorization receipt)은 프로토콜이 하나의 보편적 그룹을 만들었다고 가장하지 않으면서도 그 사슬을 보존할 수 있다. 첫 번째 절은 CoAP 그룹을 식별한다: 멀티캐스트 주소 또는 호스트명, UDP 포트, 주소 범위, 수신 대기 중인 엔드포인트, 디스커버리 출처, 구성 에포크. Any-Source Multicast는 발신자가 대상 그룹을 수신할 필요가 없으므로, 발신 엔드포인트는 별도로 기록한다.

두 번째 절은 애플리케이션 그룹과 정확한 리소스 결정을 식별한다. URI 경로, 메서드, 관련 페이로드 클래스, 그 기능을 구현할 것으로 예상되는 서버 집단, 정책 버전, 평가된 권한 자격 증명 또는 리소스 속성, 결정 결과, 만료를 기록한다. ‘패킷을 검증할 수 있음’은 결코 권한 필드로 받아들여지지 않는다.

세 번째 절은 보안 그룹을 식별한다: Group Manager, 그룹 식별자, 알고리즘 스위트, 인증된 발신자 신원, OSCORE 키 에포크, 가입 근거, 탈퇴 상태, 마지막 재키잉, 그리고 모든 필수 멤버에서 재키잉이 완료되었는지 여부. 발신자 인증과 네트워크 주소 검증은 분리된다. 도달성 검증이 중요한 곳에서는RFC 9175의 Echo 옵션이 인증된 요청자가 주장하는 주소에서 실제 도달 가능함을 확인하는 데 도움될 수 있다.

결과 절은 의도된 수신자, 관찰된 처리 결과, 응답 억제 정책, Leisure 창, 수신된 응답, 알려진 유실, 반복, 부수 효과를 기록한다. 침묵은 ‘실행 안 됨’으로 전환되지 않고 미해결 관찰로 저장된다. 수명 주기 절은 각 명부 변경을 그것을 수행한 구성 주체와 나머지 두 명부를 점검한 대조 작업에 연결한다.

이 접수증은 다니엘 카데(Daniel Kade)의 편집적 거버넌스 제안이며, RFC 10020의 요구 사항이 아니다. 그 목적은 유효한 주소, 일치하는 리소스, 유효한 보안 자료가 하나의 오해를 부르는 녹색 상태로 압축되는 일을 막는 것이다.

보안된 그룹 트래픽에도 증폭 경계가 있다

NoSec 하의 비보안 그룹 통신은 강력히 권고되지 않는다. RFC 10020은 예외를 보안을 달성할 수 없거나 요구하지 않는 좁고 잘 이해된 단계, 예컨대 일부 초기 디스커버리 사례로만 한정하고, NoSec 그룹 서버에 대한 공개 인터넷 접근을 금지한다. 그 이유는 구조적이다: 하나의 멀티캐스트 요청에서 위조된 출발 주소는 여러 서버의 응답을 피해자에게 향하게 할 수 있다.

Group OSCORE는 발신자를 인증하고 경로와 쿼리를 보호함으로써 그 공격 표면을 좁히며, 응답 한도와 Echo 옵션이 추가 방어를 더한다. 그래도 모든 위협을 없애지는 못한다. 경로상의 주체는 여전히 주소 관련 문제를 만들 수 있고, 인증된 그룹 멤버도 악의적일 수 있으며, 허용되는 응답의 수와 크기가 여전히 증폭 영향을 결정한다.

루헝의 정책 거울 논증은 더 넓은 시험 기준을 제공한다: 인터페이스는 안심시키는 추상화를 보여주는 대신 실제 권한 분포를 드러내야 한다. 여기서 권한은 멀티캐스트 구성, 리소스 배포, Group Manager 정책, 애플리케이션 권한 부여, 응답 동작, 운영 증거로 나뉘어 있다. ‘그룹 정상’ 배지 하나는 책임을 배정할 수 있는 유일한 사실들을 숨긴다.

요점은 그룹 통신을 불신하자는 것이 아니다. 각 보장이 정확히 자신이 증명하는 범위에서만 신뢰받도록 하자는 것이다.BTW Media의 현실 우선 전제가 바로 그 규율을 요구한다: 어떤 제품이 그 전부를 멤버십이라 부르고 싶어도, 도달성, 기능, 신원, 권한, 실행은 각각 별도로 관찰 가능해야 한다.

출처