Resumen

  • RFC 9932 presenta MATF como una forma de publicar metadatos federados firmados y validar pares TLS de máquina a máquina; es una RFC informativa independiente, no una norma IETF ni evidencia de una instalación real.
  • La identidad derivada de una sesión TLS puede alimentar una política de aplicación, pero no sustituye la autorización, la ejecución ni la consecuencia de una solicitud.

Una federación necesita saber qué pares pueden reconocerse entre sí. Para ello necesita algo más sólido que una lista informal de nombres: una clave de confianza, metadatos que se puedan verificar, reglas para actualizar esos metadatos y una forma de comparar el certificado de un par con los pins que la federación publica. RFC 9932 describe esa arquitectura bajo el nombre Mutually Authenticating TLS in Federations, o MATF. El valor de la arquitectura no está en prometer que toda interacción posterior será correcta. Está en definir qué evidencia debe existir antes de que una identidad llegue a la capa que toma decisiones.

Conviene empezar por el alcance que el propio documento reclama. RFC 9932 es una contribución independiente e informativa a la serie RFC. No modifica TLS, no es un estándar de la IETF y no demuestra que proveedores, universidades, administraciones o aplicaciones lo hayan desplegado. Se dirige a autenticación entre máquinas dentro de federaciones, no a autenticación de navegadores. Esta condición no rebaja el documento; evita que su publicación se convierta retóricamente en una certificación de adopción, seguridad o autoridad general.

El primer registro de la cadena es el agregado de metadatos. El operador de la federación reúne información de sus miembros y la publica como un JSON Web Signature. Allí pueden figurar identificadores de entidad, direcciones de servicio, certificados emisores, pins, tiempos de emisión y caducidad, y datos de caché. Una firma JWS permite verificar el origen e integridad de un objeto frente a una clave de verificación que ya se decidió aceptar. Eso es una prueba concreta y valiosa.

No equivale a probar que el objeto era el más reciente que conservaba el par, que fue el que se consultó al abrir una conexión o que describe una política local todavía vigente.

La caducidad vuelve visible lo que suele esconderse bajo la palabra “firmado”. RFC 9932 exige rechazar los metadatos después de exp, aunque una copia continúe almacenada, y deja a la federación la obligación de establecer expiración y comportamiento de caché. Por tanto hay, como mínimo, tres tiempos que no deben mezclarse: el instante incluido en el documento, el instante de la última actualización local y el instante en que el componente de conexión leyó esa copia. Una firma correcta puede coexistir con un almacén desactualizado. Un archivo descargado recientemente puede no haber llegado al proceso que elige endpoints. Ninguno de esos estados demuestra por sí solo que una sesión se abrió.

El segundo registro es la comparación del par. Antes de iniciar o aceptar una conexión, un miembro precarga los pins de los endpoints seleccionados o autorizables. En la conexión TLS, compara la clave pública del certificado presentado con un pin publicado en los metadatos. Si no encuentra coincidencia, la conexión debe terminar. La regla puede impedir que se trate como par a quien no satisface el criterio de pin.

Pero no se debe invertir su significado: que un pin exista no demuestra que se presentó; que se presentó no demuestra que la sesión llegó a completarse; y que la comparación funcionó no demuestra que la aplicación permitió la operación que el par quería realizar.

La distinción no es una sutileza jurídica añadida desde fuera. RFC 9932 la conserva cuando habla de intermediarios. Si un proxy termina TLS, la aplicación no puede adoptar como identidad los encabezados que envía el propio par. El intermediario debe hacer la validación o reenviar a la aplicación un certificado, un pin derivado o un entity_id por un canal protegido con integridad y autenticación de extremos. Además, cualquier valor transmitido debe derivar directamente de la sesión TLS. El documento exige esa propagación para que la aplicación pueda aplicar la autorización. La aplicación recibe una entrada de identidad; mantiene el deber de decidir qué permite.

Ahí aparecen dos superficies de control que conviene mantener separadas. La federación define quién puede incorporarse a sus metadatos, cómo se verifica una firma y cuándo hay que renovar un pin. El dueño de una API o de un recurso define si el entity_id resuelto puede invocar un método, acceder a un conjunto de datos, modificar un objeto o iniciar una acción costosa. Puede usar organización, tags e identidad como condiciones. Sigue siendo responsable de la regla, de sus excepciones y del perjuicio que cause. Convertir “miembro de la federación” en “autorizado para esta acción” trasladaría una autoridad sin trasladar la responsabilidad que la justifica.

La rotación de certificados muestra por qué los dos controles no pueden comprimirse en una sola marca verde. RFC 9932 establece un orden: el miembro agrega un pin nuevo, el operador republica los metadatos firmados, los demás miembros refrescan y precargan, el endpoint presenta el certificado nuevo, y al final se retira el pin anterior. Publicar no es propagar. Propagar no es cambiar el certificado. Cambiar el certificado no es aceptar una petición de negocio. Cada transición necesita su propia observación, porque un hueco entre ellas puede provocar un rechazo legítimo, una caída temporal o una excepción que nadie sabe atribuir.

Para operar con claridad, el registro debería conservar el emisor y hash del JWS, su exp, la versión y hora de refresco local, los pins precargados, el endpoint elegido, la huella o certificado presentado, el resultado de comparación, el componente que lo hizo y la forma en que la identidad llegó a la aplicación. Después, en otro registro, deben quedar la política evaluada, la decisión, la solicitud, la ejecución y el efecto observado. Esta división no crea burocracia artificial: impide que una investigación tenga que inventar el eslabón que convirtió una clave en permiso.

La lectura responsable de RFC 9932 no es que toda federación sea un riesgo ni que un ancla central carezca de utilidad. Es que una herramienta de identificación tiene un alcance propio. La firma de la federación hace verificable un dato de afiliación. El pin puede rechazar un certificado equivocado. La aplicación, que es quien dispone del recurso y absorbe el coste, debe conservar la autorización como una decisión local y explícita.

Fuentes