5.2. Types Kerberos de base

Cette section définit plusieurs types de base qui peuvent être utilisés tout au long du protocole Kerberos.

5.2.1. KerberosString

La spécification originale du protocole Kerberos dans la RFC 1510 utilisait GeneralString dans plusieurs endroits pour représenter des données de chaîne lisibles par l'homme. Les implémentations historiques de Kerberos n'ont pas pu exploiter toutes les fonctionnalités de GeneralString. Ce type ASN.1 nécessite l'utilisation de séquences d'échappement de désignation et d'invocation spécifiées dans ISO-2022/ECMA-35 pour changer de jeu de caractères, le jeu de caractères par défaut désigné comme G0 étant la version de référence internationale (IRV) ISO-646/ECMA-6 (également connue sous le nom d'US-ASCII), ce qui fonctionne dans la plupart des cas.

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). DER interdit de désigner un jeu de caractères comme autre chose que les ensembles G0 et C0. Malheureusement, cela semble avoir pour effet secondaire d'interdire l'utilisation des jeux de caractères ISO-8859 (ISO Latin) ou de tout autre jeu de caractères utilisant 96 caractères, car ISO-2022/ECMA-35 interdit de les désigner comme éléments de code G0. La communauté des normes ASN.1 enquête sur cet effet secondaire.

En pratique, de nombreuses implémentations traitent GeneralString comme une chaîne de 8 bits de n'importe quel jeu de caractères par défaut de l'implémentation, sans tenir compte de l'utilisation correcte des séquences d'échappement de spécification de jeu de caractères. Le jeu de caractères par défaut est généralement déterminé par les paramètres régionaux dépendant du système d'exploitation de l'utilisateur actuel. Au moins une implémentation majeure place des caractères Unicode encodés en UTF-8 non échappés dans GeneralString. Ce non-respect de la spécification GeneralString entraîne des problèmes d'interopérabilité lorsque les clients Kerberos, les services et les KDC utilisent des encodages de caractères conflictuels.

Cette situation malheureuse est due à une documentation inadéquate des restrictions sur le type ASN.1 GeneralString dans les spécifications Kerberos précédentes.

Le nouveau type (post-RFC 1510) KerberosString est défini comme suit, il s'agit d'un GeneralString contraint pour contenir uniquement les caractères de 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 doivent pas être utilisés dans les noms principaux ou les noms de royaume.

Pour la compatibilité, les implémentations peuvent choisir d'accepter des valeurs GeneralString contenant des caractères autres que ceux autorisés dans IA5String, mais elles doivent être conscientes que les codes de spécification de jeu de caractères peuvent ne pas être présents et que l'encodage devrait être traité comme spécifique aux paramètres régionaux dans presque tous les aspects. Les implémentations peuvent également choisir d'émettre des valeurs GeneralString au-delà de ce qui est autorisé dans IA5String, mais elles doivent être conscientes que cela est extrêmement risqué du point de vue de l'interopérabilité.

Certaines implémentations existantes utilisent GeneralString pour encoder des caractères non échappés spécifiques aux paramètres régionaux. Cela viole la norme ASN.1. La plupart de ces implémentations encodent US-ASCII dans la moitié gauche, donc tant que l'implémentation ne transmet que US-ASCII, elle ne viole pas la norme ASN.1 à cet égard. Une fois qu'une telle implémentation encode des caractères non échappés spécifiques aux paramètres régionaux avec le bit de poids fort défini, elle viole la norme ASN.1.

D'autres implémentations sont connues pour utiliser GeneralString pour contenir un encodage UTF-8. Cela viole également la norme ASN.1, car UTF-8 est un encodage différent, pas un ensemble "G" de 94 ou 96 caractères défini par ISO 2022. On pense que ces implémentations n'utilisent même pas les séquences d'échappement ISO 2022 pour changer l'encodage de caractères. Même si l'implémentation annonçait un changement d'encodage en utilisant cette séquence d'échappement, la norme ASN.1 interdit l'utilisation de toute séquence d'échappement autre que celles utilisées pour désigner/invoquer les ensembles "G" ou "C" autorisés par GeneralString.

