RFC(F) 3838

From RFC.Wiki
Jump to: navigation, search
Groupe de travail du réseau                                    A. Barbir
Demande de commentaires: 3838                            Nortel Networks
Catégorie: Informatif                                         O. Batuner
                                                              Consultant
                                                                 A. Beck
                                                     Technologies Lucent
                                                                 T. Chan
                                                                   Nokia
                                                                H. Orman
                                          Développement de Purple Streak
                                                               Août 2004

Exigences en matière de politique, d'autorisation et d'application
des services Open Pluggable Edge (OPES)

Statut de ce mémo

   Ce mémo fournit des informations à la communauté Internet. Cela fait
   ne pas spécifier de norme Internet d'aucune sorte. Distribution de ceci
   le mémo est illimité.

Copyright

   Copyright (C) L'Internet Society (2004).

Abstrait

   Ce document décrit la politique, l'autorisation et l'application
   les exigences relatives à la sélection des services à appliquer à un
   compte tenu du flux OPES (Open Pluggable Edge Services).

Table des matières

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Terminologie. . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Architecture politique. . . . . . . . . . . . . . . . . . . . . 4
       3.1. Composantes et fonctions de la politique. . . . . . . . . . . . 4
       3.2. Exigences relatives aux points de décision politique. . . . . . . . . 5
       3.3. Exigences relatives aux points d'application de la politique. . . . . . . 5
   4. Exigences relatives aux interfaces. . . . . . . . . . . . . . . . . 6
       4.1. Exigences relatives aux liaisons de service. . . . . . . . . . . . . 7
             4.1.1. Variables d'environnement . . . . . . . . . . . . . 7
             4.1.2. Conditions d'utilisation des informations d'état. . . . 8
             4.1.3. Conditions requises pour transmettre des informations entre
                     Prestations de service . . . . . . . . . . . . . . . . . . . . 8
       4.2. Exigences pour la gestion des règles et des règles. . . . . . . 8
             4.2.1. Exigences pour les fournisseurs de règles. . . . . . . . 8
             4.2.2. Exigences relatives aux formats de règles et aux protocoles. . 9
             4.2.3. Exigences relatives aux conditions de règle. . . . . . . . 9
             4.2.4. Conditions requises pour les actions de règle. . . . . . . . . 9
       4.3. Exigences pour l'expression de politique. . . . . . . . . . . dix
   5. Authentification des principaux et autorisation des services. . dix
       5.1. Utilisateurs finaux, éditeurs et autres considérations. . . . . 11
             5.1.1. Considérations pour les utilisateurs finaux. . . . . . . . . . 11
             5.1.2. Considérations relatives aux sites de publication. . . . . . . 12
             5.1.3. Autres considérations . . . . . . . . . . . . . . 12
       5.2. Authentification. . . . . . . . . . . . . . . . . . . . . 12
       5.3. Autorisation. . . . . . . . . . . . . . . . . . . . . 13
       5.4. Intégrité et cryptage. . . . . . . . . . . . . . . . 14
             5.4.1. Intégrité et confidentialité de l'authentification
                     et demandes / réponses de service. . . . . . . 14
             5.4.2. Intégrité et confidentialité de l'application
                     Contenu . . . . . . . . . . . . . . . . . . . . 14
       5.5. Intimité. . . . . . . . . . . . . . . . . . . . . . . . . 14
   6. Considérations de sécurité. . . . . . . . . . . . . . . . . . . 15
   7. Références. . . . . . . . . . . . . . . . . . . . . . . . . . 15
       7.1. Références normatives . . . . . . . . . . . . . . . . . . 15
       7.2. Références informatives. . . . . . . . . . . . . . . . . 15
   8. Remerciements. . . . . . . . . . . . . . . . . . . . . . . 16
   9. Adresses des auteurs. . . . . . . . . . . . . . . . . . . . . . 16
   10. Déclaration de copyright complète. . . . . . . . . . . . . . . . . . . 17

1. Introduction

   L’architecture OPES (Open Pluggable Edge Services) [1] permet
   services d'application coopératifs (services OPES) entre une donnée
   fournisseur, un consommateur de données et zéro ou plusieurs processeurs OPES. le
   services applicatifs envisagés analyser et éventuellement
   transformer les messages de niveau application échangés entre les données
   fournisseur et le consommateur de données. Le processeur OPES peut distribuer
   la responsabilité de l'exécution du service en communiquant et
   collaborer avec un ou plusieurs serveurs d'appels distants.

   L'exécution de ces services est régie par un ensemble de règles
   installé sur le processeur OPES. L'évaluation de la règle peut déclencher la
   exécution d'applications de service locales au processeur OPES ou sur un
   serveur d'appel distant.

   Les politiques expriment les objectifs d'un processeur OPES sous la forme d'un ensemble de règles
   utilisé pour administrer, gérer et contrôler l'accès aux ressources. le
   les exigences de ce document régissent le comportement des entités OPES
   déterminer lesquels des services disponibles doivent être appliqués à un
   message donné, le cas échéant.

   La portée des politiques OPES décrites dans ce document se limite à
   ceux qui décrivent les services à appeler et, le cas échéant, avec
   quels paramètres. Ces politiques n'incluent pas celles qui prescrivent
   le comportement des services appelés. Il est souhaitable d'activer un
   cadre de gestion commun pour spécifier les politiques à la fois
   l'appel et le comportement d'un service. L'intégration d'un tel
   la fonction est le domaine de l'interaction utilisateur de l'administration des politiques
   applications.

   Le document est organisé comme suit: la section 2 examine la politique
   cadre. La section 3 traite des exigences relatives aux interfaces, tandis que
   la section 4 examine l'authentification des mandants et l'autorisation des
   prestations de service.

