SPF vs SENDER ID : L'AUTHENTIFICATION A LA SOURCE

Au sein de l'infrastructure actuelle de gestion des emails, l'usurpation d'identité peut s'effectuer à différents niveaux comme dans les en-têtes des messages ou dans l'enveloppe SMTP. Ces malversations sont bien connues et exploitées par les spammeurs afin de contourner les mesures de sécurité mises en place.

La fin de l'année 2004 fut marquée par une volonté générale de lutter contre le spam. C'est ainsi que l'IETF a publié plusieurs RFC expérimentales, comme SPF[1] et SenderID[2], afin d'offrir une solution d'authentification faible de l'expéditeur des emails.

Description des technologies

Sender Policy Framework

Le protocole SPF permet aux propriétaires de noms de domaines de déclarer les adresses IP autorisées à envoyer du courrier depuis leur domaine. Cette déclaration permet de protéger les serveurs de mails contre l'usurpation d'identité.

SPF protège l'enveloppe du message, et plus précisément le domaine identifié par les méthodes "MAIL FROM" et "HELO" de la session SMTP.
Cette solution repose sur le protocole de résolution de noms de domaines en ajoutant simplement un champ "TXT" ou "SPF" aux enregistrements DNS.

Il est possible définir une seule adresse IP pouvant envoyer du courrier depuis ce domaine grâce à la requête suivante:

SPF n'est pas supporté, nativement, par les serveurs SMTP de type relais. Ces serveurs permettent de relayer des emails entre divers domaines.
Le problème provient du fait que ces relais ne modifient pas l'enveloppe SMTP mais l'adresse IP source du message. Ainsi la vérification entre l'adresse IP source et le paramètre "MAIL FROM" est invalide.

La figure1 illustre ce problème : les mails du domaine 'example.jp' sont envoyés depuis l'adresse IP "192.0.2.1" alors que le destinataire final recevra le message depuis le serveur "192.0.2.2".



Figure1: Exemple de relais SMTP
Afin de résoudre ce problème, la communauté "openspf" a développé le module SRS[3]. Ce module modifie les paramètres"MAIL FROM" des sessions SMTP afin d'indiquer que le message a été relayé (voir les figures 2 et 3).


Figure 2: Relais sans SRS

Figure 3: Relais avec SRS

SenderID: la nouvelle version de SPF ?

La solution de lutte contre l'usurpation d'identité proposée par Microsoft est basée sur un regroupement des technologies SPF et Caller-ID.

A l'instar de SPF, SenderID authentifie le domaine source des messages et utilise les enregistrements DNS. La syntaxe implémentée est également similaire à SPF sauf que l'identification du protocole est réalisée par la présence du champ "spf2.0".

Fonctionnement du protocole Sender-ID de Microsoft
La confusion provient bien souvent de ces éléments.

Pourtant Sender ID est un nouveau protocole totalement indépendant car il n'authentifie pas les mêmes caractéristiques des messages. Tandis que SPF vérifie les paramètres du protocole SMTP, SenderID s'appuie sur l'authentification de certains en-têtes du message même. La solution de Microsoft est en concurrence de la technologie "DomainKeys IM" (DKIM) développée par Yahoo et Cisco.

Sender ID implémente l'algorithme PRA[4]. Cet algorithme utilise les en-têtes suivantes du message: "Resent-Sender", "Resent-From", "Sender" et "From" afin d'identifier la source.

Le protocole Sender ID viole la RFC de SPF en utilisant les valeurs du champ "v=spf1" en absence de données "spf2.0" au sein des enregistrements DNS. Le problème résulte de certaines données SPF qui sont incompatibles avec le SenderID. Microsoft recommande alors aux administrateurs de modifier et d'adapter les informations déclarées.

La communauté SPF a d'ailleurs fait appel auprès de l'IESG afin de modifier le contenu de la RFC expérimentale "SenderID".

Il est intéressant de remarquer que l'enregistrement du domaine "aol.com" renseigne les protocoles SPF et SenderID tandis que l'enregistrement du domaine Microsoft "hotmail.com" n'inclut que le SPF (figure 4).


Figure 4: Exemples d'enregistrements DNS

La fin du SPAM

Ce type d'authentification ne peut combattre seul le fléau du pourriel. Il faut simplement le prendre comme un élément complémentaire de décision au cours de l'analyse bayésienne des emails. Ainsi, certains robots de spams se sont déjà adaptés et présentent leur domaine réel d'expédition.

Il est important de souligner que ces solutions n'authentifient que le domaine source et non l'expéditeur. Pour illustrer ce problème, un salarié malveillant peut toujours envoyer des courriers électroniques en usurpant l'adresse personnelle du directeur. D'autre part, en exploitant des faiblesses du protocole DNS, un pirate pourrait contourner ce système d'authentification.

Conclusion

L'authentification du domaine source constitue un premier pas dans la lutte contre le vol didentité mais n'est pas aussi efficace et non répudiable que la signature numérique.
Le principal avantage de ces solutions repose sur la transparence pour l'utilisateur final et un déploiement aisé sur les serveurs en production.
D'un point de vue "critique", ces systèmes représentent une rustine de plus sur un protocole beaucoup trop vieux. L'implémentation de la cryptographie permettrait de résoudre de nombreux problèmes avec des coûts d'intégration pas forcément beaucoup plus importants que les budgets de "Recherche&Développements" des laboratoires de luttes contre le Spam.

Bibliographie

[1] SPF http://www.ietf.org/rfc/rfc4408.txt
[2] Sender ID http://www.ietf.org/rfc/rfc4406.txt
[3] Sender Rewriting Scheme http://www.openspf.org/SRS
[4] Purported Responsible Address http://www.ietf.org/rfc/rfc4407.txt
[5] Internet Engineering Steering Group http://www.ietf.org/rfc/rfc4407.txt