APLICACIONES DE AUTENTIFICACIÓN

Dávila Miguel, María Fonseca Romero, Hernádez Torres, Li Fernández, M

Beatriz Sandro Miguel Jennifer Roxana Haydee
Universidad Nacional de Universidad Nacional de Universidad Nacional de Universidad Nacion
Trujillo Trujillo Trujillo Trujillo
[email protected] [email protected] [email protected] [email protected]

ABSTRACT para evitar eavesdropping y ataques de Replay. En crip-

This paper focuses on two of the most important authen- tografı́a, X.509 es un estándar UIT-T para infraestructuras
tication specifications in current use. Kerberos is an au- de claves públicas (en inglés, Public Key Infrastructure o
thentication protocol based on conventional encryption that PKI). X.509 especifica, entre otras cosas, formatos están-
has received widespread support and is used in a variety of dar para certificados de claves públicas y un algoritmo de
systems. X.509 specifies an authentication algorithm and validación de la ruta de certificación. X.509 fue publicado
defines a certificate facility. The latter enables users to ob- oficialmente en 1988 y comenzado conjuntamente con el es-
tain certificates of public keys so that a community of users tándar X.500 y asume un sistema jerárquico estricto de au-
can have confidence in the validity of the public keys. This toridades certificantes (ACs) para emisión de certificados.
facility is employed as a building block in a number of ap- Esto contrasta con modelos de redes de confianza, como
plications. PGP, donde cualquier nodo de la red (no solo las ACs)
puede firmar claves públicas, y por ende avalar la validez
Categories and Subject Descriptors de certificados de claves de otros. La versión 3 de X.509
[Aplicaciones para Seguridad en Redes]: Aplicaciones incluye la flexibilidad de soporte de otras tecnologı́as como
de Autentificación bridges y mallas. Puede usarse en una web de confianza
peer to peer de tipo OpenPGP, pero desde 2004 raramente
se usa ası́. El sistema X.500 nunca se implementó completa-
General Terms mente, y el grupo de trabajo de la infraestructura de clave
Seguridad en Redes pública de la IETF, comúnmente conocido como PKIX para
infraestructura de clave pública (X.509) o PKIX, adaptó el
Keywords estándar a la estructura más flexible de Internet. X.509 in-
Seguridad, Redes, Servicio de Autentificación, Kerberos,X.509 cluye también estándares para implementación de listas de
certificados en revocación (CRLs), y con frecuencia aspectos
1. INTRODUCCIÓN de sistemas PKI. De hecho, el término certificado X.509 se
La seguridad e integridad de sistemas dentro de una red refiere comúnmente al Certificado PKIX y Perfil CRL del
puede ser complicada. Puede ocupar el tiempo de varios certificado estándar de X.509 v3 de la IETF, como se es-
administradores de sistemas sólo para mantener la pista de pecifica en la RFC 3280. La forma aprobada por la IETF de
cuáles servicios se están ejecutando en una red y la manera chequear la validez de un certificado es el Online Certificate
en que estos servicios son usados. Más aún, la autenticación Status Protocol (OCSP).
de los usuarios a los servicios de red puede mostrarse peli-
grosa cuando el método utilizado por el protocolo es inher- 2. KERBEROS
entemente inseguro, como se evidencia por la transferencia Kerberos es un servicio de autenticación desarrollado como
de contraseñas sin encriptar sobre la red bajo los protoco- parte del Proyecto Athena en el MIT. Supongamos un en-
los FTP y Telnet. Kerberos es una forma de eliminar la torno distribuido abierto en el cual los usuarios de las esta-
necesidad de aquellos protocolos que permiten métodos de ciones de trabajo desean acceder a servicios. Nos gustarı́a
autenticación inseguros, y de esta forma mejorar la seguri- que los servidores sean capaces de restringir el acceso a
dad general de la red. Además brinda autenticación mu- usuarios autorizados y ser capaz de autenticar las solicitudes
tua: tanto cliente como servidor verifican la identidad uno del servicio. En particular, las siguientes tres amenazas ex-
del otro. Los mensajes de autenticación están protegidos isten:

• Un usuario puede tener acceso a una estacion de tra-

bajo particular, y pretender ser otro usuario que op-
eran desde esa misma estación.

• Un usuario puede alterar la dirección de red de una

estación de trabajo de tal manera que las solicitudes
enviadas desde la estación alterada parecen venir de la
estación suplantada.
 • Un usuario puede escuchar intercambios de comuni- las identidades de los clientes que soliciten el servicio. Una
cación y usar un ataque de repetición para poder en- alternativa es utilizar un servidor de autenticación (AS) que
trar en un servidor o interrumpir las operaciones. conozca las contraseñas de todos los usuarios y las almacene
en una base de datos centralizada. Por otra parte, el AS
comparte una única clave secreta con cada servidor. Es-
Kerberos proporciona un servidor de autenticación central- tas claves han sido fı́sicamente distribuidas o en alguna otra
izada, cuya función es la autenticación de usuarios a servi- forma segura.
dores y de servidores a usuarios. Kerberos se basa exclusiva-
mente en el cifrado simétrico, sin hacer uso de la encriptación Una de Autenticación más segura de Dialogo
de clave pública.
Aunque el anterior escenario resuelve algunos de los prob-
2.1 Motivación lemas de autenticación en un entorno de red abierta, los
Hoy en dı́a, el escenario más común es una arquitectura dis- problemas persisten. En primer lugar, nos gustarı́a mini-
tribuida que consiste en estaciones de trabajo de usuario mizar el número de veces que un usuario tiene que intro-
dedicadas (clientes) y servidores distribuidos o centraliza- ducir una contraseña. Podemos mejorar las cosas diciendo
dos. En este ambiente, se pueden avizorar tres enfoques de que los tickets son reutilizables. Sin embargo, bajo este es-
seguridad: quema permanece el caso en el que un usuario necesitarı́a un
nuevo ticket para cada servicio diferente. El segundo prob-
lema es que el escenario anterior involucra una transmisión
• Confiar en cada estación de trabajo cliente individual en texto plano de la contraseña. Un ”escucha” podrı́a cap-
para asegurar la identidad de sus usuarios y confiar turar la contraseña y utilizar cualquier servicio accesible a
en cada servidor para hacer cumplir una polı́tica de la vı́ctima.
seguridad basada en la identificación de usuario (ID).
• Pedir a los sistemas cliente autenticarse con los servi- Para resolver estos problemas adicionales, se introduce un
dores, pero confiar en el sistema del cliente lo con- esquema para evitar contraseñas en texto plano y un nuevo
cerniente a la identidad de sus usuarios. servidor, conocido como el servidor de otorgamiento de tick-
ets (TGS). El servicio nuevo, TGS, emite tickets a los usuar-
• Pedir que el usuario provea su identidad para cada ser- ios que han sido autenticados para AS.
vicio invocado. También requieren que los servidores
demuestren su identidad a los clientes. La versión 4 de Autenticación de Dialogo