2. Terminologie

   Les mots-clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "NE DOIT PAS",
   «DEVRAIT», «NE DEVRAIT PAS», «RECOMMANDÉ», «PEUT» et «OPTIONNEL» dans ce
   document doivent être interprétés comme décrit dans [4]. Lorsqu'il est utilisé avec
   les significations normatives, ces mots-clés seront tous en majuscules.
   Les occurrences de ces mots en minuscules comprennent l'usage normal de la prose,
   sans implications normatives.

3. Architecture politique

   Cette section décrit la décomposition de la stratégie architecturale
   exigences. Il décrit également les exigences relatives aux interfaces
   entre les composants de la politique. Beaucoup de règles ici étaient
   déterminé sous l'influence de la RFC 3238 [2].

3.1. Composantes et fonctions de la politique

   Les fonctions de politique sont décomposées en trois composants: une règle
   Auteur, un point de décision politique (PDP) [6] et une application de la politique
   Point (PEP) [6]. L'auteur de la règle fournit les règles à utiliser par un
   Entité OPES. Ces règles contrôlent l'appel des services sur
   au nom de l'auteur de la règle. Le PDP et le PEP interprètent le
   règles collectées et les appliquer de manière appropriée. La décomposition est
   illustré à la figure 1.

         +--------+                         +--------+
         |  Rule  |                         |  Rule  |
         | Author |          ...            | Author |
         +--------+                         +--------+
              |                                 |
              |                                 |
              |          +----------+           |
              |          |  Policy  |           |  <- PDP Interface
              +--------->| Decision |<----------+
                         |  Point   |
                         +----------+
                             | ^
                             | |
                             | |  <- PEP Interface
                             | |
                             V |
                       +--------------+   ...
                  ---> |    Policy    | --->
                       |  Enforcement |       Data Traffic
                  <--- |    Point     | <---
                       +--------------+


         + -------- + + -------- +
         | Règle    | | Règle |
         | Auteur   |...| Auteur |
         + -------- + + -------- +
              | |
              | |
              | + ---------- + |
              | | Politique | | <- Interface PDP
              + ---------> | Décision | <---------- +
                         | Point |
                         + ---------- +
                             | ^
                             | |
                             | | <- Interface PEP
                             | |
                             V |
                       + -------------- + ...
                  ---> | Politique | --->
                       | Application | Trafic de données
                  <--- | Point | <---
                       + -------------- +

                  Figure 1: Composantes de la politique

   La décomposition du contrôle de politique en un PDP et un PEP permet
   le déchargement de certaines tâches vers un service administratif qui peut être
   situé sur un serveur distinct des services d'application en temps réel
   du PEP résidant sur le processeur OPES.

   Le PDP prévoit l'authentification et l'autorisation de règle
   auteurs et la validation et la compilation des règles.

   Le PEP réside dans le filtre de données où les données d'un flux OPES
   est évalué par rapport aux règles compilées et aux appels appropriés au
   les services demandés sont exécutés.

   Les interfaces entre ces composants architecturaux sont des points de
   interopérabilité. L'interface entre les auteurs de règles et la stratégie
   les points de décision (interface PDP) DOIVENT utiliser le format qui peut
   des exigences décrites dans ce document.

   L'interface entre les points de décision politique et la politique
   les points d'application (interface PEP) peuvent être internes à un
   l'implémentation par le fournisseur d'un processeur OPES. Les implémentations DOIVENT utiliser
   interface standard uniquement si le PDP et le PEP résident sur des
   Processeurs OPES.

3.2. Exigences relatives aux points de décision politique

   Le point de décision politique est essentiellement un compilateur de politique. Le PDP
   DOIT être un service qui fournit un soutien administratif au
   points d'application. Le service PDP DOIT authentifier la règle
   auteurs.

   Le PDP DOIT vérifier que les règles spécifiées sont dans la portée de
   l'autorité des auteurs de règles. Le PDP DOIT être un composant de l'OPES
   Autorité administrative.

