1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
Titre: RFC 8005: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions
Auteur:
Date: Sat 26 Nov 2016 01:00:00 +0100
Lien: https://www.bortzmeyer.org/8005.html
Le protocole HIP n'avait pas à l'origine de mécanisme pour trouver l'
identificateur d'une machine distante. Cela avait été fait dans le RFC 5205,
qui permettait de trouver l'identificateur dans le DNS. Ce nouveau RFC remplace
le RFC 5205.
HIP fait partie de la famille des protocoles qui visent à séparer
l'identificateur du localisateur[1]. Les identificateurs HIP se nomment les HI
(Host Identifier) et, autrefois, le seul moyen de trouver l'HI d'une autre
machine était d'attendre qu'elle vous contacte, ou bien de le configurer
manuellement. Avec ce RFC, on peut trouver l'HI, comme une adresse IP, dans le
DNS.
Notre RFC crée donc un nouveau type d'enregistrement DNS, nommé logiquement HIP
(numéro 55[2]), qui stocke, en échange d'un nom de domaine, le HI, son
condensat (résumé) cryptographique - le HIT (Host Identifier Tag) - et les
éventuels serveurs de rendez-vous, serveurs qui, dans le protocole HIP, servent
d'intermédiaires facultatifs lorsqu'on veut contacter une machine distante (cf.
RFC 8004).
Notre RFC permet de trouver l'identificateur à partir du nom mais pas le
localisateur ; les serveurs de rendez-vous sont une solution possible pour cela
; une autre est d'utiliser les traditionnels enregistrements A et AAAA du DNS,
le localisateur HIP étant une adresse IP.
Les localisateurs peuvent changer fréquemment alors que le DNS n'est pas
temps-réel et ne change pas instantanément[3]. Si un hôte HIP veut pouvoir être
contacté malgré des changements d'adresse IP rapides, il vaut peut-être mieux
qu'il utilise le système de rendez-vous du RFC 8004.
Curieusement (pour moi), le HIT est donc stocké dans les données DNS, alors que
celles-ci n'offrent aucune sécurité au point que le RFC exige en section 4.1 de
recalculer le HIT qui vient d'être obtenu dans le DNS.
Le tout ressemble donc aux enregistrements IPSECKEY du RFC 4025, ce qui est
normal, le HI étant une clé cryptographique publique.
Voici un exemple d'enregistrement HIP tel qu'il apparaitrait dans un fichier de
zone (sections 5 et 6 de notre RFC). On y trouve l'algorithme cryptographique
utilisé (2 = RSA), le HIT (en hexadécimal), le HI (encodé en Base64) et les
éventuels serveurs de rendez-vous (ici, deux, indiqués à la fin) :
www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
rvs1.example.com.
rvs2.example.com. )
Par contre, je n'ai pas réussi à trouver encore ce genre d'enregistrement dans
la nature.
L'ensemble du RFC est assez court, ce mécanisme d'annuaire qu'est le DNS étant
simple et bien connu.
Quels sont les changements depuis le premier RFC, le RFC 5205 ? Évidement le
passage sur le chemin des normes, faisant de HIP une norme complète. Mais aussi
l'ajout de l'algorithme de cryptographie asymétrique ECDSA, et plusieurs
clarifications du RFC original sur le format des enregistrements DNS, aussi
bien leur format sur le réseau que dans le fichier de zone.
Liens:
[1]: http://www.bortzmeyer.org/separation-identificateur-localisateur.html (lien)
[2]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-4 (lien)
[3]: http://www.bortzmeyer.org/dns-propagation.html (lien)
|
