1.5.2. Envoi de Messages Extensibles

1.5.2. Envoi de Messages Extensibles

Il faut faire attention à s'assurer que les anciennes implémentations peuvent comprendre les messages qui leur sont envoyés, même si elles ne comprennent pas une extension qui est utilisée. À moins que l'expéditeur ne sache 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 est 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 retourner 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 retournées.