> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/es/otro/faqs/security-and-privacy/seguridad-de-transporte-en-radius-frente-a-radsec.md). # Seguridad de transporte en RADIUS frente a RadSec Al implementar autenticación segura mediante el Protocolo de Autenticación Extensible (EAP), la elección del protocolo de transporte — RADIUS sobre UDP frente a RADIUS sobre TLS (RadSec) — desempeña un papel fundamental para determinar con qué seguridad se transmiten los metadatos y los elementos del protocolo a través de la red. Tanto RADIUS como RadSec pueden transportar mensajes EAP, incluidos los utilizados en métodos comunes como EAP-TLS, PEAP y EAP-TTLS. Aunque el funcionamiento interno del método EAP sigue siendo el mismo, el protocolo de transporte influye en la visibilidad, la integridad, la confidencialidad de los metadatos y el comportamiento operativo. Este documento compara cómo RADIUS y RadSec afectan al transporte de EAP, centrándose en el cifrado, el uso de secreto compartido, la exposición de atributos, las implicaciones para el registro y las consideraciones de implementación. *** ### Seguridad del transporte: diferencias fundamentales Los métodos EAP como EAP-TLS, PEAP y EAP-TTLS proporcionan mecanismos de autenticación entre clientes (solicitantes) y servidores de autenticación. Sin embargo, estos métodos no cifran de forma inherente el transporte de metadatos entre nodos intermedios. Esta función recae en el protocolo de capa de transporte: * RADIUS (UDP) transmite mensajes EAP y atributos RADIUS en texto plano. * RadSec (TLS) cifra todo el paquete RADIUS, protegiendo todos los atributos y encabezados del protocolo durante la transmisión. La siguiente tabla resume estas diferencias, que afectan a la confidencialidad de atributos como la identidad externa, la IP del NAS, el ID de la estación llamante y más. Aunque los métodos EAP pueden cifrar las credenciales del usuario (por ejemplo, certificados o contraseñas), los metadatos siguen expuestos en RADIUS estándar a menos que se use RadSec. | Protocolo | RADIUS | RadSec | | ---------------------------------- | ----------------------------------------------- | -------------------------------------- | | Protocolo de la capa de transporte | UDP (normalmente) | TLS sobre TCP | | Cifrado | Sin cifrado de transporte | Cifrado completo del transporte | | Puerto predeterminado\* | UDP 1812 | TCP 2083 | | Notas | Sin estado; puede ser filtrado por cortafuegos. | Con estado; establece túneles seguros. | \*Aunque estos puertos son los estándares reconocidos, algunas implementaciones pueden personalizarlos por motivos de política local o de infraestructura. *** ### El papel del secreto compartido de RADIUS en ambos protocolos El secreto compartido de RADIUS se utiliza para la integridad de los paquetes y comportamientos heredados de cifrado. Esto se aplica independientemente de si el transporte es RADIUS estándar o RadSec. **Usos principales:** * **AVP Message-Authenticator**: Garantiza la integridad del paquete mediante HMAC-MD5. * **AVP User-Password (métodos heredados)**: Cifra las credenciales usando el secreto compartido. * **Compatibilidad con RadSec**: Incluso en RadSec, el secreto compartido se mantiene por compatibilidad con la semántica de RADIUS y con sistemas intermedios. {% hint style="info" %} **Nota:** El secreto compartido nunca se transmite por la red; se utiliza localmente para operaciones HMAC y validación de AVP. {% endhint %} *** ### Visibilidad de elementos de datos: RADIUS frente a RadSec Esta tabla compara los elementos de datos clave al usar EAP-TLS sobre RADIUS (UDP) y RadSec (TLS), agrupados por riesgo de visibilidad durante la transmisión.
Elemento de datosRADIUS (UDP)RadSec (RADIUS sobre TLS)Ejemplo / Notas
Paquete RADIUS exteriorTexto claro (sobre UDP o TCP).Cifrado (sobre TLS).Incluye tanto los encabezados como los AVP. Por ejemplo, el paquete es visible en Wireshark o tcpdump.
Identidad del usuario (identidad externa)Enviado en texto claro.Cifrado (sobre TLS).anonymous@organisation.com usado para el enrutamiento por dominio.
AVP de RADIUS (atributos)Algunos en texto claro (por ejemplo, NAS-IP, User-Name).Completamente cifrados en TLS.

NAS-IP-Address,

Calling-Station-Id

Encabezados de RADIUSTexto claroCifrados en TLS

Code (Access-Request), Identifier,

Length,

Authenticator

