APLICACIONES DE AUTENTIFICACIÓN
Dávila Miguel, María Fonseca Romero,
Beatriz Sandro Miguel
Universidad Nacional de Universidad Nacional de
Trujillo Trujillo
marbe306@hotmail.com sandro1140@hotmail.com
ABSTRACT
This paper focuses on two of the most important authen-
tication specifications in current use. Kerberos is an au-
thentication protocol based on conventional encryption that
has received widespread support and is used in a variety of
systems. X.509 specifies an authentication algorithm and
defines a certificate facility. The latter enables users to ob-
tain certificates of public keys so that a community of users
can have confidence in the validity of the public keys. This
facility is employed as a building block in a number of ap-
plications.
Categories and Subject Descriptors
[Aplicaciones para Seguridad en Redes]: Aplicaciones
de Autentificación
General Terms
Seguridad en Redes
Keywords
Seguridad, Redes, Servicio de Autentificación, Kerberos,X.509
1. INTRODUCCIÓN
La seguridad e integridad de sistemas dentro de una red
puede ser complicada. Puede ocupar el tiempo de varios
administradores de sistemas sólo para mantener la pista de
cuáles servicios se están ejecutando en una red y la manera
en que estos servicios son usados. Más aún, la autenticación
de los usuarios a los servicios de red puede mostrarse peli-
grosa cuando el método utilizado por el protocolo es inher-
entemente inseguro, como se evidencia por la transferencia
de contraseñas sin encriptar sobre la red bajo los protoco-
los FTP y Telnet. Kerberos es una forma de eliminar la
necesidad de aquellos protocolos que permiten métodos de
autenticación inseguros, y de esta forma mejorar la seguri-
dad general de la red. Además brinda autenticación mu-
tua: tanto cliente como servidor verifican la identidad uno
del otro. Los mensajes de autenticación están protegidos
Hernádez Torres, Li Fernández, M
Jennifer Roxana Haydee
Universidad Nacional de Universidad Nacion
Trujillo Trujillo
jennifer.rht@gmail.com mhlf@gmail.co
para evitar eavesdropping y ataques de Replay. En crip-
tografı́a, X.509 es un estándar UIT-T para infraestructuras
de claves públicas (en inglés, Public Key Infrastructure o
PKI). X.509 especifica, entre otras cosas, formatos están-
dar para certificados de claves públicas y un algoritmo de
validación de la ruta de certificación. X.509 fue publicado
oficialmente en 1988 y comenzado conjuntamente con el es-
tándar X.500 y asume un sistema jerárquico estricto de au-
toridades certificantes (ACs) para emisión de certificados.
Esto contrasta con modelos de redes de confianza, como
PGP, donde cualquier nodo de la red (no solo las ACs)
puede firmar claves públicas, y por ende avalar la validez
de certificados de claves de otros. La versión 3 de X.509
incluye la flexibilidad de soporte de otras tecnologı́as como
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-
mente, y el grupo de trabajo de la infraestructura de clave
pública de la IETF, comúnmente conocido como PKIX para
infraestructura de clave pública (X.509) o PKIX, adaptó el
estándar a la estructura más flexible de Internet. X.509 in-
cluye también estándares para implementación de listas de
certificados en revocación (CRLs), y con frecuencia aspectos
de sistemas PKI. De hecho, el término certificado X.509 se
refiere comúnmente al Certificado PKIX y Perfil CRL del
certificado estándar de X.509 v3 de la IETF, como se es-
pecifica en la RFC 3280. La forma aprobada por la IETF de
chequear la validez de un certificado es el Online Certificate
Status Protocol (OCSP).
2. KERBEROS
Kerberos es un servicio de autenticación desarrollado como
parte del Proyecto Athena en el MIT. Supongamos un en-
torno distribuido abierto en el cual los usuarios de las esta-
ciones de trabajo desean acceder a servicios. Nos gustarı́a
que los servidores sean capaces de restringir el acceso a
usuarios autorizados y ser capaz de autenticar las solicitudes
del servicio. En particular, las siguientes tres amenazas ex-
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-
cación y usar un ataque de repetición para poder en-
trar en un servidor o interrumpir las operaciones.
Kerberos proporciona un servidor de autenticación central-
izada, cuya función es la autenticación de usuarios a servi-
dores y de servidores a usuarios. Kerberos se basa exclusiva-
mente en el cifrado simétrico, sin hacer uso de la encriptación
de clave pública.
2.1 Motivación
Hoy en dı́a, el escenario más común es una arquitectura dis-
tribuida que consiste en estaciones de trabajo de usuario
dedicadas (clientes) y servidores distribuidos o centraliza-
dos. En este ambiente, se pueden avizorar tres enfoques de
seguridad:
• Confiar en cada estación de trabajo cliente individual
para asegurar la identidad de sus usuarios y confiar
en cada servidor para hacer cumplir una polı́tica de
seguridad basada en la identificación de usuario (ID).
• Pedir a los sistemas cliente autenticarse con los servi-
dores, pero confiar en el sistema del cliente lo con-
cerniente a la identidad de sus usuarios.
• Pedir que el usuario provea su identidad para cada ser-
vicio invocado. También requieren que los servidores
demuestren su identidad a los clientes.
Kerberos soporta este tercer enfoque. Kerberos presupone
una arquitectura cliente/servidor distribuida y emplea a uno
o más servidores Kerberos para proporcionar un servicio de
autenticación.
El primer informe publicado sobre Kerberos lista los sigu-
ientes requerimientos:
• Seguro
• Confiable
• Transparente
• Escalable
Para apoyar estos requerimientos, el plan general de Ker-
beros es el de un servicio de autenticación de un tercer par-
ticipante de confianza (a trusted third-party) que utiliza un
protocolo basado en el propuesto por Needham y Schroeder.
2.2 Kerberos Versión 4
La versión 4 de Kerberos hace uso de DES, en un protocolo
bastante elaborado, para prestar el servicio de autenticación
Una Autenticación Simple de Dialogo
En un entorno de red sin protección, cualquier cliente puede
solicitar a cualquier servidor un servicio. El riesgo de se-
guridad obvio es el de la suplantación. Para contrarrestar
esta amenaza, los servidores deben ser capaces de confirmar
las identidades de los clientes que soliciten el servicio. Una
alternativa es utilizar un servidor de autenticación (AS) que
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-
tas claves han sido fı́sicamente distribuidas o en alguna otra
forma segura.
Una de Autenticación más segura de Dialogo
Aunque el anterior escenario resuelve algunos de los prob-
lemas de autenticación en un entorno de red abierta, los
problemas persisten. En primer lugar, nos gustarı́a mini-
mizar el número de veces que un usuario tiene que intro-
ducir una contraseña. Podemos mejorar las cosas diciendo
que los tickets son reutilizables. Sin embargo, bajo este es-
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
en texto plano de la contraseña. Un ”escucha” podrı́a cap-
turar la contraseña y utilizar cualquier servicio accesible a
la vı́ctima.
Para resolver estos problemas adicionales, se introduce un
esquema para evitar contraseñas en texto plano y un nuevo
servidor, conocido como el servidor de otorgamiento de tick-
ets (TGS). El servicio nuevo, TGS, emite tickets a los usuar-
ios que han sido autenticados para AS.
La versión 4 de Autenticación de Dialogo
Aunque el precedente escenario mejora la seguridad en com-
paración con el primer intento, dos problemas adicionales
aun están presentes. El centro del primer problema es el
tiempo de vida asociado al TGT. Si el tiempo de vida es muy
corto, entonces se le pedirá repetidamente una contraseña al
usuario. Si el tiempo de vida es largo, entonces un oponente
tiene una mayor oportunidad para la replicación.
El segundo problema es que puede ser que los servidores se
autentiquen a los usuarios. Sin tal autenticación, un opo-
nente pdrı́a sabotear la configuración para que los mensajes
a un servidor se dirijan a otra ubicación.(Tabla 1)
Kerberos Reinos y Kerberos múltiples
Un ambiente de servicio completo de Kerberos consiste de
un servidor Kerberos, un número de clientes, y una serie de
servidores de aplicaciones requiere lo siguiente:
• El servidor de Kerberos debe tener el identificador de
usuario y contraseñas con algoritmo hash de todos los
usuarios que participan en su base de datos.
• El servidor de Kerberos deben compartir una clave sec-
reta con cada servidor. Todos los servidores están reg-
istrados con el servidor de Kerberos. Un territorio de
Kerberos es un conjunto de nodos administrados que
comparten la misma base de datos Kerberos. Esta
 Mensaje 1 Cliente solicita ticket de concesión de
