RFC 7542 : The Network Access Identifier
http://www.bortzmeyer.org/7542.html
----------------------------
Auteur(s) du RFC: DeKok, Alan (FreeRADIUS)
Chemin des normes
----------------------------
Ce nouveau RFC normalise le concept d'*identificateur pour l'accès au
réseau* (NAI pour "Network Access Identifier"). Cet identificateur est
traditionnellement utilisé lors d'un accès authentifié au réseau, pour
indiquer la personne ou l'entité qui veut se connecter (avec un mot de
passe, ou autre information de créance, pour s'authentifier). Le NAI a
une forme qui ressemble aux adresses de courrier ou XMPP. Par exemple,
un NAI peut être ma...@example.com ou jean_dupont@labs.potamochère.fr.
Contrairement au traditionnel "login" ou nom d'utilisateur, le NAI
inclus l'indication d'un domaine (ou plutôt royaume) d'origine,
permettant au point d'accès d'accepter des utilisateurs issus d'un
autre domaine. Le NAI permet donc des accès *fédérés*. Ce concept, en
dépit de ce nom, est désormais utilisé pour bien d'autres choses que
l'accès au réseau. Notre RFC remplace la norme précédente, le RFC 4282,
notamment en développant bien plus l'internationalisation (un NAI n'est
pas forcément en ASCII). Bienvenue dans le monde merveilleux (et très
bordélique) du AAA.
Initialement, la principale motivation pour le NAI ("Network Access
Identifier") était le "roaming" : un utilisateur abonné au FAI X se
déplace dans une zone où X ne fournit pas d'accès mais a un accord avec
le FAI Y qui, lui, est présent. Pour éviter de recopier la base
d'utilisateurs de X dans celle de Y, l'utilisateur présente un NAI qui
indique son rattachement à X (son "home domain"). Le point d'accès de Y
sait alors qu'il doit demander l'authentification à X. Une fois que
c'est fait, on peut donner l'accès via Y (le "visited domain"). C'est
par exemple ainsi que fonctionne la fédération Eduroam. (L'auteur du
RFC est d'ailleurs l'auteur et le mainteneur de FreeRADIUS, un des
logiciels les plus utilisés pour cette tâche. Le protocole RADIUS est
normalisé dans le RFC 2865.)
Le NAI permet donc à des FAI purement régionaux d'accueillir des
clients d'autres régions du pays, à des FAI nationaux d'accueillir des
clients d'autres pays, à des "hotspots WiFi" de servir plusieurs FAI
avec la même infrastructure, etc. Une description de l'usage des NAI
dans des situations de "roaming" est donné dans le RFC 2194.
On l'a vu, le NAI peut servir à bien d'autres choses que l'accès au
réseau. Sa définition est donc indépendante du protocole qui va
l'utiliser (le NAI n'est pas spécifique à RADIUS.) Par contre, son
encodage effectif dépendra du protocole (par exemple, il faudra assurer
l'échappement de certains caractères, le NAI sop...@internautique.fr
deviendra sophie@internautique%2Efr dans un URL). À noter que le NAI,
quoique répandu, n'est pas *le* format unique d'identificateur sur le
réseau. Certains protocoles existants ont un autre format, et certains
permettent le NAI et d'autres formats. Pour les protocoles futurs,
notre RFC recommande qu'ils adoptent le NAI, pour uniformiser les
identificateurs. C'est déjà le cas de 3GPP dont la norme
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/> « "TS 23.003
Numbering, addressing, and Identification (Release 12)" » précise que
l'identificateur est un NAI comme
234150999999...@ims.mnc015.mcc234.3gppnetwork.org.
Attention, le but est d'uniformiser le format, pas les identificateurs.
Le NAI n'implique pas que chaque utilisateur ait un identificateur et
un seul ! Cela poserait, entre autres, de sérieux problèmes liés à la
vie privée. Le RFC recommande d'ailleurs de permettre des
identificateurs anonymes (pseudonymes, plutôt) dès qu'ils sont visibles
publiquement.
Un peu de terminologie nécessaire pour comprendre le NAI figure en
section 1.1. Notez le NAS ("Network Access Server") qui est la première
machine à laquelle les utilisateurs se connectent pour avoir un accès à
l'Internet. Pour les technologies PPTP et L2TP, ce sera le
concentrateur d'accès. En WiFi, ce sera le point d'accès ("hotspot").
Lorsque l'utilisateur envoie son NAI, c'est le NAS qui extrait le
domaine de l'utilisateur et relaie (par exemple en RADIUS) la demande
d'authentification à ce domaine.
Une bonne partie des changements depuis le RFC 4282 avait été motivé
par l'expérience d'Eduroam. Par exemple, la section 2.1 du RFC 4282
demandait que le nom de domaine soit uniquement composé de lettres
ASCII, de chiffres et de tirets. Pour les IDN, l'idée était d'utiliser
la forme Punycode. Celle-ci est peu pratique, et souvent inutile
puisque plusieurs protocoles utilisant les NAI (comme RADIUS ou comme
l'EAP du RFC 3748) ne sont pas limités à l'ASCII et recommandent UTF-8
comme encodage des chaînes de caractères (cf. section 3.2). Le RFC 4282
avait d'autres problèmes d'internationalisation comme d'exiger une
normalisation des chaînes (qui peut rentrer en conflit avec des
exigences locales) ou comme d'exiger des opérations qui soient
dépendantes de la langue (que le NAS et autres équipements
intermédiaires ne connaissent pas forcément, et ne savent pas toujours
gérer). D'autre part, le RFC 4282 interdisait l'utilisation de points
de code Unicode non affectés. Cela empêchait le déploiement de toute
nouvelle écriture puisque, au début, tous les équipements réseau
auraient considéré ces nouveaux caractères comme non affectés ! En
pratique, d'ailleurs, aucun équipement réseau n'a mis en œuvre les
recommandations d'internationalisation du RFC 4282. Le "roaming"
international se développant, il était temps de changer ces
recommandations irréalistes.
La section 2 de notre RFC présente la définition formelle du NAI. Il
est en UTF-8, normalisé NFC. Il est divisé en deux parties, le nom
d'utilisateur, et le royaume ("realm"). Ces deux parties sont séparées
par un @. Le nom d'utilisateur peut être composée de lettres (Unicode,
pas uniquement ASCII), de chiffres et de quelques symboles.
fred=?#$&*+-/^smith est donc un nom d'utilisateur valable. Le royaume
ressemble à un nom de domaine, avec ses composants séparés par des
points mais n'en est pas forcément un. Un exemple de NAI est donc
eng%genevièv...@example.net où eng%geneviève est le nom d'utilisateur et
le domaine (royaume) est example.net. (La grammaire formelle est en
section 2.2.) Un nom de royaume ne doit pas être réduit à un seul
composant donc maire@paris n'est pas un NAI même si le TLD .paris
existe. En effet, certains équipements considèrent qu'un royaume d'un
seul composant est un sous-royaume du royaume local (donc, chez le FAI
example.net, le NAI maire@paris serait interprété
ma...@paris.example.net).
Le royaume peut être en Unicode, bien des protocoles AAA autorisent à
la transporter nativement et il est donc désormais déconseillé
d'encoder en Punycode (RFC 3492). Ainsi, le NAI faïza@café.example
s'écrit bien ainsi, et pas faïza@xn--caf-dma.example. (Il semble bien
que c'est ce que faisaient déjà tous les équipements qui géraient des
noms de royaumes en Unicode, malgré ce que disait le RFC 4282.)
Il n'y a pas de limite de taille aux NAI, juste la recommandation de
pouvoir gérer au moins 72 octets et, de préférence, 253. (Attention, en
UTF-8, un caractère ne fait pas forcément un octet.) Les NAI étant
utilisés dans des protocoles très différents, on a parfois des
surprises. Ainsi, l'attribut User-Name de RADIUS exige d'accepter
jusqu'à 63 octets mais ne dit rien au delà (RFC 2865, section 5.1). En
revanche, le protocole concurrent Diameter (RFC 6733) impose à ses
mises en œuvre des noms d'utilisateur jusqu'à 16 777 207 octets. Si on
est sûr de toujours passer par Diameter (ce qui est très peu probable),
on peut utiliser des NAI très longs.
Le nom d'utilisateur est opaque aux autres royaumes (comme pour le
courrier électronique même si beaucoup d'ignorants
<http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html
> violent cette règle). Par exemple, dans le eng%genevièv...@example.net
donné plus haut, on peut soupçonner que le nom d'utilisateur indique un
routage interne (vers le service d'ingéniérie puis vers l'utilisatrice
Geneviève) mais on ne peut pas en être sûr, chaque royaume a ses
propres règles. On doit donc traiter le nom d'utilisateur comme un
tout, sauf si on est le "home domain". Parfois, des protocoles
transmettent juste le nom de royaume, faisant passer le nom
d'utilisateur dans un canal plus sûr, afin de préserver la vie privée
(cf. le TTLS du RFC 5281). L'habitude dans ce cas est de remplacer le
nom d'utilisateur par anonymous mais c'est désormais déconseillé, il
vaut mieux un nom vide (@internautique.fr est donc un NAI valide). Avec
les autres protocoles, notre RFC recommande d'utiliser des noms
d'utilisateurs éphémères, pour la vie privée, mais c'est très rarement
le cas aujourd'hui.
On a vu qu'on pouvait utiliser des caractères Unicode aussi bien pour
le nom de royaume que pour celui de l'utilisateur. Pour les noms
d'utilisateur, les règles se basent sur celles du RFC 6532. Pour le nom
de royaume, on est restreint aux caractères utilisables dans un nom de
domaine (RFC 5891). L'éventuelle traduction en UTF-8 (au cas où
l'utilisateur ait rentré des caractères dans un autre encodage) et la
normalisation en NFC doivent être faites au tout début, lorsqu'on est
encore proche de l'utilisateur et qu'on sait ce qu'il veut (on connait
sa langue, par exemple, ce qui n'est pas le cas des équipements réseau
intermédiaires ; ces équipements intermédiaires ont tout intérêt à ne
*pas* tripoter les NAI). Ceci dit, cette situation idéale (les
terminaux normalisent, les intermédiaires ne changent rien) n'est pas
respectée aujourd'hui. Il existe des terminaux qui ne normalisent pas,
injectant ainsi des chaînes non-UTF8 dans le système
d'authentification. Le RFC note donc que le principe « les terminaux
normalisent, les intermédiaires ne changent rien » doit parfois être
violé. « "The suggestion in the above sentence contradicts the
suggestion in the previous section. This is the reality of imperfect
protocols." » Ce point a été l'un des plus disputés lors de l'écriture
de ce RFC.
Une fois le NAI défini, notre RFC s'attaque au routage des requêtes
(section 3). Typiquement, le système d'authentification et autorisation
(AAA) extrait le royaume du NAI et s'en sert comme clé pour une table
où sont stockés les royaumes qu'on connait et avec qui on a une
relation d'acceptation de leurs utilisateurs. Si le royaume n'est pas
trouvé dans la table, on refuse l'utilisateur. S'il est trouvé, le
contenu de la table nous dira le serveur à interroger pour ce royaume
(ainsi que des informations comme le secret partagé RADIUS, le port,
etc). Attention, la sémantique des noms de royaume n'est pas forcément
connue et, par exemple, les équipements réseau ne savent pas si on peut
les consulter de manière insensible à la casse. Parfois, ça marche
(rappelez-vous le paragraphe précédent : le monde de l'AAA est
imparfait...) Si on ne trouve pas un nom de royaume dans la table, on
peut router sur une partie du royaume, par exemple utiliser example.net
si le royaume france.example.net n'a pas été trouvé. Attention, ce
n'est valable que si le nom raccourci reste un nom valide (net ne le
serait pas, vu la prohibition des noms d'un seul composant).
Les NAI ressemblent aux adresses de courrier électronique et certaines
normes sont communes aux deux (comme le RFC 6532) mais attention, les
règles ne sont pas exactement les mêmes. Toute adresse de courrier
n'est donc pas forcément un NAI valide. En pratique, les deux se
ressemblent suffisamment pour que beaucoup de FAI utilisent l'adresse
de courrier du client comme son NAI.
On a vu que l'AAA était un monde très riche, ancien, et qui contient
donc plein de choses surprenantes et de traditions historiques. La
section 3.3.1 contient quelques exemples rigolos, avec les
recommandations actuelles. Par exemple, les utilisateurs de RADIUS ont
longtemps utilisé du routage explicite, où une partie du NAI contenait
d'autres instructions de routage
(chezmoi.example!utilisateur@fai.example...). Cette méthode (citée par
le RFC 4282, section 2.7) s'est avérée très fragile, cassant dès qu'on
change le réseau. RADIUS n'ayant pas de protocole de routage (qui
diffuserait automatiquement les informations de routage), il fallait
informer beaucoup de systèmes en cas de changement. (Diameter - RFC
5729 - ou 3G sont des cas différents car ils utilisent un protocole de
routage.)
Le NAI étant en général utilisé dans un contexte de sécurité (point
d'entrée pour une authentification), notre RFC consacre une section, la
4, à ces problèmes. Par exemple, si le protocole transporte le nom
d'utilisateur en clair (c'est le cas de RADIUS), un écoutant sur le
trajet peut apprendre des noms d'utilisateurs existants. Pour empêcher
cela, il faut protéger (RADIUS avec IPsec, RFC 3579, Diameter avec TLS,
RFC 6733). Si on utilise plusieurs protocoles qui tous se servent de
NAI, et que l'utilisateur n'a qu'un seul NAI, un observateur pourra
relier entre elles ces différentes utilisations. D'où l'intérêt de ne
pas transporter les NAI en clair. Dans le futur, il serait encore mieux
d'avoir des NAI éphémères, changés de temps en temps.
Le monde de l'accès réseau étant compliqué, il y a également des
risques liés au fait qu'un identificateur peut être interprété d'une
façon par un protocole et d'une autre façon par un autre protocole.
Dernier problème des NAI à régler, celui de l'avitaillement (création,
maintenance, suppression) des identificateurs. Les noms de royaumes
ressemblent à des noms de domaine pour éviter d'avoir à créer une
nouvelle infrastructure d'avitaillement. Ainsi, si on est déjà
titulaire du domaine lesrépublicains.fr, on n'a pas besoin d'autre
chose pour créer des NAI comme nicolas@lesrépublicains.fr, tout en
étant sûrs de leur unicité, sur laquelle repose le routage. Bien qu'on
puisse toujours, techniquement parlant, prendre un nom, sans
l'enregistrer comme nom de domaine, pour faire des NAI, cette pratique
est interdite. Par contre, l'usage du DNS n'est pas obligatoire et ces
noms n'ont donc pas besoin d'être publiés. Si Diameter permet
d'utiliser le DNS pour localiser un serveur d'authentification, les
autres protocoles n'ont pas forcément cette possibilité : RADIUS repose
sur des configurations statiques.
L'annexe A résume les (importants) changements depuis le RFC 4282,
notamment :
* UTF-8 autorisé dans le nom de royaume,
* Abandon de Punycode.
Ces deux changements sont déjà largement déployés dans les équipements
qui gèrent des NAI en Unicode.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
