Groupe de travail Réseau	H. Tschofenig, éd., Nokia Siemens Networks	
Request for Comments : 5580	F. Adrangi, Intel	
Catégorie : Sur la voie de la normalisation	M. Jones, Bridgewater	
	A. Lior, Bridgewater	
	B. Aboba, Microsoft Corporation	
Traduction Claude Brière de L'Isle	août 2009	

Transport des objets de localisation dans RADIUS et Diameter

Résumé
Le présent document décrit les procédures pour porter les informations de propriété de réseau d'accès et de localisation sur la base de formats de localisation civile et géospatiale dans le service d'authentification distante d'utilisateur appelant (RADIUS, Remote Authentication Dial-In User Service) et Diameter.

La distribution des informations de localisation est une tâche sensible pour la confidentialité. Les mécanismes pour préserver la confidentialité de l'utilisateur sont importants et sont traités dans le présent document.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 
Table des matières
1. Introduction	2
2. Terminologie	2
3. Méthodes de livraison pour les informations de localisation	2
3.1 Livraison de localisation fondée sur des accords hors bande	3
3.2 Livraison de localisation fondée sur une demande initiale	3
3.3 Livraison de localisation fondée sur une demande à mi-session	4
3.4 Livraison de localisation dans les messages de comptabilité	7
4. Attributs	7
4.1 Attribut Nom d'opérateur	7
4.2 Attribut Informations de localisation	9
4.3 Attribut Données de localisation	10
4.4 Attribut Basic-Location-Policy-Rules	11
4.5 Attribut Extended-Location-Policy-Rules	12
4.6 Attribut Location-Capable	13
4.7 Attribut Requested-Location-Info	13
5. Tableau des attributs	16
6. Interopérabilité Diameter RADIUS	16
7. Considérations sur la sécurité	17
7.1 Sécurité de communication	17
7.2 Considérations de confidentialité	18
7.3 Informations d'identité et de localisation	19
8. Considérations relatives à l'IANA	20
8.1 Nouveau registre : Identifiant d'espace de noms d'opérateur	20
8.2 Nouveau registré : Profils de localisation	21
8.3 Nouveau registré : Attribut Location-Capable	21
8.4 Nouveau registre : Types d'entité	21
8.5 Nouveau registre : Fanions de confidentialité	22
8.6 Nouveau registre : Attribut Requested-Location-Info	22
9. Remerciements	22
10. Références	23
10.1 Références normatives	23
10.2 Références pour information	23
Appendice A. Confrontation aux exigences de GEOPRIV	25
A.1 Distribution des informations de localisation au réseau de rattachement de l'utilisateur	25
A.2 Distribution des informations de localisation au réseau visité	25
A.3 Correspondance aux exigences	26
Adresse des auteurs	29

 	1.	Introduction

Le présent document définit les attributs qui dans RADIUS et Diameter peuvent être utilisés pour porter les informations relatives à la localisation au sein des échanges d'authentification et de comptabilité.

Les informations de localisation peuvent être utiles dans un certain nombre de scénarios. Des réseaux sans fil (y compris des LAN sans fil) sont déployés dans des lieux publics comme des aéroports, des hôtels, des centres commerciaux, et des cafés par divers ensembles d'opérateurs comme des opérateurs de réseaux cellulaires, des fournisseurs de service Internet sans fil (WISP, Wireless Internet Service Provider) et des opérateurs de haut débit fixe. Dans ces situations, le réseau de rattachement peut avoir besoin de connaître la localisation de l'utilisateur afin de permettre une facturation, une autorisation, ou autres services, qui tiennent compte de la localisation. Les informations de localisation peuvent aussi se révéler utiles dans d'autres situations (comme les réseaux filaires) où les informations de propriété de l'opérateur du réseau et de localisation peuvent être nécessaires au réseau de rattachement.

Afin de préserver la confidentialité de l'utilisateur, les informations de localisation doivent être protégées contre l'accès et la distribution non autorisés. Les exigences pour l'accès aux informations de localisation sont définies dans la [RFC3693]. Le modèle inclut un générateur de localisation (LG, Location Generator) qui crée les informations de localisation, un serveur de localisation (LS, Location Server) qui autorise l'accès aux informations de localisation, un receveur de localisation (LR, Location Recipient) qui demande et reçoit l'information, et un réglementeur (RM, Rule Maker) fournissant les politiques d'autorisation au LS, qui applique les politiques de contrôle d'accès aux demandes d'informations de localisation. À l'Appendice A, les exigences d'un GEOPRIV qui utilise le protocole de la [RFC3693] sont comparées à la fonction fournie dans le présent document.

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

La terminologie spécifique de RADIUS est empruntée aux [RFC2865] et [RFC2866].

La terminologie relative aux questions de confidentialité, aux informations de localisation, et aux règles de politique d'autorisation est tirée de la [RFC3693].

 	3.	Méthodes de livraison pour les informations de localisation

Les échanges suivants montrent comment les informations de localisation sont convoyées dans RADIUS. En décrivant les scénarios d'usage, on suppose que les politiques de confidentialité permettent que la localisation soit portée dans RADIUS ; cependant, comme on le note à la Section 6, des échanges similaires peuvent aussi avoir lieu dans Diameter. Les questions de confidentialité sont discutées au paragraphe 7.2.

 	3.1	Livraison de localisation fondée sur des accords hors bande
La Figure 1 montre un exemple de flux de messages pour livrer des informations de localisation durant la procédure d'authentification et d'autorisation de l'accès au réseau. Sur une demande d'authentification de réseau provenant d'un client de réseau d'accès, le serveur d'accès réseau (NAS, Network Access Server) soumet un message RADIUS Demande d'accès qui contient des attributs d'informations de localisation parmi les autres attributs exigés. Dans ce scénario, les informations de localisation sont rattachées au message Demande d'accès sans une demande explicite de la part du serveur RADIUS. Noter que cette approche avec un accord préalable entre le client RADIUS et le serveur RADIUS est seulement applicable dans certains environnements, comme dans les situations où le client et le serveur RADIUS sont dans le même domaine administratif. L'attribut Basic-Location-Policy-Rules (règles de base de politique de localisation) est rempli sur la base des valeurs par défaut décrites au paragraphe 4.4, sauf si il a été explicitement configuré autrement.

    +-----------+           +---------+                      +---------+
    |           |           | Serveur |                      |  Serveur|
    |Utilisateur|           | d'accès |                      |  RADIUS |
    |           |           | réseau  |                      |         |
    +-----------+           +---------+                      +---------+
        |                       |                                 |
        | Début de la phase     |                                 |
        | d'authentification    |                                 |
        |---------------------->|                                 |
        |                       |                                 |
        |                       | Demande d'accès                 |
        |                       | + Informations de localisation  |
        |                       | + Données de localisation       |
        |                       | + Règles politique localisation |
        |                       | + Nom de l'opérateur            |
        |                       |-------------------------------->|
        |                       |                                 |
        |                       | Accès accepté                   |
        |                       |<--------------------------------|
        | Authentification      |                                 |
        | réussie               |                                 |
        |<----------------------|                                 |
        |                       |                                 |

Figure 1 : Livraison de localisation fondée sur un accord hors bande

 	3.2	Livraison de localisation fondée sur une demande initiale
Si le client RADIUS fournit un attribut Location-Capable dans la demande d'accès, le serveur RADIUS PEUT alors demander des informations de localisation au client RADIUS si il exige ces informations pour l'autorisation et si les informations de localisation n'ont pas été fournies dans la demande d'accès. Cet échange est montré à la Figure 2. L'inclusion de l'attribut Location-Capable dans le message Demande d'accès indique que le NAS est capable de fournir des données de localisation en réponse à un défi d'accès. Le message Défi d'accès suivant envoyé du serveur RADIUS au NAS donne une indication concernant le type des attributs d'informations de localisation désirés. Le NAS traite les attributs Basic-Location-Policy-Rules et Extended-Location-Policy-Rules comme des données opaques (par exemple, il fait écho à ces règles fournies par le serveur au sein du défi d'accès en retour à la demande d'accès). Dans le flux de messages montré, les attributs de localisation sont alors fournis dans le message Demande d'accès suivant. Quand elle évalue ce message de demande d'accès, la procédure d'autorisation au serveur RADIUS pourrait être fondée sur un certain nombre de critères, incluant les nouveaux attributs définis mentionnés à la Section 4.

   +-----------+           +---------+                       +---------+
   |           |           | Serveur |                       | Serveur |
   |Utilisateur|           | d'accès |                       |  RADIUS |
   |           |           | réseau  |                       |         |
   +-----------+           +---------+                       +---------+
       |                       |                                  |
       | Début de la phase     |                                  |
       | d'authentification    |                                  |
       |---------------------->|                                  |
       |                       |                                  |
       |                       | Demande d'accès                  |
       |                       | + Location-Capable               |
       |                       |--------------------------------->|
       |                       |                                  |
       |                       | Défi d'accès                     |
       |                       |  + Basic-Location-Policy-Rules   |
       |                       |  + Extended-Location-Policy-Rules|
       |                       |  + Requested-Location-Info       |
       |                       |<---------------------------------|
       |                       |                                  |
       |                       | Demande d'accès                  |
       |                       |  + Informations de localisation  |
       |                       |  + Données de localisation       |
       |                       |  + Basic-Location-Policy-Rules   |
       |                       |  + Extended-Location-Policy-Rules|
       |                       |--------------------------------->|
       |                       |                                  |
       :                       :                                  :
       :       Plusieurs échanges de protocole pour effectuer     :
       : l'authentification, l'échange de clés, et l'autorisation :
       :                  ...à suivre...                          :
       :                       :                                  :
       |                       |                                  |
       |                       | Accès accepté                    |
       |                       |<---------------------------------|
       | Authentification      |                                  |
       | réussie               |                                  |
       |<----------------------|                                  |
       |                       |                                  |

Figure 2 : Livraison de localisation fondée sur une demande initiale

 	3.3	Livraison de localisation fondée sur une demande à mi-session
La méthode de livraison de localisation de mi-session à la demande utilise le message Demande de changement d'autorisation (CoA-Request, Change-of-Authorization Request) et le message accusé de réception négatif de changement d'autorisation (CoA-NAK, CoA-Negative Acknowledgement) définis dans la [RFC5176]. À tout moment durant la session, le client d'autorisation dynamique PEUT envoyer une CoA-Request contenant des attributs d'identification de session au NAS (c'est-à-dire, au serveur d'autorisation dynamique).

Afin de permettre la méthode de livraison de localisation de mi-session à la demande, le serveur RADIUS DOIT retourner une instance de l'attribut Requested-Location-Info (informations de localisation demandées) avec le fanion "FUTURE_REQUESTS" établi et des instances des attributs Basic-Location-Policy-Rules et Extended-Location-Policy-Rules dans le message Accès accepté pour la session. À réception d'un message CoA-Request contenant un attribut Type de service de valeur "Autorisation seule" pour la même session, le NAS DOIT inclure des informations de localisation et faire écho aux attributs Basic-Location-Policy-Rules et Extended-Location-Policy-Rules précédemment reçus dans le message Demande d'accès suivant.

À réception du message Demande d'accès contenant l'attribut Type de service avec une valeur de Autorisation seule provenant du NAS, le serveur RADIUS répond avec un message Accès accepté ou Accès rejeté.

L'utilisation de l'autorisation dynamique de la [RFC5176] est nécessaire quand des informations de localisation sont nécessaires à la demande et ne peuvent pas être obtenues en temps utile des informations comptables.

