1.5. Étendre Kerberos sans rompre l'interopérabilité

Vue d'ensemble

À mesure que la base déployée d'implémentations Kerberos s'élargit, l'extension de Kerberos prend plus d'importance. Cette section donne des lignes directrices pour permettre aux implémentations futures de conserver l'interopérabilité.

Mécanisme d'extension

Kerberos prévoit un mécanisme général d'extensibilité du protocole :

• les messages de protocole contiennent des emplacements typés (typed holes)
• les sous-messages contiennent une chaîne d'octets avec un entier définissant l'interprétation
• les types entiers sont enregistrés centralement
• il peut servir aux extensions du fournisseur et aux normalisations de l'IETF

Définition : dans le présent document, « extension » désigne la définition d'un nouveau type à insérer dans un emplacement typé existant, et non l'ajout de nouveaux champs aux types ASN.1 (sauf indication contraire explicite).

1.5.1. Compatibilité avec RFC 1510

Limites

Les formats de messages Kerberos existants ne peuvent pas aisément être étendus en ajoutant des champs aux types ASN.1 :

• l'envoi de champs supplémentaires entraîne souvent l'abandon du message tout entier
• aucune indication d'erreur n'est fournie

Exigences à l'égard des implémentations

Toute implémentation nouvelle ou modifiée qui reçoit une extension de message inconnue :

• DEVRAIT : conserver l'encodage de l'extension
• DEVRAIT : ignorer sa présence
• NE DOIT PAS : refuser une demande uniquement parce qu'une extension est présente

Exception : données d'autorisation

Si un type d'élément de données d'autorisation inconnu est reçu par un serveur (autre que le service d'octroi de tickets) :

• soit dans un AP-REQ
• soit dans un ticket contenu dans un AP-REQ

alors l'authentification DOIT échouer.

Justification : les données d'autorisation restreignent l'utilisation du ticket. Si le service ne peut pas déterminer si une restriction s'applique, une faiblesse de sécurité peut en résulter.

Bonne pratique : les éléments d'autorisation facultatifs DEVRAIENT être placés dans un élément AD-IF-RELEVANT.

Comportement du service d'octroi de tickets

Le TGS (Ticket-Granting Service, service d'octroi de tickets) :

• DOIT ignorer mais propager vers les tickets dérivés tout type de données d'autorisation inconnu
• Exception : si les types de données sont embarqués dans l'élément MANDATORY-FOR-KDC, la demande sera rejetée

1.5.2. Envoi de messages extensibles

Principe directeur

Il faut veiller à ce que les anciennes implémentations puissent comprendre les messages qui leur sont envoyés, même si elles ne comprennent pas une extension utilisée.

Règle : tant que l'émetteur ne sait pas qu'une extension est prise en charge, l'extension ne peut pas modifier la sémantique du message central ni celle des extensions déjà définies.

Exemple de scénario

Une extension incluant des informations de clé nécessaires pour déchiffrer la partie chiffrée d'un KDC-REP :

• ne peut être utilisée que lorsque le destinataire est connu pour prendre en charge l'extension
• le client peut signaler son support via un élément padata dans la séquence AS-REQ
• le KDC ne devrait utiliser l'extension que si l'élément padata est présent

Bonne pratique : si la politique exige l'extension, renvoyer une erreur indiquant que l'extension est requise plutôt que de l'utiliser lorsque le destinataire pourrait ne pas la prendre en charge. Cela facilite le diagnostic.

Référence

Pour les détails techniques complets, voir RFC 4120, section 1.5.