ticket
IDC Le dice al AS la identidad del usuario Mensaje 3
de este cliente
IDtgs Le dice al AS que el usuario solicita ac-
ceso al TGS
TS1 Permite que AS verifique que el reloj del Tickettgs
cliente este sincronizado con el de AS
Mensaje 2 AS regresa el ticket de concesión de AutenticadorC
ticket
KC El cifrado está basado en la contraseña Mensaje 4
del usuario, permitiendo a AS y al
cliente verificar la contraseña y prote-
giendo el contenido del mensaje.
Kc.tgs Copia de la clave de sesión accesible
al cliente creado por AS para permi-
tir el intercambio seguro entre el cliente
y TGS sin necesidad de que compartan
una clave permanente.
IDtgs Confirma que este ticket es para el TGS.
TS2 Informa al cliente del tiempo en que el
ticket fue emitido.
Tiempo de vida2 Informa al cliente del tiempo de vida del
ticket.
Tickettgs Ticket a ser usado por el cliente para
acceder al TGS. Tickettgs
Table 1: Justificación para los elementos del Proto-
colo Kerberos Versión 4(1)
reside en el sistema informático Kerberos maestro, el
cual debe mantenerse en una habitación fı́sicamente
seguro. Sin embargo, todos los cambios a la base de
datos debe hacerse en el sistema informático principal.
Cada director de Kerberos se identifica por su nom-
bre principal (constará de tres partes: un servicio o
un nombre de usuario, un nombre de instancia, y un
nombre de dominio).
• El servidor de Kerberos en cada ámbito de la interoper-
abilidad comparte una clave secreta con el servidor en
el otro reino. Los dos servidores Kerberos se registran
entre sı́.
Tiempo de vida2 billete de reproducción después de que
Con estas reglas básicas en su lugar, podemos describir el
Authenticatorc
mecanismo de la siguiente manera: Si un usuario desea el
servicio en un servidor en otro reino necesita un billete para
ese servidor. Cliente del usuario sigue los procedimientos
habituales para acceder al TGS local y solicita una nueva
TGT de TGS remoto (TGS en otro ámbito).
2.3 Kerberos Versión 5
Diferencias entre las versiones 4 y 5
Versión 5 está diseñado para hacer frente a las limitaciones
de versión 4 en dos áreas: las deficiencias del medio ambiente
y deficiencias técnicas.
a.- Autenticación del Servicio de Intercambio
El cliente solicita el ticket de concesión
de servicio.
IDV Le dice al TGS que el usuario solicita
acceso al servidor V.
Asegura a TGS que este usuario ha sido
autenticado por AS.
Generado por el cliente para validar el
ticket.
TGS retorna el ticket de concesión de
servicio.
Kc.tgs Clave compartida solo por C y TGS pro-
tege el contenido del mensaje.
Kcv Copia de la clave de sesión accesible al
cliente creado por TGS para permitir el
intercambio seguro entre cliente y servi-
dor sin que tengan que compartir una
clave permanente.
IDV Confirma que este ticket es para el servi-
dor V.
TS4 Informa al cliente del tiempo en que este
ticket fue emitido.
TicketV Ticket a ser usado por el cliente para
acceder al servidor V.
Copia de la clave de sesión accesible a
TGS utilizada para descifrar el autenti-
cador, con lo que se autentica billetes
ktgs boleto está cifrado con la clave que sólo
conocen AS y TGS, para evitar la ma-
nipulación
Kc,tgs Copia de la clave de sesión accesible a
TGS utilizada para descifrar el autenti-
cador, con lo que autenticar billetes
IDc Indica que el verdadero dueño de este
billete
ADc Evita el uso de ticket de estación de tra-
bajo que no sea uno que inicialmente
pidió el billete
IDtgs Asegura servidor que lo ha descifrado
correctamente billete
TS2 Informa TGS de tiempo este billete fue
emitido
ha caducado
Asegura que el presentador TGS billete
es el mismo que el cliente para el que
el billete se le haya expedido vida muy
corta para evitar la reproducción
Kc,tgs Autenticador se cifra con la clave que
sólo conocen los clientes y TGS, para
evitar la manipulación
IDc Debe coincidir con ID vale para auten-
ticar entradas
ADc Debe coincidir con la dirección en el bil-
lete vale para autenticar
TS3 Informa TGS de este tiempo se generó
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