Aunque el precedente escenario mejora la seguridad en com-

Kerberos soporta este tercer enfoque. Kerberos presupone paración con el primer intento, dos problemas adicionales
una arquitectura cliente/servidor distribuida y emplea a uno aun están presentes. El centro del primer problema es el
o más servidores Kerberos para proporcionar un servicio de tiempo de vida asociado al TGT. Si el tiempo de vida es muy
autenticación. corto, entonces se le pedirá repetidamente una contraseña al
usuario. Si el tiempo de vida es largo, entonces un oponente
El primer informe publicado sobre Kerberos lista los sigu- tiene una mayor oportunidad para la replicación.
ientes requerimientos:
El segundo problema es que puede ser que los servidores se
autentiquen a los usuarios. Sin tal autenticación, un opo-
• Seguro
nente pdrı́a sabotear la configuración para que los mensajes
• Confiable a un servidor se dirijan a otra ubicación.(Tabla 1)

• Transparente
• Escalable

Para apoyar estos requerimientos, el plan general de Ker- Kerberos Reinos y Kerberos múltiples
beros es el de un servicio de autenticación de un tercer par-
ticipante de confianza (a trusted third-party) que utiliza un Un ambiente de servicio completo de Kerberos consiste de
protocolo basado en el propuesto por Needham y Schroeder. un servidor Kerberos, un número de clientes, y una serie de
servidores de aplicaciones requiere lo siguiente:
2.2 Kerberos Versión 4
La versión 4 de Kerberos hace uso de DES, en un protocolo • El servidor de Kerberos debe tener el identificador de
bastante elaborado, para prestar el servicio de autenticación usuario y contraseñas con algoritmo hash de todos los
usuarios que participan en su base de datos.
Una Autenticación Simple de Dialogo
• El servidor de Kerberos deben compartir una clave sec-
En un entorno de red sin protección, cualquier cliente puede reta con cada servidor. Todos los servidores están reg-
solicitar a cualquier servidor un servicio. El riesgo de se- istrados con el servidor de Kerberos. Un territorio de
guridad obvio es el de la suplantación. Para contrarrestar Kerberos es un conjunto de nodos administrados que
esta amenaza, los servidores deben ser capaces de confirmar comparten la misma base de datos Kerberos. Esta
 Mensaje 1 Cliente solicita ticket de concesión de
ticket a.- Autenticación del Servicio de Intercambio
IDC Le dice al AS la identidad del usuario Mensaje 3 El cliente solicita el ticket de concesión
de este cliente de servicio.
IDtgs Le dice al AS que el usuario solicita ac- IDV Le dice al TGS que el usuario solicita
ceso al TGS acceso al servidor V.
TS1 Permite que AS verifique que el reloj del Tickettgs Asegura a TGS que este usuario ha sido
cliente este sincronizado con el de AS autenticado por AS.
Mensaje 2 AS regresa el ticket de concesión de AutenticadorC Generado por el cliente para validar el
ticket ticket.
KC El cifrado está basado en la contraseña Mensaje 4 TGS retorna el ticket de concesión de
del usuario, permitiendo a AS y al servicio.
cliente verificar la contraseña y prote- Kc.tgs Clave compartida solo por C y TGS pro-
giendo el contenido del mensaje. tege el contenido del mensaje.
Kc.tgs Copia de la clave de sesión accesible Kcv Copia de la clave de sesión accesible al
al cliente creado por AS para permi- cliente creado por TGS para permitir el
tir el intercambio seguro entre el cliente intercambio seguro entre cliente y servi-
y TGS sin necesidad de que compartan dor sin que tengan que compartir una
una clave permanente. clave permanente.
IDtgs Confirma que este ticket es para el TGS. IDV Confirma que este ticket es para el servi-
TS2 Informa al cliente del tiempo en que el dor V.
ticket fue emitido. TS4 Informa al cliente del tiempo en que este
Tiempo de vida2 Informa al cliente del tiempo de vida del ticket fue emitido.
ticket. TicketV Ticket a ser usado por el cliente para
Tickettgs Ticket a ser usado por el cliente para acceder al servidor V.
acceder al TGS. Tickettgs Copia de la clave de sesión accesible a
TGS utilizada para descifrar el autenti-
Table 1: Justificación para los elementos del Proto- cador, con lo que se autentica billetes
colo Kerberos Versión 4(1) ktgs boleto está cifrado con la clave que sólo
conocen AS y TGS, para evitar la ma-
nipulación
reside en el sistema informático Kerberos maestro, el
Kc,tgs Copia de la clave de sesión accesible a
cual debe mantenerse en una habitación fı́sicamente
TGS utilizada para descifrar el autenti-
seguro. Sin embargo, todos los cambios a la base de
cador, con lo que autenticar billetes
datos debe hacerse en el sistema informático principal.
IDc Indica que el verdadero dueño de este
Cada director de Kerberos se identifica por su nom-
billete
bre principal (constará de tres partes: un servicio o
ADc Evita el uso de ticket de estación de tra-
un nombre de usuario, un nombre de instancia, y un
bajo que no sea uno que inicialmente
nombre de dominio).
pidió el billete
• El servidor de Kerberos en cada ámbito de la interoper- IDtgs Asegura servidor que lo ha descifrado
abilidad comparte una clave secreta con el servidor en correctamente billete
el otro reino. Los dos servidores Kerberos se registran TS2 Informa TGS de tiempo este billete fue
entre sı́. emitido
Tiempo de vida2 billete de reproducción después de que
ha caducado
Con estas reglas básicas en su lugar, podemos describir el
Authenticatorc Asegura que el presentador TGS billete
mecanismo de la siguiente manera: Si un usuario desea el
es el mismo que el cliente para el que
servicio en un servidor en otro reino necesita un billete para
el billete se le haya expedido vida muy
ese servidor. Cliente del usuario sigue los procedimientos
corta para evitar la reproducción
habituales para acceder al TGS local y solicita una nueva
Kc,tgs Autenticador se cifra con la clave que
TGT de TGS remoto (TGS en otro ámbito).
sólo conocen los clientes y TGS, para
evitar la manipulación
2.3 Kerberos Versión 5 IDc Debe coincidir con ID vale para auten-
Diferencias entre las versiones 4 y 5 ticar entradas
ADc Debe coincidir con la dirección en el bil-
Versión 5 está diseñado para hacer frente a las limitaciones lete vale para autenticar
de versión 4 en dos áreas: las deficiencias del medio ambiente TS3 Informa TGS de este tiempo se generó
y deficiencias técnicas. autenticador

