Resumen

  • RFC 9644 ofrece un vocabulario YANG común para capacidades y listas ordenadas de algoritmos SSH, no un comprobante del resultado de cada sesión.
  • La afirmación defendible enlaza la revisión del registro, la capacidad observada, la política aprobada, ambas ofertas SSH_MSG_KEXINIT, las selecciones por dirección, la clave de host, NEWKEYS, la autenticación y el resultado de aplicación.
  • El comprobante propuesto es un control operativo y no una exigencia normativa; si falta una observación, debe reducirse la conclusión.

El expediente que parece completo

El acta de cambio dice que se retiró un algoritmo antiguo. El controlador muestra una lista nueva. El dispositivo aceptó la edición. El inventario confirma compatibilidad con las alternativas. Es fácil cerrar ahí el expediente y afirmar que las sesiones quedaron protegidas por la política nueva.

Esa conclusión añade un hecho que los documentos no contienen. RFC 9644 define los agrupamientos ietf-ssh-common, ietf-ssh-client e ietf-ssh-server, y un proceso para generar cuatro módulos de enumeraciones desde registros SSH de IANA. Su misión es que la configuración sea interoperable y verificable como intención. No crea un registro operativo de cada negociación.

La diferencia puede expresarse en cuatro preguntas: ¿existe el nombre?, ¿lo soporta esta implementación?, ¿lo permite esta política?, ¿lo eligió esta sesión? Las respuestas proceden de autoridades y momentos distintos. Incluso la cuarta deja abiertas la identidad del servidor, la autenticación del cliente y el éxito de la operación.

Registrar un nombre no equivale a recomendarlo

Los módulos generados reflejan los registros fuente, incorporan nuevas revisiones y omiten valores reservados o sin asignar. Esa trazabilidad permite saber qué vocabulario compartían el sistema de gestión y el equipo.

Pero IANA no convierte cada identificador en una recomendación para una organización concreta. Los registros contienen algoritmos con historias y estados diferentes. RFC 9142 ilustra que los niveles de exigencia o recomendación para los intercambios de claves cambian con el tiempo. Por eso el control necesita guardar la instantánea del registro y, por separado, la decisión local que admite, ordena o excluye valores.

La revisión del módulo también forma parte de la evidencia. Si no se conserva, un nombre válido hoy podría proyectarse retrospectivamente sobre una configuración que usó otra versión del vocabulario. La cadena debe empezar con fecha, revisión o huella y las desviaciones de esquema relevantes.

La capacidad no concede permiso

La función opcional algorithm-discovery permite exponer supported-algorithms como datos operativos config false. Es una herramienta útil para planear migraciones y detectar equipos incapaces de adoptar una política futura.

Su semántica es posibilidad, no permiso. Un algoritmo soportado puede estar prohibido. Uno permitido puede no ser ofrecido por el par. Uno ofrecido puede perder frente a una preferencia anterior. El inventario debe vincularse con la versión exacta de software y con las características activas, porque una actualización puede cambiarlo.

También hay que resistir la falsa certeza de una lista vacía. RFC 9644 deja en ese caso el conjunto aceptable a la implementación. La ausencia de configuración no revela un valor predeterminado universal. Si el comportamiento efectivo no se ha medido o documentado para ese producto, el dato correcto es “indeterminado”.

Dos ofertas y dos direcciones

transport-params-grouping conserva listas de intercambio de claves, clave de host, cifrado y MAC en orden de preferencia decreciente. El orden debe quedar en el comprobante junto con la revisión, el aprobador y el dispositivo que la aceptó. Reordenar alfabéticamente para un informe destruye el sentido de la política.

La sesión, sin embargo, se decide con otra parte. RFC 4253 establece que cada par envía listas en SSH_MSG_KEXINIT. La selección atiende a la preferencia del cliente entre los valores que el servidor también ofrece y, en el intercambio de claves, a las capacidades de clave de host requeridas. Cifrado y MAC se negocian de manera independiente para cliente-servidor y servidor-cliente.

