Resumen

  • RFC 5159 es un documento informativo de marzo de 2008 que registró cuatro atributos SDP procedentes de OMA BCAST.
  • stkmstream vinculaba medios protegidos con flujos de Short Term Key Messages que el terminal debía procesar.
  • Cada identificador era un entero no nulo y solo tenía que ser único dentro de la sesión SDP correspondiente.
  • Una misma cifra podía reaparecer en otra sesión con un significado distinto sin violar la especificación.
  • Una declaración en la sección multimedia sustituía a la declaración de sesión, de modo que el alcance formaba parte de la identidad efectiva.
  • Señalar el flujo correcto no acreditaba recepción de la clave, derecho de acceso, instalación del contexto ni reproducción.
  • bcastversion indicaba una versión, pero si carecía de protección podía facilitar una degradación.
  • SRTPAuthentication escogía entre RCCm1, RCCm2 y RCCm3 sin demostrar que un paquete hubiera sido autenticado.
  • SRTPROCTxRate anunciaba la cadencia del rollover counter y usaba uno por defecto.
  • Una cadencia declarada no acreditaba que emisor y receptor compartieran el mismo contador vivo.
  • El registro de nombres en IETF no trasladó desde OMA el control sobre la interpretación de la tecnología.
  • Una prueba útil debe conservar juntos sesión, versión, sección, alcance, identificador, mensajes recibidos y resultado criptográfico.

El identificador era una coordenada, no un nombre propio

En una transmisión protegida, un terminal necesita saber qué flujo de control contiene los mensajes de claves pertinentes para el medio elegido. Escuchar todos los flujos sería caro. RFC 5159 resolvió la selección con stkmstream: una referencia numérica desde la descripción SDP hacia uno o varios flujos de Short Term Key Messages.

La especificación exigía que el número fuese distinto de cero y único en la sesión. Esa última expresión fijaba la frontera. El identificador 7 no significaba «el flujo siete» para todo el sistema, toda la red o toda la vida del servicio. Significaba el flujo señalado como 7 dentro de una descripción y una sesión concretas.

Un sistema de observabilidad puede borrar esa frontera sin darse cuenta. Extrae el valor del atributo, lo coloca en una columna llamada key_stream_id y permite agrupar por número. Dos sesiones distintas aparecen entonces como una continuidad. Un incidente ocurrido en la mañana se enlaza con una rotación de la noche porque ambos usaron siete. La base de datos no contiene una mentira textual; contiene una clave incompleta que produce una relación falsa.

La unidad exportable debería incluir la identidad o huella de la descripción, sus campos de origen y versión, el instante, la sección multimedia y el alcance efectivo. Solo ese conjunto permite volver desde el número a la decisión que se tomó.

El alcance podía cambiar el significado sin cambiar la cifra

stkmstream podía aparecer a nivel de sesión o a nivel de medio. La aparición local sustituía a la lista global para esa sección. Por tanto, dos líneas idénticas en una captura podían tener efectos distintos dependiendo del lugar donde se encontraran. También una cifra podía seguir siendo siete mientras cambiaba el medio al que gobernaba.

La regla de sustitución plantea un problema de auditoría. Si el recolector aplana la estructura SDP, ya no se sabe si una referencia era global, local o estaba anulada. Si conserva solo la última cifra, tampoco se puede reconstruir la lista anterior. Y si el terminal recibió una versión distinta de la archivada por el servidor, la interpretación central no describe la conducta del extremo.

Hace falta guardar tanto la fuente como la resolución. La fuente permite revisar la sintaxis y la política. La resolución muestra qué lista terminó aplicando el software a cada medio. Un hash de la descripción del emisor no reemplaza el acuse del receptor.

Encontrar el flujo no era recibir la clave

El atributo servía para reducir trabajo: el terminal podía concentrarse en los flujos relevantes. Podían existir varias referencias como alternativas, o varias que debían procesarse en conjunto. Esa flexibilidad era útil, pero no definía por sí sola cuándo la operación había terminado.

