EVOLUCIÓN DEL STANAG 4406 HACIA TECNOLOGÍAS DE SERVICIOS WEB PARA SISTEMAS DE MENSAJERÍA MILITAR (MMHS)

EVOLUCIÓN DEL STANAG 4406 HACIA TECNOLOGÍAS DE
SERVICIOS WEB PARA SISTEMAS DE MENSAJERÍA MILITAR
(MMHS)
AUTOR: Miguel Ángel Pérez García
PROGRAMA DE DOCTORADO
Ingeniería de Sistemas Telemáticos
Departamento de Ingeniería de Sistemas Telemáticos
ETS de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Email: maperez@isdefe.es,
Resumen.
La mensajería electrónica proporciona un servicio de plataforma esencial para las
operaciones militares y así seguirá siendo. Dentro de las FAS se diferencian dos tipos de
servicios de mensajería electrónica: el de propósito general (PG) y el de mando y control
(C2). En ambos se especifican, a su vez, dos tipos de sistemas de mensajería: uno de
carácter interpersonal (con orígenes y destinatarios como personas) y otro de carácter
organizacional (con orígenes y destinatarios como identidades). El sistema de mensajería
militar (MMHS) se encuadra dentro del servicio de mensajería de C2 organizacional.
El STANAG 4406 constituye el estándar actual para los MMHS y garantiza la
interoperabilidad entre los distintos sistemas existentes en cada país. Los protocolos en los
que se basa se han quedado obsoletos y no han sido suficientemente soportados por la
industria. Es por ello que dentro de OTAN se han iniciado los primeros pasos hacia una
evolución de su estándar. El resultado de los primeros estudios dio lugar a una primera línea
de investigación, en la que se establecieron las tecnologías SMTP y S/MIME como base
para dicha evolución. En la presente memoria se expone la investigación realizada sobre la
forma en que se propone la utilización de dichas tecnologías.
Por otro lado, y como propuesta de tesis, se propone una solución alternativa bien distinta:
el estudio de las arquitecturas de sistemas distribuidos basados en servicios web (Web
Services) y sus protocolos para ser empleados en la evolución del estándar. En este terreno
se disponen de protocolos de sobra estudiados y extendidos como son RMI, CORBA,
DCOM o SOAP (en especial este último). En la presente memoria se adelantan los
protocolos que se analizarían (HTTP y XML principalmente) y los requisitos básicos de
partida a tener en cuenta.
Palabras clave.
STANAG 4406, mensajería militar, MMHS, servicios web, X.400, SOAP, XML, SMTP,
S/MIME.
1 Introducción
Dentro de los sistemas de Mando y Control (C2) que se pueden encontrar en
cualquier organización militar, el Sistema de Mensajería Militar (MMHS)
constituye sin duda uno de los más importantes y con mayor nivel de despliegue.

