ES2277495B1 - Mecanismos de direccionamiento en ip movil. - Google Patents
Mecanismos de direccionamiento en ip movil. Download PDFInfo
- Publication number
- ES2277495B1 ES2277495B1 ES200450025A ES200450025A ES2277495B1 ES 2277495 B1 ES2277495 B1 ES 2277495B1 ES 200450025 A ES200450025 A ES 200450025A ES 200450025 A ES200450025 A ES 200450025A ES 2277495 B1 ES2277495 B1 ES 2277495B1
- Authority
- ES
- Spain
- Prior art keywords
- node
- address
- public
- certificate
- private key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- VJYFKVYYMZPMAB-UHFFFAOYSA-N ethoprophos Chemical compound CCCSP(=O)(OCC)SCCC VJYFKVYYMZPMAB-UHFFFAOYSA-N 0.000 title 1
- 238000013475 authorization Methods 0.000 claims abstract description 29
- 238000000034 method Methods 0.000 claims abstract description 25
- 230000006870 function Effects 0.000 description 9
- 230000011664 signaling Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 230000008569 process Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000009131 signaling function Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H04L29/12009—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un método de delegar responsabilidad de una dirección IP propiedad de un primer nodo de red IP a un segundo nodo de red IP, pudiendo derivarse al menos una parte de la dirección IP de una clave pública de un par de claves pública/privada perteneciente al primer nodo. El método incluye notificar al primer nodo una clave pública de un par de claves pública/privada peteneciente al segundo nodo, en el primer nodo, firmar la clave pública del segundo nodo con la clave privada del primer nodo para proporcionar un certificado de autorización, y enviar el certificado de autorización del primer nodo al segundo nodo, donde el certificado de autorización recibe después mensajes referentes a dicha dirección IP y firmados con la clave privada del segundo nodo, enviada desde el segundo nodo o nodos receptores, y es utilizado por los nodos receptores para verificar la reivindicación del segundo nodo en la dirección IP.
Description
Mecanismos de direccionamiento en IP móvil.
La presente invención se refiere a mecanismos de
direccionamiento en IP móvil y más en particular a mecanismos de
direccionamiento que permiten a nodos de red IP probar que están
autorizados para alterar o actualizar información relativa a una
dirección IP propiedad de otro nodo de red.
El crecimiento masivo de la utilización de
Internet ha expuesto las debilidades y limitaciones del protocolo
de Internet corriente conocido como IPv4. Por lo tanto, Internet
Engineering Task Force (IETF), que es una conexión distribuida de
partes interesadas, está desarrollando un protocolo de Internet
mejorado denominado IPv6. IPv6 incorpora un mecanismo de seguridad
muy mejorado denominado IPSec (que permite a dos o más partes
comunicar con seguridad por Internet) así como provisiones para
acceso a Internet por móvil (IP móvil). IP móvil permite a los
usuarios acceder a Internet en movimiento, itinerando de un nodo de
acceso IP a otro. El IP móvil será utilizado en particular por
quienes acceden a mediante dispositivos móviles inalámbricos
(conectados por ejemplo a LANs inalámbricas y redes de teléfonos
celulares).
IPv6 proporciona un espacio de dirección IP
mucho más grande, proporcionando direcciones IP de 128 bits de
longitud. Los primeros 64 bits de una dirección forman un prefijo
de enrutamiento que identifica de forma única nodo de acceso a
Internet (denominado "enlace local") usado por un terminal IP
o host, mientras los últimos 64 bits forman un sufijo de host que
identifica de forma única el terminal móvil al nodo de acceso (o
dentro del enlace local). El sufijo host se denomina un
"identificador de interface" porque identifica el host
únicamente por la interface de acceso. Típicamente, cuando un host
se registra con un nodo de acceso, el host aprende el prefijo de
enrutamiento del nodo de acceso de un mensaje de aviso enviado
desde el nodo de acceso. Según RFC3041(IETF), un host genera
después su identificador de interface usando un número aleatorio
generado por el host. El host puede utilizar, además, una dirección
de capa de enlace para generar el identificador de interface,
siendo la dirección de capa de enlace por ejemplo una dirección de
capa MAC usada por la red de acceso.
Como ya se ha mencionado, IP móvil permite a
hosts itinerar entre nodos de acceso e incluso redes de acceso,
una característica que requiere que los hosts puedan cambiar las
direcciones IP que definen sus posiciones físicas corrientes.
Típicamente, a un host móvil se le asigna una dirección IP de
origen "fija" en una red doméstica. Cuando el host está en
origen, puede utilizar esta dirección de origen como su dirección
física. Sin embargo, cuando un host se une a un nodo de acceso
"extraño", al host se le asigna una "dirección actual"
temporal. Los hosts correspondientes al host móvil mantienen una
cache de enlace conteniendo aplicaciones entre direcciones de
origen y direcciones actuales. Para paquetes entrantes, la capa IP
móvil en un host correspondiente intercambia la dirección actual
por la dirección de origen en el campo de destino, mientras para
paquetes salientes la capa IP móvil a un host correspondiente
intercambia la dirección de origen por la dirección actual en la
dirección de campo de destino. Cuando un host móvil obtiene una
nueva dirección actual, debe enviar un mensaje de actualización de
enlace a todos los hosts correspondientes para actualizar sus
caches de enlace (garantizando así que se envíen los datagramas
siguientes a la dirección actual correcta). Se ilustra un escenario
IP móvil en la figura 1.
Un riesgo potencial de este mecanismo es que una
tercera parte maliciosa puede ser capaz de enviar una
actualización de enlace falsificada a un host correspondiente para
hacer que los paquetes de datos destinados a un host móvil sean
enrutados a la parte maliciosa. Si los paquetes son enviados
después al host móvil por la parte maliciosa (después de ser
abiertos y leídos por dicha parte), el host móvil ni siquiera puede
conocer que sus paquetes están siendo re-enrutados
y leídos. Este problema no se limita a IP móvil, sino que también
está presente en otras funciones de señalización dentro de la
arquitectura IPv6. El problema relacionado con IP móvil y algunos
de los otros problemas se describen con más detalle en el documento
presentado IETF
"draft-nikander-ipng-address-ownership-00.txt"
de febrero de 2001.
Una solución a este problema se ha propuesto en
el documento IETF presentado
"draftbradner-pbk-frame-00.txt"
de febrero de 2001. Implica generar en el host móvil un par de
claves bajo encargo (PBK) incluyendo una clave pública y otra
privada. Se genera una ID de Punto Final (EID) al host móvil
aplicando una elección arbitraria a la clave pública. La EID se
envía a un host correspondiente inmediatamente después del inicio
de una conexión IP. Después, el host móvil envía la clave pública
al host correspondiente. El host correspondiente es capaz de
verificar que la clave pública "pertenece" a la conexión
aplicando la función de codificación unidireccional a la clave y
comparando el resultado con la EID previamente recibida. Cualquier
actualización de enlace que se envíe después, es firmada en el host
móvil con la clave privada del host. El host correspondiente
verifica la firma unida a la actualización de enlace usando la
clave pública previamente recibida. Se han descrito mejores
soluciones que ofrecen mayor seguridad en: P. Nikander,
<draft-nikander-ipngpbk-addresses-00.txt>,
Ericsson Nomadiclab, marzo 2001, "A Scaleable Architecture for
IPv6 Address Ownership"; G. Montenegro, C. Castelluccia, 20
julio 2001, SUCV Identifiers and Addresses, Internet Draft (Work In
Progress); y M. Roe. Microsoft, agosto 2001, "Authentication of
Mobile IPv6 Binding Updates and Acknowledgements", Internet
Draft (Work In Progress), http://www.
Ietf.org/internet-drafts/draft-roe-Mobile
IP-updateauth-00.txt.
Las soluciones identificadas en el párrafo
anterior pueden tratar solamente el caso en el que el propietario
de la dirección envía la Actualización de Enlace. Sin embargo, hay
unas pocas situaciones donde es necesario que otros nodos envíen
estas notificaciones por cuenta del propietario real. Por ejemplo,
los servidores DHCP que administran un grupo de direcciones, poseen
las direcciones, pero todavía desearían permitir a los usuarios de
las direcciones beneficiarse de movilidad (véase la figura 2).
Además, un nodo podría estar detrás de un router móvil y tendría
que delegar la Actualización de Enlace enviándola a este router,
aunque la dirección real sea propiedad del nodo propiamente dicho
(figura 3, donde un nodo móvil MN se ha movido de un primer Router
de Acceso #1 a un segundo Router de Acceso AR#2).
Lo que es común a las dos situaciones descritas
es que la delegación de responsabilidad de la dirección IP es
limitada y condicional. Un router no puede enviar Actualizaciones
de Enlace después de que un nodo ha salido de la red controlada por
el router. El servidor DHCP no permite que un nodo envíe una
Actualización de Enlace con respecto a una dirección dada, después
de que dicha dirección ha sido liberada por el nodo y dada a algún
otro
nodo.
nodo.
Según un primer aspecto de la presente invención
se facilita un método de delegar responsabilidad de una dirección
IP propiedad de un primer nodo de red IP en un segundo nodo de red
IP, pudiendo derivarse al menos una parte de la dirección IP de una
clave pública de un par de claves pública/privada perteneciente al
primer nodo, incluyendo el método:
notificar al primer nodo una clave pública de un
par de claves pública/privada perteneciente al segundo nodo;
en el primer nodo, firmar la clave pública del
segundo nodo con la clave privada del primer nodo para proporcionar
un certificado de autorización; y
enviar el certificado de autorización del primer
nodo al segundo nodo,
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y se firma
con la clave privada del segundo nodo, y dicho certificado es
enviado desde el segundo nodo a nodos receptores, y es utilizado
por los nodos receptores para autenticar el mensaje.
En una realización de la presente invención,
dicho primer nodo de red IP es un servidor DHCP, y dicho segundo
nodo de red IP es un nodo cliente, por ejemplo un terminal móvil
(por ejemplo teléfono móvil, PDA, comunicador, ordenador de
bolsillo, u ordenador portátil) o un PC. El nodo cliente se puede
conectar a una red IP mediante una línea fija o un enlace
inalámbrico. En una segunda realización de la invención, dicho
primer nodo de red IP es un nodo cliente y dicho segundo nodo de
red IP es un router móvil.
Preferiblemente, una parte Identificadora de
Interface de dicha dirección IP se puede derivar de la clave
pública del par de claves pública/privada perteneciente al primer
nodo, por ejemplo aplicando una función unidireccional a dicha
clave pública.
Preferiblemente, el método de la presente
invención facilita el envío de mensajes de actualización de enlace
según el protocolo IP móvil, por el segundo nodo con respecto a
dicha dirección IP. Tales mensajes de actualización de enlace
incluyen el certificado de autorización, dicha dirección IP, y una
nueva dirección actual. El certificado puede incluir la clave
pública del primer nodo y que se requiere a autenticar el
certificado.
Dicho certificado se puede derivar firmando, con
la clave privada del primer nodo (o propietario), una combinación
de la clave pública del segundo nodo (u originante) y un sello de
tiempo, siendo el sello de tiempo el tiempo en el que expira la
autorización para usar la dirección IP.
Según un segundo aspecto de la presente
invención se facilita un método de autenticar un mensaje recibido
en un nodo receptor de una red IP de un nodo originante, estando
relacionado el mensaje con una dirección IP e incluyendo
dicha dirección IP,
una clave pública de un par de claves
pública/privada perteneciente al nodo propietario de la dirección
IP, y
un certificado concedido al nodo originante por
el nodo propietario y derivado firmando la clave pública de un par
de claves pública/privada perteneciente al nodo originante con la
clave privada del nodo propietario,
firmándose el mensaje con la clave privada del
nodo originante, incluyendo el método:
confirmar que al menos una parte de dicha
dirección IP se puede derivar de la clave pública del nodo
propietario;
confirmar que dicho certificado está firmado con
la clave privada del nodo propietario; y
confirmar que el mensaje está firmado con la
clave privada del nodo originante.
Donde dicho certificado se deriva firmando la
clave pública del par de claves pública/privada perteneciente al
nodo originante y un sello de tiempo, el nodo receptor puede
confirmar que el sello de tiempo no ha expirado antes de actuar en
el mensaje.
Según un tercer aspecto de la presente invención
se facilita un terminal cliente IP dispuesto en la práctica para
alquilar una dirección IP de otro nodo de red IP, pudiendo
derivarse al menos una parte de la dirección IP de una clave
pública de un par de claves pública/privada perteneciente al nodo
propietario, incluyendo el terminal cliente:
medios para notificar al nodo propietario de una
clave pública de un par de claves pública/privada perteneciente al
terminal cliente;
medios para recibir del nodo propietario un
certificado de autorización incluyendo la clave pública del
terminal cliente firmado con la clave privada del nodo
propietario;
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del terminal cliente, siendo dicho
certificado enviado desde el terminal cliente a nodos receptores, y
es utilizado por los nodos receptores para autenticar la
reivindicación del terminal cliente en la dirección
IP.
IP.
Según un cuarto aspecto de la presente invención
se facilita un terminal cliente IP dispuesto en la práctica para
autorizar a un nodo de red IP delegado a que utilice una dirección
IP propiedad del terminal cliente, pudiendo derivarse al menos una
parte de la dirección IP de una clave pública de un par de claves
pública/privada perteneciente al terminal cliente, incluyendo el
terminal cliente:
medios para recibir de dicho nodo delegado una
clave pública de un par de claves pública/privada perteneciente al
nodo delegado;
medios para generar un certificado de
autorización incluyendo la clave pública del nodo delegado firmada
con la clave privada del terminal cliente, y para enviar el
certificado al nodo delegado;
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del nodo delegado, y dicho certificado es
enviado desde el nodo delegado a nodos receptores, y es utilizado
por los nodos receptores para autenticar el mensaje.
Según un quinto aspecto de la presente invención
se facilita un servidor IP dispuesto en la práctica para autorizar
un nodo IP cliente a utilizar una dirección IP propiedad del
servidor, pudiendo derivarse al menos una parte de la dirección IP
de una clave pública de un par de claves pública/privada
perteneciente al servidor, incluyendo el
servidor:
servidor:
medios para recibir de dicho terminal cliente
una clave pública de un par de claves pública/privada perteneciente
al terminal cliente;
medios para generar un certificado de
autorización incluyendo la clave pública del terminal cliente
firmada con la clave privada del servidor, y para enviar el
certificado al terminal cliente;
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del terminal cliente, siendo dicho
certificado enviado desde el terminal cliente a nodos receptores, y
es utilizado por los nodos receptores para autenticar el
mensaje.
Según un sexto aspecto de la presente invención
se facilita un servidor IP dispuesto en la práctica para asumir
responsabilidad de una dirección IP propiedad de un terminal
cliente, pudiendo derivarse al menos una parte de la dirección IP
de una clave pública de un par de claves pública/privada
perteneciente al terminal cliente, incluyendo el servidor:
medios para enviar a dicho terminal cliente una
clave pública de un par de claves pública/privada perteneciente al
servidor;
medios para recibir del terminal cliente un
certificado de autorización incluyendo la clave pública del
servidor firmada con la clave privada del terminal cliente;
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del servidor, y dicho certificado es enviado
desde el servidor a nodos receptores, y es utilizado por los nodos
receptores para autenticar el mensaje.
La figura 1 ilustra esquemáticamente los
principios de enrutamiento IP móvil.
La figura 2 ilustra esquemáticamente los
principios de enrutamiento IP móvil donde una dirección IP es
propiedad y es asignada por un servidor DHCP, y
La figura 3 ilustra esquemáticamente los
principios de enrutamiento IP móvil donde un nodo móvil está situado
detrás de un router móvil.
La figura 4 es un diagrama de señalización que
representa señalización entre un nodo móvil, un servidor DHCP y un
nodo correspondiente.
Y la figura 5 es un diagrama de señalización que
representa señalización entre un nodo móvil, un router móvil y un
nodo correspondiente.
A los efectos de los ejemplos siguientes se
supone que un nodo de red IP propietario de una dirección IP posee
un par de claves pública/privada donde P denota la clave pública y
S denota la clave privada o secreta. El nodo genera la dirección IP
usando el algoritmo A = R: h(P), donde R es algún prefijo de
enrutamiento que puede pertenecer al nodo propiamente dicho o que
se puede recibir en el nodo de algún otro nodo (por ejemplo, un
nodo de acceso). La función h es alguna función unidireccional, tal
como una dispersión criptográfica. Cuando el nodo (propietario de
la dirección IP) envía una actualización de enlace a un nodo
correspondiente según el protocolo IP móvil, incluye en el mensaje
su clave pública P. El nodo emisor genera además una firma
aplicando alguna función criptográfica reversible y la clave
secreta S al contenido del mensaje, y añade la firma al
mensaje.
Cuando el nodo correspondiente recibe la
actualización de enlace verifica primero que la firma es correcta
aplicando a la firma la función criptográfica reversible y la clave
pública P contenida en el mensaje. Suponiendo que el resultado
corresponda al contenido del mensaje, y el nodo correspondiente
verifica por lo tanto que el nodo emisor posee la clave pública S
reivindicada, el nodo correspondiente aplica la función
unidireccional h a la clave pública para confirmar que la parte host
de la dirección IP fuente ha sido generada por el propietario del
par de claves (P, S). Aunque es posible que un atacante repase todos
los pares de claves posibles (P, S) intentando hallar una que
produzca el mismo valor de h (P), dado que el campo de bits
utilizado para almacenar h (P) en Ipv6 es muy grande (62 bits),
habría que realizar una inmensa cantidad de trabajo para
lograrlo.
Los servidores DHCP gestionan un grupo de
direcciones IP, que poseen y "alquilan" estas direcciones
temporalmente a nodos clientes, tal como PCs conectados a una red
particular. Aplicando las consideraciones anteriores a este
escenario (ilustrado en la figura 2), será el servidor DHCP quien
posea los pares de clave pública-privada (P, S) que
se utilizan para generar respectivas direcciones IP.
Para permitir que un nodo cliente detrás de un
servidor DHCP utilice movilidad y Actualizaciones de Enlace, se
emplea el procedimiento siguiente:
- 1.
- El cliente y el servidor DHCP acuerdan que una dirección particular sea alquilada por el cliente durante un cierto tiempo. La dirección A contiene una parte identificadora de interface que está asociada con el par de claves (P, S) propiedad del DHCP, es decir A = R:h(P).
- 2.
- El cliente puede ser autenticado opcionalmente durante este proceso.
- 3.
- El cliente posee un par de claves pública-privada (Pcl, Scl) y da su clave pública Pcl al servidor DHCP durante este proceso. El par de claves pública-privada puede haberse generado precisamente para ello, o puede ser asignada permanentemente al cliente.
- 4.
- El servidor DHCP crea un certificado para que Pcl administre la dirección relacionada con P. Es decir, el servidor firma la tupla [Pcl, tiempo final] con su clave privada S, donde el tiempo final identifica el tiempo de expiración de la dirección IP asignada. El certificado, conteniendo P y la firma, se envía al cliente.
- 5.
- Cuando el nodo cliente desea a enviar una Actualización de Enlace a algún nodo correspondiente, firma la petición con su clave privada Scl y une el certificado (creado en el paso 4) al mensaje.
- 6.
- El nodo que recibe la Actualización de Enlace verifica primero que el valor de la parte identificadora de interface de la dirección IP del emisor se refiere a la clave pública P, aplicando a la clave pública P la función unidireccional h que es conocida por el nodo correspondiente. El nodo receptor utiliza entonces la clave pública P del DHCP para verificar que el certificado está firmado correctamente con la correspondiente clave secreta S y recupera la clave pública Pcl del emisor y el tiempo final válido. Suponiendo que el tiempo final no ha expirado, el nodo receptor verifica que la firma en la Actualización de Enlace se produjo con la clave privada Scl correspondiente a la clave pública Pcl contenida en el certificado, probando así que el nodo emisor posee la clave pública Pcl. El nodo receptor actualiza después su cache de enlace con la nueva dirección actual.
El procedimiento puede ser ilustrado con el
siguiente flujo de señalización que se ilustra en la figura 4:
- 1.
- Cliente-Servidor: Petición; duración = T, clave pública del cliente = Pcl
- 2.
- Servidor-Cliente: Respuesta; dirección = A, certificado = P,{[Pcl, tiempo final] firmado con S}
- 3.
- Cliente-Otro nodo: Actualización de Enlace; dirección actual, dirección = A, certificado, firma en todo el mensaje con Scl.
Los nodos pueden estar situados a veces detrás
de un router móvil (MR) como se ilustra en la figura 2, y como el
router es responsable de administrar la conectividad a Internet,
puede tener que enviar Actualizaciones de Enlace en nombre de los
nodos. El nodo también puede salir de detrás del router móvil, en
cuyo caso el router ya no deseará ofrecer este servicio. Un
procedimiento para permitir que el router móvil envíe temporalmente
un mensaje de enlace por cuenta de un nodo es el siguiente:
- 1.
- El nodo y el router acuerdan una(s) dirección(es) particular(es) que está detrás del router durante un cierto tiempo, y que la administración de movilidad sea realizada por el router. La dirección está asociada con el par de claves (P, S) propiedad del nodo.
- 2.
- El nodo y el router pueden ser autenticados opcionalmente entre sí durante este proceso.
- 3.
- El router da su propia clave pública Pr al nodo durante este proceso. Esta clave pública es asignada típicamente permanentemente al router. El router conoce también la clave secreta Sr.
- 4.
- El nodo crea un certificado para que Pr administre la dirección relacionada con P. Es decir, el nodo firma la tupla [Pr, tiempo final] con S. El certificado incluye: P y la firma.
- 5.
- Cuando el router desea enviar una Actualización de Enlace a algún nodo correspondiente por Internet, firma la petición con Sr y une el certificado creado en el paso 4 al mensaje.
- 6.
- El nodo correspondiente que recibe la Actualización de Enlace verifica primero que el valor de la parte identificadora de interface de la dirección IP de nodo (contenida en el mensaje de actualización de enlace) se refiere a la clave pública P, aplicando a la clave pública P la función unidireccional h que es conocida por el nodo correspondiente. El nodo receptor utiliza la clave pública P para verificar que el certificado está firmado correctamente con la correspondiente clave secreta S y recupera la clave pública del router emisor Pr y el tiempo final válido. Después, verifica que la firma en la Actualización de Enlace se produjo con la clave privada Sr correspondiente a la clave pública Pr contenida en el certificado, probando así que el router emisor posee la clave pública Pr. Suponiendo que el tiempo final no ha expirado, el nodo receptor actualiza su cache de enlace con la nueva dirección actual.
El procedimiento puede ser ilustrado con el
siguiente flujo de señalización que también se ilustra en la figura
5:
- 1.
- Router-Nodo: Ofrecer servicio; duración = T, clave pública del router = Pr
- 2.
- Nodo-Router: Inicio; dirección = A, certificado = P, {[Pr, tiempo final) firmado con S}
- 3.
- Router-Otro nodo: Actualización de Enlace; dirección actual, dirección = A, firma en todo el mensaje con Sr.
Los expertos en la materia apreciarán que se
puede hacer varias modificaciones en las realizaciones antes
descritas sin apartarse del alcance de la presente invención.
Claims (12)
1. Un método de delegar responsabilidad de una
dirección IP propiedad de un primer nodo de red IP en un segundo
nodo de red IP, pudiendo derivarse al menos una parte de la
dirección IP de una clave pública de un par de claves
pública/privada perteneciente al primer nodo, incluyendo el
método:
notificar al primer nodo una clave pública de un
par de claves pública/privada perteneciente al segundo nodo;
en el primer nodo, firmar la clave pública del
segundo nodo con la clave privada del primer nodo para proporcionar
un certificado de autorización; y
enviar el certificado de autorización del primer
nodo al segundo nodo,
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del segundo nodo, y dicho certificado es
enviado desde el segundo nodo a nodos receptores, y es utilizado
por los nodos receptores para autenticar el mensaje.
2. Un método según la reivindicación 1, donde
dicho primer nodo de red IP es un servidor DHCP, y dicho segundo
nodo de red IP es un nodo cliente.
3. Un método según la reivindicación 1, donde
dicho primer nodo de red IP es un nodo cliente y dicho segundo
nodo de red IP es un router móvil.
4. Un método según cualquiera de las
reivindicaciones anteriores, donde una parte Identificadora de
Interface de dicha dirección IP se puede derivar de la clave
pública del par de claves pública/privada perteneciente al primer
nodo.
5. Un método según cualquiera de las
reivindicaciones anteriores, donde dichos mensajes son mensajes de
actualización de enlace según el protocolo IP móvil e incluyen el
certificado de autorización, dicha dirección IP, y una nueva
dirección actual.
6. Un método según cualquiera de las
reivindicaciones anteriores, donde dicho certificado se deriva
firmando, con la clave privada del primer nodo, una combinación de
la clave pública del segundo nodo y un sello de tiempo, siendo el
sello de tiempo el tiempo en el que expira la autorización para
usar la dirección IP.
7. Un método de autenticar un mensaje recibido
en un nodo receptor de una red IP de un nodo originante,
refiriéndose el mensaje a una dirección IP e incluyendo
dicha dirección IP,
una clave pública de un par de claves
pública/privada perteneciente al nodo que posee la dirección IP,
y
un certificado concedido al nodo originante por
el nodo propietario y derivado firmando la clave pública de un par
de claves pública/privada perteneciente al nodo originante con la
clave privada del nodo propietario,
firmándose el mensaje con la clave privada del
nodo originante, incluyendo el método:
confirmar que al menos una parte de dicha
dirección IP se puede derivar de la clave pública del nodo
propietario;
confirmar que dicho certificado está firmado con
la clave privada del nodo propietario; y
confirmar que el mensaje está firmado con la
clave privada del nodo originante.
8. Un método según la reivindicación 7, donde
dicho certificado se deriva firmando la clave pública del par de
claves pública/privada perteneciente al nodo originante y un sello
de tiempo, y el nodo receptor confirma que el sello de tiempo no ha
expirado antes de actuar en el mensaje.
9. Un terminal cliente IP dispuesto en la
práctica para alquilar una dirección IP de otro nodo de red IP,
pudiendo derivarse al menos una parte de la dirección IP de una
clave pública de un par de claves pública/privada perteneciente al
nodo propietario, incluyendo el terminal cliente:
medios para notificar al nodo propietario de una
clave pública de un par de claves pública/privada perteneciente al
terminal cliente;
medios para recibir del nodo propietario un
certificado de autorización incluyendo la clave pública del
terminal cliente firmada con la clave privada del nodo
propietario;
\newpage
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del terminal cliente, y dicho certificado es
enviado desde el terminal cliente a nodos receptores, y es
utilizado por los nodos receptores para autenticar el mensaje.
10. Un terminal cliente IP dispuesto en la
práctica para autorizar a un nodo de red IP delegado a que utilice
una dirección IP propiedad del terminal cliente, pudiendo derivarse
al menos una parte de la dirección IP de una clave pública de un
par de claves pública/privada perteneciente al terminal cliente,
incluyendo el terminal cliente:
medios para recibir de dicho nodo delegado una
clave pública de un par de claves pública/privada perteneciente al
nodo delegado;
medios para generar un certificado de
autorización incluyendo la clave pública del nodo delegado firmada
con la clave privada del terminal cliente, y para enviar el
certificado al nodo delegado;
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del nodo delegado, y dicho certificado es
enviado desde el nodo delegado a nodos receptores, y es utilizado
por los nodos receptores para autenticar el mensaje.
11. Un servidor IP dispuesto en la práctica para
autorizar a un nodo IP cliente que utilice una dirección IP
propiedad del servidor, pudiendo derivarse al menos una parte de la
dirección IP de una clave pública de un par de claves
pública/privada perteneciente al servidor, incluyendo el
servidor:
medios para recibir de dicho terminal cliente
una clave pública de un par de claves pública/privada perteneciente
al terminal cliente;
medios para generar un certificado de
autorización incluyendo la clave pública del terminal cliente
firmada con la clave privada del servidor, y para enviar el
certificado al terminal cliente;
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del terminal cliente, y dicho certificado es
enviado desde el terminal cliente a nodos receptores, y es
utilizado por los nodos receptores para autenticar los
mensajes.
12. Un servidor IP dispuesto en la práctica para
asumir responsabilidad de una dirección IP propiedad de un terminal
cliente, pudiendo derivarse al menos una parte de la dirección IP
de una clave pública de un par de claves pública/privada
perteneciente al terminal cliente, incluyendo el servidor:
medios para enviar a dicho terminal cliente una
clave pública de un par de claves pública/privada perteneciente al
servidor;
medios para recibir del terminal cliente un
certificado de autorización incluyendo la clave pública del
servidor firmada con la clave privada del terminal cliente;
donde el certificado de autorización se incluye
después con los mensajes referentes a dicha dirección IP y firmados
con la clave privada del servidor, y dicho certificado es enviado
desde el servidor a nodos receptores, y es utilizado por los nodos
receptores para autenticar el mensaje.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0125715 | 2001-10-26 | ||
GB0125715A GB2381423B (en) | 2001-10-26 | 2001-10-26 | Addressing mechanisms in mobile IP |
Publications (2)
Publication Number | Publication Date |
---|---|
ES2277495A1 ES2277495A1 (es) | 2007-07-01 |
ES2277495B1 true ES2277495B1 (es) | 2008-07-01 |
Family
ID=9924573
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES200450025A Expired - Fee Related ES2277495B1 (es) | 2001-10-26 | 2002-10-18 | Mecanismos de direccionamiento en ip movil. |
Country Status (6)
Country | Link |
---|---|
US (1) | US7401216B2 (es) |
CN (1) | CN100592746C (es) |
DE (1) | DE10297253T5 (es) |
ES (1) | ES2277495B1 (es) |
GB (1) | GB2381423B (es) |
WO (1) | WO2003036916A2 (es) |
Families Citing this family (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7561553B2 (en) * | 2002-02-27 | 2009-07-14 | Motorola, Inc. | Method and apparatus for providing IP mobility for mobile networks and detachable mobile network nodes |
GB2410660B (en) * | 2002-10-14 | 2005-10-19 | Toshiba Res Europ Ltd | Methods and systems for flexible delegation |
JP2004242019A (ja) * | 2003-02-05 | 2004-08-26 | Ntt Docomo Inc | 移動通信制御システム、ネットワーク管理サーバ、モバイルノード、アクセスノード及びアンカーノード |
KR100513863B1 (ko) * | 2003-04-29 | 2005-09-09 | 삼성전자주식회사 | 호스트의 이동성을 지원할 수 있는 무선 근거리 네트워크시스템 및 그의 동작방법 |
JP4425859B2 (ja) * | 2003-07-11 | 2010-03-03 | 日本電信電話株式会社 | アドレスに基づく認証システム、その装置およびプログラム |
US7873036B2 (en) * | 2004-02-03 | 2011-01-18 | Nokia Siemens Networks Oy | Method and apparatus to provide group management of multiple link identifiers for collective mobility |
US7991854B2 (en) * | 2004-03-19 | 2011-08-02 | Microsoft Corporation | Dynamic session maintenance for mobile computing devices |
US7549048B2 (en) * | 2004-03-19 | 2009-06-16 | Microsoft Corporation | Efficient and secure authentication of computing systems |
WO2005104487A1 (en) | 2004-04-14 | 2005-11-03 | Nortel Networks Limited | Mobile ipv6 authentication and authorization baseline |
WO2006018045A1 (en) * | 2004-08-20 | 2006-02-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Fast network attachment |
KR100636318B1 (ko) * | 2004-09-07 | 2006-10-18 | 삼성전자주식회사 | CoA 바인딩 프로토콜을 이용한 어드레스 오너쉽인증방법 및 그 시스템 |
GB2423448B (en) * | 2005-02-18 | 2007-01-10 | Ericsson Telefon Ab L M | Host identity protocol method and apparatus |
US7881468B2 (en) * | 2005-04-08 | 2011-02-01 | Telefonaktiebolaget L M Ericsson (Publ) | Secret authentication key setup in mobile IPv6 |
US7907948B2 (en) * | 2005-04-22 | 2011-03-15 | Telefonaktiebolaget L M Ericsson (Publ) | Providing anonymity to a mobile node in a session with a correspondent node |
US7925027B2 (en) * | 2005-05-02 | 2011-04-12 | Ntt Docomo, Inc. | Secure address proxying using multi-key cryptographically generated addresses |
US8098823B2 (en) * | 2005-05-03 | 2012-01-17 | Ntt Docomo, Inc. | Multi-key cryptographically generated address |
CN102395190B (zh) | 2005-07-08 | 2015-02-25 | 松下电器(美国)知识产权公司 | 移动节点和通信控制方法 |
JP2007189620A (ja) * | 2006-01-16 | 2007-07-26 | Kddi Corp | Ipアドレス管理サーバ、利用者端末、およびプログラム |
JP4890867B2 (ja) * | 2006-01-17 | 2012-03-07 | キヤノン株式会社 | 情報処理装置およびその制御方法 |
GB0601913D0 (en) * | 2006-01-31 | 2006-03-08 | Ericsson Telefon Ab L M | Packet re-direction in a communication network |
US7814311B2 (en) * | 2006-03-10 | 2010-10-12 | Cisco Technology, Inc. | Role aware network security enforcement |
DE602006010251D1 (de) * | 2006-05-24 | 2009-12-17 | Ericsson L M Oy | Mobilitätsverwaltung auf delegationsbasis |
US9179318B2 (en) | 2006-05-24 | 2015-11-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Delegation based mobility management |
US7958368B2 (en) * | 2006-07-14 | 2011-06-07 | Microsoft Corporation | Password-authenticated groups |
US8041942B2 (en) * | 2006-09-05 | 2011-10-18 | Panasonic Corporation | Robust peer-to-peer networks and methods of use thereof |
EP1906615A1 (en) * | 2006-09-29 | 2008-04-02 | Nokia Siemens Networks Gmbh & Co. Kg | Method and devices for delegating the control of protected connections |
US8307411B2 (en) * | 2007-02-09 | 2012-11-06 | Microsoft Corporation | Generic framework for EAP |
CN101242269B (zh) * | 2007-02-09 | 2011-12-07 | 西门子(中国)有限公司 | 预订电信服务的移动通信终端、服务提供商终端、系统及方法 |
US9628454B2 (en) | 2007-02-12 | 2017-04-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Signalling delegation in a moving network |
CN101022418B (zh) * | 2007-03-14 | 2010-05-26 | 华为技术有限公司 | Hmip认证方法、设备及系统 |
US8266427B2 (en) * | 2007-06-08 | 2012-09-11 | Cisco Technology, Inc. | Secure mobile IPv6 registration |
CN102739677B (zh) * | 2007-06-29 | 2015-09-09 | 华为技术有限公司 | 一种加密生成地址的配置方法、系统和装置 |
US9177313B1 (en) * | 2007-10-18 | 2015-11-03 | Jpmorgan Chase Bank, N.A. | System and method for issuing, circulating and trading financial instruments with smart features |
GB2454897A (en) * | 2007-11-22 | 2009-05-27 | Ericsson Telefon Ab L M | Cryptographically generated IP addresses |
WO2009068115A1 (en) * | 2007-11-30 | 2009-06-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods for secure sip signalling to a destination ip address being a cryptographi cally generated address (cga) |
US8893242B2 (en) * | 2008-04-29 | 2014-11-18 | Ebay Inc. | System and method for pool-based identity generation and use for service access |
CN101616006A (zh) * | 2009-07-31 | 2009-12-30 | 中兴通讯股份有限公司 | 证书管理方法、装置及系统 |
CN101631024A (zh) * | 2009-08-11 | 2010-01-20 | 中兴通讯股份有限公司 | 一种增强的证书管理方法和系统 |
US8498414B2 (en) * | 2010-10-29 | 2013-07-30 | Telefonaktiebolaget L M Ericsson (Publ) | Secure route optimization in mobile internet protocol using trusted domain name servers |
CN102368740A (zh) * | 2011-12-01 | 2012-03-07 | 北京交通大学 | 一种网络寻址方法 |
US10333696B2 (en) | 2015-01-12 | 2019-06-25 | X-Prime, Inc. | Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency |
JP7437722B2 (ja) * | 2019-01-31 | 2024-02-26 | コネクトフリー株式会社 | データ送信方法、通信処理方法、装置、および通信処理プログラム |
US10721198B1 (en) * | 2019-04-15 | 2020-07-21 | Microsoft Technology Licensing, Llc | Reducing avoidable transmission of an attachment to a message by comparing the fingerprint of a received attachment to that of a previously received attachment and indicating to the transmitting user when a match occurs that the attachment does not need to be transmitted |
US10721193B1 (en) * | 2019-04-15 | 2020-07-21 | Microsoft Technology Licensing, Llc | Reducing avoidable transmission of an attachment to a message by comparing the fingerprint of the attachment to be sent to that of an attachment that was previously sent or received by the user and indicating to the user when a match occurs that the attachment is redundant |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4759063A (en) * | 1983-08-22 | 1988-07-19 | Chaum David L | Blind signature systems |
US6035402A (en) * | 1996-12-20 | 2000-03-07 | Gte Cybertrust Solutions Incorporated | Virtual certificate authority |
US6513116B1 (en) * | 1997-05-16 | 2003-01-28 | Liberate Technologies | Security information acquisition |
US6292897B1 (en) * | 1997-11-03 | 2001-09-18 | International Business Machines Corporation | Undeniable certificates for digital signature verification |
US7032242B1 (en) * | 1998-03-05 | 2006-04-18 | 3Com Corporation | Method and system for distributed network address translation with network security features |
WO2001031472A1 (en) * | 1999-10-22 | 2001-05-03 | Telcordia Technologies, Inc. | Method and system for host mobility management protocol |
US6826690B1 (en) * | 1999-11-08 | 2004-11-30 | International Business Machines Corporation | Using device certificates for automated authentication of communicating devices |
FR2802666B1 (fr) * | 1999-12-17 | 2002-04-05 | Activcard | Systeme informatique pour application a acces par accreditation |
US6978364B1 (en) * | 2000-04-12 | 2005-12-20 | Microsoft Corporation | VPN enrollment protocol gateway |
US6925075B2 (en) * | 2000-07-31 | 2005-08-02 | Telefonaktiebolaget Lm Ericsson | Method and system for inter-operability between mobile IP and RSVP during route optimization |
KR100520141B1 (ko) * | 2000-10-26 | 2005-10-10 | 삼성전자주식회사 | 이동통신 시스템에서 고정 주소를 가지는 이동단말의 핸드오버 방법 |
US20020106085A1 (en) * | 2001-01-05 | 2002-08-08 | Sandeep Jain | Security breach management |
GB2367986B (en) * | 2001-03-16 | 2002-10-09 | Ericsson Telefon Ab L M | Address mechanisms in internet protocol |
US7203966B2 (en) * | 2001-06-27 | 2007-04-10 | Microsoft Corporation | Enforcement architecture and method for digital rights management system for roaming a license to a plurality of user devices |
US20030018964A1 (en) * | 2001-07-19 | 2003-01-23 | International Business Machines Corporation | Object model and framework for installation of software packages using a distributed directory |
-
2001
- 2001-10-26 GB GB0125715A patent/GB2381423B/en not_active Expired - Fee Related
-
2002
- 2002-10-18 WO PCT/SE2002/001904 patent/WO2003036916A2/en active IP Right Grant
- 2002-10-18 ES ES200450025A patent/ES2277495B1/es not_active Expired - Fee Related
- 2002-10-18 CN CN02821342A patent/CN100592746C/zh not_active Expired - Fee Related
- 2002-10-18 DE DE10297253T patent/DE10297253T5/de not_active Withdrawn
- 2002-10-23 US US10/277,945 patent/US7401216B2/en active Active
Non-Patent Citations (1)
Title |
---|
BRANDER, S. et al. A Framework for Purpose Built Keys (PBK). IETF Internet Engineering Task Force, The Internet Society, febrero de 2001, [en línea], [recuperado el 05.06.2007]. Recuperado de Internet <URL: http://tools.ietf.org/html/draft- bradner-pbk-frame-00> * |
Also Published As
Publication number | Publication date |
---|---|
GB0125715D0 (en) | 2001-12-19 |
US7401216B2 (en) | 2008-07-15 |
DE10297253T5 (de) | 2005-02-17 |
GB2381423A (en) | 2003-04-30 |
WO2003036916A2 (en) | 2003-05-01 |
ES2277495A1 (es) | 2007-07-01 |
CN100592746C (zh) | 2010-02-24 |
GB2381423B (en) | 2004-09-15 |
WO2003036916A3 (en) | 2003-11-13 |
CN1636378A (zh) | 2005-07-06 |
US20030084293A1 (en) | 2003-05-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2277495B1 (es) | Mecanismos de direccionamiento en ip movil. | |
US8549294B2 (en) | Securing home agent to mobile node communication with HA-MN key | |
US8514851B2 (en) | Mobile IPv6 authentication and authorization baseline | |
JP4756048B2 (ja) | プレフィックススコープバインディング更新をセキュアにするためのシステム及び関連方法並びに装置 | |
ES2349292T3 (es) | Procedimiento y servidor para proporcionar una clave de movilidad. | |
Montenegro et al. | Crypto-based identifiers (CBIDs) Concepts and applications | |
Deng et al. | Defending against redirect attacks in mobile IP | |
US9043599B2 (en) | Method and server for providing a mobility key | |
US20050190734A1 (en) | NAI based AAA extensions for mobile IPv6 | |
JP5144685B2 (ja) | 移動ネットワークにおけるシグナリング委任 | |
JP2004533741A (ja) | インターネットプロトコルのアドレス機構 | |
EP2253120A1 (en) | Re-establishment of a security association | |
Castelluccia et al. | Hindering eavesdropping via ipv6 opportunistic encryption | |
Qiu et al. | Authenticated binding update in Mobile IPv6 networks | |
Maekawa et al. | An enhanced location privacy framework with mobility using host identity protocol | |
DENG et al. | Defending against redirect attacks in mobile IP.(2002) | |
Georgiades et al. | Distributed authentication protocol for the security of binding updates in mobile IPv6 | |
MAEKAWA | A Location Privacy Protection Framework with Mobility using Host Identity Protocol | |
Al-Ka’bi | On Security in Wireless Mobile Networking | |
Deng et al. | Enforcing Security in Mobile Networks: Challenges and Solutions | |
NZ577864A (en) | Signalling delegation in a moving network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EC2A | Search report published |
Date of ref document: 20070701 Kind code of ref document: A1 |
|
FG2A | Definitive protection |
Ref document number: 2277495B1 Country of ref document: ES |
|
FD2A | Announcement of lapse in spain |
Effective date: 20211122 |