Les futures révisions de ce protocole permettront presque certainement des représentations de noms principaux plus interopérables, incluant peut-être UTF8String.

Notez que l'application de nouvelles contraintes à un type précédemment non contraint constitue la création d'un nouveau type ASN.1. Dans ce cas particulier, le changement n'entraînera pas de changement dans l'encodage sous DER.

5.2.2. Realm et PrincipalName

Realm           ::= KerberosString

PrincipalName   ::= SEQUENCE {
        name-type       [0] Int32,
        name-string     [1] SEQUENCE OF KerberosString
}

Les noms de royaume Kerberos sont encodés comme KerberosString. Un royaume ne doit pas contenir de caractère de code 0 (US-ASCII NUL). La plupart des royaumes sont généralement composés de plusieurs composants séparés par un point (.), dans le style des noms de domaine Internet, ou séparés par une barre oblique (/), dans le style des noms X.500. La section 6.1 spécifie les formes acceptables de noms de royaume. PrincipalName est une séquence typée de composants composée des sous-champs suivants:

name-type
Ce champ spécifie le type de nom qui suit. Les valeurs prédéfinies pour ce champ sont spécifiées dans la section 6.2. name-type doit être traité comme un indice. En ignorant le type de nom, aucun deux noms ne peuvent être identiques (c'est-à-dire qu'au moins un composant ou royaume doit être différent).

name-string
Ce champ encode la séquence de composants formant le nom, chaque composant encodé comme KerberosString. PrincipalName et Realm forment ensemble un identifiant principal. La plupart des PrincipalName n'ont que quelques composants (généralement un ou deux).

5.2.3. KerberosTime

KerberosTime    ::= GeneralizedTime -- sans fractions de seconde

Les horodatages utilisés dans Kerberos sont encodés comme GeneralizedTime. Les valeurs KerberosTime ne doivent contenir aucune fraction de seconde. Conformément aux exigences de DER, elles ne doivent également contenir aucun séparateur et doivent spécifier le fuseau horaire UTC (Z). Exemple: le seul format valide pour l'heure UTC de 6 minutes et 27 secondes après 21 heures le 6 novembre 1985 est 19851106210627Z.

5.2.4. Types entiers contraints

Certains membres entiers de types doivent être contraints à des valeurs représentables en 32 bits pour être compatibles avec des limites d'implémentation raisonnables.

Int32           ::= INTEGER (-2147483648..2147483647)
                    -- valeurs signées représentables en 32 bits

UInt32          ::= INTEGER (0..4294967295)
                    -- valeurs non signées de 32 bits

Microseconds    ::= INTEGER (0..999999)
                    -- microsecondes

Bien que cela entraîne un changement de type abstrait par rapport à la version RFC 1510, l'encodage dans DER devrait rester inchangé. Les implémentations historiques sont généralement limitées aux valeurs entières de 32 bits, et les nombres attribués devraient se situer dans l'espace des valeurs entières représentables en 32 bits pour favoriser l'interopérabilité.

Plusieurs champs entiers dans les messages sont contraints à des valeurs fixes.

pvno
Également appelé TKT-VNO ou AUTHENTICATOR-VNO, ce champ récurrent est toujours l'entier constant 5. Il n'y a pas de moyen simple de transformer ce champ en un numéro de version de protocole utile, donc sa valeur est fixe.

msg-type
Ce champ entier est généralement le même que le numéro de balise d'application contenant le type de message.

5.2.5. HostAddress et HostAddresses

HostAddress     ::= SEQUENCE  {
        addr-type       [0] Int32,
        address         [1] OCTET STRING
}

-- NOTE: HostAddresses est toujours utilisé comme champ OPTIONAL et
-- ne devrait pas être vide.
HostAddresses   -- NOTE: subtilement différent de rfc1510,
                -- mais a un mappage de valeur et encode de la même manière
        ::= SEQUENCE OF HostAddress

