Statut de ce document
Ce document spécifie un protocole pour la pile standard
d’Internet destiné à la Communauté Internet, et nécessite
des discussions et des suggestions pour être testé et opérationnel.
Référez-vous à l’édition courante des Protocoles
Standards Officiels d’Internet ("Internet Official Protocol Standards"
(STD 1)) pour connaître l’état d’avancement et de normalisation
de ce protocole. La distribution de cette note n’est pas limitée.
Copyright Notice
Copyright (C) La Communauté Internet (1998). Tous droits
réservés.
Résumé
Le Protocole Point-to-Point (PPP) [1] offre une méthode
standard pour transporter des datagrammes multi-protocoles sur des liaisons
point-à-point.
PPP définit également une extension, un protocole
de Contrôle de Liaison (Link Control Protocol), qui permet la négociation
d’un protocole d’authentification pour authentifier la paire avant
d’autoriser les protocoles de la couche Réseau à transmettre
sur cette liaison.
Ce document définit le protocole d’extension d’authentification
de PPP (PPP Extensible Authentication Protocol).
1. Introduction
Pour établir une communication sur une liaison point-à-point,
chaque extrémité de la liaison PPP doit d’abord envoyer
des paquets LCP pour configurer la liaison de données pendant la phase
d’établissement du lien. Après que la liaison a été
établi, PPP propose une phase optionnelle d’Authentification avant
de procéder à la phase du Protocole de la Couche Réseau
(Network-Layer Protocol phase).
Par défaut, l’authentification n’est pas
obligatoire. Si on souhaite l’authentification de la liaison, l’implémentation
doit spécifier les options de configuration du protocole d’authentification
pendant la phase d’établissement de la liaison.
Ces protocoles d’authentification sont initialement prévus
pour être utilisés par les hôtes et les routeurs qui se connectent
à un serveur réseau PPP par des lignes ou des circuits commutés,
mais peuvent également être utilisés sur des liens dédiés.
Le serveur peut utiliser l’identification de l’hôte ou du
routeur se connectant afin de choisir les options pour les négociations
de la couche Réseau.
Ce document définit le PPP Extensible Authentication
Protocol (EAP). Les phases d’authentification et d’établissement
de liaison, et l’option de configuration du protocole d’authentification,
sont définis dans le protocole PPP [1].
1.1. Specification of Requirements
Dans ce document, de nombreux mots sont utilises pour mettre
en avant les besoins de la normalisation. Ces mots sont généralement
mis en lettres capitales. Les mots-clefs « DOIT », « NE DOIT
PAS », « NECESSAIRE », « PEUT », « NE PEUT
PAS », « DEVRAIT », « NE DEVRAIT PAS », «
RECOMMANDE », « POURRAIT », et « OPTIONNEL » de
ce document sont à interpréter comme décrit dans la RFC
2119 [6].
1.2. Terminologie
Ce document utilise fréquemment les termes suivants :
- authentifiant : l’extrémité de la liaison
qui demande une authentification. L’authentifiant spécifie le protocole
à utiliser dans la Demande de Configuration (Configure-Request) pendant
la phase d’établissement de la liaison.
- paire : l’autre extrémité de la liaison
point-à-point ; l’extrémité qui est authentifiée
par l’authentifiant.
- détruire (silently discard) : cela signifie que l’implémentation
détruit le paquet sans autre traitement. L’implémentation
DEVRAIT offrir la possibilité de rapporter l‘erreur dans un fichier
de log, comprenant le contenu du paquet détruit, et DEVRAIT enregistrer
l’événement pour faire des statistiques.
- message à afficher : c’est une chaîne de
caractères lisible par un être humain, et qui NE DOIT PAS affecter
le fonctionnement du protocole. Le message encodé DOIT suivre le format
de transformation UTF-8 [5].
2. PPP Extensible Authentication Protocol
(EAP)
Le PPP Extensible Authentication Protocol (EAP) est un protocole
générique pour l’authentification PPP qui supporte plusieurs
mécanismes d’authentification. EAP ne choisit pas un mécanisme
d’authentification particulier pendant la phase de contrôle de la
liaison, mais attend plutôt la phase d’authentification.
Cela permet à l’authentifiant de demander des informations avant
de déterminer le mécanisme d’authentification adapté.
Cela permet également l'utilisation d'un serveur principal qui gère
la mise en application réelle des différents mécanismes
à la place de l'authentifiant PPP
1. Une fois la phase d’Etablissement de la Liaison terminée,
l’authentifiant envoie une ou plusieurs Requêtes pour authentifier
la paire. La Requête a un champ « Type » pour indiquer l’objet
de la requête. Les exemples de Requêtes comprennent l’Identité,
MD5-challenge, Mot de passe à usage unique (One-Time Password), Generic
Token Card, etc. Le Type MD5-challenge correspond sensiblement au protocole
d’authentification CHAP. Typiquement, l’authentifiant enverra d’abord
une Requête d’Identité, suivie par une ou plusieurs Requêtes
pour les informations d’authentification. Quoiqu’il en soit, la
Requête initial d’Identité n’est pas obligatoire, et
peut être court-circuitée lorsque l’identité est présupposée
(lignes spécialisées, liaisons louées, etc.).
2. La paire envoie un paquet de Réponse en réponse
à chaque Requête. Comme pour le paquet de Requête, le paquet
de Réponse contient un champ « Type » correspondant au champ
« Type » de la Requête.
3. L’authentifiant met fin à la phase d’authentification
par l’intermédiaire d’un paquet de Succès ou d’Echec.
Avantages
Le protocole EAP peut supporter de multiples mécanismes
d’authentification sans avoir à pré-négocier un mécanisme
particulier pendant la phase LCP.
Certains éléments (e.g. un serveur d’accès
ou NAS) n’auront pas forcement besoin de comprendre tous les types de
Requête et devraient néanmoins être capable d’agir
en simple agent de passage pour un serveur d’extrémité ("back-end"
server) sur un hôte. L’élément aura seulement besoin
de regarder le code Succès/Echec pour mettre fin à la phase d’authentification.
Désavantages
EAP nécessite l’ajout d’un nouveau type d’authentification
à LCP et donc, les implémentations de PPP devront être modifiées
pour être utilisées. Il varie également du modèle
d’authentification précédent de PPP pour la négociation
d’un mécanisme d’authentification particulier pendant la
phase LCP.
2.1. Format des Options de Configuration
Le format des Options de Configuration du Protocole d’Authentification
(Authentication-Protocol Configuration Option) permettent de négocier
le Protocole d’Authentification EAP est proposé ci-dessous. Les
champs sont transmis de gauche à droite.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Longueur | Protocole d’authentification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : 3
Longueur : 4
Protocole d’Authentification : C227 (Hex) pour PPP Extensible Authentication
Protocol (EAP)
2.2. Format du paquet
Un paquet PPP EAP (et exactement un) est encapsulé dans
le champ d’information de la trame PPP de la Couche Liaison de Données
où le champ protocole est mis à C227 en hexadécimal (PPP
EAP). Le format du paquet EAP est donné ci-dessous. Les champs sont transmis
de la gauche vers la droite.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifiant | Longueur |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Données ...
+-+-+-+-+
Code
Le champ Code est codé sur un octet et identifie le type
de paquet EAP.
Les Codes EAP sont utilisés comme suit :
1 Requête
2 Réponse
3 Succès
4 Echec
Identifiant
Le champ Identifiant est codé sur un octet et permet
de faire correspondre les réponses et les requêtes.
Longueur
Le champ Longueur, sur 2 octets, indique la longueur du paquet
EAP, comprenant les champs Code, Identifiant, Longueur, et Données. Les
octets supplémentaires dépassant l’intervalle donné
par le champ Longueur devraient être traités comme du bourrage
de la couche Liaison de Données et devraient être ignorés
à la réception.
Données
Le champ Données comporte zéro octet ou plus.
Le format du champ Données est determine par le champ Code.
2.2.1. Requête et Réponse
Description
Le paquet de Requête est envoyé par l’authentifiant
à la paire. Chaque Requête a un champ type qui permet d’indiquer
ce qui est demandé. L’authentifiant DOIT transmettre un paquet
EAP avec le champ Code mis à 1 (Requête). Des paquets de requêtes
supplémentaires DOIVENT être envoyés jusqu’à
ce qu’un paquet de Réponse valide soit reçu, ou qu’un
compteur optionnel de retransmission expire. Les Requêtes retransmises
DOIVENT être envoyées avec la même valeur d’identifiant
pour être distinguées des nouvelles Requêtes. Le contenu
du champ Données dépend du type de Requête. La paire DOIT
envoyer un paquet de Réponse en réponse à un paquet de
Requête. Les Réponses DOIVENT uniquement être envoyées
en réponse à un paquet de Requête reçu et jamais
retransmis suite à l’expiration d’un délai. Le champ
Identifiant de la Réponse DOIT correspondre à celui de la Requête.
Note d’implémentation : Etant donné que
le processus d’authentification va souvent demander aux utilisateurs d’entrer
des informations, des précautions doivent être prises sur les stratégies
de retransmission et l’expiration des délais d’authentification.
Il est suggéré d’utiliser par défaut un délai
de 6 secondes et un maximum de 10 retransmissions. Certains pourront avoir envie
d’augmenter ces délais dans certains cas (e.g. en cas d’utilisation
de cartes Token par exemple). De plus, la paire doit être préparée
à détruire les retransmissions reçues pendant l’attente
des informations entrées par l’utilisateur.
Le format des paquets de Requête et de Réponse
est donné ci-dessous.
Les champs sont transmis de la gauche vers la droite.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifiant | Longueur |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Données...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
1 pour Requête;
2 pour Réponse.
Identifiant
Le champ Identifiant fait 1 octet. Le champ Identifiant DOIT
être le même si un paquet de Requête est retransmis après
un délai d’attente de la réponse. Toute nouvelle (non retransmission)
Requête DOIT entraîner la modification du champ Identifiant. Si
une paire reçoit une Requête dupliquée à laquelle
il a déjà envoyé une réponse, il doit réémettre
sa Réponse. Si une paire reçoit une Requête dupliquée
avant d’avoir envoyé sa Réponse à la Requête
initiale (i.e. il attend l’entrée des informations par l’utilisateur),
il DOIT détruire la Requête dupliquée.
Longueur
Le champ Longueur est codé sur 2 octets et indique la
longueur du paquet EAP, comprenant les champs Code, Identifiant,Type, et Données.
Les octets supplémentaires sortant de l’intervalle spécifié
par le champ Longueur devraient être traités comme du bourrage
de la couche liaison de données et devraient être ignorés
à la réception.
Type
Le champ Type est codé sur un octet. Ce champ indique
le Type de Requête ou de Réponse. Un seul Type DOIT être
spécifié par Requête ou Réponse EAP. Normalement,
le champ Type de la Réponse sera le même que celui de la Requête.
Cependant, il y a également un Type « Nak » (Réponse
Négative) pour indiquer qu’un type de Requête est inacceptable
par la paire. Lorsqu’on envoie un Nak en Réponse à une Requête,
la paire DEVRAIT proposer en alternative un autre Type d’Authentification
qu’il accepte. Une sélection initiale de Types est donnée
plus loin dans ce document.
Données
Le champ Données varie en fonction du Type de Requête
et de la Réponse associée.
2.2.2. Succès et Echec
Description
Le paquet de Succès est envoyé par l’authentifiant
à la paire pour reconnaître le succès de l’authentification.
L’authentifiant DOIT transmettre un paquet EAP avec le champ Code mis
à 3 (Succès).
Si l’authentifiant ne peut authentifier la paire (Réponses
inacceptables à une ou plusieurs Requêtes), alors l’implémentation
DOIT transmettre un paquet EAP avec le champ Code mis à 4 (Echec). Un
authentifiant PEUT essayer plusieurs Requêtes avant d’envoyer la
réponse d’Echec pour prendre en compte les fautes de frappes de
l’utilisateur.
Note d’implémentation : Du fait que les paquets
de Succès et d’Echec ne sont pas suivi d’accusés de
réception, ils peuvent éventuellement se perdre. Une paire DOIT
prendre en compte cette possibilité. La paire peut utiliser un paquet
du Protocole Réseau comme une indication possible de Succès. De
même, une Requête de Fin de Session LCP peut être considérée
comme un Echec.
Le format du paquet d’Echec ou de Succès est donné
ci-dessous.
Les champs sont transmis de la gauche vers la droite.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifiant | Longueur |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
3 pour Succès;
4 pour Echec.
Identifiant
Le champ Identifiant, codé sur un octet, permet de faire
correspondre les réponses aux Réponses. L’identifiant DOIT
correspondre au champ Identifiant du paquet de Réponse auquel il répond.
Longueur
4
3. Types initiaux de Requête et Réponse
EAP
Cette section définie un ensemble de Types EAP utilisés
lors des échanges Requête/Réponse. D’autres Types
pourront être définis dans d’autres documents. Le champ Type,
codé sur un octet, identifie la structure d’un paquet de Requête
et de Réponse EAP. Les 3 premiers Types sont considérés
comme des Types particuliers. Les Types suivants définissent des échanges
d’authentification. Le Type Nak est uniquement valide dans les paquets
de Réponse , il NE DOIT PAS être envoyé dans un paquet de
Requête. Le Type Nak DOIT seulement être envoyé en réponse
à une Requête utilisant un code de Type d’authentification.
Toutes les implémentations EAP DOIVENT supporter les Types 1 à
4. Ces Types, de même que les Types 5 et 6, sont définis dans ce
document. Des RFC ultérieures définiront des Types EAP supplémentaires.
1 Identité
2 Notification
3 Nak (Réponse seulement)
4 MD5-Challenge
5 One-Time Password (OTP) (RFC 1938)
6 Generic Token Card
3.1. Identité
Description
Le Type Identité est utilisé pour demander l’identité
d’une paire.
Généralement, l’authentifiant poursuit ensuite par une Requête
initial. Un message optionnel PEUT être affiché et envoyé
pour inviter la paire dans le cas où on attend une interaction avec l’utilisateur.
Une Réponse DOIT être envoyé à cette Requête
avec un Type à 1 (Identité).
Note d’implémentation : La paire PEUT obtenir l’identité
par l’entrée d’informations de l’utilisateur. Il est
suggéré que l’authentifiant réessaye la Requête
d’Identité en cas d’Identité invalide ou d’Echec
de l’authentification pour prendre en compte les fautes de frappe de l’utilisateur.
Il est suggéré de réessayer au moins 3 fois la Requête
d’Identité avant de mettre un terme à l’authentification
avec un message d’Echec. La Requête de Notification PEUT être
utilisée pour indiquer une authentification invalide avant de transmettre
une nouvelle Requête d’Identité (éventuellement, l’échec
PEUT être indiquer par un nouveau message d’Identité).
Type
1
Données
Ce champ peut contenir un message à afficher dans la
Requête. La Réponse utilise ce champ pour renvoyer son Identité.
Si l’Identité est inconnue, ce champ peut avoir une longueur de
zéro octet. Ce champ NE DOIT PAS être terminé par Null.
La longueur de ce champ est déduite du champ longueur du paquet de Requête/Réponse
et la valeur Null n’y a pas sa place.
3.2. Notification
Description
Le Type Notification est optionnellement utilisé pour
envoyer un message à afficher de l’authentifiant vers la paire.
La paire DEVRAIT afficher ce message à l’utilisateur, ou l’enregistrer
dans les logs s’il ne peut l’afficher. Il est prévu pour
fournir une notification sur un point précis et impératif. Par
exemple, pour un mot de passe avec délai d’expiration qui est sur
le point d’expirer, l’entier d’une séquence OTP qui
s’approche de 0, une mise en garde sur l’Echec possible de l’authentification,
etc. Dans la plupart des cas, la notification n’est pas nécessaire.
Type
2
Données
Le champ Données dans la Requête contient un message
à afficher ayant une longueur supérieure à zéro
octet. La longueur du message est déterminée par le champ Longueur
du le paquet de Requête. Le message NE DOIT PAS se terminer par Null.
Une Réponse DOIT être envoyée en réponse à
cette Requête avec un champ Type mis à 2 (Notification). Le champ
Données dans la Réponse fait zéro octet de long. La Réponse
devrait être envoyée immédiatement, quelque soit la façon
dont le message est affiché ou enregistré.
3.3. Nak
Description
Le Type Nak est uniquement valide dans les messages de Réponse.
Il est envoyé en réponse à une Requête comprenant
un Type d’Authentification inacceptable. Les Types d’Authentification
sont numérotés à partir de 4. La Réponse contient
le Type d’Authentification voulu par la paire.
Type
3
Données
Ce champ DOIT contenir un seul octet indiquant le type d’authentification
voulu.
3.4. MD5-Challenge
Description
Le Type MD5-Challenge (Défi MD5) est similaire au protocole
CHAP de PPP [3] (avec l’algorithme MD5). Il faut se référer
à la RFC du protocole CHAP (Challenge Handshake Authentication Protocol)
de PPP [3] pour plus d’informations sur les spécifications de l’implémentation.
La Requête contient un message “défi” pour la paire.
Une Réponse DOIT être envoyée en réponse à
cette Requête. La Réponse peut être de Type 4 (MD5-Challenge)
ou de Type 3 (Nak). La réponse Nak indique le Type de mécanisme
d’Authentification que la paire souhaite utiliser. Toutes les implémentations
EAP DOIVENT supporter le mécanisme du MD5-Challenge.
Type
4
Données
Le contenu du champ Données est donné ci-dessous.
La référence pour l’utilisation de ces champs est la RFC
du protocole CHAP de PPP [3].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valeur-Taille | Valeur ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nom ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.5. One-Time Password (OTP)
Description
Le système OTP (Mot de passe à usage unique)
est défini dans "A One-Time Password System" [4]. La Requête
contient un message à afficher contenant le défi OTP. Une Réponse
DOIT être envoyée en réponse à cette Requête.
La Réponse DOIT être de Type 5 (OTP) ou de Type 3 (Nak). La réponse
Nak indique le Type de mécanisme d’Authentification que la paire
souhaite utiliser.
Type
5
Données
Dans la Requête, le champ Données contient le “défi”
OTP sous forme d’un message à afficher. Dans la Réponse,
ce champ est utilisé pour les 6 mots du dictionnaire OTP [4]. Le message
NE DOIT PAS se terminer par Null. La longueur du champ est déduite du
champ Longueur du paquet de Requête/Réponse.
3.6. Generic Token Card
Description
Le Type Generic Token Card est défini pour être
utilisé avec plusieurs implémentations de cartes Token qui demandent
l’entrée d’informations par l’utilisateur. La Requête
contient un message texte codé en ASCII et la Réponse contient
les informations sur la carte Token nécessaires à l’authentification.
Typiquement, ce sera des informations lues par un utilisateur de la machine
ayant la carte Token et entrées en ASCII.
Type
6
Données
Le champ Données, dans le Requête, contient un
message à afficher ayant une longueur supérieure à zéro
octet. La longueur du message est déterminée par le champ Longueur
du paquet de Requête. Le message NE DOIT PAS se terminer par Null. Une
Réponse DOIT être envoyée en réponse à la
Requête avec un champ Type mis à 6 (Generic Token Card). La Réponse
contient des données de la carte Token nécessaires pour l’authentification
La longueur des Données est déterminée par le champ Longueur
du paquet de Réponse.
Note sur la Sécurité
La sécurité est le sujet principal de cette RFC.
L’interaction entre les protocoles d’authentification
et PPP est largement dépendante de l’implémentation.
Par exemple, suite à un Echec de l’authentification,
certaines implémentations ne coupent pas la liaison. L’implémentation
préfère limiter et filtrer le trafic des protocoles de la couche
Réseau, ce qui donne la possibilité à l’utilisateur
de mettre à jour ses mots de passe ou d’envoyer un mail à
l’administrateur réseau pour lui indiquer le problème.
Il n’y a pas de disposition particulière en cas
d’échec ou de nouvelle tentative d’authentification. De toute
façon, la machine d’états LCP peut renégocier le
protocole d’authentification à tout moment, ce qui permet une nouvelle
tentative. Il est recommandé que tout compteur utilisé pour les
échecs d’authentification ne soit pas remis à zéro
tant que l’authentification n’a pas réussi, ou que la liaison
en échec n’a pas été coupée.
Il n’y a pas d’obligation à ce que l’authentification
soit bidirectionnelle (full-duplex) ou que le même protocole soit utilisé
dans les deux directions. Il est parfaitement acceptable que des protocoles
différents soient utilisés dans chaque direction. Cela dépendra,
évidemment, des protocoles spécifiés et négociés.
En pratique, au sein ou associé au serveur PPP, il ne
faut pas prévoir qu’un nom d’utilisateur particulier pourra
être authentifié par plusieurs méthodes. Cela rendrait l’utilisateur
vulnérable aux attaques qui négocieraient la méthode la
moins sûre parmi celles proposées (comme PAP plutôt que EAP).
Pour chaque nom d’utilisateur, il faudrait plutôt indiquer la seule
méthode utilisée pour authentifier cet utilisateur. Si un utilisateur
doit utiliser différentes méthodes d’authentification en
fonction des circonstances, alors plusieurs identités DEVRAIENT être
utilisées, chacune identifiant une seule méthode d’authentification.
Références
[1] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[3] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)",
RFC 1994, August 1996.
[4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938,
May 1996.
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646",
RFC 2044, October 1996.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, March 1997.
Remerciements
Ce protocole est en partie inspiré du draft AHA de Dave
Carrel ainsi que du Protocole CHAP de PPP [3].
Bill Simpson a fourni beaucoup pour ce document. Al Rubens (Merit) a également
apporté un feedback intéressant.
Contacts
Le groupe de travail peut être contacté par l’intermédiaire
de son responsable :
Karl F. Fox
Ascend Communications, Inc.
655 Metro Place South, Suite 370
Dublin, Ohio 43017
EMail: karl@ascend.com
Phone: +1 614 760 4041
Fax: +1 614 760 4050
Adresses des auteurs :
Larry J. Blunk
Merit Network, Inc.
4251 Plymouth Rd., Suite C
Ann Arbor, MI 48105
EMail: ljb@merit.edu
Phone: 734-763-6056
FAX: 734-647-3185
John R. Vollbrecht
Merit Network, Inc.
4251 Plymouth Rd., Suite C
Ann Arbor, MI 48105