Resumen

  • Una cadena válida, CertificateVerify y Finished prueban identidad criptográfica y continuidad del handshake bajo reglas concretas. No instalan el rol, la VLAN ni la ACL que debe aplicar el equipo de acceso.
  • El propio marco EAP admite que la autorización puede fallar después de autenticar, o que el backend autorice algo que el autenticador no puede ofrecer por falta de recursos.
  • La operación debe unir, sin confundir, el recibo de certificado, el resultado EAP, la decisión AAA, la entrega de claves, la ejecución del NAS y el primer tráfico observado.

Dos paneles verdes frente a un puerto bloqueado

08:14:02. En un caso construido, el cliente comprueba la cadena y el nombre del servidor EAP; el servidor comprueba el certificado del cliente. Las firmas CertificateVerify demuestran posesión de claves privadas. Finished confirma el mismo transcript protegido. El panel criptográfico queda verde.

08:14:03. El backend combina esa identidad con el NAS, el puerto y la red solicitada. Devuelve un rol y una VLAN condicionados a ese contexto. También el panel de política queda verde.

08:14:04. El switch de borde no encuentra la VLAN en el dominio de reenvío donde tendría que aplicarla. No puede prestar el servicio autorizado y mantiene cerrado el puerto controlado. No hay DHCP, autoconfiguración IPv6 ni sesión de aplicación.

No es un incidente atribuido a un operador. La escena junta límites documentados en RFC 5216, RFC 3748 y RFC 3579. Cada componente puede haber dicho la verdad; el error nace al llamar «acceso» a la suma incompleta.

La autoridad exacta de una autenticación mutua

RFC 5216 usa TLS dentro de EAP para autenticar mediante certificados, negociar con integridad, intercambiar secretos y derivar material de claves. Validar una cadena responde si el certificado llega a una raíz admitida bajo una política. CertificateVerify responde si el extremo controla la clave privada. Finished responde si las partes alcanzaron el mismo estado protegido.

Ninguna respuesta contiene por arte de magia el estado de un puerto, la existencia de una VLAN, el resultado de una ACL o la salud de una aplicación. El certificado puede aportar identidad autenticada a la autorización; no ejecuta la autorización.

El contrato contemporáneo incluye actualizaciones. RFC 8996 desaprueba TLS 1.0 y 1.1. RFC 9190 define EAP-TLS con TLS 1.3, incluyendo un calendario y una jerarquía de claves distintos. RFC 9965 añade aprovisionamiento mediante eap.arpa. Publicación y vigencia normativa no son censos de despliegue.

RFC 9190 añade una sección de autorización aplicable a EAP-TLS en general. Prohíbe fundar autorización o contabilidad en el EAP-Response/Identity exterior, que no está autenticado por EAP-TLS. Pide información autenticada del certificado, de la identidad PSK o del estado guardado para reanudación, y permite combinarla con datos del NAS, MAC, IP, puerto o SSID.

Autenticar y decidir no son sinónimos. Son dos pasos porque responden preguntas distintas.

EAP conserva el desacuerdo

RFC 3748 advierte que sincronizar el resultado de autenticación no garantiza sincronizar autorización. Un proxy AAA puede decidir algo invisible para el servidor EAP. El servidor AAA puede autenticar primero y descubrir después que no debe autorizar. Incluso puede autorizar mientras el autenticador carece temporalmente del recurso necesario.

Esas tres ramas separan autoridad, permiso y capacidad. Si la telemetría registra solo el final del método, elimina la rama que explica el fallo.

RFC 4137 modela las máquinas EAP y las señales que exponen a la capa inferior. eapSuccess no consulta la tabla de forwarding. Su nombre describe el resultado de la máquina, no una promesa de servicio de extremo a extremo.

Compartir una clave no concede el cargo

RFC 5247 divide la arquitectura: la fase EAP deriva MSK y EMSK; AAA transporta material al autenticador; después, el protocolo de asociación segura prueba posesión y genera claves transitorias.