La Figure 3 montre graphiquement l'approche décrite ci-dessus :

  +---------------+                        +---------------+    +-------+
  | Serveur/NAS   |                        | Client        |    |Serveur|
  |d'autorisation |                        |d'autorisation |    |RADIUS |
  | dynamique     |                        | dynamique     |    |       |
  +---------------+                        +---------------+    +-------+
      |                                             |              |
      |  Demande d'accès                            |              |
      |  + Location-Capable                         |              |
      |----------------------------------------------------------->|
      |                                             |              |
      |  Défi d'accès                               |              |
      |   + Basic-Location-Policy-Rules             |              |
      |   + Extended-Location-Policy-Rules          |              |
      |   + Requested-Location-Info                 |              |
      |<-----------------------------------------------------------|
      |                                             |              |
      |  Demande d'accès                            |              |
      |   + Informations de localisation            |              |
      |   + Données de localisation                 |              |
      |   + Basic-Location-Policy-Rules             |              |
      |   + Extended-Location-Policy-Rules          |              |
      |----------------------------------------------------------->|
      |                                             |              |
      :                                             |              :
      :       Plusieurs échanges de protocole pour effectuer       :
      : l'authentification, l'échange de clés, et l'autorisation   :
      :                  ...à suivre...                            :
      |                                             |              |
      |  Accès accepté                              |              |
      |      + Requested-Location-Info              |              |
               (FUTURE_REQUESTS,...)                |              |
      |      + Basic-Location-Policy-Rules          |              |
      |      + Extended-Location-Policy-Rules       |              |
      |<-----------------------------------------------------------|
      |                                             |              |
      :                                             :              :
      :          <<quelques temps plus tard>>       :              :
      :                                             :              :
      |                                             |              |
      | CoA + Type de service "Autorise seulement"  |              |
      |     + État                                  |              |
      |<--------------------------------------------|              |
      |                                             |              |
      | CoA NAK + Type service "Autorise seulement" |              |
      |         + État                              |              |
      |   + Cause d'erreur "Initiée par la demande" |              |
      |-------------------------------------------->|              |
      |                                             |              |
      |  Demande d'accès                            |              |
      |          + Type service "Autorise seulement"|              |
      |          + État                             |              |
      |          + Informations de localisation     |              |
      |          + Données de localisation          |              |
      |          + Basic-Location-Policy-Rules      |              |
      |          + Extended-Location-Policy-Rules   |              |
      |----------------------------------------------------------->|
      |  Accès accepté                              |              |
      |<-----------------------------------------------------------|
      |                                             |              |

Figure 3 : Livraison de localisation fondée sur CoA avec type de service "Autorise seulement'

Quand le client d'autorisation dynamique veut changer les valeurs des informations de localisation demandées, ou régler les valeurs des informations de localisation demandées pour la première fois, il peut le faire sans déclencher une réautorisation.  En supposant que le NAS a précédemment envoyé une demande d'accès contenant un attribut Location-Capable, le client  d'autorisation dynamique (DAC) peut envoyer une CoA-Request au NAS sans attribut Type de service, mais inclure les identifiants de NAS et de session conformément à la [RFC5176] et les attributs Requested-Location-Info, Basic-Location-Policy-Rules, et Extended-Location-Policy-Rules. Les attributs Requested-Location-Info, Basic-Location-Policy-Rules, et Extended-Location-Policy-Rules NE DOIVENT PAS être utilisés pour l'identification de session.

La Figure 4 montre graphiquement cette approche.

  +---------------+                        +---------------+    +-------+
  | Serveur/NAS   |                        | Client        |    |Serveur|
  |d'autorisation |                        |d'autorisation |    |RADIUS |
  | dynamique     |                        | dynamique     |    |       |
  +---------------+                        +---------------+    +-------+
      |                                             |              |
      |  Demande d'accès                            |              |
      |  + Location-Capable                         |              |
      |----------------------------------------------------------->|
      |                                             |              |
      |  Défi d'accès                               |              |
      |   + Basic-Location-Policy-Rules             |              |
      |   + Extended-Location-Policy-Rules          |              |
      |   + Requested-Location-Info                 |              |
      |<-----------------------------------------------------------|
      |                                             |              |
      |  Demande d'accès                            |              |
      |   + Informations de localisation            |              |
      |   + Données de localisation                 |              |
      |   + Basic-Location-Policy-Rules             |              |
      |   + Extended-Location-Policy-Rules          |              |
      |----------------------------------------------------------->|
      |                                             |              |
      |                                             |              |
      :                                             |              :
      :       Plusieurs échanges de protocole pour effectuer       :
      : l'authentification, l'échange de clés, et l'autorisation   :
      :                  ...à suivre...                            :
      |                                             |              |
      |                                             |              |
      |  Accès accepté                              |              |
      |      + Requested-Location-Info              |              |
      |      + Basic-Location-Policy-Rules          |              |
      |      + Extended-Location-Policy-Rules       |              |
      |<-----------------------------------------------------------|
      |                                             |              |
      :                                             :              :
      :          <<quelques temps plus tard>>       :              :
      :                                             :              :
      |                                             |              |
      |  CoA                                        |              |
      |      + Requested-Location-Info              |              |
      |      + Basic-Location-Policy-Rules          |              |
      |      + Extended-Location-Policy-Rules       |              |
      |<--------------------------------------------|              |
      |                                             |              |
      |  CoA ACK                                    |              |
      |-------------------------------------------->|              |
      |                                             |              |
      :                                             :              :
      :           <<Autres échanges ultérieurs>>    :              :
      :                                             :              :

Figure 4 : Livraison de localisation fondée sur CoA

 	3.4	Livraison de localisation dans les messages de comptabilité
Les informations de localisation peuvent aussi être rapportées dans des messages de comptabilité. Les messages de comptabilité sont générés au début de la session, quand la session s'arrête, et périodiquement durant la vie de la session. Les messages de comptabilité peuvent aussi être générés quand l'utilisateur est en itinérance pendant un transfert inter cellulaire.

Des informations comptables peuvent être nécessaires au système de facturation pour calculer la facture de l'utilisateur. Par exemple, il peut y avoir des tarifs ou taux de taxes différents appliqués selon la localisation.

Si le serveur RADIUS a besoin d'obtenir des informations de localisation dans les messages de comptabilité, il a alors besoin d'inclure un attribut Requested-Location-Info avec le message Accès accepté. Il doit être fait écho aux attributs Basic-Location-Policy-Rules et Extended-Location-Policy-Rules dans la demande de comptabilité si ils sont indiqués dans le message Accès accepté.

La Figure 5 montre l'échange de messages.

    +-----------+           +---------+                      +---------+
    |           |           | Serveur |                      |  Serveur|
    |Utilisateur|           | d'accès |                      |  RADIUS |
    |           |           | réseau  |                      |         |
    +-----------+           +---------+                      +---------+
       |                       |                                  |
       :                       :                                  :
       :         Interaction initiale du protocole                :
       :          (les détails sont omis)                         :
       :                       :                                  :
       |                       |                                  |
       |                       | Accès accepté                    |
       |                       |  + Requested-Location-Info       |
       |                       |  + Basic-Location-Policy-Rules   |
       |                       |  + Extended-Location-Policy-Rules|
       |                       |<---------------------------------|
       | Authentification      |                                  |
       | réussie               |                                  |
       |<----------------------|                                  |
       |                       |                                  |
       |                       | Demande de comptabilité          |
       |                       |  + Informations de localisation  |
       |                       |  + Données de localisation       |
       |                       |  + Basic-Location-Policy-Rules   |
       |                       |  + Extended-Location-Policy-Rules|
       |                       |--------------------------------->|
       |                       |                                  |
       |                       | Réponse de comptabilité          |
       |                       |<---------------------------------|
       |                       |                                  |

Figure 5 : Livraison de localisation dans des messages de comptabilité

 	4.	Attributs

Il est important de noter que les parties spécifiques de localisation des attributs définis ci-dessous ne sont pas destinées à être traitées par le serveur RADIUS. Un composant spécifique du serveur de localisation qui est plutôt utilisé en combinaison avec le serveur RADIUS est responsable de la réception, du traitement, et ensuite de distribuer les informations de localisation (en combinaison avec la protection appropriée du contrôle d'accès et de la confidentialité). À ce titre, du point de vue d'un serveur RADIUS, les informations de localisation sont traitées comme des données opaques.

 	4.1	Attribut Nom d'opérateur
Cet attribut porte l'identifiant de l'espace de noms de l'opérateur et le nom de l'opérateur. Le nom de l'opérateur est combiné avec l'identifiant d'espace de noms pour identifier de façon univoque le propriétaire d'un réseau d'accès. La valeur du Nom d'opérateur est un texte terminé par un non NULL dont la longueur NE DOIT PAS excéder 253 octets.

L'attribut Nom d'opérateur DEVRAIT être envoyé dans les messages Demande d'accès et Demande de comptabilité où le Acc-Status-Type (type de statut d'accès) est réglé à Start, Interim, ou Stop.

Un résumé de l'attribut Nom d'opérateur est montré ci-dessous.

 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    |            Texte            ...
+---------------+---------------+---------------+---------------+
|       Texte (suite)                                         ...
+---------------+---------------+---------------+---------------+

Type : 126 - Nom d'opérateur

Longueur : ≥ 4

Texte : le format est montré ci-dessous. Le type de données de ce champ est un texte. Tous 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ID espace noms | Nom d'opérateur                             ...
+---------------+---------------+---------------+---------------+
| Nom d'opérateur                                             ...
+---------------+---------------+---------------+---------------+

ID d'espace de noms : la valeur dans ce champ contient l'identifiant d'espace de noms de l'opérateur. La valeur de l'identifiant d'espace de noms est codée en ASCII.

Exemple : "1" (0x31) pour REALM

Nom d'opérateur : le champ de texte de longueur variable contient un nom d'opérateur de réseau d'accès. Ce champ est un type de données de texte fondé sur RADIUS.

Le champ Identifiant d'espace de noms donne des informations sur l'espace de noms de l'opérateur. Le présent document définit quatre valeurs pour cet attribut, qui sont données ci-dessous. Les identifiants d'espace de noms supplémentaires doivent être enregistrés auprès de l'IANA (voir le paragraphe 8.1) et doivent être associés à une organisation responsable de la gestion de l'espace de noms.

TADIG ("0" (0x30)) : cet espace de noms peut être utilisé pour indiquer les noms d'opérateur sur la base des codes du groupe d'échange de données de comptabilité transférées (TADIG, Transferred Account Data Interchange Group) comme défini dans [GSM]. Les codes TADIG sont alloués par le groupe de travail TADIG au sein de l'Association du système mondial pour les communications mobiles (GSM). Le code TADIG consiste en deux champs, avec une longueur totale de cinq caractères ASCII consistant en un code de pays de trois caractères et un identifiant alphanumérique d'opérateur (ou entreprise) de deux caractères.

REALM ("1" (0x31)) : l'espace de noms d'opérateur REALM peut être utilisé pour indiquer des noms d'opérateur sur la base de tout nom de domaine enregistré. Il est exigé de tels noms qu'ils soient uniques, et les droits d'utiliser un nom de domaine donné sont obtenus avec l'acquisition des droits d'utiliser un nom de domaine pleinement qualifié (FQDN, Fully Qualified Domain Nom) particulier. Comme cet opérateur est limité à l'ASCII, tout nom de domaine enregistré qui contient des caractères non ASCII doit être converti en ASCII. Le codage Punycode [RFC3492] est utilisé à cette  fin.

E212 ("2" (0x32)) : l'espace de noms E212 peut être utilisé pour indiquer des noms d'opérateur fondés sur le code de pays mobile (MCC, Mobile Country Code) et le code de réseau mobile (MNC, Mobile Network Code) définis dans [E.212].  Les valeurs de MCC/MNC sont allouées par le Bureau de normalisation des Télécommunications (TSB, Telecommunications Standardization Bureau) au sein de l'UIT-T et par des administrateurs désignés dans les différents pays. La valeur E212 consiste en trois chiffres ASCII contenant le MCC, suivi par deux ou trois chiffres ASCII contenant le MNC.

ICC ("3" (0x33)) : l'espace de noms ICC peut être utilisé pour indiquer des noms d'opérateur fondés sur les codes de transporteur de l'Union Internationale des télécommunications (ICC, International Telecommunication Union Carrier Codes) définis dans [M.1400]. Les valeurs d'ICC sont allouées par les autorités nationales de réglementation et sont coordonnées par le Bureau de normalisation des Télécommunication (TSB) au sein du Secteur de la normalisation de l'Union Internationale des Télécommunications (ITU-T). Quand on utilise l'espace de noms ICC, l'attribut consiste en trois caractères ASCII majuscules contenant un code de pays de trois lettres alphabétiques, comme défini dans [ISO], suivi de un à six caractères alphanumériques ASCII majuscules contenant l'ICC lui-même.

 	4.2	Attribut Informations de localisation
