RFC2948 page - 2 - Altman

Groupe de travail Réseau

J. Altman, Columbia University

Request for Comments : 2948

September 2000

Catégorie : En cours de normalisation

Traduction Claude brière de L'Isle



Chiffrement Telnet : DES3 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'algorithme de chiffrement triple-DES (norme de chiffrement des données) en mode à rebouclage par la sortie avec l'option de chiffrement telnet.


1. Noms et codes des commandes


Type de chiffrement


DES3_OFB64 4


Commandes de sous-option


OFB64_IV 1

OFB64_IV_OK 2

OFB64_IV_BAD 3


2. Signification des commandes


IAC SB ENCRYPT IS DES3_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 DES3_OFB64 OFB64_IV_OK IAC SE

IAC SB ENCRYPT REPLY DES3_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 que la commande OFB64_IV_OK a été reçue, le côté WILL ENCRYPT de la connexion devrait faire la négociation de l'id_de_clé en utilisant la commande ENC_KEYID. Une fois que la négociation du 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 DES3 de rebouclage par la sortie à 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 CFB64_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


DES3 en rebouclage par la sortie à 64 bits


clé1 clé2 clé3

| | |

v v v

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

+->| DES-e |->| DES-d |->| DES-e |-- +

| +-------+ +-------+ +-------+ |

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

v

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


Sachant que :

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

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

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


V0 = DES-e(DES-d(DES-e(iV, clé1),clé2),clé3)

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 de id_de_clé de zéro indique la clé de chiffrement par défaut, comme elle peut être déduite 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 octets, l'option DES3_OFB64 ne doit pas être offerte ou utilisés comme une option valide de chiffrement Telnet.


Les règles suivantes doivent être respectées pour la création des clés de chiffrement trois DES fondées sur les données de clé de chiffrement disponibles :


clés_à_utiliser = octets de connées de clé / taille de bloc DES (8 octets)


où les clés sont étiquetées de "clé1" à "clé6" avec "clé1" qui sont les 8 premiers octets; "clé2" les 8 octets suivants ; ... et "clé6" le sixième groupe de 8 octets (si disponible).


Lorsque deux clés sont disponibles :


. les données envoyées du serveur sont chiffrées avec clé1, déchiffrées avec clé2, et chiffrées avec clé1 ;


. les données envoyées du client sont chiffrées avec clé2, déchiffrées avec clé1, et chiffrées avec clé2


Lorsque trois clés sont disponibles :


. les données envoyées du serveur sont chiffrées avec clé1, déchiffrées avec clé2, et chiffrées avec clé3 ;


. les données envoyées du client sont chiffrées avec clé2, déchiffrées avec clé3, et chiffrées avec clé1


Lorsque quatre clés sont disponibles :


. les données envoyées du serveur sont chiffrées avec clé1, déchiffrées avec clé2, et chiffrées avec clé3 ;


. les données envoyées du client sont chiffrées avec clé2, déchiffrées avec clé4, et chiffrées avec clé1


Lorsque cinq clés sont disponibles :


. les données envoyées du serveur sont chiffrées avec clé1, déchiffrées avec clé2, et chiffrées avec clé3 ;


. les données envoyées du client sont chiffrées avec clé2, déchiffrées avec clé4, et chiffrées avec clé5


Lorsque six clés sont disponibles :


. les données envoyées du serveur sont chiffrées avec clé1, déchiffrées avec clé2, et chiffrées avec clé3 ;


. les données envoyées du client sont chiffrées avec clé4, déchiffrées avec clé5, et chiffrées avec clé6


Dans tous les cas, les clés utilisées par DES3_OFB64 doivent avoir leur parité corrigée après qu'il est déterminé qu'elles utilisent l'algorithme ci-dessus.


Noter que l'algorithme ci-dessus suppose qu'il est sûr d'utiliser une clé non DES (ou une partie d'une clé non DES) comme une clé DES. Ce n'est pas nécessairement vrai de tous les systèmes de chiffrement, mais on spécifie ce comportement comme comportement par défaut car il est vrai pour la plupart des systèmes d'authentification d'utilisation courante aujourd'hui, et pour la compatibilité avec les mises en œuvre existantes. De nouveaux mécanismes AUTHENTICATION Telnet pourront spécifier des méthodes de remplacement pour déterminer les clés à utiliser pour cette suite de chiffrement dans leur spécification, si la clé de session négociée par ce mécanisme d'authentification n'est pas une clé DES et lorsque cet algorithme peut n'être pas d'utilisation sûre.


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 ?



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.


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.