1. La dependencia del sistema de cifrado: La versión 4 Table 2: Justificación para los elementos del Proto-
requiere el uso de DES. En la versión 5, el texto cifrado colo Kerberos Versión 4(2)
es etiquetada con un identificador de tipo de cifrado
 para que cualquiera de las técnicas de cifrado puede
ser utilizado.
2. La dependencia del protocolo de Internet: la versión 4
requiere el uso de Internet Protocol (IP). Otros tipos
de direcciones, tales como la dirección de red ISO, no
b.- Intercambio de concesión de vales se alojan. La versión 5 de direcciones de red son etique-
Message 5 Solicitudes de servicio de cliente tados con el tipo y longitud, lo que permite cualquier
Ticketv Asegura servidor que este usuario ha tipo de direcciones de red que se utilizará.
sido autenticado por AS 3. Mensaje de orden de bytes: En la versión 4, el remi-
Authenticatorc Generado por el cliente para validar en- tente de un mensaje emplea una orden de bytes de
tradas su propia elección y las etiquetas el mensaje a por lo
Message 6 autenticación opcional de servidor al menos indican importantes byte en la dirección más
cliente baja o byte más significativo en la dirección más baja.
Kc,v Asegura C que este mensaje es de V En la versión 5, todas las estructuras se definen me-
TS5 + 1 Asegura C que esto no es una repetición diante las páginas de ”Abstract Syntax Notation One
de una respuesta de edad (ASN.1) y Basic Encoding Rules (BER), que propor-
Ticketv Reutilizables forma que el cliente no cionan un byte sin ambigüedades el pedido.
necesita solicitar un nuevo ticket de
TGS para cada acceso al mismo servi- 4. Venta de entradas de por vida: los valores de por vida
dor en la versión 4 se codifican en una cantidad de 8-bits
Kv boletos que está cifrada con la clave en unidades de cinco minutos. Por lo tanto, el tiempo
conocida sólo por TGS y el servidor, de vida máximo que se puede expresar es de 28 x 5
para evitar la manipulación = 1280 minutos, o un poco más de 21 horas. En la
Kc,v Copia de la clave de sesión accesible al versión 5, los boletos incluyen una hora de inicio y
cliente, que se utiliza para descifrar el hora de finalización explı́cita, lo que permite entradas
autenticador, con lo que autenticar bil- con duraciones arbitrario.
letes 5. Transmisión de autenticación: la versión 4 no permite
IDC Indica que el verdadero dueño de este credenciales emitidas a un cliente que se transmitirá a
billete otro host y utilizada por algún otro cliente. La versión
ADc Evita el uso de ticket de estación de tra- 5 ofrece esta capacidad.
bajo que no sea uno que inicialmente
pidió el billete 6. Autenticación de interregno: En la versión 4, la inter-
IDv Asegura servidor que lo ha descifrado operabilidad entre los reinos N requiere del orden de
correctamente billete N2 Kerberos a Kerberos relaciones, como se describió
TS4 Informa servidor de tiempo de este bil- anteriormente. Versión 5 es compatible con un método
lete fue emitido que requiere pocas relaciones, tal como se describe en
Tiempo de vida4 billete de reproducción después de Evita breve.
ha caducado
Authenticatorc Asegura que el presentador servidor bil-
Aparte de estas limitaciones ambientales, existen deficien-
lete es el mismo que el cliente para el
cias técnicas en la versión 4 del protocolo en sı́ son las sigu-
que el billete fue emitido; tiene vida
ientes:
muy corta para evitar la reproducción
Kc,v Autenticador se cifra con la clave que
sólo conocen cliente y servidor, para evi- 1. Billetes de doble cifrado proporcionado a los clientes
tar la manipulación se cifran en dos ocasiones, una vez con la clave secreta
IDc Debe coincidir con ID vale para auten- del servidor de destino y luego de nuevo con una clave
ticar entradas secreta conocida por el cliente. El segundo cifrado no
ADc Debe coincidir con la dirección en el bil- es necesario y es computacionalmente desperdicio.
lete vale para autenticar
TS5 Informa servidor de tiempo que esto se 2. PCBC cifrado: cifrado en la versión 4 hace uso de un
generó autenticador modo no estándar de DES conocido como cifrado de
c.- El cliente / servidor de Exchange de autenticación multiplicación de encadenamiento de bloques (PCBC).
Se ha demostrado que este modo es vulnerable a un
Table 3: Justificación para los elementos del Proto- ataque con el intercambio de texto cifrado bloques. La
colo Kerberos Versión 4(3) versión 5 proporciona mecanismos explı́citos integri-
dad, lo que permite la norma modo CBC que se utiliza
para el cifrado.
3. Las claves de sesión: Cada boleto incluye una clave de
sesión que se utiliza por el cliente para cifrar el auten-
ticador envı́a al servicio asociado a la entrada. Sin em-
bargo, debido a que el mismo billete se puede utilizar
 varias veces para obtener los servicios de un servidor INICIAL Este billete fue emitido mediante el proto-
en particular, se corre el riesgo de que un oponente re- colo AS y no se han concedido sobre la base
producir mensajes serán desde una sesión de edad para de un cupón de obtención.
el cliente o el servidor. En la versión 5, es posible que PRE-AUTHENT Durante la autenticación inicial, el cliente
un cliente y el servidor para negociar una clave sub- se ha autenticado por el KDC antes de que
sesión, que se va a utilizar sólo para esa conexión una. un billete fuera emitido.
Un nuevo acceso por parte del cliente se traducirı́a en HW-AUTHENT El protocolo empleado para la autenti-
la utilización de una clave subsesión nuevo. cación inicial exigido el uso de hardware es-
pera de ser poseı́da exclusivamente por el
4. Ataques Contraseña: Ambas versiones son vulnerables nombre del cliente.
a un ataque de contraseña. El mensaje de la AS para RENOVABLES Le dice al TGS que este billete se puede uti-
el cliente incluye material cifrado con una clave basada lizar para obtener un pasaje de sustitución,
en oponente del cliente password. que vence en una fecha posterior.
MAY-POSTDATE Le dice al TGS que un billete con fecha pos-
La versión 5 de diálogo de autentificación terior podrá expedirse sobre la base de este
TGT.
En primer lugar, considerar el cambio de servicio de aut- POSTDATED Indica que este ticket ha sido con fecha pos-
enticación. Mensaje (1) es una solicitud del cliente para un terior, el servidor final puede comprobar el
TGT. Al igual que antes, incluye el ID del usuario y el TGS. campo de authtime para ver cuándo se pro-
Los siguientes elementos se agregan otras nuevas: dujo la autenticación inicial.
INVALID Este billete no es válido y debe ser validado
por el KDC antes de su uso.
• Dominio: Indica el ámbito de usuario
PROXIABLE Le dice al TGS que un nuevo ticket que con-
• Opciones: Se utiliza para pedir que ciertos pabellones cede un servicio con una dirección de red
fijado en el billete volvió. diferente puede ser emitidos con base en el
billete presentado.
• Horario: Usado por el cliente para solicitar los ajustes PROXY Indica que este ticket es un proxy.
de hora siguientes en el billete:
FORWARDABLE Le dice al TGS que un nuevo billete de con-
– a partir de: la hora de inicio deseada para el bo- cesión de vales con una dirección de red
leto solicitado diferente puede ser emitido con base en este
– hasta: la fecha de caducidad solicitado para el TGT.
boleto solicitado FORWARDED Indica que este ticket ha sido o bien remitir
o se haya expedido sobre la base de aut-
– rtime: pidió renovar a tiempo hasta
enticación sobre un billete transmitido de
• Nonce: Un valor al azar que se repite en el mensaje concesión de vales.
(2) para asegurar que la respuesta es fresca y no ha
sido repetido por un adversario y dicho valor solo se Table 4: Banderas, versión 5 de Kerberos
usa una vez.