Dichos sistemas ofrecen, además de la funcionalidad típica de cualquier sistema de
mensajería civil con altos requisitos de seguridad (integridad, no repudio, sellado de
tiempo, etc.), servicios adicionales que son específicos del entorno militar: flujo de
validación, control de precedencias, nivel de clasificación, tipos de operación, etc.
Para cubrir dichas necesidades, el organismo militar de mayor entidad a escala
mundial y en el cual nuestro país se halla integrado (es decir, la OTAN), creó el
estándar STANAG 4406 [19], mediante el cual se establecen los requisitos técnicos
y funcionales mínimos que todo sistema de mensajería militar debe cumplir. Dichos
requisitos abarcan fundamentalmente:
· Protocolo de envío/recepción de mensajes: X.400
· Formato de mensajes: P772 (adaptación del P22, que es el equivalente civil)
· Protocolo de seguridad: PCT (subconjunto del estándar del IETF S/MIME)
· Extensiones militares especificas implementadas mediante X.400
· Interoperabilidad con sistemas legados basados en procedimientos de cinta
perforada (ACP127)
Una de las principales recomendaciones a la hora de implementar un sistema de
mensajería militar, es que esté basado en productos comerciales (COTS) en la
mayor medida posible, huyendo de desarrollos ad-hoc que normalmente complican
y retardan la obtención del producto final. Dado que los productos militares
específicos son escasos (sobretodo por el reducido mercado en el que se enmarcan)
y que los requisitos técnicos que se establecen en el STANAG 4406 (X.400, PCT,
etc.) no son precisamente los más extendidos entre los productos comerciales
existentes en el mercado civil, se ha planteado dentro de los foros internacionales en
los que se tratan estos temas la necesidad de evolucionar los requisitos técnicos del
estándar hacia protocolos más extendidos entre los productos civiles.
La principal vía de investigación que se está desarrollando en dichos foros, aboga
por la evolución hacia tecnologías con sobrada solvencia (principalmente SMTP y
S/MIME). Sin embargo, en el trabajo que aquí se describe se ha preferido abrir una
línea de investigación algo distinta. Se trata de explorar los nuevos protocolos
basados en tecnologías distribuidas e intentar aprovechar las ventajas que ofrecen
dichos protocolos (SOAP, DCOM o CORBA) con el objetivo de replantear los
servicios de mensajería militar e intentar plasmarlos como si se trataran de
“servicios WEB” (WebServices).
El objetivo de esta investigación ha tenido una doble finalidad: analizar por un lado
las propuestas existentes actualmente para que el STANAG4406 pueda evolucionar
hacia tecnologías modernas y bien asentadas, y proponer por otro una alternativa a
estas propuestas orientada a otros protocolos que, a priori, se presentan como más
prometedores en cuanto a funcionalidad y flexibilidad.
Dentro de estos objetivos, se ha tenido muy en cuenta el requisito de que dicha
evolución no suponga, en principio, una perdida de funcionalidad en los sistemas.
No obstante, los posteriores estudios de viabilidad (fuera del alcance de la tesis

propuesta) podrían recomendar la posibilidad de desencadenar de forma paralela
una adaptación de los requisitos funcionales, de forma que se “suavizara” en cierta
medida esta evolución.
2 Desarrollo
2.1 Utilidad y relevancia
El sistema de mensajería militar (MMHS) constituye sin duda uno de los más
importantes y con mayor nivel de despliegue. Así pues, el proceso de obtención de
dicho sistema y el estado de mantenimiento del mismo una vez que se implanta,
constituye un punto crítico dentro de la División de Sistemas de Información del
Estado Mayor Conjunto de cualquier nación.
Ambas fases del ciclo de vida de un sistema de mensajería militar (proceso de
diseño/obtención y mantenimiento) estarán muy condicionadas y directamente
relacionadas con la “buena salud” del estándar en el que se basan. Tal y como se ha
mencionado anteriormente, una de las principales recomendaciones a la hora de
implementar un sistema de mensajería militar, es que esté basado en productos
comerciales (COTS) en la mayor medida posible, huyendo de desarrollos ad-hoc
que normalmente complican y retardan la obtención del producto final1
. Esto no se
ha estado produciendo debido a que los requisitos técnicos que se establecen en el
STANAG 4406 (X.400, PCT, etc.) no son precisamente los más extendidos entre
los productos comerciales existentes en el mercado civil. Además, las
especificaciones técnicas del estándar conllevan implementaciones pesadas, dando
lugar a productos caros que deben funcionar sobre grandes máquinas, con el
consiguiente coste elevado de la implantación. Así pues, el problema es obvio, ya
que por un lado nos encontramos con un estándar de obligado cumplimiento por
parte de las naciones pertenecientes a la OTAN, y por otro lado no se encuentran
productos COTS que permitan afrontar los proyectos con el mínimo coste y número
de adaptaciones y por tanto mayores garantías.
Teniendo en cuenta todas estas consideraciones, la utilidad de las líneas de
investigación que aquí se describen es obvia: España, como integrante de la OTAN
que ha adoptado el STANAG 4406 como estándar para implementar su sistema de
mensajería militar, se encuentra directamente interesada en la evolución de dicho
estándar. Actualmente nuestras FAS disponen, de forma plenamente extendida y
operativa, de un sistema de mensajería militar conjunto basado en la versión
anterior de dicho estándar2
. No obstante, dentro de los planes de evolución del
1
Este ha sido el caso de España, donde el proyecto orientado a la obtención del Sistema Conjunto de
Mensajería de Defensa (SICOMEDE) ha sufrido numerosos problemas y retrasos precisamente por
estar basado en desarrollos ad-hoc.
2
En dicha versión, el protocolo de mensajería ya era el X.400, pero el de seguridad estaba basado en
el X.411 (perfiles de seguridad S1C), lo cual quiere decir que ni siquiera se implementa el PCT. De
ahí que desde hace ya algún tiempo exista la necesidad de realizar la evolución del sistema a la
última versión del STANAG.

sistema, ya se han iniciado los pasos necesarios para realizar los primeros estudios
orientados al análisis de las implicaciones que dicha evolución supone. Dado que en
este momento, tal y como se ha señalado anteriormente, se está estudiando dentro
de los foros correspondientes la evolución del estándar, el interés nacional por
conocer los caminos y resultado final de dicha evolución es obvio.
Pero no existe únicamente un interés nacional: muchos de los demás países también
integrantes de la OTAN se encuentran en situación de evolución similar a la de
España, por lo que la relevancia y utilidad de estas investigaciones adquieren
trascendencia internacional.
2.2 Ámbito de trabajo
El STANAG 4406 constituye, tal y como se ha mencionado anteriormente, el
estándar actual para los MMHS y garantiza la interoperabilidad entre los distintos
sistemas existentes en cada país. El concepto de Sistema de Tratamiento de
Mensajes Militares (MMHS) que se especifica en este STANAG se basa en las
recomendaciones de la ITU reflejadas en su estándar X.400 [10], y se complementa
con una serie de extensiones que se añaden al X.400 para crear un tipo de formato
(P772) y un sistema de transporte de mensajes especifico para propósitos militares.
Desgraciadamente, y tal y como se ha comentado anteriormente, la tecnología
X.400 no ha tenido todo el apoyo por parte de la industria que hubiera se hubiera
deseado desde OTAN. Es por ello que dentro de su seno se han iniciado los
primeros pasos hacia una evolución de su estándar. Con este objetivo, desde 2002 y
dentro del foro “Tecnologías Futuras para el MMHS” (el cual se halla enmarcado
en los grupos técnicos de trabajo de OTAN) se ha comenzado ha estudiar esta
problemática [22]. El resultado de los primeros estudios ha dado lugar a una primera
línea de investigación, en la que se establece que las tecnologías SMTP y MIME
son las que deben marcar la transición de la especificación del STANAG [21]. Dicha
elección se ha basado fundamentalmente en una de las premisas básicas con las que
se iniciaron estos trabajos: emplearse tecnologías y protocolos no solo respaldadas
con estándares suficientemente consolidados, sino también soportadas por el
mercado en cuanto a conocimiento de dichas tecnologías y disponibilidad de
numerosos productos que las implementen.
2.3 Líneas de investigación iniciadas
Tal y como se ha mencionado antes, en el foro “Tecnologías Futuras para el
MMHS” se está trabajando sobre la sustitución de los principales protocolos del
estándar por otros más extendidos entre la industria civil. Aunque ya se han
realizado avances importantes, los trabajos realizados se han centrado
fundamentalmente en determinar los protocolos sobre los que se trabajará y todos
los posibles escenarios u opciones que se presentan a la hora de implementar tanto