3.3. Exigences relatives aux points d'application de la politique

   Dans l'architecture OPES, le filtre de données représente une politique
   Point d'application (PEP). À ce stade, les données d'un flux OPES sont
   évalué par rapport aux règles compilées et aux appels appropriés aux
   les services demandés sont exécutés.

   Dans les règles PEP PEUVENT enchaîner les actions, où une série de
   les services à appeler sont spécifiés. La mise en œuvre DOIT assurer la
   transmission d'informations d'un service appelé à un autre.
   L'implémentation NE DOIT PAS interdire la réévaluation d'un message à
   déterminer si un autre service ou ensemble de services doit être appelé.

   L'exécution d'une action (c'est-à-dire le déclenchement d'une règle) peut conduire
   à la modification des valeurs de propriété de message. Par exemple, un OPES
   service qui, dans certaines circonstances, convertit les images JPEG en GIF
   images modifie le type de contenu de l'objet Web demandé.

   Une telle modification des valeurs de propriété de message peut changer le comportement
   des actions OPES effectuées ultérieurement. Le filtre de données DEVRAIT agir
   sur les règles correspondantes avant d'évaluer les règles suivantes. Plusieurs
   les règles correspondantes peuvent être déclenchées simultanément si le filtre de données peut
   déterminez à l'avance qu'il n'y a pas d'effets secondaires du
   exécution de toute règle spécifique.

   Un filtre de données PEUT évaluer les messages plusieurs fois au cours de
   gérer un flux OPES. Les points de traitement des règles PEUVENT être définis par
   noms définis administrativement. La définition de tels noms peut
   servir de sélecteur pour les règles de politique afin de déterminer l'applicabilité
   d'une règle ou d'un ensemble de règles à chaque point de traitement.

   Les rôles politiques ([5] et [6]) DEVRAIENT être utilisés lorsqu'ils contribuent à
   développement du modèle de politique OPES.

   La figure 2 exprime un flux de données de message typique entre des données
   application grand public, un processeur OPES et un fournisseur de données
   application. Il existe quatre points de traitement couramment utilisés
   identifié par les chiffres 1 à 4.


            +--------+       +-----------+       +---------+
            |        |<------|4         3|<------|         |
            | Data   |       |  OPES     |       | Data    |
            |Consumer|       | Processor |       |Provider |
            |  Appl. |------>|1         2|------>| Appl.   |
            +--------+       +-----------+       +---------+

            + -------- + + ----------- + + --------- +
            | | <------ | 4 3 | <------ | |
            | Données | | OPES | | Données |
            | Consommateur | | Processeur | | Fournisseur |
            | Appl. | ------> | 1 2 | ------> | Appl. |
            + -------- + + ----------- + + --------- +

                 Figure 2: Traitement des points d'exécution

   Tout filtre de données (PEP) ou toute implémentation administrative (PDP) DOIT
   prend en charge les quatre points de traitement des règles.

   o Rôle de traitement des demandes du consommateur de données: cela implique une demande
      traitement lorsqu'il est reçu d'une application de consommation de données.
   o Rôle de traitement des demandes du processeur OPES: cela implique une demande
      traitement avant de transmettre à l'application du fournisseur de données.
   o Rôle de gestion de la réponse du fournisseur de données: cela implique une réponse
      traitement lors de la transmission à l'application Data Consumer.
   o Rôle de gestion de la réponse du processeur OPES: cela implique une réponse
      traitement lors de la transmission à l'application Data Consumer.

4. Exigences relatives aux interfaces

   L'interface entre le système de politique et les services OPES doit
   inclure la possibilité de transmettre des informations sur l'état du système ainsi que
   Objet du message.

4.1. Exigences relatives aux liaisons de service

   Les services OPES invoqués DOIVENT pouvoir être spécifiés dans un emplacement
   mode indépendante. Autrement dit, les auteurs de règles n'ont pas besoin de savoir et
   il n'est pas nécessaire de spécifier l'instance d'un service OPES dans les règles.

   L'auteur de la règle DEVRAIT être en mesure d'identifier le service requis à
   le niveau de détail adapté à ses besoins. La règle
   l'auteur DEVRAIT être en mesure de spécifier un type de service ou de pouvoir
   spécifier tout service qui correspond à une catégorie générale de service à
   appliquée à son trafic.

   La liaison des noms de service OPES à un service spécifique PEUT être
   répartis entre le PDP et le PEP. Au fur et à mesure que les règles sont compilées et
   validés par le PDP, ils DOIVENT être résolus en un
   ensemble des installations de service OPES homogène.

   La sélection d'une instance spécifique PEUT être reportée et laissée à PEP
   pour sélectionner au moment de l'installation de la règle ou au moment de l'exécution. À
   réaliser l'interopérabilité, PEP DOIT prendre en charge la résolution d'un nom générique
   à une instance spécifique. Il est possible d'utiliser des services tels que SLP
   ou UDDI pour résoudre les noms de service génériques en un service OPES spécifique
   les instances.

   Le système de politique PEUT prendre en charge la découverte dynamique des liaisons de service.
   L'auteur de la règle peut ne pas connaître les liaisons de service spécifiques, telles que
   protocole et paramètres, lorsqu'une règle (comme spécifié sur le PDP
   Interface) est de nature générale. Les informations obligatoires requises
   DOIT être fourni par le PDP et transmis sur l'interface PEP. UNE
   une méthodologie de description de service telle que WSDL [8] DOIT être présente dans
   le système politique.

