La familia de algoritmos CHAP (Challenge-Handshake Authentication Protocol) y en particular las implementaciones de Microsoft (MS-CHAP y MS-CHAPv2) se basan en mecanismos de retos para realizar la autenticación. En vez de solicitar la clave, que podría ser interceptada, se realiza una comunicación de acuerdo en tres partes (three-way handshake) en la que el servidor reta al cliente basándose en la clave secreta, el cliente responde al reto y el servidor confirma o deniega la autenticación. Este proceso se repite regularmente durante la comunicación.
El protocolo original CHAP requiere que ambos extremos cliente y servidor conozcan la clave secreta aunque nunca sea trasmitida.
La versión MS-CHAP además permite al usuario cambiar la clave, permite autenticación mutua entre pares y no requiere que ambas partes conozcan la clave en claro, sino un resumen (Hash) de la misma.
PPP (Point-to-Point Protocol) utiliza CHAP para autenticar a los usuarios.
Todos los equipos gestionados por un servidor forman un dominio o territorio Kerberos (realm).
Supongamos que Ana quiere solicitar un servicio de Bob y el KDC es
Carlos. Tanto Ana como Bob deben ser conocidos por Carlos (tener un
usuario y contraseña).
Primero Ana solicita a Carlos autenticarse mediante un mensaje en claro. Carlos le envía a Ana dos mensajes. El primer mensaje se llama TGT (Ticket-Granting Ticket) y está cifrado con una clave privada de Carlos (indescifrable para Ana). El TGT incluye el identificador de Ana, el periodo de validez de la sesión y la clave de sesión Ana-Carlos. El segundo mensaje que le envía Carlos a Ana es la etiqueta de sesión Ana-Carlos que contiene una clave de sesión Ana-Carlos y está cifrado con la clave de Ana. Al estar cifrado con la clave de Ana solo ella podrá acceder a la clave de sesión Ana-Carlos. Si Ana es capaz de usar la clave de sesión Ana-Carlos está autenticada. Una vez autenticada Ana debe solicitar a Carlos el uso del servicio de Bob. Para hacer la solicitud envía a Carlos un mensaje con el TGT y el identificador del servicio de Bob al que quiere acceder. Además Ana envía un mensaje Autenticador que contiene su identificador y una marca de tiempo, cifrado con la clave de sesión Ana-Carlos. Carlos utiliza su clave secreta para descifrar el TGT y obtener la clave de sesión Ana-Carlos. Con la clave de sesión Ana-Carlos descifra el Autenticador y lo da por válido (pues solo Ana lo ha podido enviar ya que es la única que conoce la clave de sesión Ana-Carlos). Carlos verifica si Ana tiene permiso para acceder al servicio de Bob y en ese caso le envía a Ana dos nuevos mensajes. Un mensaje contiene una nueva clave de sesión Ana-Bob cifrada con la clave de sesión Ana-Carlos (que Ana puede descifrar). Otro mensaje petición de servicio contiene los datos de Ana (identificador, periodo de validez) y la clave de sesión Ana-Bob cifrados con la clave de Bob (indescifrable para Ana). Ana envía entonces a Bob el mensaje petición de servicio tal y como se lo envió Carlos. Además le envía un nuevo mensaje Autenticador con su identificador y una marca de tiempo cifrado con la clave de sesión Ana-Bob. Bob descifra con su clave secreta el mensaje petición de servicio, lo que le garantiza que la petición proviene de un cliente autenticado (pues lo ha generado Carlos), y obtiene la clave de sesión Ana-Bob. Con la clave de sesión Ana-Bob descifra el Autenticador suma uno a la marca de tiempo y lo devuelve a Ana, de nuevo cifrado por la clave de sesión Ana-Bob. Ana descifra el Autenticador y verifica que la marca de tiempo es la que había indicado más uno, lo que sirve para autenticar a Bob. |
NTLMv2 utiliza HMAC-MD5 y separa el control de sesión en el protocolo NTLM-session (similar a MS-CHAPv2).
Aunque el protocolo Kerberos ha sido adoptado por Microsoft para la autenticación en el directorio activo, todavía utiliza NTLM en determinadas circunstancias:
Una vez establecida una comunicación entre un cliente y un servidor, éste puede requerir una autenticación de usuario, para verificar que dicho usuario tiene acceso al servicio. Pero esta autenticación de usuario puede realizarse independientemente de si la comunicación es segura o no (aunque cada vez más, los servicios restringidos suelen realizarse a través de comunicaciones seguras).
Las funciones de los servidores de autenticación son en realidad tres, conocidas como triple A o AAA: Authentication, Authorization, Accounting (Autenticación, Autorización y Registro).
El sistema RADIUS (Remote Authentication Dial-In User Service) permite decidir la concesión de acceso a partir de una combinación de datos como la identidad del usuario, la pertenencia a un grupo, la hora del día, la fecha, el nivel de cifrado soportado, el tipo de túnel... Además permite la asignación de parámetros de conexión, como algoritmos de seguridad obligatorios.
RADIUS es escalable y permite configurarse para solicitar la autenticación a otro servidor (RADIUS o de otro tipo).
El estándar de IETF (RFCs 2138 y 2139) define el puerto UDP 1812 para autenticación, pero se ha utilizado durante mucho tiempo el 1645.
Mientras que RADIUS combina la autenticación y autorización en el perfil de usuario, TACAS+ separa las dos operaciones. Además RADIUS utiliza UDP y TACACS+ utiliza TCP.
2009-05
![]() Está permitido copiar, distribuir y/o modificar los documentos bajo los términos de la licencia "Reconocimiento-Compartir bajo la misma licencia 3.0 España" de Creative Commons. Puede ver una copia de esta licencia completa. |