Politique applicable à un système de messagerie militaire

militaire

Un autre cas d'utilisation intéressant est celui de la messagerie militaire. L'OTAN a publié, en 2005, un document sous le titre Future Military Messaging [2] (FMM), dont l'objectif était de définir les exigences d'un futur système de messagerie militaire et de clarifier la conception d'un tel système. Ce document propose trois niveaux de services (high, medium et basic grades) comportant chacun un ensemble d’exigences à respecter. Le niveau high grade, qui se rapproche des concepts de messagerie de confiance, définit les mécanismes à mettre en œuvre pour répondre à un besoin d’échanges d'informations critiques et officielles entre les utilisateurs dans un environnement opérationnel militaire. L'information critique est définie comme une information où des vies ou une mission militaire sont mises en péril si le message n'est pas remis au destinataire dans un délai défini. Les informations officielles sont des informations échangées entre organisations militaires. En ce qui concerne les niveaux medium et basic grades, ils couvrent le périmètre des échanges professionnels voire privés.

Parallèlement à ces travaux OTAN, A. Melnikov a publié une recommandation [153], compatible avec les exigences présentes dans le document FMM, qui décrit l'ensemble des champs requis pour les messages militaires. Ces champs viennent étendre le standard IMF. A partir de ces différents travaux, il est intéressant de définir une politique de correspondance électronique applicable dans un système de messagerie militaire. L'idée proposée ici est d'extraire quelques exigences obligatoires et de les intégrer dans l'exemple de politique de correspondance.

Les exigences sélectionnées sont les suivantes:  peer-entity authentication (STARTTLS)  user authentication (SASL)

114

