SEGURIDAD EN UNIX Y REDES

13.3.AUTENTICACIÓN 209CSATK CK SK TK CTK CSCliente que solicita un servicioServidor que ofrece dicho servicioServidor de autenticaciónServidor de ticketsClave secreta del clienteClave secreta del servidorClave secreta del servidor de ticketsClave de sesión entre el cliente y el servidor de ticketsClave de sesión entre cliente y servidorTabla 13.1: Abreviaturas utilizadas.sistema Unix ‘kerberizado’ teclea en primer lugar su nombre de usuario, de la misma forma que en unsistema habitual; la diferencia está en que el programa login envía el nombre de usuario al servidorde autenticación de Kerberos para solicitar un ticket que le permita comunicarse posteriormente conel servidor de tickets, TGS:C → A : C, T, NSi el usuario es conocido, el servidor de autenticación retorna un mensaje que contiene una clavepara la comunicación con TGS y un timestamp cifrado con la clave secreta del cliente, junto unticket para la comunicación con TGS cifrado con la clave secreta de este servidor:A → C : {K CT , N} KC , {ticket(C, T )} KTEl programa de login intentará descifrar {K CT , N} KC , con la clave que el usuario proporciona, ysi ésta es correcta podrá obtener K CT y N: un cliente sólo podrá descifrar esta parte del mensajesi conoce su clave secreta, K C (en este caso el password). Una vez obtenida K CT , la clave paracomunicar al cliente con el servidor de tickets, el programa passwd la guarda para una posteriorcomunicación con el TGS y borra la clave del usuario de memoria, ya que el ticket será suficientepara autenticar al cliente; este modelo consigue que el password nunca viaje por la red.13.3.2 Obtención de ticketsEl cliente ya posee una clave de sesión para comunicarse con el servidor de tickets y el ticket necesariopara hacerlo, cifrado con la clave secreta de este servidor (el cliente no puede descifrar este ticket).Cuando el cliente necesita acceder a un determinado servicio es necesario que disponga de un ticketpara hacerlo, por lo que lo solicita al TGS enviándole un autenticador que el propio cliente genera,el ticket de T y el nombre del servicio al que desea acceder, S, y un indicador de tiempo:C → T : {auth(C)} KCT , {ticket(C, T )} KT , S , NCuando TGS recibe el ticket comprueba su validez y si todo es correcto retorna un mensaje quecontiene una clave para comunicación con S y un timestamp cifrado con la clave de sesión del parCT, junto a un ticket para que el cliente C y el servidor S se puedan comunicar cifrado con la clavesecreta del servidor:T → C : {K CS , N} KCT , {ticket(C, S)} KSC sólo podrá obtener K CS si conoce la clave secreta, K CT .13.3.3 Petición de servicioTras obtener el ticket para comunicarse con S el cliente ya está preparado para solicitar el servicio;para ello presenta la credencial autenticada ante el servidor final, que es quien va a prestar el servicio.C se comporta de la misma forma que cuando solicitó un ticket a T: envía a S el autenticador reciéngenerado, el ticket y una petición que puede ir cifrada si el servidor lo requiere, aunque no esnecesario: