Resumen

  • La autorización del cliente para modificar una lista no sustituye el permiso del destinatario final. RFC 5360 mantiene ese permiso junto a la lógica de traducción que convertirá una URI objetivo en una o varias URI receptoras.
  • Un HTTP 202 deja la incorporación pendiente. El documento de permiso, la identidad que concede o deniega, la actualización del estado y la coincidencia en una petición posterior son recibos separados.
  • La incorporación de una sola URI por transacción, el 470 Consent Needed, el refresco y Trigger-Consent limitan amplificación y permisos obsoletos. Ninguno demuestra por sí solo entrega correcta, atención humana o revocación efectiva.

La autoridad para editar termina antes del cuerpo ajeno

Un administrador necesita credenciales y una política que le permita manipular la lista. Sin esas protecciones, cualquier atacante podría cambiar la traducción. Pero una cuenta legítima también puede añadir a una persona que no quiere recibir llamadas, mensajes o presencia procedentes de esa dirección colectiva.

RFC 5360 no trata esta situación como una anomalía de autenticación del administrador. Introduce una segunda decisión. El relay debe preguntar al destinatario potencial y guardar el resultado antes de traducir hacia él.

El registro de auditoría debe conservar ambos actos: quién propuso la incorporación y qué regla lo autorizó; quién controlaba la URI final y qué traducción aceptó. Si el sistema solo guarda «added_by=admin», ha eliminado la decisión que protege al receptor.

La separación también evita que una organización confunda propiedad del nombre de grupo con propiedad de las direcciones individuales. El responsable de una lista puede ordenar su configuración sin adquirir consentimiento perpetuo de todos sus miembros.

El relay es el punto donde el permiso se vuelve operativo

La traducción toma una URI objetivo de la petición entrante y produce URI receptoras para las peticiones salientes. Un proxy, B2BUA o híbrido puede desempeñar ese papel.

Por eso el permiso debe residir con la lógica que ejecuta el fan-out. Una nota en el panel de administración no impide que una versión antigua de la configuración siga enviando. Una decisión almacenada en otro servicio no sirve si el relay no la consulta en la versión correcta.

Para una ejecución concreta, hace falta unir identidad del remitente, objetivo, receptor final, documento de permiso, versión de traducción y petición saliente. La existencia de una concesión en una base de datos no prueba esa coincidencia.

La arquitectura cambia la custodia. Un proxy puede conservar relaciones de extremo a extremo; un B2BUA termina y reconstruye. El informe debe nombrar quién transformó la URI, quién aplicó el permiso y quién generó cada salida.

HTTP 202 pertenece a la solicitud de cambio

A pide añadir a B con XCAP. El relay responde 202 y coloca la dirección en pending. B todavía no ha concedido nada. Después llegará un MESSAGE con el documento de permiso, quizá almacenado mientras B está desconectado.

El 202 confirma que el cambio fue aceptado para procesamiento. No confirma lectura, concesión, instalación, envío futuro ni entrega. Confundirlo con consentimiento adelanta varias etapas que todavía pueden fallar.

El paquete Pending Additions permite observar pending, waiting, error, denied y granted. Si B no está disponible y no existe store-and-forward, la petición puede fallar. El cliente necesita ese error para decidir si reintenta.

Guarde la operación inicial, objetivo, receptor, respuesta, estado y cada NOTIFY. Cuando el estado llegue a granted, enlácelo con el hash del documento y la prueba de identidad.

El permiso describe una relación, no una preferencia universal

El documento incluye identidad del remitente, receptor original u objetivo, receptor final y URI para conceder o denegar. El modelo permite comodines en ciertos campos, pero prohíbe que la URI final sea un comodín.

Ese límite importa. Una persona puede aceptar tráfico encaminado desde un grupo concreto sin aceptar toda comunicación de cualquier servicio. Puede aceptar cualquier remitente hacia un objetivo, o exigir un remitente específico según el caso.

La interfaz debe mostrar la misma relación que procesará la máquina. Si la parte humana omite un comodín o nombra un grupo distinto, un clic correcto puede conceder otra cosa.

Conserve bytes, hash, versión, remitente, objetivo, receptor final, capacidades de concesión y denegación, identidad del relay y representación visible. Compare ambas antes de presentarlas.

En cada ejecución posterior, produzca un recibo de coincidencia. El permiso no debe adquirir alcance nuevo porque un alias fue redirigido o una lista cambió silenciosamente.

PUBLISH vacío no significa decisión sin contexto

El destinatario utiliza SIP PUBLISH o HTTP GET hacia una capacidad incluida en el documento. La petición puede tener cuerpo vacío porque la URI ya identifica la acción y el permiso.

El relay debe comprobar que procede del propietario de la URI final. RFC 5360 enumera SIP Identity, P-Asserted-Identity dentro de una red de confianza, Digest con secreto compartido y return routability.

Cada método tiene un alcance diferente. P-Asserted-Identity depende del límite administrativo. Digest prueba posesión de un secreto en su contexto. Una identidad firmada necesita una comparación con el propietario. Return routability demuestra acceso a una capacidad entregada.

No reduzca todo a un bit de autenticación. Registre método, principal, URI validada, dominio de confianza, contexto de credencial, hash de capacidad, política y resultado.

Una petición correctamente autenticada para otra identidad debe ser rechazada; credencial válida no equivale a consentimiento de la persona prevista.

Return routability es prueba de recepción acotada

El mecanismo crea una URI impredecible y la entrega en la solicitud de permiso. Quien la usa demuestra que obtuvo esa capacidad por algún camino.

