1.5. Extending Kerberos without Breaking Interoperability (Étendre Kerberos sans Rompre l'Interopérabilité)
1.5. Étendre Kerberos sans Rompre l'Interopérabilité
À mesure que la base déployée des implémentations Kerberos s'élargit, l'extension de Kerberos devient plus importante. Malheureusement, certaines extensions au protocole Kerberos existant créent des problèmes d'interopérabilité en raison de l'incertitude concernant le traitement de certaines options d'extensibilité par certaines implémentations. Cette section inclut des directives qui permettront aux implémentations futures de maintenir l'interopérabilité.
Kerberos fournit un mécanisme général pour l'extensibilité du protocole. Certains messages de protocole contiennent des trous typés (typed holes) -- des sous-messages qui contiennent une chaîne d'octets ainsi qu'un entier qui définit comment interpréter la chaîne d'octets. Les types entiers sont enregistrés de manière centralisée, mais ils peuvent être utilisés à la fois pour les extensions de fournisseurs et pour les extensions normalisées via l'IETF.
Dans ce document, le mot "extension" se réfère à l'extension par définition d'un nouveau type à insérer dans un trou typé existant dans un message de protocole. Il ne se réfère pas à l'extension par ajout de nouveaux champs aux types ASN.1, sauf si le texte l'indique explicitement.
1.5.1. Compatibilité avec RFC 1510
Notez que les formats de messages Kerberos existants ne peuvent pas facilement être étendus en ajoutant des champs aux types ASN.1. L'envoi de champs supplémentaires entraîne souvent le rejet du message entier sans indication d'erreur. Les versions futures de cette spécification fourniront des directives pour garantir que les champs ASN.1 peuvent être ajoutés sans créer de problème d'interopérabilité.
En attendant, toutes les implémentations nouvelles ou modifiées de Kerberos qui reçoivent une extension de message inconnue DEVRAIENT préserver le codage de l'extension mais autrement ignorer sa présence. Les destinataires NE DOIVENT PAS refuser une demande simplement parce qu'une extension est présente.
Il existe une exception à cette règle. 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. L'une des utilisations principales des données d'autorisation est de restreindre l'utilisation du ticket. Si le service ne peut pas déterminer si la restriction s'applique à ce service, alors une faiblesse de sécurité peut en résulter si le ticket peut être utilisé pour ce service. Les éléments d'autorisation qui sont optionnels DEVRAIENT être enfermés dans l'élément AD-IF-RELEVANT.
Le service d'octroi de tickets DOIT ignorer mais propager aux tickets dérivés tous les types de données d'autorisation inconnus, sauf si ces types de données sont intégrés dans un élément MANDATORY-FOR-KDC, auquel cas la demande sera rejetée. Ce comportement est approprié car exiger que le service d'octroi de tickets comprenne les types de données d'autorisation inconnus nécessiterait que le logiciel KDC soit mis à niveau pour comprendre les nouvelles restrictions au niveau de l'application avant que les applications n'utilisent ces restrictions, diminuant l'utilité des données d'autorisation comme mécanisme de restriction de l'utilisation des tickets. Aucun problème de sécurité n'est créé car les services auxquels les tickets sont émis vérifieront les données d'autorisation.
Note d'implémentation: De nombreuses implémentations RFC 1510 ignorent les éléments de données d'autorisation inconnus. S'appuyer sur ces implémentations pour honorer les restrictions de données d'autorisation peut créer une faiblesse de sécurité.
1.5.2. Envoi de Messages Extensibles
Il faut faire attention à 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. Sauf si l'expéditeur sait qu'une extension est prise en charge, l'extension ne peut pas changer la sémantique du message principal ou des extensions précédemment définies.
Par exemple, une extension incluant des informations de clé nécessaires pour déchiffrer la partie chiffrée d'un KDC-REP ne pourrait être utilisée que dans des situations où le destinataire était connu pour prendre en charge l'extension. Ainsi, lors de la conception de telles extensions, il est important de fournir un moyen pour le destinataire de notifier l'expéditeur de la prise en charge de l'extension. Par exemple, dans le cas d'une extension qui change la clé de réponse KDC-REP, le client pourrait indiquer la prise en charge de l'extension en incluant un élément padata dans la séquence AS-REQ. Le KDC ne devrait utiliser l'extension que si cet élément padata est présent dans l'AS-REQ. Même si la politique exige l'utilisation de l'extension, il est préférable de renvoyer une erreur indiquant que l'extension est requise plutôt que d'utiliser l'extension lorsque le destinataire peut ne pas la prendre en charge. Le débogage des implémentations qui n'interopèrent pas est plus facile lorsque des erreurs sont renvoyées.