L'attribut Informations de localisation PEUT être envoyé dans le message Demande d'accès, le messages Demande de comptabilité, ces deux messages, ou aucun message. Pour le message Demande de comptabilité, le Acc-Status-Type peut être réglé à Start, Interim, ou Stop.

L'attribut Informations de localisation fournit des méta-données sur les informations de localisation, comme l'heure de vue, la durée de vie, la méthode de détermination de localisation, etc.

Son format est montré ci-dessous.

 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    |           Chaîne            ...
+---------------+---------------+---------------+---------------+
|       Chaîne (suite)                                        ...
+---------------+---------------+---------------+---------------+

Type : 127 - Informations de localisation

Longueur : ≥ 3

Chaîne : le format est montré ci-dessous. Le type de données de ce champ est une chaîne. Tous 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Indice                      | Code          |  Entité       |
+---------------+---------------+---------------+---------------+
| Heure de vue                                                  ~
+---------------+---------------+---------------+---------------+
| Heure de vue                                                  |
+---------------+---------------+---------------+---------------+
| Durée de vie                                                ...
+---------------+---------------+---------------+---------------+
| Durée de vie                                                  |
+---------------+---------------+---------------+---------------+
|   Méthode                                                   ...
+---------------+---------------+---------------+---------------+

Indice (16 bits) : la valeur d'entier de 16 bits non signée permet à cet attribut de fournir des informations relatives aux informations incluses dans l'attribut Données de localisation auquel elles se réfèrent (via l'indice).

Code (8 bits) : ce champ indique le contenu du profil de localisation porté dans l'attribut Données de localisation. Deux profils sont définis dans le présent document -- à savoir, un profil de localisation civile (voir le paragraphe 4.3.1) qui utilise la valeur (0) et un profil de localisation géospatiale (voir le paragraphe 4.3.2) qui utilise la valeur (1).

Entité (8 bits) : ce champ code la localisation à laquelle cet attribut se réfère comme une valeur d'entier non signé de 8 bits.  Les informations de localisation peuvent se référer à des entités différentes. Le présent document enregistre deux valeurs d'entité, à savoir :
La valeur (0) décrit la localisation de l'appareil client de l'utilisateur.
La valeur (1) décrit la localisation du client RADIUS.
Le registre utilisé pour ces valeurs est établi par le présent document, voir le paragraphe 8.4.

Heure de vue (64 bits) : ce champ indique quand les informations de localisation sont précises. Le type de données de ce champ est une chaîne, et le contenu est exprimé dans le format d'horodatage de 64 bits du protocole de l'heure du réseau (NTP, Network Time Protocol) [RFC1305].

Durée de vie (64 bits) : ce champ donne une indication concernant la durée pendant laquelle les informations de localisation devraient être considérées comme actuelles. Le type des données de ce champ est une chaîne et le contenu est exprimé dans le format d'horodatage de 64 bits du protocole de l'heure du réseau [RFC1305]. Noter que le champ Durée de vie est différent du champ Retention Expires utilisé dans l'attribut Basic-Location-Policy-Rules, voir le paragraphe 4.4. Le champ Retention Expires indique l'heure à laquelle il n'est plus permis au receveur de posséder les informations de localisation.

Méthode (variable) : décrit la façon dont les informations de localisation ont été déterminées. Ce champ DOIT contenir la valeur d'exactement un jeton "method" enregistré par l'IANA [RFC4119].

La longueur de l'attribut Informations de localisation NE DOIT PAS excéder 253 octets.

 	4.3	Attribut Données de localisation
L'attribut Données de localisation PEUT être envoyé dans les messages Demande d'accès et Demande de comptabilité. Pour le message Demande de comptabilité, le Acc-Status-Type peut être réglé à Start, Interim, ou Stop.

Le format est montré ci-dessous.

 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    |            Chaîne           ...
+---------------+---------------+---------------+---------------+
|       chaîne (suite)                                        ...
+---------------+---------------+---------------+---------------+

Type : 128 - Données de Localisation

Longueur : ≥ 5

Chaîne : le format est montré ci-dessous. Le type de données de ce champ est une chaîne. Tous 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Indice                      |   Localisation              ...
+---------------+---------------+---------------+---------------+
|  Localisation                                               ...
+---------------+---------------+---------------+---------------+

Indice (16 bits) : la valeur d'entier non signé de 16 bits permet que cet attribut soit associé à l'attribut Données de localisation avec les attributs d'informations de localisation.

Localisation (variable) : le format des données de localisation dépend du profil de localisation. Le présent document définit deux profils de localisation. Les détails des profils de localisation sont décrits ci-dessous.

 	4.3.1	Profil de localisation civile
La localisation civile est une façon populaire de décrire la localisation d'une entité. Ce paragraphe définit le profil d'informations de localisation civiles correspondant à la valeur (0) indiquée dans le champ Code de l'attribut Informations de localisation. Le format de localisation est fondé sur le format de codage défini au paragraphe 3.1 de la [RFC4776], selon lequel les trois premiers octets ne sont pas mis dans le champ Localisation de l'attribut Données de localisation RADIUS décrit ci-dessus (c'est-à-dire, le code pour l'option DHCP, la longueur de l'option DHCP, et l'élément "what" ne sont pas inclus).

 	4.3.2	Profil de localisation géospatiale
Ce paragraphe définit le profil d'informations de localisation géospatiale correspondant à la valeur (1) indiquée dans le champ Code de l'attribut Informations de localisation. Les informations de localisation géospatiales sont codées comme un objet opaque, et le format se fonde sur le format des informations de configuration de localisation (LCI, Location Configuration Information) défini à la Section 2 de la [RFC3825] mais commencent au troisième octet (c'est-à-dire, le code pour l'option DHCP et le champ Longueur ne sont pas inclus).

 	4.4	Attribut Basic-Location-Policy-Rules
L'attribut Basic-Location-Policy-Rules PEUT être envoyé dans les messages Demande d'accès, Accès-accepté, Défi d'accès, Changement d'autorisation, et Demande de comptabilité.

Les règles de politique contrôlent la distribution des informations de localisation. Afin de comprendre et traiter l'attribut Basic-Location-Policy-Rules, les clients RADIUS sont obligés d'utiliser une valeur par défaut de Basic-Location-Policy-Rules, sauf explicitement configuré autrement, et de faire écho à l'attribut Basic-Location-Policy-Rules qu'ils reçoivent d'un serveur. Par défaut, le champ Noter bien ne porte pas de pointeur sur des politiques de confidentialité lisibles par l'homme, la retransmission permise est réglée à zéro (0), c'est-à-dire, une distribution plus loin n'est pas permise, et le champ Retention Expires est réglé à 24 heures.

À l'égard des politiques d'autorisation, le présent document réutilise le travail fait dans la [RFC4119] et code ces politiques dans un format non XML. Deux champs ("Heure de vue" et "Durée de vie") sont de plus inclus dans l'attribut Informations de localisation pour se conformer aux exigences de GEOPRIV au paragraphe 2.7 de la [RFC3693].

Le format de l'attribut Basic-Location-Policy-Rules est montré ci-dessous.

 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    |            Chaîne           ...
+---------------+---------------+---------------+---------------+
|       Chaîne (suite)                                        ...
+---------------+---------------+---------------+---------------+

Type : 129 - Basic-Location-Policy-Rules

Longueur : ≥ 12

Chaîne : le format est montré ci-dessous. Le type de données de ce champ est une chaîne. Tous 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Fanions                      | Retention Expires           ...
+---------------+---------------+---------------+---------------+
| Retention Expires                                           ...
+---------------+---------------+---------------+---------------+
| Retention Expires             | Noter bien                  ...
+---------------+---------------+---------------+---------------+
| Noter bien                                                  ...
+---------------+---------------+---------------+---------------+

Le présent document réutilise des champs de l'élément "usage-rules" de la [RFC4119]. Ces champs ont la signification suivante :

Fanions (16 bits) : le champ Fanions est un gabarit binaire. Seul le premier bit (R) est défini dans le présent document, et il correspond au champ Retransmission permise :

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|o o o o o o o o o o o o o o o|
+-+-------------+---------------+

R = Retransmission permise
o = réservé.

Tous les bits réservés DOIVENT être à zéro. Quand la valeur du champ Retransmission permise est réglée à zéro (0), le receveur de cet objet de localisation n'a alors pas la permission de partager les informations de localisation incluses, ou l'objet comme un tout, avec d'autres parties. La valeur de "1" permet que cet attribut partage les informations de localisation avec d'autres parties en considérant les règles de politique étendues.

Retention Expires (64 bits) : ce champ spécifie une date absolue à laquelle il n'est plus permis au receveur de posséder les informations de localisation. Le type de données de ce champ est une chaîne et le format est un horodatage NTP de 64  bits [RFC1305].

Noter bien (variable) : ce champ contient un URI qui pointe sur des instructions de confidentialité lisibles par l'homme. Le type de données de ce champ est une chaîne. Ce champ est utile quand les informations de localisation sont distribuées à des entités tierces, qui peuvent inclure des humains dans un service fondé sur la localisation. Les entités RADIUS ne sont pas supposées traiter ce champ. Chaque fois qu'un objet de localisation quitte l'écosystème RADIUS, l'URI dans l'attribut Noter bien DOIT être expansé en le texte lisible par l'homme. Par exemple, quand l'objet Localisation est transféré à un environnement fondé sur SIP, le texte lisible par l'homme est alors placé dans l'élément "noter bien" de l'élément "usage-rules" contenu dans le document Objet de localisation en format de données d'information de présence (PIDF-LO, Presence Information Data Format - Location Object) (voir la [RFC4119]). Le champ Noter bien peut être vide.

 	4.5	Attribut Extended-Location-Policy-Rules
L'attribut Extended-Location-Policy-Rules PEUT être envoyé dans les messages Demande d'accès, Accès accepté, Défi d'accès, Accès rejeté, Changement d'autorisation, et Demande de comptabilité.

Le champ Ruleset Reference (référence d'ensemble de règles) de cet attribut est de longueur variable. Il contient un URI qui indique où l'ensemble de règles le plus riche peut être trouvé. Cet URI DEVRAIT utiliser le schéma d'URI HTTPS. Comme variante de la [RFC4119], ce champ contient seulement une référence et ne porte pas un ensemble de règles étendu attaché. Cette modification est motivée par les limitations de taille imposée par RADIUS.

Afin de comprendre et traiter l'attribut Extended-Location-Policy-Rules, les clients RADIUS sont obligés d'attacher l'URI à l'attribut Extended-Location-Policy-Rules quand ils sont explicitement configurés à le faire et à faire écho à l'attribut Extended-Location-Policy-Rules qu'ils reçoivent d'un serveur. Il n'est pas attendu que les clients RADIUS aient besoin de restituer les données à l'URL spécifié dans l'attribut ou d'analyser les politiques XML.

Le format de l'attribut Extended-Location-Policy-Rules est montré ci-dessous.

 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    |            Chaîne           ...
+---------------+---------------+---------------+---------------+
|       Chaîne (suite)                                        ...
+---------------+---------------+---------------+---------------+

Type : 130 - Extended-Location-Policy-Rules

Longueur : ≥ 3

Chaîne : ce champ fait au moins deux octets, et son format est montré ci-dessous. Le type de données de ce champ est une chaîne. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Ruleset Reference                                        ...
+---------------+---------------+---------------+---------------+

Ruleset Reference : ce champ contient un URI qui pointe sur les règles de politique.

 	4.6	Attribut Location-Capable
L'attribut Location-Capable permet à un NAS (ou à la fonction client d'un serveur mandataire) d'indiquer la prise en charge de la fonction spécifiée dans le présent document. L'attribut Location-Capable avec la valeur de "Capable de localisation" DOIT être envoyé avec les messages Demande d'accès, si le NAS prend en charge la fonction décrite dans le présent document et est capable d'envoyer des informations de localisation. Un serveur RADIUS NE DOIT PAS mettre au défi pour les informations de localisation sauf si l'attribut Location-Capable lui a été envoyé.

 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      | Entier                        |
+---------------+---------------+---------------+---------------+
|       Entier (suite)          |
+---------------+---------------+

Type : 131 - attribut Location-Capable

Longueur : 6

Entier : le contenu du champ Entier code les capacités demandées. Chaque valeur de capacité représente une position de bit.

Le présent document spécifie les capacités suivantes :

Nom : CIVIC_LOCATION
Description : le client RADIUS utilise CIVIC_LOCATION pour indiquer qu'il est capable de retourner une localisation civile sur la base du profil de localisation défini au paragraphe 4.3.1.
Valeur numérique : la valeur numérique de ce jeton est "1".

Nom : GEO_LOCATION
Description : le client RADIUS utilise GEO_LOCATION pour indiquer qu'il est capable de retourner une localisation géodésique sur la base du profil de localisation défini au paragraphe 4.3.2.
Valeur numérique : la valeur numérique de ce jeton est "2".

Nom : USERS_LOCATION
Description : la valeur numérique représentant USERS_LOCATION indique que le client RADIUS est capable de fournir un attribut Informations de localisation avec l'attribut Entity exprimant la valeur de zéro (0), c'est-à-dire, le client RADIUS est capable de retourner les informations de localisation de l'appareil client de l'utilisateur.
Valeur numérique : la valeur numérique de ce jeton est "4".

Nom : NAS_LOCATION
Description : la valeur numérique représentant NAS_LOCATION indique que le client RADIUS est capable de fournir un attribut Informations de localisation qui contient les informations de localisation avec l'attribut Entity exprimant la valeur de un (1), c'est-à-dire, le client RADIUS est capable de retourner les informations de localisation du NAS.
Valeur numérique : la valeur numérique de ce jeton est "8".

 	4.7	Attribut Requested-Location-Info
L'attribut Requested-Location-Info (informations de localisation demandées) permet au serveur RADIUS d'indiquer quelles informations de localisation sur quelle entité il veut recevoir. Ce dernier aspect se réfère aux entités qui sont indiquées dans le champ Entité de l'attribut Informations de localisation.

L'attribut Requested-Location-Info PEUT être envoyé dans un paquet Accès accepté, Défi d'accès, ou Changement d'autorisation.

Si le serveur RADIUS veut décider dynamiquement demande par demande de demander les informations de localisation au client RADIUS, les cas suivants doivent alors être différenciés. Si le client RADIUS et le serveur RADIUS se sont mis d'accord hors bande pour rendre obligatoire le transfert d'informations de localisation pour chaque demande d'authentification d'accès réseau, le traitement mentionné ci-dessous n'est alors pas applicable.

o	Si le serveur RADIUS exige des informations de localisation pour calculer la décision d'autorisation et si le client RADIUS ne les fournit pas avec le message Demande d'accès, l'attribut Requested-Location-Info est attaché au Défi d'accès avec une indication sur ce qui est exigé.

o	Si le serveur RADIUS ne reçoit pas les informations demandées en réponse au Défi d'accès (incluant l'attribut Requested-Location-Info) le serveur RADIUS peut alors répondre avec un message Accès rejeté avec un attribut Cause d'erreur (incluant la valeur "Informations de localisation exigées").

