Types de sécurité

Cette section décrit le développement et la nature de l'API RPCSEC_GSS.

La sécurité avant RPCSEC_GSS

L'un des premiers types de sécurité pris en charge par RPC fut AUTH_SYS (également appelé AUTH_UNIX). AUTH_SYS fournissait un justificatif d'identité de type UNIX, employant les ID d'utilisateur et de groupe, afin d'identifier l'expéditeur et le destinataire d'un message. AUTH_SYS est facile à mettre en oeuvre ; cependant, il est aussi facile à contourner, puisqu'il n'assure pas une véritable authentification -- un serveur n'a aucun moyen de vérifier qu'un client est réellement ce qu'il prétend. Il est donc relativement simple de contrefaire une requête réseau avec AUTH_SYS.

Un autre type de sécurité, AUTH_DES, est apparu peu après AUTH_SYS. AUTH_DES est basé sur une authentification à clé publique -- il a recours à un échange de clés Diffie-Hellman pour produire une clé commune entre la clé privée d'un client et la clé publique d'un serveur. La clé commune est ensuite employée pour chiffrer une clé de session DES, laquelle est déchiffrée par un serveur pour l'établissement d'une session.

Bien que AUTH_DES constitue un progrès significatif par rapport à AUTH_SYS, il possède certaines limitations empêchant son utilisation répandue. La principale objection soulevée est que la taille des clés est faible par rapport aux normes de chiffrement actuelles.

Plus tard, un autre type de sécurité RPC fut introduit. AUTH_KERB, basé sur Kerberos V4, assure une sécurité encore meilleure que AUTH_DES ou AUTH_SYS. Toutefois, il peut aussi être exploité.

Pour de plus amples renseignements sur ces types de sécurité, consultez le ONC+ Developer's Guide.

Intégrité et confidentialité : l'API GSS

Pour améliorer la sécurité, une nouvelle couche réseau, l'API «Generic Security Standard», ou API GSS, a été ajoutée. La structure de l'API GSS offre deux services de sécurité supplémentaires en plus de l'authentification :

• Intégrité. Avec le service d'intégrité, l'API GSS utilise le mécanisme sous-jacent pour authentifier les messages échangés entre programmes. Les sommes de contrôle cryptographiques établissent :

  • L'identité de l'émetteur des données pour le destinataire.

  • L'identité du destinataire pour l'émetteur (si une authentification mutuelle est demandée)

  • L'authenticité des données transmises elles-mêmes

• Confidentialité. Le service de confidentialité englobe le service d'intégrité. En outre, les données transmises sont aussi chiffrées afin de les protéger contre les oreilles indiscrètes.

  En raison des restrictions à l'exportation en vigueur aux USA, il est possible que le service de confidentialité ne soit pas disponible pour tous les utilisateurs de SEAM.

Actuellement, le GSS-API n'est pas exposé. Toutefois, certaines caractéristiques de l'API GSS sont "visibles" via les fonctions RPCSEC_GSS -- elles peuvent être manipulées de manière "opaque". Le programmeur n'a pas besoin de se préoccuper directement de leurs valeurs.

L'API RPCSEC_GSS

Le type de sécurité RPCSEC_GSS permet aux applications RPC ONC de profiter des caractéristiques de l'API GSS. RPCSEC_GSS se situe "au-dessus" de la couche de l'API GSS :

Figure 8-1 Couches de sécurité API GSS et RPCSEC_GSS

Avec l'interface de programmation de RPCSEC_GSS, les applications RPC ONC peuvent spécifier les éléments suivants :

mécanisme

Un paradigme de sécurité. Chaque type de mécanisme de sécurité offre un genre de protection des données différent, ainsi qu'un ou plusieurs niveaux de protection des données. Dans ce cas, tout mécanisme de sécurité pris en charge par l'API GSS (Kerberos V5, clé publique RSA, etc.).

service de sécurité

Soit confidentialité, soit intégrité (ou aucun des deux). La valeur par défaut est «intégrité». Le service est indépendant du mécanisme.

QOP

Qualité de protection. La qualité de protection indique le type d'algorithme cryptographique à employer pour mettre en oeuvre les services de confidentialité ou d'intégrité. Chaque mécanisme de sécurité peut être associé à une ou plusieurs qualités de protection.

Les applications peuvent obtenir des listes de qualités de protection valides et des mécanismes via des fonctions fournies par RPCSEC_GSS. (Voir "Fonctions diverses".) Les développeurs devraient éviter les mécanismes et les qualités de protection incorporés au programme dans leurs applications, afin qu'il ne soit pas nécessaire de modifier ces dernières pour utiliser des mécanismes et des qualités de protection nouveaux ou différents.

Dans le passé, les expressions "type de sécurité" et "type d'authentification" avaient le même sens. Mais depuis l'introduction de RPCSEC_GSS, le "type" a maintenant une signification légèrement différente. Un type peut maintenant inclure un service (intégrité ou confidentialité) ainsi qu'une authentification, bien que RPCSEC_GSS soit actuellement le seul type qui en inclue un.

Avec RPCSEC_GSS, les applications RPC ONC établissent un contexte de sécurité avec un homologue, échangent des données et détruisent le contexte, tout comme avec les autres types. Une fois un contexte établi, l'application peut changer la qualité de protection et le service pour chaque unité de données envoyée.

Pour de plus amples renseignements sur RPCSEC_GSS, y compris les types de données RPCSEC_GSS, consultez la page de manuel rpcsec_gss(3N).