Resumen

  • RFC 10020 define por separado el grupo CoAP, el grupo de aplicación y el grupo de seguridad. Sus relaciones pueden ser de muchos a muchos, de uno a muchos, de muchos a uno o de uno a uno: la implantación decide cómo se corresponden.
  • Group OSCORE autentica al integrante concreto del grupo de seguridad que originó un mensaje protegido. El propio RFC advierte que esa pertenencia no debe usarse como sustituto del control de acceso a recursos de la aplicación.

El sistema de climatización ya no pertenecía al área que iba a recibir la orden, pero nadie había retirado todas sus membresías. Continuaba escuchando el mismo grupo multicast. Su recurso respondía al mismo camino. Conservaba material válido de Group OSCORE. Cuando llegó la orden, la firma era correcta y el remitente estaba identificado.

La seguridad había funcionado. La gobernanza de los padrones, no.

Esa diferencia está escrita en la arquitectura de RFC 10020, la especificación de la IETF publicada como Standards Track en julio de 2026 para comunicaciones de grupo con CoAP. El documento sustituye RFC 7390, actualiza RFC 7252 y RFC 7641, y establece UDP/IP multicast como transporte predeterminado de solicitudes grupales. Su decisión institucional más útil es no asignar todas las facultades a la palabra «grupo».

Tres listas que responden preguntas distintas

Un grupo CoAP reúne endpoints configurados para recibir mensajes enviados a una dirección IP multicast y un puerto UDP asociados. Es una pertenencia de red: indica quién escucha en ese destino. La URI puede utilizar la dirección o un nombre de grupo y señalar otro puerto si no emplea el 5683 predeterminado.

Un grupo de aplicación reúne endpoints servidores que comparten funciones mediante recursos CoAP. Es una pertenencia funcional: indica qué servidores deberían interpretar el método y el camino como una operación de esa aplicación. El grupo puede aparecer en el camino de la URI o inferirse del mensaje y del contexto.

Un grupo de seguridad reúne endpoints que guardan material compartido para proteger y verificar mensajes. Es una pertenencia criptográfica: indica quién puede participar válidamente bajo ese contexto. Un equipo puede pertenecer a más de un grupo de seguridad.

RFC 10020 no obliga a que los conjuntos coincidan. Permite relaciones muchos-a-muchos, uno-a-muchos, muchos-a-uno y uno-a-uno. Varias aplicaciones pueden compartir un grupo de seguridad para reducir almacenamiento y rotaciones. Una sola aplicación puede emplear varios grupos cuando sus clientes admiten algoritmos diferentes. Las entidades configuradoras deciden esas asociaciones según la instalación.

La lista de emisores tampoco se obtiene de los receptores. El modelo es Any-Source Multicast: quien envía puede pertenecer o no al grupo IP de destino y no hay una cantidad intrínseca máxima de fuentes. Convertir el listado de escuchas en listado de mandos autorizados es una inferencia ajena al transporte.

Una firma válida no decide el uso del recurso

Para las comunicaciones protegidas, RFC 10020 adopta Group OSCORE, definido en RFC 10021. Se apoya en OSCORE, descrito en RFC 8613, y en estructuras COSE como las de RFC 9052. El modo de grupo usa la firma privada del emisor; el modo por pares deriva claves para los intercambios individuales.

La consecuencia es importante y limitada. El receptor puede comprobar que un endpoint específico e identificable, miembro del grupo OSCORE, originó el mensaje. El material simétrico compartido solo daría autenticación del conjunto; Group OSCORE añade autenticación de origen. Aun así, no autentica la dirección IP ni el puerto fuente desde el que llegó el paquete.

Tampoco concede acceso indiscriminado a la aplicación. RFC 10020 dice de forma expresa que distintos grupos de seguridad no deberían representar políticas de acceso dentro de un grupo de aplicación. La membresía permite intercambiar mensajes protegidos y autenticar a sus integrantes. La autorización para utilizar recursos pertenece a otro dominio de seguridad y debe aplicarse con propiedades del recurso o credenciales dedicadas.

Por tanto, la verificación criptográfica contesta «quién envió esto con este conjunto de claves». La autorización contesta «si esa identidad puede ejecutar este método, sobre este camino, para este ámbito y en este momento». Hacer que la primera respuesta ocupe el lugar de la segunda convierte la distribución de claves en administración de privilegios por accidente.

El marco ACE de RFC 9200 puede intervenir cuando un endpoint solicita permiso al Group Manager para entrar en un grupo. Pero recibir el material de protección no implica automáticamente derecho a cada recurso que usa ese material. La admisión al grupo, la autenticidad del mensaje y la autorización de la operación requieren comprobantes distintos.

La desalineación puede nacer en la fábrica

RFC 10020 utiliza «entidad configuradora» porque la misma organización no tiene por qué crear las tres agrupaciones. Puede hacerlo una aplicación, una persona usuaria, un desarrollador, un servicio en la nube o una herramienta de puesta en marcha. La configuración ocurre al crear el software, en fábrica, en un distribuidor, durante el primer despliegue o en una reconfiguración posterior.

