Protocolo IPv6.
INTRODUCCION, OBJETIVOS DE DISEÑO, MECANISMOS DE SEGURIDAD DE IPv6, ADMINISTRACION DE CLAVES, USO, CONSIDERACIONES DE SEGURIDAD.
Agregado: 29 de AGOSTO de 2000 | Palabras: 4118 |
Votar! | Sin Votos |
Sin comentarios |
Agregar ComentarioCategoría:
Apuntes y Monografías >
Computación >
Varios >
Nuevo Protocolo IPv6. -=-
N3wk3rs -=-
1. INTRODUCCION
Esta parte describe los mecanismos de seguridad integrados en la versión 6 del
Protocolo de Internet (IPv6) y los servicios que los proporcionan. También se describe la
administración de claves para los mecanismos de seguridad de IPv6. Para más
información, ver el draft draft-ietf-ipngwg-sec-00
1.1 Definiciones
Esta sección contiene algunas definiciones básicas aplicables para este documento.
Autenticidad Propiedad de conocer que la
información recibida sea la misma que la información enviada y que el emisor es
realmente quien asegura.
Integridad Propiedad de asegurar que la
información es transmitida desde el emisor al destino sin detectarse alteraciones.
Confidencialidad Propiedad de mantener
comunicaciones confidenciales de modo que los participantes involucrados puedan establecer
comunicación sin que otros elementos ajenos a ellos sepan quiénes son.
Cifrado Mecanismo utilizado comunmente
para proveer confidencialidad.
No repudio Propiedad de que un receptor
sea capaz de probar que el emisor de alguna información realmente la envió, aun cuando
el emisor pudiera negar posteriormente haber enviado dichaa información.
SAID Acrónimo de "Identificador de
Asociación de Seguridad"
Asociación de Seguridad Conjunto de
información de seguridad referente a una conexión de red dada (o conjunto de
conexiones). Ésta incluye generalmente la clave criptográfica, tiempo de vida de la
clave, algoritmo, forma del algoritmo, nivel de sensibilidad (p.e. No clasificada,
Secreto, Propietario), qué clase de servicio de seguridad se proporciona (solamente
autenticidad, modo de transporte de cifrado, Modo IP de Cifrado, o alguna combinación), y
posiblemente alguna otra información.
Análisis de tráfico Una clase de
ataque de red es aquél en el cual atacante es capaz de hacer deducciones acerca de la
misma analizando sólo los patrones de tráfico de red (como frecuencia de transmisión,
con quién se habla, tamaño de paquetes, Identificador de Flujo utilizado, etc).
2. OBJETIVOS DE DISEÑO
Esta sección describe parte de los objetivos de diseño de la arquitectura de
seguridad y los mecanismos que los componen.
El objetivo principal de este trabajo es
garantizar que IPv6 tenga mecanismos de seguridad sólidos disponibles para usuarios que
deseen seguridad. Estos mecanismos estan diseñados de tal manera que los usuarios de
Internet no los empleen no se vean afectados de forma adversa.
Se pretende que estos mecanismos sean algoritmos
independientes de forma que los algoritmos de cifrado puedan ser alterados sin afectar
otras partes de la implementación.
Los algoritmos estándar por defecto (p.e: MD5
con clave, DES CBC) han sido seleccionados para garantizar interoperabilidad en la
Internet global.
Los algoritmos seleccionados son los mismos que
los algoritmos estándar por defecto utilizados en SNMPV2. Los mecanismos de Seguridad de
IPv6 deberían ser así útiles al imponer una variedad de políticas de seguridad.
3. MECANISMOS DE SEGURIDAD DE IPv6
Hay dos mecanismos de seguridad en IPV6.
La Cabecera de Autenticidad, que
proporciona integridad y autenticidad sin confidencialidad.
El Encapsulating Security Payload, que,
dependiendo del algoritmo y modo, podría proporcionar integridad, autenticidad, y siempre
confidencialidad.
Los mecanismos de IPv6 no proveen seguridad
contra un número de ataques de análisis de tráfico. Sin embargo, hay varias técnicas
que no están en esta especificación (p.e.. bulk link encryption) que podrían ser
utilizadas para proporcionar protección contra el análisis de tráfico.
Los dos mecanismos de seguridad de IPV6 pueden
ser combinados.
3.1 CABECERA DE
AUTENTICACIÓN
La Cabecera de Autenticación de IPV6 busca proporcionar integridad y autenticidad para
los datagramas IPv6. Esto se hace computando una función de autenticidad criptografica
sobre el datagrama IPv6 y empleando una clave de autenticidad secreta en el cálculo.
El emisor computa la información de autenticidad
exactamente antes de enviar el paquete IPV6 autenticado y el receptor verifica la
información autenticada con la recibida. Hay ciertos campos que son omitidos en el
cálculo de autenticidad debido a que cambian durante el tránsito como el campo Hop
Limit, decrementando en cada paso. Sin embargo, la omisión del campo Hop Limit no afecta
a la seguridad. Algunos algoritmos de autenticación podría proporcionar no repudio (p.e.
algoritmos asimétricos en los que tanto las claves del emisor como del receptor se
utilizan en el cálculo de la autenticidad) utilizados con la Cabecera de Autenticidad,
pero no es necesariamente suministrado por todos los algoritmos de autenticidad que pueden
utilizarse con la Cabecera de Autenticación.
El algoritmo de autenticación por defecto es
el MD5 con clave, que se ajusta a todos los algoritmos simétricos que no proporcionan no
repudio.
La protección del análisis de tráfico y la
confidencialidad no son suministradas por la Cabecera de Autenticación.
La Cabecera de Autenticación de IPv6 mantiene
información de autenticación para su datagrama IPv6. Esta información de autenticación
se calcula utilizando todos los campos del datagrama IPv6 que no van a cambiar durante el
tránsito desde el emisor al receptor. Todas las cabeceras de IPv6, payloads y la
información de usuario están incluidas en este cálculo. La única excepción es que
esos campos que deben cambiar en el tránsito (p.e. La Cabecera de IPv6 "Hop
Count" o la Cabecera de Encaminamiento de IPv6 "Next Address") son omitidos
cuando se calcula la información de autenticación.
El uso de la Cabecera de Autenticación
aumentará los costes de procesamiento de protocolo de IPv6 en los sistemas que lo
utilicen, así como la latencia de las comunicaciones. El aumento de latencia es
principalmente debido al cálculo de la información de autenticación por parte del
emisor y el cálculo y comparación de la información de autenticación por el receptor
de cada datagrama IPv6 contenido en una Cabecera de Autenticación (AH).
La Cabecera de Autenticación proporciona una
seguridad más fuerte que la existente en la mayoría de la actual Internet y no debería
afectar a la exportabilidad ni aumentar significativamente el coste de implementación.
Aunque la Cabecera de Autenticación puede ser instrumentada como una medida de seguridad
empleando los nombres exactos de las máquinas de una red, este modo de operación no es
seguro. En lugar de eso, la Cabecera de Autenticación debería ser utilizada también
desde el origen al destino final.
Todas las máquinas que soporten IPv6 TIENEN
que implementar la Cabecera de Autenticación de IPv6 con al menos el algoritmo de MD5 con
unas claves de 128 bits. Se PUEDE implementar otros algoritmos de autenticación además
del MD5 con clave.
3.2 ENCAPSULATING SECURITY
PAYLOAD
El Encapsulating Security Payload (ESP) de IPv6 trata de dar integridad ,
autenticación y confidencialidad a los datagramas IPv6. Esto se hace por encapsulamiento,
ya sea de un datagrama IPv6 completo o solamente información de protocolo de la capa
superior dentro del ESP, cifrando la mayor parte del contenido del ESP, para concatenar
después una nueva cabecera IPv6 sin cifrar al ya cifrado ESP. Esta cabecera IPv6 no
cifrada se utiliza para llevar los datos protegidos a través de la red. El receptor del
datagrama no cifrado retira y descarta la cabecera IPv6 y sus opciones no cifradas,
descifra el ESP, procesa y después elimina las cabeceras de ESP, trata el (ahora
descifrado) datagrama original IPv6 o los datos de un protocolo de nivel superior, como se
indica en las especificaciones del protocolo IPv6.
3.2.1 Descripción de los
Modos de ESP
Hay dos modos dentro de ESP :
El primer modo, conocido como IP-mode,
encapsula y completa el datagrama IP dentro de la cabecera de ESP.
El segundo modo, conocido como Transport-mode,
generalmente encapsula un UDP o TCP enmarcándolos dentro de IP.
3.2.2 Uso de ESP
ESP trabaja entre máquinas, entre una máquina y una entrada de seguridad, o entre
entradas de seguridad. El soporte para entradas de seguridad permite que haya redes
fiables detrás de una entrada de seguridad para omitir el cifrado y de ese modo evitar el
trabajo y costes monetarios del cifrado, mientras que ofrece confidencialidad para
tráfico transitando por segmentos de red no fiables. Cuando ambas máquinas implementan
directamente ESP y no intervienen entradas de seguridad, entonces se puede emplear el
Transport-mode (donde sólo es cifrada la información de protocolo de la capa superior
(e.g. TCP o UDP), no la cabecera de IPv6). Este modo reduce tanto el ancho de banda
consumido como los costes de procesamiento de protocolo para usuarios que no necesiten
mantener la confidencialidad del datagrama IPv6 al completo. ESP trabaja tanto con
tráfico unicast como multicast.
3.2.3 Impactos de la
Función de ESP
El enfoque dado al encapsulamiento de seguridad utilizado por ESP puede impactar
notablemente la función de la red en sistemas participantes, pero no debería influir
negativamente en encamiadores u otros sistemas intermedios que no participen en la
asociación de ESP particular.
El procesamiento de protocolo en sistemas
participantes será más complejo cuando se utilice el encapsulamiento de seguridad, ambos
requieren más tiempo y más potencia de procesamiento.
El uso del cifrado tambien aumentará la latencia
de las comunicaciones. La latencia aumentada es principalmente debida al cifrado y
descifrado requerido por cada datagrama IPv6 contenido en un ESP.
El coste preciso de ESP variará con las
especificaciones de la implementación, incluyendo el algoritmo de cifrado, tamaño de
clave y otros factores.
Las implementaciones hardware de los
algoritmos de cifrado son recomendables cuando se desee una gran productividad. Debido al
impacto de las funciones, los usuarios que no requieran confidencialidad preferirán
probablemente utilizar la cabecera de Autenticación de IPv6 en lugar de ESP.
Para interoperar a través de la Internet a nivel
mundial, todas las implentaciones de Encapsulting Security Payload de IPv6 soportan el uso
del Data Encryptión Standard (DES) en Cipher-Block Chining (CBC) Mode.
Otros algoritmos de confidencialidad y modos
pueden ser implementados además de este algoritmo y modo (obligatorios).
La exportación de métodos de cifrado y uso de
los mismos está regulado en algunos países.
3.3 COMBINANDO MECANISMOS
DE SEGURIDAD
En algunos casos la Cabecera de Autenticación de IPv6 puede combinarse con el IPv6
Encapsulating Security Protocol para obtener las propiedades de seguridad deseadas.
La Cabecera de Autenticación proporciona siempre
integridad y autenticación y puede incluir no repudio si se usa con ciertos algoritmos de
autenticación (p.e. RSA).
La Encapsulating Security Payload proporciona
siempre integridad y confidencialidad y puede proveer autenticación si utiliza ciertos
algoritmos de autenticación y cifrado.
Añadiendo la Cabecera de Autenticación a un
primer datagrama IPv6 para encapsular aquel datagrama mediante el Encapsulating Security
Protocol podría ser aconsejable para usuarios que deseen tener una integridad más
fuerte, autenticación, confidencialidad, y quizás también no repudio. Cuando se
combinan los dos mecanismos, la colocación de la Cabecera de Autenticación de IPV6
aclara que parte de la información está siendo autenticada. Detalles acerca de combinar
los dos mecanismos vienen en las especificaciones del IPv6 Encapsulating Segurity Payload.
3.4 OTROS MECANISMOS DE
SEGURIDAD
La protección del análisis de tráfico no es facilitada por ninguno de los mecanismos
de seguridad descritos anteriormente. No está claro que la protección significativa
contra el análisis de tráfico pueda ser proporcionada económicamente en la Capa de
Internet y parece que pocos usuarios de Internet son conscientes acerca del análisis de
tráfico.
Un método tradicional de protección contra el
análisis de tráfico es el uso del cifrado bulk-link.
Otra técnica es enviar tráfico falso para
aumentar el ruido en la información para el análisis de tráfico.
En la Referencia se discuten temas de análisis
de tráfico más en detalle.
4. ADMINISTRACION DE CLAVES
El protocolo de Administración de Claves que se utilizará en IPv6 no está
especificado en este documento.
IPv6 pretende sostener la llamada
administración de claves "in-band", donde la información de administración de
claves se lleva en una cabecera de IPv6 distinta.
En lugar de eso se utilizará principalmente la
llamada administración de claves "out-of-band", donde la información de
administración de claves la llevará un protocolo de capas superiores (como UDP o TCP) en
algún numero de puerto especificado.
Esto permite aclarar el desacople del mecanismo
de administración de claves de otros mecanismos de seguridad, y de ese modo se permite
una nueva y mejorada sustitución de métodos de administración sin tener que modificar
las implementaciones de los otros mecanismos de seguridad. Esto es de sobra conocido, dada
la larga historia de sutiles 'grietas' en protocolos de administración de claves
publicados.
Lo que sigue en esta sección es una
discusión breve de algunos enfoques alternativos para la administración de claves.
4.1 Distribución Manual
de Claves
La forma más simple de administración de claves es la administración de claves
manual, donde una persona configura manualmente cada sistema con su propia clave y con las
claves de otros sistemas de comunicación.
Esto es práctica habitual en entornos
estáticos, pequeños pero no de gran escala.
No es un enfoque viable a medio o largo plazo,
pero podría ser apropiado y útil en muchos entornos a corto plazo.
Por ejemplo, dentro de una LAN pequeña es
totalmente práctico configurar manualmente claves para cada si;stema. Dentro de un único
dominio administrativo es útil configurar claves para cada encaminador de modo que la
información de encaminamiento quede protegida y para reducir el riesgo de que un intruso
asalte un encaminador.
Otro caso podría ser una organización que
tenga un firewall de cifrado entre la red interna y la Internet en cada una de sus plantas
y se conecten dos o más plantas a través de la Internet.
En este caso, el firewall de cifrado podría
selectivamente cifrar tráfico por otras plantas dentro de la organización utilizando una
clave configurada manualmente, siempre y cuando no cifre tráfico con otros destinos.
Tambien podría ser apropiado cuando solamente se necesita garantizar ciertas
comunicaciones seleccionadas.
4.2 Algunas Técnicas de Administración
de Claves Existentes
Hay varios algoritmos de administración de claves descritos en literarura de tipo
público.
Needham y Schroeder han propuesto un algoritmo
de administración de claves que confía en un sistema de distribución de claves
centralizado. Este algoritmo es utilizado en el Sistema de Autenticación de Kerberos
desarrollado en MIT bajo el Proyecto Athena.
Más recientemente, Diffie y Hellman han
ideado un algoritmo que no requiere de un sistema de distribución de claves centralizado.
Lamentablemente, la técnica original de
Diffie-Hellman es vulnerable a un activo ataque "man in the middle". Sin
embargo, esta vulnerabilidad puede ser mitigada usando la firma de claves (firma digital)
para la autenticación de bootstrap en el intercambio Diffie-Hellman.
4.3 Distribución automatizada de claves
La distribución y uso extendido de seguridad de IPV6 requerirá un protocolo de
distribución de claves acoplable a la Internet estándar. Idealmente, tal protocolo
sostendría un número de protocolos en la pila de protocolos de Internet, no sólo en la
seguridad de IPv6.
Hay trabajo en camino dentro del IETF para
añadir claves de máquinas asignadas al Sistema de Nombres de Dominio (DNS).
Las claves de DNS permiten que la parte original
pueda autenticar mensajes de administración de claves con la otra parte de
administración de claves utilizando un algoritmo asimétrico. Entonces, las dos partes
tendrían un canal de comunicaciones autenticable que podría emplearse para crear una
clave de sesión compartida utilizando Diffie-Hellman u otros medios.
Hay dos enfoques de claves para IPv6:
El primer enfoque, llamado clave
host-to-host, tiene a todos los usuarios que comparten la misma clave en la máquina 1
para el uso en tráfico destinado a todos los usuarios en la máquina 2.
El segundo enfoque, llamado clave
user-to-user, permite al usuario A en la máquina 1 tener una clave de sesión única con
el usuaruio B en la máquina 2 que no está compartida con otros usuarios en host 1.
En muchos casos, un sistema de computación
único tendrá al menos dos usuarios A y B mutuamente desconfiados (que no confían el uno
en el otro). Cuando se utiliza la clave host-to-host y existen usuarios mutuamente
desconfiados, es posible por parte del usuario A averiguar la clave host-to-host por
medios bien conocidos, como un ataque Chosen Plaintext. Una vez el usuario A ha obtenido
impropiamente la clave en uso, el usuario A puede entonces o bien leer el tráfico cifrado
del usuario B o bien falsificar tráfico del usuario B. Cuando se utiliza una clave
host-to-host, este tipo de ataques de un usuario al tráfico de otro usuario no es
posible. Por tanto, se deduce que las claves host-to-host deberían estar presentes en
todas las instrumentaciones de IPv6, como está descrito más adelante en "IPv6 Key
Management Requirements".
4.4 Distribución de
Claves de Multicast
La Distribución de Claves de Multicast es un área de investigación activa en la
literatura. Para grupos de multicast que tienen relativamente pocos miembros, la
distribución manual de claves o el uso de múltiples algoritmos de distribución de
claves unicast existentes, como los Diffie-Hellman modificados, parecen posibles. Para
muchos grupos, las nuevas técnicas de adaptación son necesarias. El uso de Core-Based
Trees (CBT) para proporcionar administración de claves de sesión así como
encaminamiento multicast sería un enfoque posible en el futuro.
4.5 Requisitos de Administración de
claves de IPv6
Esta sección define requisitos de administración de claves para todas las
instrumentaciones de IPv6. Esto se aplica igualmente a la Cabecera de Autenticación de
IPv6 y al Encapsulating Security Payload de IPv6.
Todas las implementaciones de IPv6
TIENEN que soportar una administración de claves manual.
Todas las implentaciones de IPv6 DEBERÍAN
soportar un protocolo de administración de claves estándar de Internet una vez que este
último sea definido.
Todas las implementaciones de IPv6 TIENEN
que permitir la configuración y uso de claves user-to-user para el tráfico originado en
el mismo sistema y PODER permitir adicionalmente la configuración de claves host-to- host
para el tráfico originado en ese sistema como una característica añadida para hacer la
distribución manual de claves más facil y dar al administrador del sistema más
flexibilidad.
Un dispositivo que cifre o autentique
paquetes de IPv6 originados en otros sistemas, como por ejemplo un cifrador IP dedicado o
un gateway cifrador, por lo general no puede proporcionar claves user-to-user para el
tráfico originado en otros sistemas. Por tanto, tales sistemas TIENEN que implementar
claves host-to-host para tráfico originado en otros sistemas y PODER implementar claves
user-to-user para el tráfico originado en otros sistemas.
El método por medio del cual las claves son
configuradas en un sistema particular quedará definido en la implementación. Un archivo
'plano' que incluya identificadores de asociación de seguridad y los parámetros de
seguridad, incluyendo la(s) clave(s), es un ejemplo de un posible método para la
distribución manual de claves.
Un sistema IPv6 TIENE que dar pasos
razonables para proteger las claves y otra información de seguridad, ya que toda la
seguridad radica en las claves.
5. USO
Esta sección describe el uso de los posibles mecanismos de seguridad suministrados por
IPv6 en diferentes entornos y aplicaciones para dar al implementador y al usuario una
mejor idea de cómo estos mecanismos pueden utilizarse para reducir riesgos de seguridad.
5.1 USO CON FIREWALLS
Los firewalls son habituales en la actual Internet. Los dos mecanismos de IPv6 pueden
utilizarse para aumentar la seguridad suministrada por los firewalls.
Los firewalls usados con IPv6 deberán poder
analizar la cabecera daisy-chain para determinar el protocolo de transporte (p.e. UDP o
TCP) en uso y el número de puerto para esos protocolos. La función de Firewall no
debería verse afectada significativamente por el uso de IPv6, debido a que las reglas de
formato de cabecera de IPv6 hacen un análisis fácil y rápido.
Los firewalls pueden utilizar la Cabecera de
Autenticación para asegurarse de que la información (p.e. emisor, destino, protocolo de
transporte, número de puerto) que se utiliza para decisiones de control de acceso es
correcta y auténtica. La autenticación podría estar desempeñada no solamente dentro de
una organización o campus sino también con sistemas remotos a traves de Internet
mediante conexiones "end to end". Este uso de la Cabecera de Autenticación con
IPv6 proporciona mucha más seguridad que la que facilita IPv4.
Organizaciones con dos o más plantas que se
interconectan utilizando un servicio de IP comercial podrían desear utilizar un firewall
para el cifrado selectivo. Si entre cada planta de una determinada empresa y su proveedor
de servicios IP se situase un firewall de cifrado, este podría proporcionar un túnel de
IP de cifrado entre todas las plantas de la empresa; podría también cifrar tráfico
entre dicha empresa y sus suministradores, clientes y otros afiliados. El tráfico con el
NIC, con el archivo público de Internet, o alguna otra organización no podría ser
cifrado debido a la no disponibilidad de un protocolo de administración de claves
estándar o al deseo de facilitar unas mejores comunicaciones, unas funciones mejoradas de
red, y aumento de la conectividad. Tal práctica puede proteger fácilmente el tráfico
sensible de la organización de posibles caídas y modificaciones.
Algunas organizaciones (como gobiernos)
podrían desear utilizar completamente un firewall de cifrado para dar lugar a una red
virtual protegida sobre el servicio comercial de IP. La diferencia entre esto y un
dispositivo de cifrado de IPv6 es que un firewall dedicado al cifrado proveería
filtraciones del tráfico descifrado así como ofrecería cifrado de paquetes de IP.
5.2 USO CON IPV6 MULTICAST
En los últimos años, la Multicast Backbone (MBONE) ha crecido rápidamente. Las
reuniones de IETF y otras conferencias son ahora regularmente de tipo multicast con audio
en tiempo-real, video, y whiteboards. Mucha gente está utilizando ahora aplicaciones de
teleconferencia basadas en IP MULTICAST en la Internet o en redes internas privadas. Por
tanto, es importante que los mecanismos de seguridad en IPv6 sean apropiados para su uso
en un entorno donde el tipo multicast es el caso general.
Los Security Association Identifiers (SAIDS),
utilizados en mecanismos de seguridad de IPv6 están orientados al receptor, haciéndolos
apropiados para uso en multicast IP. Lamentablemente, los protocolos de distribución de
claves multicast actualmente publicados no se adaptan bien. Sin embargo, hay una
investigación activa en este área. Como paso interno, un grupo multicast podría
utilizar repetidamente un protocolo seguro de distribución de claves unicast para
distribuir la clave a todos los miembros, o el grupo podría prearrancar claves utilizando
una distribución de claves manual.
5.3 USO PARA PROPORCIONAR
PROTECCION QOS
El IAB Security Workshop identifica la protección de Quality of Service como un área
de interés significativo. Los dos mecanismos de seguridad de IPv6 están buscando
proporcionar un buen soporte para servicios en tiempo real así como de multicast. Esta
sección describe un posible enfoque para ofrecer dicha protección.
La Cabecera de Autenticación puede utilizarse,
con una administración de claves apropiada, para proveer autenticación de paquetes. Esta
autenticación es potencialmente importante para la clasificación de paquetes dentro de
routers.
El IPv6 Flow Identifier puede actuar como
Low-Level Identifier (LLID).
Usados los dos conjuntamente, la clasificación
de paquetes dentro de encaminadores se convierte en algo inmediato si el encaminador
contiene el material de claves apropiado. Por razones de eficiencia, los encaminadores
podrían autenticar solamente cada n paquetes (en lugar de autenticar cada paquete), pero
ésta es una mejora aún más significativa sobre las características de la actual
Internet. El QOS es apropiado también para utilizar el Flow ID conjuntamente con un
protocolo para reservar recursos, como podría ser RSVP. Así, la clasificación del
paquete autenticado puede utilizarse para ayudar a garantizar que cada paquete reciba una
manipulación apropiada dentro de los encaminadores.
6. CONSIDERACIONES DE SEGURIDAD
Toda esta página discute la Arquitectura de Seguridad de IPv6.
Los usuarios deben entender que la calidad de la
seguridad suministrada por los mecanismos de IPv6 depende completamente de la fortaleza de
los algoritmos criptográficos implementados, la robustez de la clave que se utiliza, la
implementación correcta de los algoritmos criptograficos, la seguridad del protocolo de
administración de claves y la implementación correcta de IPv6 y los distintos mecanismos
de seguridad de todos los sistemas que intervienen.
La seguridad de la implementación está en
parte relacionada con la seguridad del sistema operativo que encarna las implementaciones
de seguridad. Por ejemplo, si el sistema operativo no mantiene la confidencialidad de las
claves cifradas privadas, entonces el tráfico que utilice dichas claves no va a ser
seguro. Si cualquiera de éstas fuera incorrecta o insuficientemente segura, poca o
ninguna seguridad real tendría el usuario. Debido a que diferentes usuarios del mismo
sistema podrían no confiar unos en otros, cada usuario o cada sesión debería trabajar
generalmente con claves separadas. Esto también tenderá a aumentar el trabajo requerido
para criptoanalizar el tráfico, ya que no todo tráfico utilizará la misma clave.
Ciertas propiedades de seguridad (como
protección del análisis de tráfico) no las pueden aportar estos mecanismos. Un enfoque
posible para la protección contra el análisis de tráfico es un uso adecuado del cifrado
de enlace. Los usuarios tienen que considerar cuidadosamente qué propiedades de seguridad
quieren y tomar pasos activos para garantizar que sus necesidades se encuentran en estos u
otros mecanismos.
Ciertas aplicaciones (como correo
electrónico) necesitan probablemente mecanismos de seguridad específicos para cada
aplicación. Estos mecanismos están fuera del alcance de la Arquitectura de Seguridad de
IPv6. Los usuarios interesados en mecanismos de seguridad de correo electrónico
específicos de una aplicación pueden consultar RFCs que los describan.
===========================================================
Sr-Ice (1998)
Monografías
