10. Authentication and Message-Integrity Mechanisms (Mécanismes d'authentification et d'intégrité des messages)

Cette section définit deux mécanismes que les clients et serveurs peuvent utiliser pour fournir l'authentification et l'intégrité des messages dans STUN ; ces deux mécanismes sont connus sous le nom de mécanisme d'identification à court terme (short-term credential mechanism) et mécanisme d'identification à long terme (long-term credential mechanism). Ces deux mécanismes sont optionnels, et chaque utilisation doit (must) spécifier si et quand ces mécanismes sont utilisés. Ainsi, les clients et les serveurs sauront quel mécanisme (le cas échéant) suivre en fonction de la connaissance de l'utilisation applicable. Par exemple, un serveur STUN sur l'Internet public prenant en charge ICE n'aurait pas d'authentification, tandis que la fonctionnalité de serveur STUN dans un agent prenant en charge les vérifications de connectivité utiliserait le mécanisme d'identification à court terme. Un aperçu de ces deux mécanismes est fourni dans la Section 3.

Chaque mécanisme spécifie le traitement supplémentaire requis pour utiliser ce mécanisme, étendant le traitement spécifié dans la Section 7. Le traitement supplémentaire se produit à trois endroits différents : lors de la formation d'un message, lors de la réception d'un message immédiatement après l'exécution des vérifications de base, et dans le traitement détaillé des réponses d'erreur.