L'adresse hôte est encodée avec deux champs:

addr-type
Ce champ spécifie le type d'adresse qui suit. Les valeurs prédéfinies pour ce champ sont spécifiées dans la section 7.5.3.

address
Ce champ encode une seule adresse du type addr-type.

5.2.6. AuthorizationData

-- NOTE: AuthorizationData est toujours utilisé comme champ OPTIONAL et
-- ne devrait pas être vide.
AuthorizationData       ::= SEQUENCE OF SEQUENCE {
        ad-type         [0] Int32,
        ad-data         [1] OCTET STRING
}

ad-data
Ce champ contient les données d'autorisation à interpréter selon la valeur du champ ad-type correspondant.

ad-type
Ce champ spécifie le format du sous-champ ad-data. Toutes les valeurs négatives sont réservées pour une utilisation locale. Les valeurs non négatives sont réservées pour une utilisation enregistrée.

Chaque séquence de type et de données est appelée élément d'autorisation. Les éléments peuvent être spécifiques à l'application; cependant, il existe un ensemble d'éléments récursifs communs que toutes les implémentations devraient comprendre. Ces éléments contiennent d'autres éléments incorporés, l'interprétation de l'élément encapsulant déterminant quels éléments incorporés doivent être interprétés et lesquels peuvent être ignorés.

Ces éléments de données d'autorisation communs sont définis de manière récursive, ce qui signifie que l'ad-data de ces types contiendra lui-même une séquence de données d'autorisation, dont l'interprétation est affectée par l'élément encapsulant. Selon la signification de l'élément encapsulant, les éléments encapsulés peuvent être ignorés, peuvent être interprétés comme ayant été émis directement par le KDC, ou peuvent être stockés dans une partie de texte en clair séparée du ticket. Les types d'éléments encapsulants sont spécifiés dans le cadre de la spécification Kerberos car le comportement basé sur ces valeurs devrait être compris entre les implémentations, tandis que d'autres éléments ne doivent être compris que par les applications qu'ils affectent.

Si des éléments de données d'autorisation sont présents dans un ticket ou un authentificateur, ils sont considérés comme critiques. Si un serveur reçoit un type d'élément de données d'autorisation inconnu dans un AP-REQ ou dans le ticket contenu dans l'AP-REQ, alors, à moins qu'il ne soit encapsulé dans un élément de données d'autorisation connu pour modifier la criticité des éléments qu'il contient, l'authentification doit échouer. Les données d'autorisation sont destinées à restreindre l'utilisation du ticket. Si un service ne peut pas déterminer si la restriction s'applique à ce service, cela peut entraîner une faiblesse de sécurité si le ticket peut être utilisé pour ce service. Les éléments d'autorisation optionnels peuvent être encapsulés dans un élément AD-IF-RELEVANT.

Dans les définitions suivantes, la valeur ad-type de l'élément sera spécifiée comme la partie la moins significative du numéro de sous-section, et la valeur d'ad-data sera comme indiqué dans la structure ASN.1 qui suit l'en-tête de sous-section.

Contenu d'ad-data	ad-type
Encodage DER d'AD-IF-RELEVANT	1
Encodage DER d'AD-KDCIssued	4
Encodage DER d'AD-AND-OR	5
Encodage DER d'AD-MANDATORY-FOR-KDC	8

5.2.6.1. IF-RELEVANT

AD-IF-RELEVANT          ::= AuthorizationData

Les éléments AD encapsulés dans un élément if-relevant ne sont destinés qu'à être interprétés par les serveurs d'application qui comprennent le ad-type spécifique des éléments incorporés. Les serveurs d'application qui ne comprennent pas le type d'éléments incorporés dans l'élément if-relevant peuvent ignorer les éléments non interprétables. Cet élément facilite l'interopérabilité entre les implémentations qui peuvent avoir des extensions d'autorisation locales. Le ad-type d'AD-IF-RELEVANT est (1).

5.2.6.2. KDCIssued

