7.2. Messagerie KDC - transports IP

7.2. Messagerie KDC : transports IP

Kerberos définit deux mécanismes de transport IP pour la communication entre clients et serveurs : UDP/IP et TCP/IP.

7.2.1. Transport UDP/IP

Les serveurs Kerberos (KDC) prenant en charge les transports IP DOIVENT accepter les requêtes UDP et DEVRAIENT les écouter sur le port 88 (décimal), sauf configuration explicite d'un autre port UDP. Des ports alternatifs PEUVENT être utilisés lorsque plusieurs KDC pour plusieurs domaines (realms) tournent sur le même hôte.

Les clients Kerberos prenant en charge les transports IP DEVRAIENT permettre l'envoi de requêtes UDP. Les clients DEVRAIENT utiliser la découverte des KDC [7.2.3] pour déterminer l'adresse IP et le port vers lesquels envoyer leur requête.

Lorsqu'un client contacte un KDC pour une requête KRB_KDC_REQ en utilisant le transport UDP/IP, il envoie un datagramme UDP contenant uniquement un encodage de la requête au KDC. Le KDC répond par un datagramme de réponse contenant uniquement un encodage du message de réponse (soit un KRB_ERROR, soit un KRB_KDC_REP) vers le port d'envoi à l'adresse IP de l'émetteur. La réponse à une requête effectuée via le transport UDP/IP DOIT également utiliser le transport UDP/IP. Si la réponse ne peut pas être traitée en UDP (par exemple parce qu'elle est trop volumineuse), le KDC DOIT renvoyer KRB_ERR_RESPONSE_TOO_BIG, obligeant le client à réessayer la requête avec le transport TCP.

7.2.2. Transport TCP/IP

Les serveurs Kerberos (KDC) prenant en charge les transports IP DOIVENT accepter les requêtes TCP et DEVRAIENT les écouter sur le port 88 (décimal), sauf configuration explicite d'un autre port TCP. Des ports alternatifs PEUVENT être utilisés lorsque plusieurs KDC pour plusieurs domaines tournent sur le même hôte.

Les clients DOIVENT permettre l'envoi de requêtes TCP, mais PEUVENT choisir d'essayer d'abord une requête en UDP. Les clients DEVRAIENT utiliser la découverte des KDC [7.2.3] pour déterminer l'adresse IP et le port vers lesquels envoyer leur requête.

Note d'implémentation : certaines extensions du protocole Kerberos échouent si un client ou un KDC ne prenant pas en charge le transport TCP intervient dans l'échange. Les implémentations de la RFC 1510 n'étaient pas tenues de prendre en charge les transports TCP/IP.

Lorsque le message KRB_KDC_REQ est envoyé au KDC sur un flux TCP, la réponse (message KRB_KDC_REP ou KRB_ERROR) DOIT être renvoyée au client sur le même flux TCP que celui établi pour la requête. Le KDC PEUT fermer le flux TCP après avoir envoyé une réponse, mais PEUT le laisser ouvert pendant une durée raisonnable s'il attend un échange ultérieur. Il faut veiller à la gestion des connexions TCP/IP sur le KDC afin d'éviter les attaques par déni de service fondées sur le nombre de connexions TCP/IP ouvertes.

Le client DOIT être prêt à ce que le KDC ferme le flux à tout moment après réception d'une réponse. Une fermeture de flux NE DEVRAIT PAS être traitée comme une erreur fatale. Au contraire, si plusieurs échanges sont nécessaires (par ex. certaines formes de pré-authentification), le client peut devoir établir une nouvelle connexion lorsqu'il est prêt à envoyer des

messages suivants. Un client PEUT fermer le flux après avoir reçu une réponse, et DEVRAIT le fermer s'il n'attend pas d'échanges de suivi.

Un client PEUT envoyer plusieurs requêtes avant de recevoir les réponses, mais il doit être prêt à gérer la fermeture de la connexion après la première réponse.

Chaque requête (KRB_KDC_REQ) et chaque réponse (KRB_KDC_REP ou KRB_ERROR) envoyée sur le flux TCP est précédée de la longueur de la requête sur 4 octets en ordre d'octets réseau (network byte order). Le bit de poids fort de la longueur est réservé pour une extension future et DOIT actuellement être à zéro. Si un KDC qui ne sait pas interpréter un bit de poids fort à 1 dans l'encodage de la longueur reçoit une requête avec ce bit à 1, il DOIT renvoyer un message KRB-ERROR avec l'erreur KRB_ERR_FIELD_TOOLONG et DOIT fermer le flux TCP.

Si plusieurs requêtes sont envoyées sur une seule connexion TCP et que le KDC envoie plusieurs réponses, le KDC n'est pas tenu d'envoyer les réponses dans l'ordre des requêtes correspondantes. Cela peut permettre à certaines implémentations d'envoyer chaque réponse dès qu'elle est prête, même si des requêtes antérieures sont encore en cours de traitement (par exemple en attente d'une réponse d'un périphérique ou d'une base de données externe).