el formato de los mensajes como su transporte a lo largo del sistema. Dado que el
STANAG 4406 se basa fundamentalmente en su protocolo de transporte de
mensajes y en su protocolo de seguridad, esta línea de investigación se ha dividido
en dos partes [21]:
Una parte del estudio trata de analizar como se pueden implementar,
mediante SMTP, todos los servicios que actualmente se proporcionan
mediante X.400 (sobretodo los particulares de la mensajería militar),
tratando de dar alternativas en aquellos casos donde de forma directa no se
pueda resolver mediante el propio protocolo. En este sentido se ha planteado
la necesidad de desarrollar una estructura de mensaje que proporcione tanto
los servicios no soportados por SMTP, así como facilidades para
implementar la transición de X.400 a SMTP y del formato P772 al RFC
822/MIME. Para ello, esta línea de investigación aboga por tres alternativas,
cada una de las cuales a su vez permiten varias posibilidades. En esta
propuesta que nos ocupa no se entrará en el detalle de cada uno de los
escenarios, siendo en el posterior trabajo de investigación donde se
analizarán con detenimiento.
A. P772 transportado sobre SMTP: En este escenario, un mensaje se
compondría usando la estructura del formato P772, tal y como se
hace actualmente. Con esta opción se posibilita la continuación del
uso del formato P7723
y por tanto se facilita el mantener los
requisitos operativos del STANAG 4406. La diferencia estaría en
que, en lugar de utilizar el protocolo P7 del X.400 para transferir los
mensajes entre el agente de usuario (UA) y el Agente de
Transferencia de Mensajes (MTA), se usaría SMTP para enviar el
mensaje a un servidor, el cual lo reenviaría a un MTA. Al incluir
servidores SMTP se reduciría el número de MTA necesarios, con el
consiguiente ahorro en costes. Sobre esta alternativa se abren tres
posibles escenarios:
A.1) P772 transportado sobre SMTP tal cual
3
Este formato es el equivalente al P22 del X.400 pero con extensiones militares, las cuales se
transportan en la cabecera del mensaje P772

ASN.1/BER P 772
SMTP
ORIGIN ATOR RECIPIENT
BODY
Subject:
P rimary-recipients:
Originator:
P rimary-precedence:
Copy-precedence:
Distribution-codes:
Body P art n
Body P art 1
Body P art 2
HEADER
ASN.1/BER P772
BODY
Subject:
P rimary-recipients:
Originator:
P rimary-precedence:
Copy-precedence:
Distribution-codes:
Body P art n
Body P art 1
Body P art 2
HEADER
Figura 1.: P772 transportado sobre SMTP
En este escenario, el contenido del P772 se transporta sobre SMTP
tal cual. Así pues se tienen las ventajas propias de SMTP, como son
su amplio soporte en cuanto a productos, su robustez como protocolo
y su no-dependencia de los subsistemas de transmisión. El único
problema es que el contenido del P772 está en ASN.1 (8 bits), lo
cual supondría usar la extensión “8BITMIME” del SMTP extendido.
A.2) P772 encapsulado y transportado sobre SMTP

SMTP
ORIGINATOR RECIPIENT
ASN.1/BER P772
Body
Subject:
Primary-recipients:
Originator:
Primary-precedence:
Copy-precedence:
Distribution-codes:
Body Part n
Body Part 1
Body Part 2
Headers
Content-Type: message/p772
Content-Transfer-Encoding: base64
ASN.1/BER P772
Body
Subject:
Primary-recipients:
Originator:
Primary-precedence:
Copy-precedence:
Distribution-codes:
Body Part n
Body Part 1
Body Part 2
Headers
Content-Type: message/p772
Content-Transfer-Encoding: base64
Figura 2.: P772 encapsulado y transportado sobre SMTP
La diferencia en este escenario es que el contenido P772 se
encapsula en un sobre MIME “mínimo” y se transporta sobre SMTP.
Para ello sería necesario desarrollar un pseudo-estándar para soportar
P772 encapsulado sobre SMTP. Igualmente, se debería crear un
nuevo subtipo MIME para los mensajes P772 y que éste fuera
aprobado por IANA.
Otro inconveniente de este escenario es que la codificación BASE64
conlleva un aumento considerable del tamaño de los mensajes, lo
cual puede ser un inconveniente en ciertos entornos con ancho de
banda reducido (entornos tácticos, zonas de operaciones o de
maniobras, entornos marítimos, etc.).
A.3) Mensaje MIME que contiene un P772 codificado en ASN.1 y
transportado sobre SMTP

RFC 822/MIME
From:
Date:
Subject:
To:
MIME -Version: 1.0
Content -Type:
SMTP
P772 ASN.1 Encoded
Content
RFC 822/MIME
From:
Date:
Subject:
To:
MIME -Version: 1.0
Content -Type:
P772 ASN.1 Encoded
Content
Figura 3.: Mensaje MIME que contiene un P772 y transportado sobre SMTP
En este escenario, el UA originador es un cliente P772, mientras que
el receptor obtiene el mensaje en formato MIME. Esto implicaría
que los clientes deberían soportar tanto P772 como MIME.
Igualmente, sigue existiendo el mismo problema que en el escenario
anterior en cuanto al aumento de tamaño de los mensajes con la
codificación BASE64.
A continuación se presenta un esquema resumen de los tres
escenarios posibles para esta alternativa en la que se pretende
mantener el formato P772 con todas sus extensiones militares:

SMTP
MTA
P772
UA
SMTP
MTA
P772
UA
SMTP
UA
RFC 822/
MIME
UA
P772
UA
Scenario A.2
Scenario A.3
Scenario A.1
B. RFC 822/MIME transportado sobre SMTP: Este escenario se
caracteriza porque el mensaje se crea según el formato RFC
822/MIME. Las extensiones militares (códigos de precedencia,
códigos de distribución, etc.) pueden incluirse bien en la cabecera
(escenario B.1) o bien en el cuerpo del mensaje (escenario B.2).
Dichas extensiones irían en texto plano codificado, y al igual que en
el escenario A.2 deberían ser registradas y autorizadas por IANA
(aunque solo para el escenario B.2). Los mensajes serían
transportados sobre SMTP al igual que en el caso anterior.
B.1) Extensiones militares situadas en la cabecera del mensaje en
formato RFC 822/MIME

822/MIME
--boundary_ABCxyz
Content-Type: audio/basic
SMTP
--boundary_ABCxyz
Content-Type: text/plain
BODY
822/MIME
--boundary_ABCxyz--
--boundary_ABCxyz
--boundary_ABCxyz
BODY
--boundary_ABCxyz--
P772 Requirements
HEADERS
From:
Date:
Subject:
To:
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=boundary_ABCxyz
P772 Requirements
HEADERS
From:
Date:
Subject:
To:
MIME-Version: 1.0
Figura 4.: Extensiones militares situadas en la cabecera del mensaje en formato RFC 822/MIME
En este escenario la solución se alcanzaría simplemente extendiendo
las funcionalidades ya incluidas en los productos COTS para hacer
visibles las nuevas extensiones a los usuarios. No obstante, dichos
COTS debería sufrir modificaciones para ser capaces de manejar las
nuevas cabeceras militares.
B.2) Extensiones militares situadas en el cuerpo del mensaje en
formato RFC 822/MIME.

822/MIME
From:
Date:
Subject:
To:
MIME-Version: 1.0
--boundary_ABCxyz
SMTP
--boundary_ABCxyz
P772 Requirements
BODY
822/MIME
From:
Date:
Subject:
To:
MIME-Version: 1.0
--boundary_ABCxyz--
--boundary_ABCxyz
--boundary_ABCxyz
P772 Requirements
BODY
--boundary_ABCxyz--
Figura 5.: Extensiones militares situadas en el cuerpo del mensaje en formato RFC 822/MIME
A diferencia del escenario anterior, no se necesitaría registrar nuevos
valores de cabecera en IANA. Además, las extensiones al estar en
texto en el cuerpo del mensaje, su tratamiento y manejo se puede
realizar mediante procedimientos manuales de usuario en lugar de
implementarlo de forma automática. Como inconveniente, puede ser
necesario alguna comprobación adicional por parte del UA, antes de
que el mensaje sea definitivamente enviado al MTA, para asegurarse
de que el usuario ha incluido todos las extensiones militares
obligatorias.
C. RFC 822/MIME transportado sobre X.400: En este caso lo que se
propone es transportar los mensajes en formato RFC 822/MIME
sobre X.400. Así pues, es un caso similar al B), salvo que se usaría
X.400 en lugar de SMTP. Por tanto, los razonamientos expuestos
anteriormente son válidos para los escenarios de este caso (los cuales
son los mismos que para el caso B)):
C.1) Extensiones militares situadas en la cabecera del mensaje en

822/MIME
--boundary_ ABCxyz
Content -Type: audio/basic
X.400
--boundary_ ABCxyz
Content -Type: text/plain
BODY
822/MIME
--boundary_ ABCxyz --
--boundary_ ABCxyz
--boundary_ ABCxyz
BODY
P772 Requirements
HEADERS
From:
Date:
Subject:
To:
MIME-Version: 1.0
boundary=boundary_ ABCxyz
P772 Requirements
HEADERS
From:
Date:
Subject:
To:
MIME-Version: 1.0
Figura 6.: Extensiones militares situadas en la cabecera del mensaje en formato RFC 822/MIME
C.2) Extensiones militares situadas en el cuerpo del mensaje en
822/MIME
From:
Date:
Subject:
To:
MIME -Version: 1.0
Content -Type: multipart/mixed;
--boundary_ ABCxyz
X.400
--boundary_ ABCxyz
P772 Requirements
BODY
822/MIME
From:
Date:
Subject:
To:
MIME -Version: 1.0
Content -Type: multipart/mixed;
--boundary_ ABCxyz
--boundary_ ABCxyz
P772 Requirements
BODY
Figura 7.: Extensiones militares situadas en el cuerpo del mensaje en formato RFC 822/MIME

Las ventajas e inconvenientes son las mismas que en el caso anterior,
añadiendo la problemática que para los productos COTS supone el
tener que soportar X.400.
La otra parte del estudio analiza cómo se puede realizar la evolución del
protocolo de seguridad actual (PCT) hacia S/MIME, teniendo en cuenta lo
mismo que se ha expuesto anteriormente sobre la continuidad de los
servicios y mecanismos prestados, y amén de la interoperabilidad con las
versiones actuales (ver nota al pie nº 2). Sobre este tema los trabajos de
investigación que se están realizando están más definidos, ya que se ha
concluido que lo único que hay que hacer es añadir el triple “wrapping” del
S/MIME sobre el PCT (el cual de por si ya constituye el primer paso o
“wrapping” del S/MIME) [23]. Por otra parte la compatibilidad tanto con
PCT como con las antiguas versiones basadas en X.411 estaría garantizada y
de fácil resolución mediante pasarelas bastante sencillas de implementar, las
cuales adaptarían los formatos sin llegar a romperse la seguridad extremo-a-
extremo:
Figura 8.:Esquema de mapeado entre el formato X.411 (azul), PCT (rojo) y S/MIME (verde)
2.4 Alternativa propuesta: tecnologías “webservices”
Visto lo anterior, parece que la evolución del STANAG 4406 está bastante
encaminada. No obstante, y manteniendo las mismas premisas de partida (emplear

tecnologías y protocolos respaldados con estándares suficientemente consolidados y
soportadas por el mercado en cuanto a conocimiento de dichas tecnologías y
disponibilidad de productos que las implementen), el punto de vista que se propone
en la investigación aquí descrita es otro bien distinto. Se trata de ir un paso más en
cuanto a las tecnologías a tener en cuenta, para lo cual se propone usar como
referencia lo que actualmente se está considerando para sistemas de mensajería
civiles similares a los de mensajería militar. En este aspecto, principalmente nos
referiremos a las arquitecturas de sistemas distribuidos basados en servicios
Web (Web Services)4
. En este terreno se disponen de protocolos de sobra
estudiados y extendidos como son RMI, CORBA, SOAP o DCOM. A lo largo de la
investigación llevada a cabo [8] se han contemplando todas estas tecnologías, y de
los resultados obtenidos se ha deducido que el protocolo SOAP parece ser el más
completo, ya que goza de una serie de ventajas sobre las restantes:
Es sencillo de implementar, probar y usar.
Es un estándar de la industria adoptado por el W3C y por varias otras
empresas.
Utiliza los mismos estándares de Internet para casi todo: la comunicación se
hace mediante HTTP con paquetes virtualmente idénticos; los protocolos de
autenticación y encriptación son los mismos; el mantenimiento de estado se
hace de la misma forma; se implementa normalmente por el propio servidor
Web.
Atraviesa dispositivos de defensa perimetral como firewalls y los propios
routers, que "piensan" que es una comunicación HTTP. No obstante este
dato se deberá tener especialmente en cuenta, ya que puede constituir a la
vez un inconveniente en cuanto a las posibles vulnerabilidades de seguridad
que puede conllevar.
Tanto los datos como las funciones se describen en XML, lo que permite
que el protocolo no sólo sea más fácil de utilizar sino que también sea muy
sólido.
Es independiente del sistema operativo y procesador. Esto le libra de
problemas de incompatibilidad entre distintas implementaciones de
fabricantes (estos problemas están presentes, por ejemplo, en CORBA).
Se puede utilizar tanto de forma anónima como con autenticación
(nombre/clave).
Se puede afirmar que conceptualmente equivale a las tecnologías:
o Remote Procedure Call (RPC) en la terminología cliente-servidor;
o Remote Operations Service Element (ROSE) en OSI.
En la siguiente tabla se pueden ver de forma resumida las principales diferencias
entre ellos:
4
Los web services son componentes software que permiten a los usuarios usar aplicaciones de
negocio que comparten datos con otros programas modulares, vía Internet. Son aplicaciones
independientes de la plataforma que pueden ser fácilmente publicadas, localizadas e invocadas
mediante protocolos web estándar, como XML, SOAP, UDDI o WSDL. El objetivo final es la
creación de un directorio online de web services, que pueda ser localizado de un modo sencillo y que
tenga una alta fiabilidad