• Número de orden: un campo opcional que especifica

Mensaje (2) devuelve un TGT, identificando la información el número de secuencia empezando a utilizar el servi-
para el cliente, y el bloque de una cifra con la clave de cifrado dor para los mensajes enviados al cliente durante este
basado en la contraseña del usuario. El ticket incluye la perı́odo de sesiones.
clave de sesión, la identificación de la información para el
cliente, los valores de tiempo solicitado, y los indicadores
que reflejan el estado de esta entrada y las opciones solic- Boleto Banderas
itadas. Vemos que el mensaje (3) para las dos versiones
incluye un autenticador, el boleto, y el nombre del servicio El campo de banderas incluido en los boletos en la versión
solicitado. Además, la versión 5 incluye la hora solicitada y 5 soporta la funcionalidad ampliada en comparación con la
las opciones para el boleto y un nonce. Mensaje (4) tiene disponible en la versión( Tabla 4).
la misma estructura que mensaje (2), devolviendo un billete
más información que necesita el cliente, esta última cifra con
la clave de sesión compartida por el cliente y el TGS. Por
último, para el cliente y el intercambio de autenticación de
servidor, aparecen varias nuevas caracterı́sticas en la versión.
En el mensaje de (5), el cliente puede solicitar como una op- La bandera inicial indica que este billete fue emitido por el
ción que se requiere la autenticación mutua. El autenticador AS, no por el TGS. Cuando un cliente solicita un vale de
incluye varios nuevos campos de la siguiente manera: servicio de concesión de la TGS, presenta un cupón de ob-
tención obtenida de la AS. En la versión 4, ésta era la única
manera de obtener un vale de servicio de concesión. La
• Subclave: La elección del cliente para una clave de versión 5 proporciona la capacidad adicional que el cliente
cifrado que se utiliza para proteger esta sesión de la puede obtener un vale de servicio que otorgan directamente
aplicación especı́fica. Si este campo se omite, la clave de la AS. La utilidad de esto es el siguiente: Un servidor,
de sesión del billete (Kc, v) se utiliza. como un servidor de cambio de contraseña, tal vez desee
saber que la contraseña del cliente se puso a prueba recien- 3. SERVICIO DE AUTENTIFICACIÓN X.509
temente. UIT-T X.509 Recomendación forma parte de la serie de re-
comendaciones X.500 que definen un servicio de directorio.
La bandera PRE-AUTHENT, si se define, indica que cuando El directorio es, en efecto, un servidor distribuido o conjunto
el AS recibido la solicitud inicial [mensaje (1)], que autentica de servidores que mantiene una base de datos de información
al cliente antes de emitir un billete. Cuando un usuario sobre los usuarios. La información incluye una asignación
quiere obtener un billete, tiene que enviar al AS un bloque de nombre de usuario a la dirección de red, ası́ como otros
que contiene un factor de confusión autenticación previa al atributos e información sobre los usuarios.
azar, un número de versión y una marca de hora, codificado
en clave basada en contraseña del cliente. El AS descifra el X.509 define un marco para la prestación de servicios de
bloque y no enviará un cupón de obtención de subir a menos autenticación por el directorio X.500 a sus usuarios. El di-
que la marca de tiempo en el bloque de preautenticación está rectorio puede servir como un repositorio de certificados de
dentro del tiempo permitido sesgo (intervalo de tiempo para clave pública. Cada certificado contiene la clave pública de
dar cuenta de la deriva del reloj y retrasos en la red). Otra un usuario y se firma con la clave privada de una entidad
posibilidad es el uso de una tarjeta inteligente que genera certificadora de confianza. Además, X.509 define protocolos
continuamente el cambio de claves que se incluyen en los alternativos de autenticación basado en el uso de certificados
mensajes preauthenticated. Las contraseñas generadas por de clave pública.
la tarjeta puede estar basada en la contraseña de un usuario,
pero que sean transformados mediante la tarjeta para que, X.509 es un estándar importante porque la estructura de
en efecto, las contraseñas se utilizan arbitraria. Esto impide certificados y protocolos de autenticación definido en X.509
que un ataque basado en contraseñas fáciles de adivinar. se utilizan en una variedad de contextos. Por ejemplo, el for-
mato de certificado X.509 se utiliza en S / MIME, Seguridad
Cuando un billete tiene una larga vida, existe la posibilidad IP, Y SSL / TLS y SET.
para que pueda ser robados y utilizados por un contrario du-
rante un perı́odo considerable. Si un corto tiempo de vida X.509 inicialmente expedido en 1988. La norma fue revisada
se utiliza para disminuir la amenaza, a continuación, gastos posteriormente para hacer frente a algunas de las preocupa-
generales relacionados con la adquisición nuevos boletos. En ciones de seguridad; Una recomendación revisada se publicó
el caso de un cupón de obtención, el cliente tendrı́a que alma- en 1993. Una tercera versión se publicó en 1995 y revisada
cenar la clave secreta del usuario, que es claramente riesgoso, en 2000.
o varias veces pedir al usuario una contraseña. Un esquema
de compromiso es el uso de billetes de renovables. Un bo- X.509 se basa en el uso de la criptografı́a de clave pública
leto con el indicador RENOVABLES incluye dos fechas de y firmas digitales. La norma no impone el uso de un algo-
caducidad: una para este billete especı́fico y que es el último ritmo especı́fico, pero recomienda RSA. El esquema de firma
valor permitido para un tiempo de caducidad. La ventaja digital se supone que requieren el uso de una función hash.
de este mecanismo es que la TGS puede negarse a renovar Una vez más, la norma no determina un algoritmo de hash
un billete reportado como robado. especı́fica. La recomendación de 1988 incluyó la descripción
de un algoritmo de hash recomendadas; este algoritmo ha
Un cliente puede solicitar que el de proporcionar un cupón de sido demostrado que es inseguro y fue eliminado de la re-
obtención con el indicador MAY-son posteriores. El cliente comendación de 1993.
puede utilizar esta entrada para solicitar un ticket que se
marca como fecha adelantada y no válidos de la TGS. Poste- Figura 1 ilustra la generación de un certificado de clave
riormente, el cliente puede presentar el billete con fecha pos- pública.
terior para su validación.Este esquema puede ser útil para
ejecutar un trabajo por lotes de largo en un servidor que Certificados
requiere un boleto periódicamente. El cliente puede obtener
un número de entradas para esta sesión a la vez, con una El corazón del sistema X.509 es el certificado de clave pública
propagación de salida los valores de tiempo. Todos menos el asociado a cada usuario. Estos certificados de usuario se
primer boleto son inicialmente válido. Cuando la ejecución supone que son creados por alguna autoridad de certificación
alcanza un momento en que un nuevo billete es necesario, el de confianza (CA) y se coloca en el directorio de la entidad
cliente puede obtener el boleto debidamente validado. Con emisora o por el usuario. El servidor de directorio en sı́
este enfoque, el cliente no tiene que utilizar en repetidas mismo no es responsable de la creación de claves públicas o
ocasiones su TGT para obtener un ticket que concede un para la función de certificación, sino que se limita a estable-
servicio. cer una zona de fácil acceso para los usuarios que obtienen
los certificados.
El concepto de proxy es un caso limitado del procedimiento
de transmisión más potente. Si un billete se fija con la ban- La Figura 2 muestra el formato general de un certificado,
dera remitible, un TGS puede emitir al solicitante un TGT que incluye los siguientes elementos:
con una dirección de red diferente y el conjunto de aban-
deramiento enviará. Este ticket puede ser presentada en un
• Versión: Diferencia entre las sucesivas versiones del
TGS remoto. Esta capacidad permite a un cliente para ac-
formato del certificado, el valor por defecto es la ver-
ceder a un servidor en otro reino, sin necesidad de que cada
sión 1. Si el Emisor Unique Identifier o Identificador
Kerberos mantener una clave secreta con los servidores Ker-
único Asunto están presentes, el valor debe ser la ver-
beros en todos los ámbitos otros.
sión 2. Si una o más extensiones están presentes, la
 Figure 2: X.509 Formatos