El texto formula una frontera decisiva: probar posesión del material no demuestra necesariamente autorización para poseerlo. Una asociación puede confirmar que peer y NAS comparten la clave correcta sin demostrar que el backend autorizó precisamente a ese NAS, en ese lugar y para ese servicio.

RFC 4962 exige autorización de peer y autenticador. RFC 4017 enumera por separado autenticación mutua, fuerza de claves y autorización. RFC 5295 limita los usos derivados de EMSK. La entropía no sustituye la procedencia institucional.

El Accept puede ser imposible de cumplir

Cuando RADIUS transporta EAP, el NAS suele actuar como pass-through. RFC 3579 establece resultados Access-Accept y Access-Reject. El Reject obliga a denegar. El Accept termina la fase y puede transportar atributos de servicio.

Pero si el NAS no puede ofrecer el servicio pedido, debe tratar el Accept como Reject. RFC 3580 también exige no confundir el tipo de paquete RADIUS con un EAP Success o Failure encapsulado que diga lo contrario.

Por tanto, el backend acredita lo que decidió y envió. El borde debe acreditar lo que entendió y aplicó: rol, VLAN, filtro, asociación segura y transición del puerto. La red posterior debe acreditar dirección, vecino, DNS, ruta y aplicación.

El contexto puede venir de un narrador deshonesto

RFC 6677 define channel binding contra un NAS o proveedor que presenta una red al peer y otra al backend. El peer y el servidor comparan sus percepciones por un canal protegido.

La existencia del mecanismo demuestra que el certificado no autentica todos los atributos del entorno. SSID, ubicación, puerto y proveedor tienen fuentes distintas. Comprobar su consistencia mejora la decisión, pero todavía no demuestra entrega de tráfico.

RFC 7542 regula NAI y RFC 9427 actualiza métodos EAP basados en TLS para TLS 1.3. Ambos afinan el enlace entre pruebas, no permiten saltarlo.

La reanudación no congela el mundo

RFC 9190 considera autenticada una reanudación TLS 1.3 aceptada y vinculada a una sesión anterior. También advierte que no debe recibir privilegios superiores a los previstos originalmente.

Mientras un ticket sigue siendo válido, el certificado puede revocarse, el usuario cambiar de rol, el NAS cambiar de contexto o desaparecer la VLAN. Vigencia de cadena, estado de revocación, vida del ticket, autorización, sesión de puerto y servicio son relojes independientes.

La obligación de revisar revocación y el uso de OCSP stapling ayudan a un peer que aún no tiene Internet. Ese mecanismo de arranque no acredita el resultado que llegará después.

Guardar el punto exacto de ruptura

El recibo PKI conserva raíz, hashes, nombre, vigencia y revocación. El recibo TLS conserva versión, suite, CertificateVerify y Finished sin revelar secretos. El recibo EAP conserva método y resultado protegido.

AAA registra identidad, NAS, contexto, versión de política, Accept/Reject y atributos. El transporte de clave registra destinatario y alcance. El NAS registra si reconoció el servicio, instaló filtros, completó la asociación y abrió el puerto. La aplicación registra el primer intercambio útil.

Las frases negativas son válidas: «certificado correcto, autorización denegada»; «Accept recibido, VLAN ausente»; «puerto abierto, servicio fallido». Ocultarlas bajo un éxito agregado destruye la evidencia que permitiría reparar.

Fuentes

  1. RFC 5216
  2. RFC 5216 en Datatracker
  3. Estado de RFC 5216
  4. Historia de RFC 5216
  5. Erratas de RFC 5216
  6. RFC 9190
  7. RFC 3748
  8. RFC 5247
  9. RFC 4017
  10. RFC 6677
  11. RFC 8996
  12. RFC 9965
  13. RFC 7542
  14. RFC 3579
  15. RFC 3580
  16. RFC 4137
  17. RFC 4962
  18. RFC 5295
  19. RFC 9427
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption