Resumen

  • RFC 9813 permite que una relación cliente-servidor RADIUS sobreviva a cambios de dirección y que varias relaciones compartan una dirección NAT: la identidad PSK selecciona el registro candidato, mientras la posesión del PSK aporta la prueba posterior.
  • La operación debe conservar por separado la admisión de red, la validación del selector, la generación de la tabla, la prueba TLS, el secreto RADIUS, la política por cliente, la reanudación y el resultado real del acceso.

En el RADIUS clásico, la dirección de origen cumplía dos funciones. Localizaba una fila de la tabla de clientes y limitaba desde dónde podía llegar el tráfico. La fila contenía el secreto compartido y, a menudo, permisos locales para el tipo de dispositivo. Era un modelo simple mientras la dirección fuera estable y exclusiva.

La movilidad y NAT eliminan esas dos condiciones. Un solo equipo puede aparecer por varios enlaces. Varios controladores pueden salir por la misma dirección pública. Abrir una red completa resuelve la llegada, no la atribución; replicar filas por cada dirección posible convierte la configuración en una conjetura permanente.

RFC 9813, publicado en julio de 2025 como BCP 243, completa la orientación que faltaba para TLS-PSK en RADIUS sobre TLS y DTLS. La identidad PSK sustituye a la dirección de origen como identificador de cliente. Pero el cambio correcto no es «confiar en otro campo». Es repartir funciones que antes parecían una sola.

La primera cadena solo elige dónde buscar

El servidor necesita saber qué clave intentar antes de poder comprobarla. Por eso el cliente envía una identidad PSK al inicio del intercambio TLS. Esa cadena viaja en claro y la presenta un par aún no autenticado. Puede revelar afiliación si contiene un nombre significativo, y puede ser inventada por cualquiera que alcance el listener.

Una coincidencia en la tabla solo afirma que existe un registro con ese selector. No afirma que el emisor posea el PSK, que llegue desde una red permitida, que pueda enviar ese tipo de petición RADIUS ni que el dispositivo que custodia la clave sea el esperado. Llamar «cliente autenticado» a la fase de lookup elimina precisamente la separación que introduce el RFC.

Los identificadores opacos reducen la exposición, y una forma tipo Network Access Identifier puede ayudar a distribuir espacios administrativos. Ninguno de los dos convierte el nombre en secreto. La confidencialidad y la autenticación empiezan después.

Una entrada previa a la autenticación exige una frontera estricta

La identidad puede incluir UTF-8 inválido, NUL, caracteres especiales para SQL, LDAP, REST o shell, o una longitud cercana al máximo TLS de 65.535 octetos. Si se concatena a una consulta o se copia sin límites a registros y alertas, el selector se convierte en una interfaz de ataque.

El orden defensivo es concreto: limitar longitud, reconocer el espacio de nombres, validar la representación, aplicar una normalización versionada, escapar para la interfaz exacta y cerrar la conexión ante un fallo. La normalización no puede fusionar silenciosamente dos registros. Un cambio de biblioteca que modifica Unicode o mayúsculas puede cambiar qué relación se selecciona, aunque la pantalla muestre el mismo texto.

El recibo adecuado guarda un hash acotado del valor bruto, resultado y motivo de validación, forma canónica, versión de regla y fila elegida. Así la investigación puede reconstruir la decisión sin propagar bytes hostiles ni datos de afiliación por toda la observabilidad.

El registro representa un vínculo bilateral

La tabla lógica TLS-PSK puede asociar identidad, PSK, rangos de red autorizados, otras credenciales TLS y requisitos de certificado. La configuración RADIUS conserva las reglas de aplicación después de establecer el canal. Esa fila no debería entenderse como la identidad universal de una caja, sino como un vínculo entre un cliente y un servidor concretos.

Un mismo aparato puede usar relaciones diferentes con un primario y un respaldo. Dos dominios administrativos pueden compartir infraestructura y no custodia. RFC 9813 exige que una implementación admita una identidad y un PSK únicos para cada relación posible. El operador aún puede decidir reutilizar, pero ya no puede culpar al protocolo por no ofrecer aislamiento.

La unicidad permite revocar una relación, observar su último uso y limitar el alcance de una fuga. Un PSK compartido por veinte clientes produce una prueba que cualquiera de los veinte puede fabricar. La etiqueta del log parece específica, pero la autoridad subyacente sigue siendo colectiva. Con secretos simétricos, la exposición del cliente también puede facilitar la suplantación del servidor; por eso el RFC desaconseja PSK entre organizaciones no relacionadas.

