Annexe B. Art antérieur (Prior Art)

(Cette section est non normative.)

Les recommandations de ce document abstraient les recommandations des spécifications pour une large gamme de protocoles d'application. À des fins de comparaison et pour esquisser l'historique de la réflexion au sein de l'IETF concernant la vérification d'identité de service d'application, cette section informative rassemble l'art antérieur en incluant le texte exact de divers RFCs (le seul changement étant quelques changements de nom de référence pour la cohérence avec le corps de ce document et l'omission de texte non pertinent marqué par les caractères "[...]").

B.1. IMAP, POP3, et ACAP (1999)

En 1999, [USINGTLS] a spécifié le texte suivant concernant la vérification d'identité de service d'application dans IMAP, POP3, et ACAP.

2.4. Vérification d'identité du serveur (Server Identity Check)

Lors de la négociation TLS, le client DOIT (MUST) vérifier sa compréhension du nom d'hôte du serveur par rapport à l'identité du serveur présentée dans le message Certificate du serveur, afin d'empêcher les attaques de l'homme du milieu. La correspondance est effectuée selon les règles suivantes :

Le client DOIT (MUST) utiliser le nom d'hôte du serveur qu'il a utilisé pour ouvrir la connexion comme valeur à comparer au nom du serveur tel qu'exprimé dans le certificat serveur. Le client NE DOIT PAS (MUST NOT) utiliser une forme quelconque du nom d'hôte serveur dérivée d'une source distante non sécurisée (par exemple, une recherche DNS non sécurisée). La canonisation CNAME n'est pas effectuée.

Si une extension subjectAltName de type dNSName est présente dans le certificat, elle DEVRAIT (SHOULD) être utilisée comme source de l'identité du serveur.

La correspondance est insensible à la casse.

Le caractère générique "*" PEUT (MAY) être utilisé comme composant de nom le plus à gauche dans le certificat. Par exemple, *.example.com correspondrait à a.example.com, foo.example.com, etc., mais pas à example.com.

Si le certificat contient plusieurs noms (par exemple, plus d'un champ dNSName), alors une correspondance avec n'importe lequel de ces champs est considérée comme acceptable.

Si la correspondance échoue, le client DEVRAIT (SHOULD) soit demander une confirmation explicite de l'utilisateur, soit terminer la connexion et indiquer que l'identité du serveur est suspecte.

B.2. HTTP (2000)

En 2000, [HTTP-TLS] a spécifié le texte suivant concernant la vérification d'identité de service d'application dans HTTP.

3.1. Identité du serveur (Server Identity)

En général, les requêtes HTTP/TLS sont générées en déréférençant un URI. En conséquence, le nom d'hôte du serveur est connu du client. Si le nom d'hôte est disponible, le client DOIT (MUST) le vérifier par rapport à l'identité du serveur présentée dans le message Certificate du serveur, afin d'empêcher les attaques de l'homme du milieu.

Si le client a des informations externes quant à l'identité attendue du serveur, la vérification du nom d'hôte PEUT (MAY) être omise. (Par exemple, un client peut se connecter à une machine dont l'adresse et le nom d'hôte sont dynamiques, mais le client connaît le certificat que le serveur présentera.) Dans de tels cas, il est important de réduire la portée des certificats acceptables autant que possible afin d'empêcher les attaques de l'homme du milieu. Dans des cas particuliers, il peut être approprié pour le client d'ignorer simplement l'identité du serveur, mais il doit être compris que cela laisse la connexion ouverte à des attaques actives.

Si une extension subjectAltName de type dNSName est présente, elle DOIT (MUST) être utilisée comme identité. Sinon, le champ Common Name (le plus spécifique) dans le champ Subject du certificat DOIT (MUST) être utilisé. Bien que l'utilisation du Common Name soit une pratique existante, elle est dépréciée et les autorités de certification sont encouragées à utiliser le dNSName à la place.

La correspondance est effectuée en utilisant les règles de correspondance spécifiées par [PKIX-OLD]. Si plus d'une identité d'un type donné est présente dans le certificat (par exemple, plus d'un nom dNSName), une correspondance dans l'une quelconque de l'ensemble est considérée comme acceptable. Les noms peuvent contenir le caractère générique * qui est considéré comme correspondant à n'importe quel composant de nom de domaine unique ou fragment de composant. Par exemple, .a.com correspond à foo.a.com mais pas à bar.foo.a.com. f.com correspond à foo.com mais pas à bar.com.

Dans certains cas, l'URI est spécifié comme une adresse IP plutôt qu'un nom d'hôte. Dans ce cas, le subjectAltName iPAddress doit être présent dans le certificat et doit correspondre exactement à l'IP dans l'URI.

Si le nom d'hôte ne correspond pas à l'identité dans le certificat, les clients orientés utilisateur DOIVENT (MUST) soit notifier l'utilisateur (les clients PEUVENT (MAY) donner à l'utilisateur la possibilité de continuer la connexion dans tous les cas) soit terminer la connexion avec une erreur de mauvais certificat. Les clients automatisés DOIVENT (MUST) enregistrer l'erreur dans un journal d'audit approprié (s'il est disponible) et DEVRAIENT (SHOULD) terminer la connexion (avec une erreur de mauvais certificat). Les clients automatisés PEUVENT (MAY) fournir un paramètre de configuration pour désactiver cette vérification, mais DOIVENT (MUST) fournir un paramètre pour l'activer.

Notez que dans de nombreux cas, l'URI lui-même provient d'une source non fiable. La vérification ci-dessus ne fournit aucune protection contre les attaques où cette source est compromise. Par exemple, si l'URI a été obtenu en cliquant sur une page HTML qui n'a pas été elle-même obtenue via HTTP/TLS, un homme du milieu pourrait avoir remplacé l'URI. Afin d'empêcher cette forme d'attaque, les utilisateurs devraient examiner attentivement le certificat présenté par le serveur pour déterminer s'il répond à leurs attentes.

B.3. LDAP (2000/2006)

En 2000, [LDAP-TLS] a spécifié le texte suivant concernant la vérification d'identité de service d'application dans LDAP.

3.6. Vérification d'identité du serveur (Server Identity Check)

Le client DOIT (MUST) vérifier sa compréhension du nom d'hôte du serveur par rapport à l'identité du serveur présentée dans le message Certificate du serveur afin d'empêcher les attaques de l'homme du milieu.

La correspondance est effectuée selon les règles suivantes :

Le client DOIT (MUST) utiliser le nom d'hôte du serveur qu'il a utilisé pour ouvrir la connexion LDAP comme valeur à comparer au nom du serveur tel qu'exprimé dans le certificat serveur. Le client NE DOIT PAS (MUST NOT) utiliser le nom DNS canonique du serveur ou toute autre forme dérivée du nom.

Si une extension subjectAltName de type dNSName est présente dans le certificat, elle DEVRAIT (SHOULD) être utilisée comme source de l'identité du serveur.

La correspondance est insensible à la casse.

Le caractère générique "*" est autorisé. S'il est présent, il ne s'applique qu'au composant de nom le plus à gauche.

Par exemple, *.bar.com correspondrait à a.bar.com, b.bar.com, etc., mais pas à bar.com. Si plus d'une identité d'un type donné est présente dans le certificat (par exemple, plus d'un nom dNSName), une correspondance dans l'une quelconque de l'ensemble est considérée comme acceptable.

Si le nom d'hôte ne correspond pas à l'identité basée sur dNSName dans le certificat conformément à la vérification ci-dessus, les clients orientés utilisateur DEVRAIENT (SHOULD) soit notifier l'utilisateur (les clients peuvent donner à l'utilisateur la possibilité de continuer la session LDAP dans ce cas) soit terminer la connexion et indiquer que l'identité du serveur est suspecte. Les clients automatisés DEVRAIENT (SHOULD) fermer la connexion, et retourner et/ou enregistrer une erreur indiquant que l'identité du serveur est suspecte.

Au-delà de la vérification d'identité du serveur décrite dans cette section, les clients DEVRAIENT (SHOULD) être prêts à effectuer d'autres vérifications pour s'assurer que le serveur est autorisé à fournir le service qu'il est observé fournir. Le client PEUT (MAY) avoir besoin d'utiliser des informations de politique locale.

En 2006, [LDAP-AUTH] a spécifié le texte suivant concernant la vérification d'identité de service d'application dans LDAP.

3.1.3. Vérification d'identité du serveur (Server Identity Check)

Afin d'empêcher les attaques de l'homme du milieu, le client DOIT (MUST) vérifier l'identité du serveur (telle que présentée dans le message Certificate du serveur). Dans cette section, la compréhension du client de l'identité du serveur (généralement l'identité utilisée pour établir la connexion de transport) est appelée l'"identité de référence" (reference identity).

Le client détermine le type (par exemple, nom DNS ou adresse IP) de l'identité de référence et effectue une comparaison entre l'identité de référence et chacune des valeurs subjectAltName du type correspondant jusqu'à ce qu'une correspondance soit produite. Une fois qu'une correspondance est produite, l'identité du serveur a été vérifiée et la vérification d'identité du serveur est terminée. Différents types de subjectAltName sont mis en correspondance de différentes manières. Les Sections 3.1.3.1 - 3.1.3.3 détaillent comment comparer les valeurs de divers types de subjectAltName.

Le client peut mapper l'identité de référence en un autre type avant d'effectuer la comparaison. Le mappage peut être effectué pour tout type de subjectAltName disponible vers lequel l'identité de référence peut être mappée. Cependant, l'identité de référence ne devrait être mappée que vers des types pour lesquels le mappage est soit intrinsèquement sécurisé (par exemple, extraire un nom DNS d'un URI pour le comparer avec un subjectAltName de type dNSName) soit effectué de manière sécurisée (par exemple, en utilisant [DNSSEC] ou en utilisant une table de recherche hôte-vers-adresse/adresse-vers-hôte configurée par l'utilisateur ou l'administrateur).

L'identité du serveur peut également être vérifiée en comparant l'identité de référence à la valeur Common Name (CN) [LDAP-SCHEMA] dans le dernier Nom Distingué Relatif (RDN) du champ Sujet du certificat serveur (où "dernier" fait référence à l'ordre d'encodage DER, et non à l'ordre de présentation dans une représentation de chaîne des données encodées en DER). Cette comparaison est effectuée en utilisant les règles pour la comparaison des noms DNS dans la Section 3.1.3.1 ci-dessous, à l'exception qu'aucune correspondance de caractère générique n'est autorisée. L'utilisation de la valeur Common Name est une pratique existante mais est dépréciée, et les autorités de certification sont encouragées à utiliser des valeurs subjectAltName à la place. Notez que les implémentations TLS peuvent représenter les DNs dans les certificats selon X.500 ou d'autres conventions. Par exemple, certaines implémentations X.500 ordonnent les RDNs dans un DN en utilisant une convention de gauche à droite (du plus significatif au moins significatif) au lieu de la convention LDAP de droite à gauche.

Si la vérification d'identité du serveur échoue, les clients orientés utilisateur DEVRAIENT (SHOULD) soit notifier l'utilisateur (les clients peuvent donner à l'utilisateur la possibilité de continuer la session LDAP dans ce cas) soit fermer la connexion de transport et indiquer que l'identité du serveur est suspecte. Les clients automatisés DEVRAIENT (SHOULD) fermer la connexion de transport et retourner et/ou enregistrer une erreur indiquant que l'identité du serveur est suspecte.

Au-delà de la vérification d'identité du serveur décrite dans cette section, les clients devraient être prêts à effectuer d'autres vérifications pour s'assurer que le serveur est autorisé à fournir le service qu'il est demandé de fournir. Le client peut avoir besoin d'utiliser des informations de politique locale pour prendre cette détermination.

3.1.3.1. Comparaison de noms DNS (Comparison of DNS Names)

Si l'identité de référence est un nom de domaine internationalisé, les implémentations conformes DOIVENT (MUST) le convertir au format ASCII Compatible Encoding (ACE) comme spécifié dans la Section 4 de la RFC 3490 [IDNA2003] avant comparaison avec les valeurs subjectAltName de type dNSName. Spécifiquement, les implémentations conformes DOIVENT (MUST) effectuer l'opération de conversion spécifiée dans la Section 4 de la RFC 3490 comme suit :

à l'étape 1, le nom de domaine DEVRA (SHALL) être considéré comme une "chaîne stockée" ;

à l'étape 3, définir le drapeau appelé "UseSTD3ASCIIRules";

à l'étape 4, traiter chaque étiquette avec l'opération "ToASCII"; et

à l'étape 5, changer tous les séparateurs d'étiquettes en U+002E (point).

Après avoir effectué la conversion "ToASCII", les étiquettes DNS et les noms DOIVENT (MUST) être comparés pour l'égalité selon les règles spécifiées dans la Section 3 de la RFC 3490.

Le caractère générique '*' (ASCII 42) est autorisé dans les valeurs subjectAltName de type dNSName, et alors uniquement comme étiquette DNS la plus à gauche (la moins significative) dans cette valeur. Ce caractère générique correspond à n'importe quelle étiquette DNS la plus à gauche dans le nom du serveur. C'est-à-dire que le sujet *.example.com correspond au nom de serveur a.example.com et b.example.com, mais pas example.com ou a.b.example.com.

3.1.3.2. Comparaison d'adresses IP (Comparison of IP Addresses)

Si l'identité de référence est une adresse IP, l'identité DOIT (MUST) être convertie en une chaîne d'octets "dans l'ordre octet réseau" [IP] [IPv6]. Pour IP Version 4, comme spécifié dans la RFC 791, la chaîne d'octets contiendra exactement 4 octets. Pour IP Version 6, comme spécifié dans la RFC 2460, la chaîne d'octets contiendra exactement 16 octets. Cette chaîne d'octets est ensuite comparée aux valeurs subjectAltName de type iPAddress. Une correspondance se produit si l'identité de référence (chaîne d'octets) et valeur (chaîne d'octets) sont identiques.

3.1.3.3. Comparaison d'autres types de subjectName (Comparison of Other subjectName Types)

Les implémentations clientes PEUVENT (MAY) supporter la correspondance avec d'autres types de valeurs subjectAltName comme décrit dans d'autres documents.