Aller au contenu principal

1.5.1. Compatibilité avec RFC 1510

1.5.1. Compatibilité avec RFC 1510

Notez que les formats de messages Kerberos existants ne peuvent pas être facilement é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 lignes directrices pour s'assurer que les champs ASN.1 peuvent être ajoutés sans créer de problème d'interopérabilité.

En attendant, toutes les implémentations Kerberos nouvelles ou modifiées qui reçoivent une extension de message inconnue DEVRAIENT préserver l'encodage de l'extension mais sinon 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 inclus 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. Compter sur ces implémentations pour honorer les restrictions de données d'autorisation peut créer une faiblesse de sécurité.