État actuel du RFC capport

Cet article est le deuxième de la série « The protocol gap ». Dans le premier article, nous avons montré les difficultés rencontrées par les dispositifs invités pour communiquer avec les portails captifs, car il n’existe pas de protocole standardisé pour cette situation. Il est recommandé de lire cet article en premier si vous ne l’avez pas encore fait.

Définir l’espace du problème

Avant que ce groupe de travail de l’IETF ne démarre, il a essayé de définir un énoncé de problème qui énumère ce pour quoi les portails captifs sont utilisés et quels sont les problèmes qu’ils introduisent. Les portails captifs sont utilisés pour authentifier les utilisateurs, afficher les conditions d’utilisation, imposer différentes largeurs de bande par utilisateur, afficher une politique de confidentialité (GDPR) ou d’autres informations, etc. Des statistiques sur l’utilisation du WiFi peuvent également intéresser l’opérateur. Comme il n’existe pas de méthode normalisée pour ce faire, de nombreuses solutions de contournement et de manipulations du réseau sont actuellement utilisées, comme nous l’avons décrit dans le premier article de blog de cette série.

Une nouvelle norme

Le groupe de travail capport souhaite maintenant proposer des ajouts aux protocoles actuels (comme ICMP) et une nouvelle interface (API) afin de fournir une méthode de communication normalisée. https://datatracker.ietf.org/wg/capport/about/

Il est important de préciser qu’il s’agit d’un projet de RFC inachevé et qu’il représente l’état actuel en janvier 2019. Différentes approches et opinions ont été discutées sur la manière dont la communication entre un appareil client et un portail captif devrait être effectuée et la discussion est toujours en cours.

L’organigramme suivant montre l’interaction entre les parties concernées.

1. L’appareil de l’utilisateur final reçoit les paramètres initiaux du réseau tels que l’IP, le masque de sous-réseau, la passerelle, le serveur DNS, … via DHCP. Il existe également une variante utilisant PvD (Provisioning Domains). L’appareil apprend l’URL du serveur API CAPPORT via une nouvelle option DHCP (DHCP6 et RA pour IPv6) définie dans la RFC-7710 déjà publiée (avec un petit ajout RFC-7710bis).

2. Si l’appareil ne met pas en œuvre cette nouvelle norme, il ne sait pas quoi faire de cette option DHCP (160) et de cette URL, et il commence donc à envoyer du trafic. Un autre cas est celui où l’appareil a été mis hors ligne par le portail captif et qu’il n’a pas réalisé qu’il était à nouveau bloqué, il enverra également du trafic.

3. Dans le cas de l’étape 2, le portail captif envoie maintenant un message ICMP pour indiquer à l’appareil de l’utilisateur final qu’il n’est pas autorisé à envoyer du trafic. Les dispositifs qui comprennent un tel message ICMP savent maintenant qu’ils doivent demander au serveur API CAPPORT quel est l’état actuel. Les autres périphériques ignoreront ce message.

4. Le dispositif interroge le serveur API CAPPORT sur les restrictions actuelles et apprend éventuellement l’URL d’une page Web adaptée aux humains. Cette page peut contenir un formulaire de connexion, un paiement requis ou toute autre information.

5. Le dispositif ouvre alors un navigateur (captif) et présente la page de connexion à l’utilisateur si une URL a été fournie à l’étape 4.

6. Enfin, si les exigences du portail captif sont satisfaites par l’utilisateur final, l’appareil est mis en ligne et autorisé à accéder à l’internet.

Compatibilité ascendante

Lorsque cette nouvelle norme sera achevée et qu’elle sera déployée avec les appareils et les versions de systèmes d’exploitation les plus récents, il restera des appareils anciens qui existeront pendant de nombreuses années et qui ne seront pas en mesure d’interagir avec l’API CAPPORT. L’ancien comportement (redirection du trafic HTTP des clients hors ligne) doit encore être pris en charge. Le document actuel suggère d’envoyer les réponses ICMP de toute façon. Premièrement, il n’est pas certain que le client soit capable de comprendre la nouvelle API et deuxièmement, un appareil/OS peut faire les deux, la vérification de la connectivité et la vérification de l’API.

Pourquoi ICMP ?

ICMP a été la grande surprise de ce projet, mais voyons pourquoi il semble être le bon choix. Si un appareil client n’a pas (encore) été autorisé à accéder à l’internet, il doit en être informé. L’appareil ouvre n’importe quelle connexion sur l’IP et est bloqué par le portail captif. L’ICMP permet d’avertir le client sans dépendre d’un certain protocole sur les couches supérieures, comme les contrôles actuels des connexions propriétaires qui dépendent du HTTP non crypté. Ainsi, par exemple, la première connexion d’un appareil client était une connexion SMTP à un serveur de messagerie et le portail captif peut maintenant répondre par un message ICMP l’informant de la captivité.
Une autre chose intéressante à noter à propos de la notification ICMP est qu’elle ne contient pas d’URL vers l’API captive, car cela permettrait des attaques faciles. L’URL de l’API est transmise via l’option DHCP (RFC-7710). Bien sûr, DHCP n’est pas sécurisé et peut être falsifié, mais ce nouvel ajout n’abaissera pas la barrière de sécurité.

L’API CAPPORT

L’API CAPPORT permet au client d’interagir avec un portail captif via une API HTTP typique avec JSON comme format de données. Il est obligatoire d’utiliser HTTPS (HTTP over TLS – au moins la version 1.2). Alors que le dispositif client sait déjà qu’il se trouve derrière un portail captif, il veut maintenant obtenir l’état actuel et quelques détails sur la captivité. Un élément important que l’API doit fournir est l’URL d’une page web présentée à l’utilisateur avec une page de connexion ou toute autre information.

Un exemple de demande et de réponse pourrait ressembler à ceci :

GET/captive-portal/api/X54PD
Host: example.org
Accept: application/captive+json

The server then responds with the JSON content for that client:

GET/captive-portal/api/X54PD
Hôte : example.org
Acceptation : application/captive+json

Le serveur répond alors avec le contenu JSON pour ce client :

HTTP/1.1 200 OK
Cache-Control : private
Date : Mon, 04 Dec 2018 05:07:35 GMT
Content-Type : application/captive+json
{
« permitted » : faux,
« user-portal-url » : « https://example.org/portal »
« expire-date » : « 2019-01-01T23:28:56. 782Z »
}

Il ne s’agit bien sûr que d’un projet, mais il montre clairement où il nous mènera.

En ligne ou non ?

Il y a actuellement un débat sur la question de savoir si le portail captif ne peut signaler à un appareil qu’un état binaire – en ligne ou hors ligne – par rapport à une version plus différenciée dans laquelle l’appareil peut apprendre qu’il est autorisé à accéder à certaines ressources (comme dans un jardin clos) mais qu’il ne peut se connecter à aucun serveur sur l’internet. Nous préférons cette dernière solution, car les portails captifs sont principalement utilisés dans des environnements soumis à certaines restrictions.

Perspectives

L’état actuel du document nous semble prometteur en tant que fabricant et nous sommes impatients de le mettre en œuvre lorsqu’une première version sera disponible. Le manque de support pour le RFC-7710 a montré qu’il dépend des deux grands fournisseurs de systèmes d’exploitation mobiles – Google et Apple – si tout cela peut être utilisé un jour. En regardant les adresses électroniques, il semble que des personnes des deux entreprises participent, donc nous espérons toujours.

Cet article a été mis à jour.