El RFC observa que distintos actores pueden trabajar con coordinación mínima o inexistente. Una credencial instalada en fábrica, una dirección elegida por el integrador y una cohorte de recursos definida desde la nube pueden evolucionar en calendarios distintos. Quitar un dispositivo de un plano no lo quita de los demás.

El mantenimiento incluye altas y bajas, cambio de material de seguridad, nueva dirección multicast o puerto UDP, cambio de URI, renombrado de grupos de aplicación, división y fusión. La frase «se eliminó del grupo» carece de valor de auditoría si no identifica cuál, en qué época y quién comprobó las consecuencias sobre los otros dos.

Las claves añaden una dimensión temporal. Los grupos OSCORE necesitan rekeying para renovar y revocar material. Cuando la rotación tarda y hay muchas altas y bajas, el Group Manager puede agrupar cambios con cautela. Esa eficiencia tiene un precio: hasta completar la rotación, un miembro que salió puede conservar acceso con el material anterior; un integrante nuevo puede, según la política, acceder a comunicaciones previas.

Un estado que dice solo «miembro del grupo de seguridad» está incompleto. Debe indicar la época de claves, si la salida ya produjo revocación efectiva y qué integrantes terminaron la transición.

El silencio no equivale a «no ejecutado»

La comunicación grupal altera las pruebas que puede obtener el cliente. Una solicitud viaja por multicast y cada servidor responde normalmente por unicast. Para contener congestión e implosión de respuestas, la solicitud es Non-confirmable y cada servidor distribuye su respuesta dentro de un intervalo aleatorio Leisure. También siguen rigiendo NSTART y PROBING_RATE.

Además, un servidor puede suprimir respuestas. RFC 10020 recomienda suprimirlas ante errores o cuando no haya nada útil que devolver, salvo que la política de esa aplicación exija una respuesta. La opción No-Response solo debería modificar el criterio en recursos para los que ese comportamiento se haya decidido de antemano.

La ausencia de respuesta admite muchas explicaciones: solicitud perdida, recurso no aplicable, rechazo silenciado, retraso, respuesta perdida o ejecución sin devolución. Repetir con un Message ID nuevo puede provocar que servidores que ya procesaron la primera copia procesen la segunda. El registro de respuestas no es, por sí solo, un registro de efectos.

La tesis de Heng Lu sobre la primacía del código en ejecución fija aquí el método. La configuración muestra el diseño de los tres padrones; la observación muestra el comportamiento de la instalación. Gobernar exige unir ambos sin presentar el diseño como hecho ni el resultado parcial como censo completo.

Un recibo de autorización de tres padrones

Un recibo de autorización de tres padrones conservaría la cadena de decisión. La primera parte identifica el grupo CoAP: dirección o nombre multicast, puerto UDP, ámbito, endpoints a la escucha, fuente de descubrimiento y época de configuración. El remitente aparece en un campo separado porque Any-Source Multicast no lo obliga a ser receptor.

La segunda parte identifica el grupo de aplicación y la autorización exacta: camino URI, método, clase de carga útil, cohorte esperada, versión de política, credencial o propiedad evaluada, resultado y caducidad. Un resultado «firma válida» nunca rellena el campo de permiso.

La tercera parte identifica el grupo de seguridad: Group Manager, identificador, algoritmos, identidad autenticada, época OSCORE, constancia de alta, estado de baja, última rotación y su finalización. La autenticación del emisor se registra aparte de la validación de su dirección de red. Cuando sea relevante, la opción Echo de RFC 9175 ayuda a comprobar que el solicitante autenticado es alcanzable en la dirección declarada.

El resultado enumera receptores previstos, efectos observados, política de supresión, intervalo Leisure, respuestas recibidas, pérdidas conocidas y repeticiones. El silencio se conserva como incertidumbre. Cada cambio de membresía enlaza a la entidad que lo realizó y a la reconciliación posterior de los otros padrones.

Este recibo es una propuesta editorial de gobernanza de Daniel Kade, no un requisito de RFC 10020. Su función es impedir que dirección correcta, recurso existente y clave vigente se conviertan en un único estado verde que nadie puede explicar.

NoSec multiplica tanto respuestas como riesgos

RFC 10020 desaconseja con fuerza el modo NoSec y lo limita a pasos excepcionales, estrechos y bien comprendidos, como cierta detección inicial. Un servidor grupal en NoSec no debe estar accesible desde la Internet pública. Con una fuente falsificada, una petición multicast puede hacer que varios servidores respondan a una víctima.

Group OSCORE reduce esa posibilidad al autenticar al remitente y proteger camino y consulta. La limitación de respuestas y Echo aportan más mitigación. No eliminan a un integrante malicioso, a un atacante situado en ruta ni el volumen que los receptores legítimos todavía pueden producir.

El espejo de políticas de Heng Lu propone mostrar el reparto real del control. Dirección, recurso, grupo de claves, autorización, supresión y telemetría pertenecen a superficies diferentes. La etiqueta «grupo seguro» es demasiado amplia para asignar responsabilidad.

La disciplina de realidad que fundamenta BTW Media permite confiar mejor, no menos. La dirección prueba un destino configurado. Group OSCORE prueba una identidad en una época. La autorización prueba una facultad sobre el recurso. La evidencia operativa prueba lo ocurrido. Mantener sus nombres separados es una condición de control.

Fuentes