Annexe C. Questions d'Authentification
Cette annexe décrit un mécanisme d'authentification optionnel qui peut être utilisé pour vérifier l'intégrité des messages NTP et fournir une protection contre les attaques de modification et de rejeu de messages. Le mécanisme est basé sur la fonction de hachage cryptographique MD5 et utilise une clé secrète partagée entre les pairs. Lorsque l'authentification est activée, un champ d'authentificateur contenant un identifiant de clé et un condensé de message est ajouté au message NTP.
Le mécanisme d'authentification fournit les services de sécurité suivants:
- Intégrité du Message: Assure que le message n'a pas été modifié en transit.
- Authentification de Source: Vérifie que le message provient d'un pair légitime possédant la clé secrète partagée.
- Protection contre le Rejeu: Lorsqu'il est combiné avec le mécanisme d'horodatage NTP, fournit une protection contre les attaques par rejeu.
Le mécanisme d'authentification est optionnel et n'a pas besoin d'être implémenté dans tous les cas. Cependant, lorsque la sécurité est une préoccupation, en particulier dans les environnements où des serveurs de temps non autorisés pourraient injecter de fausses informations temporelles, le mécanisme d'authentification fournit un moyen efficace de protection.
C.1. Mécanisme d'Authentification NTP
Le mécanisme d'authentification NTP utilise la fonction de hachage cryptographique MD5 pour calculer un condensé de message sur le message NTP et une clé secrète partagée. Le condensé de message est ajouté au message NTP dans le champ d'authentificateur, avec un identifiant de clé qui spécifie quelle clé a été utilisée.
Le champ d'authentificateur a le format suivant:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Digest |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifiant de Clé: Il s'agit d'un entier non signé de 32 bits qui identifie la clé cryptographique utilisée pour générer le condensé de message.
Condensé de Message: Il s'agit d'un hachage MD5 de 128 bits calculé sur le message NTP (jusqu'à mais sans inclure le champ d'authentificateur) et la clé secrète partagée.
Les clés secrètes partagées sont configurées manuellement et stockées dans un fichier de clés accessible au démon NTP. Chaque clé a un identifiant unique et est représentée comme une valeur de 64 bits (8 octets). Le format de la clé est compatible avec l'algorithme de chiffrement DES, bien que DES ne soit pas utilisé directement dans le mécanisme d'authentification.
C.2. Procédures d'Authentification NTP
Les procédures d'authentification sont invoquées pendant les opérations de transmission et de réception. Lorsque l'authentification est activée, la procédure de transmission calcule le condensé de message et ajoute l'authentificateur au message sortant. La procédure de réception vérifie l'authentificateur sur les messages entrants et définit le bit authentifié en conséquence.
C.2.1. Procédure de Chiffrement
La procédure de chiffrement est appelée depuis la procédure de transmission lorsque l'authentification est activée. Elle calcule le condensé de message MD5 et ajoute l'authentificateur au message NTP.
begin encrypt procedure
if (peer.authenable = 0) exit; /* authentification désactivée */
/* Ajouter l'identifiant de clé */
pkt.keyid <- peer.hostkeyid;
/* Calculer le condensé MD5 sur le message et la clé */
digest <- MD5(message || key[peer.hostkeyid]);
/* Ajouter le condensé au message */
pkt.check <- digest;
end encrypt procedure
Le calcul MD5 est effectué sur l'ensemble du message NTP (y compris l'en-tête NTP et les champs d'horodatage) suivi de la clé secrète partagée. Le condensé de 128 bits résultant est ajouté au message dans le champ d'authentificateur.
C.2.2. Procédure de Déchiffrement
La procédure de déchiffrement est appelée depuis la procédure de réception pour vérifier l'authentificateur sur les messages entrants. Elle recalcule le condensé de message en utilisant la clé indiquée et le compare avec le condensé dans le message reçu.
begin decrypt procedure
if (peer.authenable = 0) begin /* authentification désactivée */
peer.authentic <- 1;
exit;
endif
/* Vérifier si l'identifiant de clé est valide */
if (pkt.keyid not in sys.keys) begin
peer.authentic <- 0;
exit;
endif
/* Extraire le condensé reçu */
received_digest <- pkt.check;
/* Calculer le condensé attendu */
expected_digest <- MD5(message || key[pkt.keyid]);
/* Comparer les condensés */
if (received_digest = expected_digest)
peer.authentic <- 1;
else
peer.authentic <- 0;
end decrypt procedure
Si l'authentification réussit (les condensés correspondent), le bit authentifié (peer.authentic) est défini sur 1, indiquant que le message provient d'un pair légitime. Si l'authentification échoue, le bit est défini sur 0, et selon la configuration, le message peut être rejeté.
C.2.3. Procédures de Message de Contrôle
Lorsque les messages de contrôle NTP décrits dans l'Annexe B sont implémentés avec authentification, le même mécanisme d'authentification est utilisé. Les procédures de chiffrement et de déchiffrement sont appliquées de la même manière que pour les messages NTP réguliers.
Pour les messages de contrôle, l'authentification est particulièrement importante car ces messages peuvent être utilisés pour lire et modifier les variables internes de l'implémentation NTP. Sans authentification, un attaquant pourrait potentiellement perturber la synchronisation temporelle ou extraire des informations sensibles.
Considérations d'Implémentation
Les considérations suivantes doivent être prises en compte lors de l'implémentation du mécanisme d'authentification:
-
Gestion des Clés: Les clés secrètes partagées doivent être configurées manuellement sur tous les pairs qui utiliseront l'authentification. Les clés doivent être changées périodiquement pour maintenir la sécurité.
-
Impact sur les Performances: Le calcul du condensé MD5 ajoute une surcharge de traitement à chaque message. Sur les systèmes avec des ressources CPU limitées, cela peut affecter la précision du chronométrage. Les implémentations doivent envisager la mise en cache des calculs de condensé ou l'utilisation de l'accélération matérielle lorsqu'elle est disponible.
-
Précision de l'Horodatage: L'opération de chiffrement doit être effectuée aussi près que possible de la transmission réelle du message pour minimiser l'impact sur la précision de l'horodatage. Certaines implémentations pré-calculent le décalage de condensé pour compenser le délai de chiffrement.
-
Espace d'Identifiant de Clé: L'espace d'identifiant de clé de 32 bits permet un grand nombre de clés, facilitant la rotation des clés et prenant en charge plusieurs domaines d'authentification.
-
Compatibilité Ascendante: Les messages avec et sans authentification peuvent coexister. Les pairs qui ne prennent pas en charge l'authentification ignorent simplement le champ d'authentificateur.
-
Limitations de Sécurité: Le mécanisme d'authentification protège contre les attaques de modification et de rejeu de messages mais ne fournit pas de chiffrement du contenu du message. L'information temporelle elle-même est transmise en texte clair.
Le mécanisme d'authentification décrit ici fournit un équilibre pratique entre sécurité et performances pour la plupart des déploiements NTP. Pour les environnements nécessitant des garanties de sécurité plus fortes, des mesures supplémentaires telles qu'IPsec ou d'autres mécanismes de sécurité de la couche transport peuvent être appropriées.