b.- Intercambio de concesión de vales
Message 5 Solicitudes de servicio de cliente
Ticketv Asegura servidor que este usuario ha
sido autenticado por AS
Authenticatorc Generado por el cliente para validar en-
tradas
Message 6 autenticación opcional de servidor al
cliente
Kc,v Asegura C que este mensaje es de V
TS5 + 1 Asegura C que esto no es una repetición
de una respuesta de edad
Ticketv Reutilizables forma que el cliente no
necesita solicitar un nuevo ticket de
TGS para cada acceso al mismo servi-
dor
Kv boletos que está cifrada con la clave
conocida sólo por TGS y el servidor,
para evitar la manipulación
Kc,v Copia de la clave de sesión accesible al
cliente, que se utiliza para descifrar el
autenticador, con lo que autenticar bil-
letes
IDC Indica que el verdadero dueño de este
billete
ADc Evita el uso de ticket de estación de tra-
bajo que no sea uno que inicialmente
pidió el billete
IDv Asegura servidor que lo ha descifrado
correctamente billete
TS4 Informa servidor de tiempo de este bil-
lete fue emitido
Tiempo de vida4 billete de reproducción después de Evita
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-
tar la manipulación
IDc Debe coincidir con ID vale para auten-
ticar entradas
ADc Debe coincidir con la dirección en el bil-
lete vale para autenticar
TS5 Informa servidor de tiempo que esto se
generó autenticador
c.- El cliente / servidor de Exchange de autenticación
Table 3: Justificación para los elementos del Proto-
colo Kerberos Versión 4(3)
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
se alojan. La versión 5 de direcciones de red son etique-
tados con el tipo y longitud, lo que permite cualquier
tipo de direcciones de red que se utilizará.
3. Mensaje de orden de bytes: En la versión 4, el remi-
tente de un mensaje emplea una orden de bytes de
su propia elección y las etiquetas el mensaje a por lo
menos indican importantes byte en la dirección más
baja o byte más significativo en la dirección más baja.
En la versión 5, todas las estructuras se definen me-
diante las páginas de ”Abstract Syntax Notation One
(ASN.1) y Basic Encoding Rules (BER), que propor-
cionan un byte sin ambigüedades el pedido.
4. Venta de entradas de por vida: los valores de por vida
en la versión 4 se codifican en una cantidad de 8-bits
en unidades de cinco minutos. Por lo tanto, el tiempo
de vida máximo que se puede expresar es de 28 x 5
= 1280 minutos, o un poco más de 21 horas. En la
versión 5, los boletos incluyen una hora de inicio y
hora de finalización explı́cita, lo que permite entradas
con duraciones arbitrario.
5. Transmisión de autenticación: la versión 4 no permite
credenciales emitidas a un cliente que se transmitirá a
otro host y utilizada por algún otro cliente. La versión
5 ofrece esta capacidad.
6. Autenticación de interregno: En la versión 4, la inter-
operabilidad entre los reinos N requiere del orden de
N2 Kerberos a Kerberos relaciones, como se describió
anteriormente. Versión 5 es compatible con un método
que requiere pocas relaciones, tal como se describe en
breve.
1. Billetes de doble cifrado proporcionado a los clientes
se cifran en dos ocasiones, una vez con la clave secreta
del servidor de destino y luego de nuevo con una clave
secreta conocida por el cliente. El segundo cifrado no
es necesario y es computacionalmente desperdicio.
2. PCBC cifrado: cifrado en la versión 4 hace uso de un
modo no estándar de DES conocido como cifrado de
multiplicación de encadenamiento de bloques (PCBC).
Se ha demostrado que este modo es vulnerable a un
ataque con el intercambio de texto cifrado bloques. La
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
en particular, se corre el riesgo de que un oponente re-
producir mensajes serán desde una sesión de edad para
el cliente o el servidor. En la versión 5, es posible que
un cliente y el servidor para negociar una clave sub-
sesión, que se va a utilizar sólo para esa conexión una.
Un nuevo acceso por parte del cliente se traducirı́a en
la utilización de una clave subsesión nuevo.
4. Ataques Contraseña: Ambas versiones son vulnerables
a un ataque de contraseña. El mensaje de la AS para
el cliente incluye material cifrado con una clave basada
en oponente del cliente password.
MAY-POSTDATE
La versión 5 de diálogo de autentificación
En primer lugar, considerar el cambio de servicio de aut-
enticación. Mensaje (1) es una solicitud del cliente para un
TGT. Al igual que antes, incluye el ID del usuario y el TGS.
Los siguientes elementos se agregan otras nuevas:
• Dominio: Indica el ámbito de usuario
• Opciones: Se utiliza para pedir que ciertos pabellones
fijado en el billete volvió.
• Horario: Usado por el cliente para solicitar los ajustes
de hora siguientes en el billete:
FORWARDABLE
– a partir de: la hora de inicio deseada para el bo-
leto solicitado
– hasta: la fecha de caducidad solicitado para el
boleto solicitado
– rtime: pidió renovar a tiempo hasta
• Nonce: Un valor al azar que se repite en el mensaje
(2) para asegurar que la respuesta es fresca y no ha
sido repetido por un adversario y dicho valor solo se
usa una vez.
INICIAL Este billete fue emitido mediante el proto-
colo AS y no se han concedido sobre la base
de un cupón de obtención.
PRE-AUTHENT Durante la autenticación inicial, el cliente
se ha autenticado por el KDC antes de que
un billete fuera emitido.
HW-AUTHENT El protocolo empleado para la autenti-
cación inicial exigido el uso de hardware es-
pera de ser poseı́da exclusivamente por el
nombre del cliente.
RENOVABLES Le dice al TGS que este billete se puede uti-
lizar para obtener un pasaje de sustitución,
que vence en una fecha posterior.
Le dice al TGS que un billete con fecha pos-
terior podrá expedirse sobre la base de este
TGT.
POSTDATED Indica que este ticket ha sido con fecha pos-
terior, el servidor final puede comprobar el
campo de authtime para ver cuándo se pro-
dujo la autenticación inicial.
INVALID Este billete no es válido y debe ser validado
por el KDC antes de su uso.
PROXIABLE Le dice al TGS que un nuevo ticket que con-
cede un servicio con una dirección de red
diferente puede ser emitidos con base en el
billete presentado.
PROXY Indica que este ticket es un proxy.
Le dice al TGS que un nuevo billete de con-
cesión de vales con una dirección de red
diferente puede ser emitido con base en este
TGT.
FORWARDED Indica que este ticket ha sido o bien remitir
o se haya expedido sobre la base de aut-
enticación sobre un billete transmitido de
concesión de vales.
Table 4: Banderas, versión 5 de Kerberos

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