AD-KDCIssued            ::= SEQUENCE {
        ad-checksum     [0] Checksum,
        i-realm         [1] Realm OPTIONAL,
        i-sname         [2] PrincipalName OPTIONAL,
        elements        [3] AuthorizationData
}

ad-checksum
Somme de contrôle cryptographique calculée sur l'encodage DER d'AuthorizationData dans le champ "elements" en utilisant la clé de session. Son checksumtype est le type de somme de contrôle obligatoire pour le type de chiffrement de la clé de session, sa valeur d'utilisation de clé est 19.

i-realm, i-sname
Le nom du principal émetteur, s'il est différent du nom du KDC lui-même. Ce champ sera utilisé lorsque le KDC peut vérifier l'authenticité des éléments signés par le principal émetteur, cela permet à ce KDC d'informer le serveur d'application de la validité de ces éléments.

elements
Séquence d'éléments de données d'autorisation émis par le KDC.

Le champ ad-data KDC-issued est destiné à fournir un moyen pour les informations d'identification du principal Kerberos d'incorporer des attributs de privilège et d'autres mécanismes d'autorisation positive dans leur propre sein, élargissant les privilèges du principal au-delà de ce qui pourrait être fait en utilisant des informations d'identification sans de tels éléments a-data.

Sans cet élément, il serait impossible de fournir la méthode ci-dessus, car la définition du champ authorization-data permet au détenteur du TGT d'ajouter arbitrairement des éléments lors de la demande de tickets de service, et les éléments peuvent également être ajoutés aux tickets délégués en incluant des éléments dans l'authentificateur.

Pour les éléments émis par le KDC, cela peut être évité car les éléments sont signés par le KDC en chiffrant une somme de contrôle contenant en utilisant la clé du serveur (la même clé utilisée pour chiffrer le ticket ou une clé dérivée de cette clé). Si cette "signature" n'est pas présente, le serveur d'application doit ignorer les éléments encapsulés dans l'élément émis par le KDC. De plus, les éléments encapsulés dans cet élément d'un TGT peuvent être interprétés par le KDC et utilisés comme base pour inclure de nouveaux éléments signés dans les tickets dérivés selon la politique, mais ils ne seront pas copiés directement dans les tickets dérivés. S'ils étaient copiés directement dans les tickets dérivés par un KDC qui ne connaît pas cet élément, la signature ne serait pas correcte pour les éléments de ticket d'application, et le serveur d'application ignorera ce champ.

Les applications, serveurs d'application et KDC qui n'implémentent pas cet élément peuvent ignorer en toute sécurité cet élément et ses éléments encapsulés.

Le ad-type d'AD-KDC-ISSUED est (4).

5.2.6.3. AND-OR

AD-AND-OR               ::= SEQUENCE {
        condition-count [0] Int32,
        elements        [1] AuthorizationData
}

Lorsque des éléments AD restrictifs sont encapsulés dans un élément and-or, l'élément and-or est considéré comme satisfait si et seulement si au moins le nombre d'éléments encapsulés spécifié dans condition-count est satisfait. Ainsi, cet élément peut être utilisé pour implémenter une opération "or" en définissant le champ condition-count à 1, et une opération "and" peut être spécifiée en définissant le nombre de conditions au nombre d'éléments incorporés. Les serveurs d'application qui n'implémentent pas cet élément doivent rejeter les tickets contenant des éléments de données d'autorisation de ce type.

Le ad-type d'AD-AND-OR est (5).

5.2.6.4. MANDATORY-FOR-KDC

AD-MANDATORY-FOR-KDC    ::= AuthorizationData

Les éléments AD encapsulés dans un élément mandatory-for-kdc seront interprétés par le KDC. Les KDC qui ne comprennent pas le type d'éléments incorporés dans l'élément mandatory-for-kdc doivent rejeter la demande.

Le ad-type d'AD-MANDATORY-FOR-KDC est (8).

5.2.7. PA-DATA

Historiquement, PA-DATA était appelé "données de pré-authentification", ce qui signifie qu'ils étaient utilisés pour améliorer l'authentification initiale avec le KDC. Depuis lors, ils ont également été utilisés comme trous typés pour étendre l'échange de protocole avec le KDC.

