Resumen

  • RFC 10042 es un RFC informativo de IETF, firmado por Panos Kampanakis, Douglas Stebila y Torben Hansen, que define tres intercambios SSH híbridos entre ML-KEM y curvas tradicionales.
  • La respuesta del servidor aún incluye su clave pública de host y una firma. Después, otro protocolo autentica al usuario; por ello, KEX, identidad del host e identidad del usuario no comparten comprobante.
  • Un registro SFTP de AWS muestra la separación en la práctica: primero el algoritmo híbrido, luego el algoritmo y la huella del host, y finalmente la autenticación del usuario mediante clave pública.

El registro de una conexión SSH cuenta una historia en tres tiempos. Primero, cliente y servidor acuerdan cómo crear el secreto de transporte. Después, el cliente comprueba quién firma desde el extremo remoto. Por último, el servidor decide si el usuario que llama puede entrar y qué servicio puede abrir.

Una interfaz puede resumir todo con una etiqueta verde. El protocolo no lo hace.

RFC 10042 refuerza el primer tiempo. Publicado en agosto de 2026 como documento Informational, especifica mlkem768nistp256-sha256, mlkem1024nistp384-sha384 y mlkem768x25519-sha256. Cada nombre combina ML-KEM con P-256, P-384 o X25519 y deriva el secreto SSH a partir de la contribución poscuántica y de la clásica.

El riesgo que atiende es concreto. Un adversario puede grabar hoy una sesión cifrada y guardarla hasta que disponga de capacidad para romper el acuerdo clásico. La combinación evita que la confidencialidad futura dependa de una sola familia. Eso merece un comprobante claro; no merece los comprobantes de las identidades que aún no ha evaluado.

La clave del host sigue firmando

El intercambio híbrido no aparta la identidad del servidor. En la respuesta definida por RFC 10042 viajan K_S, la clave pública del host, el material híbrido del servidor y la firma sobre el hash del intercambio.

El secreto K se obtiene aplicando un hash a la concatenación de los secretos ML-KEM y clásico. El hash de intercambio abarca las identificaciones de software, los mensajes SSH_MSG_KEXINIT, la clave de host, los valores híbridos y el secreto resultante. La clave privada del host firma ese conjunto.

La unión protege el transcript, pero no borra la división del trabajo. KEX crea secretos nuevos para cifrar. La firma vincula el transcript con una clave de servidor. El cliente todavía necesita una razón externa para creer que la clave pertenece al destino esperado.

RFC 4253 lo refleja con dos listas negociadas por separado: kex_algorithms y server_host_key_algorithms. El cliente puede confiar mediante known_hosts, una huella verificada fuera de banda, un certificado u otra política. Si acepta la clave sin comprobarla, el propio RFC advierte que queda expuesto frente a ataques activos. La parte ML-KEM no detecta por arte de magia a un intermediario cuya clave fue aceptada sin control.

Por eso el comprobante de host debe guardar el algoritmo, la huella o certificado, la fuente de confianza, el resultado de validación y cualquier rotación. Si la firma sigue siendo clásica, hay que decirlo con la misma precisión con la que se anuncia el KEX híbrido.

La cuenta del usuario es otra frontera

Cuando el transporte ya existe, RFC 4252 inicia la autenticación del cliente. publickey es el método obligatorio para las implementaciones; contraseña y hostbased son opcionales, y pueden existir extensiones. En el método de clave pública, el servidor examina el nombre de usuario, el servicio solicitado, el algoritmo, la clave y la firma. También puede exigir más factores.

No es una repetición de la firma del host. Cambia el sentido de la confianza. La clave del host permite al cliente evaluar al servidor. La credencial del usuario permite al servidor evaluar a una persona o proceso y enlazarla con una cuenta. Cambian los almacenes, los responsables y las consecuencias.

Ni authorized_keys, ni la baja de una cuenta, ni MFA, ni una orden forzada, ni los permisos de directorio SFTP caben en el nombre del intercambio ML-KEM. Una organización puede migrar KEX mientras conserva esas decisiones para otra fase. Lo que no puede hacer es usar el primer hito como evidencia de que las demás ya terminaron.

Tres líneas que impiden el atajo

El blog de seguridad de AWS conserva un ejemplo útil. La versión original de 2023 mostró un intercambio híbrido experimental basado en Kyber. Una actualización del 5 de septiembre de 2025 informa que dos políticas de AWS Transfer Family pasaron a ML-KEM y enumera los tres métodos que después recogió RFC 10042.

La traza antigua no debe llamarse sesión RFC 10042. Sirve como modelo de observación. En líneas distintas aparecen el KEX híbrido, ssh-ed25519 como algoritmo de host, la huella del servidor y, más tarde, la autenticación mediante publickey. Solo entonces se abre la sesión SFTP.

El operador puede convertir esa secuencia en un recibo de tres columnas:

  1. Método ofrecido, método seleccionado y activación de las claves nuevas.
  2. Algoritmo y huella del host, junto con la regla que permitió confiar.
  3. Método de usuario, cuenta, factores y autorización concedida.

Un estado «connected» añade evidencia de que el canal funciona. No revela si el usuario tenía demasiado privilegio, si el archivo quedó cifrado al almacenarse, si el registro de auditoría es suficiente o si la copia de respaldo puede recuperarse sin volver a exponerlo.

La sustitución de nombres experimentales por ML-KEM ilustra además el coste del ciclo de vida. El cliente más antiguo, el servidor actualizado y la automatización incrustada no avanzan el mismo día. El orden de preferencias y la política de compatibilidad determinan el resultado. IANA registra coordenadas comunes; no publica un censo de conexiones.

Un estándar valioso porque no promete todo

Amazon Science presenta a Kampanakis como principal security engineer en AWS, con trabajo en criptografía aplicada, automatización de seguridad y estándares. En un perfil de AWS de 2023 explicó la necesidad de inventariar la criptografía asimétrica, experimentar con el impacto en SSH y otros protocolos y construir agilidad algorítmica. También separó un prototipo controlado del compromiso de mantener una solución a escala.

Ese recorrido da contexto, no autoría exclusiva. Douglas Stebila y Torben Hansen firman el RFC con él. El documento reconoce implementaciones y revisiones de participantes de AWS, OpenSSH, PuTTY y otros proyectos. NIST define ML-KEM; IETF e IANA sostienen el espacio interoperable.

RFC 10042 concreta el mínimo que todos deben ejecutar igual: mensajes, combinación de secretos, codificación, comprobaciones de longitud, claves efímeras por conexión, uso correcto de aleatoriedad y desconexión cuando la entrada no es válida. Así se puede probar una implementación contra otra.

La Especificación Inicial Mínima de Heng Lu ayuda a valorar esa frontera. El estándar compartido no necesita gobernar cada almacén de confianza y cada cuenta local. La decisión futura debe permanecer cerca del sistema que asume el riesgo. La Primacía del Código en Ejecución añade la disciplina de medir lo que ocurrió, no lo que decía la etiqueta.

Un comprobante completo guarda versiones, listas propuestas, KEX elegido, huella del host, decisión de confianza, cifrado y MAC, NEWKEYS, método del usuario, resultado de autorización, canal abierto, rekey, retroceso y fallos. RFC 10042 mejora de forma decisiva la primera columna. Mantener visibles las otras dos es la manera de no devaluarla.

Fuentes