o	Si le serveur RADIUS aimerait des informations de localisation dans le message Demande de comptabilité mais ne les exige pas pour calculer une décision d'autorisation, alors le message Accès accepté DOIT inclure un attribut Informations exigées. Ceci est normalement le cas quand les informations de localisation sont utilisées seulement pour la facturation. Le client RADIUS DEVRAIT attacher ces informations de localisation, si elles sont disponibles, à la demande de comptabilité (sauf si la politique d'autorisation impose quelque chose de différent).

Si le serveur RADIUS n'envoie pas un attribut Requested-Location-Info, le client RADIUS NE DOIT alors PAS attacher les informations de localisation aux messages vers le serveur RADIUS. Les politiques d'autorisation de l'utilisateur, si elles sont disponibles, DOIVENT être consultées par le serveur RADIUS avant de demander la livraison des informations de localisation au client RADIUS.

La Figure 6 montre un simple échange de protocole où le serveur RADIUS indique le désir d'obtenir les informations de localisation, à savoir les informations de localisation civile de l'utilisateur, pour accorder l'accès. Comme l'attribut Requested-Location-Info est attaché au Défi d'accès, le serveur RADIUS indique que les informations de localisation sont exigées pour calculer une décision d'autorisation.

    +---------+                        +---------+
    | Client  |                        | Serveur |
    | RADIUS  |                        | RADIUS  |
    +---------+                        +---------+
         |                                  |
         |                                  |
         | Demande d'accès                  |
         | + Location-Capable               |
         |   ('CIVIC_LOCATION',             |
         |    'GEO_LOCATION',               |
         |    'NAS_LOCATION',               |
         |    'USERS_LOCATION')             |
         |--------------------------------->|
         |                                  |
         | Défi d'accès                     |
         | + Requested-Location-Info        |
         |   ('CIVIC_LOCATION',             |
         |    'USERS_LOCATION')             |
         | + Basic-Location-Policy-Rules    |
         | + Extended-Location-Policy-Rules |
         |<---------------------------------|
         |                                  |
         | Demande d'accès                  |
         | + Informations de localisation   |
         | + Données de localisation        |
         | + Basic-Location-Policy-Rules    |
         | + Extended-Location-Policy-Rules |
         |--------------------------------->|
         |                                  |
         |        ....                      |

Figure 6 : Serveur RADIUS demandant des informations de localisation

L'attribut Requested-Location-Info DOIT être envoyé par le serveur RADIUS, en l'absence d'un accord hors bande, si il veut que le client RADIUS retourne les informations de localisation et si les politiques d'autorisation le permettent. Cet attribut Requested-Location-Info PEUT apparaître dans le message Accès accepté ou Défi d'accès.

Un résumé de l'attribut est montré ci-dessous.

 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    |            Entier           ...
+---------------+---------------+---------------+---------------+
|       Entier (suite)          |
+---------------+---------------+

Type : 132 - attribut Requested-Location-Info

Longueur : 6

Entier : le contenu du champ Entier code les attributs des informations demandées. Chaque valeur de capacité représente une position de bit.

Le présent document spécifie les capacités suivantes :

Nom : CIVIC_LOCATION
Description : le serveur RADIUS utilise l'attribut Requested-Location-Info avec la valeur réglée à CIVIC_LOCATION pour demander des informations de localisation spécifiques au client RADIUS. La valeur numérique représentant CIVIC_LOCATION exige que le client RADIUS attache des attributs de localisation civiles. CIVIC_LOCATION se réfère au profil de localisation défini au paragraphe 4.3.1.
Valeur numérique : la valeur numérique de ce jeton est "1".

Nom : GEO_LOCATION
Description : le serveur RADIUS utilise l'attribut Requested-Location-Info avec la valeur réglée à GEO_LOCATION pour demander des informations de localisation spécifiques au client RADIUS. La valeur numérique représentant GEO_LOCATION exige que le client RADIUS attache des attributs de localisation géospatiaux. GEO_LOCATION se réfère au profil de localisation décrit au paragraphe 4.3.2.
Valeur numérique : la valeur numérique de ce jeton est "2".

Nom : USERS_LOCATION
Description : la valeur numérique représentant USERS_LOCATION indique que le client RADIUS DOIT envoyer un attribut Informations de localisation avec l'attribut Entité exprimant la valeur de zéro (0). Donc, il y a une relation biunivoque entre le jeton USERS_LOCATION et la valeur de zéro (0) de l'attribut Entité dans l'attribut Informations de localisation. Une valeur de zéro indique que les informations de localisation dans l'attribut Informations de localisation se réfèrent à l'appareil client de l'utilisateur.
Valeur numérique : la valeur numérique de ce jeton est "4".

Nom : NAS_LOCATION
Description : la valeur numérique représentant NAS_LOCATION indique que le client RADIUS DOIT envoyer un attribut Informations de localisation qui contient les informations de localisation avec l'attribut Entité exprimant la valeur de un (1). Donc, il y a une relations biunivoque entre le jeton NAS_LOCATION et la valeur de un (1) de l'attribut Entité dans l'attribut Informations de localisation. Une valeur de un indique que les informations de localisation dans l'attribut Informations de localisation se réfèrent au client RADIUS.
Valeur numérique : la valeur numérique de ce jeton est "8".

Nom : FUTURE_REQUESTS
Description : la valeur numérique représentant FUTURE_REQUESTS indique que le client RADIUS DOIT fournir de futures demandes d'accès pour la même session avec le même type d'informations que retournées dans le message Demande d'accès initial.
Valeur numérique : la valeur numérique de ce jeton est "16".

Nom : NONE
Description : le serveur RADIUS utilise ce jeton pour demander que le client RADIUS cesse d'envoyer des informations de localisation.
Valeur numérique : la valeur numérique de ce jeton est "32".

Si ni le bit NAS_LOCATION ni le bit USERS_LOCATION ne sont établis, alors la localisation par défaut de l'appareil client de l'utilisateur est retournée (si la politique d'autorisation le permet). Si les deux bits NAS_LOCATION et USERS_LOCATION sont établis, alors les informations de localisation retournées doivent être mises dans des attributs séparés. Si ni le bit CIVIC_LOCATION ni le bit GEO_LOCATION ne sont établis dans l'attribut Requested-Location-Info, alors aucune information de localisation n'est retournée. Si les deux bits CIVIC_LOCATION et GEO_LOCATION sont établis, alors les informations de localisation doivent être mises dans des attributs séparés. La valeur de NAS_LOCATION et de USERS_LOCATION se réfère aux informations de localisation demandées via CIVIC_LOCATION et GEO_LOCATION.

Par exemple, si les bits pour NAS_LOCATION, USERS_LOCATION, et GEO_LOCATION sont établis, alors les informations de localisation du client RADIUS et de l'appareil de client d'utilisateur sont retournées dans un format de localisation géospatiale.

 	5.	Tableau des attributs

Le tableau suivant est un guide sur quels attributs peuvent être trouvés dans quels messages RADIUS, et en quelle quantité.

Demande	Accepté	Rejeté	Défi	Demande de compta.	n°	Attribut
	0-1	0-1	0	0	0+	126	Nom d'opérateur
	0+	0	0	0	0+	127	Informations de localisation
	0+	0	0	0	0+	128	Données de localisation
	0-1	0-1	0-1	0-1	0-1	129	Basic-Location-Policy-Rules
	0-1	0-1	0-1	0-1	0-1	130	Extended-Location-Policy-Rules
	0-1	0	0	0	0	131	Location-Capable
	0	0-1	0	0-1	0	132	Requested-Location-Info
	0	0	0-1	0	0	101	Cause d'erreur (*)

(*) Note : l'attribut Cause d'erreur contient la valeur pour l'erreur "Informations de localisation exigées".

Messages Changement d'autorisation

Demande	ACK	NAK	n°	Attribut
	0-1	0	0	129	Basic-Location-Policy-Rules
	0-1	0	0	130	Extended-Location-Policy-Rules
	0-1	0	0	132	Requested-Location-Info

Légende :
0 : cet attribut NE DOIT PAS être présent.
0+ : zéro, une ou plusieurs instances de cet attribut PEUVENT être présentes.
0-1 : zéro ou une instance de cet attribut PEUT être présente.
1 : exactement une instance de cet attribut DOIT être présente.
1+ : une ou plusieurs instances de ces attributs DOIVENT être présentes.

Figure 7 : Tableau des attributs

L'attribut Cause d'erreur est défini dans la [RFC5176].

Les attributs Informations de localisation et Données de localisation PEUVENT apparaître plus d'une fois. Par exemple, si le serveur demande des informations de localisation civiles et géospatiales, deux attributs Informations de localisation doivent être envoyés.

Les attributs définis dans le présent document ne sont utilisés dans aucun message autre que ceux mentionnés à la Figure 7.

L'IANA a alloué une nouvelle valeur (509) dans le registre des Causes d'erreur avec la sémantique de "Informations de localisation exigées".

 	6.	Interopérabilité Diameter RADIUS

Quand ils sont utilisés dans Diameter, les attributs définis dans la présente spécification peuvent être utilisés comme des paires attribut-valeur (AVP) Diameter de l'espace de code 1 à 255 (espace de compatibilité d'attribut RADIUS). Aucune valeur de code Diameter supplémentaire n'est donc allouée. Les types de données et les règles de fanions, définies dans la [RFC3588], pour les AVP Diameter sont comme suit :

	Règles de fanion d'AVP
