030 Autenticación KDC Distribucion de claves SSO

2

Authentication Protocols

• Challenge-response

– Verificar la contraparte

• Generacion de Claves

– Establecer el canal

Protocolos “Challenge-Response”

Dado un canal

– A verifica a B

• Envía un desafío (challenge) a B • Espera la respuesta

– B toma el desafío

• Desencripta el desafío

• Lo transforma y encripta la respuesta

Usado para

– Verificar un canal recién establecido – Verificar un canal establecido

A

B

“Desafio!”

4

CR: Garantizando que no se repiten

Usar nuevamente de los desafíos es peligroso

– Alguien puede reenviar las respuestas.

Técnicas para evitarlo:

– Timestamps

CR: Nonces

Nonces=

number used once

Secuencia de bits al azar tipicamente de

Generada por el origen como un desafio No reutilizar ni memorizar.

– Puede contribuir a la generación de claves

• Ej. por “hashing”

A

B

n_A

{n_A}_kAB

A

B

{n_A}_kAB

n_A

A

B

Challeng

e-resp

on

6

CR: Timestamps

Uso de la hora en la PC origen (ms)

A

B

t_A

{t_A}_kAB

A

B

{t_A}_kAB

t_A

A

B

{t_A}_kAB {t_A-1}_kAB

Challeng

e-resp

on

CR: Números de Secuencia

El origen mantiene un contador

– Que incrementa en cada desafio

A

B

c_A

{c_A}_kAB

A

B

{c_A}_kAB

8

CR: Claves

El origen genera una clave k

– La envía encriptada

Destino responde usando k

La clave puede ser enviada por medio de un tercero.

A

B

{k}_kAB

{“Hi!”}_k

A

B

Challeng e-resp on se exch an ges usin g keys

{k}_{kAS {k}k}

BS

10

Claves

Claves compartidas

– Existen antes que el intercambio se inicie – No cambian entre corridas del protocolo

Sesión:

– Ejecución completa del protocolo.

Claves de Sesión (or short-term keys)

– Generadas en la corrida y validas durante la sesión. – Deben ser seguras por la duración de la sesión

12

Generación de claves compartidas Diffie-Hellman

•Primer esquema de doble clave

•Diffie & Hellman en 1976

– Supuestamente

James Ellis