Después de seleccionar un flujo todavía quedaban varias fronteras. Los paquetes tenían que llegar. El mensaje debía superar las comprobaciones correspondientes. El usuario o dispositivo debía tener derecho a obtener el material. La clave tenía que desenvolverse y asociarse al contexto adecuado. El tráfico SRTP tenía que autenticarse y descifrarse. Finalmente, la aplicación tenía que reproducir el contenido.

Informar «flujo de claves configurado» como «clave entregada» omite todas esas decisiones. Informar «clave recibida» como «contenido accesible» omite varias más. Una dirección no es el objeto al que apunta; una selección no es una ejecución.

El contador anunciado podía llegar tarde o no llegar

RFC 5159 añadió dos atributos relacionados con SRTP. SRTPAuthentication asignaba valores a RCCm1, RCCm2 y RCCm3. La elección coordinaba el algoritmo esperado, pero el veredicto sobre un paquete solo podía surgir al procesar ese paquete con el estado y el material correctos.

SRTPROCTxRate describía la frecuencia de transmisión del rollover counter, dentro de un intervalo de 1 a 65535, con valor uno por defecto. El ROC extiende el número de secuencia y ayuda a mantener sincronizados los extremos cuando se agota el espacio corto. La declaración de frecuencia era una promesa operativa, no un registro de recepción.

Un receptor podía perder el mensaje decisivo, rechazarlo por integridad, aplicarlo tarde o mantener otro estado después de una reanudación. En todos esos casos, la SDP seguía siendo válida. Para probar sincronía se necesitaban el paquete de control observado, su aceptación y el contador efectivo en ambos lados.

Una etiqueta de versión también podía ejercer poder

bcastversion era una cadena que señalaba la versión BCAST. El análisis de seguridad de RFC 5159 advertía que modificarla sin detección podía inducir el uso de una versión más antigua. La etiqueta actuaba sobre la decisión aunque no transportara ninguna clave.

También la manipulación de stkmstream podía apartar al terminal de los mensajes necesarios o obligarlo a gastar recursos en flujos inútiles. El efecto sería denegación de servicio. La integridad debía proteger no solo los secretos, sino también las instrucciones que determinaban dónde buscarlos y cómo interpretarlos.

Un control serio une la copia recibida con la política ejecutada. Revisar el documento publicado por el servidor no demuestra qué vio el receptor. Revisar la configuración del receptor sin guardar el documento no demuestra de dónde salió la decisión.

Registrar un término no equivalía a custodiar su significado

RFC 5159 fue publicado como Informational porque el trabajo técnico pertenecía a OMA BCAST. IETF e IANA proporcionaron un espacio estable para los nombres de atributo; OMA conservó el control de cambios sobre la semántica asociada. El registro evitaba colisiones. No convertía al registrador en propietario del protocolo ni certificaba implementaciones.

Ese reparto institucional importa en una investigación histórica. Para interpretar una captura no basta con una fila actual del registro. Hay que conocer la versión OMA, el perfil implementado y la descripción concreta. La posterior guía de multiplexación marcó bcastversion y stkmstream como NORMAL y dejó sin determinar la categoría de los dos atributos SRTP. Esa clasificación se refiere a su tratamiento en agrupación, no a calidad criptográfica ni adopción.

El texto esperaba uso con MBMS, BCMCS y DVB-H. «Esperado» describía el destino de diseño en 2008. No demuestra que una red, un operador o un terminal específico lo desplegara. La prueba de despliegue debe proceder de la operación.

Fuentes

  1. RFC 5159, HTML
  2. RFC 5159, texto
  3. Ficha de RFC Editor
  4. Ficha de IETF Datatracker
  5. Historial de RFC 5159
  6. Referencias de RFC 5159
  7. Erratas de RFC 5159
  8. RFC 4566
  9. RFC 8866
  10. RFC 4771
  11. RFC 3711
  12. RFC 8859
  13. RFC 5761
  14. RFC 7201
  15. RFC 5764
  16. RFC 8126
  17. Parámetros SDP de IANA
  18. Declaración IPR 2092
  19. RFC 2119
  20. RFC 8174
  21. RFC 3264
  22. Especificación inicial mínima
  23. Sobre las capas de realidad
  24. Primacía del código en ejecución