PA-DATA         ::= SEQUENCE {
        -- NOTE: la première balise est [1], pas [0]
        padata-type     [1] Int32,
        padata-value    [2] OCTET STRING -- peut être un AP-REQ encodé
}

padata-type
Indique comment interpréter l'élément padata-value. Les valeurs négatives de padata-type sont réservées pour une utilisation non enregistrée; les valeurs non négatives sont utilisées pour l'interprétation enregistrée des types d'éléments.

padata-value
Contient généralement l'encodage DER d'un autre type; le champ padata-type identifie le type encodé ici.

padata-type	Nom	Contenu de padata-value
1	pa-tgs-req	Encodage DER d'AP-REQ
2	pa-enc-timestamp	Encodage DER de PA-ENC-TIMESTAMP
3	pa-pw-salt	sel (non encodé ASN.1)
11	pa-etype-info	Encodage DER d'ETYPE-INFO
19	pa-etype-info2	Encodage DER d'ETYPE-INFO2

Ce champ peut également contenir des informations nécessaires pour certaines extensions du protocole Kerberos. Par exemple, il peut être utilisé pour vérifier initialement l'identité du client avant de retourner toute réponse.

Le champ padata peut également contenir des informations qui aident le KDC ou le client à sélectionner la clé nécessaire pour générer ou déchiffrer la réponse. Cette forme de padata est utile pour prendre en charge l'utilisation de certaines cartes à jeton avec Kerberos. Les détails de ces extensions sont spécifiés dans des documents séparés. Pour d'autres utilisations de ce champ, voir [Pat92].

5.2.8. KerberosFlags

Pour plusieurs types de messages, un type de chaîne de bits contrainte spécifique KerberosFlags est utilisé.

KerberosFlags   ::= BIT STRING (SIZE (32..MAX))
                    -- le nombre minimum de bits doit être envoyé,
                    -- mais pas moins de 32

5.2.9. Types liés au système de chiffrement

De nombreux messages du protocole Kerberos contiennent EncryptedData comme conteneur pour des données chiffrées arbitraires, qui sont généralement l'encodage chiffré d'un autre type de données. Les champs dans EncryptedData aident le destinataire à sélectionner la clé pour déchiffrer les données incluses.

EncryptedData   ::= SEQUENCE {
        etype   [0] Int32 -- EncryptionType --,
        kvno    [1] UInt32 OPTIONAL,
        cipher  [2] OCTET STRING -- texte chiffré
}

etype
Ce champ identifie quel algorithme de chiffrement est utilisé pour chiffrer cipher.

kvno
Ce champ contient le numéro de version de la clé utilisée pour chiffrer les données. Il n'est présent que dans les messages chiffrés avec des clés à long terme (par exemple, la clé d'un principal).

cipher
Ce champ contient le texte chiffré, encodé comme OCTET STRING.

Le type EncryptionKey est la méthode de transmission d'une clé de chiffrement utilisée pour le chiffrement.

EncryptionKey   ::= SEQUENCE {
        keytype         [0] Int32 -- en fait le type de chiffrement --,
        keyvalue        [1] OCTET STRING
}

keytype
Ce champ spécifie le type de chiffrement de la clé de chiffrement dans le champ keyvalue qui suit.

keyvalue
Ce champ contient la clé elle-même, encodée comme une chaîne d'octets.

Les messages contenant des données en texte clair à authentifier utiliseront généralement un membre de type Checksum pour l'authentification.

Checksum        ::= SEQUENCE {
        cksumtype       [0] Int32,
        checksum        [1] OCTET STRING
}

cksumtype
Ce champ indique l'algorithme utilisé pour générer la somme de contrôle accompagnante.

checksum
Ce champ contient la somme de contrôle elle-même, encodée comme une chaîne d'octets.

Pour un bref résumé de l'utilisation du chiffrement et des sommes de contrôle dans Kerberos, voir la section 4.