Mensaje (2) devuelve un TGT, identificando la información
para el cliente, y el bloque de una cifra con la clave de cifrado
basado en la contraseña del usuario. El ticket incluye la
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-
itadas. Vemos que el mensaje (3) para las dos versiones
incluye un autenticador, el boleto, y el nombre del servicio
solicitado. Además, la versión 5 incluye la hora solicitada y
las opciones para el boleto y un nonce. Mensaje (4) tiene
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-
ción que se requiere la autenticación mutua. El autenticador
incluye varios nuevos campos de la siguiente manera:
• Subclave: La elección del cliente para una clave de
cifrado que se utiliza para proteger esta sesión de la
aplicación especı́fica. Si este campo se omite, la clave
de sesión del billete (Kc, v) se utiliza.
el número de secuencia empezando a utilizar el servi-
dor para los mensajes enviados al cliente durante este
perı́odo de sesiones.
Boleto Banderas
El campo de banderas incluido en los boletos en la versión
5 soporta la funcionalidad ampliada en comparación con la
disponible en la versión( Tabla 4).
La bandera inicial indica que este billete fue emitido por el
AS, no por el TGS. Cuando un cliente solicita un vale de
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
versión 5 proporciona la capacidad adicional que el cliente
puede obtener un vale de servicio que otorgan directamente
de la AS. La utilidad de esto es el siguiente: Un servidor,
como un servidor de cambio de contraseña, tal vez desee
saber que la contraseña del cliente se puso a prueba recien-
temente.
La bandera PRE-AUTHENT, si se define, indica que cuando
el AS recibido la solicitud inicial [mensaje (1)], que autentica
al cliente antes de emitir un billete. Cuando un usuario
quiere obtener un billete, tiene que enviar al AS un bloque
que contiene un factor de confusión autenticación previa al
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
bloque y no enviará un cupón de obtención de subir a menos
que la marca de tiempo en el bloque de preautenticación está
dentro del tiempo permitido sesgo (intervalo de tiempo para
dar cuenta de la deriva del reloj y retrasos en la red). Otra
posibilidad es el uso de una tarjeta inteligente que genera
continuamente el cambio de claves que se incluyen en los
mensajes preauthenticated. Las contraseñas generadas por
la tarjeta puede estar basada en la contraseña de un usuario,
pero que sean transformados mediante la tarjeta para que,
en efecto, las contraseñas se utilizan arbitraria. Esto impide
que un ataque basado en contraseñas fáciles de adivinar.
Cuando un billete tiene una larga vida, existe la posibilidad
para que pueda ser robados y utilizados por un contrario du-
rante un perı́odo considerable. Si un corto tiempo de vida
se utiliza para disminuir la amenaza, a continuación, gastos
generales relacionados con la adquisición nuevos boletos. En
el caso de un cupón de obtención, el cliente tendrı́a que alma-
cenar la clave secreta del usuario, que es claramente riesgoso,
o varias veces pedir al usuario una contraseña. Un esquema
de compromiso es el uso de billetes de renovables. Un bo-
leto con el indicador RENOVABLES incluye dos fechas de
caducidad: una para este billete especı́fico y que es el último
valor permitido para un tiempo de caducidad. La ventaja
de este mecanismo es que la TGS puede negarse a renovar
un billete reportado como robado.
Un cliente puede solicitar que el de proporcionar un cupón de
obtención con el indicador MAY-son posteriores. El cliente
puede utilizar esta entrada para solicitar un ticket que se
marca como fecha adelantada y no válidos de la TGS. Poste-
riormente, el cliente puede presentar el billete con fecha pos-
terior para su validación.Este esquema puede ser útil para
ejecutar un trabajo por lotes de largo en un servidor que
requiere un boleto periódicamente. El cliente puede obtener
un número de entradas para esta sesión a la vez, con una
propagación de salida los valores de tiempo. Todos menos el
primer boleto son inicialmente válido. Cuando la ejecución
alcanza un momento en que un nuevo billete es necesario, el
cliente puede obtener el boleto debidamente validado. Con
este enfoque, el cliente no tiene que utilizar en repetidas
ocasiones su TGT para obtener un ticket que concede un
servicio.
El concepto de proxy es un caso limitado del procedimiento
de transmisión más potente. Si un billete se fija con la ban-
dera remitible, un TGS puede emitir al solicitante un TGT
con una dirección de red diferente y el conjunto de aban-
deramiento enviará. Este ticket puede ser presentada en un
TGS remoto. Esta capacidad permite a un cliente para ac-
ceder a un servidor en otro reino, sin necesidad de que cada
Kerberos mantener una clave secreta con los servidores Ker-
beros en todos los ámbitos otros.
3. SERVICIO DE AUTENTIFICACIÓN X.509
UIT-T X.509 Recomendación forma parte de la serie de re-
comendaciones X.500 que definen un servicio de directorio.
El directorio es, en efecto, un servidor distribuido o conjunto
de servidores que mantiene una base de datos de información
sobre los usuarios. La información incluye una asignación
de nombre de usuario a la dirección de red, ası́ como otros
atributos e información sobre los usuarios.
X.509 define un marco para la prestación de servicios de
autenticación por el directorio X.500 a sus usuarios. El di-
rectorio puede servir como un repositorio de certificados de
clave pública. Cada certificado contiene la clave pública de
un usuario y se firma con la clave privada de una entidad
certificadora de confianza. Además, X.509 define protocolos
alternativos de autenticación basado en el uso de certificados
de clave pública.
X.509 es un estándar importante porque la estructura de
certificados y protocolos de autenticación definido en X.509
se utilizan en una variedad de contextos. Por ejemplo, el for-
mato de certificado X.509 se utiliza en S / MIME, Seguridad
IP, Y SSL / TLS y SET.
X.509 inicialmente expedido en 1988. La norma fue revisada
posteriormente para hacer frente a algunas de las preocupa-
ciones de seguridad; Una recomendación revisada se publicó
en 1993. Una tercera versión se publicó en 1995 y revisada
en 2000.
X.509 se basa en el uso de la criptografı́a de clave pública
y firmas digitales. La norma no impone el uso de un algo-
ritmo especı́fico, pero recomienda RSA. El esquema de firma
digital se supone que requieren el uso de una función hash.
Una vez más, la norma no determina un algoritmo de hash
especı́fica. La recomendación de 1988 incluyó la descripción
de un algoritmo de hash recomendadas; este algoritmo ha
sido demostrado que es inseguro y fue eliminado de la re-
comendación de 1993.
Figura 1 ilustra la generación de un certificado de clave
pública.
Certificados
El corazón del sistema X.509 es el certificado de clave pública
asociado a cada usuario. Estos certificados de usuario se
supone que son creados por alguna autoridad de certificación
de confianza (CA) y se coloca en el directorio de la entidad
emisora o por el usuario. El servidor de directorio en sı́
mismo no es responsable de la creación de claves públicas o
para la función de certificación, sino que se limita a estable-
cer una zona de fácil acceso para los usuarios que obtienen
los certificados.
La Figura 2 muestra el formato general de un certificado,
que incluye los siguientes elementos:
• Versión: Diferencia entre las sucesivas versiones del
formato del certificado, el valor por defecto es la ver-
sión 1. Si el Emisor Unique Identifier o Identificador
único Asunto están presentes, el valor debe ser la ver-
sión 2. Si una o más extensiones están presentes, la