Nom d'attribut	Type de valeur	DOIT	PEUT	NE DVRT PAS	NE DOIT PAS	Chiffrement
Nom d'opérateur	OctetString		P		V,M	Oui
Informations de localisation	OctetString		P		V,M	Oui
Données de localisation	OctetString		P		V,M	Oui
Basic-Location-Policy-Rules	OctetString		P		V,M	Oui
Extended-Location-Policy-Rules	OctetString		P		V,M	Oui
Requested-Location-Info	OctetString		P		V,M	Oui
Location-Capable	OctetString		P		V,M	Oui

Les attributs RADIUS dans la présente spécification n'ont pas d'exigences particulières de traduction pour les passerelles de Diameter en RADIUS ou RADIUS en Diameter ; ils sont copiés comme ils sont, excepté pour les changements relatifs aux en-têtes, à l'alignement, et au bourrage. Voir aussi le paragraphe 4.1 de la [RFC3588] et la Section 9 de la [RFC4005].

Ce que dit la présente spécification sur l'applicabilité des attributs pour les paquets RADIUS Demande d'accès s'applique dans Diameter à la demande AA [RFC4005] ou à la demande EAP Diameter [RFC4072]. Ce qui est dit sur le Défi d'accès s'applique dans Diameter à la réponse AA [RFC4005] ou à la réponse EAP Diameter [RFC4072] avec l'AVP Code de résultat réglée à DIAMETER_MULTI_ROUND_AUTH. Ce qui est dit sur Accès accepté s'applique dans Diameter aux messages Réponse AA ou Réponse EAP Diameter qui indiquent le succès. De même, ce qui est dit sur les paquets RADIUS Accès rejeté s'applique dans Diameter aux messages Réponse AA ou Réponse EAP Diameter qui indiquent l'échec.

Ce qui est dit sur la Demande de CoA s'applique dans Diameter à la demande de ré-authentification [RFC4005].

Ce qui est dit sur la Demande de comptabilité s'applique dans Diameter aussi à la Demande de comptabilité [RFC4005].

Noter que ces AVP peuvent être utilisées par des applications Diameter autres que des [RFC4005] et [RFC4072]. Les applications sus-mentionnées sont, cependant, probablement pertinentes dans le contexte du présent document.

 	7.	Considérations sur la sécurité

Un certain nombre d'aspects de sécurité sont pertinents pour la distribution des informations de localisation via RADIUS. Ces aspects sont discutés dans les paragraphes qui suivent.

 	7.1	Sécurité de communication
Les exigences pour la protection d'un objet de localisation sont définies dans la [RFC3693] -- à savoir, l'authentification mutuelle des points d'extrémité, l'intégrité de l'objet de données, la confidentialité de l'objet de données, et la protection contre la répétition.

Si aucune authentification, protection de l'intégrité et contre la répétition entre les entités RADIUS participantes n'est fournie, des adversaires peuvent usurper et modifier les attributs transmis. Deux mécanismes de sécurité sont proposés pour RADIUS :

o	La [RFC2865] propose l'usage d'une clé statique qui a soulevé des problèmes concernant le manque de gestion dynamique des clés. Au moment de la rédaction du présent mémoire, un travail est en cours pour traiter certains des inconvénients de l'attribut de la [RFC2865] concernant la protection de la sécurité.

o	RADIUS sur IPsec [RFC3579] permet l'utilisation de mécanismes standard de gestion de clé, comme la négociation de clés Internet kerbérisées (KINK, Kerberized Internet Negotiation of Keys), le protocole d'échange de clés Internet (IKE, Internet Key Exchange Protocol), et IKEv2 [RFC4306], pour établir des associations de sécurité IPsec. La protection de la confidentialité DOIT être utilisée pour empêcher un espion d'obtenir l'accès aux informations de localisation. La protection de la confidentialité est déjà présente pour d'autres raisons dans de nombreux environnements, comme pour le transport du matériel de chiffrement dans le contexte de l'authentification et l'autorisation du protocole d'authentification extensible (EAP, Extensible Authentication Protocol). Donc, cette exigence est, dans de nombreux environnements, déjà satisfaite. L'authentification mutuelle DOIT être fournie entre les entités RADIUS voisines pour empêcher les attaques par interposition. Comme l'authentification mutuelle est déjà exigée pour le transport de clés au sein des messages RADIUS, elle ne représente pas un obstacle au déploiement. Comme la protection d'IPsec est déjà suggérée comme mécanisme pour protéger RADIUS, aucune considération supplémentaire n'a besoin d'être traitée au delà de celles décrites dans la [RFC3579].

Dans le cas où la protection IPsec n'est pas disponible pour une raison quelconque et où des mécanismes de sécurité spécifiques de RADIUS doivent être utilisés, alors les considérations suivantes s'appliquent. L'intégrité du message Demande d'accès n'est pas protégée. Cela permettrait à un adversaire de changer le contenu de l'objet de localisation ou d'insérer, modifier, et supprimer des attributs ou champs individuels. Pour traiter ces problèmes, l'authentifiant de message (80) peut être utilisé pour protéger l'intégrité du paquet Demande d'accès entier. L'authentifiant de message (80) est aussi exigé quand EAP est utilisé et donc, est pris en charge par de nombreux serveurs RADIUS modernes.

Les paquets Demande d'accès qui incluent des attributs de localisation sans un attribut Authentifiant de message (80) DEVRAIENT être éliminés en silence par le serveur RADIUS. Un serveur RADIUS qui prend en charge les attributs de localisation DOIT calculer la valeur correcte d'authentifiant de message (80) et DOIT éliminer en silence le paquet si il ne correspond pas à la valeur envoyée.

Les messages Accès accepté, incluant des attributs de localisation, sans un attribut Authentifiant de message (80) DEVRAIENT être éliminés en silence par le NAS. Un NAS qui prend en charge les attributs de localisation DOIT calculer la valeur correcte d'un authentifiant de message (80) et DOIT éliminer en silence le paquet si il ne correspond pas à la valeur envoyée.

RADIUS et Diameter ne font pas d'hypothèses sur la confiance entre les entités RADIUS traversées dans le sens que la sécurité de niveau objet n'est pas fournie par RADIUS ou Diameter. Donc, une certaine confiance doit être portée aux entités RADIUS pour qu'elles se comportent en accord avec les règles définies. De plus, le protocole RADIUS n'implique pas l'utilisateur dans ses interactions de protocole sauf pour le tunnelage des informations d'authentification (comme les messages EAP) à travers son infrastructure. RADIUS et Diameter sont même devenus un protocole de fait pour la distribution de clé pour les applications d'authentification d'accès au réseau. Donc, il y avait dans le passé des soucis quant à la confiance portée à l'infrastructure -- en particulier dans le domaine de la sécurité -- quand on arrive au chiffrement. L'infrastructure de chiffrement EAP est décrite dans la [RFC4282].

 	7.2	Considérations de confidentialité
Ce paragraphe discute des implications de confidentialité pour la distribution des informations de localisation au sein de RADIUS. Noter aussi qu'il est possible au serveur RADIUS d'obtenir des informations de localisation à partir de l'identifiant de NAS. Le présent document décrit cependant des procédures pour porter des informations de localisation plus précises sur l'hôte d'extrémité et/ou le réseau. Dans un certain nombre d'environnements de déploiement, les informations de localisation sur le réseau révèlent aussi la localisation actuelle de l'utilisateur avec un certain degré de précision, selon le de mécanisme de détermination de la localisation utilisé, la fréquence de mise à jour, la taille du réseau, et d'autres facteurs, comme les traces de mouvement.

Trois types de cas d'utilisation sont à différencier :

o	Le serveur RADIUS ne veut pas recevoir d'informations de localisation du client RADIUS.

o	Dans le cas où il y a un accord hors bande entre l'entité responsable du NAS et l'entité qui fait fonctionner le serveur RADIUS, les informations de localisation peuvent être envoyées sans une demande explicite du serveur RADIUS.

o	Le serveur RADIUS demande dynamiquement les informations de localisation au NAS.

 	7.2.1	Client RADIUS
Le client RADIUS DOIT se comporter selon les lignes directrices suivantes :

o	Si il n'existe pas d'accord hors bande et si des informations de localisation ne sont pas demandées par le serveur RADIUS, alors les informations de localisation ne sont pas divulguées par le client RADIUS.