Figure 1: Certificado de clave pública Uso Los campos de identificador único se añadieron en la versión
2 para manejar la posible reutilización de la materia y / o
nombres de emisor a través del tiempo. Estos campos se
versión debe ser la versión 3. usan raramente.
• De número de serie: Valor entero, único en la CA
emisora, que esta inequı́vocamente asociado con este El estándar usa la notación siguiente para definir un certifi-
certificado. cado:

• Firma identificadora del algoritmo: El algoritmo uti- CA << A >> = (V CA, SN, AI, CA, TA, Un Ap,)
lizado para firmar el certificado, junto con cualquier
parámetro asociado. Debido a que esta información se donde
repite en el ámbito de la firma en el final del certificado,
este campo tiene poca, si los hubiere, de utilidad. Y << X >> = El certificado de usuario X emitidos por la
autoridad de certificación Y
• Nombre del emisor: nombre X.500 de la CA que ha
creado y firmado el presente certificado. Y (I) = La firma del I por Y. Se trata de que con un código
• Periodo de validez: Consiste en dos fechas: la primera de encryptedhash anexa
y última vez que el certificado es válido.
Los CA firman el certificado con su clave privada. Si la
• Asignatura: El nombre del usuario al que se refiere el clave pública correspondiente se conoce a un usuario, a con-
presente permiso. Es decir, este certificado certifica tinuación, que el usuario puede comprobar que un certificado
la clave pública del sujeto que posee la clave privada firmado por la CA es válido.
correspondiente.
La obtención de un Certificado de usuario
• Información de clave pública del sujeto: la clave pública
del sujeto, además de un identificador del algoritmo
Los certificados de usuario generados por una CA tienen las
para que esta clave se va a utilizar, junto con cualquier
siguientes caracterı́sticas:
parámetro asociado.
• Identificador único de emisor: Un campo de bits de
• Cualquier usuario con acceso a la clave pública de la
cadena opcional que permite identificar de forma única
entidad emisora puede verificar la clave pública del
la CA emisora en el caso de que el nombre X.500 ha
usuario que se ha certificado.
sido reutilizados para diferentes entidades.
• Ninguna de las partes distintas de la autoridad de cer-
• Identificador único de Asunto: Un campo de bits ca-
tificación puede modificar el certificado sin que esto
dena opcional sirve para identificar unı́vocamente al
sea detectado.
sujeto en caso de que el nombre X.500 ha sido reuti-
lizados para diferentes entidades.
• Extensiones: Un conjunto de uno o más campos de Debido a que los certificados son infalsificables, se pueden
extensión. Las Extensiones se añadieron en la versión colocar en un directorio sin la necesidad de que el directorio
3 y se describen más adelante en esta sección. que haga esfuerzos especiales para protegerlos.

• Firma: Cubre todos los otros campos de dicho certifi- Si todos los usuarios se suscriben a la misma CA, entonces
cado, que contiene el código hash de los otros campos, no hay una confianza común en la AC. Todos los certificados
cifrada con la clave privada de la CA. Este campo in- de usuario se pueden colocar en el directorio para el acceso
cluye el algoritmo identificador de firma. de todos los usuarios. Además, un usuario puede transmitir
su certificado directamente a otros usuarios. En cualquier
caso, una vez que B se encuentra en posesión de un certi-
ficado de A, B tiene la confianza de que los mensajes son
encriptados con la clave pública de A, están a salvo de es-
cuchas y que los mensajes firmados con la clave privada de
A son infalsificables.

Si hay una gran comunidad de usuarios, puede que no sea