Por eso una casilla única que diga “cifrado aprobado” es insuficiente. Hay que conservar ambas ofertas y cada resultado direccional. Si no existe intersección válida, se desconecta la sesión. Que el equipo aceptara la política nunca fue prueba de que el par pudiera cumplirla.

Procedimiento, clave e identidad

El algoritmo de clave de host elegido describe el procedimiento que se emplea. No identifica por sí solo la clave presentada ni acredita que el cliente la aceptara por la razón correcta. RFC 8332 muestra la trampa: el mismo formato de clave RSA puede intervenir en algoritmos de firma rsa-sha2-256 o rsa-sha2-512. “Había una clave RSA” no reconstruye el hecho criptográfico.

RFC 9644 mantiene separados los parámetros de identidad del cliente y los de autenticación del servidor, incluidos los vínculos con almacenes de claves y confianza. Esa estructura obliga a separar varias decisiones: algoritmo negociado, clave observada, identidad validada, usuario autenticado, autorización concedida y operación ejecutada.

Un observador puede conocer solo parte de esa secuencia. Si captura KEXINIT pero no la decisión de confianza dentro del cliente, puede informar de la negociación y debe declarar desconocida la identidad validada. Completar el hueco por inferencia convierte una limitación de observabilidad en una afirmación falsa.

El momento en que se activan los algoritmos

SSH_MSG_NEWKEYS es la frontera donde entran en vigor las claves y algoritmos calculados. La compatibilidad de las ofertas no demuestra que se alcanzara esa frontera. Alcanzarla tampoco demuestra la autenticación de usuario definida por RFC 4252 ni el resultado de la aplicación.

Un comprobante útil, concebido como práctica operativa y no como formato impuesto por los RFC, enlaza:

  • instantánea de IANA y revisión o huella de los módulos generados;
  • implementación, funciones y desviaciones activas;
  • capacidad observada con fecha;
  • configuración ordenada exacta, revisión y aprobador;
  • huellas o capturas protegidas de los dos KEXINIT;
  • algoritmos seleccionados para intercambio, clave de host, cifrado y MAC, conservando la dirección;
  • huella de la clave de host, base y resultado de validación;
  • evidencia de NEWKEYS;
  • método y resultado de autenticación sin registrar secretos;
  • operación de aplicación, criterio de aceptación y resultado;
  • observaciones ausentes y alcance autorizado de la conclusión.

Una frase que no dependa de la fe

La especificación inicial mínima de Heng Lu obliga a elegir la afirmación antes que el sistema ornamental. “SSH cumple” no es verificable sin contexto. Una frase mínima puede ser: en una ventana identificada, una operación concreta se ejecutó con selecciones observadas que se vinculan a la política aprobada y a un par validado.

La primacía del código en ejecución decide qué hacer ante una discrepancia. Registro y modelo dan forma al plano simbólico. El intercambio real limita lo que puede decirse sobre el evento. Si divergen, la observación gobierna la descripción de la sesión y la divergencia abre una investigación.

La graduación de las conclusiones es parte del control. Con solo configuración puede afirmarse que la intención fue aceptada. Con negociación y NEWKEYS, pero sin decisión de confianza, puede acreditarse la activación, no la identidad. Con transporte e identidad, pero sin respuesta de aplicación, no puede declararse entregado el servicio.

Fuentes

  1. Especificación inicial mínima
  2. Capas de realidad y poder simbólico
  3. Primacía del código en ejecución
  4. Expediente de RFC 9644 en Datatracker
  5. Ficha de RFC 9644
  6. RFC 9644 en HTML
  7. RFC 9644 en texto
  8. RFC 9644 en XML
  9. Erratas en línea de RFC 9644
  10. Parámetros SSH de IANA
  11. Parámetros YANG de IANA
  12. RFC 4250: números asignados de SSH
  13. RFC 4252: autenticación SSH
  14. RFC 4253: transporte SSH
  15. RFC 6187: certificados X.509v3 para SSH
  16. RFC 8332: RSA con firmas SHA-2
  17. RFC 9142: actualización de intercambios de claves SSH
  18. RFC 7950: YANG 1.1
  19. RFC 8341: control de acceso a configuración
  20. RFC 8342: arquitectura de almacenes de gestión