doc/guide/admin/es/manual_gosa_es_kerberos.tex

   1 \chapter{Servicios de seguridad - Kerberos}
   2
   3 \section{Seguridad e identificación}
   4 ¿Quién se conecta al servidor?\\
   5 ¿Puedo estar seguro de que se puede confiar en el cliente, y el cliente en el servidor?
   6
   7 Esto es solo un pequeño resumen, para mas documentación vease Criptografía y Seguridad en Computadores\cite{cripto1} en español.
   8
   9 \subsection{Caso 1: Las contraseñas van en texto plano}
  10 Están ahí, todo aquel que vea el tráfico de la red las verá.
  11 Solo es factible si se están usando canales que se consideren seguros (SSL,ipsec,etc).
  12
  13 \subsection{El problema del hombre de enmedio}
  14 Si alguien ve tu usuario y tu contraseña puede hacer algo peor que simplemente ver que haces, puede suplantarte.
  15
  16 El hombre de enmedio (man in the middle) es un sistema que esta entre el cliente y el servidor que coge las peticiones del cliente, las manipula y las envia al servidor, por supuesto tambien puede manipular lo que viene del servidor.
  17
  18 \subsection{Caso 2: Las contraseñas tienen codificación simetrica}
  19
  20 \begin{enumerate}
  21 \item Mejora mucho la seguridad, cuanto mejor sea la encriptación sera mas seguro.
  22 \item Aún así es problemático y deberia usarse bajo canales seguros.
  23 \item ¿Como enviamos la clave con la que encriptamos la contraseña?
  24 \item Si esta clave cae, se producira una situación como la del envio en texto plano, y volvemos a estar en situación de que un sistema intermedio tome nuestra personalidad.
  25 \item Se considera segura a partir de 128bits de longitud.
  26 \item No autentifica quien envio el mensaje.
  27 \end{enumerate}
  28
  29 \subsection{Caso 3: Cifrado por bloques (Hashes)}
  30
  31 \begin{enumerate}
  32 \item Las contraseñas se codifican de tal manera que no se puede volver a conseguir la contraseña por otro metodo que no sea la fuerza bruta.
  33 \item Es menos problemático, pero deberia usarse solo bajo canales seguros.
  34 \item Se envían de esta manera por la red, cualquiera puede identificar que es una contraseña e intentar romper por fuerza bruta la contraseña.
  35 \item Sigue siendo sensible al problema del robo de identidad, ya que no autentifica quien envio el mensaje.
  36 \item Se puede mejorar usando tecnicas de desafio, enviando antes de pedir la clave un codigo al usuario con el que mejorar la seguridad del código resultante.
  37 \end{enumerate}
  38
  39 \subsection{Caso 4: Cifrado Asimetrico, Certificados SSL}
  40 \begin{enumerate}
  41 \item Se dividen en dos partes: la privada, aquella con la que codificamos, y la publica, que es aquella con la que decodifican los mensajes los clientes.
  42 \item Necesita logitudes de clave muy largas para ser seguros (>1024bits) y mucho mas tiempo de computación que los cifrados simetricos.
  43 \item En la práctica se utilizan para el envio de la clave y despues los mensaje se envian con codificación simetrica.
  44 \item Es mas resistente a sistemas intermedios, ya que este no puede acceder a la clave privada y por lo tanto no puede codificar mensajes.
  45 \end{enumerate}
  46
  47
  48 \subsection{Caso 5: Kerberos para identificación}
  49 \begin{enumerate}
  50 \item El protocolo supone que la red es insegura y que hay sistemas intermedios que pueden escuchar.
  51 \item Los usuarios y servicios (principales) deben autentificarse ante un tercero, el servidor kerberos, el cual es aceptado como autentico.
  52 \item Usa cifrado simetrico y asimetrico convirtiendo el conjunto en una red segura.
  53 \end{enumerate}
  54
  55
  56 \section{El protocolo Kerberos}
  57
  58 \subsection{El servidor Kerberos}
  59 El servidor kerberos no sirve un unico servicio, sino tres: \\
  60 AS = Servidor de autentificación.\\
  61 TGS = Servidor de Tickets.\\
  62 SS = Servidor de servicios.\\
  63
  64 \subsection{Clientes y Servidores}
  65
  66 El cliente autentifica contra el AS, despues demuestra al TGS que esta autorizado para recibir el ticket para el servicio que quiere usar, y por último demuestra ante el SS que esta autorizado para usar el servicio.
  67
  68 \subsection{Que es un ticket y como funciona Kerberos}
  69
  70 \begin{enumerate}
  71 \item[1.-] Un usuario introduce una clave y contraseña en el cliente.
  72 \item[2.-] El Cliente usa un hash sobre la contraseña y la convierte en la clave secreta del cliente.
  73 \item[3.-] El cliente envía un mensaje al AS pidiendo servicio para el cliente.
  74 \item[4.-] El AS comprueba si el usuario existe en la base de datos. Si existe le envia dos mensajes al cliente.\\
  75 El mensaje A: Tiene una clave de sesión del TGS codificada usando la clave secreta del usuario.\\
  76 El mensaje B: (TGT)Ticket-Granting Ticket. Este incluye el identificador del cliente, la dirección de red es este, un periodo de valided, y la clave de sesión del TGS, todo codificado usando la clave secreta del TGS.
  77 \item[5.-] El cliente recibe los mensajes A y B, con su clave secreta decodifica el mensaje A y coge la clave de sesión del TGS, con esta podra comunicarse con el TGS. Se observa que el cliente no puede decodificar el mensaje B al no tener la clave secreta del TGS.
  78 \item[6.-] Cuando el cliente quiere usar algún servicio, envia los siguientes mensajes al TGS:\\
  79 Mensaje C: Compuesto por el TGT del mensaje B y el identificador de petición de servicio.\\
  80 Mensaje D: Autentificador (El cual está compuesto por el identificador del cliente y una marca horaria - timestamp -) codificado con la clave de sesión del TGS.
  81 \item[7.-] Al recibir los dos mensajes, el TGS decodifica el autentificador usando la clave de sesión del usuario y envia los siguientes mensajes al cliente:\\
  82 Mensaje E: Ticket Cliente Servidor, que contiene el identificador del cliente, su dirección de red, un periodo de valided, y la clave de sesión del TGS, codificado usando la clave secreta del servidor.\\
  83 Mensaje F: Clave de sesión Cliente / Servidor codificada con la clave de sesión del TGS del cliente.
  84 \item[8.-] Una vez recibidos desde el TGS los mensajes, el cliente tiene información suficiente para autentificarse ante el SS. El cliente se conectara al SS y le enviara los siguientes mensajes:\\
  85 Mensaje G: El ticket de cliente / servidor codificado con la clave secreta del servidor. (Mensaje E).\\
  86 Mensaje H: Un nuevo autentificador que contiene el identificador del cliente, una marca horaria y que esta codificado usando la clave de sesión cliente / servidor.
  87 \item[9.-] El SS decodifica el Mensaje G usando su propia clave secreta y usando la clave Cliente/TGS en el mensaje F consigue la clave de sesion cliente/servidor, entonces le enviara el siguiente mensaje al cliente para confirmar su identidad:\\
  88 Mensaje I: La marca horaria del Autentificador mas 1, codificado usando la clave de sesión cliente/servidor.
  89 \item[10.-] El cliente decodifica el mensaje de confirmación y comprueba si la marca horaria ha sido actualizada correctamente. Si todo es correcto, el cliente confiara en el servidor y puede comenzar a hacer peticiones al servidor.
  90 \item[11.-] El servidor responde a las peticiones de ese cliente que ha sido autentificado.
  91
  92 \end{enumerate}
  93
  94 \section{MIT Kerberos}
  95
  96 \subsection{Instalación}
  97
  98 \subsection{Configuración y funcionamiento}
  99
 100 \subsection{Repliación - kprop}
 101
 102 \subsection{Ventajas y desventajas}
 103
 104 \section{El servidor Heimdal Kerberos}
 105
 106 \subsection{Instalación}
 107
 108 \subsection{Configuración y funcionamiento}
 109
 110 \subsection{Repliación - hprop}
 111
 112 \subsection{Repliación incremental - iprop}
 113
 114 \subsection{Heimdal sobre ldap}
 115
 116 \subsection{Ventajas y desventajas}
 117
 118 \section{La configuración de SASL}
 119
 120 \subsection{Modulos para kerberos}
 121
 122 \section{La configuración de clientes MS Windows}
 123