Réunion ARREDU

du 14 juin 2005

Renater - Paris

Participants (18) :

Jean Benoit - David Roumanet - Benoit Ribot - Bruno Mongin - Guy Bisiaux
Kostya Kortchinsky - Frederic Boivent - Olivier Perrot - Xavier Marty
Nicolas Viers - David Chopard-Lallier - Thomas Olivier - Benoit Branciard - Jean-pierre Le Moan
Patrick Petit - Eric Jullien - Jean-Luc Munier - Christian Claveleira - Vincent Carpier

Rédacteurs : CC, VC

Ordre du jour

Le projet ARREDU : présentation du projet (C. Claveleira, CRU)

Projets en cours dans les établissements :

STAR : authentification dans les établissements grenoblois (D. Roumanet, CICG)
Etat des lieux à l'UPMC (J.L. Munier, CCR)
Authentification sur Osiris (J. Benoit, CRC)

Renater au centre des relations de confiance (C. Claveleira, CRU)

Kostya Kortchinsky rappelle que la charte Renater doit être respectée, y compris par les personnes en déplacement.
Il estime qu'il serait logique, pour des raisons de sécurisation et de "qualité de service" (interventions hors heures ouvrables par exemple) que le service soit hébergé et opéré par Renater.
Vu qu'il y a un aspect juridique lié au service ARREDU il suggère que la formalisation des engagements des établissements se fasse via une annexe aux agréments de connexion et soit donc signée par les responsables d'établissements. Cette procédure administrative doit être prise en compte par les exploitants du service : pourraient-ils consulter une base d'infos chez Renater ou Renater pourrait-il transmettre l'évènement de signature d'un établissement aux procédures de gestion ?
Sur tous ces points Kostya doit se renseigner et en informer le groupe.

Considérations de sécurité autour de Radius (C. Claveleira, CRU)

Vu les problèmes posés par les portails captifs ils sont à priori écartés du champ d'ARREDU. Mais il est évoqué le problème des sites ayant des portails captifs utilisant l'authentification Radius en plus des accès 802.1x recommandés : comment faire en sorte d'empêcher toute utilisation "accidentelle" du portail par des visiteurs ?

Backup du proxy national

Deux établissements se sont proposés : Valenciennes et le CRC. C'est le CRC qui est retenu.

Procédures et outils du CRU (V. Carpier, CRU)

Après discussion sur les informations à fournir par le correspondant ARREDU, on ajoute un correspondant suppléant, un courriel fonctionnel de type arredu@mon-domaine.fr (alias), ainsi qu'un numéro de téléphone.
Quel courriel doit on privilégier lorsque l'on veut prendre contact ?
Il est convenu du nom "arredu" pour l'usager de test et un mot de passe laissé au choix du correspondant.
A la soumission du formulaire, le secret partagé sera généré automatiquement (permettant un copier/coller pour directement l'inclure dans le fichier de configuration du radius).

Toutes ces informations seront lisibles et modifiables, après authentification, à tout moment par le correspondant.

Points discutés

accès préconisés : en 802.1x + PEAP, TLS ou TTLS et WEP dynamique avec authentification du serveur de rattachement
ssid : il est convenu de recommander d'annoncer "eduroam", après accord de Terena pour la phase de transition avant raccordement à EduRoam (accord obtenu le lendemain)
service "minimum" offert aux visiteurs : il est convenu d'offrir http, https, dns, icmp, IPSec, ssh, pops, imaps, ntp et SMTP sur le serveur de messagerie local
traçabilité : il semble compliqué d'associer un utilisateur avec une adresse (croisement Radius/DHCP/associations). Il est convenu que le CRC et le CICG qui ont commencé à se frotter à ce problème, fassent part de leurs expériences
Talweg : le portail développé par le CRIUM a été testé en particulier à Grenoble. Si le principe est séduisant (convertir du http en https), il semble y avoir des problèmes avec les ActiveX et javascript entre autres.
différentiation de populations : comment "selectionner" les catégories de visiteurs (principalement distinguer les personnels des étudiants) ? Il faudrait remonter la valeur de l'attribut eduPersonAffiliation et la tester sur le serveur du site visité : mais comment ?