RFC 5360 exige que el MESSAGE vaya a SIPS, que las URI de grant y deny sean seguras y que su componente aleatorio tenga al menos 32 bits. Estas condiciones reducen la posibilidad de adivinar o interceptar.

Pero no prueban identidad duradera ni comprensión humana. Un store-and-forward comprometido, un historial expuesto o una capacidad reenviada pueden separar posesión de la persona esperada.

Registre calidad de generación, hash, ruta protegida, momento, tratamiento de reuso y principal operativo. Evite guardar el secreto reutilizable en logs.

Si el relay migra a SIP Identity, la política de aceptación cambia. Los recibos antiguos deben mantener su método original en lugar de presentarse después como pruebas equivalentes.

Una URI por transacción compra un solo envío de permiso

Sin límite, un atacante podría añadir miles de direcciones con una petición pequeña y hacer que el relay emita miles de MESSAGE. El propio sistema de consentimiento se convertiría en amplificador.

La respuesta de RFC 5360 es crediticia: una transacción XCAP añade como máximo una URI, y un REGISTER dentro del marco añade como máximo un contacto. El ancho de banda de entrada se aproxima al trabajo saliente.

No es un límite total. Muchas transacciones, muchas cuentas o una campaña lenta aún pueden causar carga. El control elimina la multiplicación instantánea, no toda conducta maliciosa.

Mida actor, objetivo, receptor, bytes, frecuencia, respuesta 409 o 403 y reintentos. Añada presupuestos agregados por cuenta, objetivo y destino.

También verifique que el almacenamiento offline no vuelva a enviar repetidamente la misma solicitud y cree una amplificación diferida.

Con una URI sin permiso, 470 detiene toda la lista

Las listas contenidas en la propia petición eligen destinatarios en el momento del intento. El relay mantiene un conjunto de URI que ya concedieron permiso, un superconjunto de cualquier lista particular.

Si falta permiso para una sola URI, no debe realizar la traducción. Debe responder preferentemente 470 Consent Needed y usar Permission-Missing para indicar cuáles faltan.

La regla evita un fan-out parcial. Enviar a los autorizados y fallar para el resto ya produjo efectos que una respuesta global puede ocultar. También puede revelar composición mediante diferencias observables.

Guarde el hash de la lista, la versión del conjunto de permisos, el resultado por URI y la respuesta. Proteja la lista de ausentes como dato sensible.

La instantánea de errata muestra un informe técnico Reported sobre el uso de corchetes angulares cuando la puntuación de la URI hace ambiguo Permission-Missing. No es una corrección verificada ni debe incorporarse en silencio.

Revocar requiere llegar al mismo estado que autorizó

El receptor puede usar la capacidad deny guardada. Si la pierde, una petición traducida posterior puede incluir Trigger-Consent con el objetivo. Así solicita un documento nuevo y después niega.

La recuperación revela una ventana. Querer revocar no ha eliminado todavía el permiso; incluso puede ser necesario recibir otra petición no deseada para obtener el trigger.

El relay debe correlacionar el trigger con receptor y objetivo. Un 200 al primer PUBLISH solo inicia la obtención del documento. La revocación termina cuando una denegación autenticada cambia la lógica activa.

Registre intención, trigger, documento, denegación, versión, corte y última salida con la concesión anterior. Defina qué ocurre con peticiones concurrentes.

Además, eliminar un miembro o expirar un contacto debería borrar el permiso. El refresco periódico es recomendado, pero el intervalo pertenece a la aplicación. La ausencia de revocación explícita no crea vigencia infinita.

El REGISTER de un tercero es otra traducción

El registro normal suele unir a la misma entidad que configura el contacto y recibirá tráfico. Un registro de tercero rompe esa premisa: alguien puede enlazar su AoR con el contacto de una víctima.

El 202 para ese REGISTER coloca la dirección en pending. El registrar pide permiso al contacto y notifica después el estado. La configuración aceptada no es todavía autoridad para reenviar.

El análisis debe identificar AoR, contacto, registrante, autenticación, relación de conexión, carácter de tercero, permiso y decisión final.

RFC 5360 no exige la misma ceremonia cuando el agente registra y recibe sobre la misma conexión, ni cuando el registrar rechaza registros de terceros. La arquitectura y la política determinan el riesgo.

Proteger el canal no prueba la interpretación

El documento revela relaciones sensibles y contiene capacidades. Un atacante que lo modifique puede cambiar lo que la persona cree conceder.

La RFC recomienda integridad y confidencialidad fuertes, con protección de extremo a extremo cuando sea posible o TLS/SIPS por salto. El store-and-forward debe entregar contenido protegido aunque su interfaz no sea SIP.

Eso no demuestra que la parte legible coincida con XML, que un comodín fuese visible, que el principal correcto actuara, que el relay instalara el mismo tuple o que lo aplicara después.

Vincule presentación y documento mediante hash. Pruebe mutación, replay, filtración de capacidad y estado obsoleto. Mantenga recibos distintos para transporte, interpretación y ejecución.

La actualización RFC 8217 cambia sintaxis, no adopción

RFC 8217 actualiza varios documentos SIP, incluido RFC 5360, para aclarar cuándo debe usarse name-addr. Una prueba actual debe declarar el conjunto normativo y el parser utilizado.

La relación entre documentos no prueba que un producto desplegara el cambio. El estado Proposed Standard tampoco demuestra uso, interoperabilidad ni comportamiento presente de un servicio concreto.