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

Página 1

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: [email protected],

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.

Página 2

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

Página 3

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.

Página 4

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

Página 5

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

Página 6

ASN.1/BER P 772

SM TP

ORIGIN ATOR RECIPIEN T

BODY

Subject:

P rimary-recip ien ts :

Originator :

P rimary-precedence :

Copy-precedence:

Distr ibut ion-codes :

Body P art n

Body P art 1

Body P art 2

HEADERASN.1/BER P772

BODY

Subject:

P rimary-recip ien ts :

Originator :

P rimary-precedence :

Copy-precedence:

Distr ibut ion-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

Página 7

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: m essage/p772Content-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/p772Content-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

Página 8

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:

Página 9

SMTPMTA

P772UA

SMTPMTA

P772UA

SMTPUA

RFC 822/MIME

UA

P772UA

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

Página 10

822/MIME

--boundary_ABCxyzContent-Type: audio/basic

SMTP


--boundary_ABCxyzContent-Type: text/plain

BODY

822/MIME

--boundary_ABCxyz--



BODY

--boundary_ABCxyz--

P772 Requirements

HEADERSFrom:Date:Subject:To:MIME-Version: 1.0Content-Type: multipart/mixed;

boundary=boundary_ABCxyz

P772 Requirements

HEADERSFrom:Date:Subject:To:MIME-Version: 1.0Content-Type: multipart/mixed;


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.

Página 11

822/MIMEFrom:Date:Subject:To:MIME-Version: 1.0Content-Type: multipart/mixed;



SMTP



P772 Requirements

BODY

822/MIMEFrom:Date:Subject:To:MIME-Version: 1.0Content-Type: multipart/mixed;


--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 formato RFC 822/MIME.

Página 12

822/MIME

-- boundary_ ABCxyz Content - Type: audio/basic

X.400


-- boundary_ ABCxyz Content - Type: text/plain

BODY

822/MIME

-- boundary_ ABCxyz --


-- boundary_ ABCxyz Content - Type: text/plain

BODY


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 Content - Type: multipart/mixed;

boundary=boundary_ ABCxyz

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 formato RFC 822/MIME.

822/MIME From: Date: Subject: To: MIME - Version: 1.0 Content - Type: multipart/mixed;



X.400


-- boundary_ ABCxyz Content - Type: text/plain P772 Requirements

BODY

822/MIME From: Date: Subject: To: MIME - Version: 1.0 Content - Type: multipart/mixed;




-- boundary_ ABCxyz Content - Type: text/plain P772 Requirements

BODY


Figura 7.: Extensiones militares situadas en el cuerpo del mensaje en formato RFC 822/MIME

Página 13

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

Página 14

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

Página 15

DCOM CORBA/IIOP EJB/RMI/IIOP SOAPFormato 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

Página 16

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. Consumer sends UDDI

request for list of

available services

4. Registry sends UDDI

response with WSDL

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

ServiceConsumer

ServiceProvider

RESPONSE

2. Pro

vider

publi

shes

WSDL s

ervice

desc

riptio

nPUBLISH DISCOVER

REQUEST



request for list of

available services


response with WSDL




Service Registry

ServiceConsumer

ServiceProvider

RESPONSE

2. Pro

vider

publi

shes

WSDL s

ervice

desc

riptio

nPUBLISH

REQUEST



request for list of

available services


response with WSDL




Service Registry

ServiceConsumer

ServiceProvider

RESPONSE

2. Pro

vider

publi

shes

WSDL s

ervice

desc

riptio

nPUBLISH

Página 17

• 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


2. Prov

ider p

ublis

hes

WSDL s

ervice

desc

riptio

n


request for list of

available services


response with WSDL




DISCOVER

RESPONSETLS Tunnel

TLSTLS

ServiceProvider

Service Registry

ServiceConsumer

Tunneling provides severaluseful 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


2. Prov

ider p

ublis

hes

WSDL s

ervice

desc

riptio

n


request for list of

available services


response with WSDL




DISCOVER

RESPONSETLS Tunnel

TLSTLS

TLS TunnelTLS Tunnel

TLSTLS

TLSTLS

ServiceProvider

Service Registry

ServiceConsumer

Tunneling provides severaluseful security properties:

• Message Integrity• Message Confidentiality• Protection Against Replay Attacks

Tunneling fails to provide:• End-to-end Security• Mutual Authentication• Non-repudiation• Authorization

Página 18

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:

Página 19

�� 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)

Página 20

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]

Página 21

[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

Technology

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