ES2344870T3 - Control de mensaje a transmitir desde un dominio de emisor hacia un dominio de destinatario. - Google Patents
Control de mensaje a transmitir desde un dominio de emisor hacia un dominio de destinatario. Download PDFInfo
- Publication number
- ES2344870T3 ES2344870T3 ES07858490T ES07858490T ES2344870T3 ES 2344870 T3 ES2344870 T3 ES 2344870T3 ES 07858490 T ES07858490 T ES 07858490T ES 07858490 T ES07858490 T ES 07858490T ES 2344870 T3 ES2344870 T3 ES 2344870T3
- Authority
- ES
- Spain
- Prior art keywords
- domain
- sender
- notification
- recipient
- message
- 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.)
- Active
Links
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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0254—Stateful filtering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/212—Monitoring or handling of messages using filtering or selective blocking
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
- Radio Relay Systems (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Procedimiento para controlar un mensaje (MES) a transmitir por un terminal de remitente (TE) conectado a un dominio de emisor (EM) hacia un dominio de destinatario (DES), sin que el remitente esté vinculado a un dominio de remitente (EXP), caracterizado porque incluye las siguientes etapas, después de una autentificación del remitente del mensaje por el dominio de remitente: transmitir (E25, E31) datos de dominio de remitente desde el dominio de remitente al dominio de emisor y una solicitud de notificación (NOT) que contiene dichos datos desde el dominio de emisor al dominio de destinatario, en respuesta a la recepción de la solicitud de notificación, transmitir (E32) una solicitud de confirmación de notificación (REQC_N) que contiene dichos datos, desde el dominio de destinatario al dominio de remitente, si los datos contenidos en la solicitud de confirmación de notificación son idénticos a los datos transmitios por el dominio de remitente después de la autentificación de el remitente, retransmitir (E33) esta solicitud desde el dominio de remitente al dominio de emisor, y en respuesta a la recepción de la solicitud de confirmación de notificación, transmitir (E34) desde el dominio de emisor una respuesta de confirmación de notificación (REPC_N) al dominio de destinatario.
Description
Control de mensaje a transmitir desde un dominio
de emisor hacia un dominio de destinatario.
La presente invención se refiere a un control de
mensaje a transmitir desde un dominio de emisor hacia un dominio de
destinatario mediante una red de telecomunicaciones.
Las redes de telecomunicaciones, como Internet,
transmiten datos por medio de una infraestructura común entre
diferentes entidades de servicio, tales como un servidor web o un
servidor de mensajería electrónica. Estas redes sufren ataques que
tienen como destino objetivos profesionales, administrativos o
individuales. Por ejemplo, un ataque consiste en enviar hacia el
mayor número de destinatarios posibles mensajes no deseados que no
han solicitado, tales como "Spam" para correos electrónicos o
"Split" para llamadas telefónicas en Internet. El calificativo
de "no deseado" se toma en sentido amplio y se aplica a la vez
a la identidad del remitente del mensaje, que puede ser auténtica o
falsificada, y al contenido del mensaje.
Por ejemplo, el desarrollo del Spam se basa en
los siguientes factores:
- -
- la debilidad de los protocolos utilizados en Internet, tales como el protocolo SMTP ("Simple Mail Transfer Protocol" en inglés), el más usado para la transferencia de correo electrónico y que no incorpora funciones de autentificación del emisor de un correo, por ejemplo;
- -
- el aumento de la potencia de los ordenadores, que pueden enviar masivamente mensajes no deseados de manera automática en un periodo muy corto;
- -
- el aumento del número de redes en Internet y de la conectividad entre las redes, lo cual presenta a los atacantes un número muy alto de objetivos que pueden ocultarse detrás de las redes relativamente permisivas o fuera del alcance legal o administrativo de las redes objetivo.
\vskip1.000000\baselineskip
Por otra parte, un dominio de emisor puede
volver a lanzar un mensaje emitido por un remitente que está
conectado al dominio de emisor y que no está vinculado
administrativamente o por contrato al dominio emisor, hacia un
dominio de destinatario. Por ejemplo, un remitente itinerante
conectado a un dominio de emisor "emisor.fr" envía un correo
electrónico cuya dirección de origen es
"usuario@remitente.fr" y cuya dirección de destino es
usuario2@destinatario.fr. Actualmente, el dominio de emisor
no puede determinar si la dirección del remitente es válida, es
decir si la dirección del remitente está efectivamente atribuida en
el dominio de remitente "remitente.fr" y si el remitente
dispone de los derechos para enviar un mensaje desde esa dirección,
ya que el dominio de emisor no controla las identidades, es decir
las direcciones lógicas "remitente.fr". Esta ausencia de
control se utiliza a menudo por parte de atacantes para emitir
mensajes bajo una falsa identidad desde un dominio al cual los
atacantes tienen acceso o bien por medio de una máquina corrompida
en un dominio legítimo.
Una solución a esta ausencia de control consiste
en bloquear en el dominio de emisor el envío de cualquier mensaje
cuya dirección de origen no esté vinculada al dominio de emisor,
pero esta solución es demasiado limitativa, especialmente para la
movilidad de los servicios de "voz en IP" voIP ("voice over
Internet Protocol" en inglés), con los cuales un terminal
itinerante puede utilizar un tercer repetidor, tal como un dominio
de emisor para establecer una llamada telefónica.
Se han desarrollado distintos procedimientos
para combatir el envío de mensajes no deseados.
Unos procedimientos proponen analizar el
contenido de los mensajes en función de algunos criterios, tales
como palabras clave, o firmas de mensaje, y deducir de ello mensajes
potencialmente no deseados.
Otros procedimientos consisten en detectar la
fuente de donde proceden mensajes no deseados en función de
comportamientos de tráfico y eventualmente de análisis de firmas, de
manera a bloquear el tráfico de los mensajes no deseados lo más
cerca posible de la fuente detectada.
Según más procedimientos, las fuentes de tráfico
se clasifican en distintas categorías en función de la reputación
de confianza que presentan, por ejemplo con la ayuda de listas
negras o blancas de direcciones acreditadas como peligrosas o
no.
Según otros procedimientos, se controla la
autenticidad de un usuario de un servicio en Internet con el fin de
responsabilizar a los proveedores de acceso a Internet o dominios de
Internet desde los cuales se envían mensajes, por ejemplo
certificando la identidad proporcionada por el usuario u obligando
al usuario a pasar con éxito un test antes de enviar un
mensaje.
Otros procedimientos se basan en el envío previo
de una notificación por parte del remitente de un mensaje a un
destinatario, debiendo este último aceptar la notificación para
recibir el mensaje.
\newpage
Todos estos procedimientos presentan el
inconveniente de que se controla un mensaje en el dominio de
destinatario que recibe en último lugar los mensajes, sin que este
último interactúe con el dominio de emisor del mensaje, no pudiendo
el dominio de destinatario confiar en los controles realizados
anteriormente. Algunos procedimientos presentan, además, el
inconveniente de la necesidad de desplegar una infraestructura de
clave pública PKI ("Public Key Infrastructure" en inglés).
Por otra parte se conoce mediante el documento
WO 2005/025177 la opción de autentificar al emisor de un mensaje
por interacción entre el emisor y el destinatario.
Para solucionar los inconvenientes anteriormente
expuestos, un procedimiento según la invención para controlar un
mensaje a transmitir por un terminal de remitente conectado a un
dominio de emisor hacia un dominio de destinatario, con el
remitente vinculado a un dominio de remitente, se caracteriza porque
incluye las siguientes etapas, después de una autentificación del
remitente del mensaje por el dominio de remitente:
- transmitir datos de dominio de remitente desde el dominio de remitente al dominio de emisor y una solicitud de notificación que contiene dichos datos desde el dominio de emisor al dominio de destinatario,
- en respuesta a la recepción de la solicitud de notificación, transmitir una solicitud de confirmación de notificación que contiene dichos datos desde el dominio de destinatario al dominio de remitente,
- si los datos contenidos en la solicitud de confirmación de notificación son idénticos a los datos transmitidos por el dominio de remitente después de la autentificación del remitente, retransmitir dicha solicitud desde el dominio de remitente al dominio de emisor, y
- en respuesta a la recepción de la solicitud de confirmación de notificación, transmitir desde el dominio de emisor una respuesta de confirmación de notificación al dominio de destinatario.
\vskip1.000000\baselineskip
A continuación, el mensaje se puede transmitir
desde el dominio emisor hacia, al menos, un terminal de destinatario
que ha proporcionado un consentimiento definitivo al dominio de
destinatario para recibir el mensaje.
La invención controla ventajosamente cualquier
mensaje transmitido por un remitente desde un dominio de emisor
hacia un dominio de destinatario haciendo interactuar el dominio de
remitente al que está vinculado el remitente con los dominios de
emisor y de destinatario. La invención genera de este modo una
responsabilización del dominio de emisor que interviene en el
control de un mensaje emitido desde éste último y una
responsabilización del dominio de remitente que debe autentificar
el remitente del mensaje. Los dominios de emisor y de remitente se
comprometen entonces a que el mensaje no sea del tipo no
deseado.
Por otra parte, el procedimiento según la
invención es independiente de la arquitectura de la red en la que
está implementado. En particular, el procedimiento según la
invención ofrece una implementación compatible con protocolos
existentes de envío de mensajes, tales como el protocolo SMTP para
las aplicaciones de correo electrónico. Por otra parte, la
verificación del origen del mensaje la puede realizar el dominio de
destinatario, cualquiera que sea el número de servidores de enlace
que han transmitido el mensaje hacia el dominio de destinatario.
Según una característica de la invención, la
autentificación del remitente del mensaje incluye, además, una
autentificación de la identidad del remitente y una validación de
derechos necesarios para reivindicar la identidad por parte del
dominio de remitente, después de un intercambio de datos entre el
dominio de remitente y el terminal de remitente.
Ventajosamente, la invención prioriza un control
sobre el origen del mensaje en lugar de sobre el contenido del
mensaje, haciendo intervenir especialmente el dominio de remitente
que autentifica la identidad del remitente y los derechos
necesarios para reivindicar la identidad. En efecto, los controles
basados en algoritmos de filtrado que filtran el contenido de
mensaje pueden ser esquivados por un atacante si éste conoce los
algoritmos de filtrado. Además, la mayoría de los mensajes cuyo
origen está falsificado son generalmente del tipo no deseado
mientras que a la inversa, la mayoría de los mensajes cuyo origen es
auténtico no son del tipo no deseado.
Según otra característica de la invención,
después de la recepción de la respuesta de confirmación de
notificación, el dominio de destinatario puede generar una lista de
rechazo, una lista de consentimiento definitivo y una lista de
consentimientos provisionales que incluye identificadores de los
destinatarios para los cuales, respectivamente, se rechaza la
recepción del mensaje, se concede definitivamente y se concede
provisionalmente, y transmite una respuesta de notificación que
contiene las listas en el dominio de emisor.
Según otra característica de la invención, si la
lista de consentimiento definitivo incluye al menos un identificador
de destinatario, la respuesta de notificación contiene una clave
definitiva y, después de haber recibido la respuesta de
notificación, el dominio de emisor transmite un mensaje
autentificado que contiene el mensaje y la clave definitiva al
dominio de destinatario para que este último transmita el mensaje a
al menos un terminal de un destinatario cuyo identificador está
incluido en la lista de consentimiento definitivo, después de haber
validado la clave definitiva contenida en el mensaje
autentificado.
El control de mensaje según la invención implica
en primer lugar el destinatario de un mensaje en lo que respecta a
recibir dicho mensaje con objeto de obtener previamente a cualquier
transmisión de mensaje al dominio de destinatario, el
consentimiento explícito o implícito del destinatario para recibir,
siempre que la identidad de remitente del mensaje se haya
confirmado previamente. La identidad del remitente corresponde
generalmente a una dirección lógica cuyo formato es propio del
protocolo considerado.
Por otra parte, el control de mensaje según la
invención reduce el volumen de mensajes inútiles o no deseados que
circulan en la red de telecomunicaciones y que llenan los servidores
de enlace de mensaje, así como los buzones de entrada de los
destinatarios cuando los mensajes son correos electrónicos.
La invención se refiere asimismo a un sistema
para controlar un mensaje a transmitir por un terminal de remitente
conectado a un dominio de emisor hacia un dominio de destinatario,
estando el remitente vinculado a un dominio de remitente. El
sistema se caracteriza porque incluye:
- -
- un medio en el dominio de remitente para transmitir datos de dominio de remitente al dominio de emisor, después de una autentificación del remitente del mensaje por parte del dominio de remitente,
- -
- un medio en el dominio de emisor para transmitir una solicitud de notificación que contiene dichos datos al dominio de destinatario,
- -
- un medio en el dominio de destinatario para transmitir, en respuesta a la recepción de la solicitud de notificación, una solicitud de confirmación de notificación que contiene dichos datos al dominio de remitente,
- -
- un medio en el dominio de remitente para retransmitir la solicitud de confirmación de notificación al dominio de emisor, si los datos contenidos en la solicitud de confirmación de notificación son idénticos a los datos transmitidos por el dominio de remitente después de la autentificación del remitente, y
- -
- un medio en el dominio de emisor para transmitir una respuesta de confirmación de notificación al dominio de destinatario, en respuesta a la recepción de la solicitud de confirmación de notificación.
\vskip1.000000\baselineskip
La invención se refiere asimismo a una entidad
en un dominio de emisor para controlar un mensaje a transmitir por
un terminal de remitente conectado al dominio de emisor hacia un
dominio de destinatario, estando el remitente vinculado a un
dominio de remitente, caracterizado porque está adaptada para:
- -
- transmitir una solicitud de notificación que contiene datos de dominio de remitente al dominio de destinatario después de la recepción de dichos datos transmitidos por el dominio de remitente después de una autentificación del remitente del mensaje por parte del dominio de remitente, con el fin de que en respuesta a la recepción de la solicitud de notificación, el dominio de destinatario transmita una solicitud de confirmación de notificación que contiene dichos datos al dominio de remitente y,
- -
- transmitir una respuesta de confirmación de notificación al dominio de destinatario en respuesta a la recepción de la solicitud de confirmación de notificación que se ha transmitido desde el dominio de remitente al dominio de emisor si los datos contenidos en la solicitud de confirmación de notificación son idénticos a los datos transmitidos por el dominio de remitente después de la autentificación del remitente.
\vskip1.000000\baselineskip
La invención se refiere también a una entidad en
un dominio de remitente para controlar un mensaje a transmitir por
un terminal de remitente conectado a un dominio de emisor hacia un
dominio de destinatario, estando el remitente vinculado al dominio
de remitente, caracterizado porque está adaptada para:
- -
- transmitir datos de dominio de remitente al dominio de emisor, después de una autentificación del remitente del mensaje por parte del dominio de remitente, y
- -
- retransmitir una solicitud de confirmación de notificación que contiene dichos datos al dominio de emisor, si los datos contenidos en la solicitud de confirmación de notificación son idénticos a los datos transmitidos por el dominio de remitente después de la autentificación del remitente, habiéndose transmitido la solicitud por parte del dominio de destinatario al dominio de remitente en respuesta a la recepción de una solicitud de notificación que contiene los datos transmitidos por el dominio de emisor al dominio de destinatario después de la autentificación del remitente, para que el dominio de emisor transmita una respuesta de confirmación de notificación al dominio de destinatario.
\vskip1.000000\baselineskip
Finalmente, la invención se refiere a programas
informáticos aptos para ser aplicados en parte en una entidad
incluida en un dominio de emisor y en parte en una entidad incluida
en un dominio de remitente para controlar un mensaje transmitido
por un terminal de remitente vinculado al dominio de emisor hacia un
dominio de destinatario, estando el remitente vinculado al dominio
de remitente. Los programas incluyen instrucciones que, cuando se
ejecutan dichos programas respectivamente en dichas entidades,
realizan las etapas según el procedimiento de la invención.
Otras características y ventajas de la presente
invención aparecerán con mayor claridad en la siguiente descripción
de varios modos de realización de la invención dados a título de
ejemplos no limitativos, en referencia a los dibujos anexos
correspondientes en los cuales:
- la figura 1 es un diagrama de bloques
esquemático de un sistema de control según la invención repartido
entre un dominio de emisor, un dominio de remitente y un dominio de
destinatario vinculados entre sí mediante una red de
telecomunicaciones, y
- la figura 2 es un algoritmo de un
procedimiento según la invención para controlar un mensaje a
transmitir desde el dominio de emisor hacia el dominio de
destinatario.
En referencia a la figura 1, un sistema de
telecomunicaciones incluye un dominio de emisor EM, un dominio de
remitente EXP y un dominio de destinatario DES que se comunican
entre sí a través de una red de telecomunicaciones RT.
Los dominios de emisor EM, remitente EXP y
destinatario DES incluyen respectivamente un controlador de mensaje
de emisor C_EM, un controlador de mensaje de remitente C_EXP y un
controlador de mensaje de destinatario C_DES, que forman un sistema
de control según la invención.
Los dominios de emisor EM y de destinatario DES
incluyen respectivamente uno o más terminales de remitente TE y uno
o más terminales de destinatario TD. Cada dominio EM, EXP, DES
incluye un servidor de borde de recepción SBR_EM, SBR_EXP, SBR_DES
y opcionalmente un servidor de borde de emisión SBE_EM, SBE_EXP,
SBE_DES que se posicionan en el límite entre el dominio y la red de
telecomunicaciones RT. En una variante, se fusionan los servidores
de borde de emisión y de recepción en un dominio. Además, en un
domino, el controlador de mensaje se puede integrar en todo o parte
en uno u otro servidor de borde de emisión y de recepción vinculados
al dominio.
Los controladores C_EM, C_EXP y C_DES están
respectivamente vinculados a bases de datos B_EM, E_EXP y B_DES
para memorizar informaciones relativas a solicitudes y respuestas
intercambiadas entre los controladores.
En cada uno de los dominios de emisor EM, de
remitente EXP y de destinatario DES, los servidores de borde de
emisión SBE_EM, SBE_EXP, SBE_DES y de recepción SBR_EM, SBR_EXP,
SBR_DES implementan funciones de emisión y de recepción de mensajes
y se comunican con los terminales de remitente y los terminales de
destinatario, directamente o mediante al menos un servidor de
enlace.
Un servidor de borde o de enlace es una entidad
capaz de recibir un mensaje y de reenviar este mensaje hacia el
terminal del destinatario del mensaje u otra entidad más cercana de
dicho terminal. Por ejemplo, en aplicaciones de correo electrónico
relativas al dominio de emisor EM o de destinatario DES, un servidor
de enlace es típicamente un agente de transferencia de correo MTA
("Mail Transfer Agent" en inglés) en el seno de una red
vinculada al dominio, y un servidor de borde es típicamente un
agente de distribución de correo MDA ("Mail Delivery Agent" en
inglés) en la periferia de la red. Por ejemplo, en aplicaciones de
"vox en IP", los servidores de borde y de enlace son
"proxy" (de interconexión). En cualquier caso, estos servidores
disponen de tablas de encaminamiento estáticas o dinámicas para
remitir un menaje hacia el destinatario deseado.
Los dominios de emisor EM, remitente EXP y
destinatario DES pueden dividirse en diversos subdominios. En este
caso, cada subdominio incluye al menos un controlador de mensaje y
un servidor de borde de recepción, y los controladores de mensaje
de subdominios se interconectan de manera cooperativa, con el fin de
repartir la carga de procesamiento de los mensajes.
En una variante, el dominio de emisor EM no
incluye servidor de borde de emisión SBE_EM. Por ejemplo, para
algunas aplicaciones de mensajería, unos terminales de remitente TE
se conectan directamente a la red de telecomunicaciones RT, tal
como Internet, y envían correos electrónicos sin recurrir a un
servidor de borde de emisión SBE con la función de un repetidor de
mensajería bajo el control del proveedor de acceso a Internet. En
este caso, el controlador de mensaje de emisor C_EM intercepta los
mensajes generados por los terminales de remitente y él mismo envía
mensajes salientes hacia el dominio de destinatario.
En otra variante, el dominio de emisor EM
presenta una arquitectura muy distribuida y un controlador de
mensaje de emisor C_EM se implementa en cada terminal de
remitente.
En el resto de la descripción, un mensaje de
remitente MES es un conjunto de datos de cualquier naturaleza
transmitido entre los dominios de emisor y de destinatario. Por
ejemplo, un mensaje contiene un correo electrónico, o paquetes de
un diálogo multimedia, tales como los paquetes de inicio de un
diálogo. La transmisión del mensaje puede ser de cualquier tipo,
por ejemplo relativa a un diálogo bidireccional o un envío de
mensaje unitario e independiente de las características de la red
de transporte utilizada, pudiendo este último estar en modo
conectado o en modo no conectado. Un mensaje de remitente MES se
emite desde un terminal de remitente TE del dominio de emisor hacia
uno o más terminales de destinatario TD del dominio de destinatario.
Un terminal de destinatario puede ser por ejemplo un ordenador
personal, un móvil o un servidor de mensajería directamente
accesible mediante terminales.
\newpage
Un mensaje emitido desde el dominio de emisor
hacia el dominio de destinatario puede atravesar uno o más dominios
intermedios, en función de políticas de encaminamiento entre los
operadores relativos a los dominios de emisor y de destinatario.
Cada dominio intermedio incluye uno o más servidores de enlace que
encaminan el mensaje hacia el dominio de destinatario. En general,
para los servicios de mensajería, el servidor de borde de emisión
en el dominio de emisor se comunica directamente con el servidor de
borde de recepción en el dominio de destinatario, sin pasar por
dominios intermedios.
Opcionalmente, la base de datos B_DES vinculada
al controlador de mensaje de destinatario C_DES contiene listas de
direcciones de remitente, tales como una lista negra de direcciones
prohibidas en el seno del dominio de destinatario LNDD, una lista
negra de direcciones prohibidas en el seno de un subdominio del
dominio de destinatario LNSD y una lista negra de direcciones
prohibidas por un usuario LNU, o al menos una de las listas
anteriores. La base de datos puede contener asimismo una lista
blanca de direcciones autorizadas en el seno del dominio de
destinatario LBDD, una lista blanca de direcciones autorizadas en el
seno de un subdominio del dominio de destinatario LBSD y una lista
blanca de direcciones autorizadas por un usuario LBU, o al menos una
de las listas anteriores.
El controlador de mensaje de emisor C_EM y el
controlador de mensaje de remitente C_EXP se comunican entre sí,
especialmente para autentificar de manera remota el remitente de un
mensaje.
En una variante, el remitente se vincula
administrativa o contractualmente al dominio de emisor EM que
administra la dirección del remitente o del terminal de remitente
TE. En este caso, se fusionan los dominios de emisor EM y de
remitente EXP.
Por ejemplo, si el dominio de emisor es
"emisor.fr" y el remitente se identifica con la dirección
lógica usuario@emisor.fr, no se efectúa la autentificación
remota, ya que el dominio de remitente coincide con el dominio de
emisor. Por el contrario, si el remitente se identifica con la
dirección lógica usuario@remitente.fr, la autentificación
remota es necesaria, ya que el dominio de emisor no puede
autentificar la identidad presentada por el remitente y validar los
derechos necesarios para utilizar esta identidad.
El controlador de mensaje de emisor C_EM genera
solicitudes de autentificación AUT y de notificación NOT que
incluyen informaciones de enrutado y de los siguientes elementos de
información reagrupados en un conjunto de datos denominado adjunto
de notificación y anotado como {Notificación}.
<Remitente>: este elemento contiene una
dirección lógica del remitente según un formato que es propio de
una aplicación considerada. Generalmente, la dirección lógica se
compone de un identificador que designa al usuario o al terminal
utilizado y de un nombre de dominio al cual se vincula
administrativa o contractualmente el usuario. Por ejemplo, para una
aplicación de correo electrónico, el formato de este elemento es una
dirección del tipo "identificador@remitente.fr" y, para una
aplicación de telefonía en Internet, el formato de este elemento es
una dirección del tipo "<sip:identificador@dominio.fr>".
Esta dirección puede formar parte del conjunto de direcciones
administradas por el dominio de emisor, o bien estar vinculada al
dominio de remitente. La dirección lógica contenida en el elemento
<Remitente> es distinta de una dirección de transporte que
permite encaminar los paquetes en la red y que es del tipo
"w.x.y.z" para una red IP. Opcionalmente una dirección de
transporte puede completar o sustituir a la dirección lógica
contenida en el elemento <Remitente>.
<Emisor>: este elemento contiene la
dirección de una entidad que genera, en su caso, una solicitud de
notificación o de autenticación y que procesará una respuesta a la
solicitud de notificación o de autentificación. Esta dirección
puede ser la propia dirección del controlador de mensaje de emisor
C_EM o simplemente el nombre del dominio de emisor, o también la
misma dirección que la contenida en el elemento <Remitente> si
el dominio de remitente coincide con el dominio de emisor. De este
modo, el elemento emisor contiene bien una dirección del tipo
lógico, bien una dirección del tipo transporte.
{<Destinatario>}: este elemento, del tipo
lista, contiene el conjunto de direcciones de los destinatarios a
los que se envía el mensaje, que designa generalmente las
direcciones lógicas de los destinatarios o, en su variante, las
direcciones de transporte de los terminales de destinatario. El
formato de cada elemento <Destinatario> es el mismo que el
del elemento <Remitente> y la lista incluye al menos un
elemento. Por otra parte, cada solicitud de notificación contiene
únicamente elementos <Destinatario> pertenecientes a un mismo
dominio de destinatario. Por consiguiente, si un remitente envía un
mensaje hacia destinatarios pertenecientes a diferentes dominios,
el controlador de mensaje de emisor C_EM genera tantas solicitudes
de notificación como distintos dominios de destinatario haya.
<KI>: este elemento contiene una clave
inicial generada por el controlador de mensaje de emisor C_EM para
identificar una solicitud de autenticación o una solicitud de
notificación. Por ejemplo, las claves iniciales generadas para cada
solicitud tienen una misma longitud.
Opcionalmente, una solicitud de notificación
contiene otros elementos útiles para la aplicación considerada como
por ejemplo los siguientes elementos de información.
<Asunto>: este elemento indica el objeto
del mensaje para orientar al destinatario del mensaje, en caso de
que se solicite un consentimiento explícito al destinatario para
aceptar el mensaje.
<Firma> este elemento contiene una firma
del mensaje con objeto de garantizar la integridad del contenido
del mensaje o de su origen. La firma se puede realizar por ejemplo
utilizando una clave secreta o privada generada por el dominio de
emisor. Para ser válida, la firma debe tratar de una parte del
mensaje que no es susceptible de ser modificada por servidores
intermedios.
De manera abreviada, el adjunto de notificación
se escribe:
{Notificación} = <Remitente> +
<Emisor>
{Destinatario} = <KI> + <Asunto> +
(<Firma>),
donde el operador "+" designa la
concatenación de elementos, y los elementos entre paréntesis son
opcionales.
En referencia a la figura 2, el procedimiento de
control de mensaje según la invención incluye desde la etapa E1 a
la etapa E7 ejecutadas en el sistema de telecomunicaciones.
Se supone que no se fusionan los dominios de
emisor EM y de remitente EXP.
En la etapa inicial E1, un remitente desea
enviar un mensaje MES a uno o más destinatarios vía el terminal de
remitente TE. Después de la validación del mensaje por parte del
remitente, el controlador de mensaje de emisor C_EM intercepta el
mensaje a enviar por el terminal de remitente a los destinatarios.
El mensaje MES es por ejemplo un correo electrónico o el
establecimiento de una llamada telefónica en Internet.
El mensaje MES se memoriza temporalmente en el
controlador de mensaje de emisor C_EM antes de ser eventualmente
transmitido a uno o más destinatarios vía el dominio de
destinatario.
Antes de cualquier comunicación entre el dominio
de emisor EM y el dominio de destinatario DES, el controlador de
mensaje de emisor C-EM verifica si el remitente es
legítimo en una fase de autentificación en las etapas E21 a E25 que
componen la etapa E2. En particular, el controlador C_EM verifica si
la entidad del remitente está definida y atribuida en el dominio de
remitente y si el remitente dispone de los derechos necesarios para
reivindicar esta identidad.
En la etapa E21, el controlador de mensaje de
emisor C_EM genera una solicitud de autentificación AUT a transmitir
al controlador de mensaje de remitente C_EXP.
El controlador de mensaje de emisor C_EM extrae
informaciones contenidas en el mensaje MES recibido del terminal de
remitente TE para generar un adjunto de notificación {Notificación}
que contiene en particular los elementos <Remitente>,
<Emisor>, {<Destinatario>} y <KI> y que, a
continuación, se inserta en una solicitud de autentificación AUT.
Por ejemplo, el controlador C_EM informa al remitente de que el
mensaje MES va a experimentar una fase de autentificación remota,
debido a que los dominios de emisor y de remitente son
diferentes.
A continuación, el controlador de mensaje de
emisor C_EM transmite la solicitud de autentificación AUT a la
dirección de transporte de un servidor de borde de recepción SBE_EXP
en el dominio de remitente, o hacia la dirección de transporte del
controlador de mensaje C_EXP si ésta se ha determinado. Por ejemplo,
la dirección de transporte a la que se transmite la solicitud de
autentificación se determina consultando tablas de traducción
preconfiguradas o mediante solicitudes de resolución de nombre de
dominio DNS ("Domain Name Server" en inglés), después de la
extracción del nombre de dominio contenido en el elemento
<Remitente>.
Paralelamente a la transmisión de la solicitud
de autentificación AUT, las informaciones relativas a la
autentificación, especialmente el adjunto de notificación
{Notificación}, se memorizan en la base de datos
B-EM administrada por el controlador de mensaje de
emisor C_EM.
En la etapa E22, el controlador de mensaje de
remitente C_EXP recibe la solicitud de autentificación AUT y extrae
el adjunto de notificación {Notificación}, en particular los
elementos <Remitente>, <Emisor> y la clave inicial
contenida en el elemento <KI>.
Opcionalmente, el controlador de mensaje de
remitente C_EXP verifica si la dirección de transporte fuente de la
solicitud de autentificación AUT forma parte de las direcciones
atribuidas al dominio de emisor.
El controlador de mensaje de remitente C_EXP
ejecuta una de las tres siguientes políticas de autentificación,
cuya elección depende eventualmente del contenido de los elementos
<Emisor> o <Remitente>.
Según una primera política de autentificación
denominada "total", el controlador de mensaje de remitente
C_EXP genera un adjunto de confirmación de autentificación
{Conf_Autentificación] que contiene el adjunto de notificación
{Notificación}, un adjunto de autentificación {Autentificación} y
opcionalmente un elemento <MAC_AUT>. El adjunto
{Notificación} puede reducirse a una forma lo más compacta posible,
conservando únicamente por ejemplo los elementos <Emisor>,
<Remitente> y <KI>. El adjunto {Autentificación}
contiene un adjunto {Desafío} y opcionalmente los elementos
<Hora>, <KE> y <Origen>.
El elemento <Hora> es un marcador temporal
de la autentificación que incluye opcionalmente una hora límite de
validez. El elemento <KE> es un testigo generado
aleatoriamente en cada autentificación para identificar de manera
única el adjunto de confirmación de autentificación. El elemento
<Origen> contiene la dirección de transporte desde donde se
ha recibido la solicitud de autentificación AUT. El adjunto
{Desafío} contiene un conjunto de datos denominado "desafío"
que el dominio de emisor debe intercambiar con el terminal de
remitente con el fin de autentificar la identidad del remitente. Por
ejemplo, el desafío transmitido contiene un elemento aleatorio que
el terminal de remitente TE debe cifrar con una contraseña atribuida
al remitente y retransmitir al controlador C_EXP. El elemento
aleatorio cifrado debe corresponder a un resultado esperado por el
controlador C_EXP para que el desafío sea aceptable. El elemento
<MAC_AUT> es un código de autentificación calculado por el
controlador C_EXP en la conatenación de los adjuntos {Notificación}
y {Autentificación}, utilizando por ejemplo una clave secreta o
privada que se renueva periódicamente.
De forma abreviada, el adjunto de confirmación
de autentificación se escribe:
\vskip1.000000\baselineskip
donde MAC es una función de cálculo
de código de autentificación que utiliza una clave secreta o
privada, el operador "+" designa la concatenación de
elementos, y los elementos entre paréntesis son
opcionales.
A continuación, el controlador de mensaje de
remitente C_EXP genera y transmite una solicitud de confirmación de
autentificación REQC_A que contiene el adjunto de confirmación de
autentificación con destino a la dirección de transporte desde
donde se ha recibido la solicitud AUT.
Según una segunda política de autentificación
denominada "parcial", el controlador de mensaje de remitente
C_EXP transmite una solicitud de confirmación de autentificación
REQC_A idéntica a la generada según la política de autentificación
"total", con la diferencia de que la solicitud no contiene el
adjunto {Desafío}. Ventajosamente, la política de autentificación
"parcial" permite verificar la validez de la dirección de
transporte de donde procede la solicitud de autentificación AUT, a
la vez que consume menos recursos en el dominio de remitente que la
política de autentificación "total".
Según una tercera política de autentificación
denominada "directa", el controlador de mensaje de remitente
C_EXP no genera solicitud de confirmación de autenticación REQC_A y
el procedimiento pasa directamente a la etapa E25 descrita más
adelante, para una validación de la identidad del remitente
contenida en el elemento <Remitente>. Según esta política de
autentificación "directa", el consumo de recursos en el dominio
de remitente es limitado, ya que no requiere memorización alguna ni
cálculo de código MAC por el controlador de mensaje de remitente
C_EXP.
Paralelamente a la generación de la solicitud
REQC_A y en función de los recursos de procesamiento y de memoria
de que dispone el controlador C_EXP, este último adopta una de las
siguientes tres políticas locales de memorización.
Según la primera política de memorización
denominada "mínima", el controlador C_EXP no memoriza elemento
alguno de la solicitud REQC_A en la base de datos B_EXP y calcula
el código de autentificación <MAC_AUT> que garantiza la
integridad de los elementos de información a los que se refiere y
que se inserta en la solicitud REQC_A. Esta política "mínima"
no consume recurso de memoria alguno, pero requiere recursos de
procesamiento adicionales para la transmisión de la solicitud
REQC_A y la verificación de una respuesta a la solicitud REQC_A.
Según la segunda política de memorización
denominada "media", el controlador C_EXP memoriza una
información mínima asociada al contenido de la solicitud REQC_A que
sirve a continuación de clave de búsqueda durante la recepción de
una respuesta a la solicitud REQC_A. Por ejemplo, la clave de
búsqueda para la solicitud REQC_A es el elemento <KE>, o el
elemento <KI> en la ausencia de elemento <KE>. El
controlador de mensaje de remitente C_EXP memoriza la clave de
búsqueda en la base de datos B_EXP, calcula e inserta el código
<MAC_AUT> en la solicitud REQC_A. Esta política consume
recursos de memoria mínimos a la vez que reduce los recursos de
procesamiento de recepción en el caso de un ataque por
inundación.
Según la tercera política de memorización
denominada "máxima", el controlador C_EXP memoriza el adjunto
(Conf-Autentificación) sin calcular ni insertar el
código de autentificación <MAC_AUT> en la solicitud REQC_A.
Esta política requiere pocos recursos de procesamiento, ya que no
realiza cálculo alguno del código <MAC_AUT>, por el
contrario, consume muchos recursos de memoria, lo cual la hace
vulnerable a ataques por inundación.
En la etapa E23, el controlador de mensaje de
emisor C_EM recibe la solicitud de confirmación de autentificación
REQC_A y extrae el adjunto de confirmación de autentificación, en
particular la clave inicial contenida en el elemento <KI>. Si
esta clave inicial corresponde a una clave inicial ya memorizada en
la base de datos B_EM del controlador C_EM, el procesamiento de la
solicitud REQC_A continúa. En caso contrario, la solicitud REQC_A
no se procesa y termina el procedimiento.
Si el adjunto de confirmación de autentificación
no contiene adjunto {Desafío}, en el caso de una política de
autentificación "parcial" adoptada en la etapa E22, el
controlador de mensaje de emisor C_EM ejecuta directamente la etapa
E24.
Si el adjunto de confirmación de autentificación
{Conf_Autentificación} contiene un adjunto {Desafío} transmitido
por el dominio de remitente, el controlador C_EM proporciona el
conjunto de datos contenido en el adjunto {Desafío}, es decir el
desafío, al terminal de remitente TE identificado por el elemento
<Remitente> del adjunto {Notificación} que corresponde al
elemento <KI>. El terminal de remitente TE debe entonces
devolver una respuesta al controlador C_EM. Si no se recibe ninguna
respuesta al desafío por parte del terminal remitente en un plazo
limitado, la etapa E23 se considera fallida y termina el
procedimiento, en caso contrario se ejecuta la etapa E24.
En la etapa E24, el controlador C_EM genera una
respuesta de confirmación de autentificación REPC_A y la transmite
hacia la dirección de transporte desde donde se ha recibido la
solicitud de confirmación de autentificación REQC_A o
alternativamente hacia la dirección de transporte a la que se ha
enviado la solicitud de autentificación AUT.
La respuesta de confirmación de autentificación
REPC_A incluye el adjunto de confirmación de autentificación
{Conf_Autentificación} tal como se extrae de la solicitud de
confirmación de autentificación REPC_A y, en su caso, un elemento
<Respuesta-Desafío> que contiene la respuesta
al desafío devuelta por el terminal de remitente, que es por
ejemplo un dato cifrado.
En la etapa E25, el controlador de mensaje de
remitente C_EXP recibe la respuesta de confirmación de
autentificación REPC_A y extrae el adjunto de confirmación de
autentificación y el elemento
<Respuesta-Desafío> si este último está
presente.
Opcionalmente, el controlador C_EXP verifica la
validez temporal de la respuesta, sobre la base del elemento
<Hora>. El mismo elemento <Hora> se puede utilizar por
parte del controlador C_EXP para encontrar la clave secreta o
privada que había utilizado, en su caso, para el cálculo del código
de autentificación <MAC_AUT> en la solicitud de confirmación
de autentificación REQC_A.
Opcionalmente, el controlador C_EXP verifica que
la dirección de transporte desde donde se ha recibido la respuesta
de confirmación de autentificación REPC_A es idéntica a la contenida
en el elemento <Origen> del adjunto {Autentificación} si este
elemento está presente.
A continuación, el controlador C_EXP verifica la
validez de la respuesta REPC_A según la política de memorización
local adoptada previamente a la etapa E22 para la transmisión de la
solicitud REQC_A. Según la política de memorización "máxima",
el adjunto {Conf_Autentificación} no contiene elemento
<MAC_AUT> y la verificación se refiere a los contenidos de
los adjuntos {Notificación} y {Autentificación}, que deben ser
estrictamente iguales a los de los adjuntos {Notificación} y
{Autentificación} respectivamente, previamente memorizados por el
módulo CMP_EXP en la etapa E22. Si la verificación tiene éxito, la
respuesta REPC_A se considera válida y el procedimiento continúa.
Si fracasa la verificación, se ignora la respuesta REPC_A y termina
el procedimiento.
Según la política de memorización "media",
el controlador C_EXP verifica en premier lugar si la clave de
búsqueda contenida en la respuesta REPC_A, por ejemplo <KI> o
<KE>, corresponde a una clave de búsqueda previamente
memorizada por el controlador C_EXP en la base B_EXP. Si la
verificación tiene éxito, el controlador C_EXP procede a la
verificación del código de autentificación contenido en el elemento
<MAC_AUT>, como se indica más adelante en referencia a la
política de memorización "mínima". Si fracasa la verificación,
se ignora la respuesta REPC_A y termina el procedimiento.
Según la política de memorización "mínima",
la verificación se basa únicamente en un cálculo de código de
autentificación, ya que no se ha memorizado elemento de información
alguno por parte del controlador C_EXP durante la generación de la
solicitud REQC_A en la etapa E22. El controlador C_EXP calcula un
código de verificación de autentificación en los adjuntos
{Notificación} y {Autentificación} contenidos en la respuesta de
confirmación de autentificación REPC_A, utilizando la clave secreta
o privada adecuada. Si el código de verificación de autentificación
es igual al código de autentificación <MAC_AUT> contenido en
la respuesta de confirmación de autentificación REPC_A, esta última
se considera válida. En caso contrario, o en la ausencia de código
de autentificación <MAC_AUT>, la respuesta de confirmación de
autentificación REPC_A es inválida y termina el procesamiento de la
etapa E25.
Si la respuesta de confirmación de
autentificación REPC_A es válida según una de las tres políticas de
memorización anteriores, el controlador C_EXP verifica que la
identidad del remitente contenida en el elemento <Remitente>
del adjunto {Notificación} es auténtica respecto del dominio de
remitente. En referencia a la política de autentificación
previamente ejecutada durante la generación de la solicitud REQC_A,
si la política de autentificación es "parcial" o
"directa", esta verificación es relativa únicamente a la
condición a) expuesta más adelante y, si la política local de
autentificación es "total", la verificación es relativa a las
condiciones a) y b) expuestas más adelante:
a) el elemento <Remitente> contiene una
identidad autorizada, es decir atribuida, en el dominio
remitente;
b) la respuesta contenida en el elemento
<Respuesta-Desafío> certifica que el terminal
de remitente dispone de los derechos necesarios para reivindicar la
identidad autorizada. La ausencia del elemento
<Respuesta-Desafío> en caso de una política
de autentificación "total" se asimila a un elemento
<Respuesta-Desafío> erróneo.
A continuación, una interfaz de comunicación del
controlador C_EXP transmite una respuesta de autentificación R_AUT
que contiene un adjunto de datos {Rep_Autentificación} propio del
dominio de remitente con destino a la dirección de transporte desde
donde se ha recibido la respuesta REPC_A o, alternativamente, con
destino a la dirección de transporte designada por el campo
<Origen> del adjunto {Autentificación} si este último está
presente.
Si se autentifica la identidad del remitente, el
adjunto {Rep_Autentificación} incluye el adjunto {Notificación} tal
como se ha recibido en la respuesta REPC_A, un adjunto
{Consentimiento_Remitente} y opcionalmente un elemento
<MAC_R_AUT>. El adjunto {Consentimiento_Remitente} incluye un
aviso de aceptación y elementos de información <KA>,
<Origen> y opcionalmente <Hora>, que son respectivamente
equivalentes a los elementos <KE>, <Origen> y
<Hora> contenidos en la solicitud REQC_A generada en la etapa
E22. El elemento <MAC_R_AUT> es un código de autentificación
calculado por el controlador C_EXP en la concatenación de los
adjuntos {Notificación} y {Consentimiento_Remitente}, utilizando por
ejemplo una clave secreta o privada que se renueva periódicamente.
La elección de insertar el elemento <MAC_R_AUT> se basa en la
respuesta R_AUT, como para la inserción del código <MAC_AUT>
en la solicitud REQC_A en la etapa E22, sobre la política local de
memorización.
Si la identidad del remitente no se autentifica,
el adjunto {Rep_Autentificación} se compone del adjunto
{Notificación} tal como se ha recibido del mensaje REPC_A y de un
adjunto {Rechazo_Remitente}, que contiene un aviso de rechazo
acompañado opcionalmente de la causa del rechazo.
Durante la fase de autentificación, el dominio
de remitente es alertado por un envío posterior de una solicitud de
notificación desde el dominio de emisor hacia el dominio de
destinatario. En resumen, el dominio de emisor espera del dominio
de remitente que le remita una solicitud de confirmación de
notificación REQC_N recibida en respuesta a la solicitud de
notificación enviada anteriormente al dominio de destinatario.
El dominio de emisor EM transmite de este modo
al dominio de destinatario DES una solicitud de notificación que
describe el mensaje MES que el remitente desea enviar a uno o más
destinatarios con el fin de que cada destinatario acepte o rechace
el mensaje MES, en una fase de notificación en las etapas E31 a E35
que componen la etapa E3.
En la etapa E31, el controlador de mensaje de
emisor C_EM recibe la respuesta de autentificación R_AUT de la que
verifica, gracias a la clave <KI> contenida en el adjunto
{Notificación}, que corresponde a una solicitud anteriormente
emitida por el controlador C_EM.
Si la respuesta de autentificación R_AUT
contiene un aviso de rechazo, la autentificación del terminal de
remitente a fracasado y la fase de notificación no se ha realizado,
poniendo fin al procedimiento.
Si la respuesta de autentificación R_AUT
contiene un aviso de aceptación, la autentificación del remitente
del terminal de remitente ha tenido éxito y se lleva a cabo la fase
de notificación. El controlador de mensaje de emisor C_EM genera
una solicitud de notificación NOT que contiene los adjuntos
{Notificación} y {Rep_Autentificación}. El adjunto {Rep_
Autentificación} se extrae directamente de la respuesta R_AUT,
mientras que el adjunto {Notificación} es similar al enviado por el
controlador C_EM en la solicitud AUT en la etapa E21, e incluye en
particular la clave inicial contenida en el elemento <KI>. El
adjunto {Rep_Autentificación} contiene a su vez un adjunto
{Notificación} que consiste generalmente en una forme reducida del
adjunto {Notificación} generado en la etapa E21. La solicitud de
notificación NOT se transmite mediante una interfaz de comunicación
del controlador de mensaje de emisor C_EM al controlador de mensaje
de destinatario C_DES o al servidor de borde de recepción SBR_DES
del dominio de destinatario DES.
Paralelamente a la transmisión de la solicitud
de notificación, se memorizan informaciones relativas a la
solicitud de notificación en la base de datos B_EM administrada por
el controlador C_EM.
En la etapa E32, el controlador de mensaje de
destinatario C_DES recibe la solicitud de notificación NOT y extrae
los adjuntos {Notificación} y {Rep_Autentificación}.
Opcionalmente, el controlador de mensaje de
destinatario C_DES verifica si la dirección de transporte desde
donde se ha recibido la solicitud de notificación NOT forma parte de
las direcciones atribuidas al dominio de emisor EM en función de la
dirección contenida en el elemento <Emisor>.
El controlador de mensaje de destinatario C_DES
analiza la dirección lógica contenida en el elemento
<Remitente> para determinar la dirección de transporte del
servidor de borde SBR_EXP del dominio de remitente EXP al cual se
acopla el controlador de mensaje de remitente C_EXP. Dicha dirección
de transporte se determina consultando tablas de traducción
preconfiguradas o mediante solicitudes de resolución de nombre de
dominio DNS. Opcionalmente, la dirección de transporte se determina
antes del procesamiento de la solicitud de notificación NOT, con el
fin de ahorrar recursos de procesamiento en caso de que fracasase la
determinación de la dirección.
El controlador de mensaje de destinatario C_DES
genera a continuación un adjunto de confirmación de notificación
{Conf_Notificación} que contiene los adjuntos {Rep_Autentificación},
{Notificación}, un adjunto {Notificación_ACK} y, opcionalmente, un
elemento <MAC_NOT>. Los adjuntos {Rep_Autentificación} y
{Notificación} son idénticos a los extraídos de la solicitud NOT, y
contienen por lo tanto la clave inicial del elemento <KI>. El
adjunto {Notificación_ACK} contiene el elemento <Origen> y un
elemento <KP> y, opcionalmente, el elemento <Hora>. El
elemento <KP> es un testigo generado aleatoriamente en cada
solicitud de confirmación de notificación, para identificar de
manera única el adjunto de confirmación de notificación. El
elemento <Origen> indica la dirección de transporte desde
donde se ha recibido la solicitud de notificación NOT.
El elemento <MAC_NOT> contiene un código
de autentificación que se calcula sobre los adjuntos {Notificación}
y {Notificación_ACK} a partir de una clave secreta o privada propia
del controlador C_DES. El cálculo del código <MAC_NOT> y su
inserción en el adjunto {Conf_Notificación} dependen de la política
local de memorización adoptada y descrita en la etapa E22.
De manera abreviada, el adjunto de confirmación
de notificación se escribe:
donde MAC es una función de cálculo
de código de autentificación que utiliza una clave secreta o
privada, el operador "+" designa la concatenación de
elementos, y los elementos entre paréntesis son
opcionales.
A continuación, el controlador de mensaje de
destinatario C_DES transmite una solicitud de confirmación de
notificación REQC_N que contiene el adjunto de confirmación de
notificación {Conf_Notificación} y, por consiguiente, la clave
inicial del elemento <KI>, con destino a la dirección de
transporte determinada a partir de la dirección lógica contenida en
el elemento <Remitente>, es decir al servidor de borde de
recepción SBR_EXP del dominio de remitente o al controlador de
mensaje de remitente C_EXP.
De este modo, para una política local de
memorización "mínima" o "media", el procesamiento de la
solicitud de notificación no impone memorización alguna, o una
memorización limitada respectivamente, de mensaje de remitente en
el dominio de destinatario que pudiese hacer vulnerable el dominio
de destinatario a ataques del tipo denegación de servicio.
En la etapa E33, el controlador de mensaje de
remitente C_EXP recibe la solicitud de confirmación de notificación
REQC_N y extrae el adjunto de confirmación de notificación
{Conf_Notificación} que contiene el adjunto {Rep_Autentificación}
que se supone ha sido generado por el dominio de remitente y, en
particular, la clave inicial contenida en el elemento
<KI>.
Con el fin de verificar que el adjunto
{Rep_Autentificación} ha sido generado por el dominio de remitente,
el controlador de mensaje de remitente C_EXP verifica la validez de
la solicitud REQC_N de manera similar a la etapa E25 y según la
política de memorización local adoptada previamente en la etapa
E22.
Según la política de memorización "máxima",
el adjunto {Rep_Autentificación} no contiene elemento
<MAC_
R_AUT> y la verificación trata de los contenidos de los adjuntos {Notificación} y {Consentimiento_Remitente} que deben ser estrictamente iguales a los de los adjuntos {Notificación} y {Consentimiento_Remitente} respectivamente, previamente memorizados en la etapa E25 por el módulo CMP_EXP.
R_AUT> y la verificación trata de los contenidos de los adjuntos {Notificación} y {Consentimiento_Remitente} que deben ser estrictamente iguales a los de los adjuntos {Notificación} y {Consentimiento_Remitente} respectivamente, previamente memorizados en la etapa E25 por el módulo CMP_EXP.
Según la política de memorización "media",
el controlador C_EXP verifica en premier lugar si la clave de
búsqueda contenida en la solicitud REQC_N, por ejemplo <KI> o
<KA>, corresponde a una clave de búsqueda previamente
memorizada por el controlador C_EXP en la base B_EXP. Si la
verificación tiene éxito, el controlador C_EXP procede a la
verificación del código de autentificación contenido en el elemento
<MAC_R_AUT>, como se indica más adelante en referencia a la
política de memorización "mínima".
Según la política de memorización "mínima",
la verificación se basa únicamente en el código de autentificación
contenido en el elemento <MAC_R_AUT>, ya que no se ha
memorizado elemento de información alguno por parte del controlador
C_EXP durante la generación de la solicitud R_AUT en la etapa E25.
El elemento <MAC_R_AUT> es un código de autentificación
calculado sobre el contenido del adjunto {Rep_Autentificación}, que
se supone que debe haber sido generado anteriormente por el dominio
de remitente en la etapa E25. Para que la solicitud REQC_N sea
válida, un código de verificación de autentificación sobre el
contenido del adjunto {Rep_Autentificación} calculado por el
controlador C_EXP debe ser igual al código de autentificación
<MAC_R_AUT> contenido en la solicitud REQC_N. En particular,
la igualdad de los códigos <MAC_R_AUT> y de verificación se
comprueba cuando el adjunto {Rep_Autentificación} de la solicitud
REQC_N es idéntico al generado por el controlador C_EXP en la etapa
E25.
Si la verificación tiene éxito, es decir en
todos los casos, si la clave inicial contenida en la solicitud de
confirmación de notificación es idéntica a la clave inicial ya
memorizada en el dominio remitente tras la fase de autentificación,
la solicitud REQC_N se considera válida y el controlador C_EXP
analiza el adjunto {Rep_Autentificación} para extraer el elemento
<Origen> memorizado en la etapa E25. Una interfaz de
comunicación del controlador de mensaje de remitente C_EXP
retransmite entonces la solicitud de confirmación de notificación
REQC_N a la dirección de transporte designada por el elemento
<Origen>, después de haber suprimido opcionalmente el adjunto
{Rep_Autentificación} de la solicitud REQC_N.
Si la verificación falla, el remitente designado
por el adjunto {Notificación} no ha sido autentificado previamente
por el controlador C_EXP y la solicitud REQC_N podría estar
corrompida. En este caso, no se procesa la solicitud REQC_N y
termina el procedimiento.
En cuanto se ha retransmitido la solicitud
REQC_N por parte del controlador C_EXP, éste puede suprimir de la
base de datos B_EXP cualquier posible registro del adjunto de
notificación correspondiente a la solicitud REQC_N, sin que
intervenga el controlador C_EXP en las siguientes etapas del
procedimiento.
Por otra parte, cualquier posible registro
efectuado tras a una fase de autentificación durante las etapas E22
o E25 puede suprimirse después de un plazo predeterminado, con el
fin de no exponer el controlador C_EXP a posibles ataques del tipo
denegación de servicio.
En la etapa E34, el controlador de mensaje de
emisor C_EM recibe la solicitud de confirmación de notificación
REQC_N y extrae el adjunto de confirmación de notificación
{Conf_Notificación}, en particular el adjunto {Notificación} que
contiene. El controlador C_EM verifica que el adjunto {Notificación}
recibido en la solicitud REQC_N corresponde efectivamente a una
solicitud de notificación generada previamente por el dominio de
emisor, por ejemplo comprobando que la clave <KI> extraída
del adjunto {Notificación} corresponde a una clave ya memorizada en
la base de datos B_EM.
Si el adjunto {Notificación} recibido es
idéntico a una notificación ya memorizada en la base de datos B_
EM, una interfaz de comunicación del controlador de mensaje de
emisor C_EM transmite una respuesta de confirmación de notificación
REPC_N que contiene el adjunto de confirmación de notificación
{Conf_Notificación} tal como se ha extraído de la solicitud REQC_N,
después de haber suprimido, en su caso, el adjunto
{Respuesta_Autentificación}, con destino a la dirección de
transporte hacia la que se ha enviado la solicitud de notificación
NOT, es decir con destino al controlador C_DES.
Por el contrario, si el adjunto {Notificación}
recibido no es idéntico a notificación alguna ya memorizada en la
base de datos B_EM del controlador C_EM, no se procesa la solicitud
REQC_N y termina el procedimiento.
Por otra parte, si después de un plazo
predeterminado que sucede a la etapa E31, no se recibe solicitud
alguna de confirmación de notificación REQC_N por parte del
controlador C_EM en respuesta a una solicitud de notificación
previa NOT transmitida por el controlador C_EM, el dominio de emisor
reinicia una fase de notificación, transmitiendo de nuevo una
solicitud de notificación al controlador C_DES, considerando que ha
fallado la fase de notificación anterior.
En la etapa E35, el controlador de mensaje de
destinatario C_DES recibe la respuesta de confirmación de
notificación REPC_N y extrae el adjunto de confirmación de
notificación {Conf_Notificación}.
\newpage
Opcionalmente, el controlador C_DES verifica la
validez temporal de la respuesta, sobre la base del elemento
<Hora>. El mismo elemento <Hora> puede utilizarse por
parte del controlador C_DES para hallar la clave secreta o privada
que había utilizado para el cálculo del código de notificación
<MAC_NOT> en la solicitud de confirmación de notificación
REQC_N. Esta verificación sólo es útil si el controlador C_DES
utiliza claves secretas o privadas renovadas periódicamente.
A continuación, el controlador C_DES verifica la
validez de la respuesta REPC_N de manera similar a la etapa E25 o
E33, y según la política de memorización local adoptada previamente
a la etapa E32 en función de los elementos {Notificación},
{Notificación_ACK} y, en su caso, el elemento <MAC_NOT>.
Si la verificación tiene éxito, la respuesta de
confirmación de notificación REPC_N se considera válida. En caso
contrario, la respuesta de confirmación de notificación REPC_N es
inválida y las siguientes etapas no se ejecutan por parte del
controlador C_DES del dominio de destinatario, poniendo fin al
procedimiento.
Si la respuesta de confirmación de notificación
REPC_N es válida, el controlador C_DES consulta listas de
direcciones de remitente en la base de datos B_DES, especialmente la
lista blanca de direcciones autorizadas en el seno del dominio de
destinatario LBDD, la lista blanca de direcciones autorizadas en el
seno de un subdominio del dominio de destinatario LBSD y la lista
blanca de direcciones autorizadas por un usuario particular LBU. El
controlador C_DES puede consultar asimismo las listas negras de
direcciones prohibidas LNDD, LNSD y LNU. La consulta de las listas
en la base de datos B_DES indica al controlador C_DES si se autoriza
la dirección del remitente, para al menos un destinatario, con el
fin de aceptar la recepción del mensaje MES procedente de esta
dirección.
A partir de la lista de destinatarios
{<Destinatario>} extraída del adjunto {Notificación}, el
controlador C_DES genera entonces una lista de rechazo LR, una
lista de consentimiento definitivo LAD y una lista de consentimiento
provisional LAP en función de las listas consultadas.
La lista de rechazo LR incluye los
identificadores de los destinatarios para los que se ha rechazado la
recepción del mensaje MES, bien porque estos destinatarios no
existen en el dominio de destinatario, bien porque la dirección del
remitente aparece al menos en una de las listas LNDD, LNSD o en una
de las listas LNU relativas a estos destinatarios.
La lista de consentimiento definitivo LAD
incluye los identificadores de los destinatarios para los cuales la
recepción del mensaje MES se concede definitivamente. La condición
para que un destinatario sea añadido a esta lista es que la
dirección del remitente no aparezca en ninguna de las listes LNDD o
LNSD o en la lista LNU relativa a este destinatario, y que a la
inversa, la dirección del remitente aparezca en las listas LBDD o
LBSD o en la lista LBU relativa a este destinatario.
La lista de consentimiento provisional LAP
incluye los identificadores de los destinatarios para los cuales se
ha concedido provisionalmente la recepción del mensaje MES, es decir
ni rechazada, ni aceptada a priori, por oposición a los
destinatarios que son identificados respectivamente en las listas LR
y LAD.
Al final, el número cardinal de la lista
{<Destinatario>} es igual a la suma de los números cardinales
de las listas LR, LAD y LAP de las que al menos una de las tres no
está vacía.
En una variante, el controlador C_DES genera la
lista LR, respectivamente LAD, sin recurrir a las listas LNDD o
LNSD o LNU, respectivamente LBDD o LBSD o LBU, por ejemplo
recogiendo rechazos, respectivamente consentimientos, explícitos de
los destinatarios identificados en la notificación. En cualquier
caso, la lista LAP contiene los identificadores de los
destinatarios que no forman parte ni de la lista LR ni de la lista
LAD.
Si al menos una des listas LAP o LAD no está
vacía, el controlador C_DES memoriza el adjunto de notificación
{Notificación} tal como se ha extraído de la respuesta REPC_N y,
opcionalmente, las listas generadas LR, LAP, LAD asociadas. El
controlador C_DES produce a continuación una respuesta de
notificación R_NOT que contiene el adjunto de notificación
{Notificación} tal como se ha extraído de la respuesta REPC_N y
reducido a su forma más compacta posible, y las listas generadas
LR, LAD y LAP. La respuesta de notificación R_NOT se transmite a la
dirección de transporte desde donde procede la respuesta REPC_N o,
alternativamente, a la dirección de transporte designada por el
elemento <Origen> del adjunto {Notificación ACK}, es decir, la
dirección desde donde se ha recibido la solicitud de notificación
NOT.
Si la lista de consentimiento definitivo LAD no
está vacía e incluye al menos un identificador de destinatario, es
decir, si al menos un destinatario ya ha proporcionado su
consentimiento para recibir el mensaje MES explícita o
implícitamente mediante una lista LBDD, LBSD o LBU, la respuesta de
notificación R_NOT contiene además, una clave definitiva KD.
En la etapa E4, el controlador de mensaje de
emisor C_EM recibe la respuesta de notificación R_NOT y extrae las
listas LR, LAD y LAP. El controlador C_EM presenta las listas LR,
LAD y LAP al remitente del mensaje MES, que queda así informado de
los destinatarios que han rechazado la solicitud de notificación,
los que la han aceptado y aquellos para quienes es necesaria une
solicitud de consentimiento explícita.
\newpage
Si la lista de consentimiento definitivo LAD no
está vacía, el controlador C_EM extrae de la respuesta de
notificación R_NOT la clave definitiva KD correspondiente y produce
un mensaje autentificado MA que contiene el mensaje inicial MES
recibido en la etapa E1 y la clave definitiva KD. El mensaje
autentificado MA se transmite hacia la misma dirección de
transporte que aquella desde donde se ha recibido la respuesta R_NOT
o, alternativamente, hacia la dirección a la que se ha transmitido
la solicitud de notificación NOT o la respuesta de confirmación de
notificación REPC_N.
En la etapa E5, el controlador de mensaje de
destinatario C_DES recibe el mensaje autentificado MA que contiene
el mensaje MES y la clave definitiva KD, y verifica la validez de
esta última respecto de una notificación previamente registrada en
la etapa E35. Si la clave definitiva KD es válida, el controlador de
mensaje de destinatario C_DES recupera el adjunto de notificación
{Notificación} correspondiente, tal como lo ha memorizado el
controlador C_DES en la etapa E35. Por otra parte, el controlador
C_DES puede controlar asimismo la integridad del mensaje MES
recibido con la ayuda de la firma del mensaje proporcionada por el
elemento <Firma>, si este último está presente en el mismo
adjunto de notificación.
A continuación, el controlador C_DES transmite
el mensaje MES a los destinatarios cuyos identificadores se
incluyen en la lista de consentimiento definitivo LAD, tal como lo
ha memorizado el controlador C_DES en la etapa E35 antes de la
transmisión de la respuesta de notificación R_NOT, con el fin de
evitar que un emisor malintencionado modifique la lista de
destinatarios entre la transmisión de la solicitud de notificación
NOT y la transmisión del mensaje autentificado MA. El controlador
C_DES transmite el mensaje MES a los terminales de los
destinatarios TD o a las direcciones de los destinatarios.
Si la clave definitiva KD no es válida, el
mensaje MES no se transmite a los destinatarios, ya que el mensaje
ha podido ser alterado por una tercera persona malintencionada, y
termina el procedimiento.
Volviendo a la etapa E35, si la lista de
consentimiento provisional LAP incluye al menos el identificador de
un destinatario, el destinatario debe dar su consentimiento o su
rechazo explícito para recibir el mensaje MES descrito en la
solicitud de notificación NOT.
Con este fin, el controlador de mensaje de
destinatario C_DES presenta al terminal del destinatario
informaciones procedentes del adjunto {Notificación} relativas al
remitente del mensaje MES, tales como la dirección o el
identificador del remitente, en la etapa E6. A continuación, previa
solicitud del controlador de mensaje de destinatario C_DES, el
destinatario proporciona explícitamente al controlador C_DES su
consentimiento o su rechazo para recibir el mensaje MES. El
controlador C_ DES actualiza entonces el contenido de la lista LAD
o LR en función del consentimiento o del rechazo explícito
proporcionado por el destinatario.
Por otra parte, el controlador C_DES también
puede actualizar la lista negra LNU y la lista blanca LBU relativas
al destinatario. Ventajosamente, el controlador C_DES puede recorrer
regularmente las listas negra y blanca de cada destinatario para
actualizar las listas blancas LBDD y LBSD y negras LNDD y LNSD
relativas al dominio de destinatario.
Cuando se han recogido todos los consentimientos
y/o rechazos por parte del controlador C_DES para el conjunto de
los destinatarios contenidos en la lista LAP, ese último genera una
segunda respuesta de notificación R_NOT2 que contiene las listas
actualizadas LR y LAD y las transmite al controlador C_EM con el fin
que este último indique al remitente los destinatarios
complementarios que han aceptado y/o rechazado el mensaje MES.
A continuación, en a la etapa E7, el controlador
de mensaje de destinatario C_DES transmite el mensaje MES a los
terminales de destinatarios TD o a las direcciones de los
destinatarios que han dado explícitamente su consentimiento.
Si la lista de consentimiento provisional LAP
generada por el controlador C_DES en la etapa E35 está vacía, no se
ejecutan las etapas E6 y E7.
En una variante, ya que se puede retrasar el
consentimiento o el rechazo para recibir el mensaje MES por cada
destinatario de la lista LAP, por ejemplo mediante la ausencia de al
menos un destinatario, se puede ejecutar la etapa E6 en varias
veces, según el número de destinatarios vinculados a la lista LAP.
En este caso, se repite la etapa E7 varias veces con el fin de que
el controlador C_DES transmita el mensaje MES sólo a los terminales
de destinatarios TE que han dado explícitamente su consentimiento,
incluso si otros destinatarios no han dado todavía su
consentimiento.
En una variante, el controlador C_DES transmite
la segunda respuesta de notificación R_NOT2 que contiene las listas
actualizadas LR y LAD al controlador C_EM después haber transmitido
el mensaje MES a los terminales de destinatarios TD que han dado
explícitamente su consentimiento.
En otra variante, si la lista de consentimiento
provisional LAP generada en la etapa E35 incluye al menos un
identificador de un destinatario y si la lista de consentimiento
definitivo LAD está vacía, la respuesta de notificación R_NOT
transmitida en la etapa E35 no contiene clave definitiva KD. En este
caso, las etapas E4 y E5, durante las cuales el mensaje
autentificado MA que contiene el mensaje MES y la clave definitiva
KD se transmite desde el controlador de mensaje de emisor C_EM
sucesivamente al controlador de mensaje de destinatario C_DES, y a
continuación a los destinatarios, se ejecutan después de la etapa
E6. A lo largo de la etapa E6, el controlador C_DES transmite la
segunda respuesta de notificación R_NOT2 que contiene las listas
actualizadas LR y LAD y una clave definitiva KD al controlador C_EM,
es decir, después de que al menos un destinatario haya
proporcionado su consentimiento explícito para recibir el mensaje
MES. Por consiguiente, el dominio de emisor transmite el mensaje
autentificado MA al dominio de destinatario después de haber
recibido la segunda respuesta de notificación R_NOT2 que contiene
la lista de consentimiento definitivo actualizada que incluye al
menos un identificador de un destinatario.
En otra variante, se administra la identidad del
remitente mediante el dominio de emisor EM, y se fusionan los
dominios de remitente EXP y de emisor EM. En este caso, la etapa E2
relativa a la fase de autentificación incluye únicamente la etapa
E23, durante la cual el terminal de remitente TE responde al desafío
transmitido opcionalmente por el controlador de mensaje de emisor
C_EM con el fin de que este último autentifique el remitente del
mensaje MES. Por otra parte, las etapas E32 y E33 ya sólo forman una
etapa durante la cual el controlador de mensaje de destinatario
C_DES transmite la solicitud de confirmación de notificación REQC_N
directamente hacia el controlador de mensaje de emisor C_EM, no
hacia el dominio de remitente.
En otra variante, el controlador de mensaje de
emisor C_EM queda incluido en el terminal de remitente y no ejecuta
de manera automática ninguna de las etapas del procedimiento según
la invención. En cada etapa en la que interviene el controlador
C_EM, este último indica al remitente mediante el terminal de
remitente TE las instrucciones a seguir para la ejecución de la
etapa. Por ejemplo, las instrucciones se visualizan en una pantalla
del terminal de remitente y el remitente participa manualmente en la
creación de las solicitudes y respuestas relativas a las fases de
autentificación y de notificación.
La invención descrita en la presente memoria se
refiere a un procedimiento y a dos entidades incluidas
respectivamente en un dominio de emisor y en un dominio de
remitente para controlar un mensaje a transmitir mediante un
terminal de remitente conectado al dominio de emisor hacia un
dominio de destinatario vía una red de telecomunicaciones, con el
remitente vinculado administrativa o contractualmente al dominio de
remitente. Según una implementación, las etapas del procedimiento
de la invención se determinan mediante las instrucciones de
programas informáticos incorporados respectivamente a dichas
entidades según la invención. Los programas incluyen instrucciones
de programa que, cuando se ejecutan dichos programas
respectivamente en dichas entidades, cuyo funcionamiento se rige
entonces por la ejecución de los programas, realizan las etapas del
procedimiento según la invención.
En consecuencia, la invención se aplica asimismo
a un programa informático, especialmente un programa informático
grabado en un soporte de información legible por un ordenador y
cualquier dispositivo de procesamiento de datos, adaptado para
aplicar la invención. Este programa puede utilizar cualquier
lenguaje de programación, y tener forma de código fuente, código
objeto o código intermedio entre código fuente y código objeto,
como una forma parcialmente compilada, o cualquier otra forma
deseable para implementar el procedimiento según la invención.
El soporte de información puede ser cualquier
entidad o dispositivo capaz de almacenar el programa. Por ejemplo,
el soporte puede incluir un medio de almacenamiento o soporte de
grabación en el cual se graba el programa informático según la
invención, tal como una ROM, por ejemplo un CD ROM o una ROM de
circuito microelectrónico, así como una clave USB, o un medio de
grabación magnética, por ejemplo un disquete (floppy disc) o un
disco duro.
Por otra parte, el soporte de información puede
ser un soporte transmisible, como una señal eléctrica u óptica, que
se puede encaminar por un cable eléctrico u óptico, por radio o por
otros medios. El programa según la invención se puede descargar
especialmente de una red del tipo Internet.
Alternativamente, el soporte de información
puede ser un circuito integrado en el cual se incorpora el programa,
con el circuito adaptado para ejecutar o para ser utilizado en la
ejecución del procedimiento según la invención.
Claims (13)
1. Procedimiento para controlar un mensaje (MES)
a transmitir por un terminal de remitente (TE) conectado a un
dominio de emisor (EM) hacia un dominio de destinatario (DES), sin
que el remitente esté vinculado a un dominio de remitente (EXP),
caracterizado porque incluye las siguientes etapas, después
de una autentificación del remitente del mensaje por el dominio de
remitente:
- transmitir (E25, E31) datos de dominio de remitente desde el dominio de remitente al dominio de emisor y una solicitud de notificación (NOT) que contiene dichos datos desde el dominio de emisor al dominio de destinatario,
- en respuesta a la recepción de la solicitud de notificación, transmitir (E32) una solicitud de confirmación de notificación (REQC_N) que contiene dichos datos, desde el dominio de destinatario al dominio de remitente,
- si los datos contenidos en la solicitud de confirmación de notificación son idénticos a los datos transmitios por el dominio de remitente después de la autentificación de el remitente, retransmitir (E33) esta solicitud desde el dominio de remitente al dominio de emisor, y
- en respuesta a la recepción de la solicitud de confirmación de notificación, transmitir (E34) desde el dominio de emisor una respuesta de confirmación de notificación (REPC_N) al dominio de destinatario.
\vskip1.000000\baselineskip
2. Procedimiento conforme a la reivindicación 1,
según el cual después de la recepción de la respuesta de
confirmación de notificación (REPC_N), el dominio de destinatario
genera (E35) una lista de rechazo (LR), una lista de consentimiento
definitivo (LAD) y una lista de consentimiento provisional (LAP),
que incluyen identificadores de los destinatarios para los cuales
la recepción del mensaje queda respectivamente rechazada, concedida
definitivamente y concedida provisionalmente, y transmite (E35) una
respuesta de notificación (R_NOT) que contiene las listas al
dominio de emisor.
3. Procedimiento conforme a la reivindicación 2,
según el cual si la lista de consentimiento definitivo (LAD)
incluye al menos un identificador de destinatario, la respuesta de
notificación (R_NOT) contiene una clave definitiva (KD) y, después
de haber recibido la respuesta de notificación, el dominio de emisor
transmite (E4) al dominio de destinatario un mensaje autentificado
(MA) que contiene el mensaje (MES) y la clave definitiva (KD), con
el fin de que este último transmita (E5) el mensaje a al menos un
terminal de un destinatario cuyo identificador queda incluido en la
lista de consentimiento definitivo, después de haber validado la
clave definitiva contenida en el mensaje autentificado.
4. Procedimiento conforme a la reivindicación 2
o 3, según el cual si la lista de consentimiento provisional (LAP)
incluye al menos un identificador de un destinatario, previa
solicitud del dominio de destinatario, el destinatario proporciona
un consentimiento o un rechazo para recibir el mensaje (MES) al
dominio de destinatario con el fin de que este último transmita el
mensaje hacia el terminal del destinatario.
5. Procedimiento conforme a la reivindicación 4,
según el cual el dominio de destinatario actualiza la lista de
rechazo y la lista de consentimiento definitivo en función del
consentimiento o del rechazo proporcionado por el destinatario y
transmite una segunda respuesta de notificación (R_NOT2) que
contiene las listas actualizadas al dominio de emisor.
6. Procedimiento conforme a la reivindicación 5,
según el cual si en la respuesta de notificación (R_NOT) la lista
de consentimiento provisional (LAP) incluye al menos un
identificador de un destinatario y la lista de consentimiento
definitivo (LAD) está vacía, el dominio de emisor transmite el
mensaje al dominio de destinatario después de haber recibido la
segunda respuesta de notificación (R_NOT2) que contiene la lista de
consentimiento definitivo actualizada que incluye al menos un
identificador de un destinatario.
7. Procedimiento conforme a una cualquiera de
las reivindicaciones 1 a 6, según el cual la autentificación (E2)
del remitente del mensaje incluye, además, una autentificación de la
identidad del remitente y una validación de derechos necesarios
para reivindicar la identidad por el dominio de remitente, después
de un intercambio de datos entre el dominio de remitente y el
terminal de remitente.
8. Sistema para controlar un mensaje (MES) a
transmitir por un terminal de remitente (TE) conectado a un dominio
de emisor (EM) hacia un dominio de destinatario (DES), con el
remitente vinculado a un dominio de remitente (EXP),
caracterizado porque incluye:
- -
- un medio (C_EXP) en el dominio de remitente para transmitir datos de dominio de remitente al dominio de emisor, después de una autentificación del remitente del mensaje por el dominio de remitente,
- -
- un medio (C_EM) en el dominio de emisor para transmitir una solicitud de notificación (NOT) que contiene dichos datos al dominio de destinatario,
- -
- un medio (C_DES) en el dominio de destinatario para transmitir, en respuesta a la recepción de la solicitud de notificación, una solicitud de confirmación de notificación (REQC_N) que contiene dichos datos al dominio de remitente,
- -
- un medio (C_EXP) en el dominio de remitente para retransmitir la solicitud de confirmación de notificación al dominio de emisor, si los datos contenidos en la solicitud de confirmación de notificación son idénticos a los datos transmitidos por el dominio de remitente después de la autentificación del remitente, y
- -
- un medio (C_EM) en el dominio de emisor para transmitir una respuesta de confirmación de notificación (REPC_N) al dominio de destinatario, en respuesta a la recepción de la solicitud de confirmación de notificación.
\vskip1.000000\baselineskip
9. Sistema conforme a la reivindicación 8, en el
que se fusionan los dominios de emisor (EM) y de remitente
(EXP).
10. Entidad (C_EM) en un dominio de emisor (EM)
para controlar un mensaje (MES) a transmitir por un terminal de
remitente (TE) conectado al dominio de emisor hacia un dominio de
destinatario (DES), con el remitente vinculado a un dominio de
remitente (EXP), caracterizado porque está adaptada para:
transmitir (E31) una solicitud de notificación
(NOT) que contiene los datos de dominio de remitente al dominio de
destinatario, después de la recepción des dichos datos transmitidos
por el dominio de remitente tras una autentificación del remitente
del mensaje por el dominio de remitente, con el fin de que en
respuesta a la recepción de la solicitud de notificación, el
dominio de destinatario transmita una solicitud de confirmación de
notificación (REQC_N) que contiene dichos datos al dominio de
remitente, y
transmitir (E34) una respuesta de confirmación
de notificación (REPC_N) al dominio de destinatario en respuesta a
la recepción de la solicitud de confirmación de notificación que se
ha retransmitido desde el dominio de remitente al dominio de emisor
si los datos contenidos en la solicitud de confirmación de
notificación son idénticos a los datos transmitidos por el dominio
de remitente después de la autentificación del remitente.
11. Entidad (C_EXP) en un dominio de remitente
(EXP) para controlar un mensaje (MES) a transmitir por un terminal
de remitente (TE) conectado a un dominio de emisor (EM) hacia un
dominio de destinatario (DES), con el remitente vinculado al
dominio de remitente, caracterizado porque está adaptada
para:
transmitir (E25) datos de dominio de remitente
al dominio de emisor, después de una autentificación del remitente
del mensaje por el dominio de remitente, y
retransmitir (E33) una solicitud de confirmación
de notificación (REQC_N) que contiene dichos datos al dominio de
emisor, si los datos contenidos en la solicitud de confirmación de
notificación son idénticos a los datos transmitidos por el dominio
de remitente después de la autentificación del remitente, habiéndose
transmitido dicha solicitud mediante el dominio de destinatario al
dominio de remitente en respuesta a la recepción de una solicitud
de notificación (NOT) que contiene los datos transmitidos por el
dominio de emisor al dominio de destinatario, después de la
autentificación del remitente, con el fin de que el dominio de
emisor transmita una respuesta de confirmación de notificación
(REPC_N) al dominio de destinatario.
12. Programa informático apto para ser aplicado
en una entidad (C_EM) en un dominio de emisor (EM) para controlar
un mensaje (MES) a transmitir por un terminal de remitente (TE)
conectado a un dominio de emisor hacia un dominio de destinatario
(DES), con el remitente vinculado a un dominio de remitente (EXP),
caracterizado porque incluye instrucciones que, cuando se
ejecuta el programa en dicha entidad, realizan las etapas de:
transmitir (E31) una solicitud de notificación
(NOT) que contiene datos de dominio de remitente al dominio de
destinatario, después de la recepción de dichos datos transmitidos
por el dominio de remitente después de una autentificación del
remitente del mensaje por el dominio de remitente, con el fin de
que, en respuesta a la recepción de la solicitud de notificación,
el dominio de destinatario transmita una solicitud de confirmación
de notificación (REQC_N) que contiene dichos datos al dominio de
remitente, y
transmitir (E34) una respuesta de confirmación
de notificación (REPC_N) al dominio de destinatario en respuesta a
la recepción de la solicitud de confirmación de notificación que se
ha retransmitido desde el dominio de remitente al dominio de emisor
si los datos contenidos en la solicitud de confirmación de
notificación son idénticos a los datos transmitidos por el dominio
de remitente después de la autentificación del remitente.
13. Programa informático apto para ser aplicado
en una entidad (C_EXP) en un dominio de remitente (EXP) para
controlar un mensaje (MES) a transmitir por un terminal de remitente
(TE) conectado a un dominio de emisor hacia un dominio de
destinatario (DES), con el remitente vinculado a un dominio de
remitente, caracterizado porque incluye instrucciones que,
cuando el programa se ejecuta en dicha entidad, realizan las etapas
de:
\newpage
transmitir datos de dominio de remitente al
dominio de emisor, después de una autentificación del remitente del
mensaje por el dominio de remitente, y
retransmitir (E33) una solicitud de confirmación
de notificación (REQC_N) que contiene dichos datos al dominio de
emisor, si los datos contenidos en la solicitud de confirmación de
notificación son idénticos a los datos transmitidos por el dominio
de remitente después de la autentificación del remitente, siendo
dicha solicitud transmitida por el dominio de destinatario al
dominio de remitente en respuesta a la recepción de una solicitud
de notificación (NOT) que contiene los datos transmitidos por el
dominio de emisor al dominio de destinatario después de la
autentificación del remitente, con el fin de que el dominio de
emisor transmita una respuesta de confirmación de notificación
(REPC_N) al dominio de destinatario.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0654294A FR2907292A1 (fr) | 2006-10-16 | 2006-10-16 | Controle de message a transmettre depuis un domaine d'emetteur vers un domaine de destinataire |
| FR0654294 | 2006-10-16 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2344870T3 true ES2344870T3 (es) | 2010-09-08 |
Family
ID=38069097
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07858490T Active ES2344870T3 (es) | 2006-10-16 | 2007-10-02 | Control de mensaje a transmitir desde un dominio de emisor hacia un dominio de destinatario. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US20100306820A1 (es) |
| EP (1) | EP2092703B1 (es) |
| AT (1) | ATE467966T1 (es) |
| DE (1) | DE602007006544D1 (es) |
| ES (1) | ES2344870T3 (es) |
| FR (1) | FR2907292A1 (es) |
| WO (1) | WO2008047024A1 (es) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9100417B2 (en) * | 2007-09-12 | 2015-08-04 | Avaya Inc. | Multi-node and multi-call state machine profiling for detecting SPIT |
| US9438641B2 (en) * | 2007-09-12 | 2016-09-06 | Avaya Inc. | State machine profiling for voice over IP calls |
| US9736172B2 (en) | 2007-09-12 | 2017-08-15 | Avaya Inc. | Signature-free intrusion detection |
| US8141152B1 (en) * | 2007-12-18 | 2012-03-20 | Avaya Inc. | Method to detect spam over internet telephony (SPIT) |
| WO2009131437A1 (en) * | 2008-04-25 | 2009-10-29 | It Unlimited Holding B.V. | Verifying authorized transmission of electronic messages over a network |
| WO2010133783A1 (fr) * | 2009-05-20 | 2010-11-25 | France Telecom | Procédé de protection contre les messages indésirables dans un réseau de télécommunications |
| EP2543013A4 (en) * | 2010-03-01 | 2014-12-24 | Opera Solutions Llc | COMPUTER IMPLEMENTED METHOD FOR REINFORCING TARGETED PRODUCT SALES |
| EP2735977A1 (en) * | 2012-11-21 | 2014-05-28 | Alcatel-Lucent | Media cloud copyless message passing |
| US9443107B2 (en) | 2013-02-19 | 2016-09-13 | Qualcomm Incorporated | Method for protecting the integrity of a group of memory elements using an aggregate authentication code |
| US10205598B2 (en) * | 2015-05-03 | 2019-02-12 | Ronald Francis Sulpizio, JR. | Temporal key generation and PKI gateway |
| US11552923B2 (en) * | 2015-12-30 | 2023-01-10 | Donuts, Inc. | Whitelist domain name registry |
| US20240007295A1 (en) * | 2021-02-09 | 2024-01-04 | Sony Semiconductor Solutions Corporation | Information processor, mobile body apparatus, and communication system |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6266703B1 (en) * | 1992-12-29 | 2001-07-24 | International Business Machines Corporation | Method and apparatus for providing confirmation notification for isochronous data |
| US6986049B2 (en) * | 2003-08-26 | 2006-01-10 | Yahoo! Inc. | Method and system for authenticating a message sender using domain keys |
| AU2003269292A1 (en) * | 2003-09-09 | 2005-03-29 | Ghazal Abadi Naeini | Global village communication protocol (gvcp) |
| US20050216587A1 (en) * | 2004-03-25 | 2005-09-29 | International Business Machines Corporation | Establishing trust in an email client |
| US7721093B2 (en) * | 2004-04-02 | 2010-05-18 | Microsoft Corporation | Authenticated exchange of public information using electronic mail |
| FR2877114B1 (fr) * | 2004-10-22 | 2007-02-02 | Bruno Decarpigny | Systeme et procede de gestion de messages dans un reseau de communication par messagerie electronique |
| US7519818B2 (en) * | 2004-12-09 | 2009-04-14 | Microsoft Corporation | Method and system for processing a communication based on trust that the communication is not unwanted as assigned by a sending domain |
-
2006
- 2006-10-16 FR FR0654294A patent/FR2907292A1/fr not_active Withdrawn
-
2007
- 2007-10-02 WO PCT/FR2007/052057 patent/WO2008047024A1/fr not_active Ceased
- 2007-10-02 DE DE602007006544T patent/DE602007006544D1/de active Active
- 2007-10-02 US US12/445,584 patent/US20100306820A1/en not_active Abandoned
- 2007-10-02 ES ES07858490T patent/ES2344870T3/es active Active
- 2007-10-02 AT AT07858490T patent/ATE467966T1/de not_active IP Right Cessation
- 2007-10-02 EP EP07858490A patent/EP2092703B1/fr not_active Not-in-force
Also Published As
| Publication number | Publication date |
|---|---|
| US20100306820A1 (en) | 2010-12-02 |
| FR2907292A1 (fr) | 2008-04-18 |
| ATE467966T1 (de) | 2010-05-15 |
| EP2092703B1 (fr) | 2010-05-12 |
| DE602007006544D1 (de) | 2010-06-24 |
| WO2008047024A1 (fr) | 2008-04-24 |
| EP2092703A1 (fr) | 2009-08-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2344870T3 (es) | Control de mensaje a transmitir desde un dominio de emisor hacia un dominio de destinatario. | |
| US7917757B2 (en) | Method and system for authentication of electronic communications | |
| US7437558B2 (en) | Method and system for verifying identification of an electronic mail message | |
| US7376835B2 (en) | Implementing nonrepudiation and audit using authentication assertions and key servers | |
| US20090138711A1 (en) | Sender Email Address Verification Using Reachback | |
| US20060212520A1 (en) | Electronic message system with federation of trusted senders | |
| US20090210708A1 (en) | Systems and Methods for Authenticating and Authorizing a Message Receiver | |
| US9906501B2 (en) | Publicly available protected electronic mail system | |
| Leiba et al. | DomainKeys Identified Mail (DKIM): Using Digital Signatures for Domain Verification. | |
| US20060143136A1 (en) | Trusted electronic messaging system | |
| US7971061B2 (en) | E-mail system and method having certified opt-in capabilities | |
| US8090940B1 (en) | Method and system for verifying identification of an electronic message | |
| KR101219862B1 (ko) | 서버와 대응 도메인이 호환성 안전 이메일을 갖도록 하기위한 시스템 및 방법 | |
| KR101109817B1 (ko) | 이메일 메시지 인증 방법 및 장치 | |
| US9560029B2 (en) | Publicly available protected electronic mail system | |
| CN101273345B (zh) | 通过密钥产生和比较来防止未请求及不需要的电子消息传送的系统和方法 | |
| Allman et al. | RFC 4871: Domainkeys identified mail (DKIM) signatures | |
| EP4675974A1 (en) | Method for establishing a secure e-mail communication channel, data processing system, computer program, and computer-readable medium | |
| Breuch | Web Key Directory and other key exchange methods for OpenPGP | |
| Allman et al. | Domainkeys identified mail (dkim) signatures draft-ietf-dkim-base-10 | |
| JP2024024650A (ja) | サーバ | |
| Hansen et al. | DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations | |
| Hansen et al. | RFC 5863: DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations | |
| Delany et al. | DomainKeys Identified Mail (DKIM) Signatures | |
| Delany et al. | DKIM E. Allman Internet-Draft Sendmail, Inc. Intended status: Standards Track J. Callas Expires: August 15, 2007 PGP Corporation |