Chiffrement Telnet : CAST-128 en rebouclage par la sortie à 64 bits

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé

Le présent document spécifie comment utiliser l'algorithm de chiffrement CAST-128 en mode de rebouclage par la sortie avec l'option de chiffrement telnet. Deux tailles de clés sont définies : 40 bits et 128 bits.

1. Noms et codes des commandes

Type de chiffrement

CAST5_40_OFB64 9

CAST128_OFB64 11

Commandes de sous-option

OFB64_IV 1

OFB64_IV_OK 2

OFB64_IV_BAD 3

2. Signification des commandes

IAC SB ENCRYPT IS CAST5_40_OFB64 OFB64_IV <vecteur initial> IAC SE

IAC SB ENCRYPT IS CAST128_OFB64 OFB64_IV <vecteur initial> IAC SE

L'envoyeur de cette commande génère un vecteur initial aléatoire de 8 octets, et l'envoie à l'autre côté de la connexion en utilisant la commande OFB64_IV. Le vecteur initial est envoyé en clair. Seul le côté de la connexion qui est WILL ENCRYPT peut envoyer la commande OFB64_IV.

IAC SB ENCRYPT REPLY CAST5_40_OFB64 OFB64_IV_OK IAC SE

IAC SB ENCRYPT REPLY CAST128_OFB64 OFB64_IV_OK IAC SE

IAC SB ENCRYPT REPLY CAST5_40_OFB64 OFB64_IV_BAD IAC SE

IAC SB ENCRYPT REPLY CAST128_OFB64 OFB64_IV_BAD IAC SE

L'envoyeur de ces commandes accepte ou rejette le vecteur initial reçu dans une commande OFB64_IV. Seul le côté de la connexion qui est DO ENCRYPT peut envoyer les commandes OFB64_IV_OK et OFB64_IV_BAD. La commande OFB64_IV_OK DOIT être envoyée pour la rétro compatibilité avec les mises en œuvre existantes ; il n'y a en fait aucune raison pour qu'un envoyeur ait besoin d'envoyer la commande OFB64_IV_BAD sauf dans le cas d'une violation du protocole où le vecteur initial envoyé n'aurait pas la longueur correcte (c'est à dire ne ferait pas huit octets).

3. Règles de mise en œuvre

Une fois qu'une commande OFB64_IV_OK a été reçue, le côté WILL ENCRYPT de la connexion devrait faire une négociation d'id_de_clé en utilisant la commande ENC_KEYID. Une fois que la négociation de id_de_clé a bien identifié un id_de_clé commun, les commandes START et END peuvent alors être envoyées par le côté de la connexion qui est WILL ENCRYPT. Les données seront chiffrées en utilisant l'algorithme de rétroaction en sortie CAST128 à 64 bits.

Si le chiffrement (déchiffrement) est désactivé et réactivé à nouveau, et si le même id_de_clé est utilisé lors du redémarrage du chiffrement (déchiffrement) le texte en clair qui intervient ne doit pas changer l'état de la machine de chiffrement (déchiffrement).

Si une commande START est envoyée (reçue) avec un id_de_clé différent, la machine de chiffrement (déchiffrement) doit être réinitialisée immédiatement après la fin de la commande START avec la nouvelle clé et le vecteur initial envoyés (reçus) dans la dernière commande OFB64_IV.

Si une nouvelle commande OFB64_IV est envoyée (reçue) et si le chiffrement (déchiffrement) est activé, la machine de chiffrement (déchiffrement) doit être réinitialisée immédiatement après la fin de la commande OFB64_IV avec le nouveau vecteur initial et le id_de_clé envoyés (reçus) dans la dernière commande START.

Si le chiffrement (déchiffrement) n'est pas activé lorsque une commande OFB64_IV est envoyée (reçue) la machine de chiffrement (déchiffrement) doit être réinitialisée après la prochaine commande START, avec le id_de_clé envoyé (reçu) dans cette commande START, et le vecteur initial envoyé (reçu) dans cette commande OFB64_IV.

4. Algorithme

Rebouclage de sortie CAST à 64 bits

clé --->+------+

+->| CAST |--+

| +------+ |

+------------+

v

ENTRÉE --------->(+) ----> DONNÉES

Sachant que :

iV : vecteur initial, est long de 64 bits (8 octets.

Dn : est le n^e tronçon de 64 bits (8 octets) de données à chiffrer (déchiffrer).

On : est le n^e tronçon de 64 bits (8 octets) de résultat chiffré (déchiffré).

V0 = CAST(iV, clé)

V(n+1) = CAST(Vn, clé)

On = Dn ^ Vn

5. Intégration avec l'option Telnet AUTHENTICATION

Comme il est noté dans les spécifications de l'option Telnet ENCRYPTION, une valeur d'id_de_clé de zéro indique la clé de chiffrement par défaut, comme on peut la déduire de l'option Telnet AUTHENTICATION. Si la clé de chiffrement par défaut négociée par suite de l'option Telnet AUTHENTICATION contient moins de 16 (5) octets, l'option CAST128_OFB64 (CAST5_40_OFB64) ne doit pas être offerte ou utilisée comme option de chiffrement Telnet valide.

Si il y a moins de 32 (10) octets de données de clé, les 16 (5) premiers octets de données de clé sont utilisés comme id_de_clé 0 dans chaque direction. Si il y a au moins 32 (10) octets de données de clé, les 16 (5) premiers octets de données de clé sont utilisés pour chiffrer les données envoyées par le client Telnet au serveur Telnet ; les 16 (5) octets suivants des données de clé sont utilisés pour chiffrer les données envoyées par le serveur Telnet au client Telnet.

Toutes les données de clé supplémentaires sont utilisées comme données aléatoires à envoyer comme vecteur d'initialisation.

6. Considérations pour la sécurité

Le chiffrement avec le rebouclage de sortie n'assure pas l'intégrité des données ; un attaquant actif peut être capable de substituer du texte, si il peut prédire le texte en clair qui est transmis.

Le compromis est ici que d'ajouter un code d'authentification de message (MAC) va augmenter de façon significative le nombre d'octets nécessaire pour envoyer un seul caractère dans le protocole Telnet, ce qui va impacter les performances sur les liaisons lentes (c'est-à-dire, téléphoniques).

Lorsque cette option était à l'origine en projet, les vitesses de CPU n'étaient pas nécessairement assez rapides pour permettre l'utilisation de CFB. Depuis lors, les CPU vont beaucoup plus vite. Connaissant les faiblesses inhérentes au mode de rebouclage de résultat, peut-être devrait-il être déconseillé en faveur du mode CFB ?

Les modes de chiffrement qui utilisent des clés de 40 bits ne sont pas considérés comme sûrs. Le mode de clé à 40 bits CAST5_40_OFB64 est cité ici pour simplement documenter les mises en œuvre qui sont toujours très présentes sur l'Internet mais n'avaiennt jamais été documentées.

7. Remerciements

Le présent document se fonde sur le documence "Chiffrement Telnet : DES à rebouclage de sortie à 64 bits" rédigé à l'origine par Dave Borman de Cray Research avec le concours du groupe de travail Telnet de l'IETF.

8. Références

[RFC2144] C. Adams, "L'algorithme de chiffrement CAST-128", mai 1997. (Information)

Adresse de l'auteur

Jeffrey Altman, Editor

Columbia University

612 West 115th Street Room 716

New York NY 10025

USA

téléphone : +1 (212) 854-1344

mél : jaltman@columbia.edu

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définies dans les processus des normes de l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation à un objet particulier.

Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement assuré par la Internet Society.