(UK CESG

http://www.cesg.gov.uk/) lo propuso secretamente en

1970

Diffie-Hellman Setup

Se ponen de acuerdo en parámetros:

– Un primo grande o polinomio

q

– α es una raíz primitiva de q

Cada usuario (eg. A) genera su clave

– Un numero secreto:

x

< q

– Calcula su clave publica:

y

=

α

mod q

16

Diffie-Hellman Key Exchange

La clave entre A y B es K

:

K_AB = αxA.xB mod q

= y_AxB mod q (which B can compute)

= y_BxA mod q (which A can compute)

Si se quieren seguir comunicando usan la misma clave o

seleccionan una nueva clave publica

Ejemplo de Diffie-Hellman

Alicia y Bob Esponja:

Se ponen de acuerdo en el primo

q=353

y

α=3

Seleccionan sus claves al azar:

Calculo de la parte publica:

– y_A=397 mod 353 = 40 (Alicia)

– y_B=3233 mod 353 = 248 (Bob)

Cada uno puede calcular la clave de sesión con:

K_AB= y_BxA mod 353 = 24897 = 160 (Alicia)

Distribución de claves

Dadas las partes A y B se presentan alternativas de

Distribución de claves

:

1. A selecciona la clave y se la envía en forma segura a B

2. Un tercero selecciona la clave y se las envía en forma segura

(A y B)

3. Si tienen una clave anterior pueden usar el canal cifrado para

generar una nueva.

4. Si ambos tienen un canal seguro con un tercero (C) se lo

20

Protocolo de clave simétrica Needham-Schroeder

Forma la Base de kerberos

Permite establecer las claves de Sesión

24

Needham-Shroeder Shared Key

•S es un servidor confiado por ambas partes

•K

es una clave simétrica que conocen sólo A y S

¿Que esta mal?

•El paso 3 no esta protegido con un

nonce

26

¿Que esta mal?

•Ejemplo: Soy un empleado que disgustado, aplico los

pasos uno y dos repetidamente sobre todos los

empleados.

28

Postulado 1: Significado del Mensaje

De recibir un paquete a creer que el paquete lo

envió la contraparte.

30

Postulado 2: Nonce verification

Se conoce que el paquete fue enviado por B a =>

se confia en la recepcion.

Postulado 3: Jurisdicción

32

34

Kerberos: Introducción

Durante 1983 en el M.I.T. (Massachussetts Institute of Technology) comenzó el proyecto Athena

entorno de trabajo educacional compuesto por estaciones gráficas, redes de alta velocidad y servidores

Sistema operativo Unix 4.3BSD

Sistema de autenticación:Kerberos ([MNSS87])

Antes:

– La autenticación se realizaba de dos formas:

• Se aplicaba la autenticación por declaración (Authentication by assertion), en la que el usuario es libre de indicar el servicio al que desea acceder (por ejemplo, mediante el uso de un cliente

determinado)

• se utilizaban contraseñas para cada servicio de red.

– El primer modelo proporciona un nivel de seguridad muy bajo, ya que se le otorga demasiado poder al cliente sobre el

servidor.

36

Si un servidor conoce la identidad de un cliente puede decidir sobre la concesión de un servicio o la asignación de privilegios especiales.

KryptoKnight ([MTHZ92], [JTY97]...), SESAME ([PPK93]) o Charon ([Atk93]) se basan en mayor o menor medida en Kerberos.

Uso de Kerberos

– Se encuentra disponible en la mayoria de los Unix, y viene integrado con OSF/DCE (Distributed Computing Environment).

– Login

– en el acceso a otros servidores (por ejemplo, mediante rlogin) – en el acceso a sistemas de ficheros en red como NFS.

– Usado por Microsoft a partir de Windows 2000

• Kerberos se puede implementar en un servidor, mediante un conjunto de bibliotecas que utilizan tanto los clientes como las aplicaciones;

Arquitectura de Kerberos

Basada en: Clave de Sesión, Ticket y Autenticador.

Clave de sesión es una clave secreta generada por Kerberos y expedida a un cliente para uso con un servidor durante una sesión.

Ticket es un testigo expedido a un cliente del servicio de tickets de Kerberos para solicitar los servicios de un servidor; garantiza que el cliente ha sido autenticado recientemente.

38

Kerberos

Es un sistema de autenticación centralizado

basado en clave simétrica

– Permite el acceso a servicios distribuidos

– Los servidores delegan el servicio de autenticación

en Kerberos

– Todos confían en el servidor de autenticación

Requerimientos

Requerimientos contemplados:

– seguridad

– confiabilidad

– transparencia

– Escalabilidad

40

Introducción a Kerberos 4

Servidor de Autenticación/

– Los usuarios se identifican al AS

– El AS entrega una credencial o Tiquet criptográfico

(ticket granting ticket TGT)

Ticket Granting server (TGS)

– Esta credencial o tiquet es presentado al TGS para

solicitar el acceso a servicios o servidores este

Grafico K4

1- So licitu

d TGT

2- TG T y Cl

ave de Sesio

n

Servidor AS Authentication Server

Servidor TGS Ticket Granting Server

3- Solic

itud SG T

4- SGT

y Clav

e de S esion

1- El Usuario solicita un servicio

2- el AS verifica la identidad y crea el TGT. El resultado se envía encriptado con la clave compartida con el usuario.

3- con la clave del usuario se desencripta lo recibido. Se envía el TGT al TGS.

4- El TGS desencripta el TGT con la clave que comparte con el TGT.

Se crea un ticket para el Servidor del servicio. 5- Req

uerimie

nto de S_ervicio

43

Kerberos 4 Paquetes

Intercambio de autenticación

(1) CL->AS: IDC || IDtgs || TS1

(2) AS->CL: EKc[KC,tgs || IDtgs || TS2 || LifeTime || Tickettgs]

Tickettgs = Ektgs [ KC,tgs || IDC || ADC || IDtgs || TS2 || LifeTime ]

Solicitud del Servicio al TGS

(3) CL->TGS: IDV || Tickettgs || Authenticator

(4) TGS->CL: EKC,tgs [ KC,V || IDV || TS4 || LT4 || TicketV ]

Tickettgs = EKtgs [ KC,tgs || IDC || ADC || IDtgs || TS2 || LT2 ]

Ticketv = EKv [ KC,V || IDC || ADC || IDV || TS4 || LT4 ]

Authenticator = Ekc,tgs [ IDC || ADC || TS3 ]

Acceso al Servicio

(5) CL-V: Ticketv || Authenticator

(6) V>CL: EKC,V [ TS5 + 1]

Ticketv = EKv [ KC,V || IDC || ADC || IDV || TS4 || LT4 ]

Authenticator = Ekc,v [ IDC || ADC || TS5 ]

1- Solic itud TGT

2- TGT y Clav

e de S esion

Servidor AS Authentication Server

Servidor TGS Ticket Granting Server

3- Solicitu d SGT

4- SGT y Cl

ave de Ses ion

5- Requerimiento de Servicio 6- Autenticador del Servidor

IDC Identidad de CL

IDTGS Identidad del TGS

TS Time Stamp

EKc Encripcion con clave del Cliente

ADC Address C Direccion del Cliente

Multiple Kerberos: Realm

1- Solicitud TGT

2- TGT y Clav

e de Sesion

AS

TGS

3- Solicitud SGT

4- SGT y Clave de Sesion

5- R eq ue rim ien to T ick et d e S erv

45

Problemas de Kerberos

Kerberizacion:

•Cualquier programa que lo utilice tiene que ser modificado siguiendo un proceso denominado `kerberización'.

•Esto implica disponer del código fuente de cada aplicación que se desee kerberizar, y una inversión de tiempo considerable.

Disponibilidad

•Relacionado con la seguridad de Kerberos es la gran centralización que presenta el sistema. Tiene que estar SIEMPRE DISPONIBLE.

Sincronismo de Hora (Secure Time Services)

•uso de timestamps como pruebas de frescura en Kerberos.

Problemas de Kerberos

Relativos a las claves:

•Usando apis de Kerberos se puede intentar probar secuencialmente las claves de un determinado usuario. Lo cual se incrementa si los usuarios usan claves debiles

Uso por servicios

•Fue pensado para personas que se autentican no para servicios que corren en segundo plano.

•En este caso debera almacenar de alguna forma la clave en el cliente. Y los equipos no suelen tener un servicio de almacenamiento seguro.

Acceso a los caches de las claves

47

Problemas de Kerberos

Suplantacion de Programa de Acceso (Spoofing Login):

•Se puede intentar de alguna forma reemplazar el login o que el usuario acceda a algo parecido al login. De forma tal que ingrese sus credenciales en un sistema falso que actua de intermediario.

Ticket Forwarding

•En kerberos 5 se incorporo la posibilidad de pasar el token. Confianza en cascada… ¿Quién usa el token?

49 Authentication Service (AS) Ticket Granting Service (TGS) Windows 2000 domain controller (KDC) Kerberos client \\AppServ

1. Request a ticket for TGS

2. Return TGT to client

3. Send TGT and request for ticket to \\AppServ

4. Return ticket for \\AppServ

5. Send session ticket to \\AppServ

6. (Optional) Send confirmation of identity to client

Authentication Service (AS) Ticket Granting Service (TGS) Windows 2000 domain controller (KDC) Username Password Client Logon AS_REQ E U(LTSK)(Authenticator), Username AS_REP

E_KDC(TGT), E_U(SK)

TGS_REQ

E_KDC(TGT), E_SK(Authenticator), AppSrv

TGS_REP

E_AppSrv(Ticket), E_SK(C-K)(SK

C-A)

AP_REQ

E_AppSrv(Ticket), E_SKC(Authenticator)

52

Implementación

http://web.mit.edu/kerberos/www/

Arquitectura

Autenticación

TGT

Ticket request

Service ticket

Service request

Service

Clientes

Servidores

56

Configuración del KDC

Instalar herramientas administrativas

Instalar ntpdate y elegir el servidor de sincronismo

– Puede ser interno o externo a la red

Crear el realm

Configuración de los servidores

•Instalar cliente de Kerberos

•Establecer el realm y el KDC

•Instalar servicios kerberizados

•Instalar ntpdate y sincronizar

•Agregar principals para el servidor

58

Configuración de los clientes

•Instalar cliente de Kerberos

•Establecer el realm y el KDC

•Instalar clientes de servicios kerberizados

•Instalar ntpdate y sincronizar

60

El concepto consiste en la autenticación única por parte del usuario para acceder a sus recursos.

La idea es realizar por única vez el logueo, sin necesidad de volver realizarlo a la hora de acceder a nuevos recursos en los que aún no se había autentificado.

SSO: Características

Multiplataforma: facilitar las tareas de inicio de sesión y de acceso a recursos de red desde distintas plataformas

Transparencia: el acceso a los recursos de sistemas se efectúa de forma transparente al usuario debido a la automatización del inicio de sesión

62

SSO: Características

Control de acceso: no se ve afectado por el uso de este sistema, SSO implica cambiar los mecanismos de autentificación del cliente y/o servidor, pero no modifica los permisos de los recursos.

Seguridad: depende de la arquitectura usada, pero en todos los casos la información debería viajar cifrada por la red

(SSL, certificados...)

SSO: Características

Sistemas Adaptados

– Los sistemas por medio de apis delegan la

autenticación en el SSO.

– Kerberos: Los servicios se kerberizan.

Por medio de Macros

64

CAS Web Single Sign On

Es un servicio de autenticacion centralizado pensado como un SSO para web.

Concebido y desarrollado por Shawn Bayern de la Universidad de Yale

En Diciembre de 2004, se convirtió en un proyecto de Java Architectures Special Interest Group, quien desde 2008 es responsable de su mantenimiento y desarrollo

Antes conocido formalmente como “Yale CAS”, ahora también se lo

conoce como “JA-SIG CAS”

CAS Web Single Sign On

Se accede a través de tres URL:

URL de login: realiza autenticación primaria (pide al usuario una NetID y una contraseña y lo valida). Intenta agregar la ticket-granting cookie (opcional, da la apariencia de Single Sign On).

Una vez que se completa la autenticación primaria, el CAS redirige al usuario a la aplicación desde donde vino, agregando el ticket.

URL de validación: Revisa en su base de datos si guardó en el pasado un ticket correspondiente al cual acaba de recibir. Si lo encuentra, y si el servicio asociado al ticket coincide con el servicio peticionado por la aplicación que está pidiendo la validación, devuelve a la aplicación que realiza la petición el NetID asociado a ese ticket. En caso contrario, se niega a validar el pedido.

66

web browser

app. #1 app. #2 app. #3

con CAS

CAS Web Single Sign On

web browser

app. #1 app. #2 app. #3 authentication

server

sin SSO

user

database user

database

CAS: Autenticación de Usuario

TGC: Ticket Granting Cookie

– User’s passport to the CAS server – Private and protected cookie

– Opaque re-playable ticket CAS

server

netId password

PS

user database

68

CAS: Acceso a la aplicación

web browser CAS server TGC HTT PS application

TGC ST

ST ST

ST: Service Ticket

– Browser’s passport to the CAS client (application) – Opaque and non re-playable ticket

– Very limited validity (a few seconds)

71

Cuando se termina el ciclo, la aplicación web ha podido

verificar la identidad de un usuario sin haber tenido acceso a la

contraseña.

Queda una cookie que puede volver a identificar al usuario

ante CAS de modo que el usuario no tenga que ingresar su NetID

y su contraseña en el futuro.

73

CA eTrust SSO: macro de Login

set _ERRORMODE resume set display_msgs 0

set debug 0

# Mapeo

proc map_drive {server group drive_letter} {

# Desconectar unidad previamente mapeada sso net_use -device $drive_letter -del yes

if {$debug} {

sso msgbox -msg "Map '\\\\$server\\$group' to $drive_letter para grupo $group" }

if {$display_msgs} {

sso statusbox -msg "$group Map '\\\\$server\\$group' to $drive_letter ... " }

sso net_use -device $drive_letter -net \\\\$server\\$group -persistent n -user $_LOGINNAME -password $_PASSWORD

if {$debug} {

sso msgbox -msg "SSOERR = $_SSOERR , $_LOGINNAME , $_PASSWORD" }

if {[file exist $drive_letter]} {

if {$display_msgs} {

sso statusbox -msg "Drive $drive_letter mapped to \\\\$server\\$group" sso sleep -time 2sec

} } else {

sso msgbox -msg "Map drive '\\\\$server\\$group' to $drive_letter FAILED (error $_SSOERR)" }

}