DCOM CORBA/IIOP EJB/RMI/IIOP SOAP
Formato Binario Binario Binario XML
Plataforma
Principalmente
Windows
Principalmente
Unix
Independiente Independiente
Lenguaje de
Programación
Independiente Independiente Java
Puede
acceder a
través de
dominios de
confianza
No No No Si
A continuación se representa el formato básico de un mensaje SOAP y el modelo de
servicios web mediante SOAP. En este último se puede apreciar como, tanto el
productor como el consumidor de servicios, publican y acceden a estos de una
forma sencilla:
Figura 9.: Estructura básica del formato de un mensaje SOAP

Figura 10.: Modelo básico de servicios web en SOAP
Obviamente, un aspecto crítico muy a tener en cuenta serán los mecanismos de
seguridad que por la propia condición de los sistemas de mensajería militar deben
estar presentes en los propios protocolos en sí. Precisamente, y como una de las
conclusiones obtenidas en la investigación realizada, el aspecto de la seguridad era
en el que más lagunas presentaban estos protocolos. Será, por tanto, un objetivo
“paralelo” de esta investigación el analizar cómo estos protocolos pueden mejorar
en este aspecto, contribuyendo de esa forma al enriquecimiento de los mismos. En
cuanto a SOAP, se han definido algunos estándares y mecanismos que tratan de
dotar de seguridad a las transacciones de datos XML:
ESTÁNDARES
• Web Service Security (WSS). WS-Security trata de definir una
aproximación general para asegurar las transacciones de datos XML.
• Security Assertions Markup Language (SAML) define una serie de
operaciones de seguridad estándar que pueden ser embebidas en las
transacciones XML, haciendo posible que los web services intercambien
información de autenticación y autorización entre ellos, de modo que un
web service confié en un usuario autentificado por web service.
• ANSI X9.96 (XCMS). Estándar basado en el Cryptographic Message
Syntax (CMS) que especifica como proteger mediante CMS una
transacción XML para que el texto no pueda ser ni accedido ni
modificado.
MECANISMOS
• XML_ENC. Encriptación XML. Permite realizar una encriptación XML
y así evitar que los datos se vean expuestos a lo largo de su recorrido.
DISCOVER
REQUEST
1. Provider develops
service parameters and
server software
3. Consum
er sends
UDDI
request for list of
available
services
4. Registry
sends
UDDI
response
with
W
SDL
descriptions, including
(2)
5. Service consumer
develops suitable client
software
6. Client and server
applications communicate
XML data via SOAP and
either HTTP or SMTP
Service Registry
Service
Consumer
Service
Provider
RESPONSE
2. Provider publishes
W
SDL
service
description
PUBLISH DISCOVER
REQUEST
server software
3. Consum
er sends
UDDI
request for list of
available
services
4. Registry
sends
UDDI
response
with
W
SDL
(2)
5. Service consumer
software
either HTTP or SMTP
Service Registry
Service
Consumer
Service
Provider
RESPONSE
W
SDL
service
description
PUBLISH
REQUEST
server software
3. Consum
er sends
UDDI
request for list of
available
services
4. Registry
sends
UDDI
response
with
W
SDL
(2)
5. Service consumer
software
either HTTP or SMTP
Service Registry
Service
Consumer
Service
Provider
RESPONSE
W
SDL
service
description
PUBLISH

• XML_DSIG. Firma digital XML. Asocia los datos del mensaje al usuario
que emite la firma, de modo que este usuario es el único que puede
modificar dichos datos.
También es probable que sea necesario algún tipo de Infraestructura de Clave
Pública (PKI):
• XML Key Management Specification (XKMS). Define web services que
se pueden usar para chequear la confianza de un certificado de usuario.
Además, también hay técnicas que permiten mantener la seguridad a otros niveles.
La seguridad en UDDI5
permite autentificar todas las entidades que toman parte en
la publicación de un web service: proveedor, agente y consumidor del servicio. De
este modo, nadie podrá registrar servicios en el papel de un proveedor o hacer uso
de ellos sin contar con los permisos adecuados.
Figura 11.: Modelo avanzado de servicios web en SOAP (con seguridad mediante túneles TLS)
Tal y como se ha mencionado anteriormente, e independientemente de cómo se
aborde, esta transición conllevará el replanteamiento de ciertas cuestiones, dado que
5
Este protocolo permite la publicación y localización de los servicios. Los directorios UDDI actúan
como una guía telefónica de web services.
PUBLISH
REQUEST
server software
W
SDL
service
description
3. Consum
er sends
UDDI
request for list of
available
services
4. Registry
sends
UDDI
response
with
W
SDL
(2)
5. Service consumer
software
either HTTP or SMTP
DISCOVER
RESPONSE
TLS Tunnel
TLS
TLS
Service
Provider
Service Registry
Service
Consumer
Tunneling provides several
useful security properties:
• Message Integrity
• Message Confidentiality
• Protection Against Replay Attacks
Tunneling fails to provide:
• End-to-end Security
• Mutual Authentication
• Non-repudiation
• Authorization
PUBLISH
REQUEST
server software
W
SDL
service
description
3. Consum
er sends
UDDI
request for list of
available
services
4. Registry
sends
UDDI
response
with
W
SDL
(2)
5. Service consumer
software
either HTTP or SMTP
DISCOVER
RESPONSE
TLS Tunnel
TLS
TLS
TLS TunnelTLS Tunnel
TLS
TLS
TLS
TLS
Service
Provider
Service Registry
Service
Consumer
Tunneling provides several
useful security properties:
• Message Integrity
• Message Confidentiality
• Protection Against Replay Attacks
Tunneling fails to provide:
• End-to-end Security
• Mutual Authentication
• Non-repudiation
• Authorization

