1. L’authentification des communicateurs
SEP permet une authentification des divers communicateurs. Dans le cas ou une IA est active, cette dernière présente un certificat d’identité et un certificat délégué par le serveur origine lui donnant le droit d’authentifier les utilisateurs. Si la IA SEP est passive, c’est le serveur origine qui s’authentifie avec un certificat d’identité auprès des clients. L’authentification par certificat d’identité est toujours accompagnée d’une signature sur l’ensemble des paramètres échangés.
Les clients SEP ont le choix entre plusieurs méthodes d’authentification. Une particularité de SEP est qu’il permet au client durant une même session, d’avoir plusieurs authentifications : par exemple, une authentification par certificat X.509 puis une deuxième par un mot de passe. Ceci afin d’éviter la négociation d’une nouvelle session SEP pour accéder à de nouvelles ressources.
2. La confidentialité de l’information
Les informations transitant entre les entités sont sécurisées durant le transport à travers le réseau. Avec SEP, la confidentialité peut être maintenue de bout en bout entre l’émetteur et le
destinataire, même dans le cas de l’utilisation d’un serveur intermédiaire. Afin de fournir la confidentialité, nous utilisons le chiffrement conventionnel par AES ou 3DES.
3. L’intégrité des données
SEP garantit que le contenu du message n’est pas altéré pendant le transport. En effet, les messages SEP sont protégés par un HMAC, associé à SHA-1 ou MD5.
Avec SEP, les algorithmes de chiffrement, de hachage et de signatures sont négociés durant le premier échange SEP pour chaque service négocié.
4. Non rejeu
L’anti-rejeu (parfois appelé « intégrité de séquence ») est assuré dans toutes les configurations SEP grâce à un compteur Sequence Number (SN) placé dans l’en-tête des messages SEP et protégé en intégrité.
Dans le cas d’utilisation du protocole de transport TCP, le SN est concaténé avec les autres données protégées en intégrité dans le champ MAC des messages SEP.
Dans le cas d’utilisation du protocole de transport UDP, le SN est géré de la même manière suivante que celle d’IPSec ESP. Ainsi, le premier datagramme d’un flux entre deux correspondants SEP, possède un SN égal à 1. A chaque nouveau datagramme émis par une pile SEP, le SN est incrémenté de 1. A la réception d’un message, SEP gère une fenêtre glissante (de 32 ou 64 positions par exemple) permettant de préciser les numéros de séquence déjà reçus dans cette fenêtre. L’algorithme de détection du rejeu est le suivant :
- Un datagramme avec un SN plus petit que la borne inférieure de la fenêtre est détruit; - Un datagramme avec un SN déjà validé dans la fenêtre est un rejeu et doit être traité en conséquence (alerte à l’opérateur, journalisation,…);
- Un datagramme avec un SN dans la fenêtre mais non encore validé est accepté; - Un datagramme avec un SN dépassant la borne supérieure de la fenêtre provoque le glissement de celle-ci vers ce nouveau SN.
Le fait d’ignorer les datagrammes dont le SN est en deçà de la fenêtre peut entraîner des réémissions de datagrammes gérées par TCP (mais pas par UDP, pour lequel les datagrammes sont définitivement perdus).
5. La mise en œuvre d’un VPN
La principale caractéristique de SEP est qu’il permet la mise en œuvre d’un VPN au niveau d’échange entre un client et un serveur destinataire à travers une autorité intermédiaire. En effet, les paquets SEP sont identifiés par un en-tête qui permet de multiplexer les données de plusieurs applications et de plusieurs clients. Ceci grâce à un double identificateur session (GSID et LSID) placé dans les en-têtes SEP ainsi qu’un champ (Protocol Type) qui contient le type de donnée négocié (HTTP, FTP, ASNP, etc.).
Les applications comme HTTP et FTP peuvent bénéficier des services de sécurité de SEP sans avoir à changer leur port. En effet, la même technique de port forwarding utilisée avec SSH va permettre à SEP de multiplexer plusieurs types de trafic sans avoir à changer les ports de chaque application. De ce fait, SEP devient un protocole transparent aux applications et qui ne nécessite aucune intégration des modules de sécurité au niveau applicatif.
6. Le service de Single Sign On ou SSO
Le service de Single Sign On (SSO) est proposé récemment comme un nouveau service dans de nombreux protocoles comme le protocole SAML [SAML] pour les Web Services et le protocole SSH [SSH-Arch]. Même si la notion de Single Sign On diffère d’un protocole à un
autre (SSH utilise la notion d’un agent SSH pour transporter la clé publique du client entre les serveurs alors que SAML est basé sur une architecture centralisée), ce service est indispensable pour notre protocole où les différentes applications peuvent être cachées derrière une IA qui oriente après les requêtes client vers le service demandé. Ainsi, l’autorité intermédiaire IA est une entité centrale pour appliquer le service SSO entre un client qui demande l’accès à plusieurs ressources distribuées sur plusieurs serveurs SEP et possédant tous la même méthode d’authentification. Pour cela, le nombre d’opérations d’authentification d’un client durant une session SEP est relatif au nombre d’opérations d’authentification distinctes. Par exemple, si le client souhaite accéder à 4 serveurs dont 3 possèdent la même méthode d’authentification, le client est obligé de présenter seulement deux identités.
7. Le contrôle d’accès
Grâce à l’intégration d’un intermédiaire de confiance (IA) dans l’architecture et les échanges SEP, la IA de SEP fournit un point unique et stratégique où l’audit et le contrôle d’accès peuvent être imposés. Ces IAs bénéficient également d’une base de données relationnelle qui centralise les différents types d’accès et les règles de sécurité nécessaires pour chaque type d’application.