4.1.1. Variables d'environnement

   Il peut être nécessaire de définir et de soutenir un moyen de maintenir
   les informations d'état qui peuvent être utilisées à la fois dans l'évaluation des conditions et
   exécution de l'action. En fonction de l'environnement d'exécution, OPES
   les services PEUVENT avoir la liberté de définir les variables nécessaires et
   utiliser ces variables pour définir davantage leur comportement de service sans
   le support du filtre de données.

4.1.2. Conditions requises pour l'utilisation des informations d'état

   Les règles de politique PEUVENT spécifier que les informations d'état doivent être utilisées dans le cadre de
   l'évaluation des règles par rapport à un message donné dans un flux OPES.
   Ainsi, le système de politique DEVRAIT prendre en charge la maintenance de groupes qui
   peut être utilisé pour évaluer les conditions de règle. Appartenance à de tels groupes
   peut être utilisé comme déclencheur d'action.

   Par exemple, un service de blocage de site autorisé peut conclure que
   un utilisateur particulier ne devrait pas être autorisé à accéder à un certain site Web
   site. Plutôt que d'appeler le service pour chaque demande envoyée par
   un utilisateur, une règle peut être créée pour déterminer si un utilisateur est
   membre d'utilisateurs bloqués et si un site demandé est membre de
   sites bloqués, puis appelez un service de blocage local pour renvoyer un
   message approprié à l'utilisateur.

4.1.3. Conditions requises pour la transmission d'informations entre les services

   Les variables d'environnement peuvent être utilisées pour transmettre des informations d'état entre
   prestations de service. Par exemple, analyse de la demande ou modifications de
   la demande peut devoir être capturée en tant qu'informations d'état qui peuvent être
   transmis à d'autres services sur le chemin de la requête ou à des services sur le
   réponse (s) associée (s) à cette demande.

   Dans le PEP, il DEVRAIT y avoir des dispositions pour permettre la configuration de variables
   lors du retour d'un appel de service et en passant des variables à d'autres
   appelés services basés sur la politique.

4.2. Conditions requises pour la gestion des règles et des règles

   Cette section décrit les conditions requises pour la gestion des règles. le
   les règles sont divisées en deux groupes. Certaines règles sont fournies par le
   application de consommateur de données, et d'autres règles sont fournies par les données
   application du fournisseur.

4.2.1. Exigences pour les fournisseurs de règles

   Les exigences pour les fournisseurs de règles sont les suivantes:

   o Les fournisseurs de règles DOIVENT être authentifiés et autorisés pour les règles qui
      s'appliquent à leur rôle de réseau.
   o Les fournisseurs de règles NE DOIVENT PAS être en mesure de spécifier des règles qui NE
      dans leur champ d’autorité.
   o Les fournisseurs de règles DEVRAIENT être en mesure de spécifier uniquement ce qui est nécessaire pour
      leurs services.
   o La compilation de règles provenant de différentes sources NE DOIT PAS conduire à
      exécution de règles contradictoires.
   o La résolution de tels conflits de règles est hors de portée.

   o Les règles sont supposées statiques et appliquées au réseau actuel
      Etat.

4.2.2. Exigences relatives aux formats de règles et aux protocoles

   Il est souhaitable de choisir des technologies standard comme XML pour spécifier
   le format de la langue des règles.

   Les règles doivent être envoyées par les auteurs des règles à OPES
   serveur d'administration pour l'autorisation de service, la validation des règles et
   compilation. Les mécanismes pour y parvenir sont hors du champ d'application
   travail actuel.

   Une fois les règles autorisées, validées et compilées par le
   serveur administratif, les règles doivent être envoyées à l'OPES
   processeur. Les mécanismes pour y parvenir sont hors du champ d'application
   travail actuel.

4.2.3. Conditions requises pour les conditions de règle

   Les conditions de règle DOIVENT être mises en correspondance avec les valeurs d'attribut du
   protocole encapsulé ainsi que les valeurs des variables d'environnement.
   Les valeurs d'attribut du protocole encapsulé incluent l'en-tête de protocole
   valeurs et éventuellement aussi les valeurs du corps du protocole.

   Certains services OPES peuvent devoir être appelés pour toutes les demandes des utilisateurs ou
   réponses du serveur, telles que les services avec fonctionnalité de journalisation, pour
   exemple. Le système de règles DEVRAIT permettre des règles inconditionnelles plutôt
   que de demander aux auteurs de règles de spécifier des conditions de règle
   toujours vrai.