ninguna de las tecnologías y protocolos antes mencionados soportan todos los
requisitos originales operativos y funcionales plasmados en el STANAG 4406.
•
•
•
•
!
"
• # $
$ %&#
'( "
•
• ) $ *+
%&#
• ,
'(
•
"
• - . /
0
! 1
Figura 12.: Análisis sintetizado de SOAP
3 Conclusiones: objetivos y expectativas
Una vez identificada la problemática asociada al motivo del estudio en torno al
STANAG 4406, el objetivo principal de éste se enfocará en analizar cómo se puede
realizar la evolución de dicho estándar, abordando el problema desde la visión que
las nuevas tecnologías y protocolos orientados a entornos distribuidos pueden
aportar. Como objetivo colateral, se pretenderá que los estudios aquí desarrollados
puedan servir de acicate y como aportación a los foros de investigación
relacionados con estos temas, para lo cual se intentará asistir a dichos foros y
exponer en ellos los progresos de esta investigación.
Dados la relevancia (en el ámbito antes mencionado) del asunto en cuestión y el
enfoque eminentemente práctico desde el punto de vista de aplicación que tendrán
las conclusiones finales, como expectativa a largo plazo, el objetivo final de estas
investigaciones es facilitar a los distintos países la implementación de sus sistemas
de mensajería, tanto desde el punto de vista de sencillez de los sistemas a la hora de
implantarlos, así como desde el punto de vista de costes a la hora de utilizar
productos COTS basados en protocolos muy extendidos en el mercado civil que
permitan diseñar sistemas escalables. Para ello, se buscará que las tecnologías y
protocolos seleccionados presenten al menos las siguientes características:

Simplicidad – Deben posibilitar la definición de un formato de mensajes
mediante una semántica básica, apoyándose en protocolos de aplicación
robustos y de sobra probados.
Portabilidad – Este es un aspecto importante, ya que dada la variedad de
preferencias sobre lenguajes y plataformas existente en los distintos países,
las implementaciones deben ser factibles sobre cualquiera de ellos.
Flexibilidad – Posibilidad de que los contenidos (“content type”) se puedan
definir según sean necesarios (de cara a la inclusión de los servicios que el
STANAG 4406 implementa basándose en estos contenidos adicionales)..
Interoperabilidad – No debe suponer un problema la existencia de ciertos
elementos separadores como firewalls, debiendo poder ser atravesados
fácilmente, aunque no sin cierto control de seguridad.
Abierto – Las tecnologías basadas en servicios Web ya incluyen de por si la
definición de lenguajes abiertos. Uno de ellos es el Web Services
Description Language (WSDL), el cual permite desarrollar y desplegar
clientes y servidores de forma rápida.
Seguridad – Este es un aspecto muy importante, en el cual puede que sea
necesario el realizar algunas mejoras sobre lo que, en general, aportan de
por si las tecnologías orientadas a servicios Web.
Como objetivo “corolario” y tal y como se comentó anteriormente, se realizará una
revisión de las tecnologías orientadas a servicios Web en cuanto a los mecanismos
de seguridad que proporcionan. Por tanto, y aunque no constituya un objetivo de la
tesis que se derive, es posible que se obtengan algunas conclusiones que puedan
servir de aportación a estos protocolos en cuanto a reforzar dichos mecanismos de
seguridad.
4 Abreviaturas y acrónimos
ACP Allied Communications Procedures/Publication
AHWGSy Ad-Hoc Working Group on Security
CMS Cryptographic Message Syntax
CORBA Common Object Request Broker Architecture
COTS Commercial Off-the-Shelf
CRONOS Crisis Response Operations in NATO Open System
CSP Common Security Protocol
DCOM Distributed Component Object Model
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
ISO
ISP International Standardized Profile
ISSC Information Systems Sub-Committee
ITU
LTS Long Term Solution
MMHS (WG) Military Message Handling System (Working Group)