Esta combinación de mecánica mínima común y decisión local encaja con Minimum Initial Specification. El estándar exige capacidad de aislamiento; cada operador asume de forma visible el coste y el riesgo de su topología.

La dirección sigue siendo evidencia, pero ya no es el nombre

RFC 9813 conserva dos comprobaciones. Antes de procesar la identidad, el servidor rechaza conexiones fuera de los rangos generales permitidos. Después de seleccionar la relación, verifica que la dirección observada pertenezca a los rangos autorizados para ese cliente.

La primera decisión reduce la superficie expuesta. La segunda aplica contexto a una relación que ya tiene candidato. Esto permite varias identidades detrás de NAT y una identidad desde distintas direcciones sin volver irrelevante la red. Un pase de rango prueba ubicación observada; un pase PSK prueba posesión de una credencial simétrica. Ni uno ni ambos prueban qué persona sostuvo el dispositivo.

Para el cliente móvil, el historial debe mostrar una relación estable atravesando ubicaciones autorizadas, no una sucesión ficticia de identidades. Para el NAT, debe mostrar relaciones distintas compartiendo una coordenada. Esa diferencia mejora tanto la política como la investigación.

TLS PSK y secreto compartido RADIUS son papeles distintos

El PSK TLS autentica la relación del canal. El secreto RADIUS protege partes del protocolo que circula dentro. RFC 9813 prohíbe usar el mismo valor en ambos lugares y exige rechazar esa configuración. Tampoco debe reutilizarse el mismo PSK entre TLS 1.3 y versiones anteriores. RFC 9258 describe importación con separación por versión, KDF y contexto.

Una consola con un único campo «secreto» borra estas fronteras. La interfaz debería presentar roles, generaciones y dependencias por separado, comparar valores sin registrarlos y permitir enumerar qué relaciones dependen de cada generación. El éxito del handshake no sustituye las comprobaciones del mensaje RADIUS ni la autorización de la solicitud.

Rotar significa cambiar también el selector

Como la identidad busca la clave, una nueva clave requiere una nueva identidad. Cambiar el PSK bajo el mismo nombre hace imposible distinguir un cliente desactualizado de una distribución fallida o de un ataque contra un nombre conocido. También oculta el solapamiento y permite que una reversión restaure autoridad sin una transición legible.

Una rotación controlada crea una generación nueva, observa su primer uso, limita el intervalo de coexistencia, registra el último éxito de la anterior y desactiva el selector viejo. Los intentos posteriores pasan a ser señales. La entrega de configuración no es finalización; retirar la autoridad anterior sí lo es.

El «último visto» ayuda a gestionar clientes dormidos, pero el silencio puede ser retiro, avería, estacionalidad o robo. Toda invalidación automática necesita propietario, umbral, excepción y recuperación definidos.

La reanudación no hereda autorización eterna

TLS 1.3 también genera PSK e identidades para reanudación. Son tickets del subsistema TLS, no identidades estáticas del administrador. RFC 9813 recomienda no usar reanudación en TLS-PSK; si una transición obliga a admitirla, los espacios de nombres y las tablas deben ser inequívocos. Una colisión no puede enviar un ticket a la tabla estática ni aceptar como sesión un texto no autenticado.

El servidor debe recuperar el contexto de la negociación original, reevaluar políticas afectadas por una dirección nueva y hacer un handshake completo cuando el caché no sea seguro. Ticket y caché tienen un máximo de siete días. «Reanudado» describe la recuperación de estado criptográfico; no concede una exención de la política presente.

La verdad operacional está en la secuencia

Cada aceptación debería poder reconstruir: rango general, parser y normalización, fila y generación exactas, rango del cliente, versión TLS y KDF, prueba PSK, caché de reanudación, integridad RADIUS, política local, acción del NAS y servicio observado. Un paso exitoso puede convivir con el fracaso del siguiente.

Running-Code Primacy obliga a preguntar qué código y qué tabla tomaron la decisión, no qué debería haber ocurrido según el formulario. On Reality Layers impide que una coincidencia simbólica hable por la criptografía, la política o la experiencia del usuario.

RFC 9813 convierte una dirección cambiante en contexto y una identidad PSK en selector. La mejora se conserva solo si ninguna de ellas absorbe autoridad que pertenece a otra capa.

Fuentes