10.1. Short-Term Credential Mechanism (Mécanisme d'identification à court terme)

Le mécanisme d'identification à court terme suppose qu'avant la transaction STUN, le client et le serveur ont utilisé un autre protocole pour échanger une identification sous forme de nom d'utilisateur et de mot de passe. Cette identification est limitée dans le temps. La limite de temps est définie par l'utilisation.

Par exemple, dans l'utilisation ICE [MMUSIC-ICE], les deux points de terminaison utilisent une signalisation hors bande pour s'accorder sur un nom d'utilisateur et un mot de passe, et ce nom d'utilisateur et mot de passe sont applicables pendant la durée de la session média.

Cette identification est utilisée pour former une vérification d'intégrité de message dans chaque requête et dans de nombreuses réponses. Il n'y a pas de défi et de réponse comme dans le mécanisme à long terme ; par conséquent, la relecture est empêchée en vertu de la nature limitée dans le temps de l'identification.

10.1.1. Forming a Request or Indication (Formation d'une requête ou indication)

Pour un message de requête ou d'indication, l'agent doit (MUST) inclure les attributs USERNAME et MESSAGE-INTEGRITY dans le message. Le HMAC pour l'attribut MESSAGE-INTEGRITY est calculé comme décrit dans la Section 15.4. Notez que le mot de passe n'est jamais inclus dans la requête ou l'indication.

10.1.2. Receiving a Request or Indication (Réception d'une requête ou indication)

Après que l'agent a effectué le traitement de base d'un message, l'agent effectue les vérifications listées ci-dessous dans l'ordre spécifié :

• Si le message ne contient pas à la fois un attribut MESSAGE-INTEGRITY et un attribut USERNAME :

  • Si le message est une requête, le serveur doit (MUST) rejeter la requête avec une réponse d'erreur. Cette réponse doit (MUST) utiliser un code d'erreur de 400 (Bad Request).

  • Si le message est une indication, l'agent doit (MUST) abandonner silencieusement l'indication.

• Si le USERNAME ne contient pas une valeur de nom d'utilisateur actuellement valide dans le serveur :

  • Si le message est une requête, le serveur doit (MUST) rejeter la requête avec une réponse d'erreur. Cette réponse doit (MUST) utiliser un code d'erreur de 401 (Unauthorized).

  • Si le message est une indication, l'agent doit (MUST) abandonner silencieusement l'indication.

• En utilisant le mot de passe associé au nom d'utilisateur, calculer la valeur pour l'intégrité du message comme décrit dans la Section 15.4. Si la valeur résultante ne correspond pas au contenu de l'attribut MESSAGE-INTEGRITY :

  • Si le message est une requête, le serveur doit (MUST) rejeter la requête avec une réponse d'erreur. Cette réponse doit (MUST) utiliser un code d'erreur de 401 (Unauthorized).

  • Si le message est une indication, l'agent doit (MUST) abandonner silencieusement l'indication.

Si ces vérifications réussissent, l'agent continue à traiter la requête ou l'indication. Toute réponse générée par le serveur doit (MUST) inclure l'attribut MESSAGE-INTEGRITY, calculé en utilisant le mot de passe utilisé pour authentifier la requête. La réponse ne doit pas (MUST NOT) contenir l'attribut USERNAME.

Si l'une des vérifications échoue, un serveur ne doit pas (MUST NOT) inclure un attribut MESSAGE-INTEGRITY ou USERNAME dans la réponse d'erreur. C'est parce que, dans ces cas d'échec, le serveur ne peut pas déterminer le secret partagé nécessaire pour calculer MESSAGE-INTEGRITY.

10.1.3. Receiving a Response (Réception d'une réponse)

Le client recherche l'attribut MESSAGE-INTEGRITY dans la réponse. S'il est présent, le client calcule l'intégrité du message sur la réponse comme défini dans la Section 15.4, en utilisant le même mot de passe qu'il a utilisé pour la requête. Si la valeur résultante correspond au contenu de l'attribut MESSAGE-INTEGRITY, la réponse est considérée comme authentifiée. Si la valeur ne correspond pas, ou si MESSAGE-INTEGRITY n'était pas présent, la réponse doit (MUST) être abandonnée, comme si elle n'avait jamais été reçue. Cela signifie que les retransmissions, le cas échéant, continueront.

10.2. Long-Term Credential Mechanism (Mécanisme d'identification à long terme)

Le mécanisme d'identification à long terme repose sur une identification à long terme, sous forme de nom d'utilisateur et de mot de passe partagés entre le client et le serveur. L'identification est considérée à long terme car on suppose qu'elle est provisionnée pour un utilisateur et reste en vigueur jusqu'à ce que l'utilisateur ne soit plus abonné au système ou jusqu'à ce qu'elle soit modifiée. Il s'agit essentiellement du nom d'utilisateur et du mot de passe de "connexion" traditionnels donnés aux utilisateurs.

Comme ces noms d'utilisateur et mots de passe sont censés être valides pendant des périodes prolongées, la prévention de la relecture est fournie sous forme de défi de condensé. Dans ce mécanisme, le client envoie initialement une requête, sans offrir d'identifications ni de vérifications d'intégrité. Le serveur rejette cette requête, fournissant à l'utilisateur un royaume (realm, utilisé pour guider l'utilisateur ou l'agent dans la sélection d'un nom d'utilisateur et d'un mot de passe) et un nonce. Le nonce fournit une protection contre la relecture. C'est un cookie, sélectionné par le serveur, et encodé de manière à indiquer une période de validité ou une identité de client à partir de laquelle il est valide. Le client réessaie la requête, cette fois en incluant son nom d'utilisateur et son royaume, et en répétant le nonce fourni par le serveur. Le client inclut également une intégrité de message, qui fournit un HMAC sur l'ensemble de la requête, y compris le nonce. Le serveur valide le nonce et vérifie l'intégrité du message. S'ils correspondent, la requête est authentifiée. Si le nonce n'est plus valide, il est considéré comme "périmé", et le serveur rejette la requête, fournissant un nouveau nonce.

Dans les requêtes ultérieures au même serveur, le client réutilise le nonce, le nom d'utilisateur, le royaume et le mot de passe qu'il a utilisés précédemment. De cette façon, les requêtes ultérieures ne sont pas rejetées jusqu'à ce que le serveur invalide le nonce, auquel cas le rejet fournit au client un nouveau nonce.

Notez que le mécanisme d'identification à long terme ne peut pas être utilisé pour protéger les indications, car les indications ne peuvent pas être challengées. Les utilisations utilisant des indications doivent soit utiliser le mécanisme d'identification à court terme, soit omettre l'authentification et l'intégrité des messages pour elles.

Étant donné que le mécanisme d'identification à long terme est susceptible aux attaques par dictionnaire hors ligne, les déploiements devraient (SHOULD) utiliser des mots de passe difficiles à deviner. Dans les cas où l'identification n'est pas saisie par un utilisateur mais est plutôt placée sur un appareil client pendant le provisionnement de l'appareil, le mot de passe devrait (SHOULD) avoir au moins 128 bits de hasard. Dans les cas où l'identification est saisie par un utilisateur, ils devraient (SHOULD) suivre les meilleures pratiques actuelles concernant la structure des mots de passe.

10.2.1. Forming a Request (Formation d'une requête)

Il existe deux cas lors de la formation d'une requête. Dans le premier cas, il s'agit de la première requête du client au serveur (identifié par son adresse IP et son port). Dans le deuxième cas, le client soumet une requête ultérieure suite à l'achèvement réussi d'une transaction requête/réponse antérieure. La formation de requêtes en conséquence d'une réponse d'erreur 401 ou 438 est couverte dans la Section 10.2.3 et n'est pas considérée comme une "requête ultérieure", et n'utilise donc pas les règles décrites dans la Section 10.2.1.2.

10.2.1.1. First Request (Première requête)

Si le client n'a pas terminé une transaction requête/réponse réussie avec le serveur (identifié par le nom d'hôte, si les procédures DNS de la Section 9 sont utilisées, ou par l'adresse IP sinon), il devrait (SHOULD) omettre les attributs USERNAME, MESSAGE-INTEGRITY, REALM et NONCE. En d'autres termes, la toute première requête est envoyée comme s'il n'y avait pas d'authentification ou d'intégrité de message appliquée.

10.2.1.2. Subsequent Requests (Requêtes ultérieures)

Une fois qu'une transaction requête/réponse s'est terminée avec succès, le serveur aura fourni au client un royaume et un nonce, et le client aura sélectionné un nom d'utilisateur et un mot de passe avec lesquels il s'est authentifié. Le client devrait (SHOULD) mettre en cache le nom d'utilisateur, le mot de passe, le royaume et le nonce pour les communications ultérieures avec le serveur. Lorsque le client envoie une requête ultérieure, il devrait (SHOULD) inclure les attributs USERNAME, REALM et NONCE avec ces valeurs mises en cache. Il devrait (SHOULD) inclure l'attribut MESSAGE-INTEGRITY, calculé comme décrit dans la Section 15.4 en utilisant le mot de passe mis en cache.

10.2.2. Receiving a Request (Réception d'une requête)

Après que le serveur a effectué le traitement de base d'une requête, il effectue les vérifications listées ci-dessous dans l'ordre spécifié :

• Si le message ne contient pas d'attribut MESSAGE-INTEGRITY, le serveur doit (MUST) générer une réponse d'erreur avec un code d'erreur de 401 (Unauthorized). Cette réponse doit (MUST) inclure une valeur REALM. Il est recommandé (RECOMMENDED) que la valeur REALM soit le nom de domaine du fournisseur du serveur STUN. La réponse doit (MUST) inclure un NONCE, sélectionné par le serveur. La réponse ne devrait pas (SHOULD NOT) inclure un attribut USERNAME ou MESSAGE-INTEGRITY.

• Si le message contient un attribut MESSAGE-INTEGRITY, mais manque l'attribut USERNAME, REALM ou NONCE, le serveur doit (MUST) générer une réponse d'erreur avec un code d'erreur de 400 (Bad Request). Cette réponse ne devrait pas (SHOULD NOT) inclure un attribut USERNAME, NONCE, REALM ou MESSAGE-INTEGRITY.

• Si le NONCE n'est plus valide, le serveur doit (MUST) générer une réponse d'erreur avec un code d'erreur de 438 (Stale Nonce). Cette réponse doit (MUST) inclure des attributs NONCE et REALM et ne devrait pas (SHOULD NOT) inclure l'attribut USERNAME ou MESSAGE-INTEGRITY. Les serveurs peuvent invalider les nonces afin de fournir une sécurité supplémentaire. Voir la Section 4.3 de [RFC2617] pour des conseils.

• Si le nom d'utilisateur dans l'attribut USERNAME n'est pas valide, le serveur doit (MUST) générer une réponse d'erreur avec un code d'erreur de 401 (Unauthorized). Cette réponse doit (MUST) inclure une valeur REALM. Il est recommandé (RECOMMENDED) que la valeur REALM soit le nom de domaine du fournisseur du serveur STUN. La réponse doit (MUST) inclure un NONCE, sélectionné par le serveur. La réponse ne devrait pas (SHOULD NOT) inclure un attribut USERNAME ou MESSAGE-INTEGRITY.

• En utilisant le mot de passe associé au nom d'utilisateur dans l'attribut USERNAME, calculer la valeur pour l'intégrité du message comme décrit dans la Section 15.4. Si la valeur résultante ne correspond pas au contenu de l'attribut MESSAGE-INTEGRITY, le serveur doit (MUST) rejeter la requête avec une réponse d'erreur. Cette réponse doit (MUST) utiliser un code d'erreur de 401 (Unauthorized). Elle doit (MUST) inclure des attributs REALM et NONCE et ne devrait pas (SHOULD NOT) inclure l'attribut USERNAME ou MESSAGE-INTEGRITY.

Si ces vérifications réussissent, le serveur continue à traiter la requête. Toute réponse générée par le serveur (à l'exception des cas ci-dessus) doit (MUST) inclure l'attribut MESSAGE-INTEGRITY, calculé en utilisant le nom d'utilisateur et le mot de passe utilisés pour authentifier la requête. Les attributs REALM, NONCE et USERNAME ne devraient pas (SHOULD NOT) être inclus.

10.2.3. Receiving a Response (Réception d'une réponse)

Si la réponse est une réponse d'erreur avec un code d'erreur de 401 (Unauthorized), le client devrait (SHOULD) réessayer la requête avec une nouvelle transaction. Cette requête doit (MUST) contenir un USERNAME, déterminé par le client comme le nom d'utilisateur approprié pour le REALM de la réponse d'erreur. La requête doit (MUST) contenir le REALM, copié de la réponse d'erreur. La requête doit (MUST) contenir le NONCE, copié de la réponse d'erreur. La requête doit (MUST) contenir l'attribut MESSAGE-INTEGRITY, calculé en utilisant le mot de passe associé au nom d'utilisateur dans l'attribut USERNAME. Le client ne doit pas (MUST NOT) effectuer cette nouvelle tentative s'il ne modifie pas le USERNAME ou le REALM ou son mot de passe associé par rapport à la tentative précédente.

Si la réponse est une réponse d'erreur avec un code d'erreur de 438 (Stale Nonce), le client doit (MUST) réessayer la requête, en utilisant le nouveau NONCE fourni dans la réponse 438 (Stale Nonce). Cette nouvelle tentative doit (MUST) également inclure le USERNAME, le REALM et le MESSAGE-INTEGRITY.

Le client recherche l'attribut MESSAGE-INTEGRITY dans la réponse (succès ou échec). S'il est présent, le client calcule l'intégrité du message sur la réponse comme défini dans la Section 15.4, en utilisant le même mot de passe qu'il a utilisé pour la requête. Si la valeur résultante correspond au contenu de l'attribut MESSAGE-INTEGRITY, la réponse est considérée comme authentifiée. Si la valeur ne correspond pas, ou si MESSAGE-INTEGRITY n'était pas présent, la réponse doit (MUST) être abandonnée, comme si elle n'avait jamais été reçue. Cela signifie que les retransmissions, le cas échéant, continueront.