NATO North Atlantic Treaty Organization
NC3B NATO Consultation Command and Control Board
NMS NATO Messaging System
ORB Object Request Broker
P22 Interpersonal Messaging Content as defined in X.420
P772 Military Messaging Content as defined in STANAG
4406/ACP123
PCT Protecting Content Type
PKCS Public Key Cryptography Standards
PKI Public Key Infrastructure
RFC Request For Comments
RMI Remote Method Invocation
S1C Security Profile 1 – Confidentiality as defined in X.400
S/MIME Secure/Multipurpose Internet Mail Extensions
SICOMEDE Sistema Conjunto de Mensajería de Defensa
SOAP Simple Object Access Protocol
STANAG 4406 (NATO) Standarization Agreement 4406 - Military Message
Handling System
TARE Telegraph Automatic Relay Equipment
UDDI Universal Description Discovery and Integration
W3C World Wide Web Consortium
WSDL Web Services Definition Services
X.400 Message Handling System as defined by ITU and ISO
X.411 MTS Abstract Service Definition and Procedures for Distributed
Operation
XML eXtended Markup Language
5 Bibliografía y referencias
a. Referencias civiles
[1] BONATTI C., EGGEN A., HOFFMAN P.: “Securing X.400 Content with S/MIME”,
[http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-09].
[2] BONATTI C., HOFFMAN P.: “Transporting S/MIME Objects in X.400”,
[http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-09].
[3] DEAN T., OTTAWAY W.: “Domain Security Services using S/MIME”, October 2001.
[http://www.ietf.org/rfc/rfc3183.txt]
[4] HOFFMAN P.: “Enhanced Security Services for S/MIME”, June 1999.
[http://www.ietf.org/rfc/rfc2634.txt]
[5] HOUSLEY R.: “Cryptographic Message Syntax”,
[http://www.ietf.org/internet-drafts/ draft-ietf-smime-rfc3369bis-03.txt]
[6] HOUSLEY R.: “Cryptographic Message Syntax (CMS) Algorithms”,
[http://www.ietf.org/internet-drafts/draft-ietf-smime-cmsalg-08.txt]
[ftp://ftp.rfc-editor.org/in-notes/rfc3370.txt]

[7] MSDN: SOAP y WebServices, 2003
[8] PÉREZ GARCÍA Miguel A.: “Análisis de los ORB's: interoperabilidad desde CORBA hasta
SOAP”. 2001
[9] RAMSDELL B.: “S/MIME Version 3.1 Certificate Handling”,
[http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-06]
[10] ITU-T : “Sistema de tratamiento de mensajes – Descripción y Servicios” (Rec. X.400), 1992.
[11] ITU-T: “Sistema de tratamiento de mensajes – Arquitectura General” (Rec. X.402), 1992.
[12] ITU-T: “Sistema de tratamiento de mensajes – Sistema de Transferencia de Mensajes.
Definición Abstracta del Servicio y procedimientos” (Rec. X.411), 1992.
[13] ITU-T: “Sistema de tratamiento de mensajes – Sistema de Mensajería Interpersonal” Rec.
(X.420), 1992.
[14] IETF: “Simple Mail Transfer Protocol” (RFC 821), 1982.
[15] IETF: “MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and
Describing the Format of Internet Message Bodies” (RFC 1341), 1992.
[16] IETF: “S/MIME Version 3 Message Specification” (RFC 2633), 1999.
[17] Stylusinc.NET: “SOAP vs. DCOM & RMI/IIOP”, 2001
[18] W3C: “ SOAP 1.2 Recommendation”. 24 June 2003
[18.1] SOAP Version 1.2 Part0: Primer
http://www.w3.org/TR/2003/REC-soap12-part0-20030624/
[18.2] SOAP Version 1.2 Part1: Messaging Framework
[18.3] SOAP Version 1.2 Part2: Adjuncts
[18.4] SOAP Version 1.2: Specification Assertions and Test Collection
http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/
b. Referencias OTAN
[19] STANAG 4406: “NATO Military Message Handling System – MMHS Extensions to [X.400 |
ISO/IEC 10021-1]”. 1996
[20] SC/4-AHWG/6-0202/12-08: “The NATO Profile for the Use of S/MIME CMS”, Issue 0.8, 2
Dec 2001.
[21] MMHSWG (NC3B brief): “Scenarios for MMHS Use of Future Messaging Technologies”,
Junio 2002.
[22] MMHSWG (NC3B WP257): “Concept paper for the NATO LTS”, Abril 2001.
[23] MMHSWG (NC3B WP367): “NATO Use of S/MIME: The Long Term Solution for Secure
Messaging”, Marzo 2002.
[24] MMHSWG (NC3B WP511): “Requirements and Rationale for Future Military Messaging”.
Octubre 2003

EVOLUCIÓN DEL STANAG 4406 HACIA TECNOLOGÍAS DE SERVICIOS WEB PARA SISTEMAS DE MENSAJERÍA MILITAR (MMHS)

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (16)

Similar a EVOLUCIÓN DEL STANAG 4406 HACIA TECNOLOGÍAS DE SERVICIOS WEB PARA SISTEMAS DE MENSAJERÍA MILITAR (MMHS)

Similar a EVOLUCIÓN DEL STANAG 4406 HACIA TECNOLOGÍAS DE SERVICIOS WEB PARA SISTEMAS DE MENSAJERÍA MILITAR (MMHS) (20)

Último

Último (13)

EVOLUCIÓN DEL STANAG 4406 HACIA TECNOLOGÍAS DE SERVICIOS WEB PARA SISTEMAS DE MENSAJERÍA MILITAR (MMHS)