Aller au contenu principal

5. Message Specifications (Spécifications des Messages)

5. Spécifications des Messages​

L'ASN.1 collecté ici devrait être identique au contenu de l'Annexe A. En cas de conflit, le contenu de l'Annexe A prévaudra.

Le protocole Kerberos est défini ici en termes de Notation de Syntaxe Abstraite Un (ASN.1) [X680], qui fournit une syntaxe pour spécifier à la fois la disposition abstraite des messages de protocole ainsi que leurs codages. Les implémenteurs n'utilisant pas un compilateur ASN.1 existant ou une bibliothèque de support sont avertis de comprendre la spécification ASN.1 réelle de manière approfondie afin d'assurer un comportement d'implémentation correct. Il y a plus de complexité dans la notation que ce qui est immédiatement évident, et certains tutoriels et guides sur ASN.1 sont trompeurs ou erronés.

Notez qu'à plusieurs endroits, des modifications aux types abstraits du RFC 1510 ont été apportées. Cela est en partie pour répondre aux hypothèses répandues que divers implémenteurs ont faites, dans certains cas résultant en des violations involontaires de la norme ASN.1. Celles-ci sont clairement signalées là où elles se produisent. Les différences entre les types abstraits dans le RFC 1510 et les types abstraits dans ce document peuvent causer l'émission de codages incompatibles lorsque certaines règles de codage, par exemple, les Règles de Codage Compact (PER, Packed Encoding Rules), sont utilisées. Cette incompatibilité théorique ne devrait pas être pertinente pour Kerberos, car Kerberos spécifie explicitement l'utilisation des Règles de Codage Distingué (DER, Distinguished Encoding Rules). Cela pourrait être un problème pour les protocoles cherchant à utiliser les types Kerberos avec d'autres règles de codage. (Cette pratique n'est pas recommandée.) À de très rares exceptions près (notamment les utilisations de BIT STRING), les codages résultant de l'utilisation du DER restent identiques entre les types définis dans le RFC 1510 et les types définis dans ce document.

Les définitions de types dans cette section supposent une définition de module ASN.1 de la forme suivante:

KerberosV5Spec2 {
        iso(1) identified-organization(3) dod(6) internet(1)
        security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN

-- reste des définitions ici

END

Cela spécifie que le contexte de marquage (tagging) pour le module sera explicite et non automatique.

Notez que dans certaines autres publications (telles que [RFC1510] et [RFC1964]), la partie "dod" de l'identifiant d'objet est spécifiée de manière erronée comme ayant la valeur "5". Dans le cas du RFC 1964, l'utilisation de la valeur OID "correcte" entraînerait un changement dans le protocole de transmission; par conséquent, elle reste inchangée pour le moment.

Notez qu'ailleurs dans ce document, la nomenclature pour divers types de messages est incohérente, mais elle suit largement les conventions du langage C, y compris l'utilisation de caractères de soulignement (_) et l'orthographe en majuscules des noms destinés à être des constantes numériques. De plus, à certains endroits, les identifiants (en particulier ceux faisant référence à des constantes) sont écrits en majuscules afin de les distinguer du texte explicatif environnant.

La notation ASN.1 ne permet pas les traits de soulignement dans les identifiants, donc dans les définitions ASN.1 réelles, les traits de soulignement sont remplacés par des traits d'union (-). De plus, les noms de membres de structure et les valeurs définies dans ASN.1 DOIVENT commencer par une lettre minuscule, tandis que les noms de types DOIVENT commencer par une lettre majuscule.

5.1. Notes de Compatibilité Spécifiques sur ASN.1​

À des fins de compatibilité, les implémenteurs devraient tenir compte des notes spécifiques suivantes concernant l'utilisation d'ASN.1 dans Kerberos. Ces notes ne décrivent pas de déviations de l'utilisation standard d'ASN.1. Le but de ces notes est plutôt de décrire certaines bizarreries historiques et la non-conformité de diverses implémentations, ainsi que des ambiguïtés historiques qui, bien qu'elles soient de l'ASN.1 valide, peuvent conduire à la confusion lors de l'implémentation.

5.1.1. Règles de Codage Distingué ASN.1​

Le codage des messages du protocole Kerberos DOIT obéir aux Règles de Codage Distingué (DER) d'ASN.1 comme décrit dans [X690]. Certaines implémentations (considérées principalement comme étant celles dérivées de DCE 1.1 et antérieures) sont connues pour utiliser les Règles de Codage de Base (BER, Basic Encoding Rules) plus générales; en particulier, ces implémentations envoient des codages indéfinis de longueurs. Les implémentations PEUVENT accepter de tels codages dans l'intérêt de la compatibilité ascendante, bien que les implémenteurs soient avertis que le décodage du BER entièrement général est semé d'embûches.

5.1.2. Champs Entiers Optionnels​

Certaines implémentations ne distinguent pas en interne entre une valeur entière optionnelle omise et une valeur transmise de zéro. Les endroits du protocole où cela est pertinent incluent divers champs de microsecondes, nonces et numéros de séquence. Les implémentations DEVRAIENT traiter les valeurs entières optionnelles omises comme ayant été transmises avec une valeur de zéro, si l'application s'y attend.

5.1.3. Types SEQUENCE OF Vides​

Il existe des endroits dans le protocole où un message contient un type SEQUENCE OF comme membre optionnel. Cela peut résulter en un codage qui contient un codage SEQUENCE OF vide. Le protocole Kerberos ne distingue pas sémantiquement entre un type optionnel SEQUENCE OF absent et un type optionnel SEQUENCE OF présent mais vide. Les implémentations NE DEVRAIENT PAS envoyer de codages SEQUENCE OF vides qui sont marqués OPTIONAL, mais DEVRAIENT les accepter comme étant équivalents à un type OPTIONAL omis. Dans la syntaxe ASN.1 décrivant les messages Kerberos, les instances de ces types optionnels SEQUENCE OF problématiques sont indiquées par un commentaire.

5.1.4. Numéros de Tag Non Reconnus​

Les révisions futures de ce protocole peuvent inclure de nouveaux types de messages avec différents numéros de tag de classe APPLICATION. Ces révisions devraient protéger les anciennes implémentations en envoyant uniquement les types de messages aux parties qui sont connues pour les comprendre; par exemple, au moyen d'un bit d'indicateur défini par le récepteur dans une demande précédente. Dans l'intérêt d'une gestion robuste des erreurs, les implémentations DEVRAIENT gérer gracieusement la réception d'un message avec un tag non reconnu de toute façon, et renvoyer un message d'erreur, si approprié.

En particulier, les KDC DEVRAIENT renvoyer KRB_AP_ERR_MSG_TYPE si le tag incorrect est envoyé sur un transport TCP. Les KDC NE DEVRAIENT PAS répondre aux messages reçus avec un tag inconnu sur un transport UDP afin d'éviter les attaques par déni de service. Pour les applications non-KDC, l'implémentation Kerberos indique généralement une erreur à l'application qui prend les mesures appropriées en fonction du protocole d'application.

5.1.5. Numéros de Tag Supérieurs à 30​

Une implémentation naïve d'un décodeur ASN.1 DER peut rencontrer des problèmes avec les numéros de tag ASN.1 supérieurs à 30, en raison du fait que de tels numéros de tag sont codés en utilisant plus d'un octet. Les révisions futures de ce protocole peuvent utiliser des numéros de tag supérieurs à 30, et les implémentations DEVRAIENT être préparées à renvoyer gracieusement une erreur, si approprié, lorsqu'elles ne reconnaissent pas le tag.

5.2. Types Kerberos de Base​

Cette section définit un certain nombre de types de base qui sont potentiellement utilisés dans plusieurs messages du protocole Kerberos.

5.2.1. KerberosString​

La spécification originale du protocole Kerberos dans le RFC 1510 utilise GeneralString à de nombreux endroits pour les données de chaîne lisibles par l'homme. Les implémentations historiques de Kerberos ne peuvent pas utiliser la pleine puissance de GeneralString. Ce type ASN.1 nécessite l'utilisation de séquences d'échappement de désignation et d'invocation comme spécifié dans ISO-2022/ECMA-35 [ISO-2022/ECMA-35] pour changer de jeux de caractères, et le jeu de caractères par défaut qui est désigné comme G0 est la version de référence internationale (IRV) ISO-646/ECMA-6 [ISO-646/ECMA-6] (alias ASCII américain), qui fonctionne principalement.

ISO-2022/ECMA-35 définit quatre éléments de code de jeu de caractères (G0..G3) et deux éléments de code de fonction de contrôle (C0..C1). Le DER interdit la désignation de jeux de caractères autres que les ensembles G0 et C0. Malheureusement, cela semble avoir l'effet secondaire d'interdire l'utilisation des jeux de caractères ISO-8859 (ISO Latin) [ISO-8859] ou de tout autre jeu de caractères qui utilise un jeu de caractères à 96 caractères, car ISO-2022/ECMA-35 interdit de les désigner comme l'élément de code G0. Cet effet secondaire est en cours d'investigation dans la communauté des normes ASN.1.

En pratique, de nombreuses implémentations traitent les GeneralStrings comme s'il s'agissait de chaînes 8 bits du jeu de caractères par défaut de l'implémentation, sans égard à l'utilisation correcte des séquences d'échappement de désignation de jeu de caractères. Le jeu de caractères par défaut est souvent déterminé par la locale dépendante du système d'exploitation de l'utilisateur actuel. Au moins une implémentation majeure place des caractères Unicode codés UTF-8 non échappés dans le GeneralString. Ce manquement au respect des spécifications GeneralString entraîne des problèmes d'interopérabilité lorsque des codages de caractères conflictuels sont utilisés par les clients Kerberos, les services et le KDC.

Cette situation malheureuse est le résultat d'une documentation incorrecte des restrictions du type ASN.1 GeneralString dans les spécifications Kerberos antérieures.

Le nouveau type (post-RFC 1510) KerberosString, défini ci-dessous, est un GeneralString qui est contraint de ne contenir que des caractères dans IA5String.

KerberosString  ::= GeneralString (IA5String)

En général, les caractères de contrôle US-ASCII ne devraient pas être utilisés dans KerberosString. Les caractères de contrôle NE DEVRAIENT PAS être utilisés dans les noms de principaux ou les noms de domaines.

Pour la compatibilité, les implémentations PEUVENT choisir d'accepter des valeurs GeneralString qui contiennent des caractères autres que ceux permis par IA5String, mais elles devraient être conscientes que les codes de désignation de jeu de caractères seront probablement absents, et que le codage devrait probablement être traité comme spécifique à la locale de presque toutes les manières. Les implémentations PEUVENT également choisir d'émettre des valeurs GeneralString qui vont au-delà de celles permises par IA5String, mais elles devraient être conscientes que cela est extraordinairement risqué du point de vue de l'interopérabilité.

Certaines implémentations existantes utilisent GeneralString pour coder des caractères spécifiques à la locale non échappés. Ceci est une violation de la norme ASN.1 standard et peut causer des problèmes d'interopérabilité sérieux.

📊 Rapport de Progression de Traduction​

✅ Chapitres Complétés​

Chapitre 1: Introduction (100%)

  • 1.1 Le Protocole Kerberos
  • 1.2 Opération Inter-Domaines
  • 1.3 Choisir un Principal
  • 1.4 Autorisation
  • 1.5 Étendre Kerberos
  • 1.6 Hypothèses Environnementales
  • 1.7 Glossaire des Termes

Chapitre 2: Indicateurs de Ticket (100%)

  • 2.1-2.9 Tous les sous-chapitres

Chapitre 3: Échanges de Messages (100%)

  • 3.1 Échange AS
  • 3.2 Échange Client/Serveur
  • 3.3 Échange TGS
  • 3.4 Échange KRB_SAFE
  • 3.5 Échange KRB_PRIV
  • 3.6 Échange KRB_CRED
  • 3.7 Authentification Utilisateur-à-Utilisateur

Chapitre 4: Chiffrement et Sommes de Contrôle (100%)

Chapitre 5: En cours

  • 5.1 Notes de Compatibilité ASN.1 (complété)
  • 5.2.1 KerberosString (complété)
  • 5.2.2-5.10 À compléter

📍 Statut Actuel​

Fichiers créés: 17 fichiers .md Progression globale: ~25% du RFC 4120 complet

Note: RFC 4120 est un document technique très long (plus de 7700 lignes). Les sections 5-11 contiennent des spécifications ASN.1 détaillées, des définitions de constantes et des considérations de sécurité qui nécessiteront plusieurs sessions supplémentaires pour compléter la traduction à 100%.

Dernière mise à jour le