Figure 1: Certificado de clave pública Uso
versión debe ser la versión 3.
• De número de serie: Valor entero, único en la CA
emisora, que esta inequı́vocamente asociado con este
certificado.
• Firma identificadora del algoritmo: El algoritmo uti-
lizado para firmar el certificado, junto con cualquier
parámetro asociado. Debido a que esta información se
repite en el ámbito de la firma en el final del certificado,
este campo tiene poca, si los hubiere, de utilidad.
• Nombre del emisor: nombre X.500 de la CA que ha
creado y firmado el presente certificado.
• Periodo de validez: Consiste en dos fechas: la primera
y última vez que el certificado es válido.
• Asignatura: El nombre del usuario al que se refiere el
presente permiso. Es decir, este certificado certifica
la clave pública del sujeto que posee la clave privada
correspondiente.
• Información de clave pública del sujeto: la clave pública
del sujeto, además de un identificador del algoritmo
para que esta clave se va a utilizar, junto con cualquier
parámetro asociado.
• Identificador único de emisor: Un campo de bits de
cadena opcional que permite identificar de forma única
la CA emisora en el caso de que el nombre X.500 ha
sido reutilizados para diferentes entidades.
• Identificador único de Asunto: Un campo de bits ca-
dena opcional sirve para identificar unı́vocamente al
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
extensión. Las Extensiones se añadieron en la versión
3 y se describen más adelante en esta sección.
• Firma: Cubre todos los otros campos de dicho certifi-
cado, que contiene el código hash de los otros campos,
cifrada con la clave privada de la CA. Este campo in-
cluye el algoritmo identificador de firma.
Figure 2: X.509 Formatos
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
usan raramente.
El estándar usa la notación siguiente para definir un certifi-
cado:
CA << A >> = (V CA, SN, AI, CA, TA, Un Ap,)
donde
Y << X >> = El certificado de usuario X emitidos por la
autoridad de certificación Y
Y (I) = La firma del I por Y. Se trata de que con un código
de encryptedhash anexa
Los CA firman el certificado con su clave privada. Si la
clave pública correspondiente se conoce a un usuario, a con-
tinuación, que el usuario puede comprobar que un certificado
firmado por la CA es válido.
La obtención de un Certificado de usuario
Los certificados de usuario generados por una CA tienen las
siguientes caracterı́sticas:
• Cualquier usuario con acceso a la clave pública de la
entidad emisora puede verificar la clave pública del
usuario que se ha certificado.
• Ninguna de las partes distintas de la autoridad de cer-
tificación puede modificar el certificado sin que esto
sea detectado.
Debido a que los certificados son infalsificables, se pueden
colocar en un directorio sin la necesidad de que el directorio
que haga esfuerzos especiales para protegerlos.
Si todos los usuarios se suscriben a la misma CA, entonces
no hay una confianza común en la AC. Todos los certificados
de usuario se pueden colocar en el directorio para el acceso
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-
ras de certificados necesitan aparecer en el directorio, y el
usuario tiene que saber cómo están relacionadas a seguir un
camino al certificado de clave pública de otro usuario. X.509
sugiere que las CA se disponen en una jerarquı́a de modo que
la navegación es sencilla.
Recuerde del La figura 2 que cada certificado incluye un
perı́odo de validez, al igual que una tarjeta de crédito. Nor-
malmente, un nuevo certificado es emitido justo antes de la
expiración de la anterior. Además, puede ser conveniente en
ocasiones para revocar un certificado antes de su expiración,
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
A
2. Que el mensaje estaba destinado a B
3. La integridad y la originalidad (que no se ha enviado
en múltiples ocasiones) del mensaje
Tenga en cuenta que sólo la identidad de la entidad se veri-
fica en iniciar este proceso, no el de la entidad de respuesta.
Como mı́nimo, el mensaje incluye una marca de tiempo tA,
un rA nonce y la identidad de B y se firma con la clave
generado por B
2. Que el mensaje estaba destinado a un
3. La integridad y la originalidad de la respuesta
Dos vı́as de autenticación por tanto, permiten a ambas partes
en una comunicación a verificar la identidad del otro.
El mensaje de respuesta incluye el nonce de la A, para val-
idar la respuesta. También incluye una marca de tiempo y
nonce generado por B. Al igual que antes, el mensaje puede
incluir información adicional firmado y una clave de sesión
cifrada con la clave pública de A.
Autenticación de tres vı́as
En la autenticación de tres vı́as, un mensaje final de A a
B está incluido, el cual contiene una copia firmada de la
RB nonce. La intención de este diseño es que las mar-
cas de tiempo No necesita ser controlado: Debido a que
tanto nonces se hacen eco de vuelta por el otro lado, cada
lado puede comprobar el nonce devuelto para detectar los
ataques de repetición. Este enfoque es necesario cuando se
sincronizan los relojes no están disponibles.
X.509 versión 3
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
siguientes requisitos no cumplidos con la versión 2:
1. El campo Asunto no es suficiente para transmitir la
identidad del propietario de una clave a un usuario de
clave pública. nombres X.509 puede ser relativamente
corta y carente de datos de identificación obvio que
puede ser necesaria para el usuario.
2. El campo Asunto también es insuficiente para muchas
aplicaciones, que por lo general reconocen entidades
por Internet una dirección de correo electrónico, una
dirección URL, o alguna otra identificación relacionada
con Internet.
3. Es necesario indicar la información de seguridad común.
Esto permite a una aplicación de seguridad o de la fun-
ción, tales como IPSec, para relacionar un certificado
X.509 a una determinada polı́tica.
4. Hay una necesidad de limitar el daño que puede derivarse
de una errónea o maliciosa CA, estableciendo restric-
ciones en la aplicabilidad de un certificado en particu-
lar.
5. Es importante ser capaz de identificar diferentes claves
utilizadas por el mismo propietario en diferentes mo-
mentos. Esta función admite la administración de
claves del ciclo de vida, en particular, la capacidad
de actualizar los pares de claves para los usuarios y las
entidades emisoras de manera regular o en circunstan-
cias excepcionales.
En lugar de continuar añadiendo campos a un formato fijo,
los desarrolladores de Normas estimó que un enfoque más
flexible que se necesitaba. Ası́, la versión 3 incluye una serie
de extensiones opcionales que pueden añadirse a la versión
2 de formato. Cada extensión consiste en un identificador
de extensión, un indicador crı́tico, y un valor de extensión.
El indicador de criticidad indica si una extensión puede ser
ignorado con seguridad. Si el indicador tiene un valor de
TRUE y una aplicación no reconoce la extensión, debe con-
siderar el certificado como válido.
Las extensiones de certificado se dividen en tres categorı́as
principales: información clave y la polı́tica, los temas y
los atributos del emisor, y las limitaciones de certificación
camino.
Clave y la polı́tica informativa
Estas extensiones de transmitir información adicional sobre
el tema y las claves emisor, además de indicadores de la
polı́tica de certificado. Una polı́tica de certificación es un
llamado conjunto de reglas que indica la aplicabilidad de
un certificado a una comunidad en particular y / o clase de
aplicación con requisitos de seguridad común. Por ejemplo,
una polı́tica podrı́a ser aplicable a la autenticación de inter-
cambio electrónico de datos (EDI) las operaciones para el
comercio de mercancı́as dentro de un rango de precios.
Esta área incluye las siguientes:
• Identificador de clave Autorizada: Identifica la clave
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
campo es manejar la actualización del par clave de CA
• Asunto identificador clave: Identifica la clave pública
certificada. Útil para la actualización del par de claves
en cuestión. Además, un sujeto puede tener varios
pares de claves y, en consecuencia, los certificados dis-
tintos para diferentes propósitos (por ejemplo, firma
digital y cifrado acuerdo de claves).
• Uso de claves: Indica una restricción impuesta sobre la
finalidad para la cual, y las polı́ticas en las que, puede
ser la clave pública certificada utilizada. Puede indicar
uno o más de los siguientes: firma electrónica, no re-
pudio, la clave de cifrado, cifrado de datos, acuerdo de
claves, de verificación de firmas en los certificados de
CA, CA de verificación de firma en las CRL.
• El uso de la clave privada de las actividades: Indica el
perı́odo de utilización de la clave privada correspondi-
ente a la clave pública. Por lo general, la clave privada
se utiliza durante un perı́odo diferente de la validez de
la clave pública. Por ejemplo, con las claves de firma
digital, el perı́odo de uso de la clave de firma privada
suele ser más corto que el de la verificación de la clave
pública.
• 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
que el certificado es reconocido como el apoyo, junto
con información calificador optativo.
• Polı́tica de asignaciones: Sólo se usa con certificados
de entidades emisoras de certificados emitidos por enti-
dades emisoras de otros. asignaciones de Polı́tica per-
miten una CA emisora para indicar que una o más de
que las polı́ticas del emisor se puede considerar equiv-
alente a otro de polı́tica utilizados en el dominio del
tema de CA.
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,
e IPSec, que pueden emplear sus formas propio nom-
bre.
• Emisor nombre alternativo: Contiene uno o varios nom-
bres alternativos, utilizando cualquiera de una var-
iedad de formas.
• Sin perjuicio de los atributos de directorio: Transmite
cualquier directorio X.500 valores de los atributos de-
seados para el tema de este certificado.
Certificación Limitaciones Camino
Estas extensiones permiten limitar especificaciones que deben
incluirse en los certificados emitidos por CAs por otras CAs.
Las limitaciones pueden restringir los tipos de certificados
que pueden ser emitidas por el tema de la CA o que puedan
producirse posteriormente en una cadena de certificación.
Los campos de extensión en este ámbito son las siguientes:
• Limitaciones básicas: Indica si el sujeto puede actuar
como una entidad emisora. Si es ası́, una ruta de cer-
tificación restricción de longitud que se indique.
• Lmitaciones Nombre: Indica un espacio de nombres
en el que todos los nombres de objeto de los certifica-
dos posteriores en una ruta de certificación debe estar
ubicada.
• Polı́tica de restricciones: limitaciones Especifica que
pueden exigir la identificación explı́cita polı́tica de cer-
tificación o inhibir la asignación de directivas para el
resto de la ruta de certificación.
4. INFRAESTRUCTURA DE CLAVE PÚBLICA
El Glosario de Seguridad de Internet define la infraestruc-
tura de clave pública (PKI) como el conjunto de hardware,
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
objetivo principal para el desarrollo de una PKI es permitir
una adquisición segura, práctico y eficaz de claves públi-
cas. El grupo de trabajo Ingenierı́a de Internet Task Force
(IETF) Infraestructura de clave pública X.509 (PKIX) ha
sido la fuerza impulsora detrás de la creación de un oficial
(y general) modelo basado en X.509 que es adecuado para la
implementación de una arquitectura basada en certificados
de de Internet. Los elementos clave del modelo PKIX son:
Figure 5: Modelo Arquitectónico PKIX
• Entidad final: Un término genérico utilizado para de-
notar a los usuarios finales, dispositivos (por ejemplo,
servidores, routers), o cualquier otra entidad que se
pueden identificar en el ámbito objeto de un certificado
de clave pública. Las entidades finales normalmente
consumen y / o apoyan los servicios relacionados de
PKI.
• Autoridad de certificación (CA): El emisor de los certi-
ficados y (generalmente) las listas de revocación de cer-
tificados (CRL). Puede además soportar una variedad
de funciones administrativas, aunque con frecuencia
son delegadas a una o varias autoridades de registro.
• Autoridad de Registro (RA): Es un componente op-
cional que puede asumir una serie de funciones admin-
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.
• Emisor CRL: es un componente opcional al que un CA
puede delegar la publicación de las CRL.
• Repositorio (almacén): Término genérico utilizado para
denotar cualquier método para almacenar certificados
y CRL para que puedan ser recuperados por entidades
finales.
La relacion entre estos elementos se muestra en la Figura 5.
4.1 Funciones de Gestión PKIX
PKIX identifica una serie de funciones de gestión que nece-
sitan potencialmente ser soportados por los protocolos de
gestión. Estos se indican en la Figura 5 y se incluyen las
siguientes:
• Registro: Es el proceso mediante el cual un usuario
se da a conocer primero a una CA (directamente o a
través de un RA), antes de que ese CA expida un certi-
ficado o certificados para dicho usuario. La inscripción
comienza el proceso de inscribirse en una PKI. El Reg-
istro suele implicar algunos procedimientos con o sin
conexión para la autenticación mutua. Normalmente,
se emite a la entidad final una o más claves secretas
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