práctico para todos los usuarios suscribirse a la misma CA.
Debido a que es la CA que firma certificados, cada usuario
participante debe tener una copia de su propia clave pública
de la CA para verificar las firmas. Esta clave pública debe
ser facilitada a cada usuario en un seguro totalmente (con
respecto a la integridad y autenticidad) camino para que
el usuario tenga la confianza en los certificados correspon-
dientes. Ası́, con muchos usuarios, puede ser más práctico
para que haya un número de AC, cada uno de los cuales con
seguridad ofrece su clave pública para algunas fracciones de
los usuarios. Ahora supongamos que A ha obtenido un certi-
ficado de entidad emisora de certificados X1 y B ha obtenido Figure 3: X.509 Jerarquı́a: Un Ejemplo Hipotético
un certificado de CA X2. Si A no sabe con seguridad la clave
pública de X2, entonces el certificado de B, emitido por el
X2, es inútil para A. Un certificado A puede leer B, pero Figura 3, Tomado de X.509, es un ejemplo de tal jerarquı́a.
A no puede comprobar la firma. Sin embargo, si las dos Los cı́rculos conectados indicar su relación jerárquica entre
entidades emisoras han intercambiado de forma segura sus las entidades emisoras de certificados, las cajas asociadas in-
propias llaves públicas, el siguiente procedimiento le permi- dican los certificados mantenidos en el directorio para cada
tirá obtener una clave pública de B: entrada de CA. La entrada de directorio para cada CA in-
cluye dos tipos de certificados:
1. A obtiene, por el directorio, el certificado de X2 fir-
mado por X1. Dado que A conoce con seguridad la
• Certificados de avance: Certificados de X generado por
clave pública X1, A pueda obtener una clave pública
otras CA
de X2 de su certificado y verificar por medios de la
firma en el certificado de X1. • Certificados Reverso: los certificados generados por X
2. A continuación, se remonta al directorio y obtiene el que son los certificados de otras CA
certificado de B firmado por X2 Debido a que A tiene
ahora una copia de la clave pública de confianza X2,
En este ejemplo, el usuario A puede adquirir los siguientes
A puede verificar la firma y segura de obtener la clave
certificados desde el directorio para establecer una ruta de
pública de B.
certificación para B: X << W >> W << V >> V <<
Y >><< Z >> Z << B >>
A ha utilizado una cadena de certificados para obtener la
clave pública de B.. En la notación de X.509, esta cadena Cuando A ha obtenido estos certificados, se puede desen-
se expresa como X1 << X2 >> X2 << B >> volver la ruta de certificación en orden a recuperar una copia
de confianza de la clave pública de B. Con esta clave pública,
De la misma manera, B puede obtener una clave pública con A puede enviar mensajes cifrados a B. Si A desea recibir
la cadena inversa: X2 << X1 >> X1 << A >> mensajes cifrados devueltos de B, o para firmar los men-
sajes enviados a B, entonces B requerirá una clave pública
Este esquema no tiene por qué limitarse a una cadena de de A, la cual se puede obtener de la ruta de certificación
dos certificados. Un camino de longitud arbitraria de las siguiente: Z << Y >> Y << V >> V << W >> W <<
CA se puede seguir para producir una cadena. Una cadena X >> X << A >>
con n elementos se expresarı́a como X1 << X2 >> X2 <<
X3 >> ...XN < B ><> B puede obtener este conjunto de certificados del directorio,
o A puede proporcionar a ellos como parte de su mensaje
En este caso, cada par de entidades emisoras de la cadena inicial a B.
(Xi, Xi +1) debe haber creado los certificados para cada
otro. Revocación de Certificados

Todos estos certificados de CAs por Cas entidades emiso- Recuerde del La figura 2 que cada certificado incluye un
ras de certificados necesitan aparecer en el directorio, y el perı́odo de validez, al igual que una tarjeta de crédito. Nor-
usuario tiene que saber cómo están relacionadas a seguir un malmente, un nuevo certificado es emitido justo antes de la
camino al certificado de clave pública de otro usuario. X.509 expiración de la anterior. Además, puede ser conveniente en
sugiere que las CA se disponen en una jerarquı́a de modo que ocasiones para revocar un certificado antes de su expiración,
la navegación es sencilla. por alguna de las siguientes razones:
 1. Clave privada del usuario se supone que es compro-
metida.
2. El usuario ya no está certificada por esta CA.
3. Certificado de la CA se supone que se vea compro-
metida.

Cada CA debe mantener una lista compuesta por todos los

revocados, pero no los certificados vencidos emitidos por
dicha CA, incluyendo tanto los entregados a los usuarios
y otras entidades emisoras de certificados. Estas listas tam-
bién deben ser colocadas en el directorio.

Cada lista de certificados revocados (CRL) publicado en el