o	Le client RADIUS DOIT passer les informations de localisation aux autres entités (par exemple, quand les informations sont écrites dans une base de données locale ou dans les fichiers de journaux d'événements) seulement avec les règles de politique. L'entité qui reçoit les informations de localisation (avec les politiques) DOIT suivre les lignes directrices données par ces règles.

o	Un client RADIUS DOIT inclure les attributs Basic-Location-Policy-Rules et Extended-Location-Policy-Rules qui sont configurés dans un paquet Demande d'accès.

o	Les mises en œuvre de NAS qui prennent en charge la présente spécification, qui sont configurées à fournir des informations de localisation, DOIVENT faire écho aux attributs Basic-Location-Policy-Rules et Extended-Location-Policy-Rules non modifiés au sein d'un paquet Demande d'accès suivant. De plus, un paquet Demande d'accès envoyé avec une valeur de type de service de "Autorise seulement" DOIT inclure les attributs Basic-Location-Policy-Rules ou Extended-Location-Policy-Rules qui ont été reçus dans un Accès accepté précédent si le fanion FUTURE_REQUESTS était établi dans l'attribut Requested-Location-Info.

 	7.2.2	Serveur RADIUS
Le serveur RADIUS est un endroit naturel pour mémoriser les politiques d'autorisation car l'utilisateur a normalement une sorte de relation de confiance avec l'entité qui gère le serveur RADIUS. Une fois que l'infrastructure est déployée et que des applications à capacité de localisation sont disponibles, il pourrait y avoir un fort désir d'utiliser aussi les informations de localisation à d'autres fins.

Le cadre de politique commun de la [RFC4745] qui a été étendu pour la confidentialité de la géolocalisation [RFC6772] est conçu à cette fin. Le protocole d'accès à la configuration en langage de balisage extensible (XCAP, Extensible Markup Language Configuration Access Protocol) [RFC4825] donne aux utilisateurs la capacité de changer leur politique de confidentialité en utilisant un protocole normalisé. Ces politiques sont un outil important pour limiter la distribution ultérieure de la localisation de l'utilisateur à d'autres services fondés sur la localisation.

Le serveur RADIUS DOIT se comporter conformément aux lignes directrices suivantes :

o	Le serveur RADIUS DOIT attacher les règles disponibles au message Accès accepté, Accès rejeté, ou Défi d'accès quand le client RADIUS est supposé fournir des informations de localisation.

o	Quand les informations de localisation sont rendues disponibles aux autres entités (par exemple, écrites sur une mémorisation stable pour un traitement ultérieur de facturation) alors le serveur RADIUS DOIT attacher les règles de confidentialité aux informations de localisation.

 	7.2.3	Mandataire RADIUS
Un mandataire RADIUS, se comportant comme un client et serveur RADIUS combinés, DOIT suivre les règles décrites aux paragraphes 7.2.1 et 7.2.2.

 	7.3	Informations d'identité et de localisation
Pour les scénarios d'usage envisagés, les identités de l'utilisateur et de son appareil sont étroitement couplées au transfert des informations de localisation. Si l'identité peut être déterminée par le réseau visité ou les courtiers RADIUS, il est alors possible de corréler les informations de localisation avec un utilisateur particulier. À ce titre, cela permet au réseau visité et aux courtiers d'apprendre les schémas de mouvement des utilisateurs.

L'identité de l'utilisateur peut "fuiter" au réseau visité ou aux courtiers RADIUS de différentes façons :

o	L'appareil de l'utilisateur peut employer une adresse fixe de contrôle d'accès au support (MAC, Media Access Control) ou fonder son adresse IP sur une telle adresse. Cela permet la corrélation de l'appareil particulier à ses différentes localisations. Des techniques existent pour éviter l'utilisation d'une adresse IP fondée sur une adresse MAC [RFC4941].  Certaines couches de réseau rendent possible d'éviter les adresses MAC ou de les changer dynamiquement.

o	Des procédures d'authentification d'accès au réseau, comme le protocole d’authentification par dialogue à énigme (CHAP, Challenge Handshake Authentication Protocol) PPP [RFC1994] ou EAP [RFC4187], peuvent révéler l'identité de l'utilisateur au titre de la procédure d'authentification. Des techniques existent pour éviter ce problème dans les méthodes EAP, par exemple en employant des identifiants d'accès réseau (NAI, Network Access Identifier) [RFC4282] privés dans le message Réponse d'identité EAP et par des méthodes spécifiques d'échanges d'identité privés dans la méthode EAP (par exemple, [RFC4187], [RFC5281], [PEAP], et [RFC5106]). La prise en charge de la confidentialité de l'identité dans CHAP n'est pas disponible.

o	RADIUS peut retourner des informations provenant du réseau de rattachement à celui visité d'une manière qui rende possible d'identifier l'utilisateur ou au moins de corréler sa session avec d'autres sessions, comme l'utilisation de données statiques dans un attribut de classe [RFC2865] ou dans certains scénarios d'usage d'attribut de comptabilité [RFC4372].

o	Des protocoles de mobilité peuvent révéler des identifiants à long terme, comme une adresse de rattachement.

o	Des protocoles de couche d'application peuvent révéler d'autres identifiants permanents.

Pour empêcher la corrélation des identités avec les informations de localisation, il est nécessaire d'empêcher les fuites des informations d'identité provenant de toutes les sources, pas juste d'une.

Malheureusement, la plupart des utilisateurs ne sont pas conscients de l'importance de la confidentialité de l'identité, et certains protocoles ne prennent pas en charge les mécanismes de confidentialité de l'identité. Ce problème est aggravé par le fait que les utilisateurs peuvent être incapables de choisir des protocoles particuliers, car le choix est souvent dicté par le type d'opérateur de réseau qu'ils utilisent, le type de réseau auquel ils souhaitent accéder, le type d'équipement qu'ils ont, ou le type de méthode d'authentification qu'ils utilisent.

Un scénario où l'utilisateur est rattaché au réseau de rattachement est, du point de vue de la confidentialité, plus simple qu'un scénario où un utilisateur voyage dans un réseau visité, car le NAS et le serveur RADIUS de rattachement sont dans le même domaine administratif. Aucune relation directe entre le réseau visité et l'opérateur du réseau de rattachement peut n'être disponible, et certains courtiers RADIUS doivent être consultés. Avec l'accès réseau fondé sur l'abonnement tel qu'utilisé aujourd'hui, l'utilisateur a une relation contractuelle avec le fournisseur du réseau de rattachement qui pourrait (théoriquement) permettre d'appliquer des considérations de confidentialité supérieures (incluant des règles de politique mémorisées dans le réseau de rattachement lui-même, afin d'empêcher une distribution plus étendue).

Dans de nombreux cas il est nécessaire de sécuriser le transport des informations de localisation le long de l'infrastructure RADIUS. Les mécanismes pour réaliser cette fonctionnalité sont discutés au paragraphe 7.1.

 	8.	Considérations relatives à l'IANA

Les types et valeurs d'attribut définis dans le présent document ont été enregistrés par l'IANA dans les espaces de noms RADIUS comme décrit dans la section "Considérations relatives à l'IANA" de la [RFC3575], en accord avec le BCP 26 [RFC5226]. De plus, le type d'attribut a été enregistré dans l'espace de noms Diameter. Pour les attributs et registres RADIUS créés par le présent document, l'IANA les a placés dans le registre des types Radius.

Le présent document définit les attributs suivants :
Nom d'opérateur
Informations de localisation
Données de localisation
Basic-Location-Policy-Rules
Extended-Location-Policy-Rules
Location-Capable
Requested-Location-Info

Se repporter à la Section 5 pour la liste des numéros enregistrés.

L'IANA a aussi alloué une nouvelle valeur (509) pour l'attribut Cause d'erreur [RFC5176] de "Location-Info-Required" en accord avec le présent document.

De plus, l'IANA a créé les nouveaux registres suivants mentionnés dans les paragraphes qui suivent.

 	8.1	Nouveau registre : Identifiant d'espace de noms d'opérateur
Le présent document définit aussi un registre Identifiant d'espace de noms d'opérateur (utilisé dans le champ Identifiant d'espace de noms de l'attribut Nom d'opérateur). Noter que le présent document demande seulement à l'IANA de tenir un registre des espaces de noms existants à utiliser dans ce champ d'identifiant, et non d'établir des espaces de noms ou de placer des valeurs dans ces espaces de noms.

L'IANA a ajouté les valeurs suivantes au registre des identifiant d'espace de nom d'opérateur en utilisant un identifiant numérique (alloués à la suite) un jeton pour l'espace de noms d'opérateur, et une personne de contact pour le registre.

Identifiant	Jeton d'espace de noms d'opérateur	Contact
 0x30	TADIG	Coordinateur TD.13 (td13@gsm.org)
 0x31	REALM	Directeurs zone IETF O&M (ops-ads@ietf.org)
 0x32	E212	Directeur UIT (tsbdir@itu.int)
 0x33	ICC	Directeur UIT (tsbdir@itu.int)

Noter que les valeurs d'identifiant ci-dessus représentent la valeur ASCII "0" (décimal 48 ou hex 0x30), "1" (décimal 49, ou hex 0x31), "2" (décimal 50, ou hex 0x32), et "3" (décimal 51, ou hex 0x33). Ce codage a été choisi pour simplifier l'analyse.

Les demandes à l'IANA pour une nouvelle valeur d'identifiant d'espace de noms, c'est-à-dire, les valeurs de 0x34 à 0xFE, seront approuvées par revue d'expert. Un expert désigné sera appointé par l'IESG.

L'expert réviseur devrait s'assurer qu'une nouvelle entrée est bien exigée ou pourrait tenir dans une base de données existante, par exemple, si il y a une réelle exigence de fournir un jeton pour un identifiant d'espace de noms parce que un est déjà en service, ou si l'identifiant de domaine plus le nom devrait être recommandés au demandeur. De plus, l'expert réviseur devrait s'assurer avec un degré raisonnable de diligence qu'une nouvelle entrée est une référence correcte à un espace de noms d'opérateur chaque fois qu'un nouveau est enregistré.

 	8.2	Nouveau registre : Profils de localisation
Le paragraphe 4.2 définit l'attribut Informations de localisation et un champ Code qui contient une valeur d'entier de 8 bits. Deux valeurs, zéro et un, sont définies dans le présent document, à savoir :
Valeur (0) : profil de localisation civile décrit au paragraphe 4.3.1
Valeur (1) : profil de localisation géospatiale décrit au paragraphe 4.3.2

Les valeurs restantes sont réservées pour une utilisation future.

Suivant les politiques mentionnées dans la [RFC3575], les bits disponibles avec la description de leur sémantique vont être alloués après le processus de revue d'expert. Des mises à jour peuvent être fournies seulement sur la base de l'approbation de l'expert. Sur la base de l'approbation de l'expert, il est possible de marquer des entrées comme "déconseillé". Un expert désigné sera appointé par l'IESG.

Chaque enregistrement doit inclure la valeur et la sémantique correspondante du profil de localisation défini.

 	8.3	Nouveau registré : Attribut Location-Capable
Le paragraphe 4.6 définit l'attribut Location-Capable qui contient un gabarit binaire. 32 bits sont disponibles, dont 4 bits sont définis par le présent document. Le présent document crée un nouveau registre de l'IANA pour l'attribut Location-Capable. L'IANA a ajouté les valeurs suivantes à ce registre :

Valeur	Jeton de capacité
1	CIVIC_LOCATION
2	GEO_LOCATION
4	USERS_LOCATION
8	NAS_LOCATION

Suivant les politiques mentionnées dans la [RFC3575], les bits disponibles avec la description de leur sémantique vont être alloués après le processus de revue d'expert. Des mises à jour peuvent être fournies seulement sur la base de l'approbation de l'expert. Sur la base de l'approbation de l'expert, il est possible de marquer des entrées comme "déconseillé". Un expert désigné sera appointé par l'IESG.

Chaque enregistrement doit inclure :
Nom : jeton de capacité (c'est-à-dire, un identifiant de la capacité)
Description : brève description indiquant la signification de l'élément "info".
Valeur numérique : valeur numérique placée dans l'attribut Capacité représentant un bit dans la chaîne de bits de l'attribut Requested-Location-Info.

 	8.4	Nouveau registre : Types d'entité
Le paragraphe 4.2 définit l'attribut Informations de localisation qui contient un champ Entité de 8 bits. Deux valeurs sont enregistrées par le présent document, à savoir :
Valeur (0) décrit la localisation de l'appareil client de l'utilisateur.
Valeur (1) décrit la localisation du client RADIUS.

Toutes les autres valeurs sont réservées pour une utilisation future.

Suivant les politiques mentionnées dans la [RFC3575], les bits disponibles avec la description de leur sémantique vont être alloués après le processus de revue d'expert. Des mises à jour peuvent être fournies seulement sur la base de l'approbation de l'expert. Sur la base de l'approbation de l'expert, il est possible de marquer des entrées comme "déconseillé". Un expert désigné sera appointé par l'IESG.

Chaque enregistrement doit inclure la valeur et une description correspondante.

 	8.5	Nouveau registre : Fanions de confidentialité
Le paragraphe 4.4 définit l'attribut Basic-Location-Policy-Rules qui contient les fanions qui indiquent les réglages de confidentialité. 16 bits sont disponibles, dans lesquels un seul bit, le bit (0), indiquant "retransmission permise" est défini par le présent document. Les bits 1 à 15 sont réservés pour une utilisation future.

Suivant les politiques mentionnées dans la [RFC3575], les bits disponibles avec la description de leur sémantique vont être alloués après le processus de revue d'expert. Des mises à jour peuvent être fournies seulement sur la base de l'approbation de l'expert. Sur la base de l'approbation de l'expert, il est possible de marquer des entrées comme "déconseillé". Un expert désigné sera appointé par l'IESG.

Chaque enregistrement doit inclure la position du bit et la sémantique du bit.

 	8.6	Nouveau registre : Attribut Requested-Location-Info
Le paragraphe 4.7 définit l'attribut Requested-Location-Info qui contient un gabarit binaire. 32 bits sont disponibles, desquels 6 bits sont définis par le présent document. Le présent document crée un nouveau registre IANA pour l'attribut Requested-Location-Info. L'IANA a ajouté les valeurs suivantes à ce registre :

Valeur	Jeton de capacité
  1	CIVIC_LOCATION
  2	GEO_LOCATION
  4	USERS_LOCATION
  8	NAS_LOCATION
16	FUTURE_REQUESTS
32	NONE

La signification de ces valeurs est définie au paragraphe 4.7.

Suivant les politiques mentionnées dans la [RFC3575], les bits disponibles avec la description de leur sémantique vont être alloués après le processus de revue d'expert. Des mises à jour peuvent être fournies seulement sur la base de l'approbation de l'expert. Sur la base de l'approbation de l'expert, il est possible de marquer des entrées comme "déconseillé". Un expert désigné sera appointé par l'IESG.

Chaque enregistrement doit inclure :
Nom : jeton de capacité (c'est-à-dire, un identifiant de la capacité)
Description : bréve description indiquant la signification de l'élément "info".
Valeur numérique : valeur numérique placée dans l'attribut Capacité représentant un bit dans la chaîne binaire de l'attribut Requested-Location-Info.

 	9.	Remerciements

Les auteurs tiennent à remercier les personnes suivantes de leur aide sur la version initiale du présent document et pour leurs apports : Chuck Black, Paul Congdon, Jouni Korhonen, Sami Ala-luukko, Farooq Bari, Ed Van Horne, Mark Grayson, Jukka Tuomi, Jorge Cuellar, et Christian Guenther.

Henning Schulzrinne a fourni le contenu des informations de localisation civile du présent document. Le format des informations de localisation géospatiale est fondé sur le travail de James Polk, John Schnizlein, et Marc Linsner. Le format de la politique d'autorisation se fonde sur le travail de Jon Peterson.

Les auteurs tiennent à remercier Victor Lortz, Anthony Leibovitz, Jose Puthenkulam, Bernrad Aboba, Jari Arkko, Parviz Yegani, Serge Manning, Kuntal Chowdury, Pasi Eronen, Blair Bullock et Eugene Chang de leurs retours sur la version initiale du présent document. Merci à Jari Arkko pour ses contributions de texte. Lionel Morand a fourni des retours détaillés sur de nombreux problèmes. Ses commentaires ont aidé à améliorer la qualité du présent document. Jouni Korhonen, Victor Fajardo, Tolga Asveren, et John Loughney ont aidé sur la section d'interopérabilité Diameter RADIUS. Andreas Pashalidis a révisé une version ultérieure du document et fourni un certain nombre de commentaires. Alan DeKok, Lionel Morand, Jouni Korhonen, David Nelson, et Emile van Bergen ont fourni des conseils sur l'attribut Requested-Location-Info et participé aux discussions sur l'échange de capacités. Allison Mankin, Jouni Korhonen, et Pasi Eronen ont fourni le texte pour le registre d'identifiant d'espace de noms d'opérateur. Jouni Korhonen a interagi avec le GSMA pour trouver une personne de contact pour l'espace de noms d'opérateur TADIG, et Scott Bradner a consulté l'UIT-T pour trouver la personne de contact pour l'espace de noms d'opérateur E212 et ICC.

Le présent document est fondé sur les discussions au sein du groupe de travail IETF GEOPRIV. Donc, les auteurs remercient Henning Schulzrinne, James Polk, John Morris, Allison Mankin, Randall Gellens, Andrew Newton, Ted Hardie, et Jon Peterson pour le temps passé à discuter les problèmes avec nous. Merci à Stephen Hayes pour l'alignement de ce travail avec les activités du 3GPP.

Nous souhaitons remercier les membres du groupe de travail itinérance mondiale du Forum Wimax (GRWG) pour leurs retours sur l'attribut Nom d'opérateur. Ray Jong Kiem nous a aidé avec sa description détaillée à corriger le document.

Les présidents du groupe de travail RADEXT, David Nelson et Bernard Aboba, ont fourni plusieurs relectures du projet et nous les remercions de leur aide et de leur patience.

Finalement, nous voudrions remercier Dan Romascanu, Glen Zorn, Russ Housley, Jari Arkko, Ralph Droms, Adrial Farrel, Tim Polk, et Lars Eggert pour leur commentaires sur le dernier appel à l'IETF ; Derek Atkins pour sa revue du directorat de la zone Sécurité ; et Yoshiko Chong pour avoir pointé une erreur dans la section des Considérations relatives à l'IANA.

 	10.	Références
 	10.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC2865]	C. Rigney et autres, "Service d'authentification à distance de l'utilisateur appelant (RADIUS)", juin 2000. (MàJ par RFC2868, RFC3575, RFC5080, RFC8044) (D.S.)

[RFC3492]	A. Costello, "Punycode : Codage Bootstring d'Unicode pour les noms de domaine internationalisés dans les applications (IDNA)", mars 2003. (P.S.)

[RFC3575]	B. Aboba, "Considérations relatives à l'IANA pour le service d'authentification distante d'utilisateur appelant (RADIUS)", juillet 2003. (MàJ RFC2865) (P.S.)

[RFC3588]	P. Calhoun et autres, "Protocole fondé sur Diameter", septembre 2003. (Remplacée par la RFC6733) (P.S.)

[RFC3825]	J. Polk, J. Schnizlein, M. Linsner, "Option du protocole de configuration dynamique d'hôte pour les informations de configuration de localisation fondées sur des coordonnées", juillet 2004. (Obsolète, voir RFC6225) (P.S.)

[RFC4776]	H. Schulzrinne, "Option du protocole de configuration dynamique d'hôte (DHCPv4 et DHCPv6) pour les informations de configuration d'adresses civiles", novembre 2006. (Remplace RFC4676) (P.S.)

[RFC5176]	M. Chiba et autres, "Extensions d'autorisation dynamique au service d'authentification distante d'utilisateur appelant (RADIUS)", janvier 2008. (Remplace RFC3576) (Information)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

 	10.2	Références pour information

[E.212]	Recommandation UIT-T E.212, "Plan d'identification internationale des terminaux mobile et utilisateurs mobiles",  UIT-T, Genève, mai 2004.

[GMLv3]	"Open Geography Markup Language (GML) Implementation Specification", OGC 02-023r4, janvier 2003, <http://www.opengis.org/techno/implementation.htm>.

[GSM]	"TADIG Naming Conventions", Version 4.1, GSM Association Official Document TD.13, juin 2006.

[ISO]	Organisation Internationale de normalisation,"Codes pour la représentation des noms de pays et de leurs subdivisions -- Partie 1 : Codes de pays, 2ième édition", Norme ISO 3166, novembre 2006.

[M.1400]	Recommandation UIT-T M.1400, "Désignations pour les interconnexions entre les réseaux des opérateurs", janvier 2004.

[PEAP]	Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected EAP Protocol (PEAP) Version 2", Travail en cours, octobre 2004.

[RFC1305]	D. Mills, "Protocole de l'heure du réseau, version 3, spécification, mise en œuvre et analyse", STD 12, mars992. (Remplacée par RFC5905)

[RFC1994]	W. Simpson, "Protocole d'authentification par mise en cause de la prise de contact en PPP (CHAP)", août 1996.

[RFC2866]	C. Rigney, "Comptabilité RADIUS", juin 2000. (MàJ par RFC2867, RFC5080) (Information)

[RFC3579]	B. Aboba, P. Calhoun, "Prise en charge du protocole d'authentification extensible (EAP) par RADIUS", septembre 2003. (MàJ par RFC5080) (Information)

[RFC3693]	J. Cuellar et autres, "Exigences pour Geopriv", février 2004. (Information)

[RFC4005]	P. Calhoun et autres, "Application de serveur d'accès au réseau Diameter", août 2005. (P.S.) (Remplacée par RFC7155)

[RFC4017]	D. Stanley et autres, "Exigences de méthode pour le protocole d'authentification extensible (EAP) pour les LAN sans fil", mars 2005. (Information)

[RFC4072]	P. Eronen et autres,  "Application Diameter du protocole d'authentification extensible (EAP)", août 2005. (P.S.  ; MàJ par RFC8044)

[RFC4119]	J. Peterson, "Format d'objet de localisation GEOPRIV fondé sur la présence", décembre 2005. (MàJ par RFC5139) (P.S.)

[RFC4187]	J. Arkko, H. Haverinen, "Méthode du protocole d'authentification extensible pour l'authentification et l'accord de clé de 3e génération (EAP-AKA)", janvier 2006. (Information ; MàJ par 9048)

[RFC4282]	B. Aboba et autres, "L'identifiant d'accès réseau", décembre 2005. (P.S., Remplacée par RFC7542)

[RFC4306]	C. Kaufman, "Protocole d'échange de clés sur Internet (IKEv2)", décembre 2005. (Obsolète, voir la RFC5996)

[RFC4372]	F. Adrangi et autres, "Identité de l'utilisateur facturé", janvier 2006. (P.S.)

[RFC4745]	H. Schulzrinne et autres, "Politique commune : un format de document pour exprimer les préférences de confidentialité", février 2007. (P.S.)

[RFC4825]	J. Rosenberg, "Protocole d'accès de configuration (XCAP) du langage de balisage extensible (XML)", mai 2007. (P.S.)

[RFC4941]	T. Narten et autres, "Extensions de confidentialité pour l'auto configuration d'adresse sans état dans IPv6", septembre  2007, DOI 10.17487/RFC4941. (D.S. ; remplace RFC3041 ; remplacée par 8981)

[RFC5106]	H. Tschofenig et autres, "Méthode du protocole d'authentification extensible/protocole d'échange de clés Internet version 2 (EAP-IKEv2)", février 2008. (Expérimentale)

[RFC5281]	P. Funk, S. Blake-Wilson, "Protocole authentifié de sécurité de couche Transport version 0 tunnelé dans le protocole d'authentification extensible (EAP-TTLSv0)", août 2008. (Information)

[RFC6772]	 H. Schulzrinne, éd., H. Tschofenig, éd., J. Cuellar, J. Polk, J. Morris et M. Thomson, "Politique de géolocalisation : format de document pour exprimer les préférences de confidentialité pour les informations de localisation", janvier  2013. (P.S.)

 	Appendice A.	Confrontation aux exigences de GEOPRIV

Cette section compare les exigences pour un protocole utilisant GEOPRIV, décrites dans la [RFC3693], par rapport à l'approche de la distribution des objets de localisation avec RADIUS.

Dans les Appendices A.1 et A.2, on discute les implications de confidentialité quand les entités RADIUS rendent les informations de localisation disponibles à d'autres parties. Dans l'Appendice A.3, les exigences sont confrontées à ces deux scénarios.

 	A.1	Distribution des informations de localisation au réseau de rattachement de l'utilisateur
Quand les informations de localisation sont convoyées du client RADIUS au serveur RADIUS, elles pourraient ensuite être rendues disponibles pour des fins différentes. Ce paragraphe discute les implications de confidentialité de rendre les informations de localisation disponibles à d'autres entités.

Pour utiliser un scénario plus générique, on suppose que le RADIUS visité et le serveur RADIUS de rattachement appartiennent à des domaines administratifs différents. Le receveur de localisation obtient des informations de localisation sur une cible particulière via des protocoles spécifié en dehors du domaine d'application du présent document (par exemple, SIP, HTTP, ou une API).

La figure suivante montre graphiquement les entités qui interagissent :

     Réseau visité    |        Réseau de rattachement
                      |
                      |        +----------+
                      |        |Détenteur |
                      |        |des règles|
                      |        +----+-----+
                      |             |
                      |    interface|de règles
    +----------+      |             V                     +------------+
    |Générateur|      |        +----------+  notification |  Receveur  |
    |localisat.|      |        |Serveur de|<------------->|  de        |
    +----------+  interface de |localisat.|  interface    |localisation|
    |Client    |<------------->+----------+               +---------  -+
    |RADIUS    |  publication  |Serveur   | par exemple, SIP/HTTP
    +----------+      |        |RADIUS    |
                      |        +----------+
 par exemple, NAS   RADIUS
                      |
                      |

Figure 8 : Serveur de localisation au réseau de rattachement

Le terme "Détenteur des règles" dans la Figure 8 note l'entité qui crée l'ensemble de règles d'autorisation.

 	A.2	Distribution des informations de localisation au réseau visité
Ce paragraphe décrit un scénario où les informations de localisation sont rendues disponibles aux receveurs de localisation par un serveur de localisation dans le réseau visité. Un identifiant doit être utilisé comme un indice au sein de la base de données de localisation. Un identifiant possible est l'identifiant d'accès réseau (NAI). Les [RFC4282] et [RFC4372] donnent les bases concernant si les entités dans le réseau visité peuvent obtenir le NAI de l'utilisateur en clair.

Le réseau visité fournit des informations de localisation à un receveur de localisation (par exemple, via SIP ou HTTP). Le présent document permet au NAS d'obtenir la politique de confidentialité de l'utilisateur via l'interaction avec le serveur RADIUS. Autrement, seules les politiques par défaut, qui sont très restrictives, sont disponibles. Cela permet au serveur de localisation dans le réseau visité de s'assurer qu'il agit conformément aux politiques de l'utilisateur.

La figure suivante montre graphiquement les entités qui interagissent :

    Réseau visité      |        Réseau de rattachement
                       |
     +----------+      |
     |Receveur  |      |
     |de        |      |
     |localisat.|      |
     +----------+      |
          ^            |        +----------+
          |            |        |Détenteur |
      interface de     |        | des      |
      notification     |        | règles   |
          |            |        +----+-----+
          |            |             |
          |            |    interface|de règles
          v            |             |
     +----------+      |             |
     |Serveur de|      |             v
     |localisat.|  Transport    +----------+
     +----------+  des règles   |Serveur   |
     |Client    |<------------->|RADIUS    |
     |RADIUS    |   RADIUS      +----------+
     +----------+      |
     |Générateur|      |
     |de locali-|
     | sation   |
     +----------+

Figure 9 : Serveur de localisation au réseau visité

Les informations de localisation voyagent toujours avec les politiques de confidentialité. Le présent document permet au client RADIUS d'obtenir ces politiques. Le serveur de localisation peut ensuite agir en accord avec ces politiques pour fournir le contrôle d'accès en utilisant l'attribut Extended-Location-Policy-Rules et pour adhérer aux déclarations de confidentialité dans l'attribut Basic-Location-Policy-Rules.

 	A.3	Correspondance aux exigences
Le paragraphe 7.1 de la [RFC3693] détaille les exigences d'un "Objet de localisation". On discute des exigences dans la liste suivante :

Exigence 1. (généralités sur l'objet de localisation) :
*	Concernant l'exigence 1.1, la syntaxe et la sémantique de l'objet de localisation sont tirées des [RFC3825] et [RFC4776]. Il est de plus possible de le convertir au format utilisé dans le langage de balisage géographique [GMLv3], utilisé avec PIDF-LO [RFC4119].
*	Concernant l'exigence 1.2, un certain nombre de champs dans le format d'informations de localisation civiles sont facultatifs.
*	Concernant l'exigence 1.3, l'inclusion du type d'élément de place (CAtype 29) utilisé dans le format civil DHCP donne encore une classification de la localisation. Cet attribut peut être vu comme une extension.
*	Concernant l'exigence 1.4, le présent document ne définit pas le format des informations de localisation.
*	Concernant l'exigence 1.5, les informations de localisation sont seulement envoyées du client RADIUS au serveur RADIUS.
*	Concernant l'exigence 1.6, l'objet de localisation contient les informations de localisation et les règles de confidentialité.  Les informations de localisation sont décrites aux paragraphes 4.2, 4.3.1, et 4.3.2. Les règles de confidentialité correspondantes sont détaillées aux paragraphes 4.4 et 4.5.
*	Concernant l'exigence 1.7, l'objet de localisation est utilisable dans divers protocoles. Le format de l'objet est réutilisé d'autres documents, comme précisé aux paragraphes 4.2, 4.3.1, 4.3.2, 4.4, et 4.5.
*	Concernant l'exigence 1.8, le codage de l'objet de localisation met l'accent sur un format de codage léger à utiliser avec RADIUS.

Exigence 2. (champs de l'objet de localisation) :
*	Concernant l'exigence 2.1, l'identifiant de cible est porté dans le protocole d'authentification d'accès au réseau (par exemple, dans la réponse EAP-Identity quand EAP est utilisé et/ou dans la méthode EAP elle-même). Comme décrit au paragraphe 7.2 du présent document, cela a un certain nombre d'avantages si cet identifiant n'est pas porté en clair. Cela est possible avec certaines méthodes EAP par lesquelles l'identité dans la réponse EAP-Identity contient seulement des informations pertinentes pour acheminer la réponse au réseau de rattachement de l'utilisateur. L'identité de l'utilisateur est protégée par le protocole d'authentification et d'échange de clés.
*	Concernant l'exigence 2.2, le receveur de localisation est, dans le scénario principal, le serveur RADIUS de rattachement. Pour un scénario où le receveur de localisation obtient les informations de localisation du serveur de localisation via HTTP ou SIP, les mécanismes respectifs définis dans ces protocoles sont utilisés pour identifier le receveur. Le générateur de localisation ne peut pas, a priori, connaître les receveurs si ils ne sont pas définis dans ce protocole.
*	Concernant l'exigence 2.3, les accréditifs du receveur de localisation sont connus des entités RADIUS sur la base des mécanismes de sécurité définis dans le protocole RADIUS lui-même. La Section 7 du présent document décrit les mécanismes de sécurité offerts par le protocole RADIUS. La même chose est vraie pour l'exigence 2.4.
*	Concernant l'exigence 2.5, les paragraphes 4.2, 4.3.1, et 4.3.2 décrivent le contenu des champs Localisation. Comme le format de localisation lui-même n'est pas défini dans le présent document, les vecteurs de mouvement et de direction mentionnés dans l'exigence 2.6 ne sont pas définis.
*	Concernant l'exigence 2.6, le présent document donne la capacité au serveur RADIUS d'indiquer quel type d'informations de localisation il aimerait voir de la part du client RADIUS.
*	Concernant l'exigence 2.7, les informations de temps sont fournies avec le champ "Sighting Time" (heure de vue) et "Time-to-Live" (durée de vie) définis au paragraphe 4.2.
*	Concernant l'exigence 2.8, une référence à un ensemble de règles externes (plus détaillé) est fournie avec l'attribut Extended-Location-Policy-Rules au paragraphe 4.5.
*	Concernant l' exigence 2.9, les en-têtes et en-queues de sécurité sont fournis au titre du protocole RADIUS ou même au titre de IPsec.
*	Concernant l'exigence 2.10, un numéro de version dans RADIUS est fourni avec l'enregistrement des attributs par l'IANA. Les nouveaux attributs reçoivent un nouveau numéro de l'IANA.

Exigence 3. (Types de données de localisation) :
*	Concernant l'exigence 3.1, le présent document réutilise les informations de localisation civiles et géospatiales comme décrit aux paragraphes 4.3.2 et 4.3.1.
*	Avec la prise en charge des informations de localisation civiles et géospatiales, l'exigence 3.2 est satisfaite.
*	Concernant l'exigence 3.3, les informations de localisation géospatiales utilisées par le présent document se réfèrent seulement aux coordonnées absolues. Cependant, la granularité des informations de localisation peut être réduite avec l'aide des champs AltRes, LoRes, et LaRes décrits dans la [RFC3825].
*	Concernant l'exigence 3.4, d'autres types de données de localisation peuvent être ajoutés via de nouveaux systèmes de références de coordonnées (CRS -- voir le champ Datum dans la [RFC3825]) et via des extensions aux [RFC3825] et [RFC4776].

Le paragraphe 7.2 de la [RFC3693] détaille les exigences d'un "protocole d'utilisation". La liste de ces exigences est ci-dessous.

Exigence 4 : le protocole utilisateur doit respecter les instructions de confidentialité et de sécurité codées dans l'objet de localisation (LO) concernant la transmission et la mémorisation du LO. Le présent document exige que les entités qui visent à rendre les informations de localisation disponibles à des tiers soient obligées de respecter les instructions de confidentitalité.

Exigence 5 : le protocole utilisateur va normalement faciliter le transport des clés associées aux accréditifs aux parties respectives, c'est-à-dire, que l'établissement des clés est de la responsabilité du protocole utilisateur. La Section 7 du présent document spécifie comment les mécanismes de sécurité sont utilisés dans RADIUS et comment ils peuvent être réutilisés pour assurer la protection de la sécurité de l'objet de localisation. De plus, les considérations de confidentialité (voir le paragraphe 7.2) relèvent aussi de cette exigence.

Exigence 6  (Transfert d'un seul message) : en particulier, pour traquer de petits appareils cibles, la conception devrait permettre la transmission d'un seul message/paquet de localisation comme une transaction complète. Le codage de l'objet de localisation est conçu spécifiquement pour l'inclusion dans un seul message qui respecte même la taille de la MTU (de chemin).

Le paragraphe 7.3 de la [RFC3693] détaille les exigences d'un "transfert de données de localisation fondé sur la règle". Ces exigences sont mentionées ci-dessous.

Exigence 7. (Règles du serveur de localisation) : avec le scénario de la Figure 8, la décision d'un serveur de localisation de donner à un receveur de localisation l'accès aux informations de localisation est fondée sur les règles de confidentialité définies par le détenteur des règles, qui sont mémorisées dans le réseau de rattachement. À l'égard du scénario de la Figure 9, les règles de confidentialité définies par le détenteur des règles sont envoyées du serveur RADIUS au NAS (voir plus de détails aux paragraphes 4.4, 4.5, et 7.2).

Exigence 8. (Règles pour le générateur de localisation) : pour tous les scénarios d'usage, il est possible de considérer la règle de confidentialité avant de transmettre les informations de localisation du NAS au serveur RADIUS ou même à des tiers. Dans le cas d'un accord hors bande entre le propriétaire du NAS et celui du serveur RADIUS, la confidentialité pourrait être appliquée à une granularité supérieure. Pour le scénario de la Figure 8, le réseau visité est déjà en possession des informations de localisation de l'utilisateur avant l'authentification et l'autorisation de l'utilisateur. Une corrélation entre la localisation et l'identité de l'utilisateur pourrait, cependant, n'être pas toujours possible pour le réseau visité (comme expliqué au paragraphe 7.2). Un serveur de localisation dans le Réseau visité doit évaluer les ensembles de règles disponibles.

Exigence 9 (Règles de celui qui voit) : le détenteur des règles pourrait définir (via des mécanismes qui sortent du domaine d'application du présent document) quelles règles de politique sont divulguées à d'autres entités.

Exigence 10. (Langage complet des règles) : GEOPRIV a défini un langage de règles capable d'exprimer  une large gamme de règles de confidentialité qui sont applicables dans le domaine de la distribution des objets de localisation. Un ensemble de règles de base est fourni avec l'attribut Basic-Location-Policy-Rules (paragraphe 4.4). Une référence à l'ensemble de règles étendu est donnée au paragraphe 4.5. Le format de ces règles est décrit dans les [RFC4745] et [RFC6772].

Exigence 11. (Langage limité des règles) : un ensemble limité (ou basique) de règles est fourni par l'attribut Policy-Information au paragraphe 4.4 (et comme introduit avec PIDF-LO [RFC4119]).

Le paragraphe 7.4 de la [RFC3693] détaille les exigences d'un "objet de localisation de confidentialité et sécurité". Ces exigences sont données ci-dessous.

Exigence 12 (Protection de l'identité) : la prise en charge de pseudonymes sans lien est fournie par l'usage d'un protocole correspondant d'authentification et d'échange de clés. De tels protocoles sont disponibles, par exemple, avec la prise en charge de EAP comme méthode d'authentification de l'accès au réseau. Certaines méthodes EAP prennent en charge la confidentialité passive de l'identité d'utilisateur, tandis que d'autres prennent même en charge la confidentialité active de l'identité d'utilisateur. Cette question est discutée plus en détails à la Section 7. L'importance de la confidentialité de l'identité d'utilisateur et de la protection de l'identité a déjà été reconnue comme une propriété importante (voir, par exemple, un document sur les exigences de la méthode EAP pour les LAN sans fil [RFC4017]).

Exigence 13 (Exigences d'accréditifs) : comme décrit à la Section 7, les messages de signalisation RADIUS peuvent être protégés avec IPsec. Cela permet qu'un certain nombre de protocoles d'authentification et d'échange de clés soient utilisés au titre de IKE, IKEv2, ou KINK.

Exigence 14 (Caractéristiques de sécurité) : GEOPRIV définit quelques exigences de sécurité pour la protection des objets de localisation, comme l'authentification mutuelle de point d'extrémité, l'intégrité de l'objet de données, la confidentialité de l'objet de données, et la protection contre la répétition. Comme décrit à la Section 7, ces exigences sont satisfaites avec l'usage de IPsec si l'authentification mutuelle se réfère aux entités RADIUS (agissant comme diverses entités GEOPRIV) qui communiquent directement les unes avec les autres.

Exigence 15 (Chiffrement minimal) : un minimum de mécanismes de sécurité sont rendus obligatoires par l'usage de RADIUS. La sécurité de communication pour les objets de localisation entre les éléments de l'infrastructure RADIUS est fournie par le protocole RADIUS (incluant IPsec et son cadre de gestion dynamique de clés) plutôt que de s'appuyer sur la sécurité d'objet via S/SIME (qui n'est pas disponible avec RADIUS).

 	Adresse des auteurs

Hannes Tschofenig (éditeur)	Farid Adrangi	Mark Jones	
Nokia Siemens Networks	Intel Corporatation	Bridgewater Systems Corporation	
Linnoitustie 6	2111 N.E. 25th Avenue	303 Terry Fox Drive	
Espoo  02600	Hillsboro OR	Ottawa, Ontario  K2K 3J1	
Finland	USA	CANADA	
mél : Hannes.Tschofenig@gmx.net	mél : farid.adrangi@intel.com	mél : mark.jones@bridgewatersystems.com	
URI: http://www.tschofenig.priv.at			

Avi Lior	Bernard Aboba	
Bridgewater Systems Corporation	Microsoft Corporation	
303 Terry Fox Drive	One Microsoft Way	
Ottawa, Ontario  K2K 3J1	Redmond, WA  98052	
CANADA	USA	
mél : avi@bridgewatersystems.com	mél : bernarda@microsoft.com