4.2.4. Conditions requises pour les actions de règle

   Le système de règles DOIT permettre la spécification d'actions de règles qui
   sont déclenchés si les conditions d'une règle sont remplies. Règles concordantes
   conduisent généralement à l'invocation de services locaux ou distants. Règle
   les actions DOIVENT identifier le service OPES qui doit être exécuté pour le
   demande ou réponse de message en cours.

   Les actions de règle PEUVENT contenir des paramètres d'exécution qui peuvent être utilisés pour
   contrôler le comportement d'un service OPES. Si spécifié, ces
   les paramètres DOIVENT être passés au service OPES exécuté.

4.3. Conditions requises pour l'expression de stratégie

   Les processeurs OPES DOIVENT appliquer les exigences de politique définies par les données
   consommateurs et / ou éditeurs de données conformément à l'architecture
   [1] et ce document. Ils ne peuvent pas faire cela de manière cohérente à moins qu'il
   sont une sémantique et une représentation sans ambiguïté des éléments de données
   mentionné dans la politique. Par exemple, ce document mentionne
   protection des informations relatives à l '«identité» et au «profil» des utilisateurs. Si un utilisateur
   précise que son identité ne doit pas être partagée avec d'autres OPES
   domaines de confiance administratifs, et découvre plus tard que sa famille
   nom a été partagé, il pourrait se plaindre. Si on lui disait que
   "les noms de famille ne sont pas considérés comme des" identités "par ce site",
   pense probablement qu’il avait matière à se plaindre. Ou, on pourrait lui dire
   que lorsqu'il a sélectionné "ne pas partager d'identité" sur un formulaire Web proposé
   par le fournisseur de services OPES, que cela ne couvrait que son nom de connexion,
   et qu'une autre partie du formulaire devait être remplie pour protéger
   le nom de famille. Une autre panne peut se produire si la configuration
   les informations fournies par un tel formulaire Web sont traduites en
   les éléments de configuration donnés à un processeur OPES, et ceux
   les éléments de configuration sont difficiles à
   se traduisent par l'application des politiques. Les éléments de données peuvent avoir
   noms confus ou être divisés en groupes difficiles à
   se rapportent les uns aux autres.

   Les exemples illustrent pourquoi la politique OPES DOIT avoir des définitions de
   éléments de données, leurs relations et leur relation avec
   mise en vigueur. Cette sémantique des éléments essentiels ne nécessite pas
   protocole distinct, mais ils DOIVENT être approuvés par tous les services OPES
   fournisseurs, et les utilisateurs des services OPES DOIVENT être assurés qu'ils
   ont la possibilité de connaître leurs paramètres, de les modifier si le
   la politique du fournisseur de services autorise les changements et
   l'assurance qu'ils sont appliqués avec des interprétations raisonnables.

   Les exigences relatives aux éléments de données de politique dans la spécification OPES
   n'ont pas à être tout compris, mais ils DOIVENT couvrir l'ensemble minimal
   des éléments qui permettent les politiques qui protègent les données de fin
   utilisateurs et éditeurs.

5. Authentification des mandants et autorisation des services

   Cette section considère l'autorisation et l'authentification d'OPES
   prestations de service.

5.1. Utilisateurs finaux, éditeurs et autres considérations

