Resumen

  • RFC 5197 es una guía informativa de aplicabilidad: compara siete formas de distribuir o acordar claves con MIKEY y muestra que la validez de una sesión depende del modo, de sus prerrequisitos y del escenario.
  • «Certificado aceptado», «identidad vinculada», «revocación reciente», «clave acordada», «PFS obtenida» y «SRTP descifrable» son hechos separados y deben conservar pruebas separadas.

Una cadena válida no contiene el presente

En el modo RSA de MIKEY, el iniciador genera la TGK, la protege con una clave envolvente y cifra esa clave con la clave pública del receptor. El mecanismo permite transportar el material en un solo mensaje y se adapta bien al media temprano cuando el certificado del destinatario ya está disponible.

La comodidad tiene límites precisos. Para escalar de forma general necesita una PKI; el certificado del receptor debe conocerse de antemano; el iniciador es quien genera el material; y no hay confidencialidad persistente. RFC 5197 añade otra advertencia operativa: la verificación de certificados puede no realizarse en tiempo real, por ejemplo cuando el estado de revocación proviene de otro componente.

Por eso una aplicación no debería emitir una sola afirmación llamada certificate_valid. Debe decir qué cadena verificó, contra qué almacén de confianza, a qué hora, para qué identidad y con qué evidencia de revocación. Si la consulta estaba caída o la respuesta era antigua, el sistema puede decidir continuar según política. Lo que no puede hacer honestamente es convertir esa decisión en prueba de frescura.

RSA-R resuelve el descubrimiento, no el contrafactual

El problema se vuelve distinto cuando el iniciador no conoce al receptor final. El forking o el retargeting pueden conducir la invitación a un terminal cuyo certificado no estaba disponible al comenzar. RSA-R permite que el certificado del respondedor llegue dentro del propio intercambio. Esa es una mejora concreta de descubrimiento e interfuncionamiento.

No equivale a PFS. El respondedor controla el secreto en la forma básica del intercambio. El iniciador puede incluir un valor aleatorio para participar, pero no puede obligar al otro extremo a utilizarlo de la manera honesta esperada. RFC 5197 lo refleja en su matriz: RSA-R no recibe la propiedad de confidencialidad persistente.

Es importante mantener ese matiz porque los inventarios tienden a sumar ventajas. Ven certificado en banda, contribución posible y cifrado de medios, y fabrican una categoría superior que el modo no promete. La pregunta de PFS sigue siendo contrafactual: si mañana se compromete la credencial duradera, ¿siguen a salvo las sesiones anteriores? El descubrimiento del certificado no responde.

La elección empieza por lo que realmente existe

La propia secuencia de selección de RFC 5197 parte del material disponible. Si existe un PSK, el iniciador puede usar PSK; si además la política exige PFS o aportación de ambos extremos, puede elegir DH-HMAC. Si conoce la clave RSA del respondedor, puede usar RSA. Si el respondedor quizá no tenga el certificado del iniciador, RSA-R aporta información en banda. Si la política exige PFS y contribución bilateral, DH-SIGN es el candidato certificado. NULL sólo tiene sentido si una capa inferior como TLS o IPsec aporta la protección prevista.

Esto no es una tabla para escoger el modo «más fuerte» en abstracto. Es una disciplina de prerrequisitos. DH-SIGN ofrece PFS y acuerdo mutuo, pero para escalar conserva una dependencia de certificados y sirve principalmente a punto a punto. DH-HMAC evita la PKI, pero exige PSK y no cubre por sí solo todas las formas de clave de grupo. NULL escala, pero puede dejar la clave maestra visible en un proxy donde termina la capa inferior.

La política debe declarar el objetivo antes de la selección. De lo contrario, el sistema elige por disponibilidad y después atribuye al resultado la propiedad que el negocio deseaba.

El reloj y el cache también votan

MIKEY trata el replay mediante marcas de tiempo y caché de mensajes, no con un desafío nuevo para cada intercambio. El veredicto depende de relojes razonablemente sincronizados, una tolerancia declarada y memoria suficiente para retener los identificadores relevantes. RFC 5197 recomienda ajustar el tamaño del caché al skew del entorno.

Una auditoría de certificados que ignore este estado puede certificar la identidad de un mensaje antiguo. En el extremo opuesto, una política de tiempo excesivamente estricta puede rechazar intercambios legítimos y dejar a los pares con TGK diferentes. Hay que conservar fuente de tiempo, desfase observado, ventana aceptada, época de reinicio del caché y resultado de la búsqueda.

De la TGK al primer paquete descifrado

Un Crypto Session Bundle puede agrupar varias Crypto Sessions con TGK y parámetros comunes, derivando TEK diferentes. La evidencia debe seguir ese árbol sin registrar los secretos en claro: identificador de CSB, identidad de TGK, cada sesión, ámbito de TEK y ramas receptoras.

Después viene el tiempo de uso. PSK y RSA pueden dejar el material preparado con el primer mensaje. Los modos Diffie-Hellman y RSA-R necesitan una respuesta. Si SRTP viaja por un camino más corto que la respuesta SDP, el media puede llegar antes de que el iniciador tenga la clave final. Una negociación válida puede no estar lista para el primer paquete.

El recibo termina sólo cuando enlaza propuesta, respuesta, instalación, primer paquete protegido y primer descifrado correcto. De ese conjunto se deriva un vector explícito: identidad, frescura de revocación, aportación de claves, PFS, replay, exposición intermediaria, aptitud de grupo y preparación del media. Ninguna casilla hereda el valor de otra.

Fuentes

  1. RFC 5197 en HTML
  2. RFC 5197 en texto
  3. Ficha informativa de RFC 5197
  4. Datatracker de RFC 5197
  5. Historial de RFC 5197
  6. Referencias de RFC 5197
  7. Erratas de RFC 5197
  8. RFC 3830 — MIKEY
  9. RFC 3711 — SRTP
  10. RFC 4650 — DH-HMAC
  11. RFC 4738 — RSA-R
  12. RFC 4567 — gestión de claves en SDP y RTSP
  13. RFC 4568 — descripciones de seguridad
  14. RFC 5027 — precondiciones de seguridad
  15. RFC 4086 — requisitos de aleatoriedad
  16. RFC 4082 — TESLA
  17. RFC 4442 — arranque de TESLA
  18. Heng Lu — capas de realidad y poder simbólico
  19. Heng Lu — especificación inicial mínima
  20. Heng Lu — primacía del código en ejecución