Secreto compartido de RADIUSNo se transmite (se usa internamente)No se transmite (se usa internamente)Se usa para el cifrado de AVP y la Message-Authenticator validación.
Carga útil EAP Cifrada entre el cliente y el servidorCifrados en TLSIncluye el handshake de TLS, la validación de certificados, etc.
Credenciales del usuario (certificados/clave)Cifradas en el túnel EAPCifradas en el túnel EAP + TLSSe aplica a métodos basados en certificados (EAP-TLS) y basados en contraseña (PEAP). Certificado del cliente con sujeto CN=jsmith, OU=IT
Contraseña (por ejemplo, PEAP o MSCHAPv2)Cifrada en el método en túnel (por ejemplo, PEAP)Cifrada en el túnel EAP + TLSSe aplica a métodos basados en contraseña.
*** ### Privacidad de la identidad: identidad externa frente a identidad interna Los métodos EAP que usan tunelización o certificados (por ejemplo, PEAP, EAP-TTLS, EAP-TLS) admiten identidades externas e internas: * **Identidad externa**: Se envía en claro en el AVP User-Name para facilitar el enrutamiento por dominio. A menudo se anonimiza (por ejemplo, `anonymous@domain.com`). * **Identidad interna**: Se transporta de forma segura dentro del túnel EAP cifrado (por ejemplo, nombre de usuario/contraseña, CN del certificado). #### Comportamiento entre transportes: * En **RADIUS**, la identidad externa se envía en texto plano y es visible en la red. * En **RadSec**, todo el paquete, incluida la identidad externa, está cifrado. Las preocupaciones de privacidad relacionadas con que la identidad externa se transmita en texto plano con RADIUS pueden mitigarse configurando la privacidad de la identidad o aprovechando certificados de dispositivo que no contengan datos personales identificables (PII) en el atributo de nombre común {% hint style="info" %} **Nota**: Algunas plataformas, como el cliente EAP nativo de Windows, pueden no admitir la privacidad de la identidad de forma predeterminada en métodos como EAP-TLS, exponiendo potencialmente la identidad real en la capa externa. {% endhint %} #### Identidad externa La tabla siguiente ofrece una visión general de los valores típicos con los que varias plataformas de SO rellenan la identidad externa. | Tipo de credencial | Identidad externa | SO aplicable | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Nombre de usuario/contraseña |



Normalmente:
- UPN
- Dirección de correo electrónico

| | | Certificado de dispositivo |

Propiedad del nombre común (CN) del nombre del sujeto del certificado cliente.

Normalmente:
- DeviceName
- ID del dispositivo de Intune (GUID)
- ID del dispositivo de AAD (GUID)

|

| | Certificado de usuario |

Propiedad del nombre común (CN) del nombre del sujeto del certificado cliente.

Normalmente:
- UPN
- Dirección de correo electrónico

|

| \*El cliente EAP utilizado en Windows no admite la privacidad de la identidad para EAP-TLS. *** ### Consideraciones de registro y despliegue #### RadSec (TLS) RadSec cifra todo el paquete RADIUS, lo que evita la escucha pasiva. Esto traslada el registro y el diagnóstico desde la inspección de red al nivel de la aplicación o del servidor RADIUS, ya que esos son los extremos que terminan la sesión TLS. Las organizaciones que migran a RadSec deben evaluar los flujos de trabajo de supervisión para adaptarlos al tráfico cifrado. #### RADIUS (UDP) La transmisión en texto claro de atributos (User-Name, NAS-IP-Address, etc.) simplifica la resolución de problemas y el diagnóstico en vivo, permitiendo la captura de paquetes con herramientas mínimas. Sin embargo, esto aumenta el riesgo de exposición de metadatos sensibles durante la transmisión. #### Compatibilidad de red La compatibilidad con RadSec no es universal en todos los dispositivos e infraestructuras de red. Muchos conmutadores de red, puntos de acceso inalámbricos y cortafuegos solo admiten RADIUS tradicional. En entornos mixtos, puede ser necesario un proxy de RadSec a RADIUS para conectar componentes modernos y heredados. Se recomiendan evaluaciones de infraestructura antes de desplegar RadSec en producción. *** ### Conclusión y puntos clave Transportar métodos EAP a través de RADIUS o de RadSec ofrece la misma sólida protección de extremo a extremo para las credenciales del usuario, pero difiere significativamente en cómo se exponen los metadatos y los elementos del protocolo durante la transmisión. * **Protección de extremo a extremo de EAP**: EAP proporciona una sólida protección para las credenciales del usuario tanto sobre RADIUS como sobre RadSec. * **Diferencia principal**: RADIUS usa UDP y no cifra el propio paquete RADIUS, mientras que RadSec envuelve todo el paquete en TLS, ocultando todos los atributos y encabezados de la red. * **Confidencialidad de los metadatos**: RadSec cifra todos los metadatos (encabezados, atributos e identidad externa), evitando su exposición a nivel de red. * **Secreto compartido**: El secreto compartido nunca se transmite. Solo se usa localmente para calcular comprobaciones de integridad del mensaje y verificar la autenticidad. * **Compensaciones**: RadSec ofrece mayor confidencialidad, pero complica el diagnóstico debido al cifrado, y su compatibilidad no es universal en todos los equipos de red. *** ### Estándares y referencias RFC Para más detalles sobre protocolos y especificaciones: * EAP (Protocolo de Autenticación Extensible): RFC 3748 * EAP-TLS: RFC 5216 * RADIUS (Servicio de usuario de autenticación remota de acceso telefónico): RFC 2865 * RadSec (RADIUS sobre TLS): RFC 6614 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.radiusaas.com/es/otro/faqs/security-and-privacy/seguridad-de-transporte-en-radius-frente-a-radsec.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.