5.1.1. Considérations pour les utilisateurs finaux

   Une règle OPES détermine les attributs du trafic qui déclencheront le
   application des services OPES. L'auteur du service peut fournir
   règles, mais l'auteur ne peut pas fournir la partie nécessaire de la règle
   condition préalable qui détermine quels utilisateurs du réseau disposeront de l'OPES
   les services demandés. Cette section explique comment les utilisateurs
   identifiées dans les conditions préalables de la règle, et comment les utilisateurs peuvent sélectionner et
   désélectionner les services OPES pour leur trafic, comment un service OPES
   le fournisseur DEVRAIT identifier les utilisateurs et comment ils déterminent si
   de ne pas ajouter leur sélection de service à un point d'application OPES.

   Un fournisseur de services OPES DOIT satisfaire à ces exigences majeures:

   o Permettre à tous les utilisateurs de demander l'ajout, la suppression ou le blocage d'OPES
      services pour leur trafic (blocage signifie "ne pas utiliser
      service pour mon trafic ").
   o Empêcher les utilisateurs non approuvés d'interférer avec les services OPES
      avec le trafic des autres utilisateurs.
   o Permettre aux utilisateurs de voir leurs profils de service OPES et les informer
      changements.
   o Tenez un journal de toutes les activités du profil à des fins d'audit.
   o Adhérez à une politique de confidentialité protégeant les profils des utilisateurs.

   L'administrateur du PDP est une partie de confiance et peut définir la politique
   pour les individus ou les groupes utilisant la communication hors bande et
   fichiers de configuration. Cependant, les utilisateurs DOIVENT toujours pouvoir interroger le
   PDP afin d'apprendre quelles règles s'appliquent à leur trafic.

   Les règles peuvent être déposées dans le PDP sans condition préalable relative à
   utilisateurs du réseau. C'est ainsi que les règles sont empaquetées avec un OPES
   service lorsqu'il est livré pour installation. Le PDP est
   responsable de lier les identités aux règles et de les transmettre
   au PEP. L'identité utilisée par le PDP pour les décisions de politique DOIT
   être strictement mappé à l'identité utilisée par le PEP. Ainsi, si un utilisateur
   passe par une procédure d'identification et d'authentification avec le
   PDP et est connu sous l'identité «A», et si le PEP utilise des adresses IP
   pour les identités, alors le PDP DOIT fournir au PEP une liaison
   entre "A" et l'adresse IP actuelle de A.

5.1.2. Considérations relatives aux sites de publication

   Un fournisseur de services OPES agissant pour le compte de différents éditeurs
   les sites DEVRAIENT garder toutes les considérations ci-dessus à l'esprit lorsque
   mise en place d'un site OPES. Parce que chaque site de publication peut être
   représenté par une seule identité, l'authentification et
   les bases de données d'autorisation peuvent être plus faciles à gérer pour le PEP.

5.1.3. autres considérations

   Une authentification peut être nécessaire entre les PDP et les PEP, les PEP et
   serveurs d'appel, PEP et autres PEP, et serveurs d'appel et autres
   serveurs d'appel, à des fins de validation des politiques de confidentialité. Dans tous
   cas où les données utilisateur ou le trafic franchissent les limites du domaine de confiance, le
   le domaine de confiance d'origine DEVRAIT avoir une politique décrivant quel autre
   les domaines sont approuvés et il DEVRAIT authentifier les domaines et leurs
   politiques avant de transmettre des informations.

5.2. Authentification

   Lorsqu'un individu sélectionne (ou désélectionne) un service OPES, le
   l'individu DOIT être authentifié par le fournisseur de service OPES. Ce
   signifie qu'une liaison entre le canal de communication de l'utilisateur et un
   l'identité connue du fournisseur de services est établie de manière sécurisée.
   Cela DEVRAIT être fait en utilisant une méthode d'authentification forte avec un
   certificat de clé publique pour l'utilisateur; cela sera utile dans
   résoudre les différends ultérieurs. Il est recommandé que le service
   Le fournisseur tient un journal de toutes les demandes de services OPES. Le service
   le fournisseur DEVRAIT utiliser des certificats de clé publique pour authentifier les réponses
   aux demandes.

   Le fournisseur de services peut avoir des utilisateurs de confiance qui, par
   un contrat implicite peut affecter, supprimer ou bloquer des services OPES pour
   utilisateurs particuliers. Les utilisateurs de confiance DOIVENT être authentifiés avant
   être autorisé à prendre des mesures qui modifieront la base de politiques, et
   ainsi, les actions des PEP.

   En raison de la sensibilité des profils utilisateur, l'interface PEP
   entre le PEP et le PDP DOIT utiliser un protocole de transport sécurisé.
   Les PEP DOIVENT adhérer aux préférences de confidentialité des utilisateurs.

   Lorsqu'un fournisseur de services OPES accepte un service OPES, il DOIT
   un nom unique pour le service fourni par l'entité qui publie le
   un service. Les utilisateurs PEUVENT se référer au nom unique lorsqu'ils demandent un
   un service. Le nom unique DOIT être utilisé lors de la notification aux utilisateurs de
   leurs profils de service. Les PEP DOIVENT être conscients du nom unique de
   chaque service accessible depuis leur domaine. Il DOIT y avoir un
   liaison cryptographique entre le nom unique et l'entité

   responsable du comportement fonctionnel du service, c'est-à-dire s'il
   est un service de traduction en langage humain, puis le nom de l'entreprise
   qui a écrit le logiciel DEVRAIT être lié au nom unique.

5.3. Autorisation

   En plus de demander ou de mettre fin à des services spécifiques, les utilisateurs PEUVENT
   bloquer des services particuliers, indiquant que les services ne doivent pas
   appliquée à leur trafic. La directive "block all OPES" DOIT être
   pris en charge par utilisateur.

   Une réponse à une demande de service OPES peut être positive ou
   négatif. Les raisons d'une réponse négative incluent "service inconnu"
   ou "service refusé par la politique PDP". Les réponses positives DEVRAIENT inclure
   l'identité du demandeur et du service et le type de
   demande.

   Comme décrit dans l'architecture OPES [1], les demandes de services OPES
   proviennent de l'utilisateur final ou du domaine de l'éditeur. Le PDP
   fonde sa décision d'autorisation sur le demandeur et le domaine.
   Dans certains cas, la décision peut être compliquée.

   o L'utilisateur final a bloqué un service, mais un utilisateur de confiance du PDP
      veut qu'il soit appliqué de toute façon. Dans ce cas, l'utilisateur final DEVRAIT
      prévalent, sauf s'il existe des raisons de sécurité ou juridiques pour le laisser en
      endroit.
   o L'éditeur et l'utilisateur final appartiennent au même domaine. Si la
      l'éditeur et l'utilisateur final sont tous deux clients d'un PDP, peuvent-ils
      demandes qui affectent le traitement de l'autre? Dans ce cas, le
      PDP DOIT avoir des règles de politique nommant les identités qui sont autorisées
      pour fixer de telles règles.
   o L'éditeur demande un service pour un utilisateur final. Dans ce cas,
      où le PDP et le PEP sont dans le dossier administratif de l'éditeur
      domaine, l'éditeur dispose d'un moyen d'identifier l'utilisateur final et
      son trafic, et le PDP DOIT permettre au PEP d'appliquer le
      politique. Ceci est autorisé, mais le PDP DOIT utiliser des méthodes fortes pour
      identifier l'utilisateur et son trafic. L'utilisateur DOIT être en mesure de
      demander et recevoir des informations sur le profil de service qu'un
      le site de l'éditeur garde sur lui.
   o L'utilisateur final demande un service spécifique à l'identité d'un éditeur
      (par exemple, nfl.com), mais l'éditeur interdit le service (par exemple,
      via un en-tête d'application "NO OPES"). Comme dans le cas ci-dessus,
      l'éditeur DOIT pouvoir demander et recevoir son profil
      les informations qu'un utilisateur conserve sur un éditeur.

   En général, le PDP DEVRAIT conserver sa base de politique de manière à
   rend la procédure de décision pour tous les cas facile à comprendre.

5.4. Intégrité et cryptage

5.4.1. Intégrité et confidentialité de l'authentification et des demandes /

        Réponses pour le service

   Les demandes et réponses DEVRAIENT être liées cryptographiquement au
   identités du demandeur et du répondeur, et les messages DEVRAIENT
   PAS être modifiable sans détection. Un numérique basé sur des certificats
   la signature est fortement recommandée dans le cadre de l'authentification
   processus. Une liaison entre la demande et la réponse DEVRAIT être
   établie à l'aide d'un moyen cryptographique bien fondé, pour montrer que
   la réponse est faite en réponse à une demande spécifique.

5.4.2. Intégrité et confidentialité du contenu de l'application

   Comme indiqué par le PEP, le contenu sera transformé en totalité ou en
   partie par les services OPES. Cela signifie que la cryptographie de bout en bout
   les protections ne peuvent pas être utilisées. Ceci est probablement acceptable pour le vaste
   majorité du trafic, mais dans les cas où une forme de contenu moindre
   une protection est souhaitable, des protections saut par saut peuvent être utilisées à la place.
   Les exigences pour de telles protections sont:

   o L'intégrité utilisant des secrets partagés DOIT être utilisée entre tous les traitements
      points, de bout en bout (c'est-à-dire que les deux extrémités d'un "saut" DOIVENT partager un
      secret, mais le secret peut être différent entre les "sauts"). le
      les points de traitement incluent les serveurs d'appel.
   o Le cryptage peut être demandé séparément, avec le même secret
      l'exigence de partage entre "sauts". Sur demande, cryptage
      s'applique à tous les points de traitement, y compris les serveurs d'appel.
   o Le signal d'intégrité (et éventuellement de cryptage) DOIT
      provenir du demandeur (auquel cas il est appliqué
      à la réponse) ou le répondeur (auquel cas il couvre
      seulement la réponse).
   o Les secrets partagés DOIVENT être uniques (à l'intérieur d'un très
      certitude probabiliste) pour chaque paire demandeur / répondeur. Ce
      aide à protéger la confidentialité des données des utilisateurs finaux contre les attaques internes
      ou des erreurs de configuration lors de son transit sur le réseau du fournisseur.

5.5. Intimité

   Le PDP DOIT avoir une politique de confidentialité concernant les données OPES telles que l'utilisateur
   profils de services. Les utilisateurs DOIVENT pouvoir limiter la promulgation
   de leurs données de profil et de leurs identités.

   Les limitations prises en charge DOIVENT inclure:

   o La capacité d'empêcher l'identité d'être donnée à l'appel
      les serveurs.

   o La capacité d'empêcher le partage des informations de profil.
   o La possibilité d'empêcher les données de trafic d'être envoyées à l'accroche
      serveurs gérés par des tiers.
   o La capacité d'empêcher le trafic provenant de sites particuliers d'être
      donné aux serveurs d'appel OPES.

   Lorsqu'un service OPES est fourni par un tiers, il DOIT avoir un
   politique de confidentialité et s'identifier en amont et en aval
   parties, en leur indiquant comment accéder à sa politique de confidentialité. Un mécanisme
   est nécessaire pour spécifier ces préférences et un protocole de distribution
   (voir section 3.3).

6. Considérations relatives à la sécurité

   Ce document traite de la politique, de l'autorisation et de l'application
   exigences d'OPES. Dans [3] plusieurs problèmes de sécurité et de confidentialité
   liés aux services OPES sont discutés.

7. Références

7.1. Références normatives

   [1] Barbir, A., Penno, R., Chen, R., Hofmann, M. et H. Orman, "An
        Architecture pour Open Pluggable Edge Services (OPES) ", RFC 3835,
        Août 2004.

   [2] Floyd, S. et L. Daigle, "IAB Architectural and Policy
        Considérations relatives aux services Open Pluggable Edge ", RFC 3238,
        Janvier 2002.

   [3] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M. et H.
        Orman, "Menaces et risques de sécurité pour Open Pluggable Edge
        Services (OPES) », RFC 3837, août 2004.

   [4] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer l'exigence
        Niveaux », BCP 14, RFC 2119, mars 1997.

   [5] Moore, B., Ellesson, E., Strassner, J. et A. Westerinen,
        "Policy Core Information Model - Version 1 Specification", RFC
        3060, février 2001.

7.2. Références informatives

   [6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. et S.
        Waldbusser, "Terminologie pour la gestion basée sur des politiques", RFC 3198,
        Novembre 2001.

   [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P., et T. Berners-Lee, "Hypertext Transfer Protocol -
        HTTP / 1.1 ", RFC 2616, juin 1999.

   [8] Christensen et al., Web Services Description Language (WSDL)
        1.1, W3C Note 15 mars 2001, http://www.w3.org/TR/wsdl

8. Remerciements

   Un grand merci à Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M.
   Condry (Intel), Randy Presuhn (Mindspring) et B. Srinivas (Nokia).

9. Adresses des auteurs

   Abbie Barbir
   Nortel Networks
   3500 avenue Carling
   Nepean, Ontario K2H 8E9
   Canada
   Téléphone: +1613763 5229
   Courriel: abbieb@nortelnetworks.com

   Oskar Batuner
   Consultant
   Courriel: batuner@attbi.com

   André Beck
   Technologies Lucent
   101, chemin Crawfords Corner
   Holmdel, NJ 07733
   Etats-Unis
   COURRIEL: abeck@bell-labs.com

   Tat Chan
   Nokia
   Route 5 Wayside
   Burlington, MA 01803
   Etats-Unis
   Courriel: Tat.Chan@nokia.com

   Hilarie Orman
   Développement de Purple Streak
   COURRIEL: ho@alum.mit.edu

10. Déclaration de droit d'auteur complète

   Copyright (C) L'Internet Society (2004). Ce document est sujet
   aux droits, licences et restrictions contenus dans BCP 78, et
   sauf indication contraire, les auteurs conservent tous leurs droits.

   Ce document et les informations qu'il contient sont fournis sur un
   "TEL QUEL" et LE CONTRIBUTEUR, L'ORGANISATION QU'IL / ELLE REPRÉSENTE
   OU EST SPONSORISÉ PAR (LE CAS ÉCHÉANT), LA SOCIÉTÉ INTERNET ET INTERNET
   GÉNIE TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE,
   INCLUANT, MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION
   LES INFORMATIONS CI-DESSUS NE VIOLENT AUCUN DROIT OU TOUT DROIT IMPLICITE
   GARANTIES DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.

Propriété intellectuelle

   L'IETF ne prend aucune position concernant la validité ou la portée de tout
   Droits de propriété intellectuelle ou autres droits susceptibles d'être revendiqués
   concernent la mise en œuvre ou l'utilisation de la technologie décrite dans
   ce document ou la mesure dans laquelle une licence en vertu de ces droits
   peut ou peut ne pas être disponible; il ne signifie pas non plus qu'il a
   fait tout effort indépendant pour identifier ces droits. Information
   sur les procédures relatives aux droits dans les documents RFC peuvent être
   trouvé dans BCP 78 et BCP 79.

   Copies des divulgations de DPI faites au Secrétariat de l'IETF et
   les assurances de licences à mettre à disposition, ou le résultat d'un
   tentative faite pour obtenir une licence générale ou une autorisation pour l'utilisation de
   ces droits de propriété par les exécutants ou les utilisateurs de ce
   Les spécifications peuvent être obtenues auprès du référentiel IPR en ligne de l'IETF à l'adresse
   http://www.ietf.org/ipr.

   L'IETF invite toute partie intéressée à porter à son attention toute
   droits d'auteur, brevets ou demandes de brevets, ou autres
   les droits qui peuvent couvrir la technologie qui peut être nécessaire pour mettre en œuvre
   cette norme. Veuillez adresser les informations à l'IETF à l'ietf-
   ipr@ietf.org.

Reconnaissance

   Le financement de la fonction RFC Editor est actuellement assuré par le
   Société Internet.

Balisage HTML produit par rfcmarkup 1.129d, disponible sur https://tools.ietf.org/tools/rfcmarkup/