# ¿Cómo se protege TR-369? TLS, extremo a extremo, certificados y roles

Equipo de ingeniería de Dodderware · Publicado 2026-10-28 · https://blog.dodderware.com/es/seguridad-tr-369/

[Read in English](https://blog.dodderware.com/tr-369-security/)

> **Respuesta corta:** TR-369 protege USP en tres niveles. Cada Message Transfer Protocol debe usar transporte seguro, normalmente TLS, cuando el tráfico cruza fronteras entre redes. Si hay brokers o proxies en el camino, el Secure Message Exchange puede llevar TLS dentro de los USP Records entre los dos Endpoints. Y cada Controlador se autentica y recibe un rol, cuyos permisos rwxn el Agente revisa antes de actuar sobre un mensaje.

El Agente de la ONT de un cliente reinicia el equipo, cambia el Wi-Fi o descarga firmware cuando un Controlador se lo
pide. Por eso TR-369 dedica una sección entera a quién es ese Controlador y qué puede tocar. Esta guía recorre cómo USP
protege el canal, el mensaje y el modelo de datos, citando el requisito de cada paso.

## ¿Dónde pone USP su seguridad?

Como USP une componentes que pueden usar protocolos fuera de su alcance, la seguridad debe pensarse de extremo a
extremo, y por eso USP trae sus propios mecanismos (§1.6.2). La arquitectura los lista como piezas separadas: la
seguridad del MTP, un sistema de confidencialidad, integridad y autenticación de identidad de extremo a extremo, y el
control de acceso por elemento (§2). La comunicación entre Endpoints se protege con el MTP, con un Session Context de
USP, o con ambos (§2.1), como resume el [panorama de TR-369](https://blog.dodderware.com/es/que-es-tr-369/).

1. **Handshake TLS** (MTP): El Agente le exige un certificado X.509 a su par.
2. **Certificado verificado** (Autenticación): El Endpoint ID del certificado debe coincidir con el from_id del Record.
3. **Rol determinado** (Autorización): Asignado, heredado de una CA de confianza o untrusted en el primer uso.
4. **Revisión de permisos** (Cada mensaje): El rol debe permitir la acción antes de que el Agente la ejecute.

*Lo que revisa un Agente antes de actuar sobre el mensaje de un Controlador. Diagrama de Dodderware, basado en TR-369 §4.1.2, §8.1, §8.8 y §8.9.*

## ¿Qué protege TLS en el MTP?

R-MTP.0 exige transporte seguro cuando los mensajes USP cruzan fronteras entre redes, y se espera que los MTP que
corren sobre TCP implementen al menos TLS 1.2 (§4.1.2). Tres reglas definen cómo lo usa el Agente:

- **El par presenta un certificado.** Cuando TLS protege un MTP, el Agente debe exigir un certificado X.509 (R-MTP.1).
- **El certificado nombra al Endpoint.** Lleva el Endpoint ID en la extensión subjectAltName, y los Records cuyo
  `from_id` no coincida no se deben procesar (R-SEC.0a). Explicamos los Endpoint IDs en
  [Agente vs Controlador en USP](https://blog.dodderware.com/es/agente-vs-controlador-usp/).
- **El reloj importa.** Un Agente que puede obtener la hora absoluta debería esperarla antes de establecer TLS. Si se
  conecta sin ella, debe ignorar las fechas de validez del certificado; con la hora exacta, debe verificarlas
  (R-MTP.2, R-MTP.3).

La especificación también recomienda que los Agentes cifren todos los MTP, que activen ese cifrado por defecto y que
no implementen la opción de desactivarlo (§8.1). Las reglas TLS de cada binding están en
[transportes USP comparados](https://blog.dodderware.com/es/mtp-usp-websocket-mqtt-stomp/).

## ¿Cuándo no basta el cifrado del MTP?

Cuando hay algo en medio. Si la conexión MTP va directa entre Agente y Controlador, el cifrado del MTP basta para
lograr cifrado y seguridad de extremo a extremo (§8). Si hay un proxy o un broker entre los dos, se requiere el End
to End Message Exchange de la capa USP, o que el intermediario sea una parte confiable del ecosistema de extremo a
extremo (§8).

Ese intermediario confiable es un **Trusted Broker**: verifica que el `from_id` de cada Record coincida con el
certificado o las credenciales del Endpoint, o forma parte de un ecosistema cerrado cuyos Endpoints no falsifican su
ID (§1.4). Debe autenticar a cada cliente con un certificado de cliente único y garantizar que su comunicación no
pueda reenviarse a terceros (R-SEC.4b). Y no debe inspeccionar las cargas USP que viajan dentro de los USP Records
(R-SEC.4c).

Cuando el MTP no protege un Record, quien lo envía igual debe proteger la integridad de sus campos fuera de la carga
(R-E2E.29), con una firma ECDSA P-256 o, si ya existe una sesión TLS, con un HMAC basado en SHA-256 (§6.3).

## ¿Cómo funciona el Secure Message Exchange de extremo a extremo?

Existe por los transportes con broker y los proxies: los bindings solo protegen cada tramo (§6.4). El Endpoint de
origen protege la carga antes de segmentarla y enviarla, y el Endpoint receptor la descifra después de reensamblarla
(§6.4). El campo `payload_security` del Record indica cómo: `PLAINTEXT` o `TLS12`, que significa TLS 1.2 o superior
(§4.1.3.1).

El propio handshake TLS viaja dentro de USP Records, así que los Endpoints que usan `TLS12` deben intercambiar Records
dentro de un E2E Session Context (R-E2E.41). El Endpoint que inició el Session Context actúa como cliente TLS, y una
sesión TLS nueva toma dos viajes de ida y vuelta (§6.4.1.1).

| Requisito            | Qué exige                                                                                               |
| -------------------- | ------------------------------------------------------------------------------------------------------- |
| R-E2E.40             | TLS 1.2 o superior, `ECDHE-ECDSA-AES128-GCM-SHA256` para TLS 1.2 y `TLS-AES128-GCM-SHA256` para TLS 1.3 |
| R-E2E.40a, R-E2E.40b | Intercambio de claves ECDHE con la curva NIST P-256, firmas ECDSA con P-256 y SHA-256                   |
| R-E2E.42             | Prohibida la renegociación TLS                                                                          |
| R-E2E.43             | Autenticación mutua con certificados X.509                                                              |

## ¿Cómo decide un Agente si confía en un Controlador?

Los Controladores se autentican con certificados X.509, o con secretos compartidos en un MTP UNIX domain socket (§8.1).
Antes de procesar el mensaje de un Controlador, el Agente debe tener la información del certificado de ese Controlador,
o la de un Trusted Broker, y una conexión protegida criptográficamente (R-SEC.0). Después determina su rol:

- **Autoridades de certificación de confianza.** El Agente puede confiar en una CA solo para responder por la
  identidad de un Controlador, o también para otorgarle un rol que el Controlador hereda (§8.3, §8.9.2.4). La
  información guardada de la CA incluye como mínimo una huella (fingerprint) y su algoritmo (R-SEC.2).
- **Certificados autofirmados y TOFU.** Aceptarlos es política del Agente. Si los permite, el Controlador recibe un rol
  “untrusted” en el primer uso (R-SEC.6): el Agente confía en el certificado para cifrar, pero restringe mucho lo que
  ese Controlador puede hacer (§8.5). El Agente debe recordar qué certificado corresponde a qué Endpoint ID; si no,
  cada uso pasa a ser un primer uso (R-SEC.8, §8.5).
- **Challenges (desafíos).** Una frase de acceso o un PIN, por ejemplo impreso en la caja, puede elevar el rol de un
  Controlador. El valor de fábrica debe ser único por Agente, no deducible de lo que este revela, y con intentos
  limitados (§8.7, R-SEC.14 a R-SEC.16).

Un Agente debe borrar todas las sesiones de cifrado y autorizaciones de rol que tenga en caché cuando se reinicia
(R-SEC.21).

## ¿Cómo autentican los Controladores a los Agentes?

Los Controladores deben autenticar a los Agentes con certificados X.509, con un secreto compartido o con un Trusted
Broker que responda por ellos (R-SEC.9). La especificación desaconseja los secretos compartidos que no son únicos por
dispositivo, y también un mismo certificado compartido por varios Agentes mediante un Endpoint ID con comodín, que los
Controladores no están obligados a soportar (§8.6, R-SEC.11).

Con los certificados autofirmados de los Agentes, la decisión es del Controlador: rechazarlos, dejar que una persona
apruebe cada Agente o aceptarlos automáticamente (§8.5).

> **Dónde encaja DWS Support**
>
> El controlador USP de DWS Support maneja los certificados de los Agentes en modo Strict o Trust-On-First-Use, con un
> flujo de aprobación en la consola donde un administrador los acepta o los rechaza. Para quienes usan la consola, los
> roles se arman con permisos por acción, como reiniciar o restablecer de fábrica, y cada comando enviado a un
> dispositivo queda registrado.
>
> [Conoce DWS Support](https://dodderware.com/es/productos/dws-support/)

## ¿Qué puede hacer un Controlador una vez que es de confianza?

Un rol (Role) es el conjunto de permisos, una lista de control de acceso, que un Agente le otorga a un Controlador
sobre su Instantiated Data Model (§1.4). El Agente debe confirmar esos permisos antes de ejecutar cualquier acción de
un mensaje (R-SEC.1); si faltan, el error es 7006 “Permission denied” (§7.8).

Los roles se definen en las entradas `Device.LocalAgent.ControllerTrust.Role.`. Cada entrada Permission indica sus
Targets (las rutas que cubre), un Order y cuatro cadenas de permisos: Param, Obj, InstantiatedObj y CommandEvent
(§8.9.2.1). Cada cadena tiene cuatro caracteres, siempre en el orden `rwxn`, por Read, Write, Execute y Notify, con un
guion por cada permiso que falta. El ejemplo de la especificación da acceso total y luego retira la configuración de
confianza (se muestran las líneas de Param):

```text
Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Order = 1
Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Targets = Device
Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Param = rwxn
Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Order = 2
Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Targets = Device.LocalAgent.ControllerTrust
Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Param = ----
```

Dentro de un mismo rol, donde los Targets se superponen gana la entrada con el Order mayor. Entre varios roles, los
permisos se suman: `r---` y `---n` dan `r--n` (§8.9.2.3). Tres roles especiales tienen funciones fijas (§8.9.2.2):
`UntrustedRole` para cualquier Controlador que aún no tiene otro rol autorizado, `BannedRole` para certificados
revocados y `SecuredRoles` para los Controladores autorizados a leer Parameters protegidos (secured). Cualquier otro
Controlador los lee como un valor nulo, por ejemplo una cadena vacía. Los Agentes también deberían exponer el
`AssignedRole` y el `InheritedRole` de cada Controlador, para que los usuarios detecten Controladores intrusos
(R-SEC.1a).

> **¿Sabías que…?**
>
> Los permisos también ocultan lo que existe. Si un Controlador no tiene permiso de lectura sobre un Object o un
> Parameter, el Agente lo trata como si no estuviera en su Supported Data Model (R-GET.1). La especificación lo presenta
> como una medida de seguridad: un Controlador que no puede listar los elementos de un Object no debería descubrirlos
> sondeando con Get (§7.5.1).

## ¿Sabías que…?

- Un Agente que acepta el certificado autofirmado de un Controlador debe darle un rol “untrusted” (no confiable) en el primer uso. (TR-369 §8.5, R-SEC.6)
- Un Trusted Broker responde por la identidad de los Endpoints que transporta, pero no debe inspeccionar las cargas USP de sus Records. (TR-369 §8.4, R-SEC.4c)
- Los permisos se escriben con cuatro caracteres, rwxn, por Read, Write, Execute y Notify, con un guion por cada permiso que le falta al rol. (TR-369 §8.9.2.1)
- Un Agente que se conecta antes de tener la hora exacta debe ignorar las fechas de validez del certificado que recibe. (TR-369 §4.1.2, R-MTP.2)
- El Secure Message Exchange de extremo a extremo prohíbe la renegociación TLS. (TR-369 §6.4.1.1, R-E2E.42)

## Preguntas frecuentes

### ¿TR-369 exige TLS?

Un MTP debe usar transporte seguro cuando los mensajes USP cruzan fronteras entre redes, y se espera que los MTP sobre TCP implementen al menos TLS 1.2 (R-MTP.0, §4.1.2). Dentro de una LAN puede no ser necesario. Cuando se usa TLS, el Agente debe exigirle a su par un certificado X.509 (R-MTP.1).

### ¿Basta TLS en el MTP para tener seguridad de extremo a extremo?

Si la conexión MTP va directa entre Agente y Controlador, sí. Si hay un proxy o un broker en medio, se requiere el End to End Message Exchange de la capa USP, salvo que el intermediario sea una parte confiable del ecosistema de extremo a extremo (§8, §8.1).

### ¿Qué es Trust On First Use (TOFU) en USP?

TOFU es la política que hace usables los certificados autofirmados. El primer certificado que presenta un Endpoint se acepta y se recuerda para su Endpoint ID, y el Agente que lo permite le da a ese Controlador un rol “untrusted” en el primer uso, hasta que alguien lo eleve (§8.5, R-SEC.6 a R-SEC.8).

### ¿Qué es un Trusted Broker en USP?

Un intermediario en el que se confía para responder por el from_id de los Endpoints que conecta. Debe autenticar a los clientes con certificados únicos, garantizar la confidencialidad de sus comunicaciones y nunca inspeccionar las cargas USP (§1.4, §8.4, R-SEC.4b, R-SEC.4c).

### ¿Qué significa rwxn en USP?

Es la forma de escribir los permisos de un rol. Las letras corresponden a Read, Write, Execute y Notify, siempre en ese orden, y un guion marca el permiso que falta, como en r--n (§8.9.2.1).

### ¿Qué cifrado usa USP de extremo a extremo?

Los Endpoints que protegen las cargas con TLS deben implementar ECDHE-ECDSA-AES128-GCM-SHA256 para TLS 1.2 y TLS-AES128-GCM-SHA256 para TLS 1.3, con ECDHE y ECDSA sobre la curva NIST P-256 (R-E2E.40, R-E2E.40a, R-E2E.40b).

## Fuentes

- Broadband Forum, TR-369 – The User Services Platform, Issue 1 Amendment 5 (USP 1.5), enero de 2026.
- Dodderware, documentación de producto e ingeniería de DWS Support.
- §1.4: Definiciones (Role, Trusted Broker, End to End Message Exchange)
- §1.6.2, §2, §2.1: La seguridad como objetivo de diseño, componentes de la arquitectura, cómo se protege la comunicación entre Endpoints
- §4.1.2, §4.1.3.1: Protección de los MTP, el campo payload_security
- §6, §6.3, §6.4: End to End Message Exchange, integridad del Record, Secure Message Exchange
- §7.5.1, §7.8: Permiso de lectura en Get (R-GET.1), error 7006 Permission denied
- §8, §8.1 a §8.8: Autenticación, RBAC, CA de confianza, Trusted Brokers, certificados autofirmados, autenticación de Agentes, challenges
- §8.9: Teoría de operación, roles, permisos y roles especiales

[Leer la especificación TR-369](https://usp.technology/specification/index.htm)

TR-369 © The Broadband Forum. Todos los derechos reservados. Citado brevemente y parafraseado con fines explicativos; los diagramas son de Dodderware.

---

**Gestiona equipos TR-069 y TR-369 desde una sola consola.** DWS Support reúne cada ONT y router del hogar en una consola web, hable el protocolo que hable: TR-069 por GenieACS o un ACS integrado, TR-369 por un controlador USP nativo. Se instala en tu propia infraestructura. [Solicita una demo](https://dodderware.com/es/productos/dws-support/#get-started)