Ensuite, il est nécessaire d'identifier les évènements concernés et les mécanismes à mettre en œuvre.

 peer-entity authentication. L'évènement concerné est la soumission. Ce mécanisme peut être mis en œuvre à l'aide du protocole STARTTLS[84].

 user authentication. L'évènement concerné est la soumission. Ce mécanisme peut être mis en œuvre à l'aide du protocole SMTP AUTH [66] et SASL [65] en associant un ou plusieurs algorithmes d'authentification.

 Precedence (IMF). Les évènements concernés sont la création et l'affichage. Par sa présence, cette information indique le niveau d'urgence militaire pour les destinataires en action (champ d'entête To). Ce champ étend le standard IMF.

Dans cet exemple, trois évènements sont donc impliqués par l'application de la politique de correspondance: creation, submission et display . La Figure 42 décrit le périmètre d'application de la politique de correspondance militaire que nous appellerons MIL. La politique de correspondance MIL peut être exprimée de la manière suivante. Elle est composée de trois politiques de correspondance évènementielles.

= { , , }

La politique de correspondance évènementielle , exécutée lors de l'évènement creation, décrit les règles qui ne s'appliquent que sur le message.

La politique de correspondance évènementielle , exécutée lors de l'évènement submission, décrit les règles qui s'appliquent lors du transfert du message entre le aMUA et le MSA puis sur le message.

La politique de correspondance évènementielle , exécutée lors de l'évènement display, décrit les règles qui ne s'appliquent que sur le message.

Figure 42 : périmètre d'application de la politique de correspondance de messagerie militaire

7.2.1 Politique évènementielle applicable lors de l'évènement de création

La première description proposée ici comporte les règles à appliquer lors de l'évènement de création du message. Pour des soucis de clarté, la description de la politique est réalisée en plusieurs parties. Creation InitTransfer FinalTransfer Submission Retrieving Display Delivery Evènements appliquant la politique MIL

115

1.1 <CORRESPONDENCE_POLICY name="MIL" version = "1.0" domain="mil.org"> 1.2 <EVENT eventId="CREATION">

1.3 <POLICY_TARGET policyTargetId ="MESSAGE"> 1.4 < POLICY_TYPE policyType="TRANSFORMATION"> ...

La partie ci-dessus de politique peut être interprétée de la manière suivante :

- la ligne 1.1 comporte la référence de politique de correspondance, à savoir la composition de name, version et domain.

- la ligne 1.2 comporte l'évènement concerné (CREATION).

- la ligne 1.3 comporte la cible sur laquelle la politique sera appliquée, à savoir le message. - la ligne 1.4 comporte le nom du type de politique, à savoir TRANSFORMATION.

2.1 <RULE ruleId ="g1">

2.2 <ACTION> addHeaderField 2.3 <PARAMETERS>

2.4 <PARAMETER name="description" > add primary precedence header field </PARAMETER> 2.5 <PARAMETER name="headerFieldName" > MMHS-Primary-Precedence </PARAMETER> 2.5 </PARAMETERS>

2.7 </ACTION> ...

La partie ci-dessus propose une description d'une règle permettant l'ajout d'un champ d'entête. - la ligne 2.1 comporte l'identifiant de la règle.

- la ligne 2.2 comporte le nom de l'opération exécutée pour ajouter le champs d'entête. - la ligne 2.4 comporte une description de l'opération.

- la ligne 2.5 comporte le nom du champ d'entête à créer, à savoir MMHS-PRIMARY- PRECEDENCE. La valeur de ce champ est récupérée à partir du formulaire de création de message.

7.2.2 Politique évènementielle applicable lors de l'évènement de soumission

La description proposée ici comporte les règles à appliquer lors de l'évènement de soumission du message.

3.1 <CORRESPONDENCE_POLICY name="MIL" version = "1.0" domain="mil.org"> 3.2 <EVENT eventId="SUBMISSION">

3.3 <POLICY_TARGET policyTargetId ="TRANSFER"> 3.4 < POLICY_TYPE>

3.5 <RULE ruleId = "t1">

3.6 <ACTION> peerEntityAuthentication 3.7 <PARAMETERS>

3.8 <PARAMETER name="description" > STARTTLS </PARAMETER> 3.9 <PARAMETER name="status"> required </PARAMETER>

3.10 <PARAMETER name="method"> clientAuthentication </PARAMETER> 3.11 </PARAMETERS>

3.12 </ACTION> ...

116

La partie ci-dessus propose une description d'une règle concernant l'authentification mutuelle du MUA et du MSA basée sur le standard STARTTLS.

- la ligne 3.2 comporte l'évènement concerné (SUBMISSION).

- la ligne 3.3 comporte la cible sur laquelle la politique sera appliquée, à savoir le transfert. - la ligne 3.5 comporte l'identifiant de la règle.

- la ligne 3.6 comporte le nom de l'opération exécutée pour l'authentification mutuelle. - la ligne 3.8 comporte une description de l'opération.

- la ligne 3.9 comporte le statut de l'opération, à savoir exigé. - la ligne 3.10 comporte la méthode imposée.

4.1 <RULE ruleId = "t2">

4.2 <ACTION> userAuthentication 4.3 <PARAMETERS>

4.4 <PARAMETER name="description" > SASL user authentication </PARAMETER> 4.5 <PARAMETER name="status"> required </PARAMETER>

4.6 <PARAMETER name="algorithm"> SASL External </PARAMETER> 4.7 </PARAMETERS>

4.8 </ACTION> ...

La partie ci-dessus propose une description d'une règle concernant l'authentification de l'utilisateur basée sur le standard SASL.

- la ligne 4.1 comporte l'identifiant de la règle.

- la ligne 4.2 comporte le nom de l'opération exécutée pour l'authentification de l'utilisateur. - la ligne 4.4 comporte une description de l'opération.

- la ligne 4.5 comporte le statut de l'opération, à savoir exigé. - la ligne 4.6 comporte la méthode d'authentification imposée.

7.2.3 Politique évènementielle applicable lors de l'évènement d'affichage

La description proposéeici est liée à l'évènement d'affichage du message et donc appliquée dans le MUA du destinataire.

5.1 <CORRESPONDENCE_POLICY name="MIL" version = "1.0" domain="mil.org"> 5.2 <EVENT eventId="DISPLAY">

5.3 <POLICY_TARGET policyTargetId ="MESSAGE"> 5.4 < POLICY_TYPE policyType="VERIFICATION"> ...

La partie ci-dessus de politique peut être interprétée de la manière suivante :

- la ligne 5.1 comporte la référence de politique de correspondance, à savoir la composition de name, version et domain.

- la ligne 5.2 comporte l'évènement concerné (DISPLAY).

- la ligne 5.3 comporte la cible sur laquelle la politique sera appliquée, à savoir le message. - la ligne 5.4 comporte le nom du type de politique, à savoir VERIFICATION.

117

6.1 <RULE ruleId ="v1">

6.2 <ACTION> checkHeaderField 6.3 <PARAMETERS>

6.4 <PARAMETER name="description" > check primary precedence header field </PARAMETER> 6.5 <PARAMETER name="headerFieldName" > MMHS-Primary-Precedence </PARAMETER> 6.6 </PARAMETERS>

6.7 </ACTION> ...

La partie ci-dessus propose une description d'une règle permettant la vérification d'un champ d'entête.

- la ligne 6.1 comporte l'identifiant de la règle.

- la ligne 6.2 comporte le nom de l'opération exécutée pour vérifier le champs d'entête. - la ligne 6.4 comporte une description de l'opération.

- la ligne 6.5 comporte le nom du champ d'entête à vérifier, à savoir MMHS-PRIMARY- PRECEDENCE.

Dans cet exemple, la politique DISPLAY permet de vérifier ce qui a été appliqué dans la politique CREATION. Cependant, d'autres scénarios de politique sont envisageables. Il serait par exemple possible de mettre en œuvre des mécanismes de contrôle de rôle. Pour cela, la politique SUBMISSION pourrait être étendue et comporter des règles imposant, une vérification du rôle porté par le signataire du message puis l'ajout d'une contre-signature cryptographique attestant de ce rôle. La politique DISPLAY comporterait des règles visant à vérifier la signature et la contre-signature. Ainsi, la politique DISPLAY serait satisfaite seulement si les politiques CREATION et SUBMISSION ont été correctement appliquées. Ce dernier exemple démontre l'intérêt de la décomposition des politiques en évènements.

7.3

Bilan

Dans ce chapitre, nous avons présenté deux exemples de description de politiques de correspondance. En effet, les conditions de réalisation de cette thèse imposaient de proposer des concepts contribuant à la définition de futurs systèmes de messagerie civile et militaire. Pour le premier exemple, nous nous sommes appuyés sur les spécifications du référentiel général de sécurité appelé RGS [5]. Pour le second exemple, nous avons pris en compte les différentes spécifications existantes pour la définition d'un système de messagerie militaire, compatible avec les exigences de l'OTAN.

118

Chapitre 8