7.2.3. Découverte des KDC sur les réseaux IP

Les implémentations clientes Kerberos DOIVENT fournir un moyen pour le client de déterminer l'emplacement des centres de distribution de clés Kerberos (KDC). Traditionnellement, les implémentations Kerberos ont stocké ces informations de configuration dans un fichier sur chaque machine cliente. L'expérience montre que cette méthode pose des problèmes d'information obsolète et de montée en charge, en particulier avec l'authentification inter-domaines. Cette section décrit une méthode utilisant le système de noms de domaine (Domain Name System) [RFC1035] pour stocker les informations de localisation des KDC.

7.2.3.1. DNS et Kerberos : sensibilité à la casse des noms de domaine (realm)

Dans Kerberos, les noms de domaine (realm names) sont sensibles à la casse. Bien qu'il soit fortement recommandé que tous les noms de domaine soient entièrement en majuscules, cette recommandation n'a pas été adoptée par tous les sites. Certains sites utilisent des noms entièrement en minuscules, d'autres un mélange. Le DNS, en revanche, est insensible à la casse pour les requêtes. Comme les noms de domaine « MYREALM », « myrealm » et « MyRealm » sont tous différents, mais se résolvent de la même façon dans le système de noms de domaine, il est nécessaire qu'une seule des combinaisons possibles de majuscules et minuscules soit utilisée dans les noms de domaine.

7.2.3.2. Spécification de l'emplacement des KDC avec les enregistrements DNS SRV

Les informations de localisation des KDC doivent être stockées au moyen du RR DNS SRV [RFC2782]. Le format de ce RR est le suivant :

_Service._Proto.Realm TTL Class SRV Priority Weight Port Target

Le nom de service pour Kerberos est toujours « kerberos ».

Le Proto peut être « udp » ou « tcp ». Si ces enregistrements SRV doivent être utilisés, les enregistrements « udp » et « tcp » DOIVENT être spécifiés pour tous les déploiements de KDC.

Le Realm est le domaine Kerberos auquel correspond cet enregistrement. Le domaine DOIT être un nom de domaine de style DNS (domain-style realm name).

TTL, Class, SRV, Priority, Weight et Target ont la signification habituelle définie dans la RFC 2782.

Conformément à la RFC 2782, le numéro de port utilisé pour les enregistrements SRV « _udp » et « _tcp » DEVRAIT être la valeur assignée à « kerberos » par l'Internet Assigned Numbers Authority : 88 (décimal), sauf si le KDC est configuré pour écouter sur un autre port TCP.

Note d'implémentation : de nombreux clients existants ne prennent pas en charge la découverte des KDC et sont configurés pour envoyer les requêtes au port assigné par l'IANA (88 décimal) ; il est donc fortement recommandé que les KDC soient configurés pour écouter sur ce port.

7.2.3.3. Découverte des KDC pour les noms de domaine de style DNS sur les réseaux IP

Il s'agit d'enregistrements DNS pour un domaine Kerberos EXAMPLE.COM. Il possède deux serveurs Kerberos, kdc1.example.com et kdc2.example.com. Les requêtes doivent d'abord être dirigées vers kdc1.example.com selon la priorité indiquée. Les poids ne sont pas utilisés dans ces enregistrements d'exemple.

_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.