directorio es firmado por parte del emisor e incluye (Figura 2(b)
Nombre del emisor, la fecha de creación de la lista, la fecha
de la CRL próxima está programada para ser emitida, y una
entrada para cada revocó certificado. Cada entrada contiene
el número de serie de un certificado y la fecha de la revo-
cación de ese certificado. Porque los números de orden son
únicos dentro de una CA, el número de orden es suficiente
para identificar el certificado.
Figure 4: X.509 Procedimientos de autenticación
Cuando un usuario recibe un certificado en un mensaje, el fuerte
usuario debe determinar si el certificado ha sido revocado.
El usuario podrá revisar el directorio cada vez que se recibe
un certificado. Para evitar los retrasos (y los posibles costos) privada de A. La marca de tiempo consiste en un tiempo de
asociados a las búsquedas de directorio, es probable que los generación opcional y un tiempo de caducidad. Esto evita
usuarios se mantienen una caché local de certificados y listas que haya retrasó en la entrega de mensajes. El nonce se
de certificados revocados. puede utilizar para detectar ataques de repetición. El valor
nonce debe ser único en la fecha de caducidad del mensaje.
Procedimientos de autenticación Por lo tanto, B puede almacenar el nonce hasta que expire
y rechazar cualquier mensaje nuevo con el mismo nonce.
X.509 también incluye tres procedimientos de autenticación
alternativos que se destinen al consumo a través de una var- Para la autenticación pura, el mensaje sólo se usa para pre-
iedad de aplicaciones. Todos estos procedimientos hacen uso sentar las credenciales a B. El mensaje también puede incluir
de la firma de clave pública. Se supone que las dos partes información que se desea transmitir. Esta información, sgn-
se conocen la clave pública, ya sea mediante la obtención Data, está incluido en el ámbito de la firma, que garantice
de sus respectivos certificados en el directorio o por que el su autenticidad e integridad. El mensaje también puede ser
certificado está incluido en el mensaje inicial de cada lado. usados para transmitir una clave de sesión para B, cifra con
la clave pública de B.
Figura 4ilustra los tres procedimientos.
Autenticación de dos vı́as
Autenticación de una vı́a
Además de los tres elementos que acabamos de mencionar,
Una forma de autenticación consiste en una única transferen- la autenticación en ambos sentidos establece los siguientes
cia de información de un usuario (A) a otro (B), y establece elementos:
lo siguiente:

1. La identidad de B y que el mensaje de respuesta se ha

1. La identidad de A y que el mensaje fue generado por generado por B
A
2. Que el mensaje estaba destinado a un
2. Que el mensaje estaba destinado a B
3. La integridad y la originalidad (que no se ha enviado 3. La integridad y la originalidad de la respuesta
en múltiples ocasiones) del mensaje
Dos vı́as de autenticación por tanto, permiten a ambas partes
Tenga en cuenta que sólo la identidad de la entidad se veri- en una comunicación a verificar la identidad del otro.
fica en iniciar este proceso, no el de la entidad de respuesta.
El mensaje de respuesta incluye el nonce de la A, para val-
Como mı́nimo, el mensaje incluye una marca de tiempo tA, idar la respuesta. También incluye una marca de tiempo y
un rA nonce y la identidad de B y se firma con la clave nonce generado por B. Al igual que antes, el mensaje puede
incluir información adicional firmado y una clave de sesión los atributos del emisor, y las limitaciones de certificación
cifrada con la clave pública de A. camino.

Autenticación de tres vı́as Clave y la polı́tica informativa

En la autenticación de tres vı́as, un mensaje final de A a Estas extensiones de transmitir información adicional sobre
B está incluido, el cual contiene una copia firmada de la el tema y las claves emisor, además de indicadores de la
RB nonce. La intención de este diseño es que las mar- polı́tica de certificado. Una polı́tica de certificación es un
cas de tiempo No necesita ser controlado: Debido a que llamado conjunto de reglas que indica la aplicabilidad de
tanto nonces se hacen eco de vuelta por el otro lado, cada un certificado a una comunidad en particular y / o clase de
lado puede comprobar el nonce devuelto para detectar los aplicación con requisitos de seguridad común. Por ejemplo,
ataques de repetición. Este enfoque es necesario cuando se una polı́tica podrı́a ser aplicable a la autenticación de inter-
sincronizan los relojes no están disponibles. cambio electrónico de datos (EDI) las operaciones para el
comercio de mercancı́as dentro de un rango de precios.
X.509 versión 3
Esta área incluye las siguientes:
El formato X.509 versión 2 no transmite toda la información
que el diseño reciente y la experiencia en implementación
ha demostrado que es necesario. [FORD95] Enumera los • Identificador de clave Autorizada: Identifica la clave
siguientes requisitos no cumplidos con la versión 2: pública que se utilizarán para verificar la firma de este
certificado o CRL. Permite distintas claves de la misma
CA que ser diferenciadas. Uno de los usos de este
1. El campo Asunto no es suficiente para transmitir la
campo es manejar la actualización del par clave de CA
identidad del propietario de una clave a un usuario de
clave pública. nombres X.509 puede ser relativamente • Asunto identificador clave: Identifica la clave pública
corta y carente de datos de identificación obvio que certificada. Útil para la actualización del par de claves
puede ser necesaria para el usuario. en cuestión. Además, un sujeto puede tener varios
2. El campo Asunto también es insuficiente para muchas pares de claves y, en consecuencia, los certificados dis-
aplicaciones, que por lo general reconocen entidades tintos para diferentes propósitos (por ejemplo, firma
por Internet una dirección de correo electrónico, una digital y cifrado acuerdo de claves).
dirección URL, o alguna otra identificación relacionada
con Internet. • Uso de claves: Indica una restricción impuesta sobre la
finalidad para la cual, y las polı́ticas en las que, puede
3. Es necesario indicar la información de seguridad común. ser la clave pública certificada utilizada. Puede indicar
Esto permite a una aplicación de seguridad o de la fun- uno o más de los siguientes: firma electrónica, no re-
ción, tales como IPSec, para relacionar un certificado pudio, la clave de cifrado, cifrado de datos, acuerdo de
X.509 a una determinada polı́tica. claves, de verificación de firmas en los certificados de
CA, CA de verificación de firma en las CRL.
4. Hay una necesidad de limitar el daño que puede derivarse
de una errónea o maliciosa CA, estableciendo restric- • El uso de la clave privada de las actividades: Indica el
ciones en la aplicabilidad de un certificado en particu- perı́odo de utilización de la clave privada correspondi-
lar. ente a la clave pública. Por lo general, la clave privada
5. Es importante ser capaz de identificar diferentes claves se utiliza durante un perı́odo diferente de la validez de
utilizadas por el mismo propietario en diferentes mo- la clave pública. Por ejemplo, con las claves de firma
mentos. Esta función admite la administración de digital, el perı́odo de uso de la clave de firma privada
claves del ciclo de vida, en particular, la capacidad suele ser más corto que el de la verificación de la clave
de actualizar los pares de claves para los usuarios y las pública.
entidades emisoras de manera regular o en circunstan-
cias excepcionales. • Certificado de polı́ticas: Los certificados podrán ser
utilizados en ambientes donde las polı́ticas se aplican
múltiples. Esta extensión de las listas de las polı́ticas
En lugar de continuar añadiendo campos a un formato fijo, que el certificado es reconocido como el apoyo, junto
los desarrolladores de Normas estimó que un enfoque más con información calificador optativo.
flexible que se necesitaba. Ası́, la versión 3 incluye una serie
de extensiones opcionales que pueden añadirse a la versión • Polı́tica de asignaciones: Sólo se usa con certificados
2 de formato. Cada extensión consiste en un identificador de entidades emisoras de certificados emitidos por enti-
de extensión, un indicador crı́tico, y un valor de extensión. dades emisoras de otros. asignaciones de Polı́tica per-
El indicador de criticidad indica si una extensión puede ser miten una CA emisora para indicar que una o más de
ignorado con seguridad. Si el indicador tiene un valor de que las polı́ticas del emisor se puede considerar equiv-
TRUE y una aplicación no reconoce la extensión, debe con- alente a otro de polı́tica utilizados en el dominio del
siderar el certificado como válido. tema de CA.

Las extensiones de certificado se dividen en tres categorı́as

principales: información clave y la polı́tica, los temas y Certificado de reserva y los atributos del Emisor
Estas extensiones de nombres alternativos, en otros formatos,
por un sujeto del certificado o el certificado del emisor y
pueden transmitir información adicional acerca del sujeto
del certificado, para aumentar la confianza de un certificado
de usuario de que el sujeto del certificado es una persona
o entidad particular. Por ejemplo, información como su di-
rección postal, la posición dentro de una corporación o una
imagen de la imagen puede ser requerida.

Los campos de extensión en este ámbito son las siguientes:

• Asunto alternativa nombre: Contiene uno o más nom-

bres alternativos, utilizando cualquiera de una var-
iedad de formas. Este campo es importante para respal-
dar ciertas aplicaciones, como correo electrónico, EDI, Figure 5: Modelo Arquitectónico PKIX
e IPSec, que pueden emplear sus formas propio nom-
bre.
• Emisor nombre alternativo: Contiene uno o varios nom- • Entidad final: Un término genérico utilizado para de-
bres alternativos, utilizando cualquiera de una var- notar a los usuarios finales, dispositivos (por ejemplo,
iedad de formas. servidores, routers), o cualquier otra entidad que se
pueden identificar en el ámbito objeto de un certificado
• Sin perjuicio de los atributos de directorio: Transmite de clave pública. Las entidades finales normalmente
cualquier directorio X.500 valores de los atributos de- consumen y / o apoyan los servicios relacionados de
seados para el tema de este certificado. PKI.
• Autoridad de certificación (CA): El emisor de los certi-
Certificación Limitaciones Camino ficados y (generalmente) las listas de revocación de cer-
tificados (CRL). Puede además soportar una variedad
Estas extensiones permiten limitar especificaciones que deben de funciones administrativas, aunque con frecuencia
incluirse en los certificados emitidos por CAs por otras CAs. son delegadas a una o varias autoridades de registro.
Las limitaciones pueden restringir los tipos de certificados
que pueden ser emitidas por el tema de la CA o que puedan • Autoridad de Registro (RA): Es un componente op-
producirse posteriormente en una cadena de certificación. cional que puede asumir una serie de funciones admin-
Los campos de extensión en este ámbito son las siguientes: istrativas de la entidad emisora. La AR se asocia a
menudo con el proceso de registro entidad final, pero
puede ayudar a un número de otras areas también.
• Limitaciones básicas: Indica si el sujeto puede actuar
como una entidad emisora. Si es ası́, una ruta de cer- • Emisor CRL: es un componente opcional al que un CA
tificación restricción de longitud que se indique. puede delegar la publicación de las CRL.
• Lmitaciones Nombre: Indica un espacio de nombres • Repositorio (almacén): Término genérico utilizado para
en el que todos los nombres de objeto de los certifica- denotar cualquier método para almacenar certificados
dos posteriores en una ruta de certificación debe estar y CRL para que puedan ser recuperados por entidades
ubicada. finales.
• Polı́tica de restricciones: limitaciones Especifica que
pueden exigir la identificación explı́cita polı́tica de cer- La relacion entre estos elementos se muestra en la Figura 5.
tificación o inhibir la asignación de directivas para el
resto de la ruta de certificación.
4.1 Funciones de Gestión PKIX
PKIX identifica una serie de funciones de gestión que nece-
4. INFRAESTRUCTURA DE CLAVE PÚBLICA sitan potencialmente ser soportados por los protocolos de
El Glosario de Seguridad de Internet define la infraestruc- gestión. Estos se indican en la Figura 5 y se incluyen las
tura de clave pública (PKI) como el conjunto de hardware, siguientes:
software, personas, polı́ticas, y procedimientos necesarios
para crear, gestionar, almacenar, distribuir y revocar cer-
tificados digitales basados en la criptografı́a asimétrica. El • Registro: Es el proceso mediante el cual un usuario
objetivo principal para el desarrollo de una PKI es permitir se da a conocer primero a una CA (directamente o a
una adquisición segura, práctico y eficaz de claves públi- través de un RA), antes de que ese CA expida un certi-
cas. El grupo de trabajo Ingenierı́a de Internet Task Force ficado o certificados para dicho usuario. La inscripción
(IETF) Infraestructura de clave pública X.509 (PKIX) ha comienza el proceso de inscribirse en una PKI. El Reg-
sido la fuerza impulsora detrás de la creación de un oficial istro suele implicar algunos procedimientos con o sin
(y general) modelo basado en X.509 que es adecuado para la conexión para la autenticación mutua. Normalmente,
implementación de una arquitectura basada en certificados se emite a la entidad final una o más claves secretas
de de Internet. Los elementos clave del modelo PKIX son: compartidas utilizadas para la autenticación siguiente.
 • Inicialización: Antes de que un sistema cliente puede existentes. A pesar de todas las funciones PKIX son sopor-
operar con seguridad, es necesaria la instalación de los tadas, las funciones no mapean todo en protocolos especı́fi-
materiales clave que tienen la relación adecuada con las cos de intercambio.
claves almacenadas en otras partes de la infraestruc-
tura. Por ejemplo, el cliente necesita estar inicializado 5. CONCLUSIONES
de manera segura con la clave pública y otro informa- 1. Kerberos es una solución para ciertos problemas de
ción segura de las CA de confianza, para ser utilizado seguridad de la red. Provee las herramientas de auten-
en la validación de rutas de certificado. ticación y criptografı́a reforzada a través de la red para
• Certificación: Este es el proceso en el que una CA ayudar a asegurar que los sistemas de información de
expide un certificado para una clave pública de usuario, una empresa o corporación están bien resguardados.
y devuelve ese certificado para el sistema cliente del 2. X.509 es un estándar UIT-T para infraestructuras de
usuario y / o envı́a dicho certificado en un repositorio. claves públicas (en inglés, Public Key Infrastructure
• Recuperación de par de claves: Los pares de claves se o PKI). X.509 especifica, entre otras cosas, formatos
pueden utilizar para soportar la creación y verificación estándar para certificados de claves públicas y un al-
de firma digital, cifrado y descifrado, o ambas cosas. goritmo de validación de la ruta de certificación.
Cuando un par de claves se utiliza para el cifrado / de-
scifrado, es importante establecer un mecanismo para
recuperar las claves de descifrado necesarias cuando el
acceso normal al material clave ya no es posible, de lo
contrario no será posible recuperar los datos cifrados.
La pérdida de acceso a la clave de descifrado puede ser
resultado de contraseñas o PIN olvidados, unidades de
disco dañado, el daño a tokens de hardware, y ası́ suce-
sivamente. El par de claves de recuperación permite
a las entidades finales restablecer su par de claves de
cifrado / descifrado de una copia de seguridad autor-
izada clave (por lo general, el CA que emitió el certifi-
cado de la entidad final).
• Actualización de par de Claves: Todos los pares de
claves necesitan ser actualizados con regularidad (es
decir, se reemplazarán por un nuevo par de claves) y un
nuevo certificado es emitido. La actualización es nece-
sario cuando el tiempo de vida del certificado caduca
y como consecuencia de la revocación de certificados.
• Solicitud de revocación: Una persona autorizada avisa
a una CA de una situación anormal requiriendo revo-
cación de certificados. Las razones para la revocación
incluyen compromiso de la clave privada, el cambio en
la afiliación, y el cambio de nombre.
• Certificación cruzada: Dos CA intercambian informa-
ción utilizados en el establecimiento de una certifi-
cación cruzada. Una certificación cruzada es un certi-
ficado emitido por una CA a otra CA que contiene una
clave de firma utiliza para la expedición de certificados.

4.2 Protocolos de Gestión PKIX

El Grupo de trabajo PKIX ha define dos alternativas de
protocolos de gestión entre las entidades PKIX que sopor-
tan las funciones de gestión enumerados en el apartado an-
terior. RFC 2510 define los protocolos de gestión de certifi-
cados (CMP). Dentro de CMP, cada una de las funciones de
gestión se identifica explı́citamente por el protocolo especı́-
fico de intercambio. CMP está diseñado para ser un proto-
colo flexible, capaz de acomodar una variedad de modelos
de negocio técnicos, operativos.

RFC 2797 define los mensajes de gestión certificados sobre

CMS (CMC), donde CMS refiere a RFC 2630, la sintaxis
de mensajes criptográficos. CMC se basa en trabajos an-
teriores y tiene por objeto movilizar las implementaciones